problem at mae-west tonight?
Owen DeLong
owen at DeLong.SJ.CA.US
Mon Jul 15 18:22:06 UTC 1996
> 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 at 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
> ] >
> ]
> ]
> ]
>
>
More information about the NANOG
mailing list