mailing list archives
Routing vs Switching (was Re: Another UUNET Explanation)
From: smd () clock org (Sean M. Doran)
Date: 02 Jul 1997 02:09:57 -0400
"Chris A. Icide" <chris () nap net> writes:
smd> A clumsy tech or a backhoe takes out a physical path
smd> between two POPs, each of which contains several routers
smd> that form part of this flat network.
smd> What happens now?
Layer 2 heals itself, without the knowledge of layer 3. Layer 3
experiences a latency increase between certain paths.
Sorry, had to do it.
Well, this is certainly the obvious approach, and is
certainly in line with the generally reasonable philosophy
of "degraded performance rather than no performance"
response to partitions, assuming the routers don't
notice a topology change.
There are some interesting issues with respect to
convergence at the L2 layer (rerouting VCs takes time
too), and I've seen problems where the fast-packet layer
converged slowly enough that IS-IS adjacencies were lost,
causing really neat routing slosh as the VC went and came
(To augment one of my own questions, when you have two
routers in a full mesh (FR, ATM, whatever using VCs) and
the VC between N-1 and N-2 goes out of service, how do N-1
and N-2 decide what path(s) to use to talk to each other?
Feel free to consider a network using any commonly
available IGP and the iBGP hack.)
I also have some anecdotes about VCs improperly travelling
along the same path for long periods of time because of
configuration errors or unnoticed physical
disconnectivities between switches. There have also been
neat tales of VCs going simplex from time to time.
Monitoring two networks simultaneously, fun fun fun... :)
I'm sure there are people here with practical experiences
who might be willing to share what they've learned.
however, in this fast paced industry, will we
ever have the "perfect" protocol (okay, ever is a big
IPv6 over ATM/LANE with RSVP will someday change the world.
Sean Doran <smd () ab use net>
"Boy, you obviously don't have a clue!" -- Chad Skidmore, Data Source L.L.C.
- Re: Another UUNET Explanation, (continued)