Quantcast
Channel: VMware Communities: Message List
Viewing all articles
Browse latest Browse all 144140

Re: vDS - Dropped Egress packets

$
0
0

If it really just drops the 0x8922 frames because it doesn't recognize this ethertype, then this can be safely ignored, even though it may look a bit eyebrow-raising.

 

I tested a bit with CentOS 6.3 VMs but I wasn't able to reproduce the dropped packet count increase you're seeing on your Ubuntu VMs.

Did you increase the MTU on the dvSwitch? The size of the MTU Health Check 0x8922 frames should correspond to the MTU you've set on the dvSwitch. I thought maybe your VM drops them because they are too large.

Does the dropped frame counter increase in a VM if if you're running tcpdump on it (running it should "accept" all frames)?

 

I also tried crafting custom layer 2 frames with scapy, using the same or other random ethertypes and larger frames sizes, but I never got the dropped packet counter to increase. I'm not sure when the kernel would decide to drop frames, except maybe for wrong checksums or such.

 

With the scapy packet crafting tool I tried stuff like this:

Source scapy VM:

# scapy

>>> a=Ether(dst="FF:FF:FF:FF:FF:FF", src="00:50:56:22:44:55", type=0x8922)

>>> a

<Ether  dst=FF:FF:FF:FF:FF:FF src=00:50:56:22:44:55 type=0x8922 |>

>>> sendp(a)

.

Sent 1 packets.


 

>>>payload="Some dummy data that is 1400 byte long ....[...]"

>>> a/payload

<Ether  dst=FF:FF:FF:FF:FF:FF src=00:50:56:82:35:15 type=0x8922 |<Raw  load='Some dummy data that is 1400 byte long ...........[...]

>>> sendp(a/payload)

.

Sent 1 packets.

 

 

 

Destination VM (with eth MTU set to 1300):

# tcpdump -i eth0 -nnvvve not ip and not arp

11:39:16.448518 00:50:56:22:44:55 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x8922), length 60:



11:43:39.923808 00:50:56:82:35:15 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x8922), length 1414:

    0x0000:  536f 6d65 2064 756d 6d79 2064 6174 6120  Some.dummy.data.

    0x0010:  7468 6174 2069 7320 3134 3030 2062 7974  that.is.1400.byt

    0x0020:  6520 6c6f 6e67 202e 2e2e 2e2e 2e2e 2e2e  e.long..........

 

 

Using unicast MAC of the destination or other exotic/non-existent ethertypes (http://standards.ieee.org/develop/regauth/ethertype/eth.txt) didn't make a difference, I never saw drops in the guest.

Check if you can reproduce the drops with scapy or some other packet crafting tool like this. But like I said above, it shouldn't be something to worry about if your Ubuntu is just dropping ethertypes it doesn't know.


Viewing all articles
Browse latest Browse all 144140

Trending Articles