Discovering AS Path confederation...

Thu Jul 26 15:45:22 UTC 2001

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