cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
433
Views
5
Helpful
7
Replies

IPS 4215 in inline mode: unequal RX and TX counters - HOW?

ovt
Level 4
Level 4

Hi!

On the 4215 sensor the fa0/1 interface is paired with fa1/0.

The counters are:

- fa0/1 TX=117,RX=44413

- fa1/0 RX=1303,TX=43227

The traffic is very low. Almost all packets are STP packets. No packets were dropped. "sh statistics virtual-sensor" shows no signature fireings. And I cleared the statistics with the "show int clear" yesterday.

Why TX and RX counters are unequal? How this can happen?

Interface Statistics

Total Packets Received = 45715

Total Bytes Received = 3693043

Missed Packet Percentage = 0

Current Bypass Mode = Auto_off

MAC statistics from interface FastEthernet0/1

Interface function = Sensing interface

Description =

Media Type = TX

Missed Packet Percentage = 0

Inline Mode = Paired with interface FastEthernet1/0

Pair Status = Up

Link Status = Up

Link Speed = Auto_100

Link Duplex = Auto_Full

Total Packets Received = 44413

Total Bytes Received = 3247586

Total Multicast Packets Received = 0

Total Broadcast Packets Received = 0

Total Jumbo Packets Received = 0

Total Undersize Packets Received = 0

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 117

Total Bytes Transmitted = 9009

Total Multicast Packets Transmitted = 0

Total Broadcast Packets Transmitted = 0

Total Jumbo Packets Transmitted = 0

Total Undersize Packets Transmitted = 0

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

MAC statistics from interface FastEthernet1/0

Interface function = Sensing interface

Description =

Media Type = TX

Missed Packet Percentage = 0

Inline Mode = Paired with interface FastEthernet0/1

Pair Status = Up

Link Status = Up

Link Speed = Auto_100

Link Duplex = Auto_Full

Total Packets Received = 1303

Total Bytes Received = 445457

Total Multicast Packets Received = 0

Total Broadcast Packets Received = 0

Total Jumbo Packets Received = 0

Total Undersize Packets Received = 0

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 43227

Total Bytes Transmitted = 2811138

Total Multicast Packets Transmitted = 0

Total Broadcast Packets Transmitted = 0

Total Jumbo Packets Transmitted = 0

Total Undersize Packets Transmitted = 0

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

7 Replies 7

mhellman
Level 7
Level 7

"No packets were dropped. "sh statistics virtual-sensor" shows no signature fireings"

By default, the normalizer engine signatures will drop without firing an alarm. That is one possibility.

Even if the norm. engine drops the packet this will be shown in the "show stat virtual-sensor" output. This output clearly shows that no packets were dropped.

I'm on V6, promiscuous mode. There is a section in the output that shows the normalizer engine stats, but I couldn't tell you if they're accurate. There has been issues with the show stats command in the past.

You might try logging into the service account and looking at the interface stats in in /proc/net/cisco/ to see how they look. That should get you a little closer to the actual stats from an OS perspective.

scothrel
Level 3
Level 3

Those numbers *look* like an asymmetric route. I say that because it appears that nearly all of your traffic is received on fa0/1 and transmitted on fa1/0. I would expect *a lot* more reverse traffic, for the ACKs if nothing else.

I'd put a sniffer on the line (or use the sensor to sniff) and look at your packet mixes in each dir. Asymmetric and retransmitted packets (that have already been acked) are two things I can think of that might cause something like this.

No, this is not an asymmetric route. All of these packets are BPDUs which are obviously sent one way (from the root bridge down the STP). Actually there were no IP trafic on this link except some ARPs and broadcasts.

So, I'm still wondering why RX on the fa0/1 is NOT THE SAME as the TX number on the fa1/0 ??? The sensor is in the inline mode. Normalizer didn't drop anything. And the Linux seems to show the same numbers (under the service account). Of course, I will recheck this today and come back later with new numbers.

Anyway, Thx for the replay.

marcabal
Cisco Employee
Cisco Employee

The sensor will not pass CDP packets generated by the switch. So CDP packets will be received on one interface of the pair, but will not be transmitted on the second interface.

Hi!

Glad to hear you, Marcoa!

Yes, the "show cdp neighbors" doesn't show neighbors thru the sensor! Is this the only example when a sensor drops packets (I know about normalizer)?

BTW, I noticed that Sig 1308 - TTL evasion - is disabled in newer Sig updates. This opens up the possibility to evade the sensor. Are there any plans to redesign this signature, so that the signature will store the largest TTL value for every TCP session, rather than the smallest one? This will not break TCP sessions when a sensor sees packets twice and protect from evasion.

Thx. for the replay!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card