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

[Nitin Kakkar <Nitin.Kakkar at CITRIX.COM>]

In the event of router id change, Wouldn't this delay new adjacency by
at least dead interval?
To prevent that may be we can explicitly mention that whenever router-id
is administratively removed, ospf should explicitly teardown adjacency
Nitin

-----Original Message-----
From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of
Naiming Shen
Sent: Tuesday, February 21, 2006 11:10 AM
To: OSPF at PEACH.EASE.LSOFT.COM
Subject: Re: Detecting router id change in p2p-over-lan connection

Agree with Dave's argument, and this is the same idea as in the
current draft of p2p-over-lan (section 4.5):

                                      ... If the system ID or the
    router ID of incoming hello packet does not match the system ID or
    the router ID of already established adjacency over this
p2p-over-lan
    circuit, it MUST discard the packet. The implementation should offer
    logging and debugging information of the above events.

Do we need to change anything here?

thanks.
- Naiming

Dave Katz said the following on 02/20/2006 08:53 PM:
> 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.
>>>
>>>
>>