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
