Traffic accounted in interface that has no ip and is not in promisc mode

Traffic accounted in interface that has no ip and is not in promisc mode

[Dennis Jacobfeuerborn]

Hi,
I'm seeing a strange phenomenon on some systems: The packet and byte
counters get increased from traffic that doesn't target the interface.

On one system the interfaces does not even have an IP and is not in
promiscuous mode yet looking at the interface stats the packet and byte
counters show traffic of 40 mbit:

# ip a show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 52:54:00:2f:be:59 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fe2f:be59/64 scope link
       valid_lft forever preferred_lft forever

# ip -s l show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 52:54:00:2f:be:59 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    3185025880 2136432122 0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    1120135715 18322641 0       0       0       0

So in order to verify that no traffic is flowing on the interface
segment with this interface as its target I did:

tcpdump -e -nn -i eth0 ether host 52:54:00:2f:be:59

This shows not a single packet while at the same time I still see the
packet and byte counters going up.
Then I did this:

tcpdump -e -p -nn -i eth0

This actually shows traffic but not destined for this interface. I don't
understand why it would do so because I used -p to not put the interface
in promisc mode.

This is happening in a virtual-machine using the virtio-net driver for
the network interfaces.

Does anyone have an idea why the interface accounts this traffic?

Regards,
  Dennis

RE: Traffic accounted in interface that has no ip and is not in promisc mode

[Joel Gerber]

Have you verified that the incoming traffic you're seeing isn't destined to a broadcast MAC address, or a multicast MAC address related to an IGMP stream that your system has joined?

When an interface is not in promiscuous mode, it still will get frames not destined to its MAC address if the destination MAC address is either a broadcast address, or a multicast address that the system has joined. Depending on your configuration, you might even see multicast traffic that you haven't specifically joined.

Joel Gerber
Network Specialist
Network Operations
Eastlink
E: Joel.Gerber@corp.eastlink.ca T: 519.786.1241


-----Original Message-----
From: lartc-owner@vger.kernel.org [mailto:lartc-owner@vger.kernel.org] On Behalf Of Dennis Jacobfeuerborn
Sent: November-06-14 11:44 AM
To: lartc@vger.kernel.org
Subject: Traffic accounted in interface that has no ip and is not in promisc mode

Hi,
I'm seeing a strange phenomenon on some systems: The packet and byte counters get increased from traffic that doesn't target the interface.

On one system the interfaces does not even have an IP and is not in promiscuous mode yet looking at the interface stats the packet and byte counters show traffic of 40 mbit:

# ip a show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:2f:be:59 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fe2f:be59/64 scope link
       valid_lft forever preferred_lft forever

# ip -s l show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:2f:be:59 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    3185025880 2136432122 0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    1120135715 18322641 0       0       0       0

So in order to verify that no traffic is flowing on the interface segment with this interface as its target I did:

tcpdump -e -nn -i eth0 ether host 52:54:00:2f:be:59

This shows not a single packet while at the same time I still see the packet and byte counters going up.
Then I did this:

tcpdump -e -p -nn -i eth0

This actually shows traffic but not destined for this interface. I don't understand why it would do so because I used -p to not put the interface in promisc mode.

This is happening in a virtual-machine using the virtio-net driver for the network interfaces.

Does anyone have an idea why the interface accounts this traffic?

Regards,
  Dennis
--
To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Traffic accounted in interface that has no ip and is not in promisc mode

[Dennis Jacobfeuerborn]

The only broadcast traffic I see is a couple of arp packets per seconds
and there is no multicast traffic.

Since this is a virtual machine that is plugged into a bridge on the
host side I'm wondering if that might have something to do with it but
according to my understanding even if packets were forwarded from the
host side that are not targeted at the vm then the vm would drop these
packets and not account them under received packets/bytes for that
interface.

Regards,
  Dennis

On 06.11.2014 18:15, Joel Gerber wrote:
> Have you verified that the incoming traffic you're seeing isn't destined to a broadcast MAC address, or a multicast MAC address related to an IGMP stream that your system has joined?
> 
> When an interface is not in promiscuous mode, it still will get frames not destined to its MAC address if the destination MAC address is either a broadcast address, or a multicast address that the system has joined. Depending on your configuration, you might even see multicast traffic that you haven't specifically joined.
> 
> Joel Gerber
> Network Specialist
> Network Operations
> Eastlink
> E: Joel.Gerber@corp.eastlink.ca T: 519.786.1241
> 
> 
> -----Original Message-----
> From: lartc-owner@vger.kernel.org [mailto:lartc-owner@vger.kernel.org] On Behalf Of Dennis Jacobfeuerborn
> Sent: November-06-14 11:44 AM
> To: lartc@vger.kernel.org
> Subject: Traffic accounted in interface that has no ip and is not in promisc mode
> 
> Hi,
> I'm seeing a strange phenomenon on some systems: The packet and byte counters get increased from traffic that doesn't target the interface.
> 
> On one system the interfaces does not even have an IP and is not in promiscuous mode yet looking at the interface stats the packet and byte counters show traffic of 40 mbit:
> 
> # ip a show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>     link/ether 52:54:00:2f:be:59 brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::5054:ff:fe2f:be59/64 scope link
>        valid_lft forever preferred_lft forever
> 
> # ip -s l show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>     link/ether 52:54:00:2f:be:59 brd ff:ff:ff:ff:ff:ff
>     RX: bytes  packets  errors  dropped overrun mcast
>     3185025880 2136432122 0       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     1120135715 18322641 0       0       0       0
> 
> So in order to verify that no traffic is flowing on the interface segment with this interface as its target I did:
> 
> tcpdump -e -nn -i eth0 ether host 52:54:00:2f:be:59
> 
> This shows not a single packet while at the same time I still see the packet and byte counters going up.
> Then I did this:
> 
> tcpdump -e -p -nn -i eth0
> 
> This actually shows traffic but not destined for this interface. I don't understand why it would do so because I used -p to not put the interface in promisc mode.
> 
> This is happening in a virtual-machine using the virtio-net driver for the network interfaces.
> 
> Does anyone have an idea why the interface accounts this traffic?
> 
> Regards,
>   Dennis
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Traffic accounted in interface that has no ip and is not in promisc mode

[Rick Jones]

On 11/06/2014 03:00 PM, Dennis Jacobfeuerborn wrote:
> The only broadcast traffic I see is a couple of arp packets per seconds
> and there is no multicast traffic.
>
> Since this is a virtual machine that is plugged into a bridge on the
> host side I'm wondering if that might have something to do with it but
> according to my understanding even if packets were forwarded from the
> host side that are not targeted at the vm then the vm would drop these
> packets and not account them under received packets/bytes for that
> interface.

Perhaps the bridge has yet to learn the MACs involved and so is 
flooding.  Whether then the "NIC" driver would/should count/not count 
such traffic as having been received is probably a matter of 
interpretation.  If you take the point of view that any packet which 
came into the host should "count" then the current behaviour would seem 
to make sense.

It is also interesting that this non-configured interface has 
transmitted a large (though smaller than RX count) number of packets.  I 
would have expected your (first) tcpdump to have shows the ether host 
transmitting (very) roughly one packet for every 100 received.

rick jones

Re: Traffic accounted in interface that has no ip and is not in promisc mode

[Dennis Jacobfeuerborn]

On 07.11.2014 00:11, Rick Jones wrote:
> On 11/06/2014 03:00 PM, Dennis Jacobfeuerborn wrote:
>> The only broadcast traffic I see is a couple of arp packets per seconds
>> and there is no multicast traffic.
>>
>> Since this is a virtual machine that is plugged into a bridge on the
>> host side I'm wondering if that might have something to do with it but
>> according to my understanding even if packets were forwarded from the
>> host side that are not targeted at the vm then the vm would drop these
>> packets and not account them under received packets/bytes for that
>> interface.
> 
> Perhaps the bridge has yet to learn the MACs involved and so is
> flooding.  Whether then the "NIC" driver would/should count/not count
> such traffic as having been received is probably a matter of
> interpretation.  If you take the point of view that any packet which
> came into the host should "count" then the current behaviour would seem
> to make sense.

This is one of the packets that I can see on the interface and that is
responsible for that traffic:
00:20:01.957553 00:25:90:0d:9e:43 > 52:54:00:2d:83:3f, ethertype IPv4
(0x0800), length 66: <src ip>.41638 > <dst ip>.80: Flags [.], ack 563,
win 123, options [nop,nop,TS val 36272290 ecr 116198943], length 0

Looking at the MAC table of the bridge on the host I can see an entry
for 00:25:90:0d:9e:43 as non-local but no entry for 52:54:00:2d:83:3f.
Am I correct in believing that the bridge only learns source MACs but
ignores the destination MAC? If so then my suspicion is that I'm dealing
with an asymetric routing situation where the bridge only sees the
incoming traffic but since the response to this packet actually comes
from a different machine it never gets to learn the 52:54:00:2d:83:3f
address and thus will keep flooding all packets with that destination
MAC indefinitely.

> It is also interesting that this non-configured interface has
> transmitted a large (though smaller than RX count) number of packets.  I
> would have expected your (first) tcpdump to have shows the ether host
> transmitting (very) roughly one packet for every 100 received.

The interface was in operation previously which is probably the reason
for that number. The important information that I should probably have
mentioned more explicitly is that the rx counters increase rapidly while
the tx counters don't move at all.

Regards,
  Dennis

Re: Traffic accounted in interface that has no ip and is not in promisc mode

[Rick Jones]

>> Perhaps the bridge has yet to learn the MACs involved and so is
>> flooding.  Whether then the "NIC" driver would/should count/not count
>> such traffic as having been received is probably a matter of
>> interpretation.  If you take the point of view that any packet which
>> came into the host should "count" then the current behaviour would seem
>> to make sense.
>
> This is one of the packets that I can see on the interface and that is
> responsible for that traffic:
> 00:20:01.957553 00:25:90:0d:9e:43 > 52:54:00:2d:83:3f, ethertype IPv4
> (0x0800), length 66: <src ip>.41638 > <dst ip>.80: Flags [.], ack 563,
> win 123, options [nop,nop,TS val 36272290 ecr 116198943], length 0
>
> Looking at the MAC table of the bridge on the host I can see an entry
> for 00:25:90:0d:9e:43 as non-local but no entry for 52:54:00:2d:83:3f.
> Am I correct in believing that the bridge only learns source MACs but
> ignores the destination MAC? If so then my suspicion is that I'm dealing
> with an asymetric routing situation where the bridge only sees the
> incoming traffic but since the response to this packet actually comes
> from a different machine it never gets to learn the 52:54:00:2d:83:3f
> address and thus will keep flooding all packets with that destination
> MAC indefinitely.

That has always been my understanding of how bridges/switches work. 
Until they see a given MAC address as a source MAC, any traffic destined 
for that MAC address will be flooded out all ports (well, save for the 
one it came-in on of course).

You could, I suppose, ping/arp for the IP associated with the 
52:54:00:2d:83:3f and if they hypothesis is correct, once you do that, 
you should no longer see the traffic arriving.

rick jones

Re: Traffic accounted in interface that has no ip and is not in promisc mode

[Dennis Jacobfeuerborn]

On 07.11.2014 01:07, Rick Jones wrote:
>>> Perhaps the bridge has yet to learn the MACs involved and so is
>>> flooding.  Whether then the "NIC" driver would/should count/not count
>>> such traffic as having been received is probably a matter of
>>> interpretation.  If you take the point of view that any packet which
>>> came into the host should "count" then the current behaviour would seem
>>> to make sense.
>>
>> This is one of the packets that I can see on the interface and that is
>> responsible for that traffic:
>> 00:20:01.957553 00:25:90:0d:9e:43 > 52:54:00:2d:83:3f, ethertype IPv4
>> (0x0800), length 66: <src ip>.41638 > <dst ip>.80: Flags [.], ack 563,
>> win 123, options [nop,nop,TS val 36272290 ecr 116198943], length 0
>>
>> Looking at the MAC table of the bridge on the host I can see an entry
>> for 00:25:90:0d:9e:43 as non-local but no entry for 52:54:00:2d:83:3f.
>> Am I correct in believing that the bridge only learns source MACs but
>> ignores the destination MAC? If so then my suspicion is that I'm dealing
>> with an asymetric routing situation where the bridge only sees the
>> incoming traffic but since the response to this packet actually comes
>> from a different machine it never gets to learn the 52:54:00:2d:83:3f
>> address and thus will keep flooding all packets with that destination
>> MAC indefinitely.
> 
> That has always been my understanding of how bridges/switches work.
> Until they see a given MAC address as a source MAC, any traffic destined
> for that MAC address will be flooded out all ports (well, save for the
> one it came-in on of course).
> 
> You could, I suppose, ping/arp for the IP associated with the
> 52:54:00:2d:83:3f and if they hypothesis is correct, once you do that,
> you should no longer see the traffic arriving.

I now implemented a script that sends a gratuitous arp every minute from
that interface and with it running the bridge now picks up the MAC and
the traffic disappeared. Thanks for pointing me in the right direction
with those bridge remarks!

Regards,
  Dennis