North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Agenda suggestions?
- From: Curtis Villamizar
- Date: Thu Jan 26 13:09:40 1995
In message <199501260100.SAA01035@ski.utah.edu>, Tired of the Information Super
> Vadim Antonov wrote:
> >Another thing we really need from router manufacturers is
> >_persistent_ static routes by default. The current behaviour
> >of one rather popular brand of routers (name witheld to protect
> >the guilty) is to remove routes if the associated circuit goes
> >down. We need to change it to have packets to go to the bit
> >bucket instead, and make the old behaviour be configurable
> >with an explicit knob.
> Hm, I would think most would want that behaviour configured in the current
> way... because it makes network debugging so much easier. Based on many
> years of beating my head against various network reliability problems,
> I would say that it's better to have the route go away and let the user
> know about it than to throw data into the bit bucket.
> Maybe we could compromise on an option to leave the route there when the
> circuit goes down, for those network managers who want to receive calls
> from users saying "My data went into the bit bucket" and then spend some
> time to figure out that it's because the circuit went down.
> -- Walt
A good Internet service provider will also be looking at SNMP counters
and other indications of trouble on a regular basis using automated
tools and should be able to detect a problem independent of routing.
If your links are very noisy, routing will usually stay up anyway and
a very high percentage of packets may go in the bit bucket. Worse yet
is when routing can't decide whether to use the link or not and
changes its decision every few minutes. Too many shoddy providers are
not looking at link conditions and relying on routing to go down.
Multiply that by a few hundred flakey circuits around the world at any
given time and you have the current load on today's backbone routers.
Since the backbones can't fix the source of the problem, it becomes
nessecary to make the protocol machinery able to deal with the problem
somehow. That's were the route flap dampenning work comes in.