Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

neutron bridging and ethernet padding issue

I have a Mitaka lab setup. One of the nodes in this setup is Neutron running on Ubuntu 14.04LTS on a VMware ESXi guest. It has two network interfaces - eth0 for external connectivity and eth1 for internal management and VXLAN termination. On eth0 there's a promiscuos mode enabled in a VMware vswitch. I'm using classic approach with linux-bridging agent.

Theres' a virtual router(r1) residing on this network node which was provisioned by standart neutron utility. It's connected to a project and external network, and has a public IP address from an external subnet. It's connections are managed by a bridge, which consists of two interfaces - eth0 and a tap interface.

When I try to send trafic from r1 to any external IP, it first sends and ARP who-has for a gateway MAC. This ARP packet is switched by the bridge, and bridge updates it's MAC table so r1 MAC address is assosiated with tap interface. But this ARP packet is also 48 bytes long, so it has to be padded to 64 bytes(60 without a CRC) according to the rules of ethernet. The issue is, that padding happens somewhere in a system, so a new 60byte packet gets reinserted in the network stack of a host, so a brdige now sees this new 60byte packet on it's eth0 interface. After that the bridge updates it's MAC table so the r1 MAC address is now assosiated with an eth0 interface of a bridge. Everything that follows is a normal operation. ARP who-has packet gets sent to a network, response ARP is-at packet comes with a dst-MAC of an r1, bridge makes a lookup, sees this MAC address on incoming interface, and drops the packet accoring to a split horizon rule.

Any ideas how to fix this behavior? Packet MUST be padded, but it MUST NOT be reiserted in a network stack in such a fashion that bridge sees this packet again on eth0. Does a fact that network node works on VMware guest has something to do with it? Maybe its VMware e1000 driver behavior?

click to hide/show revision 2
retagged

neutron bridging and ethernet padding issue

I have a Mitaka lab setup. One of the nodes in this setup is Neutron running on Ubuntu 14.04LTS on a VMware ESXi guest. It has two network interfaces - eth0 for external connectivity and eth1 for internal management and VXLAN termination. On eth0 there's a promiscuos mode enabled in a VMware vswitch. I'm using classic approach with linux-bridging agent.

Theres' a virtual router(r1) residing on this network node which was provisioned by standart neutron utility. It's connected to a project and external network, and has a public IP address from an external subnet. It's connections are managed by a bridge, which consists of two interfaces - eth0 and a tap interface.

When I try to send trafic from r1 to any external IP, it first sends and ARP who-has for a gateway MAC. This ARP packet is switched by the bridge, and bridge updates it's MAC table so r1 MAC address is assosiated with tap interface. But this ARP packet is also 48 bytes long, so it has to be padded to 64 bytes(60 without a CRC) according to the rules of ethernet. The issue is, that padding happens somewhere in a system, so a new 60byte packet gets reinserted in the network stack of a host, so a brdige now sees this new 60byte packet on it's eth0 interface. After that the bridge updates it's MAC table so the r1 MAC address is now assosiated with an eth0 interface of a bridge. Everything that follows is a normal operation. ARP who-has packet gets sent to a network, response ARP is-at packet comes with a dst-MAC of an r1, bridge makes a lookup, sees this MAC address on incoming interface, and drops the packet accoring to a split horizon rule.

Any ideas how to fix this behavior? Packet MUST be padded, but it MUST NOT be reiserted in a network stack in such a fashion that bridge sees this packet again on eth0. Does a fact that network node works on VMware guest has something to do with it? Maybe its VMware e1000 driver behavior?

click to hide/show revision 3
retagged

neutron bridging and ethernet padding issue

I have a Mitaka lab setup. One of the nodes in this setup is Neutron running on Ubuntu 14.04LTS on a VMware ESXi guest. It has two network interfaces - eth0 for external connectivity and eth1 for internal management and VXLAN termination. On eth0 there's a promiscuos mode enabled in a VMware vswitch. I'm using classic approach with linux-bridging agent.

Theres' a virtual router(r1) residing on this network node which was provisioned by standart neutron utility. It's connected to a project and external network, and has a public IP address from an external subnet. It's connections are managed by a bridge, which consists of two interfaces - eth0 and a tap interface.

When I try to send trafic from r1 to any external IP, it first sends and ARP who-has for a gateway MAC. This ARP packet is switched by the bridge, and bridge updates it's MAC table so r1 MAC address is assosiated with tap interface. But this ARP packet is also 48 bytes long, so it has to be padded to 64 bytes(60 without a CRC) according to the rules of ethernet. The issue is, that padding happens somewhere in a system, so a new 60byte packet gets reinserted in the network stack of a host, so a brdige now sees this new 60byte packet on it's eth0 interface. After that the bridge updates it's MAC table so the r1 MAC address is now assosiated with an eth0 interface of a bridge. Everything that follows is a normal operation. ARP who-has packet gets sent to a network, response ARP is-at packet comes with a dst-MAC of an r1, bridge makes a lookup, sees this MAC address on incoming interface, and drops the packet accoring to a split horizon rule.

Any ideas how to fix this behavior? Packet MUST be padded, but it MUST NOT be reiserted in a network stack in such a fashion that bridge sees this packet again on eth0. Does a fact that network node works on VMware guest has something to do with it? Maybe its VMware e1000 driver behavior?

click to hide/show revision 4
No.4 Revision

neutron bridging and ethernet padding issue

I have a Mitaka lab setup. One of the nodes in this setup is Neutron running on Ubuntu 14.04LTS on a VMware ESXi guest. It has two network interfaces - eth0 for external connectivity and eth1 for internal management and VXLAN termination. On eth0 there's a promiscuos mode enabled in a VMware vswitch. I'm using classic approach with linux-bridging agent.

Theres' a virtual router(r1) residing on this network node which was provisioned by standart neutron utility. It's connected to a project and external network, and has a public IP address from an external subnet. It's connections are managed by a bridge, which consists of two interfaces - eth0 and a tap interface.

When I try to send trafic from r1 to any external IP, it first sends and ARP who-has for a gateway MAC. This ARP packet is switched by the bridge, and bridge updates it's MAC table so r1 MAC address is assosiated with tap interface. But this ARP packet is also 48 bytes long, so it has to be padded to 64 bytes(60 without a CRC) according to the rules of ethernet. The issue is, that padding happens somewhere in a system, so a new 60byte packet gets reinserted in the network stack of a host, so a brdige now sees this new 60byte packet on it's eth0 interface. After that the bridge updates it's MAC table so the r1 MAC address is now assosiated with an eth0 interface of a bridge. Everything that follows is a normal operation. ARP who-has packet gets sent to a network, response ARP is-at packet comes with a dst-MAC of an r1, bridge makes a lookup, sees this MAC address on incoming interface, and drops the packet accoring to a split horizon rule.

Any ideas how to fix this behavior? Packet MUST be padded, but it MUST NOT be reiserted in a network stack in such a fashion that bridge sees this packet again on eth0. Does a fact that network node works on VMware guest has something to do with it? Maybe its VMware e1000 driver behavior?