Trust Boundaries and QoS on the Nexus 5000/2000 – Part 3

This is the third article on my series on QoS on the Nexus 5000 (N5K) and Nexus 2000 (N2K) for medical grade networks. The first article was QoS on the Nexus 5000/2000 – Part 1, the second was (Configuring) QoS on the Nexus 5000/2000 – Part 2.

In the previous articles, I discussed some MQC background as well as key aspects of QoS on Nexus 5000/2000 switches, looked at the queuing and queue structure on Nexus 5000 and 2000 switches, and provided a sample configuration. One of my collegeages asked me for clarification on how trust and trust boundaries work with the N5K/N2K, so I decided to summarize our discussions.

The basic query was how the sample configurations in my previous article support trust boundaries for VoIP servers. On the N5K/N2K, the trust boundary is enforced by the incoming interface as follows:

• By default, all Ethernet interfaces are trusted interfaces. The 802.1p CoS and DSCP are preserved unless marking is configured. There is no default CoS to queue and DSCP to queue mapping. You can define and apply a policy to create these mappings. By default, without a user defined policy, all traffic is assigned to the default queue.
• Any packet not tagged with an 802.1p CoS value is classified into the default drop system class. If the untagged packet is sent over a trunk, it is tagged with the default untagged CoS value, which is zero.

For my previous two articles, the N5K/N2K were assumed to be access switches supporting servers in the data center. The server-facing ports were set as the trust boundary for the rest of the enterprise network. In the interest of simplicity, these configurations did not include support for a trusted port such as a VoIP server, or an uplink from a trusted internal switch.

So what would need to be added to support a trusted server? The answer is it depends – on whether the trusted server connects to a N5K or a N2K port.

Traffic from a Trusted Server (or Trusted Switch) on a N5K Port

If the VoIP server or any trusted device connects to a N5K port, then we need a different set of class-maps to classify the traffic based on the existing DSCP values, and a policy-map to put the classified traffic into the appropriate qos-group. The following class-map uses the same classes as on the previous articles, but with a “TR” appended to the end of each class-map:

class-map type qos match-any IN-NETWORK-CONTROL-TR
 description Network Control
 match DSCP CS3
!
class-map type qos match-any IN-VOICE-TR
 description Voice/VoIP/IPT
 match DSCP EF
!
class-map type qos match-any IN-CLINICAL-LIFE-CRITICAL-TR
 description Clinical Life Critical
 match DSCP CS5
!
class-map type qos match-any IN-MULTIMEDIA-CONFERENCING-TR
 description Multimedia Conferencing
 match DSCP AF41
!
class-map type qos match-any IN-REAL-TIME-INTERACTIVE-TR
 description Real-Time Interactive (i.e. Immersive TelePresence)
 match DSCP CS4
!
class-map type qos match-any IN-MULTIMEDIA-STREAMING-TR
 description Multimedia Streaming
 match DSCP AF31
!
class-map type qos match-any IN-SIGNALING-TR
 description Call Signaling
 match DSCP CS3
!
class-map type qos match-any IN-LOW-LATENCY-DATA-TR
 description Low-Latency Data (i.e. Scavenger Class)
 match DSCP AF21
!
class-map type qos match-any IN-NETWORK-MANAGEMENT-TR
 description Network Management
 match DSCP CS2
!
class-map type qos match-any IN-HIGH-THROUGHPUT-DATA-TR
 description High-throughput data traffic (FTP, etc.)
 match DSCP AF11
!
class-map type qos match-any IN-LOW-PRIORITY-DATA-TR
 description Low priority data applications (i.e. non-business apps)
 match DSCP CS1
!

With these new class-maps, a trusted policy-map is needed:

policy-map type qos TRUSTED-5K
 description Inbound policy for trusted ports
 class IN-VOICE-TR
   set qos-group 5
 class IN-CLINICAL-LIFE-CRITICAL-TR
   set qos-group 5
!
 class IN-MULTIMEDIA-CONFERENCING-TR
   set qos-group 4
 class IN-REAL-TIME-INTERACTIVE-TR
   set qos-group 4
!
 class IN-NETWORK-CONTROL-TR
  set qos-group 3
! 
 class IN-MULTIMEDIA-STREAMING-TR
   set qos-group 3
 class IN-SIGNALING
   set qos-group 3
 class IN-LOW-LATENCY-DATA-TR
   set qos-group 3
 class IN-NETWORK-MANAGEMENT-TR
   set qos-group 3
!
 class IN-HIGH-THROUGHPUT-DATA-TR
   set qos-group 2
 class IN-LOW-PRIORITY-DATA-TR
   set qos-group 2
!

The policy would be applied inbound only to the trusted ports. The more specific TRUSTED -5K interface policy will take precedence over the global CLASSIFY-GLOBAL policy.

Note: For a portchannel member, the service-policy needs to be configured under the interface port-channel, not on individual channel ports.

interface “ethernet mod/port” or “port-channel #”
! Use a range of interfaces if possible.
 service-policy input TRUSTED-5K
!
end

Traffic from a Trusted Server on a N2K Port

However, if a trusted server connects through a N2K interface, by default inbound traffic is marked w/ COS 0 unless it comes in on a trunk port when it will pick up the COS value on the trunk. The DSCP for the traffic is carried along if it exists. When the traffic leaves the N2K on uplink ports and enters N5K, potentially both trusted and untrusted ports will be aggregated on the same uplinks. Therefore, for trusted ports connected to the N2K, we need to analyze the traffic at the N2K uplinks into the N5K using the access lists, class-maps, policy-maps, and service policy in “Configuring Traffic Classification Based on DSCP” section in the previous post on (Configuring) QoS on the Nexus 5000/2000 – Part 2 to classify traffic and set the DSCP value and qos-group. We can not simply trust the DSCP values for all traffic from the N2K.

Note: At this time the Nexus 2148, Nexus 2232, and Nexus 2248 modules can only support CoS based traffic classification. Therefore, the configuration uses a global classification policy based on COS that is applied globally all N5K/N2K ports using a type qos policy and type QOS class-map as discussed in the previous post in the “Configuring Global Traffic Classification Based on COS” section.

For example, if the traffic from a N2K port matches the QOS-VOICE ACL, when it reaches the N5K it is marked as DSCP EF value and placed in qos-group 5. If the traffic matches the QOS-SIGNALING ACL, it will be marked DSCP CS3 and placed in qos-group 3.

All Traffic Needs Correct System Class

These two ways of handling traffic are needed to support putting traffic in the correct system class. (The system class is uniquely identified by a qos-group value.) On the N5K, egress scheduling and queuing is based on qos-groups, and is discussed in the previous post’s “Configuring Egress Scheduling and Queuing Based on QOS-Groups” and the “Establishing the System QoS Configuration” sections. The type queuing output QUEUING-GLOBAL policy under system QoS determines the bandwidth allocation for both the N5K and N2K interfaces.

Since the N2K only supports COS-based QOS, as I discussed before a policy is needed to establish the COS value of traffic sent to the N2K. The “Marking COS Based on QOS-Groups for Traffic Sent to N2K Ports” section defines the class-maps used to identifiy qos-groups, and the policy-map that uses the qos-groups to set the COS value. The service-policy type network-qos GLOBALNETWORKPOLICY supports the queuing and scheduling of traffic from the N5K to the N2K.

I hope this helps illustrate trust boundaries and QoS on the N5K/N2K. For further articles in the series, check back later, or subscribe to the NetCraftsmen blog feed!

— cwr

_________________________________________________________________________________________

More on Medical Grade Networks
For more information on medical grade networks, you may want to review the following articles:

• QoS on the Nexus 5000/2000 – Part 1
• (Configuring) QoS on the Nexus 5000/2000 – Part 2
• Designing a Medical Grade Network
• Healthcare Network Pain: Causes and Treatments
• Medical Grade Network Design and Operation

More on Nexus 5000
For more information on Nexus 5000 designs, you may want to review the following articles:

• Configuring Back-to-Back vPCs on Cisco Nexus Switches
• The Nexus 5000 and Nexus 2000: Tidbits and Gotchas
• Designing with the Nexus 5000 / 2000
• QoS on the Nexus 5000/2000 – Part 1
• (Configuring) QoS on the Nexus 5000/2000 – Part 2