Also Sprach Joshua Coombs
I currently administer a pool of 8 TC1000 chassis, and have been pulling hair out trying to stabilize OSPF. What we are seeing is some TC's refuse to ack some LSA reannouncements from the DR, causing it to eventually drop and restart OSPF sessions at random times. Every now and then this 'corrective' action taken by the DR will trip up a batch of TC's and 5 or 6 will all drop OSPF and reload their sessions. These hiccups are quite noticable to our dual channel ISDN customers (whom also seem to trigger the activity.)
You already got a response to confirm your MPIP setup...all correct...make sure you follow all the steps...once that's working correctly, you might consider a second MPIP server in case the one you have falls over you can continue to process cross-chassis MP calls. Anyway...suggestions on the OSPF side of things. Don't. My suggestion would be to switch the Arcs to use RIPv2...in my experience, the Arc OSPF capabilities has always been a bit flakey. Set the Arcs to RIPv2, and it will, obviously, also require RIPv2 on the Cisco as well. Then have the Cisco redistribute the RIPv2 routes into OSPF. Its what we're doing here, with 18 chassis/Arcs spread across 4 different cities and 6 different subnets. The 6 subnets with the Arcs talk RIPv2 to the directly attached Cisco router which redistributes each subnet's RIPv2 routes into OSPF (summarizing a little bit in the process, where possible). Works like a champ. Customers with static IP addresses can dial into any city, any Arc and their routing works and is propogated across our whole network before they even finish their PPP negotiation. Its rock solid, too. As a suggestion, on the Cisco(s), set the RIPv2 interfaces as passive-interface for RIPv2...this drastically cuts down on the CPU usage on the Ciscos, and, most likely, doesn't affect your reachability at all (I suspect your Arcs all have default routes pointing to your Ciscos anyway, so the traffic is going to go that way in any case). Oh...for the MPIP thing, I've got 2 MPIP servers for all of my Arcs, so...all 4 different cities and 6 subnets talk to one of the two MPIP servers (ie, two of the cities don't have an MPIP server locally at all). Works without hiccups. I did have an issue a month or two ago where a phantom MPIP bundle was in the MPIP servers' tables that didn't exist in reality. Unfortunately, there is no way for MPIP to resync with reality in this case. But in investigating the situation, I found out that the MPIP database had been in continuous existance and use for several *years*. (ie, one or the other of the MPIP servers would be rebooted, but not both at the same time at any point...when one would come back up after a reboot, it would resync with the other server's MPIP database state....so the database survived reboots of each of the MPIP servers since they never got rebooted at the same time...they resync their databases with each other after a reboot, but unfortunately, not with the reality of what bundles *actually* exist on the clients...a flaw in MPIP as far as I'm concerned...but after years of continuous operation, there was only one phantom bundle in my MPIP servers, so its not that serious of a problem really). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456