Effects of QinQ on other switch features

Per the IEEE standards, protocols such as STP and GVRP are assigned separate addresses for customer networks and provider networks, ensuring that QinQ has no impact on their operations. Bridge Protocol Data Units (BPDUs) that need to be tunneled through the provider network are treated as normal multicast frames at the provider bridge and forwarded out.

However, other protocols use common addresses for both customer and provider networks, and so are not supported when QinQ is enabled on the switch. Similarly, proprietary features such as discovery, UDLD, and loop-protect do not provide tunneling support. In such cases, where provider networks could run an instance of the same protocol as a customer could run local to their site, these frames are dropped at the customer-network ports of the provider bridge.

NOTE:

The IEEE standards group is devising new addressing schemes that may support additional QinQ tunneling operations. Check the latest product release notes for implementation updates as they apply to switches.

When QinQ is not enabled (the default setting), there are no impacts to the switch's normal operations. The following table shows the impacts of QinQ on the operation of switch protocols and features based on the QinQ mode that is configured as QinQ mixed VLAN mode (C-VLANs and S-VLANs are allowed) or QinQ S-VLAN mode (S-VLANs only).

Impacts of QinQ configurations on other switch features

Switch feature

Impacts of QinQ configurations and allowed operations

ACLs

In QinQ mixed VLAN or S-VLAN modes:

  • On double-tagged frames , the VID applicable when applying ACLs will be the S-VLAN tag and not the C-VLAN tag.

aaa

In QinQ mixed VLAN mode:

  • auth-vid/unauth-vid configuration is not supported on S-VLAN ports; the auth-vid/unauth-vid cannot be an S-VLAN id.

  • If a port that is a member of C-VLANs is configured with auth-vid or unauth-vid and it needs to be added to the S-VLAN domain, the auth/unauth configuration must first be undone.

arp-protect

In QinQ mixed VLAN mode:

  • ARP-protect is not supported on S-VLANs, nor on S-VLAN ports.

CDP

In QinQ VLAN or S-VLAN modes:

  • CDP frames are consumed at customer network ports, if CDP is enabled on the device port, and the customer device shows up as a CDP neighbor on the customer-network port. If not, the frames are dropped.

DHCP

In QinQ mixed VLAN or S-VLAN modes:

  • DHCP relay applies only to C-VLANs.

  • DHCP snooping is not supported on S-VLANs.

directed-broadcast

In QinQ S-VLAN mode:

  • directed-broadcast is not supported on provider core devices.

GVRP

In QinQ mixed VLAN mode:

  • S-VLAN ports cannot be GVRP enabled.

  • Regular VLANs will participate in C-VLAN GVRP if enabled to do so. S-VLANs will tunnel all C-VLAN GVRP frames through.

  • An explicit GVRP disable on a port is a prerequisite for moving the port to an S-VLAN domain.

  • Port-based interfaces do not have support for provider-GVRP protocols. Provider GVRP frames received at S-VLAN interfaces will be dropped.

  • If a VLAN being configured as an S-VLAN is already a GVRP VLAN on the switch, this S-VLAN creation would be blocked.

In QinQ S-VLAN mode:

  • GVRP is supported on S-VLAN ports if the qinq mode is S-VLAN.

igmp-proxy

In QinQ mixed VLAN mode:

  • IGMP-proxy cannot be configured on S-VLANs.

In QinQ S-VLAN mode:

  • IGMP-proxy is not supported.

IPv6

In QinQ mixed VLAN mode:

  • IPv6 features are not supported on S-VLANs.

ip-recv-mac

In QinQ mixed VLAN mode:
  • ip-recv-mac

    cannot be configured on S-VLANs.

In QinQ S-VLANmode:
  • ip-recv-mac

    is not supported.

Jumbo

In QinQ mixed VLAN or S-VLAN modes:

  • No change in operations. HPE recommends to jumbo-enable all S-VLANs used for customer data tunneling to support the addition of the extra S-tag in each frame.

LACP/ Port Trunks

In QinQ mixed VLAN mode:

  • Dynamic-LACP is not supported on S-VLAN ports: LACP manual trunks alone are supported. The new trunk will be a member of C-VLANs (port types are not applicable).

  • If two ports are added to a trunk, the resultant trunk will be a member of the default-vlan (vid-1) which is always a C-VLAN. The trunk can subsequently be manually assigned to an S-VLAN.

  • Port-type and VLAN configurations are not mapped. If the port-type is updated through CLI or SNMP and the port is subsequently moved from the C-VLAN space to the S-VLAN space then back again, the last configured port-type is retained through each move.

In QinQ S-VLAN mode:

  • On S-VLAN bridges, both manual and dynamic LACP trunks are supported. HPE does not recommend that you configure dynamic trunks on customer ports because they cannot become dynamic members of S-VLANs (there is no provider-gvrp for a dynamic trunk to become a member of S-VLANs.)

  • A newly formed trunk will by default be of type provider-network. When the trunk is manually assigned to an S-VLAN for the first time after being created, the port-type is provider-network.

Layer 3 Protocols (IP, IP+, DHCP, ARP, IGMP Layer 3, Layer 3 ACLs)

In QinQ mixed VLAN mode:

  • There is no IP layer functionality on S-VLANs.

  • No change in IP layer functionality on regular C-VLANs.

  • S-VLANs cannot be configured as RIP, OSPF, PIM, or VRRP interfaces.

In QinQ S-VLAN mode:

  • S-VLANs can be ip enabled.

  • IP routing is not supported.

LLDP

In QinQ mixed VLAN or S-VLAN modes:

  • LLDP is supported on the device (in both qinq modes). However, there is no provision for tunneling customer LLDP BPDUs through the provider-network.

  • LLDP BPDUs received from a customer's network will be consumed at the customer-network ports of a provider device and the customer device will be displayed as an LLDP neighbor. Similarly the provider network device will show up as a neighbor on the customer's network if the customer-network ports send out LLDP advertisements.

load-sharing

In QinQ S-VLAN mode:

  • Equal cost multi-path (ECMP) is not supported on provider core devices.

management VLAN

In QinQ mixed VLAN mode:

  • The management VLAN cannot be an S-VLAN.

Mirroring/Monitoring

In QinQ mixed VLAN mode:

  • Remote mirroring is not supported on S-VLANs.

  • Cannot monitor a VLAN with mirror ports in the other VLAN domain. That is, an S-VLAN or an S-VLAN port cannot be monitored using a C-VLAN port as its mirror, and vice-versa.

  • When a port is moved from the S-VLAN space to the C-VLAN space (or vice versa), all mirror/monitor sessions on the port must be unconfigured before the move will be allowed.

multicast-routing

In QinQ S-VLAN mode:

  • Multicast routing is not supported on provider core devices.

QoS

In QinQ mixed VLAN or S-VLAN modes:

  • HPE does not recommend that you enable DSCP on S-VLANs used for tunneling as the customer IP-pkt will be modified in the S-VLAN space.

Routing

In QinQ S-VLAN mode:

  • Routing is not supported on provider core devices.

source-binding

In QinQ mixed VLAN or S-VLAN modes:

  • source-binding cannot be configured on S-VLANs.

source-route

In QinQ S-VLAN mode:

  • source-route is not supported on provider core devices.

Spanning Tree

In QinQ mixed VLAN mode:

  • Customer (C-VLAN) spanning tree is supported. All C-VLAN ports will receive/transmit customer STP BPDUs and participate in regular VLAN spanning tree as usual.

  • When customer STP BPDUs are received at S-VLAN ports on the switch, they will be flooded out of the other ports on the S-VLAN. All such frames will be tunneled through the S-VLAN tunnel unscathed.

  • Provider (S-VLAN) spanning tree is not supported on the switch. If S-VLAN STP frames are received on any S-VLAN enabled ports, they will be re-forwarded out of the other ports on the S-VLAN.

  • STP configuration on S-VLAN ports is not supported.

  • If a port that is a member of C-VLANs is moved into being a member of S-VLANs, the port would, by default, tunnel customer STP BPDUs.

  • If a C-VLAN port has been configured with any non-default STP parameters (such as admin-edge, auto-edge, and bpdu-protect) and is then moved into an S-VLAN, the port will be put into a forwarding state regardless of the STP configurations done when the port was a member of the C-VLAN.

  • MSTP instances cannot include S-VLANs.

In QinQ S-VLAN mode:

  • Provider (S-VLAN) spanning tree is supported—both provider-network ports and customer-network ports will receive/transmit provider STP BPDUs.

  • Customer (VLAN) spanning tree tunneling is supported on S-VLAN interfaces—customer-network or provider-network ports will tunnel customer STP BPDUs through the appropriate S-VLAN.

Stacking

In QinQ mixed VLAN mode:

  • Stacking is supported only on C-VLANs. The device does not advertise itself (using the stack discovery protocol) in the S-VLAN space.

In QinQ S-VLAN mode:

  • Configuring QinQ with S-VLANs in a switch is not supported. Stacking discovery protocol frames will not be sent out of customer-network ports; similarly, any stacking discovery protocol frames received on customer-network ports will be dropped.

UDLD

In QinQ mixed vlan or S-VLAN modes:

  • UDLD frames received on udld-disabled customer network ports will be dropped. However, if the customer-network port is udld-enabled, it can peer with a customer device.

  • UDLD frames received on udld-disabled provider network ports will be re-forwarded out of other udld-disabled provider network ports on the same VLAN.

  • UDLD re-forwarding in the C-VLAN space (QinQ disabled or mixed VLAN mode) will remain unaltered.

udp-bcast-forward

In QinQ S-VLAN mode:
  • udp-bcast-forward

    is not supported on provider core devices.

unknown-vlans

In QinQ mixed VLAN mode:

  • GVRP (learn and disabled modes) not supported on S-VLAN ports.

  • A C-VLAN port that has GVRP enabled will need to disable it before it can be added to S-VLANs.

Voice VLANs

In QinQ mixed VLAN mode:

  • S-VLANs cannot be configured as voice-VLANs.

VRRP

In QinQ mixed VLAN or S-VLAN modes:

  • VRRP is not supported on S-VLANs.