Free Streaming CCNA Voice Bootcamp from INE

I got today a newsletter from INE announcing a freebie. You have it below. Enjoy!

Free Streaming of our NEW
CCNA Voice Bootcamp Course!

FOR A LIMITED TIME until March 31st, 2012, get FREE streaming
of the NEW CCNA Voice Bootcamp Course with CCIEx2 #14073
Mark Snow when you become a member with INE!
Registration today for free!

The CCNA Voice class is an ultimate all-in-one solution for engineers pursuing the Cisco Certified Network Associate Voice (CCNA Voice) certification. This Video-on-Demand course includes over 25 hours of instructor-led content that will fully prepare you for the latest Cisco 640-461 ICOMM v8 certification exam. Please note that per Cisco CCNA Voice certification requirements, you need to have already met the pre-requisite of having a valid regular CCNA (Routing & Switching) status. View this course on your desktop computer, iPhone®, iPad® or other .mov video file format compatible devices. Learn more »

Click Here to register for your free account with INE to receive your FREE access to the ALL NEW CCNA Voice Bootcamp Course!

Cisco: Prioritize Voice traffic with LLQ



In one of my previous posts I was explaining how to mark packets closer to network edge. Starting from that point, we are sure the packets are market with the correct value, so on the router device we can directly match those packets and prioritize using Low Latency Queueing.

I believe you already know why queueing is so important for Voice packet especially, but also for all other kind of real time protocol (e.g. Video over IP), but just a small reminder. Most of the interfaces are using FIFO method for queuing. This is the most basic queue method and as you probably know means First In First Out. In human terms, first packet how arrive on the interface will be send first. Nothing wrong with this theory until this point and I can assure you that most of the time you don’t have to do anything to improve this technique. But what if you have real time protocols (e.g. voip services) and data transfer over the same physical interface? With FIFO the packets are sent out the interface as they arrive, but this is not very good for the delay sensitive traffic like voice. If a TCP packet in HTTP flow can wait it’s turn to be sent out, with not visible impact for user, than a delayed voice packet will cause deprecation in voice call.

With this problems need to be solved we arrive at LLQ, which is an ehanced version of Priority Queueing (PQ) in a Class-Based Weighted Fair Queueing (CBWFQ).

Before we start let’s have a look to the topology we will use (the same like in Cisco: Mark voice packets at the network edge post):

After marking the packets on the Access Switch,now we want to prioritize voice packets on the core router:

1) Match packets market with EF in a class-map

class-map VOICE
match dscp 46

2) Configure a policy-map unde which you match the traffic in the class-map VOICE and enable LLQ. The parameter “priority” is the one telling policy-map to enable priority queueing under that class. The value after the “priority” keyword can be a value in kbps or percentage from the total bandwidth. In the example below I assume that I have a 10Mbps bandwidth and I’ll configure LLQ class to use 10% from it, meaning 1000kbps

policy-map MYPOLICY
class VOICE
priority 1000

or with percentage

policy-map MYPOLICY
class VOICE
priority percent 10

I have to tell you that after the bandwidth or percent value you can add a burst value in bytes. If you don’t add this value, it will be calculated automatically. I chose this method when I’m doing simple config, but if you want to fine tune the values you can calculate it yourself and add it. Be careful that a higher value will influence the Tc value in the process.

3) Apply the policy to the WAN interface of the Core router (I assumed that the Core router is your direct connection to provider backbone) direction outbound. You cannot apply this type of queueing direction inbound. Keep this in mind.

interface s0/0
service-policy output MYPOLICY

If you insist on applying it inbound, you’ll get an error message:

Core(config-if)#service-policy input MYPOLICY
Low Latency Queueing feature not supported in input policy.

To check that your queueing policy is applied:

show policy-map interface s0/0

Service-policy output: MYPOLICY

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: EF
Priority: 10% (1000 kbps), burst bytes 25000, b/w exceed drops: 0

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Core Knowledge Questions for All CCIE Labs

Important change in all CCIE labs exams. Finally the attendees for CCIE RS Lab will now feel discriminated by the Core Knowledge Questions, as starting with next year, this will become mandatory for all CCIE Lab exams.

Interesting is that they say for all CCIE Labs exam, but below the Security and Voice exams are not specified…

See below the official announcement:

Effective January 4, 2010, the Cisco CCIE® Service Provider, Storage, and Wireless lab exams will add a new type of question format in a section called Core Knowledge. In this new section, candidates will be asked a series of four open-ended questions that require a short written response to be entered into the computer, typically several words. The questions will be randomly drawn from a pool of questions on topics eligible for testing. Candidates can review the topics by visiting the CCIE track information on Cisco.com or the Cisco Learning Network. No new topics are being added as a result of this change.

Candidates will have up to 30 minutes to complete the Core Knowledge section and may not return to it once they have moved on. A passing score on the Core Knowledge section is required to achieve certification. Core Knowledge questions were implemented on Routing and Switching labs in February 2009 and Security labs in June 2009, and allow Cisco to maintain strong exam security and ensure that only qualified candidates are awarded CCIE certification. Candidates with exam dates on January 4, 2010 or later should expect to see the new question format on their lab exam.

Cisco AutoQoS VoIP

QoS – one of the most interesting and challenging part of the network engineer’s life. I think I’m not wrong when I’m saying that most engineers that hear the word QoS, react somehow like “ah, that ugly stuff…” I have to be honest and say that QoS is not one of my preferred part, but as a network engineer you have to accomplish all task, not only the one that you like. With QoS you can achieve some great results, and once you have started to work with it, you’ll see that is not such a monster. The idea that QoS is not a friendly topic was develop due to historical ways to configure this service. In fact there were so many ways that without working with this topic everyday, you have no chance to remember how has to be implemented. Even among Cisco devices, there were multiple way to configure QoS from device to device. Nowadays Cisco is putting a lot of effort to standardize the implementation of QoS and in the same time to simplify it.

In this context AutoQoS appeared. First, AutoQoS VoIP was developed as the more QoS configuration is needed for Voice traffic over the network and then a more complex Auto QoS Enterprise was released. Today I plan to speak a little bit about AutoQoS VoIP and in one of the future articles about the Enterprise edition.

AutoQoS VoIP gives you the ability to deploy QoS features for converged IP telephony and data networks in a fast and reliable way, by simplifying the MQC (Modular QoS command-line interface). AutoQoS VoIP generate automatically traffic classes and policy map CLI templates. In more human terms, if AutoQoS VoIP is configured on an interface, the traffic that is passing by is receiving the required QoS treatment automatically. By doing this automatically AutoQoS spares you from having in-depth knowledge about the services policies, link  efficiency mechanism or best practice for Voice QoS. Everything is done by AutoQoS, which automatically discovers applications and provides appropriate QoS treatment, generate policies and provide configuration.

Of course that are some drawbacks like in any other technology, but this can be easy overcome if you have some knowledge about QoS configuration. It theory everything should run smoothly, but in real environment, you run into the situation that QoS should be fine tuned to reach the level of your expectation. This is easy done with AutoQoS, as after it enable and configure the QoS templates, you can easy configure them to fine tune parameters, add or delete policies. Basically you start from nice template, sourced by AutoQoS, and develop your own QoS. As I said before, you have only to do this is something is not working or if you feel the strong attraction to “make it your own way”.

AutoQoS VoIP is supported on the most popular Cisco routers and switches platform with the appropriate IOS or CatOS image. Before you configure AutoQoS VoIP you should know that:

– CEF is required to be configured, as AutoQoS use NBAR (Network-Based Application Recognition) which is based on Cisco Express Forwarding
– no QoS Policies are attached on the interface on which you are configuring AutoQoS
– correct bandwidth has to be configured on the interface; if there is no bandwidth statement, then this defaults to 1544 Mbps, which is not all the time accurate

Now a tricky part in regards to interface bandwidth. If this is 768kbps or below, you have to configure an IP address on the interface due to the fact the AutoQoS is enabling by default Multilink PPP and copy the  configured IP under the multilink interface. If you configure AutoQoS on a remote site, and the 768kbps (or lower) interface is the only connection there, please pay attention as configuring AutoQoS Voip may break your connection due to MLP situation explained above.

Another recommendation from Cisco and me, is that you should use no auto qos voip command when you stop using the interface on which AutoQoS VoIP is configured. In this way you assure that all the QoS configuration will be removed. If you just shutdown the interface or delete the PVC, without the above command, then the AutoQoS VoIP will not be completely removed.

Configuration is very simple:

router# configure terminal
router(config)# interface Serial x/y
router(config-if)# bandwidth 1540
router(config-if)# auto qos voip
router(config-if)# exit

I tried to put together a scenario like in the following topology, to generate some traffic and show you have AutoQoS behave when configuring policies:

Cisco AutoQoS VoIP topology

After applying the AutoQoS config you should see something like this in your running-config:

class-map match-any AutoQoS-VoIP-Remark
match ip dscp ef
match ip dscp cs3
match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
match protocol rtp audio
match access-group name AutoQoS-VoIP-RTCP
!
!
policy-map AutoQoS-Policy-UnTrust
class AutoQoS-VoIP-RTP-UnTrust
priority percent 70
set dscp ef
class AutoQoS-VoIP-Control-UnTrust
bandwidth percent 5
set dscp af31
class AutoQoS-VoIP-Remark
set dscp default
class class-default
fair-queue
!
ip access-list extended AutoQoS-VoIP-Control
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
permit udp any any range 16384 32767

I will try to generate some traffic between this, so called, voice server and client and to let AutoQoS  VoIP do it’s job and configure automatically traffic flow policies.

Below you have a video tutorial about AutoQoS VoIP has to be configured and some monitoring commands that will output the result of traffic flow:

cisco-autoqos-voip

Cisco certification: Important content change in CCIE Voice Lab Exam

This announcement is from The Cisco Learning Network:

Effective July 16th, 2009, important content changes will be implemented in the CCIE Voice Lab Exam. Candidates for lab exams scheduled July 16th, 2009 or later should prepare using the v3.0 Lab Equipment and Software Versions. Candidates scheduled on or before July 15th, 2009 should continue using the v2.0 Lab Equipment and Software Versions.

You can examine the v3.0 CCIE Voice Lab print below:

1.00 Implement and Troubleshoot Campus Infrastructure and Services
1.01 VLAN
1.02 DHCP
1.03 TFTP
1.04 NTP
2.00 Implement and Troubleshoot CUCM Endpoints
2.01 CUCM SCCP Endpoints
2.02 CUCM SIP Endpoints
3.00 Implement and Troubleshoot CUCME Endpoints
3.01 CUCME SCCP Endpoints
3.02 CUCME SIP Endpoints
4.00 Implement and Troubleshoot Voice Gateways
4.01 T1/E1 PRI
4.02 T1/E1 CAS
4.03 H.323
4.04 MGCP
4.05 SIP
4.06 H.323 RAS
4.07 IP-IP Gateway/CUBE
5.00 Implement and Troubleshoot Call Routing Policies
5.01 Route Patterns and Dial-peers
5.02 Digit Manipulations and Translations
5.03 Class of Services
5.04 Route Selection Preference and Redundancy
5.05 Mobility and Single Number Reach
6.00 Implement and Troubleshoot High Availability Features
6.01 SRST
6.02 AAR
7.00 Implement and Troubleshoot Media Resources
7.01 CODEC Selection and Flexibility
7.02 Conference Bridges
7.03 Transcoder
7.04 Music-on-hold
7.05 Media Resources Preference and Redundancy
7.06 Other CUCM Media Resources
8.00 Implement and Troubleshoot Supplementary Services
8.01 Call Park
8.02 Call Pickup
8.03 Barge
8.04 Callback
8.05 Other Supplementary Services
9.00 Implement and Troubleshoot Other CUCM Voice Applications
9.01 Extension Mobility
9.02 IPMA
9.03 Other CUCM Voice Applications
10.00 Implement and Troubleshoot QoS and CAC
10.01 L2/L3 Traffic Classifications and Policing
10.02 L2/L3 Queuing Mechanisms
10.03 L2 LFI
10.04 RSVP
10.05 Call Admission Control
11.00 Implement and Troubleshoot Messaging
11.01 Cisco Unity Connection
11.02 Cisco Unity Express
11.03 Call Handling and Routing
12.00 Implement and Troubleshoot Cisco Unified Contact Center Express
12.01 Advanced Configuration
12.02 Script Customization
12.03 Redundancy
13.00 Implement and Troubleshoot Cisco Unified Presence
13.01 CUCM Presence
13.02 Cisco Unified Presence Server Integration



Please read more on cisco.com