Posts from ‘QoS’
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.
traffic-shape group 100 128000 traffic-shape group 101 64000 traffic-shape rate 256000
Tags: Frame-Relay, QoS, traffic-shaping
As you know, purchasers of the new INE 5-day QoS bootcamp receive the class in four different modalities. There is the interactive self-paced version, the live class, the recorded live class, and an audio bootcamp.
If you would like to check out a sample lesson of the audio bootcamp, tune into W-INE Internet radio, or visit the course’s Samples page. The lesson is also going to appear on our iTunes podcast channel by Saturday, May 22, 2010. Just search the iTunes store for INE.
Enjoy, and I look forward to “seeing you” in class soon.
Fans of the wildly popular CCIE Written Bootcamp by Anthony Sequeira 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!
The QoS section for our new CCIE Routing & Switching Lab Workbook Volume 1 Version 5 is now completed and posted on the members site! In its completed format this document consists of over 80 sections and totals nearly 500 pages. This is by far the most complete single resource I have ever seen for QoS on Cisco IOS. Special thanks to Petr Lapukhov for his intense research and unparalleled expertise in the development of this topic area. The following sections are now available in QoS:
- Hold-Queue and Tx-Ring
- Weighted Fair Queuing (WFQ)
- Legacy RTP Reserved Queue
- Legacy RTP Prioritization
- Legacy Custom Queueing
More sections have been posted to the IEWB-RS Volume 1 Version 5 section for QoS. The following topics are now available.
10.1 Hold-Queue and Tx-Ring
10.2 Weighted Fair Queuing (WFQ)
10.3 Legacy RTP Reserved Queue
10.4 Legacy RTP Prioritization
10.5 Legacy Custom Queueing
10.6 Legacy Custom Queueing with Prioritization
10.7 Legacy Priority Queueing
10.8 Legacy Random Early Detection
10.9 Legacy Flow-Based Random Early Detection
10.10 Selective Packet Discard
10.11 Payload Compression on Serial Links
10.12 Generic TCP/UDP Header Compression
10.13 MLP Link Fragmentation and Interleaving
10.14 Legacy Generic Traffic Shaping
10.15 Legacy CAR for Admission Control
10.16 Oversubscription with Legacy CAR and WFQ
10.17 Legacy CAR for Rate Limiting
10.18 Legacy CAR Access-Lists
10.19 Legacy GTS for Frame Relay
10.20 Legacy Frame Relay Traffic Shaping
10.21 Legacy Adaptive FRTS
10.22 Legacy FRTS with Per-VC WFQ
10.23 Legacy FRTS with Per-VC PQ
10.24 Legacy FRTS with Per-VC CQ
10.25 Legacy FRTS with Per-VC Fragmentation
10.26 Legacy FRTS with Per-VC IP RTP Priority
10.27 Frame-Relay RTP/TCP Header Compression
10.28 Frame-Relay Broadcast Queue
10.29 Frame-Relay DE Marking
10.30 Legacy FRTS PVC Interface Priority Queue
10.31 Frame-Relay Priority to DLCI Mapping
10.32 Frame-Relay Traffic Policing & Congestion Mgmt
10.33 MQC Classification and Marking
10.34 MQC Bandwidth Reservations and CBWFQ
10.35 MQC Bandwidth Percent
10.36 MQC LLQ and Remaining Bandwidth Reservations
10.37 MQC WRED
10.38 MQC Dynamic Flows and WRED
10.39 MQC WRED with ECN
More OSPF topics will be posted later tonight in anticipation of tomorrow’s Open Lecture Series on Advanced OSPF Design. Hope to see you there!
