On Tue, 16 Nov 1999, Brian wrote:
If I remember right it doesn't work like that. When you have a DR and a BDR, and you reboot the DR, yes the BDR becomes the DR. But then when the "old" DR comes back up it does not become BDR. You have to reboot your other box (the original BDR , now DR) for this too happen. In other words, the cluenote I remember is "2 reboots are necessary for a re-election of OSPF DR/BDR".
Turns out that it really doesn't matter who the DR/BDR is, or what the RFC says about LSAs or floods :) The real problem is that the ARC is letting less specific routes override more specific routes, and thus confusing itself about its own netmask. That's apparently why communication fails with the new DR:
fra-ts2> list ip route
IP ROUTES Destination Prot NextHop Metric Interface 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 127.0.0.1/H LOCAL 127.0.0.1 1 loopback 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 206.240.130.14/H LOCAL 206.240.130.14 1 eth:1
This points out a problem I've brought up before. The subnet mask on this LAN should be /25, not /23. There is a /23 route being advertised by the Cisco that points at fra1's Null0 though (for BGP4 purposes) and this is somehow getting confused with the local netmask set on the eth:1 interface, which is set correctly:
Ok, fra1 is that your border? Are you injecting static routes into the IGP at all? I use tiedowns for my BGP routes as well.........you want to set these with a HIGH administrative weight, of like 250 though, so they don't get used. Do you have a weight set on them?
Yeah, fra1 is the border (3620). The null0 tiedown routes have a "250" distance metric on the end (used to be 10 til last night), and those routes are getting injected into OSPF. The ARC still uses them whether the metric is 10 or 250... it seems to ignore the metric. The only way I was able to make things sane was to stop the tiedowns from getting injected into OSPF at all. I haven't yet figured out how to stop just those routes from getting injected without shutting down redistribution of ALL static routes. (Fortunately there aren't many other static routes, so for now, this is what I've done.) I had tried various combinations of distribute-list on the Cisco, as well as receivepolicy on the ARC, and didn't have much luck. I'm sure there's a better way to do it though. :) The screwed up netmask caused by this is *definitely* what's making it stick in ExStart. I did find a workaround that did NOT require rebooting, finally: reconfig ip network ip addr 206.240.130.14/25 (to fix the mask) disable ospf enable ospf and voila, things start working again. Of course the netmask goes back to the wrong thing immediately after this, if you haven't stopped the tiedowns from getting injected into OSPF...
Also, using null0 as a tiedown used to be slow switched, so people used loopbacks, but I think now in later ios's this is not the case, and both can be used, but if you are running an older version you may want to consider that.
It's 11.3(11a)T1... about 2 months old. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.