Robert, It's my understanding that MAE-W is composed of two facilities, one at MFS, and the second at NASA-AMES. 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..... 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. 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. -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 ] > > matthew@scruz.net ] > > ] > > ] > ] > 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 ] > ] ] ]

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 ] > > matthew@scruz.net ] > > ] > > ] > ] > 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 ] > ] ] ]