They originally did, but for some reason the new secondary no longer seems to be bound to the MAC address of the blade. Can change to the 1st secondary and all is cool. Can ping the 2nd secondary from any number of other routers and networks to indicate the routing is fine on that side of things. It just seems to have disapperared as a 2nd gateway for a select group of modems on an exclusive network statically routed to a local college campus. ARP requests are there from the CPE side of the modem and sh arp | include 'laptop nic' from the uBR sees the MAC address of the CPE.
Can remove the 1st secondary just leaving the one in question and still no dice. Any tips for what to check next? BTW, these are static (fixed) CPE addresses not included anywhere in the modem config file. TIA for any direction here.
Poge
After much headscratching on this one, it was time to punt and reboot the router as a last resort. Fixed the problem -- or maybe more accurately just made a symptom go away temporarily? So the question now becomes, is there a widely recognized uBR7246 IOS version for the best stability vs. performance ratio that should be considered over the 12.2(15)BC2 that we're running now? We can't have secondary gateway addresses mysteriously disappearing from a MAC domain, now can we?
But back to the original question; how would that happen? Another device somehow hijacking or stepping on the address causing it to essentially 'shut down'? Seems to me that such a device would need to be another router with just a bit more influence over the network (or address space) than the uBR, though. Thing is, no ARP entry for the gateway address to be found anywhere during the problem.
Anyone else experienced this?
Poge
I did not experience the same problem as you, but when we had 12.2.x code running on 7246s we had all sorts of strange problems most of which required a reboot to fix. The 12.3.2x code is much better and much more stable. We use 12.3(21a)BC3 and have had almost no problems whatsoever.
be advised though upgrading from 12.2.x to 12.3.x the cmts is going to want to put all your cable interfaces in a bundle so don't freak out when ips are missing of your interfaces they are just assigned to Bundle 1 by default.
Thank you, sir.
On February 9th, 2010 kwesibrunee says:
> I did not experience the same problem as you, but when we had 12.2.x code running on 7246s we had all sorts of strange problems most of which required a reboot to fix. The 12.3.2x code is much better and much more stable. We use 12.3(21a)BC3 and have had almost no problems whatsoever.
Will ubr7200-k8su2-mz.123-23.BC7 play nice on a non-VXR 7246 with NPE225 and MC16C's?
Poge
Yes it does work
here is a snippet of show hardware on a production CMTS with those specs
show hardware
IOS (tm) 7200 Software (UBR7200-IK8SU2-M), Version 12.3(23)BC7, RELEASE SOFTWARE (fc1)
ROM: System Bootstrap, Version 12.0(19991120:010612) [nlaw-conn_4xe_ECC 112], DEVELOPMENT SOFTWARE
BOOTLDR: 7200 Software (UBR7200-BOOT-M), Version 12.0(15)SC, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
....
cisco uBR7246 (NPE225) processor (revision A) with 245760K/16384K bytes of memory.
I thought I would need a new bootloader too.
Poge