RFC2328 is silent on what to do if you see a different router ID
on a P2P link; if you take it literally, you will create two
adjacencies (temporarily), advertise both in your router LSA,
and your network will most likely black hole traffic until one
of them times out.
On real P2P links, this will suffice (if you don't mind a
network outage for the dead time of the old adjacency) and
things will eventually stabilize since it is
"impossible" (cough) two get two neighbors in 2Way. The fact
that it is underspecified doesn't matter that much.
In the P2P-over-LAN case, there needs to be a mechanism to try to
do something useful if there turn out to be more than two
routers on the link. I don't think it's reasonable to say "gee
it's misconfigured, we don't care what happens to the network."
It seems to me that there are two possible cases, namely, use the
old adjacency until it times out (effectively ignoring the
hellos from the new guy) or to form an adjacency with the new
guy (and blow away or otherwise ignore the old guy.)
The first case has the advantage of stability and simplicity--
the third router that shows up for the party will be ignored by
both parties. There is a potential for a circle of one-way
adjacencies to stabilize, but this will still be stable (there
won't be a usable adjacency across the subnetwork.)
The second case has the advantage that it adapts more quickly
when something changes. Some implementations already do this
for the pure P2P case. However, it is destabilizing in the
misconfiguration case, as the router will flap its router LSA
each time another Hello is received. Probably the only
reasonable way out would be to detect the flap and then choose
one neighbor and stick to it, ignoring the other (which
degenerates into the first case.)
Given all of this, I'd propose that the right thing to do is the
first case, and suffer through the dead time (or use BFD and
suffer through the detection time.)
(A third possible case would be to actually bring up the
adjacency and end up running full-mesh multipoint, which would
probably even work, but would be butt ugly.)
--Dave
On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote:
Kalyan Bade wrote:
Acee,
This might not work if the interface is defined as demand
circuit.
Good point - We're in the process of discussing whether this
behavior
should be in the
draft. Possibly, handling detection of a router-id change on a
P2P
over
LAN link
differently than a normal P2P link may be a bad idea.
How about bringing down the neighbor (rather than ignoring)
when a third
neighbor on a P2P over LAN sends a new hello? This creates
unnecessary
flaps, but again having more than 2 routers on a p2p LAN is a
misconfig.
Atleast, the processing will be similar to a regular p2p
interface.
That would be fine and consistent with what most routers do on
normal P2P links. I think the
P2P over LAN specific router-ID change processing should be
removed from the draft.
Thanks,
Acee
Thanks,
Kalyan.