router A is Version 11.0(16)
router B is Version 11.1(5)
starting saturday night, i noticed that snmp queries were failing to one
or both of the routers at various points.
i tried to log into the routers, but telnet was failing.
using the console access to one of the units, i found that memory was
exhausted.
after a reload, the memory would be exhausted again, and i noted that
"show mem" indicated numerous of "Packet header" or some such hanging
around in memory.
whatever was happening did not seem to effect the packet flow through the
router, as the connections and volumes were normal.
i figured either some kinda bug or exploit was being sent against the unit,
but nothing in my tcpdumps indicated abnormal traffic to any of the interface
addresses.
i was planning on upgrading the IOS today, but this morning, i found that
everything had returned to normal, with a normal amount of free memory, and
no real amount of extraneous junk in memory.
can anyone point me at what might have been the cause, and/or a solution so
that it doesn't happen again?
This is an old IOS bug affecting 2500s. Not sure of the range of IOS
images with the bug present. I had to work on a massive field recall
a couple years ago (engineering-issued, not Cisco-issued) to upgrade the
flash in these things so that we could slap a 12.x IOS on them.
There is a chance that you have a static for 0.0.0.0 0.0.0.0 to eth0 or
something like that even though the other end may be the only thing on the
ethernet. DON'T do that!
The router will arp for every address it needs to get to.
With codered around, that can be bad.
There is a chance that you have a static for 0.0.0.0 0.0.0.0 to eth0 or
something like that even though the other end may be the only thing on the
ethernet. DON'T do that!
The router will arp for every address it needs to get to.
With codered around, that can be bad.
Use a static default to a real ip address.
Use "no ip proxy-arp" (you should all be doing this anyway). With proxy ARP
disabled, a default route to an ethernet interface won't work unless
0.0.0.0/0 really is connected at layer 2.