Hi Dave,
Dave Katz wrote:
On Feb 21, 2006, at 6:04 AM, Acee Lindem wrote:
Naiming Shen wrote:
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?
Hi Naiming,
Given that this situation can happen in the case of misconfiguration or
router-ID change, I wouldn't optimize for the former. Especially
considering Kalyan's point that if hello's are suppressed, the router-id change
will either not be recognized or require additional logic. I'd vote to either
leave it unspecified (consistent with RFC 2328's omission of router-id
change P2P link handling) or discard the old neighbor and bring up
an adjacency with the new (which is what at least one implementation does
today).
My libertarian streak says to leave anything unspecified that does not impact interoperability (a philosophy absent from the OSPF spec, which has normative text for all kinds of unnecessary things.) Indeed, the handling of this case is not an interoperability issue.
Given the failure modes caused by misconfiguration, however, I would campaign for having a SHOULD on detecting the misconfiguration, which will otherwise look like mysterious adjacency flapping, or the inability for adjacencies to come up, or something. It should be pretty trivial to detect the fact that you're actively receiving Hellos from multiple systems on what is supposedly a point-to-point medium.
Thanks, Acee
--Dave
Thanks, Acee
Thanks, Acee
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:
That would be fine and consistent with what most routers do on normal P2P links. I think theAcee,
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.
P2P over LAN specific router-ID change processing should be removed from the draft.
Thanks, Acee
Thanks, Kalyan.