Community NO-EXPORT
Community NO-EXPORT I have AS1 connected to AS2 via two different paths and different routers |-------------------| |--------| | |---------| |-----OTHERS | AS1 | | AS2 | | 192.168.0.0/16 | | | | |---------| |-----OTHERS |-------------------| |--------| I advertise my class B range from AS1 for example 192.168.0.0/16 on both routers but to achieve some load-sharing I addvertise 192.168.0.0/17 on one router and 192.168.128.0/17 on the other router as well. I setup a community NO-EXPORT for the /17 so AS2 won't advertise them out to other AS's. The question In AS2 BGP selects the best route and /17 should be selected because of the longest match rule. BGP places the /17 in its routing table. BGP should only UPDATE the other IBGP Peers with its routing table entry (IE Each router won't send it's entire BGP database). So if the /17 will be sent to other IBGP with the community NO-EXPORT how do other AS's learn about the /16 ? Dave Cahill
|-------------------| |--------| | |---------| |-----OTHERS | AS1 | | AS2 | | 192.168.0.0/16 | | | | |---------| |-----OTHERS |-------------------| |--------|
I advertise my class B range from AS1 for example 192.168.0.0/16 on both routers but to achieve some load-sharing I addvertise 192.168.0.0/17 on one router and 192.168.128.0/17 on the other router as well.
I setup a community NO-EXPORT for the /17 so AS2 won't advertise them out to other AS's.
The question In AS2 BGP selects the best route and /17 should be selected because of the longest match rule. BGP places the /17 in its routing table. BGP should only UPDATE the other IBGP Peers with its routing table entry (IE Each router won't send it's entire BGP database). So if the /17 will be sent to other IBGP with the community NO-EXPORT how do other AS's learn about the /16 ?
AS2 will have both /17's and the /16 in it's routing table. Those are three separate destinations. The /16 will never actually be used, because there's a more specific (one of the /17's) for every possible address within that /16, but that's irrelevant. There are three distinct destinations (196.168/16, 192.168/17, 192.168.128/17) and BGP will (absent some sort of filtering) install the best route to each such destination in it's table. Absent filtering, AS2 would send all three routes to it's BGP peers, but your NO EXPORT community will cause the two /17s to be filtered, so only the /16 will make it beyond AS2. -- Brett
At Tuesday 07:36 PM 8/22/00, Brett Frankenberger wrote:
Absent filtering, AS2 would send all three routes to it's BGP peers, but your NO EXPORT community will cause the two /17s to be filtered, so only the /16 will make it beyond AS2.
Correct me if I'm wrong, but isn't there a synchronization issue here as well? E.g.: AS2 is transit provider, probably has bgp synchronization on (default), and will only propagate routes to other AS's that have made it into their IGP. The question then is: have all 3 routes made it into AS2's IGP successfully? Only if the answer is yes, will it actually propagate that /16.
On Wed, Aug 23, 2000 at 10:03:21AM -0400, Kai Schlichting wrote:
Correct me if I'm wrong, but isn't there a synchronization issue here as well? E.g.: AS2 is transit provider, probably has bgp synchronization on (default), and will only propagate routes to other AS's that have made it into their IGP. The question then is: have all 3 routes made it into AS2's IGP successfully? Only if the answer is yes, will it actually propagate that /16.
Synchronization is almost universally disabled in the real world. None of the IGPs in use today would cope well with a full BGP table redistributed into them. Redistribution of BGP->IGP is rarely needed or advisable.
On Wed, Aug 23, 2000 at 09:55:59AM -0700, Bradley Dunn wrote:
On Wed, Aug 23, 2000 at 10:03:21AM -0400, Kai Schlichting wrote:
Correct me if I'm wrong, but isn't there a synchronization issue here as well? E.g.: AS2 is transit provider, probably has bgp synchronization on (default), and will only propagate routes to other AS's that have made it into their IGP. The question then is: have all 3 routes made it into AS2's IGP successfully? Only if the answer is yes, will it actually propagate that /16.
Synchronization is almost universally disabled in the real world.
Color me confused, but isn't the synchronization waiting on the NEXT_HOPs showing up in your IGP, not the actual BGP route? After all, the issue is this: BR-A - (your internal network) - BR-B A route shows up at BR-A with a nexthop of some interface on BR-A (or the loopback interface of BR-A). It is then propogated via iBGP to BR-B. It is only unsafe to install said route and propogate it BR-B's peers if the route's nexthop is not reachable by BR-B. This is a far cry from having to inject your BGP into your IGP. I will note that this isn't how Cisco has it documented, and I don't know how they actually treat the sync issue. The documentation actually says it does wait for the route to show up in the IGP.
None of the IGPs in use today would cope well with a full BGP table redistributed into them. Redistribution of BGP->IGP is rarely needed or advisable.
However, its a wonderful way to see the failure states of your router's IGPs. :-) -- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
participants (5)
-
Bradley Dunn -
Brett Frankenberger -
Dave Cahill -
Jeff Haas -
Kai Schlichting