Latest

Cisco Viptela SDWAN: DSCP Marked Traffic

 Cisco Viptela SDWAN: DSCP Marked Traffic

Today we are touching an important topic in Cisco Viptela SDWAN and that is DSCP Marked Traffic. As you know that vEdge/cEdge routers and controllers communicate using DTLS or TLS connections and use the DSCP value CS6 (48 decimal) by default.

Routing devices in the vEdge family encapsulate their data plan tunnel traffic with IPsec or GRE encapsulation. In order to measure data plane performance and detect failures, routers periodically transmit packets of BFD packets. A DSCP value of CS6 is also attached to these BFD packets.

DSCP that marks to the outer IP header will also be seen as UDP traffic by the Internet Service Provider; this is because vEdge routers and SD-WAN controllers copy DSCP to the outer IP header by default.

Run the below command

NDNA_vEdge1# show system statistics diff


Each packet carries the TOS byte 0xc0 (which is the equivalent to decimal 192 or 110 000 00 in binary. The first 6 high order bits correspond to DSCP bits value 48 in decimal or CS6).

Based on the packet length and the TOS marking, it could be concluded that these were BFD packets (both RX and TX directions) with high confidence. The first two packets in the output correspond to a control plane tunnel, and the two that follow to data plane tunnel traffic. These packets are marked with CS6 as well.

There is a possibility that some service providers, especially MPLS L3 VPN/MPLS L2 VPN providers, may maintain a different service level agreement with the customer and have different ways to route different classes of traffic based on the DSCP markings of the customer.

If you're paying premium service for DSCP EF or CS6 voice or signaling traffic, for instance, it can be noticed packet loss when priority traffic is policed. When priority traffic is policed, even if a total uplink bandwidth is not exceeded, packet loss can be seen for this type of traffic.

There have been cases where standard traffic (for example, ping from the vEdge router) is not affected if the dedicated priority queue on the service provider router is starved, as such traffic is marked with a default value of 0 as shown here (TOS byte)