RE: BGP Confederation config problem...
Andy,
We have a 4-memberAS confederation, each with two IBGP peers. The arrangement looks sort of like an octagon. the "r" is AS3 is an internal hop, not a BGP peer.
_______ ______ | R-----R---r | | / | | | | |AS2 R | |AS3 R | ----|-- ----|- | | ____|__ ____|_ |AS4 R | |AS1 R | | \ | | / | | R-------R | ------- ------
The problem is this: How do you get BGP to choose the shortest "AS PATH", since internal AS paths are ignored in selecting BGP routes? Right now, to top router in AS4 will always choose a route through (2 3 1) instead of (1), because it prefers "external" routes (even external confederation routes) over internal routes.
So, when given a choice, the router on the distant side of the AS will ALWAYS prefer the three-AS-hop path, because it is external. Is there a way around this?!?
Perhaps I'm misunderstanding your question, but I thought BGP considered AS_path length before considering whether the path was an external path or an internal path. According to the Cisco documentation, BGP uses the following criteria to select a path for a destination: 1. If the path specifies a next hop that is inaccessible, drop the update. 2. Prefer the path with the largest weight. 3. If the weights are the same, prefer the path with the largest local preference. 4. If the local preferences are the same, prefer the path that was originated by BGP running on this router. 5. If no route was originated, prefer the route that has the shortest AS_path. 6. If all paths have the same AS_path length, prefer the path with the lowest origin type (where IGP is lower than EGP, and EGP is lower than Incomplete). 7. If the origin codes are the same, prefer the path with the lowest MED attribute. 8. If the paths have the same MED, prefer the external path over the internal path. 9. If the paths are still the same, prefer the path through the closest IGP neighbor. 10. Prefer the path with the lowest IP address, as specified by the BGP router ID. So, I'm going to make the following assumptions: A. Your BGP configuration is correct, i.e. the routes to AS1 via AS2 don't have a larger weight or local preference. B. You don't have any connectivity problems, i.e. the BGP table in the top router in AS4 contains routes that follow both the (2 3 1) path and the (1) path to the networks in AS1. C. AS4 only originates routes to networks in AS4, not the entire BGP confederation, i.e. no explicit "network" statements for the networks in AS1 and no redistribution of IGP routes to AS1's networks into AS4's BGP table. If this is all true, then perhaps your problem is a "next hop" problem. A next hop problem can occur when the next hop for a BGP entry is unreachable via the IGP. In your example the direct routes to AS1 in the top router in AS4 would have as their next hop the external interface of the bottom router in AS4. So, are you running an IGP on the external interface of the bottom router in AS4? If you are not running an IGP on the external interface, then BGP is not selecting the direct routes to AS1 because they're being rejected due to rule 1 in the above table. If this is indeed the problem, make sure that when you go to fix the problem that you run the IGP on the external interface in "passive" mode so that the peer doesn't hear your IGP updates. -Richard ------------------------------------------------------------ Richard Parker Third Point Systems <richard_parker@thirdpoint.com> 2400 Broadway Ave. #D230 +1 (310) 829-5949 Santa Monica, CA 90404
The problem with AS paths (at least on Cisco) is that within a confederation, the internal AS path is ingored in making the selection. -Andy -- Andy McConnell アンディ マッコネル Network Architect, NTT Multimedia Communications Laboratories I think myself that we have more machinery of government than is necessary, too many parasites living on the labor of the industrious. -- Thomas Jefferson, 1812 On 7 Mar 1998, Richard Parker wrote: richard_parker> Andy, richard_parker> richard_parker> > We have a 4-memberAS confederation, each with two IBGP peers. The richard_parker> > arrangement looks sort of like an octagon. the "r" is AS3 is an richard_parker> > internal hop, not a BGP peer. richard_parker> > richard_parker> > _______ ______ richard_parker> > | R-----R---r | richard_parker> > | / | | | | richard_parker> > |AS2 R | |AS3 R | richard_parker> > ----|-- ----|- richard_parker> > | | richard_parker> > ____|__ ____|_ richard_parker> > |AS4 R | |AS1 R | richard_parker> > | \ | | / | richard_parker> > | R-------R | richard_parker> > ------- ------ richard_parker> > richard_parker> > The problem is this: How do you get BGP to choose the shortest richard_parker> > "AS PATH", since internal AS paths are ignored in selecting BGP richard_parker> > routes? Right now, to top router in AS4 will always choose a richard_parker> > route through (2 3 1) instead of (1), because it prefers richard_parker> > "external" routes (even external confederation routes) over richard_parker> > internal routes. richard_parker> > richard_parker> > So, when given a choice, the router on the distant side of the AS richard_parker> > will ALWAYS prefer the three-AS-hop path, because it is external. richard_parker> > Is there a way around this?!? richard_parker> richard_parker> Perhaps I'm misunderstanding your question, but I thought BGP richard_parker> considered AS_path length before considering whether the path was richard_parker> an external path or an internal path. According to the Cisco richard_parker> documentation, BGP uses the following criteria to select a path richard_parker> for a destination: richard_parker> richard_parker> 1. If the path specifies a next hop that is inaccessible, drop richard_parker> the update. richard_parker> 2. Prefer the path with the largest weight. richard_parker> 3. If the weights are the same, prefer the path with the largest richard_parker> local preference. richard_parker> 4. If the local preferences are the same, prefer the path that richard_parker> was originated by BGP running on this router. richard_parker> 5. If no route was originated, prefer the route that has the richard_parker> shortest AS_path. richard_parker> 6. If all paths have the same AS_path length, prefer the path richard_parker> with the lowest origin type (where IGP is lower than EGP, and richard_parker> EGP is lower than Incomplete). richard_parker> 7. If the origin codes are the same, prefer the path with the richard_parker> lowest MED attribute. richard_parker> 8. If the paths have the same MED, prefer the external path over richard_parker> the internal path. richard_parker> 9. If the paths are still the same, prefer the path through the richard_parker> closest IGP neighbor. richard_parker> 10. Prefer the path with the lowest IP address, as specified by richard_parker> the BGP router ID. richard_parker> richard_parker> So, I'm going to make the following assumptions: richard_parker> richard_parker> A. Your BGP configuration is correct, i.e. the routes to AS1 via richard_parker> AS2 don't have a larger weight or local preference. richard_parker> B. You don't have any connectivity problems, i.e. the BGP table richard_parker> in the top router in AS4 contains routes that follow both the richard_parker> (2 3 1) path and the (1) path to the networks in AS1. richard_parker> C. AS4 only originates routes to networks in AS4, not the entire richard_parker> BGP confederation, i.e. no explicit "network" statements for richard_parker> the networks in AS1 and no redistribution of IGP routes to richard_parker> AS1's networks into AS4's BGP table. richard_parker> richard_parker> If this is all true, then perhaps your problem is a "next hop" richard_parker> problem. A next hop problem can occur when the next hop for a BGP richard_parker> entry is unreachable via the IGP. richard_parker> richard_parker> In your example the direct routes to AS1 in the top router in AS4 richard_parker> would have as their next hop the external interface of the bottom richard_parker> router in AS4. So, are you running an IGP on the external richard_parker> interface of the bottom router in AS4? richard_parker> richard_parker> If you are not running an IGP on the external interface, then BGP richard_parker> is not selecting the direct routes to AS1 because they're being richard_parker> rejected due to rule 1 in the above table. If this is indeed the richard_parker> problem, make sure that when you go to fix the problem that you richard_parker> run the IGP on the external interface in "passive" mode so that richard_parker> the peer doesn't hear your IGP updates. richard_parker> richard_parker> -Richard richard_parker> richard_parker> ------------------------------------------------------------ richard_parker> Richard Parker Third Point Systems richard_parker> <richard_parker@thirdpoint.com> 2400 Broadway Ave. #D230 richard_parker> +1 (310) 829-5949 Santa Monica, CA 90404 richard_parker> richard_parker>
participants (2)
-
Andy McConnell
-
Richard Parker