WE have this 1700 router and past 2 weeks it has been showing bursty excessive cpu util >90% with "ip in put " process as culprit
There have been 2 observations
1)This router which is used for internet and a bandwidth of 128k almost always shows almost 95 % input rate on its serial interface..what is INPUT for serialint and what could be causing the same...the output on the same interface always is 30-40% lesser
2)When a debug ip packet was taken..we get SOURCE AS
x.y.z.c, WHICH IS THE SERIAL IP OF THE SAME ROUTER ..now this is confusing since source i would be expecting LAN ip...is something amiss here and the "SYN" flag tops it..
IP: s="x.y.z.c" (FastEthernet0), d=184.108.40.206 (Serial0), g=220.127.116.11, len 48, forward
TCP src=23890, dst=135, seq=493328847, ack=0, win=65535 SYN
We had expected the same and have patched,cleaned all the vulnerable systems some time beforeand yet no change , i had presumed that "sh ip nat translations icmp" would expose the worm in my network since its notorious for sending outgoing random pings
What has me worried is that the
"Ip debug packet detail" shows up with source x.y.z.c(fast ethernet0) x.y.z.c being the PUBLIC ip and IP OF THE SERAIL INTERFACE when i was expecting a LAN ip as source..any explaination for the anamoly
High input rate in my serial is another thing that has me stumped
i have replaced the ip with x.y.z.c
1: IP: s=x.y.z.c (FastEthernet0), d=18.104.22.168 (Serial0), g=22.214.171.124, len 40, forward
You should verify that you do not have the following vunerability. Cisco Security Advisory:Cisco IOS Interface Blocked by IPv4 Packets. The url is listed below which explains in detail how the vunerablity affects your routers.
I'm not sure, but it seems a logical explanation to me, that NAT occurs before DEBUG, so the debug output shows the translated addresss.
Regarding the RX load, could be the combination of normal traffic and incoming traffic that is a result of the scan (SYN ACK replies, ICMP unreachable replies). Doesn't your debug ip packet show the inbound packets? Could they be dropped by an ACL?
If my assumption about the debug showing the NAT address is correct, then yes the scan originates on your lan and you should check show ip nat translations to see which is the original originating ip address.
Well i would presume debug captures LAN IP on F0 as
NAT happens after routing on a inside to outside packet and debug should tell me exactly that..with source as private ip and on ethernet interface..now im not so sure...can someone throw some light here
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...