This exact problem has happened to me several times and it was NOT caused by the ARC deciding to become the DR. I have a small network of about 13 Lucent portmasters, 3 USR TC chassis, one Cisco 4500 and one Cisco 4700 router. ALL of the termservers are set with OSPF priority 0, meaning they will never become a DR or BDR. The Cisco 4500 and 4700 OSPF priorities were left as-is leaving one to become the DR and the other to become the BDR. If I rebooted or otherwise disturbed the DR the USR TC chassis would lose all their OSPF routing. The Lucent equipment did not have a problem at all. Getting the OSPF back on the USRs required a reboot of every chassis. For now I have set one of the Ciscos to priority 0 so that it will never become a BDR or DR. It seems as though the HARC cards have a problem recognizing a change of a BDR to a DR while the rest of my equipment does not. If this problem is indeed being caused by an ARC deciding to become a DR then it would seem to be a bug. In my case this should not be happening as all the HARCs are set to NOT participate in DR/BDR elections. Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams Sent: Monday, October 11, 1999 8:35 PM To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) arcs and ospf Thus spake Mike Andrews
I've been having a really bizarre problem off and on the last week or two. Occasionally some of my ARCs will suddenly stop doing OSPF right. The routing table loses all OSPF routes, and the ARC stops announcing its routes via OSPF to our Ciscos. Disabling/enabling OSPF doesn't help, but most of the time (not all the time) rebooting the ARC will.
One thing that seemed to trigger it was rebooting some of our Ciscos... and since that happens so infrequently (not rebooted since going to ARC 4.2 in fact) it's hard to track down. I don't know which one exactly, maybe our AS border router dying is what threw it off.
Hrmm...something to check...not sure if this will have any signficance...is the settings/values for the designated router on your ethernet(s) when this happens. I suspect your Cisco's were the designated routers initially, and when they went away, one of your Arc's got promoted to that...who knows what happened when your cisco's came back. When I was first playing with 4.2.29, I noticed a little bit of odd behavior with the Arc's wrt designated routers...but then when I set up a test lab environment for it, I couldn't reproduce it. What I saw was then I brought the Arc up on 4.2.29, it would take over the designated router functionality somehow...which would be against the OSPF spec, but possible for it to happen. I haven't played with OSPF on the arc's since then in any great depth...I've got one up and running on 4.2.32 at this point, but haven't really done anything with it. Maybe this will give you an idea of something to look at. Switching designated routers is definitely something you want to avoid if at all possible because its going to cause a resyncronization of LSA databases and a recalc of most (all?) of the shortest path first calculations...so...this *can* cause up to a couple of minutes of your routing being hosed as potentially every router on your network recalcs its OSPF routes. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - 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. - 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.