yahoo-eng-team team mailing list archive

[OpenStack Infra <1988069@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/875809
Committed: https://opendev.org/openstack/neutron/commit/88ce859b568248a0ee2f47a5d91c1708b774d20e
Submitter: "Zuul (22348)"
Branch:    master

commit 88ce859b568248a0ee2f47a5d91c1708b774d20e
Author: Brian Haley <haleyb.dev@xxxxxxxxx>
Date:   Wed Mar 1 00:52:38 2023 -0500

    Change API to validate network MTU minimums
    
    A network's MTU is now only valid if it is the minimum value
    allowed based on the IP version of the associated subnets,
    68 for IPv4 and 1280 for IPv6.
    
    This minimum is now enforced in the following ways:
    
    1) When a subnet is associated with a network, validate
       the MTU is large enough for the IP version. Not only
       would the subnet be unusable if it was allowed, but the
       Linux kernel can fail adding addresses and configuring
       network settings like the MTU.
    
    2) When a network MTU is changed, validate the MTU is large
       enough for any currently associated subnets. Allowing a
       smaller MTU would render any existing subnets unusable.
    
    Closes-bug: #1988069
    Change-Id: Ia4017a8737f9a7c63945df546c8a7243b2673ceb


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1988069

Title:
  neutron-dhcp-agent fails when small tenant network mtu is set

Status in neutron:
  Fix Released

Bug description:
  High level description: 
  When a user creates a tenant network with a very small MTU (in our case 70), neutron-dhcp-agent stops updating the dnsmasq configuration, causing DHCP issues for all networks.

  Pre-conditions:
  Neutron is using the openvswitch, baremetal, and networking-generic-switch mechanism drivers.
  A physical network named `physnet1` is configured, with MTU=9000

  Step-by-step reproduction steps:
  As an admin user, run:

  # Create "normal" network and subnet
  openstack network create --provider-network-type vlan --provider-physical-network physnet1 --mtu 1500 test-net-1500
  openstack subnet create --subnet-range 10.100.10.0/24 --dhcp --network test-net-1500 test-subnet-1500

  # Create "small MTU" network and subnet
  openstack network create --provider-network-type vlan --provider-physical-network physnet1 --mtu 70 test-net-70
  openstack subnet create --subnet-range 10.100.11.0/24 --dhcp --network test-net-70 test-subnet-70

  # attempt to launch an instance on the "normal" network
  openstack server create --image Ubuntu --flavor Baremetal --network test-net-1500

  Expected output: what did you hope to see?
  We expected to see neutron-dhcp-agent update the dnsmasq configuration, which would then serve requests from the instances.

  * Actual output: did the system silently fail (in this case log traces are useful)?
  Openstack commands complete successfully, but instance never receives a response to its DHCP requests. Neutron-dhcp-agent logs show:
  https://paste.opendev.org/show/b4r0XCu5KpguM72bnh0u/

  Version:
    ** OpenStack version "stable/xena", hash bc1dd6939d197d15799aaf252049f76442866c21
    ** Linux distro, kernel. Ubuntu 20.04
    ** Containers built with Kolla, and deployed via Kolla-Ansible

  * Environment: 
  Single node deployment, all services (core, networking, database, etc.) on one node.
  All compute-nodes are baremetal via Ironic.

  * Perceived severity: is this a blocker for you?
  High, as non-admin users can trigger an DHCP outage affecting all users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1988069/+subscriptions