Jump to content
Sign in to follow this  
cdipman

H2/H2+ Section 2.4

Recommended Posts

"Ensure that any prefix that originate in any of these main site will not advertise back to same site via redundant gateway."

 

Each sites have 2 redundant PE and CE routers. So to me, this mean that if a route is redistributed from bgp to ospf in DC by R15, it should not get back to mpls bgp by R16.

 

What is the solution used for fulfill this requirement?

Please comment.

Regards.

Share this post


Link to post
Share on other sites

Hello,

 

Please see this topic. Everything has been answered there already.

 

Hidden Content

    Give reaction to this post to see the hidden content.

Share this post


Link to post
Share on other sites

Hello,

 

Please see this topic. Everything has been answered there already.

 

Hidden Content

    Give reaction to this post to see the hidden content.

 

No, it's not. I am also following that thread, but it's not related to the routing issues that can happen between the redundant gateways per sites

 

This is what i mean from my post. Let's consider DC. there is mutual redistribution on R15/16 between ospf and bgp.

Routes gets redistributed from ospf to bgp on R15 to mpls, once in the core mpls, these routes can possibly be redistributed back to ospf from bgp by R16. The inverse is also true from bgp to ospf by one gateway let's say R15 and redistributed back to bgp by other gateway R16.

 

I think in this req, cisco is asking to ensure that one gateway is not redistributing back the routes to where it came from. The solution discussed in that thread is only about routes coming from one site to other sites and prevent from coming back to origin site. But not related to the redundant gateway routers doing redistributions like R15/16 R55/56

 

please give any comment.

  • Like 1

Share this post


Link to post
Share on other sites

No, it's not. I am also following that thread, but it's not related to the routing issues that can happen between the redundant gateways per sites

 

This is what i mean from my post. Let's consider DC. there is mutual redistribution on R15/16 between ospf and bgp.

Routes gets redistributed from ospf to bgp on R15 to mpls, once in the core mpls, these routes can possibly be redistributed back to ospf from bgp by R16. The inverse is also true from bgp to ospf by one gateway let's say R15 and redistributed back to bgp by other gateway R16.

 

I think in this req, cisco is asking to ensure that one gateway is not redistributing back the routes to where it came from. The solution discussed in that thread is only about routes coming from one site to other sites and prevent from coming back to origin site. But not related to the redundant gateway routers doing redistributions like R15/16 R55/56

 

please give any comment.

 

If I remember the H2/H2+ solutions correctly we are not importing the RT exported on the neighboring PE on given site back. In other words, on R15 we set RT export to 65002:1516 but we are not importing it back on R16, and wise versa. So that should do the trick. To be on the safe side, you can configure SOO with the neighbor command to add another level of loop prevention, which will be effective even if the RT import-export policy is changed in the future.

 

In the opposite direction on R15/16, when redistributing BGP into OSPF we set the metric-type to 1. When redistributing OSPF into BGP, we are matching internal and metric-type 2 only, so there is no route feedback. On 55/56 there should redistribution filtering pre-configured. Rest of the sites do not perform mutual redistribution.

Share this post


Link to post
Share on other sites

If I remember the H2/H2+ solutions correctly we are not importing the RT exported on the neighboring PE on given site back. In other words, on R15 we set RT export to 65002:1516 but we are not importing it back on R16, and wise versa. So that should do the trick. To be on the safe side, you can configure SOO with the neighbor command to add another level of loop prevention, which will be effective even if the RT import-export policy is changed in the future.

 

In the opposite direction on R15/16, when redistributing BGP into OSPF we set the metric-type to 1. When redistributing OSPF into BGP, we are matching internal and metric-type 2 only, so there is no route feedback. On 55/56 there should redistribution filtering pre-configured. Rest of the sites do not perform mutual redistribution.

 

Yes, SoO is a good candidate for that.

 

In R15/16, this type of redistribution is done only for H2 and not for H2+ in the solutions. In H2+, they do normal redistribution back and fother on R15/16. and on R18 they do metric-type 1 to ospf from bgp.

Any reason why they don't use same method for both H2/H2+ on R15/16?

 

The only difference as far as i know, in H2, we aggregate 10.2.0.0/16 and in H2+, we aggregate 10.0.0.0/16. which is right based on the req from section 2.4

 

Regards.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...