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>