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). Thanks, Acee 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
