08-28-2007 10:06 PM - edited 03-10-2019 03:46 AM
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
08-29-2007 04:45 AM
"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.
08-29-2007 05:37 AM
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.
08-29-2007 06:17 AM
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.
08-29-2007 07:45 AM
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.
08-29-2007 10:51 PM
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.
08-30-2007 06:23 AM
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.
08-30-2007 11:39 PM
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!
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: