Re: Detecting router id change in p2p-over-lan connection

[Dave Katz <dkatz at JUNIPER.NET>]

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.