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

From: Nitin Kakkar <[email-masked]>
Date: Tue, 21 Feb 2006 12:35:20 +0530

HI Acee,
  Personal message just for FYI.
  Cisco support multiple ospf adjacencies on P2P.
  The reason being I vaguely remember some patents by "Alex Zini" which
uses a backup routerid to retrieve data from peer. 
Regards
Nitin

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Tuesday, February 21, 2006 4:56 AM
To: [email-masked]
Subject: Re: Detecting router id change in p2p-over-lan connection

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.

---

From: Nitin Kakkar <[email-masked]>
Date: Tue, 21 Feb 2006 16:55:37 +0530

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:[email-masked]] On Behalf Of
Naiming Shen
Sent: Tuesday, February 21, 2006 11:10 AM
To: [email-masked]
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,
>>>
>>>
>> P2P over LAN specific router-ID change processing should be removed  
>> from the draft.
>>
>> Thanks,
>> Acee
>>
>>> Thanks,
>>> Kalyan.
>>>
>>>
>>