Posts from ‘QoS’
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.
Continue Reading
Tags: ccie qos, frame-relay traffic shaping, srTCM, traffic contract, traffic policing, trTCM
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.
Tags: catalyst, catalyst-qos
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]).
Continue Reading
Tags: bandwidth, cbr, circuit-switching, llq, over-provisioning, packet-switching, priority-queue, psn, QoS, voip
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
Answer:
C
Explanation:
The C_MUSIC class-map does not specify the match-any or match-all option. The default is match-all. Therefore, for traffic to be classified in the C_MUSIC class-map, a packet would simultaneously have to be a Kazaa version 2 packet and a Napster packet, which isn’t possible.
The C_WEB class-map uses the match-any option, meaning that traffic will be classified in this class-map if it is HTTP traffic or if it is traffic that was classified in the C_MUSIC class-map. Since, no traffic will be classified in the C_MUSIC class-map, as described above, the only traffic that will be classified by the C_WEB class-map is HTTP traffic.
The policy-map P_WEB is configured to police (i.e. rate limit) traffic classified by the C_WEB class-map to a bandwidth of 64 kbps. (NOTE: The default conform-action is transmit, and the default exceed-action is drop.) Since only HTTP (i.e. web) traffic is matched by the C_WEB class-map, web traffic is the only traffic that is policed. Continue Reading
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
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
Tags: Frame-Relay, QoS, traffic-shaping
Fans of the wildly popular CCIE Written Bootcamp need to check out Practice Exam 2 which has been updated with some more thought-provoking Quality of Service (QoS) questions that will help with the CCIE R&S Written as well as the Lab exam.
For some fun for all, try this question on for size:
Match the QoS marking with the correct definition:
QoS Marking
1. DSCP EF
2. DSCP 20
3. IP PREC 5
4. DE
5. CLP
6. EXP BITS
Definition
a. ATM
b.Diff Serv VoIP
c. Frame Relay
d. MPLS
e.Legacy VoIP Marking
f. Assured Forwarding 22
The answer is posted in the comments. Enjoy.
This blog post is taken from the INE Resources area Understanding Frame-Relay Traffic Shaping presentation by Brian Dennis.
Overview
Frame-Relay traffic shaping is designed to control the amount of traffic the router sends out of an interface or out of a particular DLCI. Common reasons for Frame-Relay traffic shaping are:
- It allows the router to conform to the rate subscribed with the service provider
- It allows for the throttling of a higher speed site (768K) so that it does not overrun a lower speed site (64K)
Traffic shaping is designed to delay excess traffic, whereas policing is designed to drop excess traffic.
Terminology
- Available Rate (AR) – the actual physical speed of the interface; on a DCE serial interface this is determined by the configured clock rate. On a DTE serial interface, it is determined by the received clock rate. A router will always (by default) try to send out at the AR regardless of the interface bandwidth. AR is also commonly referred to as port speed, line rate, or access rate.
Many people have problems understanding the meaning of Bc (committed burst) used with traffic policing. Everyone seems to know the “magic” formula (Bc=1,5sec*CIR) but have a vague understanding of the reasons behind it. Let’s clear the confusion and see what Bc really affects when it comes to policing.
Averaging and Smoothing
Imagine you’re driving a car and want to find out your speed. In order to do this, you need to count the time (T) it takes you to pass the distance (S). The speed is then V=S/T – what a nice looking elementary school formula. So if you drove 100 miles in 1 hour your speed is 100 Mph. However, if you drove 50 miles in 30 minutes, your speed is the same 100 Mph. The only difference between the two measurements is the time interval used. Ideally, the only real value is your instant speed defined as the limit of S/T with T going to zero. However, this only works well in mathematics – in the real world, you always need a finite time interval to perform the measurement.
Continue Reading
Tags: ccie, QoS, traffic policing
Hello everyone! We want your feedback on changes to this product sent to: asequeira@ine.com
Here is what we are going to do for sure:
- Replace rote memorization questions with newer, more accurate questions for the actual Core Knowledge Section.
Here is what we are proposing or at least thinking about 
:
- Eliminate all computer grading and move to self-graded questions.
- Organize questions by topic area of the blueprint.
We look forward to your feedback on these proposed changes – or anything else you want done.
Happy studying everyone!
