Current Series Release Notes

8.0.0-33

New Features

  • Adds per-port default_vlan parameter to device driver interfaces. The plug_port_to_network, delete_port, plug_bond_to_network, and unplug_bond_from_network methods now accept an optional default_vlan parameter that allows specifying a default VLAN on a per-port basis.

    This enhancement provides greater flexibility compared to the existing switch-wide ngs_port_default_vlan configuration option. When both are specified, the per-port value takes precedence. If neither is provided, no default VLAN cleanup or restoration will be performed.

  • Extends VXLAN support to Arista EOS and SONiC switches, enabling VXLAN overlay networks for bare metal deployments across multiple switch platforms.

    Prerequisites: This feature requires the networking-baremetal plugin with the baremetal-l2vni mechanism driver, which handles hierarchical port binding and allocates local VLAN segments that are mapped to VXLAN VNIs on the switch fabric.

    Arista EOS:

    Arista EOS uses BGP EVPN control plane with ingress-replication for BUM (Broadcast, Unknown unicast, and Multicast) traffic handling, following the same architecture as Cisco NX-OS. This approach aligns with vendor best practices and scales properly with Neutron’s dynamic VNI assignment model.

    For each VXLAN network, the driver automatically configures:

    • BGP EVPN control plane (VLAN configuration with route distinguisher and route targets)

    • VLAN to VNI mapping

    • Ingress-replication for BUM traffic (default behavior)

    Configuration requires:

    • ngs_bgp_asn - BGP AS number (required)

    • vxlan_interface - VXLAN interface name (defaults to Vxlan1)

    Switch prerequisites include BGP EVPN configuration.

    SONiC:

    SONiC uses BGP EVPN control plane with ingress-replication for BUM (Broadcast, Unknown unicast, and Multicast) traffic handling. The implementation uses FRR for EVPN configuration and relies on EVPN Type-3 IMET routes for dynamic VTEP discovery, avoiding the scaling issues associated with static flood lists.

    For each VXLAN network, the driver automatically configures:

    • BGP EVPN control plane (per-VNI configuration in FRR with route distinguisher and route targets)

    • VLAN to VNI mapping on the VTEP interface

    • Ingress-replication for BUM traffic (via EVPN)

    Configuration requires:

    • vtep_name - VXLAN tunnel endpoint interface name (required)

    • ngs_bgp_asn - BGP AS number (required)

    See the VXLAN L2VNI Support section in the configuration documentation for complete setup instructions and examples for each platform.

  • Adds VXLAN support for Cisco NX-OS switches using BGP EVPN with ingress-replication. This enables VXLAN overlay networks for bare metal deployments with Cisco Nexus switches acting as VXLAN Tunnel Endpoints (VTEPs).

    Prerequisites: This feature requires the networking-baremetal plugin with the baremetal-l2vni mechanism driver, which handles hierarchical port binding and allocates local VLAN segments that are mapped to VXLAN VNIs on the switch fabric.

    The implementation uses BGP EVPN control plane with ingress-replication for BUM (Broadcast, Unknown unicast, and Multicast) traffic handling. This approach aligns with Cisco best practices and scales properly with Neutron’s dynamic VNI assignment model.

    For each VXLAN network, the driver automatically configures:

    • BGP EVPN control plane (VNI L2, route distinguisher, route targets)

    • VLAN to VNI mapping (vn-segment)

    • NVE interface membership with ingress-replication protocol bgp

    Configuration is minimal - only the NVE interface name needs to be specified (defaults to nve1). Switch prerequisites include BGP EVPN configuration with the NVE interface set to host-reachability protocol bgp.

    See the VXLAN L2VNI Support section in the configuration documentation for complete setup instructions and examples.

  • Now the etcd api version is detected automatically. The API version can be overridden by the api_version query parameter of the coordination backend url, or the ETCD3GW_API_PATH environment.

  • Adds VXLAN L2VNI support for Juniper Junos and Cumulus NVUE platforms, completing VXLAN capabilities across major network operating systems.

    Prerequisites: This feature requires the networking-baremetal plugin with the baremetal-l2vni mechanism driver, which handles hierarchical port binding and allocates local VLAN segments that are mapped to VXLAN VNIs on the switch fabric.

    Juniper Junos:

    Supports VXLAN L2VNI configuration on QFX and EX series switches. The implementation maps VLANs (referenced by name) to VNIs using the vxlan vni command. Optional EVPN control plane support is available via VRF target configuration.

    Configuration options:

    • ngs_evpn_vni_config - Enable EVPN VRF target configuration (default: false)

    • ngs_bgp_asn - BGP AS number (required when EVPN is enabled)

    When EVPN is enabled, the driver configures per-VLAN VRF targets for EVPN Type-2 route import/export using the format target:<asn>:<vni>.

    Cumulus NVUE:

    Supports VXLAN L2VNI configuration on the default bridge domain br_default for Cumulus Linux 5.x switches. Provides flexible BUM traffic handling with support for:

    • EVPN-only deployments (no configuration needed)

    • Head-End Replication (HER) with static flood lists

    • Hybrid deployments combining EVPN and HER

    Configuration options:

    • ngs_her_flood_list - Global HER flood list (comma-separated VTEP IPs, optional)

    • ngs_physnet_her_flood - Per-physical-network HER flood lists (format: physnet1:ip1,ip2;physnet2:ip3,ip4, optional)

    • ngs_evpn_vni_config - Enable EVPN VNI control plane configuration in FRR (default: false)

    • ngs_bgp_asn - BGP AS number (required when EVPN is enabled)

    HER flood list resolution follows a three-tier hierarchy: per-physnet mapping, global configuration, or EVPN-only (default).

    See the VXLAN L2VNI Support section in the configuration documentation for complete setup instructions and examples for each platform.

  • It is now possible to add security group support to existing drivers. This is implemented as a neutron service plugin and can be enabled by appending genericswitch_security_group to the neutron configuration [DEFAULT]service_plugins list. The security group feature is limited to applying one security group to a port.

    The first driver to have security group support added is netmiko_cisco_nxos. Limitations specific to this driver are:

    • Only ingress rules allowed

    • Only IPv4 rules are implemented

    • Supports rules for protocols: tcp, udp, icmp

  • The netmiko_dell_os10 driver now supports security groups on switches running Dell OS10, supporting the following:

    • Ingress and egress rules

    • IPv4

    • Rule filters for IP protocols TCP, UDP and ICMP

  • The netmiko_sonic driver now supports security groups on upstream distributions of SONiC, supporting the following:

    • Ingress and egress rules

    • IPv4 and IPv6

    • Rule filters for IP protocols TCP, UDP and ICMP

    The security group (ACL) implementation of Dell Enterprise SONiC 4.5 diverges from upstream enough to require the addition of a new driver netmiko_dell_enterprise_sonic. This driver should be specified when running this distribution of SONiC on Dell hardware.

    Dell Enterprise SONiC 4.5 also lacks support for ICMP filter rules, and this is enforced by netmiko_dell_enterprise_sonic.

Upgrade Notes

  • Any Aruba AOS-CX device using the “aruba_os” device type in its configuration needs a configuration update. The device type should be replaced with “aruba_aoscx”.

Bug Fixes

  • Add error checking for Dell Force10 and OS10 devices.

  • Add Arista EOS bond trunk commands so LACP bond trunk ports are supported.

  • Convert boolean configuration parameters before passing them to Netmiko. Previously, we were only converting numeric parameters (int/floats). This allows full configurability of low-level Netmiko parameters, such as SSH key management.

  • Fix Netmiko device type for Aruba AOS-CX. The previously-used device type, “aruba_os”, is meant for wireless controllers, not for switches running AOS-CX. As a result, trying to run any command over SSH with Netmiko would fail on Aruba AOS-CX switches.

  • Fixed incorrect command when unplugging bond subports. Previously, when a bond was unplugged from a network with trunk subports, the system would incorrectly try to add subports instead of removing them. This bug has been fixed, and the system now uses the correct command to remove subports, ensuring proper bond cleanup.

8.0.0

Other Notes

  • Explicit usage and monkey-patching with eventlet have been removed. Since this is a Neutron plugin, Neutron may still load eventlet modules, but netowrking-generic-switch no longer explicitly uses it. Operators should be sensitive to potential performance changes, although none are expected.