|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: problem at mae-west tonight?
> Robert, > > It's my understanding that MAE-W is composed of two facilities, > one at MFS, and the second at NASA-AMES. > Actually, it's three. There's another one at 2 North Second Street for ConXioN. > It's my understanding that while a virtual medium is created, they > actually reside on two separate gigaswitches. I seem to recall 1 > or 2 OC3s connecting the two..... > Actually, it's a combination of Gigaswitches and NetEdge boxes. There are 2 OC3s between the GS at MFS and the GS at Ames. There's a single T3 to North Second. (That'll become an OC3 soon, though). > Given this, it is, then, possible that the route server is located > on segment A, while customers x,y, and z are located on segment B. > RS's are both located at Ames. Additionally, there are multiple segments at Ames and at MFS. > If you are on segment A, and try to follow the RSes advice to talk > to x, y, and z, you are depending on the links connecting the two > segments. > > However, I may be incorrect. > That is correct. > -alan > > ......... Robert Bowman is rumored to have said: > ] > ] We experienced the same thing with Netcom. Currently we are peered with over > ] 40 netwroks through the RS, but I have only had this problem with Netcom. > ] > ] Is it really a next-hop problem or a Netcom internal problem? Last time > ] this happened, about 2 weeks ago, they cleared their RA session and did > ] some other things and everything came up fine. I did not get details from > ] the routing folks over there. > ] > ] I don't quite see how and where the layer 2 topology comes into play here. > ] Netcom should simply be seeing routes (through the RS) that state your MW > ] IP address and the routes advertised from it. Is there some reason that your MW > ] IP would be unreachable by Netcom? I am confused as to why this would ever > ] happen in the MW scenario. Now the PB-NAP is a different story with the > ] non-fully meshed scenario. > ] > ] Please explain what you mean Matt. > ] > ] Rob > ] Exodus Communications Inc. > ] > > ] > > The problem I have with the route server this evening is that I announce > ] > > my routes to the route server, and my policy configuration in the route server > ] > > reflects that I peer with Netcom, and so the route server tells Netcom how > ] > > to reach me. Unfortunately, packets leaving Netcom headed to me at layer 2 > ] > > are going into a black hole. To fix this, I've had to dump my peering with > ] > > the route server entirely, so that Netcom is only seeing my routes from AGIS > ] > > (our transit provider) and not from the route server. Ugh. My fears about > ] > > the route server not knowing the status of the layer 2 topology have come true, > ] > > and there's no way to fix this that doesn't involve manual intervention. > ] > > > ] > > -matthew kaufman > ] > > [email protected] > ] > > > ] > > > ] > > ] > Well, I run gated on a BSDI box for the Hooked MAE West router. I'm > ] > thinking about implementing a "pingnouse INTERVAL" option on the > ] > peer/group commands in gated, so it will periodically ping next hops > ] > received from the route servers and set the nouse bit if the nexthop > ] > is unreachable. Any better ideas? > ] > > ] > It would be nice to come up with a good mechanism for doing 3rd party > ] > keepalives that cisco and other router vendors would be willing to > ] > implement. > ] > > ] > Rob > ] > > ] > ] > ] > > - - - - - - - - - - - - - - - - -
|