North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: BGP Confederation config problem...

  • From: Andy McConnell
  • Date: Mon Mar 09 12:08:24 1998

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> <[email protected]>     2400 Broadway Ave. #D230
richard_parker> +1 (310) 829-5949                   Santa Monica, CA 90404
richard_parker> 
richard_parker>