Environment: OpenStack Platform 10 (Netwon) Problem Summary: The problem occurs with Tetant network which network mtu is set to 8500. The network is hosted on Cisco VTS but compute uses openvswitch mechanism_driver not the cisco_vts, controller uses cisco_vts. Controller configuration: $ egrep -v "^$|^#" etc/neutron/neutron.conf | grep mtu advertise_mtu = true global_physnet_mtu=8500 $ egrep -v "^$|^#" etc/neutron/neutron.conf | grep ml2 core_plugin=ml2 This is mechanism driver cisco_vts: $ egrep -ir -v "^$|^#" etc/neutron/* | grep vts etc/neutron/plugin.ini:mechanism_drivers = sriovnicswitch,cisco_vts etc/neutron/plugins/ml2/ml2_conf.ini:mechanism_drivers = sriovnicswitch,cisco_vts --- Compute configuration: Bridge: Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Port "tapde1ffa0b-bb" tag: 1 Interface "tapde1ffa0b-bb" Port int-br-sriovb Interface int-br-sriovb type: patch options: {peer=phy-br-sriovb} Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Port int-br-sriova Interface int-br-sriova type: patch options: {peer=phy-br-sriova} Bridge br-sriova Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port phy-br-sriova Interface phy-br-sriova type: patch options: {peer=int-br-sriova} Port br-sriova Interface br-sriova type: internal Bridge br-sriovb Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port br-sriovb Interface br-sriovb type: internal Port phy-br-sriovb Interface phy-br-sriovb type: patch options: {peer=int-br-sriovb} We think these br-sriovb and br-sriova are created because of the neutron bridge mappings on compute, as they are not part of compute.yaml. etc/neutron/plugin.ini:121:mechanism_drivers =openvswitch,sriovnicswitch etc/neutron/plugin.ini:209:network_vlan_ranges =provider:1001:1141,sriova:2425:2425,sriovb:2426:2426 etc/neutron/plugins/ml2/openvswitch_agent.ini:224:bridge_mappings =provider:br-ex,sriova:br-sriova,sriovb:br-sriovb etc/neutron/plugins/ml2/sriov_agent.ini:123:physical_device_mappings =sriova:ens1f0,sriovb:ens1f1,sriova:ens2f0,sriovb:ens2f1 etc/neutron/plugins/ml2/ml2_conf.ini:121:mechanism_drivers =openvswitch,sriovnicswitch etc/neutron/plugins/ml2/ml2_conf.ini:209:network_vlan_ranges =provider:1001:1141,sriova:2425:2425,sriovb:2426:2426 Note that mechanism drivers used on the controller are different from the compute node because the controller is using cisco_vts while the compute doesn't have that configure. What we have been trying on the session: We have removed br-sriova and br-sriovb empty bridge from OVS and as well removed ports int-br-sriova and int-br-sriovb from br-int. Verified that qdhcp namespace tap device itself is created with MTU 8500. We went to Cisco VTS and checked the qrouter interface was set to MTU 1500, and have modified it to 8500: What we observed: Bridge br-int is configured with MTU 1500 and whenever you create a VM it creates tap device in the br-int bridge and that bridge inherits it's MTU value. *** The problem here is that the tap device is being created with the MTU 1500. *** Network in which the instance is being created is configured with MTU 8500. If we switch br-int MTU to 8500 OR tap device MTU to 8500 (it will bump up the value of br-int) all the other instances that are being created are already with 8500. The instance get's well MTU 8500 injected thru the dhcp. Research: Cisco VTS 2.5(2) had initially reported problem with setting MTU on tap devices https://quickview.cloudapps.cisco.com/quickview/bug/CSCvg57941 You mention that the mechanism driver for cisco_vts is not used on the compute, only on controller. The compute is using openvswitch. And as well you mentioned that you are running Cisco VTS 2.6.
First, clarification on configuration: 1. compute nodes don't care about mechanism_drivers option. Openvswitch agent, when running, advertises itself to controller node, and allows the latter to schedule ports to it; if the port is bound to the agent, it will attempt to wire it based on firewall_driver. 2. I am not sure having the mixed environment of Cisco VTS driver enabled on controller side and openvswitch agent running on compute nodes is even possible. If anything, it's not a configuration meant to be supported by DFG:Networking. I expect Cisco folks to give us guidance here. Is it even something one could expect to work? How does Cisco VTS plugin drive Open vSwitch agent in this case? The agent usually relies on RPC endpoints and logic implemented by its own ml2 driver - openvswitch. Is Cisco VTS driver a direct and transparent replacement of it? @Nir, should we pull in someone from Cisco side here? If so, who would it be? Since we are looking into potential relationship between this bug and https://bugzilla.redhat.com/show_bug.cgi?id=1553839, could you please also list which firewall_driver is configured on compute nodes?
Hello, Here is the compute firewall driver: grep ^firewall_driver /cases/02049190/sosreport-20180309-024354/teststack-compute-0/etc/neutron/plugins/ml2/openvswitch_agent.ini firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
Moving the bug to Compute DFG since if there is an issue, it's in nova not enforcing MTU for tap device it creates when iptables hybrid firewall driver is not used by Neutron. There is little Networking DFG can do here. Not sure if the fix would belong to os-vif or openstack-nova, moving to the latter and leaving it up to the Compute team to pick the right component.
(In reply to Ihar Hrachyshka from comment #8) > Moving the bug to Compute DFG since if there is an issue, it's in nova not > enforcing MTU for tap device it creates when iptables hybrid firewall driver > is not used by Neutron. Right. There is already a patch upstream that should fix the issue [0]. Also it looks like we have a similar issue but for different usage. Not sure whether we want mark this bug as duplicate of bug 1553839. [0] https://review.openstack.org/#/c/553072/
Hi there, If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text. If this bug does not require doc text, please set the 'requires_doc_text' flag to -. Thanks, Alex
Verified by validating that the mtu is now included in the instance XML: [heat-admin@compute-0 ~]$ sudo virsh dumpxml instance-00000005 | grep mtu <mtu size='1446'/>
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:2714