North American Network Operators Group

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

RE: Discovering AS Path confederation...

  • From: Daniel Golding
  • Date: Thu Jul 26 12:09:01 2001

Chris,

It appears your speaking of a somewhat well known phenomenon -

- Route A is learned via path 1-2-3-4 in a BGP confederation
- The best path is 1-6-4 due to any number of reasons, including metrics and
traffic engineering.
- The 1-6-4 path could be learned from numerous connected sub-AS's, all of
which have a different AS-Path and AS-Set towards 4.

>From my experience this is only observable from inside the confederated
network, and is because path selection is not based on AS-Set length.

This can occur in a steady-state condition in a BGP confederation network.
It is more likely to be seen in especially well-connected sub-AS's, as they
have more neighbors to learn paths from.

- Dan

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Chris Rapier
> Sent: Thursday, July 26, 2001 11:45 AM
> To: Vijay Gill
> Cc: [email protected]
> Subject: Re: Discovering AS Path confederation...
>
>
>
>
>
> Vijay Gill wrote:
> >
> > On Wed, 25 Jul 2001, Chris Rapier wrote:
> >
> > > I can say the observed divergence corresponds to this previously seen
> > > path. E.g.... I run a trace and find it traverses 701 702
> 8414 2912 7262
> > > 101 while the route table indicates its path should be 701
> 7262 101. If
> > > I know that 701 is confederating 8414 and 2912 then I know that the
> > > actual path corresponds to the routing table. However, I first need to
> > > determine that UUnet if actually doing that.
> >
> > I think you're confusing confederations with something else entirely.
>
> Confusing the the concept of confederation with something else is
> entirely possible. This is an aspect of the work I didn't think I'd have
> to get into and have been struggling to catch up in.
>
> Let me see if I can get some examples of what I am seeing...
>
> Here we go...
>
> trace -> 144.9.158.8 :  5050 701
> bgp ->   144.9.158.8 : 5050 701 701 701 701 6334
>
> t 147.128.68.22 :  5050 11536
> b 147.128.68.22 : 5050 701 11536
>
> t 148.245.167.130 :  5050 701 6503 3561
> b 148.245.167.130 : 5050 701 6503
>
> t 194.85.129.80 :  5050 701 702 8350
> b 194.85.129.80 : 5050 701 702 8350
>
> t 199.183.24.200 :  5050 701 702 2551
> b 199.183.24.200 : 5050 701
>
> t 200.186.247.25 :  5050 701 702 209 11415
> b 200.186.247.25 : 5050 701 4230 11415
>
>
> What I am looking for is a way to explaion the differences between the
> ASes reported traveresed during the traceroute and the path as reported
> by our local BGP routing tables.
> Some of them makes sense as 701 -  705 inclusive is UUNet. And in
> something like this:
> t 199.183.24.200 :  5050 701 702 2551
> b 199.183.24.200 : 5050 701
>
> I am going with the assumption that UUNet provides
> transit/network/whatrever services for AS 2551. Therefore, UUNet doesn't
> actually have externally announce that route because it is still,
> essentailly, part of the UUnet network. I don't know if that assumption
> is warranted though so I'm looking to see how I can prove that
> assumption.
>
> I am having more difficulty trying to explain something like...
> t 200.186.247.25 :  5050 701 702 209 11415
> b 200.186.247.25 : 5050 701 4230 1141
>
> Where it seemingly traverses an AS thats nowhere close to the BGP
> reported path. I've some guesses such as the routing table is out of
> date (but how often would we see something like this), something is
> misconfigured at UUnet, or there is some administrative stuff going on
> (like 209 is the same or owned by 4230).
>
> The reason why I am doing this is because I'm planning on dropping some
> monitors at a few locations in the I2 network and mapping traffic to the
> AS mesh. Mostly I just want to see what it tells me at this point (but
> there are some other aspects of it as well which might actually prove to
> be useful). My initial assumption was that the BGP reported paths
> conformed to reality closely enough that I wouldn't have to do
> independent path discovery (like using the nikhef traceroute or
> something). However, I need to prove that. Ya know?
>
> > For
> > example, the confederated paths are not visible outside a
> confederated AS.
> > Eg, some paths will show up like 1 2 3 4 5 6
> >
> > and 2 may have an internal as path of (65518 655025 655123 23)
> but for all
> > intents and purposes, the internal structure of 2 is completely
> opaque to
> > entities not in the same AS.
>
> Will all of the internal paths always correspond to private ASes? Or can
> they be pretty much any AS (or series of ASes) controlled or otherwise
> serviced by that primary AS? When I read the RFC my impression was that
> they didn't have to be private.
>
> Chris Rapier
> PSC/NCNE/NLANR
>