[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Detecting router id change in p2p-over-lan connection
Group,
There are two thing going on here.. here is
my full blown dictionary interpretation of
what is done and justify the empty hello for
hello suppression change and/or router-id
changes.
1) hello suppression and revoke of hello suppression
-------
If only a hello suppression is revoked, I can almost
scizophrenicly see that one could send a hello with
a nbr listed.
In theory. Actively revoking can be done with a hello
listing or not listing the nbr.
HOWEVER, The RFC specifies that upon a link change
state that hello suppression can be done.
RFC 1793 section 3.2.1
"The router will then
automatically attempt to renegotiate Hello suppression whenever
the link goes down and comes back up."
This is bi-directional to me..
This "implicitly" disaproves of checking the hello bit
after the nbr has formed the adj. I didn't write this. :)
So in theory a flag gets set when the nbr is seen and
we compare whether we both want to suppress hellos. After
we complete the adj formation, we check the flag and if
se, we suppress hellos. Realize that we were also sending
DNA LSAs out at initial DBD exhange time based on this
flag setting.
Thus, we need to reset the nbr state if we want to
later re-enable suppression and re-originate LSAs
with/without the DNA bit set.
In addition, if we supress the D/C behaviour, I read
that the DNA bit should no longer be set. To reset
this bit, one needs to re-originate the LSAs. The
only simple way is via a new adj and yes with a empty
hello.
2) router-id change...
However, if one also changes a router-id, sorry, I
can not see how the adj can be re-uesed for the
LSAs.
With the empty nbr hello...
The protocol states that we ONLY send a nbr listed within
the hello if we have seen a hello within our dead-router
time. With the suppression of hellos we surely haven't
met that criteria....
each originated LSA is tagged with the router-id and
a new router-id requires new LSAs...................
Yes, I am ALSO assuming for consistency that if a router-id
changed then the SAME BEHAVIOUR without regard to interface
type SHOULD be followed. Without a P2P interface (say a
BMA interface type or a P2MP, changing the router-id
leads to uncertaincy. Even with P2P, we may not
have communicated with this nbr for up to 1 hr.
If the D/C nbr has not quietly gone away:
* the empty hello re-inits (nbt = init state) an exiting
adj,
* ALL LSAs are tagged with the router-id, unless
one goes out and searches for existing LSAs with
the old router-id, then the LSAs need to be reflooded,
* The adj went to the init state, (we are
re-initializing at least the hello),
* we should get a response within the hello interval,
* changing one's own router-id SHOULD be an infrequent
router change...
* the LSAs should be fairly consistent and achieving full
adj should be a minimal task,
* this is a guranteed way to recieve a hello if the
nbr is just suppressing hellos,
Thus, is the justification for empty hellos to reset nbr
state if hello suppression and/or router-id is changed.
Mitchell Erblich
-----------------
Acee Lindem wrote:
>
> Nitin Kakkar wrote:
>
> >Can someone please explain me the rational behind terminating adjacency
> >in " if OSPF hello suppression as described in [DEMAND] is active for
> >the
> >adjacency, it MUST be terminated and renegotiated"
> >
> >Why do we want a stray hello to terminate existing adjacency?
> >
> >
> Perhaps "it" should be replaced with "hello suppression" or perhaps you
> were lead astray by
> prevoius poss. Terminating "hello suppresssion" doesn't bring down the
> adjacency, it merely
> implies that the dead interval is enforced and hello are sent. The
> reason for this is to handle
> router-id changes. Without this clause, the old adjacency would persist
> indefinitely.
>
> Thanks,
> Acee
>
> >Thanks & Regards
> >Nitin
> >-----Original Message-----
> >From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of Sunil
> >Patro
> >Sent: Thursday, February 23, 2006 3:24 AM
> >To: OSPF at PEACH.EASE.LSOFT.COM
> >Subject: Re: Detecting router id change in p2p-over-lan connection
> >
> >Hi Everyone,
> >
> >Thanks for all the feedback.
> >
> >Can I safely assume that the final behavior is what Acee's recommended
> >paragraph says below?
> >
> >"If the system ID or the router ID in an incoming hello packet
> >doesn't match the the system ID or router ID for an established
> >adjacency
> >over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore,
> >if OSPF hello suppression as described in [DEMAND] is active for the
> >adjacency, it MUST be terminated and renegotiated."
> >
> >Thanks,
> >Sunil
> >
> >
> >
> >>-----Original Message-----
> >>From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of
> >>
> >>
> >Naiming
> >
> >
> >>Shen
> >>Sent: Tuesday, February 21, 2006 9:43 PM
> >>To: OSPF at PEACH.EASE.LSOFT.COM
> >>Subject: Re: Detecting router id change in p2p-over-lan connection
> >>
> >>Hello Acee,
> >>
> >>Your suggested paragraph looks fine with me.
> >>
> >>Even though this sentence assumes there is really a
> >>router-id change from a DC neighbor. A router probably
> >>should send a 'neighbor probing' [RFC 3883], if no
> >>response, then reset the adjacency and start
> >>the renegotiation; otherwise it should still ignore
> >>the new join on the p2p-over-lan link.
> >>
> >>But I would consider router-id change over a demand
> >>circuit over a p2p-over-lan on OSPF link a
> >>'misconfiguration';-) so it does not matter too much.
> >>Your version is fine.
> >>
> >>thanks.
> >>- Naiming
> >>
> >>Acee Lindem said the following on 02/21/2006 02:47 PM:
> >>
> >>
> >>>Hello Naiming,
> >>>
> >>>Naiming Shen wrote:
> >>>
> >>>
> >>>
> >>>>Acee Lindem said the following on 02/21/2006 06:04 AM:
> >>>>
> >>>>
> >>>>
> >>>>>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).
> >>>>>
> >>>>>
> >>>>
> >>>>Hello Acee,
> >>>>
> >>>>The original idea in the draft was to prevent multiple routers
> >>>>
> >>>>
> >joinning
> >
> >
> >>>>onto the same LAN rather than handing the router-ID change from the
> >>>>same router. Even through there is a side effect to it.
> >>>>
> >>>>For the router-ID change issue. If one is willing to change
> >>>>
> >>>>
> >router-ID
> >
> >
> >>>>or system-ID during normal operation, there are more things broken
> >>>>and there is nothing wrong to wait until the current adjacent
> >>>>
> >>>>
> >timeout.
> >
> >
> >>>Agreed.
> >>>
> >>>
> >>>
> >>>>If the hello is suppressed over the link, then the behaviour is not
> >>>>bounded by this paragraph since it does not say the purpose is to
> >>>>detect neighbor router-id change.
> >>>>
> >>>>
> >>>I disagree here. It says "MUST discard packet". That sounds pretty
> >>>bounding to me :^).
> >>>
> >>>
> >>>
> >>>>Also there is little reason to
> >>>>suppress a hello over p2p-over-lan links. Thus I don't think
> >>>>router-id is an issue with this sentence.
> >>>>
> >>>>
> >>>I agree - but there is nothing in this draft or RFC 1793 that
> >>>
> >>>
> >precludes
> >
> >
> >>it.
> >>
> >>
> >>>>Since p2p-over-lan is different from normal p2p circuit that
> >>>>
> >>>>
> >multiple
> >
> >
> >>>>routers can easily join the same LAN unintentionally. If we ignore
> >>>>the new station to join, then we can prevent the adjacency constant
> >>>>flapping(this does not happen to normal p2p link), the worst it can
> >>>>happen is slow to handle router-id change as mentioned above, which
> >>>>is a non issue. Thus I think it's a good thing to ignore the extra
> >>>>adjacency joinning. This sentence does not govern the normal p2p
> >>>>
> >>>>
> >link
> >
> >
> >>>>behaviour so the implementation is ok(even prefered) to reset the
> >>>>existing adjacency on a normal p2p link. Thus I don't think we
> >>>>should say we must reset the current adjacency for p2p-over-lan.
> >>>>
> >>>>My preference of this sentence in the draft is with this order:
> >>>>
> >>>> - leave it as is
> >>>> - change the MUST to SHOULD
> >>>> - remove the router-id related sentence
> >>>>
> >>>>
> >>>How about leave it "almost" as is:
> >>>
> >>> If the system ID or the router ID in an incoming hello packet
> >>>
> >>>
> >>doesn't
> >>
> >>
> >>> match the the system ID or router ID for an established
> >>>
> >>>
> >adjacency
> >
> >
> >>over
> >>
> >>
> >>> a p2p-over-lan circuit, the packet MUST be discarded.
> >>>
> >>>
> >Futhermore,
> >
> >
> >>> if OSPF hello suppression as described in [DEMAND] is active for
> >>>
> >>>
> >the
> >
> >
> >>> adjacency, it MUST be terminated and renegotiated.
> >>>
> >>>[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits",
> >>> RFC 1793, April 1995.
> >>>
> >>>Thanks,
> >>>Acee
> >>>
> >>>
> >>>
> >>>>thanks.
> >>>>- Naiming
> >>>>
> >>>>
> >>>>
> >>>>>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:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >
> >
> >