Public bug reported: When creating a tenant network with type vxlan, the MTU is automatically set to 1450:
# neutron net-show net2 +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | availability_zone_hints | | | availability_zones | nova | | created_at | 2016-04-08T11:11:42 | | description | | | id | f44e9e2c-8a60-46c7-98bb-3f1824fc09e9 | | ipv4_address_scope | | | ipv6_address_scope | | | mtu | 1450 | | name | net2 | | provider:network_type | vxlan | | provider:physical_network | | | provider:segmentation_id | 65633 | | router:external | False | | shared | False | | status | ACTIVE | | subnets | 288021c1-7073-41c5-a233-529226971dd3 | | tags | | | tenant_id | e3c253d3e8344a8796e70bc4f96b6166 | | updated_at | 2016-04-08T11:11:42 | +---------------------------+--------------------------------------+ This is the maximum Ethernet MTU possible for the tenant assuming the encapsulated packet has to fit into an IP MTU of 1500 on the tunnel network. Now neutron tells DHCP to set --dhcp-option-force=option:mtu,1450 but the DHCP option refers to the IP layer MTU, see https://tools.ietf.org/html/rfc2132 section 5.1. So a correctly behaving client will set its interface (Ethernet) MTU to 1454, implying an IP MTU of 1450. But now it will send Ethernet frames of size 1454, which encapsulated have size 1504, and thus get dropped on the tunnel network. The correct behaviour here would be to advertise an MTU reduced by 4 via DHCP. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1567923 Title: Neutron advertises too high MTU for vxlan Status in neutron: New Bug description: When creating a tenant network with type vxlan, the MTU is automatically set to 1450: # neutron net-show net2 +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | availability_zone_hints | | | availability_zones | nova | | created_at | 2016-04-08T11:11:42 | | description | | | id | f44e9e2c-8a60-46c7-98bb-3f1824fc09e9 | | ipv4_address_scope | | | ipv6_address_scope | | | mtu | 1450 | | name | net2 | | provider:network_type | vxlan | | provider:physical_network | | | provider:segmentation_id | 65633 | | router:external | False | | shared | False | | status | ACTIVE | | subnets | 288021c1-7073-41c5-a233-529226971dd3 | | tags | | | tenant_id | e3c253d3e8344a8796e70bc4f96b6166 | | updated_at | 2016-04-08T11:11:42 | +---------------------------+--------------------------------------+ This is the maximum Ethernet MTU possible for the tenant assuming the encapsulated packet has to fit into an IP MTU of 1500 on the tunnel network. Now neutron tells DHCP to set --dhcp-option-force=option:mtu,1450 but the DHCP option refers to the IP layer MTU, see https://tools.ietf.org/html/rfc2132 section 5.1. So a correctly behaving client will set its interface (Ethernet) MTU to 1454, implying an IP MTU of 1450. But now it will send Ethernet frames of size 1454, which encapsulated have size 1504, and thus get dropped on the tunnel network. The correct behaviour here would be to advertise an MTU reduced by 4 via DHCP. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1567923/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
