BGP Redistribution

[routerdork]

I swear I read somewhere that when BGP is redistributed into an IGP all NLRI details are stripped from the route. I'm having trouble confirming this since I don't remember where I think I read it at. Can anyone provide a source confirming or denying this?

[ScottF]

Doesn't this happen the other way round, as in IGP redistribution into BGP strips info?

[deanwebb]

Found http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3e/irg-iproute-bgp-xe-3e-book/irg-overview.html#GUID-A562F485-E994-486C-B91E-3C8E6618E038

And then searched on "redistrib" until I found:

It is possible to configure BGP peers that exchange both unicast and multicast Network Layer Reachability Information (NLRI) where multiprotocol BGP routes can be redistributed into BGP. Multiprotocol extensions, however, will be ignored by any peers that do not support multiprotocol BGP. When PIM builds a multicast distribution tree through a unicast BGP network (because the route through the unicast network is the most attractive), the RPF check may fail, preventing the MDT from being built. If the unicast network runs multiprotocol BGP, peering can be configured using the appropriate multicast address family. The multicast address family configuration enables multiprotocol BGP to carry the multicast information and the RPF lookup will succeed.

If IGP doesn't support NLRI multiprotocol extensions, then this implies they'll be ignored... but stripped? Hmm... "strip" did not give a hit on that page.

So I went to the BGP-4 RFC: https://tools.ietf.org/html/rfc4271

Did not see any explicit stuff on stripping info, but I'm not very well-versed on BGP, so I may have missed something. There is some discussion in the RFC about doing things to keep NLRI infos from conflicting with each other, but I'm not sure if that answers your question.

[NetworkGroover]

Found http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3e/irg-iproute-bgp-xe-3e-book/irg-overview.html#GUID-A562F485-E994-486C-B91E-3C8E6618E038

And then searched on "redistrib" until I found:

It is possible to configure BGP peers that exchange both unicast and multicast Network Layer Reachability Information (NLRI) where multiprotocol BGP routes can be redistributed into BGP. Multiprotocol extensions, however, will be ignored by any peers that do not support multiprotocol BGP. When PIM builds a multicast distribution tree through a unicast BGP network (because the route through the unicast network is the most attractive), the RPF check may fail, preventing the MDT from being built. If the unicast network runs multiprotocol BGP, peering can be configured using the appropriate multicast address family. The multicast address family configuration enables multiprotocol BGP to carry the multicast information and the RPF lookup will succeed.

If IGP doesn't support NLRI multiprotocol extensions, then this implies they'll be ignored... but stripped? Hmm... "strip" did not give a hit on that page.

So I went to the BGP-4 RFC: https://tools.ietf.org/html/rfc4271

Did not see any explicit stuff on stripping info, but I'm not very well-versed on BGP, so I may have missed something. There is some discussion in the RFC about doing things to keep NLRI infos from conflicting with each other, but I'm not sure if that answers your question.

Hmmm... not sure I'm following but I'll take a stab/guess.  You could probably summarize this by putting 2 and 2 together.  If IGP doesn't support NLRI, they would be ignored (not stripped).  I'd have to imagine that the IGP then takes that data and puts it into a format that can be digested by the internal data structures, so in a sense I guess you might consider it stripping - but not really.  It's more conversion than stripping - my radical theory anyway.

EDIT - I should probably elaborate a bit more.  When I think of "stripping", I think of a situation where you may have a given DSCP value, and a device literally passes the exact same payload, but strips the DSCP value (Which I guess is still not "stripping", it's just changing it to 0).  In this case though, you're converting from a BGP format to an IGP format.

[routerdork]

Now that you mention "ignore" I seem to remember this, I remembered wrong. I ran into this for the first time today and it caught me by surprise to see an EIGRP route get redistributed back into BGP and have a weight with it from another router.

[that1guy15]

Nope, both OSPF and EIGRP do it., MP-BGP will carry over the metric of an EIGRP prefix as an extended community. Also the whole function of OSPF "super backbone" works off OSPF attributes being converted into BGP communities.

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_bgpcc.html#wp1067175
https://tools.ietf.org/html/rfc4577

[NetworkGroover]

Nope, both OSPF and EIGRP do it., MP-BGP will carry over the metric of an EIGRP prefix as an extended community. Also the whole function of OSPF "super backbone" works off OSPF attributes being converted into BGP communities.

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_bgpcc.html#wp1067175
https://tools.ietf.org/html/rfc4577

Sorry I'm probably muddying the waters here being a tard, but isn't what you're talking about an IGP going into BGP?

Isn't the OP talking about BGP going into an IGP?  Or were you responding to ScottF ?

[routerdork]

I was referring to both. Site A and B run BGP with our global WAN provider. Each site has a different AS number. At Site A BGP is redistributed into EIGRP and EIGRP into BGP. Site A connects to several other sites via an in-country WAN including Site B. At Site B BGP is redistributed into EIGRP and EIGRP into BGP. This is where the issue comes in. The routes redistributed from EIGRP into BGP cause obtain a weight of 32768 which is better than the global WAN route that doesn't have a weight. So when Site B flapped, convergence happened and Site B's routing table now preferred all the redistributed routes from EIGRP due to a higher weight. I went through a few different scenarios but none achieved the full fail over dynamically. In the end I set the weight on the incoming global WAN routes on the BGP routers at Sites A and B so that they will always prefer their own routes over redistributed routes. Problem solved.

[wintermute000]

guys, ipspace.net has a wealth of interesting info re: design choices for DC fabrics and various L2/L3 designs.

I would post up the PDFs except its paid material

Nonetheless as a consultant or SE surely you could spin this as a work expense?


And yes I've seen that exact weight scenario trip up a CCIE before. Of course, we realised and fixed the issue pronto But he had not considered it in his design. Takeaway: redistribution is bad (but in this particular case we did not have the scope to deviate from the customer's existing overall routing domain, which is a redistribution mess that we both loathe) - if redistributing IGP into BGP, sort the weights

[NetworkGroover]

redistribution is bad

Amen, brother.  Another good reason for not using EIGRP.

[routerdork]

So while I agree that I'm not a fan of redistribution it really makes things easy if you control it properly and don't have a ton of redundancy. Are there any other design considerations you guys have used or seen over redistribution?

[routerdork]

guys, ipspace.net has a wealth of interesting info re: design choices for DC fabrics and various L2/L3 designs.

Never heard of them, I'll check it out.

[routerdork]

guys, ipspace.net has a wealth of interesting info re: design choices for DC fabrics and various L2/L3 designs.

Never heard of them, I'll check it out.

LOL it's been too long since I've been to his website I guess. I've read some things but didn't realize it had subscription stuff too.