[c-nsp] understanding interface traffic counters of Cisco router and Cisco switch

Christopher J. Pilkington cjp at 0x1.net
Thu Nov 10 19:48:31 EST 2011 

Fa0/1 is an access port, not a 802.1q trunk, the traffic on that
interface is not tagged, so the monitor destination will "see"
untagged traffic.



On Nov 10, 2011, at 19:38, Martin T <m4rtntns at gmail.com> wrote:

> Sergey,
> I modified the setup a little:
>
> http://img64.imageshack.us/img64/5736/interfacestrafficcounte.png
>
> ..so now port Fa0/3 in the switch is in "monitoring" state and all the
> traffic from switch port Fa0/1 is copied to Fa0/3, which is connected
> to eth1 interface on "ubuntu" machine. Now if I start "tcpdump -nei
> eth1 -c10" in "ubuntu" machine in the middle of the iperf test, then
> results are:
>
> root at ubuntu:~# tcpdump -nei eth1 -c10
> tcpdump: WARNING: eth1: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 00:10:30.167558 10:40:10:40:10:40 > 00:06:d7:4d:c0:61, ethertype IPv4
> (0x0800), length 1512: 10.10.10.2.54064 > 10.10.11.2.5001: UDP, length
> 1470
> 00:10:30.167563 00:06:d7:4d:c0:61 > 10:40:10:40:10:40, ethertype IPv4
> (0x0800), length 1512: 10.10.11.2.46531 > 10.10.10.2.5001: UDP, length
> 1470
> 00:10:30.168556 10:40:10:40:10:40 > 00:06:d7:4d:c0:61, ethertype IPv4
> (0x0800), length 1512: 10.10.10.2.54064 > 10.10.11.2.5001: UDP, length
> 1470
> 00:10:30.168805 00:06:d7:4d:c0:61 > 10:40:10:40:10:40, ethertype IPv4
> (0x0800), length 1512: 10.10.11.2.46531 > 10.10.10.2.5001: UDP, length
> 1470
> 00:10:30.169805 10:40:10:40:10:40 > 00:06:d7:4d:c0:61, ethertype IPv4
> (0x0800), length 1512: 10.10.10.2.54064 > 10.10.11.2.5001: UDP, length
> 1470
> 00:10:30.170055 00:06:d7:4d:c0:61 > 10:40:10:40:10:40, ethertype IPv4
> (0x0800), length 1512: 10.10.11.2.46531 > 10.10.10.2.5001: UDP, length
> 1470
> 00:10:30.171054 10:40:10:40:10:40 > 00:06:d7:4d:c0:61, ethertype IPv4
> (0x0800), length 1512: 10.10.10.2.54064 > 10.10.11.2.5001: UDP, length
> 1470
> 00:10:30.171303 00:06:d7:4d:c0:61 > 10:40:10:40:10:40, ethertype IPv4
> (0x0800), length 1512: 10.10.11.2.46531 > 10.10.10.2.5001: UDP, length
> 1470
> 00:10:30.172304 10:40:10:40:10:40 > 00:06:d7:4d:c0:61, ethertype IPv4
> (0x0800), length 1512: 10.10.10.2.54064 > 10.10.11.2.5001: UDP, length
> 1470
> 00:10:30.172308 00:06:d7:4d:c0:61 > 10:40:10:40:10:40, ethertype IPv4
> (0x0800), length 1512: 10.10.11.2.46531 > 10.10.10.2.5001: UDP, length
> 1470
> 10 packets captured
> 10 packets received by filter
> 0 packets dropped by kernel
> root at ubuntu:~#
>
> In other words it looks like traffic isn't VLAN-tagged("ethertype"
> should be 0x8100 in this case). Or might this be some sort of
> switch-internal VLAN tag?
>
>
> regards,
> martin
>
> 2011/11/10 Sergey Nikitin <oldnick at oldnick.ru>:
>> Hi,
>>
>> Most likely this is because of 802.1Q tag (4 bytes) added to the counter on
>> a switch interface (and obviously you don't see this tag on a router
>> interface). For example, interfaces Fa3/0 and Fa0/24:
>> 773476480 - 771435576 = 2040904
>> 2040904 / 510226 = 4
>>
>> HTH
>>
>> Martin T wrote:
>>>
>>> I made a following setup:
>>>
>>> http://img828.imageshack.us/img828/5736/interfacestrafficcounte.png
>>>
>>> ..and executed "iperf -s -u -fm" in "ubuntu" machine and "iperf -c
>>> 10.10.11.2 -fm -u -d -b 10m -t600" in "PE860" machine. Before the test
>>> I cleared all interface counters. Iperf results were following:
>>>
>>> root at PE860:~# iperf -c 10.10.11.2 -fm -u -d -b 10m -t600
>>> ------------------------------------------------------------
>>> Server listening on UDP port 5001
>>> Receiving 1470 byte datagrams
>>> UDP buffer size: 0.12 MByte (default)
>>> ------------------------------------------------------------
>>> ------------------------------------------------------------
>>> Client connecting to 10.10.11.2, UDP port 5001
>>> Sending 1470 byte datagrams
>>> UDP buffer size: 0.12 MByte (default)
>>> ------------------------------------------------------------
>>> [  3] local 10.10.10.2 port 44911 connected with 10.10.11.2 port 5001
>>> [  4] local 10.10.10.2 port 5001 connected with 10.10.11.2 port 49469
>>> [ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total
>>> Datagrams
>>> [  4]  0.0-600.0 sec    715 MBytes  10.0 Mbits/sec  0.008 ms    0/510205
>>> (0%)
>>> [  4]  0.0-600.0 sec  1 datagrams received out-of-order
>>> [  3]  0.0-600.0 sec    715 MBytes  10.0 Mbits/sec
>>> [  3] Sent 510206 datagrams
>>> [  3] Server Report:
>>> [  3]  0.0-600.0 sec    715 MBytes  10.0 Mbits/sec  0.026 ms
>>> 2/510205 (0.00039%)
>>> [  3]  0.0-600.0 sec  1 datagrams received out-of-order
>>> root at PE860:~#
>>>
>>>
>>> For some reason, the interface counters in switch(Fa0/1, Fa0/2, Fa0/23
>>> and Fa0/24):
>>>
>>> Cisco2950#show interfaces Fa0/1 | i packets input|packets output
>>>     510227 packets input, 773472188 bytes, 0 no buffer
>>>     510236 packets output, 773484380 bytes, 0 underruns
>>> Cisco2950#show interfaces Fa0/2 | i packets input|packets output
>>>     510225 packets input, 773476416 bytes, 0 no buffer
>>>     510223 packets output, 773471932 bytes, 0 underruns
>>> Cisco2950#show interfaces Fa0/23 | i packets input|packets output
>>>     510230 packets input, 773476736 bytes, 0 no buffer
>>>     510233 packets output, 773479832 bytes, 0 underruns
>>> Cisco2950#show interfaces Fa0/24 | i packets input|packets output
>>>     510222 packets input, 773471868 bytes, 0 no buffer
>>>     510226 packets output, 773476480 bytes, 0 underruns
>>> Cisco2950#
>>>
>>> ..show little bit different results than router counters:
>>>
>>> C3640#show interfaces Fa2/0 | i packets input|packets output
>>>     510228 packets input, 771431340 bytes
>>>     510230 packets output, 771435816 bytes, 0 underruns
>>> C3640#show interfaces Fa3/0 | i packets input|packets output
>>>     510226 packets input, 771435576 bytes
>>>     510222 packets output, 771430980 bytes, 0 underruns
>>> C3640#
>>>
>>> I tried this test multiple times with different bandwidth(-b) values
>>> and always the difference between router counters and switch counters
>>> were ~0.3%. If the difference were 1.2% - 1.3% then it would make
>>> sense because probably in this case router counts only up to IP
>>> header, but switch includes L2 header as well, but what might cause
>>> this 0.3% difference?
>>>
>>>
>>> regards,
>>> martin
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list