In message <[email protected]>
Acee Lindem writes:
> One assumption could be that a legacy router would not support
> auto-config and, if deployed, would have to be configured with a
> unique Router ID (as they are today).
Got that.
Don't use a non-configured router-id if you don't support this
ability to back off. (Routers today don't pick a random router-id
and they shouldn't unless they can backoff).
> Thanks,
> Acee
The key uncertainty is the effect of a collision on a legacy router.
This looks like it is covered. (indentation changed)
[RFC2328] 13.4. Receiving self-originated LSAs
It is a common occurrence for a router to receive self- originated
LSAs via the flooding procedure. A self-originated LSA is detected
when either 1) the LSA's Advertising Router is equal to the
router's own Router ID or 2) the LSA is a network- LSA and its
Link State ID is equal to one of the router's own IP interface
addresses.
However, if the received self-originated LSA is newer than the
last instance that the router actually originated, the router must
take special action. The reception of such an LSA indicates that
there are LSAs in the routing domain that were originated by the
router before the last time it was restarted. In most cases, the
router must then advance the LSA's LS sequence number one past the
received LS sequence number, and originate a new instance of the
LSA.
[...] In all these cases, instead of updating the LSA, the LSA
should be flushed from the routing domain by incrementing the
received LSA's LS age to MaxAge and reflooding (see Section 14.1).
[RFC5340] 4.5.1. Receiving Link State Update Packets
[...] In IPv4, eight steps are executed for each LSA, as
described in Section 13 of [OSPFV2]. For IPv6, all the steps are
the same, except that Steps 2 and 3 are modified as follows:
[stub or nssa or reserved scope changes]
It seems then that if the auto-config router picks a new router-id,
the legacy router will correct any damage. Perhaps the legacy router
will do this for the wrong reasons (collisions, not stale leftovers
from a restart elsewhere), but it seems like it will take action to
fix it.
Acee - should this move to OSPF? Others - No cross posting please.
Curtis
> On Oct 12, 2011, at 10:46 PM, Curtis Villamizar wrote:
>
> >
> > In message <[email protected]>
> > Russ White writes:
> >
> >>
> >>> Russ> You need a unique identifier at the equipment level for
> >>> Russ> anything you intend to auto-configure --autoconfiguring
> >>> Russ> uniqueness is a very hard, probably impossible, problem on a
> >>> Russ> global scale. So we need to count on this one thing, no matter
> >>> Russ> what else we might need to back in to.
> >>>
> >>> Russ> Now, it might be possible to some hash over a GPS location for
> >>> Russ> a "base," and then add on MAC addresses, or some such, but
> >>>
> >>> We've assumed a unique MAC, which is 48 bits long.
> >>> But OSPF router-id is 32 bits. What is the likelyhood of a collision
> >>> in the bottom 32-bits of the MAC?
> >>
> >> Ah, I see the problem... There is a pretty high likelihood of a
> >> collision, actually, at least as long as you use multiple vendors in
> >> your home network. It's bound to happen to someone, someplace.
> >>
> >> So, a suggestion to resolve this:
> >>
> >> 1. Use the lower 32 bits of one of the mac addresses on the box as the
> >> initial id.
> >>
> >> 2. Add a new field to the router capabilities that carries the full 48
> >> bit mac address, or even some munged together "longer id," based on
> >> multiple mac addresses on the device, or some such.
> >
> > Not backwards compatible. The older OSPF routers will see only the
> > non-unique 32 bits and the network won't work.
> >
> >> 3. During initial setup, if you receive a capability that appears to be
> >> from yourself, you open this secondary id section to find out if it's
> >> really you, or someone else who happens to have the same 32 bit id.
> >>
> >> 4. If it's really you, discard the packet.
> >>
> >> 5. If it's not really you, and if the other router's "large id" is lower
> >> than yours, choose another mac address from which to take your local id,
> >> and restart your ospf process.
> >>
> >> 6. If it's not really you, and the other router's "large id" is higher
> >> than yours, then send a router capabilities LSA unicast to this "other
> >> router," so the "other router" knows to change its id.
> >>
> >> I don't think IS-IS would have this problem.
> >>
> >> :-)
> >>
> >> Russ
> >
> > If the other router doesn't implement the extension you've described,
> > the network is hosed forever.
> >
> > If you have more than one link you should receive the LSA (or LSPDU)
> > that you advertised. If you have one link, you won't.
> >
> > If you receive a LSA (or LSPDU) that clearly you didn't advertise,
> > then you have a collision. *Both* routers should pick a new router-id
> > if this condition is detected and they implement this extension.
> >
> > Don't even bother using a MAC address for the router-id. Use a random
> > number. If a collision occurs, use a different random number. This
> > should also work for interfaces without a MAC (not that many homes run
> > POS today, but maybe some layer-2 in the future).
> >
> > Here is where it if fuzzy if one router is a legacy router. It may
> > not look at LSA (or LSPDU) apparently from itself or may just log a
> > problem and continue. When backing off, the bogus advertisements need
> > to be withdrawn. A possible backward compatibility wrinkle exists if
> > the legacy router does not readvertise (being legacy it will not pick
> > a new router-id). The problem could persist for maxage. Better than
> > forever but still not good.
> >
> > Don't use a non-configured router-id if you don't support this ability
> > to back off. (Routers today don't pick a random router-id and they
> > shouldn't unless they can backoff).
> >
> > Curtis
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
