North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Discovering AS Path confederation...
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 >
|