Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: problem at mae-west tonight?

  • From: Matthew Kaufman
  • Date: Sun Jul 14 20:04:35 1996

Original message <199607150340.UAA00784@elite.exodus.net>
From: Robert Bowman <rob@elite.exodus.net>
Date: Jul 14, 20:40
Subject: Re: problem at mae-west tonight?
> 
> 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.

Sure. Netcom changed out an FDDI card. There is a bad ARP entry or bridge
table entry somewhere, which causes packets transmitted by Netcom towards me
to be black-holed. MFS is, as far as I know, _still_ investigating this.
However we can see the route server as can Netcom. The route server
states our MW IP address, and so they transmit packets towards us using that,
and yet the underlying layer 2 fabric is discarding those before they get to
us. Yes, IF EVERYTHING WAS WORKING PROPERLY it is fully meshed... but
things don't always work properly.

What I know is that when I stopped believing the route server's routes
to Netcom, there was still a discontinuity, but when I stopped telling the
route server my routes (and it then stopped telling Netcom), Netcom switched
to sending my packets to our transit provider, and my Netcom connectivity
came back. That required both manual intervention AND tearing down the whole
session with the route server (I can't easily get the route server to stop
telling Netcom about me while still telling everyone else about me without 
editing my policy and waiting for it to appear on the RS)

-matthew kaufman
 matthew@scruz.net

ps. At this point, we still can't see Netcom... problem has lasted for 1 day,
  8 hours. From my interface (198.32.136.18) I cannot ping Netcom at
  198.32.136.15, but I can ping Alternet at 198.32.136.42. That points to
  a layer 2 discontinuity.

- - - - - - - - - - - - - - - - -




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.