Understanding CoS on OVSDB-Managed VXLAN Interfaces
You can configure class of service (CoS) features on OVSDB-managed VXLAN interfaces on QFX5100 and QFX10000 Series switches. An OVSDB-managed VXLAN interface uses an OVSDB controller to create and manage the VXLAN interfaces and tunnels. OVSDB-managed VXLAN interfaces support:
Packet classifiers on ingress interfaces. On network-facing interfaces (interfaces that connect to the network, for example, switch interfaces that connect to a VXLAN gateway), you can configure DSCP classifiers. Fixed classifiers, 802.1p classifiers, and MPLS EXP classifiers are not supported on VXLAN interfaces.
MF Filters on access-facing interfaces are applied as a group config and not as a normal filter.
Packet rewrite rules (to change the code point bits of outgoing packets). On network-facing interfaces, you can configure DSCP rewrite rules. Rewrite rules are not supported on access-facing interfaces, and are not supported for IEEE 802.1p code points.
Rewrite rules rewrite the DSCP code point on the VXLAN header only. Rewrite rules do not rewrite the DSCP code point on the inner packet header.
Packet schedulers on egress interfaces. You can configure schedulers on network-facing and access-facing interfaces.
You cannot configure CoS on manually configured VXLAN interfaces.
CoS configuration on OVSDB-managed VXLAN interfaces uses the same CLI statements and configuration constructs as CoS configuration on regular Ethernet interfaces. However, feature support differs on OVSDB-managed VXLAN interfaces and regular Ethernet interfaces. The following sections describe the differences between CoS support on OVSDB-managed VXLAN interfaces and regular Ethernet interfaces:
Classifier and Rewrite Rule Interface Support
The switch Ethernet ports can function as:
Layer 2 physical interfaces (family ethernet-switching)
Layer 2 logical interfaces (family ethernet-switching)
Layer 3 physical interfaces (family inet/inet6)
Layer 3 logical interfaces (family inet/inet6)
You can apply CoS classifiers and rewrite rules only to the following interfaces:
Layer 2 physical interfaces. All underlying logical Layer 2 interfaces on the physical interface use the classifier and rewrite rule configuration on the physical interface. All OVSDB-managed VXLAN traffic on the interface uses the same Layer 2 CoS classifiers and rewrite rules.
Layer 3 physical interfaces if at least one logical Layer 3 interface is configured on the physical interface. All underlying logical Layer 3 interfaces on the physical interface use the classifier and rewrite rule configuration on the physical interface. All OVSDB-managed VXLAN traffic on the interface uses the same Layer 3 CoS classifiers and rewrite rules.
Table 1 shows on which interfaces you can configure and apply classifiers and rewrite rules on network-facing interfaces.
Table 1: OSVDB-Managed VXLAN Interface Support for Classifier and Rewrite Rule Configuration on Network-Facing Interfaces
CoS Classifiers and Rewrite Rules
Layer 2 Physical Interfaces
Layer 2 Logical Interfaces
Layer 3 Physical Interfaces (If at Least One Logical Layer 3 Interface Is Defined)
Layer 3 Logical Interfaces
DSCP IPv6 classifier
IEEE 802.1p classifier
DSCP rewrite rule
DSCP IPv6 rewrite rule
IEEE 802.1p rewrite rule
EXP rewrite rule
The switch encapsulates packets in VXLAN after packet classification, and before packet rewrite and scheduling.
Classifiers on OVSDB-Managed VXLAN Interfaces
Classifiers map incoming packets to a CoS service level, based on the code points in the header of the incoming packet. At the ingress interface, the switch reads the code point value in the packet header, then assigns the packet to the forwarding class and loss priority mapped to that code point value. The forwarding class is mapped to an egress queue and to scheduling properties. OVSDB-managed VXLAN interfaces support packet classification based on DSCP code points on all ingress interfaces, and packet classification based on DSCP multi-field (MF DSCP) code points or for behavior aggregate (BA) classification, the DSCP, DSCP IPv6, or IP precedence bits of the IP header convey the behavior aggregate class information on access-facing interfaces.
If you do not configure classifiers, the switch uses the default CoS settings to classify incoming traffic, as described in Understanding Default CoS Scheduling and Classification.
Classifier configuration on an OVSDB-managed VXLAN switch interface is similar to classifier configuration on any other type of ingress interface (see Understanding CoS Classifiers). However, on OVSDB-managed VXLAN interfaces, there is a difference in the way you can apply classifiers to Layer 2 interfaces compared to non-VXLAN interfaces. On OVSDB-managed VXLAN interfaces, you apply classifiers to Layer 2 physical interfaces, and the underlying logical interfaces use the classifier configuration applied on the physical interface. On non-VXLAN interfaces, you apply Layer 2 classifiers to logical interface unit 0 (all other logical interfaces on the port use the classifier configured on unit 0), and not to physical interfaces.
Classifiers on Access-Facing Interfaces
When a packet enters an ingress switch from a server (or other source), you can map it to a forwarding class and a loss priority based on its DSCP multi-field (MF DSCP) classifiers code points. The forwarding class is mapped to an egress queue and to scheduling properties. For behavior aggregate (BA) classification, the DSCP, DSCP IPv6, or IP precedence bits of the IP header convey the behavior aggregate class information.
Classifiers on Network-Facing Interfaces
When a packet enters an egress switch from the network, you can map it to a forwarding class and a loss priority based on its DSCP code points by applying a classifier to the Layer 3 physical interface. The forwarding class is mapped to an egress queue and to scheduling properties.
By default, before a packet exits the network-facing interface on the ingress switch, the switch copies the DSCP code points from the packet header into the VXLAN header, so the DSCP code points are not rewritten. However, you can configure a rewrite rule on the egress interface (network-facing interface) of the ingress switch if you want to change the value of the DSCP code points.
On the egress switch, the network-facing interface reads the DSCP code points from the VXLAN header and assigns packets to forwarding classes (which are mapped to egress queues) and loss priorities based on the DSCP code points.
You cannot classify traffic using an IEEE 802.1p classifier.
Rewrite Rules on OVSDB-Managed VXLAN Interfaces
When packets exit a network, edge switches might need to change the CoS settings of the packets. Rewrite rules change the value of the code points in the packet header by rewriting the code points to a different value in the outgoing packet. See Understanding CoS Rewrite Rules for detailed information about rewrite rules.
On OVSDB-managed VXLAN interfaces, you can apply DSCP rewrite rules to packets on network-facing physical interfaces. You cannot apply rewrite rules to access-facing OVSDB-managed VXLAN interfaces, and you cannot apply rewrite rules to IEEE 802.1p code points on network-facing interfaces.
By default, before a packet exits the network-facing interface on the ingress switch, the switch copies the DSCP code points from the packet header into the VXLAN header, so the DSCP code points are not rewritten. The VXLAN header needs to contain the correct DSCP code points because the network-facing ingress port of the egress switch uses the DSCP code points in the VXLAN header to classify the incoming packets.
If you want to change the value of the DSCP code points before the switch transmits packets across the network to the egress switch, you can configure a DSCP rewrite rule and apply it to the egress (network-facing) interface on the ingress switch.
Rewrite rules on OVSDB-managed VXLAN interfaces rewrite only the DSCP code point value in the VXLAN header. Rewrite rules on OVSDB-managed VXLAN interfaces do not rewrite the inner (IP) packet header DSCP code point value, so the DSCP code point value in the IP packet header remains unchanged.
Schedulers on OVSDB-Managed VXLAN Interfaces
Packet scheduling (the allocation of port resources such as bandwidth, scheduling priority, and buffers) on OVSDB-managed VXLAN interfaces uses enhanced transmission selection (ETS) hierarchical port scheduling, the same as other interfaces on the switch.
ETS hierarchical port scheduling allocates port bandwidth to traffic in two tiers. ETS provides better port bandwidth utilization and greater flexibility to allocate port resources to forwarding classes (this equates to allocating port resources to output queues because queues are mapped to forwarding classes) and to groups of forwarding classes called forwarding class sets (fc-sets).
First, ETS allocates port bandwidth to fc-sets (also known as priority groups). Each fc-set consists of one or more forwarding classes that carry traffic that requires similar CoS treatment. The bandwidth each fc-set receives is then allocated to the forwarding classes in that fc-set. Each forwarding class is mapped to an output queue. The scheduling properties of a forwarding class are assigned to the queue to which the forwarding class is mapped. Traffic control profiles control the allocation of port bandwidth to fc-sets. Queue schedulers control the allocation of fc-set bandwidth to forwarding classes. See Understanding CoS Output Queue Schedulers, Understanding CoS Traffic Control Profiles, and Understanding CoS Hierarchical Port Scheduling (ETS) for detailed information about scheduling.
It is important to take into account the overhead due to VXLAN header encapsulation when you calculate the amount of bandwidth to allocate to VXLAN traffic. When a virtual tunnel endpoint (VTEP) encapsulates a packet in VXLAN, the VXLAN header adds 50 bytes to the packet.
When you configure the queue scheduler transmit rate, which is the minimum amount of guaranteed bandwidth allocated to traffic mapped to a particular queue, and the traffic control profile guaranteed rate, which is the minimum amount of guaranteed bandwidth allocated to traffic mapped to a particular priority group (fc-set), be sure to configure a high enough bandwidth allocation to account for the VXLAN header overhead.