I know certain protocols hit SUP mod's CPU, however if VLAN traffic is configured on VLAN1 does this also hit the CPU and get "processed switched".I know certain protocols such as IGMP etc always hit CPU according to some tests we have done.
Lets start with the obvious are you sure the GBIC's are working correctly, if you are then remove UDLD, it could be a bug but i did a quick scan and came up empty BUG'd, also not sure what IOS version you are running.Dale
Unfortunately you can not partition these devices anymore, think this is due to the new ClassC DOS style Filesystem which is the default.Found this which backs up the point.http://www.cisco.com/en/US/partner/products/hw/routers/ps282/products_qanda_i...
Sounds like a H/W issue, are there any error msg's.?If you do a sh ver it will tell you why it reloaded.I have had similar isses with other devices which all it took was to remove and rebuild the config.
This is assuming you are shunting Mcast to different VLANS an trunks or uplinks are configured correctly.:)The reason why your source stops is that the *.G entry is being flooded by dense mode.I would say move to IGMP on the Cat5 but you have the 290...
This is not true by any means, when running SRM the NON-DR supervisor is in an active state but with all VLAN's etc in down state, there is no routing info, arp tables etc so its not a stateful failover feature and as such is not a "live" on the netw...
