While delivering what turned out to be a very successful UCS and Nexus 1000V class a week and a half back, a number of you on the east coast of the US got tragically knocked out of class due to Hurricane/TS Sandy. While the class had to go on, I received a number of emails later on the following week mentioning about the disappointment many of you had based on not being able to ask questions during the live class. So we've decided to run the class again, live, the week after next. So for any who were not able to attend the first time due to this or any other reason, or would just like to attend again (or simply have an opportunity to purchase it for the first time and still attend a live version of this class), we will offer it again beginning on Nov 26 and running through Nov 30.

One of our most anticipated products of the year - INE's CCIE Service Provider v3.0 Advanced Technologies Class - is now complete!  The videos from class are in the final stages of post production and will be available for streaming and download access later this week.  Download access can be purchased here for $299.  Streaming access is available for All Access Pass subscribers for as low as $65/month!  AAP members can additionally upgrade to the download version for $149.

This blog post reviews and compares two most common types of traffic contracts - single rate and dual-rate agreements and their respective implementations using single-rate and dual-rate (two-rate) policing. We are also going to briefly discuss effects of packet remarking on end-to-end throughput and finally look at some examples of IOS configuration.

What is Traffic Contract

Service-providers network topology typically follows core/aggregation model, where network core has meshed topology and aggregation layers use some variation of tree topology. This design results in bandwidth aggregation when flows converge toward the core. Therefore, to avoid network resource oversubscription, accurate admission control is necessary at the network edge. The admission operation was trivial with circuit-switched TDM-based networks, but became significantly more complicated in packet switched networks. In a packet network, there is no such thing as a constant traffic flow rate, as flows only exist "temporarily" when packets are transmitted. In packet networks, it is common for service providers to connect customer using a sub-rate connection. Sub-rate a connection that provides only a fraction of the maximum possible link bandwidth, e.g. 1Mbps on a 100Mbps connection.

Implementing sub-rate access requires special agreement between service provider and customer - a specification known as "traffic contract". Traffic contracts are enforced both at customer and SP sides by using traffic shaping and policing respectively. Traffic contracts may vary and include multiple QoS parameters, but there are two most common types that we are going to look at today: single-rate and dual-rate traffic contracts.

In this first of a series of blog posts regarding Catalyst QoS, we will exam the AutoQoS capabilities on the 3560 Catalyst devices. AutoQoS allows for the automation of QoS settings for the switch with an absolute minimum of configuration required from the engineer. In particular, the 3560 AutoQoS features automates the classification and congestion management configurations required in VoIP environments. You should note that the 3560 AutoQoS has much “catching up” to do when you compare this feature to AutoQoS for VoIP and AutoQoS for Enterprise that are both now possible in the pure router class of Cisco devices.

First, the easy part. The interface configuration command required for QoS is simply:

auto qos voip [cisco-phone | cisco-softphone | trust]

Notice the auto qos voip command is used in conjunction with keywords that specify what devices to “trust” when it comes to these important VoIP packets. The cisco-phone keyword instructs the AutoQoS feature to only trust and act upon the incoming voice packets if they are truly sent from a Cisco IP Phone. The phone’s presence is detected thanks to CDP. Similarly, the cisco-softphone keyword instructs the device to only trust and act upon the voice packets if they are sent from a Cisco phone running in software on a PC. Finally, the trust keyword instructs the device to trust markings for VoIP packets that are coming from another switch or router over the port.

Abstract

This publication discusses the spectrum of problems associated with transporting Constant Bit Rate (CBR) circuits over packet networks, specifically focusing VoIP services. It provides guidance on practical calculation for voice bandwidth allocation in IP networks, including the maximum bandwidth proportion allocation and LLQ queue settings. Lastly, the publication discusses the benefits and drawbacks of transporting CBR flows over packet switched networks and demonstrates some effectiveness criteria.

Introduction

Historically, the main design goal of Packet Switched Networks (PSNs) was optimum bandwidth utilization for low-speed links. Compared to their counterpart, circuit-switched networks (CSNs such as SONET/SDH networks), PSNs use statistical as opposed to deterministic (synchronous) multiplexing. This feature allows PSNs to be very effective for bursty traffic sources, i.e. those that send traffic sporadically. Indeed, with many sources this allows the transmission channel to be optimally utilized by sending traffic only when necessary. Statistical multiplexing is only possible if every node in the network implements packet queueing, because PSNs introduce link contention. One good historical example is ARPANET: the network theoretical foundation has been developed in Kleinrock's work on distributed queueing systems (see [1]).

INE is happy to announce that we now have all 21 Modules of our new CCIE Voice Deep Dive completed --115 hours of recorded class-on-demand style video (no breaks or dead-air in the recordings - that's 115 hours of actual learning!)-- completed and ready for your consumption!

As we mentioned in a previous post, The author and poet Maya Angelou said “Words mean more than what is set down on paper. It takes the human voice to infuse them with deeper meaning.”. Well that is certainly what we have attempted to do with the CCIE Voice Deep Dive self-paced Class on Demand series – that is to bring the human instructional voice element to infuse deeper meaning to what is already fantastic Cisco Documentation. Anyone that has set out and determined to undertake the task of studying for and ultimately passing any CCIE Lab exam, knows that at some point during your studies, the words on paper (Cisco Docs, RFCs, books) – while a absolute phenomenal source of information – can at times seem to loose their impact. Perhaps you have been studying too long, read one too many docs, have the time pressure of your family and friends waiting for you to return to be a part of their life, or perhaps you are just starting out on your adventure and don’t know where to begin. Whatever stage you are at or whatever the case may be, it is certainly helpful to have a tutor and mentor there beside you at times, assisting you in understanding what each complex technology’s documentation is trying to teach you, in possibly a deeper and more insightful way than you can manage on your own.

For each complex topic we have held (or will soon hold) an online class where we dive down deep and explore all the concepts, practical application, and troubleshooting associated with each technology topic. The general format for each Class-on-Demand Deep Dive module spends between 4-7 hours on the given topic for that day, and during that time follows this outlined training methodology:

• Collectively discuss and teach all concepts involved in the technology
• Whiteboard concepts to further deepen every participant’s understanding
• Define a specific set of tasks to be accomplished
• Demonstrate how the tasks and concepts are implemented and properly configured
• Test the configuration thoroughly
• Vary the configuration to understand how different permutations effect the outcome
• Debug and trace the working configuration to understand what should be seen
• Break the configuration and troubleshoot with debugs and traces to contrast from the working set

Before we go on with the 21 module outline, here are a few demos of this Deep Dive series:

Demo 1: Module 10 :: Dial Plan :: Globalization Prezi - Theory and Reasons :: Runtime 1 hr

Demo 2: Module 10 :: Dial Plan :: Inbound Calling Party Localization :: Runtime 30 mins

Demo 3: Module 12 :: CUBE :: Conforming to ITSP Reqs: SIP Header Conversions :: Runtime 51 mins

Demo 4: Module 13 :: Unified Mobility :: Mobile Connect Access Lists and Exclusivity :: Runtime 20 mins

Try these questions on for size! Learn all this and much more in the new QoS class - woohoo!

1. Based on the following configuration, what traffic will be policed?

class-map C_MUSIC

  match protocol kazaa2

  match protocol napster

!

class-map match-any C_WEB

  match protocol http

  match class-map C_MUSIC

!

policy-map P_WEB

  class C_WEB

    police 64000

!

interface serial 0/0

  service-policy output P_WEB

A. All Kazaa version 2 traffic is policed

B. All Napster traffic is policed

C. All web traffic is policed

D. All Kazaa version 2, Napster, and web traffic is policed

E. No traffic is policed

2. You are configuring a Cisco Catalyst 3560 switch port to trust CoS markings if, and only if, the marking originated from a Cisco IP Phone. In an attempt to perform this configuration, you enter the mls qos trust device cisco-phone command. However, your configuration does not seem to be working properly. Why is the switch not trusting CoS markings coming from an attached Cisco IP Phone?

A. A Cisco Catalyst 2950 switch supports the mls qos trust device cisco-phone command, but the Cisco Catalyst 3560 does not support this command

B. The mls qos trust cos command is missing

C. The mls qos trust extend command is missing

D. The mls qos cos 5 command is missing

E. The PC attached to the phone is overriding the CoS markings

We know from the 5-Day QoS bootcamp that Differentiated Services is one of the three major overall approaches to providing Quality of Service in an enterprise. The other options are Integrated Services and Best Effort.

When we studied Differentiated Services, we saw that the primary marking technology approach was the Differentiated Services Code Point (DSCP) concept. These are the high order 6 bits in the IP packet ToS Byte. But how can MPLS use these markings in order to provide QoS treatment (Per Hop Behaviors (PHBs)) to various traffic forms?

The first major issue to solve is the fact that Label Switch Routers (LSRs) rely solely on the MPLS header when making forwarding decisions. These devices will no longer analyze the IP Header information, thus negating the use of the ToS Byte. This was solved through the creation of the Experimental Bits field  in the MPLS header. The IETF has now renamed the field to the Traffic Class field.  See RFC 5462.

In this short blog post, we are going to give condensed overview of the four main flavors of Frame-Relay Traffic Shaping (FRTS). Historically, as IOS evolved with time, different methods have been introduced, having various level of feature support. Two main features, specific to Frame-Relay Traffic-Shaping are per-VC shaping and queueing and adaptive shaping in response to Frame-Rleay congestion notifications (e.g. BECNs). You'll see that not every flavor supports these two features. We begin with the «fossil» known as Generic Traffic Shaping.

Generic Traffic Shaping

This feature was initially designed to shape packet traffic sent over any media, be it Ethernet, Frame-Relay, PPP etc. The command syntax is traffic-shape {rate|group} and allows specifying traffic scope using an access-list (notice that different ACL types are supported). You may tune the Bc/Be values as well as the shaping queue depth (amount of buffers). If the shaper delays traffic, the queue service strategy would be fixed to WFQ with the queue size equal to the buffer space allocated. Additional WFQ parameters such as number of flows and congestive discard threshold could not be tuned and set based on the shaper rate automatically.

An unique feature of GTS is the ability to apply multiple shapers to a single interface. However, shapers are not cascaded, but rather a packet is assigned to the first matching shaper rule. In the example below, there are three rules, with the last one being "fallback", matching all packets that didn't match access-lists 100 and 101. Unlike using the legacy CAR feature (rate-limit command) you cannot «cascade» multiple traffic-shape statements on the same interface, i.e. there is no "continue" action.

traffic-shape group 100 128000

traffic-shape group 101 64000

traffic-shape group 199 256000

!

access-list 199 permit ip any any