OVSDB-Managed Networking Scenario
Conventionally, network service providers and cloud service providers expanding their data center scale to meet the needs of XaaS (i.e. ITaaS, IaaS, SaaS, etc.) are seen as the path to increased monetization and business. However, introducing these innovative services to the market requires a new approach to networking in the cloud. One solution to merge legacy network elements into SDN environments is to connect bare-metal servers and other legacy virtual instances to a top-of-rack (ToR) switch, which provides interconnectivity with the virtualized SDN environment, as shown in Figure 1 below. Juniper Networks Contrail Cloud supports this interconnectivity with ToR switches through the Open vSwitch Database Management (OVSDB) protocol. The bare-metal servers and other legacy VMs can belong to any of the virtual networks configured in the Contrail cluster, facilitating communication with the other virtualized instances. Then policy and class-of-service (CoS) configurations can be used to control this communication.
These network environments contain both Network-Network-Interfaces (NNI) and Customer-Network-Interfaces (CNI), and the use of an OVSDB-managed ToR switch means it is necessary to implement different CoS policies on each interface type. This created the demand for a newly designed testing approach for CoS users.
For more information on using a Junos device as an OVSDB-managed ToR switch, see OVSDB and VXLAN and OVSDB Connections in a Contrail Environment.
Figure 1: Using a ToR Switch to Integrate Bare-Metal Servers into a Contrail/SDN Environment
Specially Designed Hybrid Testing Technology for Customers
Generally, Junos devices using CoS may implement both multifield (MF) and behavior aggregate (BA) classification to identify packets going through an interface. However, unlike normal traffic classification in a traditional environment, OVSDB-managed interfaces on a Junos device do not support BA classification. Therefore, these interfaces must use MF classifiers to identify packets. In this case, a hybrid testing scenario/testing technology is designed for both unicast and multicast traffic:
- On NNIs: Examine DSCP markings using BA classifiers.
- On CNIs: Examine DSCP markings using MF classifiers.
The BA and MF classifiers can identify various incoming application traffic, and assign it to up to 12 forwarding classes, where the traffic can then be forwarded to the next step in the CoS process. The following section demonstrates how BA and MF classifications are used in this scenario.
Test Specialty Simulation
- Test Scenario and Traffic Types
As shown in Figure 1 above, an NNI is connected to the Layer 3 Transport Network, while a CNI is attached to a physical server. The CNI could also be connected to a local router or switch.
In this case, the traffic details are follows:
From NNI to CNI:
• Dest_MAC: 00:AA:00:00:00:01
• Src_MAC: 00:BB:00:00:00:01
• VLAN 100
• Dest_IP: 100.100.100.100/24
• Src_IP: 100.100.100.1/24
• DSCP: 111110
• MTU 1200 Bytes
• PPS=50,000/s
From CNI to NNI:
• Dest_MAC: 00:BB:00:00:00:01
• Src_MAC: 00:AA:00:00:00:01
• VLAN 100
• Dest_IP address 100.100.100.1/24
• Src_IP: 100.100.100.100/24
• DSCP: 100100
• MTU 1200 Bytes
• PPS=50,000/s
- Forwarding Classes Configuration
Forwarding classes (queues) must be configured before traffic classification can be performed. On a QFX5100 device, up to 12 queues can be configured.
|
forwarding-classes {
class be queue-num 0;
class ef queue-num 1;
class af queue-num 2;
class nc queue-num 3;
class be1 queue-num 4;
class ef1 queue-num 5;
class af1 queue-num 6;
class nc1 queue-num 7;
class m1 queue-num 8;
class m2 queue-num 9;
class m3 queue-num 10;
class m4 queue-num 11;
}
|
- CNI Traffic Identification Based on DSCP
Most popular end-host OSs, routers, and switches support DSCP marking as packets leave the device. For example, using Windows, enabling Quality of Service (QoS) is an option to regulate the outgoing traffic.
In this case, packets flowing from the physical server towards the CNI are marked with DSCP 100100.
|
show firewall family ethernet-switching filter mf-classifier-for-dscp term af-mhigh1
from {
dscp 36;
}
then {
forwarding-class af;
loss-priority medium-high;
}
show groups contrail interfaces xe-0/0/16:3
unit <*> {
family ethernet-switching {
filter {
input mf-classifier-for-dscp;
}
}
}
Note: For CNIs, MF classifiers must be implemented on unit <*> to assign packets to target forwarding classes.
|
- Customer Simulation Result
- Hybrid Classification Result A: MF Identification
- NNI Traffic Identification Based on DSCP
|
show class-of-service interfaces
xe-0/0/11:2 {
classifiers {
dscp dscp_classifier;
}
}
show class-of-service classifiers dscp dscp_classifier
forwarding-class be {
loss-priority low code-points 000000;
loss-priority medium-high code-points 000100;
loss-priority high code-points 000110;
}
forwarding-class ef {
loss-priority low code-points [ 001000 011000 ];
loss-priority medium-high code-points [ 001100 011100 ];
loss-priority high code-points [ 001110 011110 ];
}
forwarding-class af {
loss-priority medium-high code-points [ 100100 101100 ];
loss-priority high code-points [ 100110 101110 ];
loss-priority low code-points [ 100000 101000 ];
}
forwarding-class nc {
loss-priority low code-points [ 110000 111000 ];
loss-priority medium-high code-points [ 110100 111100 ];
loss-priority high code-points [ 110110 111110 ];
}
|
- Customer Simulation Result
• Hybrid Classification Result B: BA Identification
Summary
In this scenario, a new hybrid testing approach has been introduced, which implements both BA and MF classification methods to support the OVSDB-managed CNI. In addition, this hybrid approach is able to successfully provide a set of classifications on both multicast and unicast traffic.