BGP-IGP redistribution
below is from the discussion of dbmack and pete templin at www.routerie.com
the common practice:
Use the bgp redistribute-internal command to enable redistribution of iBGP routes into IGP.
I'm looking for a detailed analysis of the pros & cons of redistribution of EBGP\IBGP into IGP protocols under special circumstances. The more prevalent school of thought is {never do it} & the other is, if you must do it under special circumstances, exercise caution {because of loops}.
For #1, IGPs (or CPUs) just aren't made to handle hundreds of thousands of routes. I and many other service providers have gone to an IGP core with iBGP as my "IGP" for reachability to my customers. As a result, my IGP doesn't see any activity when customer links go up or down, and stays rock-steady at ~205 routes total .
For #2, on the surface this one seems easy. BGP's loop prevention is only accurate to the AS level, not to the hop level. It relies on the IGP for that. Since all of the various BGP 'details' are lost, the IGP will struggle to stay stable.
The mere loss of information (AS path, local pref, MED, communities, etc.) would be enough to talk me out of wanting to do this.
A case study of why NOT:
===================================
On Friday morning, April 25 of 1997, a small ISP in Florida made a mistake in the configuration of the router that joined their small network to Sprint. This ISP, known by their AS number, 7007, allowed all the routes learned from Sprint using BGP to be exported back to Sprint as their own routes. This actually is easy to do, as BGP implementations can take routes from IGP and convert them into EGP routes. In this case, the IGP converted CIDR routes into classful routes.
The Sprint BGP speaker was not filtering properly either, and began sending out updates that added AS7007 as the correct route for a portion every CIDR block (essentially, the first class C, or 24 bit long, network prefix).
This misinformation first spread through Sprint's network, then to neighboring NSPs, including ANS, MCI, UUNet, and other NSPs. Many routers crashed, as their routing tables suddenly doubled in size (an additional route added for each CIDR block), and the routing instability spread throughout the Internet. Remember that when a router crashes, it drops its BPG connection with its peer, who then sends out an update withdrawing all the routes previous announced by the crashed router. It took over an hour for the Internet to gradually become stable again. Network managers added filters that blocked routes that included AS7007, fixing the problem until the ISP solved their local problem and Sprint reconnected them to the Internet.
And this was just an accident, caused by a misconfiguration that redistributed routing information learned from BGP, into an IGP, then back into BGP.
===================================
in some cases you might be forced to use non-BGP routers in your BGP transit network
– multi-vendor environment, old models
– IBGP scaling solutions are not available on intermediate routers
• if the IGP support route tagging, then you might have a chance to convert BGP information into IGP route tags and back
– however, exporting and importing BGP information must be done in a consistent way in the whole routing domain
– some limitations might exist on this conversion, but at least mandatory attributes should be converted and transited
The real key to BGP-IGP-BGP muckups is that the AS path is lost. Subsequently, the routes being originated out of BGP from IGP learned from BGP only have as their AS path. As a result, many other ASes tend to prefer these 'new' routes based on their shorter path.
Another key is that many ISPs place a higher local preference on customer routes than on peer/transit routes. If they accept a full table of short-AS-path routes from a customer and prefer them, they end up thinking the Internet is on the other side of the customer's link, rather than the myriad of interconnections they'd worked so hard to build.
(Confessional debugging moment) Typing that paragraph made me realize a unique design trick that can help prevent catastrophes: use the default local preference to your advantage. Currently, I assign local preference values of 110-300 for upstream routes and 100000-150000 for customer routes. The customer local pref is assigned in the same route map used to prefix and AS filter their announcements. If someone forgets the route map, customer routes inherit local pref 100, and therefore treats them with less preference than any other production route in place. I'd been considering restructuring my LP values, and this provides a constraint for stability.
As far as why TO do it, I'd have to say that reasons 1 and 2 are inexcusable. If your gear can't do BGP right, get rid of it. If your business plan doesn't support that expense, you don't deserve to be in business. For IBGP scaling solutions, the route reflector clients have no clue that they're involved in a scaling solution, so just design around that. Or heck, roll out MPLS and you don't need BGP on P routers
RFC 1268:
A.2.1 Propagation of BGP Information via the IGP
While BGP can provide its own mechanism for carrying BGP information within an AS, one can also use an IGP to transport this information,
as long as the IGP supports complete flooding of routing information(providing the mechanism to distribute the BGP information) and onepass convergence (making the mechanism effectively atomic). If an IGP is used to carry BGP information, then the period of desynchronization described earlier does not occur at all, since BGP information propagates within the AS synchronously with the IGP, and
the IGP converges more or less simultaneously with the arrival of the new routing information. Note: that the IGP only carries BGP information and should not interpret or process this information.
A.2.2 Tagged Interior Gateway Protocol
Certain IGPs can tag routes exterior to an AS with the identity of their exit points while propagating them within the AS. Each border gateway should use identical tags for announcing exterior routing information (received via BGP) both into the IGP and into Internal BGP when propagating this information to other border gateways within the same AS. Tags generated by a border gateway must uniquely identify that particular border gateway--different border gateways must use different tags.
the common practice:
Use the bgp redistribute-internal command to enable redistribution of iBGP routes into IGP.
I'm looking for a detailed analysis of the pros & cons of redistribution of EBGP\IBGP into IGP protocols under special circumstances. The more prevalent school of thought is {never do it} & the other is, if you must do it under special circumstances, exercise caution {because of loops}.
For #1, IGPs (or CPUs) just aren't made to handle hundreds of thousands of routes. I and many other service providers have gone to an IGP core with iBGP as my "IGP" for reachability to my customers. As a result, my IGP doesn't see any activity when customer links go up or down, and stays rock-steady at ~205 routes total .
For #2, on the surface this one seems easy. BGP's loop prevention is only accurate to the AS level, not to the hop level. It relies on the IGP for that. Since all of the various BGP 'details' are lost, the IGP will struggle to stay stable.
The mere loss of information (AS path, local pref, MED, communities, etc.) would be enough to talk me out of wanting to do this.
A case study of why NOT:
===================================
On Friday morning, April 25 of 1997, a small ISP in Florida made a mistake in the configuration of the router that joined their small network to Sprint. This ISP, known by their AS number, 7007, allowed all the routes learned from Sprint using BGP to be exported back to Sprint as their own routes. This actually is easy to do, as BGP implementations can take routes from IGP and convert them into EGP routes. In this case, the IGP converted CIDR routes into classful routes.
The Sprint BGP speaker was not filtering properly either, and began sending out updates that added AS7007 as the correct route for a portion every CIDR block (essentially, the first class C, or 24 bit long, network prefix).
This misinformation first spread through Sprint's network, then to neighboring NSPs, including ANS, MCI, UUNet, and other NSPs. Many routers crashed, as their routing tables suddenly doubled in size (an additional route added for each CIDR block), and the routing instability spread throughout the Internet. Remember that when a router crashes, it drops its BPG connection with its peer, who then sends out an update withdrawing all the routes previous announced by the crashed router. It took over an hour for the Internet to gradually become stable again. Network managers added filters that blocked routes that included AS7007, fixing the problem until the ISP solved their local problem and Sprint reconnected them to the Internet.
And this was just an accident, caused by a misconfiguration that redistributed routing information learned from BGP, into an IGP, then back into BGP.
===================================
in some cases you might be forced to use non-BGP routers in your BGP transit network
– multi-vendor environment, old models
– IBGP scaling solutions are not available on intermediate routers
• if the IGP support route tagging, then you might have a chance to convert BGP information into IGP route tags and back
– however, exporting and importing BGP information must be done in a consistent way in the whole routing domain
– some limitations might exist on this conversion, but at least mandatory attributes should be converted and transited
The real key to BGP-IGP-BGP muckups is that the AS path is lost. Subsequently, the routes being originated out of BGP from IGP learned from BGP only have
Another key is that many ISPs place a higher local preference on customer routes than on peer/transit routes. If they accept a full table of short-AS-path routes from a customer and prefer them, they end up thinking the Internet is on the other side of the customer's link, rather than the myriad of interconnections they'd worked so hard to build.
(Confessional debugging moment) Typing that paragraph made me realize a unique design trick that can help prevent catastrophes: use the default local preference to your advantage. Currently, I assign local preference values of 110-300 for upstream routes and 100000-150000 for customer routes. The customer local pref is assigned in the same route map used to prefix and AS filter their announcements. If someone forgets the route map, customer routes inherit local pref 100, and therefore treats them with less preference than any other production route in place. I'd been considering restructuring my LP values, and this provides a constraint for stability.
As far as why TO do it, I'd have to say that reasons 1 and 2 are inexcusable. If your gear can't do BGP right, get rid of it. If your business plan doesn't support that expense, you don't deserve to be in business. For IBGP scaling solutions, the route reflector clients have no clue that they're involved in a scaling solution, so just design around that. Or heck, roll out MPLS and you don't need BGP on P routers
RFC 1268:
A.2.1 Propagation of BGP Information via the IGP
While BGP can provide its own mechanism for carrying BGP information within an AS, one can also use an IGP to transport this information,
as long as the IGP supports complete flooding of routing information(providing the mechanism to distribute the BGP information) and onepass convergence (making the mechanism effectively atomic). If an IGP is used to carry BGP information, then the period of desynchronization described earlier does not occur at all, since BGP information propagates within the AS synchronously with the IGP, and
the IGP converges more or less simultaneously with the arrival of the new routing information. Note: that the IGP only carries BGP information and should not interpret or process this information.
A.2.2 Tagged Interior Gateway Protocol
Certain IGPs can tag routes exterior to an AS with the identity of their exit points while propagating them within the AS. Each border gateway should use identical tags for announcing exterior routing information (received via BGP) both into the IGP and into Internal BGP when propagating this information to other border gateways within the same AS. Tags generated by a border gateway must uniquely identify that particular border gateway--different border gateways must use different tags.
posted by Jun Wen at 11:51 AM
0 Comments:
Post a Comment
<< Home