Archive for June, 2008
The CCIE Voice lab is unique in the sense that it requires you to configure diverse number of applications sharing little in common with each other. For example, you will have to use GUI to configure Call Manager and CLI to configure SRST. On top of that, it’s hard to break the Voice lab into “core” and “non-core” parts, since you are required to configure a lot of different things (e.g. register phones, add gateways, set up dial-plan, configure dial-peers) in order to place an end-to-end call and test “connectivity”. All that makes the Voice lab tougher than any other CCIE lab.
Lab Strategy Overview
Generally, we can subdivide strategy into the following sections:
I) Order of Operations. The way you want to follow through configuring the lab. Almost certainly you dont want to configure tasks in linear, sequential fashion, as it is not the fastest way possible. Speed is number one priority in any CCIE exam, and it’s especially vital in the Voice lab.
II) Time Management. The thing you definitely need to control is the amount of time you spend on each task. While this part seems so obvious, most people cant resist the urge to troubleshoot one single task for “another five minutes”. “Don’t get stuck!” should be your motto here.
III) Stress Management. Huge stress is what differentiates the real lab exam from any practice lab you’ve done. Remember, stress is your enemy and your friend at the same time – it boosts your strengths and concentration but makes you flaky. Take in account the impact of stress on your accuracy and speed.
IV) Dealing with wildcard scenarios. You cant possible learn all the voice technologies out there. So there is still a chance you can meet something scary and unfamiliar (or simply badly worded) in your real lab. Or maybe, you would face a rack or initial configuration issue. All this has to deal a lot with sections (II) and (III) of the strategy, but you should be prepared to meet the unexpected. Never panic, and try to isolate the wildcard situation as soon as possible.
V) Verifications. Many people believe they dont need a verification plan, as the verification ideas will come out by themselves. Basically if they see something working, they become assured it would last till the end of the exam. Do not make this mistake, and develop a thorough verification plan for your solutions, as stress and time can play bad jokes with you.
Lab Exam Topics Outline.
Before coming up with an order of operations, let’s make a short outline of the current (2008) CCIE Voice lab exam:
I) Infrastructure. Voice & Data VLANs, switchports. DHCP for IP address allocation, NTP for time synchronization. Other advanced tasks, pertaining to switching infrastructure (e.g. DHCP snooping).
II) Station Devices. Register ephones with CME and assign extensions. Auto-register IP and Analog endpoints with the CallManager and assign extension numbers. Phones Presentation settings (display layout, softkeys, buttons, calling number masks). Users and Directory Services.
III) Gateways & Trunks. Configure ISDN PRI settings in the routers. Register MGCP gateways (analog/digital PRI backhaul). H.323 gateways and Gatekeeper. Gatekeeper registration. SIP Trunk and IP to IP gateway.
IV) Call Routing. Plan the dialing patterns and Classes of Restriction. Create Partitions and CSSes in the CallManager, Route Groups and Route Lists. Call Hunting Constructs in CCM and CME.
V) CAC & Codecs. Regions, Locations, Gatekeeper admission, dial-peer settings, voice-class, CCM global codec settings, DTMF-relay.
VI) Media Resources. Registering NM-HDV/NM-HDV2/6608 with the CallManager. Transcoders and Conference Bridges. Software Media Resources. Music on Hold Servers, Multicast Music on Hold. Media Resource Groups and Lists, order of allocation.
VII) Applications & Services. Call Forward/Transfer, Park/Pickup/Extended Functions. Cisco IP Phone Services. IPMA (Proxy/Shared), Attendant Console, Extension Mobility. B-ACD for CME.
VIII) High Availability. AAR and SRST. HSRP/VRRP (advanced topics). Call Backup.
IX) QoS. FRTS (legacy/MQC) and CBWFQ. Link Efficiency: FRF.12 and MLPPPoFR, cRTP. LAN QoS: Classification/Policing and Marking. WRR and PQ. Marking in the gateways (IOS, ATA, VG248).
X) Voice Mail. Unity integration with CCM/CME via SCCP. CUE Integration with CME via SIP. Unity Subscribers, CallHandler, CallRouting, Schedule, Recording. CUE Groups and Subscribers, AvT. Redirecting Calls to a Voicemail system.
XI) CRS. Integration with CCM. ICD Script customization, CRS Editor.
Order of Operations
The most import part of you plan – essentially this is the core of your strategy.
Step 1: Planning (20 – 25 mins)
It’s the beginning of your lab exam. You are probably all excited and nervous, and open your lab workbook. Take a couple of deep breaths and locate the lab diagrams. You will probably have a topology diagram and supplementary drawings/tables describing your connectivity and PSTN/WAN settings. Redraw the major diagram real quick – you will enhance your drawings as you read through the lab after that. Also, drawing will probably calm you down a little bit. Next start with reading through the whole lab. You heard that before, now it’s time to hear it again Do not underestimate the importance of reading the lab as a whole. This will give you all the connections between the tasks, and probably insights on possible issues.
As you read through the lab, locate the following information and put it on your diagram: Extension Numbers, Site DID patterns, WAN settings (CIRs, port speeds), IP addressing (servers, loopbacks, voice vlan subnets). Dont spend too much time on the Call Routing/Dialplan sections for the CallManager, and don’t stick with analyzing advanced Call Routing tasks like call backup, TEHO etc. However, locate the dialing pattern for CallManager Express and SRST systems (if you have them in your lab). Spot whether you will need a gatekeeper in your configuration, and whether it’s a backbone device you your internal pod router.
Using “show cdp neighbor” command verify that you see all your IP Phones. Record the last four digits of each MAC address and draw it next to the respective phone on your diagram. At the same time, perform a quick connectivity test to ensure your equipment is set up properly, and you can reach the CallManager and Unity servers.
As you finished with reading over, unbind the paper sheets, and re-arrange them in the order you find comfortable.
Step 2: IOS and CLI configurations (1,5 – 2 hours)
This is the part where you configure all IOS-relevant applications, starting with infrastructure and finishing with CME/CUE and SRST (if needed). As much as you can, try to type all your configurations in notepad first and than paste into command line. This requires a lot of practice, but it really worth it. Remember to use consistent names: I recommend using all uppercase separated by underscores like “class-map VOICE_BEARER”.
Start with configure VLANs and switchports, DHCP servers (IOS/Windows) and NTP. Ensure all devices obtain IP addresses (check the DHCP bindings) and are pingable (A small side-step will be required to configure Windows DHCP server, but it’s OK). Set up NTP if required, and synchronize the CallManager time if they ask for that. Ensure your time is synchronized. If you get some small issues like devices not getting IP addresses, don’t spend more than 5 minutes trying to troubleshoot it. Take note if it fails, and go on.
Multicast & QoS
Configure multicast routing if needed for multicast MoH later. Verify multicasting by joining groups on routers and pinging end-to-end. Configure FRTS and CBWFQ in routers per the requirement of your QoS section. If you have LAN QoS requirements, apply the most basic configs here (trusting, basic CoS->DSCP remarking) but don’t spend a lot of time coping, editing and pasting long crazy QoS configurations from the DocCD here. You can do that later in the exam if you have enough time, and your goal right now is speed. If you really hate LAN QoS, just disable “mls qos” and move on here. It wont probably cost you many points, but will win you a lot of time and nerves.
CallManager Express and CUE
You first big task. Set up CallManager Express phones – register them and configure buttons/layout/call-forwarding/transferring. Set up all necessary telephony-service settings here (dialplan-pattern if needed, time-zone, etc) . Set up the basic dial-plan to reach PSTN destinations. Call between PSTN phone and CME Phones to validate your configuration. If you have any other tasks in your lab pertaining CME (like B-ACD, call-hunting, local-directory etc) do them all here.
If required by the lab, reset the CUE module, and perform integration with the CallManager Express system. Don’t forget to enable HTTP server in the CME and perform the CUE web-init dialog. Create subscribers and complete advanced CUE tasks. Take care if they ask you to route VoIP calls to CUE, as you will need the transcoder registered with the CME.
SRST, PVDMs, Gatekeeper and MGCP PRI backhaul
If required by your scenario, configure all MGCP PRI backhaul in IOS routers right now. Although you will configure gateways in the CallManager later, it makes sense to complete all IOS stuff right now. Configure NM-HDV to register with the CallManager if your scenario requires this as well.
If you they ask you to do SRST, configure the respective router. Set up everything, including the dialplan and incoming calls handling for SRST. Verify SRST to CME calling by using “csim start” command in SRST and “debug isdn q931” command in both CME and SRST systems.
If you need to set up a gatekeeper in a routers inside your pod, and/or register with a backbone gatekeeper, do it now as well. If needed, register CME system with the gatekeeper too. Use “debug h225 asn1” for advanced debugging.
When you’re done with Step 2, you should have almost all IOS parts configured. Endpoints obtained IP addresses, switches impose marking, CME/CUE integration works and you should be able to test basic calling. By now you probably have 30mins-1hour gap before the lunch break.
Step 3: CallManager Setup (1 hour)
Follow the Top-Down, Left-to-Right approach with the CallManager set up.
You should already know your time-zone, presentation settings, regions, locations and device pool requirements. Start by configuring the CCM servers, replacing names with IP addresses everywhere, adding regions, AAR groups, locations (if required). Always rename the default entities (like default Date/Time Group, default Device pool) and re-use them. Try to stick with consistent naming scheme mentioned above. For example, use “DP_HQ, DP_BR1” names for device pools, “REG_HQ”, “REG_BR1” for regions, “LOC_HQ” for locations etc. Make the names self-explaining and keep the number of device pools minimal. As you’ve done with “System” settings, start the CallManager services, if they are not started already. Ensure you don’t start unnecessary services, like IPMA/EM, if they are not mentioned in your scenario. Less services means less worries!
As you finished with basic system settings, proceed to media resources configuration. Configure the software media resources first. Ensure you set the proper codec’s for MoH and assigned a location/device pool to MoH servers. You may need a separate device pool for MoH servers to control codec’s precisely. Set up Multicast MoH settings in servers and sources. Ensure you have Annunciators and MTPs running on both servers. As you’ve finished with the Software Resources, proceed to transcoders and conference bridge registration. Add the respective devices that you probably already configured in the IOS systems. Complete your Media Resources configuration by creating MRGs and MRGLs and assigning the latter to device pools created before.
Gateways and Trunks
Before you start this section, create a partition for all internal extensions (e.g. “PT_INTERNAL”) and a default CSS for each site. Default CSS is the one which will be mostly used by your respective site internal devices. Give it a name like (“CSS_HQ_DEFAULT” or “CSS_BR1_DEFAULT”). Now proceed with creating gateways in the CallManager (H.323, MGCP, SIP). Assign a proper device pool, incoming CSS and other settings per your PSTN requirements. If you have a gatekeeper in your scenario, add a gatekeeper to the CallManager and create a Gatekeeper-controlled Trunk. Ensure the CallManager registers with the Gatekeeper.
Station Devices & Users
If needed, create new softkey template and button template before you start with the phones. Then, perform auto-registration for all IP and Analog Endpoints. This is probably the most time-consuming section, which requires a lot of accuracy. Pickup up the default CSS, Partition and External Phone Number Mask for auto-registration carefully, to minimize the number of changes later. Ensure all your endpoints registered (you may need to lift handsets on the VG248 devices or switch it to manual enable mode). List all the phones registered with the CallManager and configure them all, starting with VG248 and ATA186 phones, since they are easy to spot on the screen. For all other phones, use your diagram with the last 4 digits of the MAC addresses to spot the phones. Don’t forget to set up Display ID, External Phone Number Mask, AAR Group, AAR CSS, Softkey/Button template, Directory Number, etc. As you’ve done, check the phones layout and try calling between phones real quick.
After that, create users in Global Directory (if needed) and associate them as required per your lab scenario. To finish with basic verifications, call internal phones from the PSTN phone. Do not attempt to configure any advanced CallManager applications here
Step 4: Unity Integration (20 – 30 minutes)
Set up Unity side first and then run the integration wizard in the CallManager. Ensure you can reach the Unity General Greeting. Take in account possible AAR requirements when configuring integration, as you should have AAR groups created already. Account for any subscribers calling from the PSTN. Create Subscribers (disable self-enrollment dialog, set simple password etc) per the requirements of your lab. Ensure you can send and receive messages, and MWI is working. Since Unity is usually simple, complete all other Unity tasks here as well (CallHandlers, Live Recording etc).
Step 5: CallManager Applications (20 – 30 minutes)
Configure IPMA, EM, AC and other CallManager application here, if required by your lab scenario. Remember you should start any advanced configuration only after you’ve done with all the basic configurations. Test your applications and assess the current situation. If you feel like you have enough time, proceed to IPCC Express Integration and script customization. If not, skip directly to Call Routing section.
Step 6: CRS/IPCCX (20 – 30 minutes)
IPCCX is not a big part of the lab exam, but it requires considerable amount of time to complete and verify. So start working on this part only if you are feeling sure about yourself and want to earn some “hard” points. Integrate IPCCX with the CallManager and verify the default script. You may want to configure IPPA single-sign on to ease the verification process. Skip the script part if you don’t know how to do it, just complete and verify that your integration is “IN_SERVICE”.
Step 7: Call Routing (40 minutes – 1 hour)
This is probably the next (after Auto-Registration) most time consuming part of the lab. To accomplish it, read the Call Routing section of the lab scenario now. Outline the dialing patterns, classes of restriction and corresponding partitions and Calling Search Spaces. Use consistent and self-explaining names like “PT_HQ_PSTN_DEFAULT”, “PT_BR1_PSTN_RESTRICTED” and “CSS_HQ_PREMIUM” to outline the classes of restriction used in your scenario. It’s useful to type all patterns and corresponding partitions in the notepad first, to get better understanding of the Call Routing. Take special care with respect to presentation settings (CLIDs, Calling Names) and other additional requirements.
Create route groups for all your gateways (e.g. “RG_HQ”, “RG_BR1” etc) and a route-list for each type of call-routing behavior. Again, stick with names which make sense, like “RL_HQ_INTL_GW_HQ_BAK_GW_BR1” – attempt an international call from HQ using the local gateway and using BR1 gateway as a backup. Create all your route-lists first, and design DDIs as required per your scenario. Prefer to implement DDIs inside Route Lists and not at pattern level.
Next, create the additional partitions required and start adding dialing patterns one by one. As you add each pattern, use “debug isdn q931” where possible to trace the paths your call is taking. Call the PSTN phone or any other site’s phone as appropriate to verify each pattern. Start with basic dialing (e.g. 911, Local calls) and end with more complex routing rules like TEHO and calls across the gatekeeper. Be very accurate with each pattern, since it doesn’t take much to make a mistake here. This is why it’s crucial to verify every piece while you progress.
You may also need to implement additional dialing rules in the IOS routers (e.g. in the CME system). Use the same step-by-step approach and verify every a new pattern as soon as you configure it.
You should be able to finish your lab in 5-6 hours and have about 2 hours to verify everything you’ve done. Now for verification part, you need to check the following
a) SRST & AAR
b) PSTN Phone can Call everyone
c) Every Phone adheres to it’s class of restriction
d) Calls between sites work
e) Voice Mail works (Unity and CUE)
f) Applications work (e.g. IPMA/EM, B-ACD etc)
g) Media Resources Work (MoH, Transcoding, Conferencing)
h) QoS Marking and Enforcement
i) Time synchronization and other infrastructure stuff
k) Redundancy: CCM Subscriber disabled, everything falls to the Publisher
Remember, it’s vital to have a clear verification plan in mind, as well as practice it during your preparations. As you progress with verifications, mark each section of the lab as “verified”. It never hurts to do verification twice, but be careful and don’t do any drastic changes to your configurations even if you think this should fix the situation. Always apply small changes – one change at time.
There is a lot of things to say about stress management. The idea is: there is no easy way to defeat stress and anxiety in the day of your lab, unless you are prepared to face the stress. Build your stress tolerance through the whole process of preparations. Observe strict day regiment, go to bed and wake up at the same time every day. Try not to work at nights, as this way is against your body physiology. Don’t forget regular physical exercises – if you cant afford everyday trainings, at least try to make short breaks during your work and get a walk around. Eat healthy food and avoid cold drinks and food that is hard to digest. All those things are plainly about physiology and body functions, but you’ll be surprised to see how much does it help. If feel like it, learn any meditation or relaxation technique (usually breathing exercises) – it really helps to deal with sleep issues and helps you combating anxiety. And last, but probably most important advice (quite obvious too) – the best thing to reduce stress in the day of the lab is to be well prepared..
The day before your lab, try to forget all your worries and relax. Get a life, walk around have fun – don’t think about your exam, just try to spend a good day. Try to walk a lot, to make your body physically tired. Do not take any sleeping pills the day before your lab, as they can affect you alertness the next day. This is the last day before your exam – there is nothing you can do to improve your skills now. You should have had plenty of time to do that in ahead
The day of the lab, try no to overload yourself with caffeine. It’s OK as long as you keep the amount reasonable, but can make you jittery if consumed in large amounts. Also, during the lunch, try to relax as much as possible and eat some warm, liquid food – it generally makes you feel energized.
It’s quite simple to understand, but hard to implement. Have a plan in your head; know the time you need to spend on each section, and execute you plan. Build a habit of not sticking with any task for more than 15 minutes, unless you’re doing a big and complex task like IPMA. But if you got something not working, don’t spend desperate minutes trying to troubleshoot it for 30 minutes. During the preparations, I found it really useful to run a widget playing chimes every 15 minutes – just to keep me on track. Another benefit of time management – seeing your lab progressing in accordance with the amount of time planned in advance generally helps you reduce the level of stress.
There are different types. First, and most harmless – you get an unfamiliar topic in the lab. Skip it the first time, and then refer to the DocCD if you have enough time left in the end of your lab. No big deal, unless you think most of the tasks are unfamiliar to you Usually that means you were preparing to a different exam. OK, so the next wildcard – hardware and software issues in your rack. This is a type of issue you should battle with proctor – just make sure those are real issues. If that didn’t help much – prepare a complain letter to Cisco, and ask for a free lab attempt – and it’s no joke! Proctor is yet another wildcard. They are merely humans, so you can’t expect 100% courteous service all the time; occasionally, you can meet an unhappy or unfriendly guy, so be prepared to use all your social skills. The last and most uncommon wildcard – some accidental situations like building fire or earthquake. But those are the things you need to worry less about.
The things you should probably take care of are unexpected issues with your health. Like a cold flu, or sudden headache, or something of that kind. Ensure you have minimal amount of medicine necessary to suppress pain and other unpleasant syndromes for the duration of the lab exam.
That was just a sample of a lab strategy. Remember, you goal is to come up with your own, personal strategy, that fits you best. There is no universal solution that fits everyone. But as long as you try to plan and approach your preparations systematically, you are on the right track. Good luck with your lab!
I ran into these nasty frame relay mappings during an initial lab set-up and was wondering why they are there, (even with inverse-arp disabled), and what they are actually doing. I was able to remove them only after writing my configuration to memory, and then performing a reload of the router.Router(config-if)#do show frame map Serial0/0 (up): ip 0.0.0.0 dlci 113(0x71,0x1C10) broadcast, CISCO, status defined, inactive Serial0/0 (up): ip 0.0.0.0 dlci 105(0x69,0x1890) broadcast, CISCO, status defined, active Serial0/0 (up): ip 0.0.0.0 dlci 104(0x68,0x1880) broadcast, CISCO, status defined, active Serial0/0 (up): ip 0.0.0.0 dlci 103(0x67,0x1870) broadcast, CISCO, status defined, active
This is actually an error relating to AutoInstall over Frame Relay. When the router boots up and does not have a configuration file saved in NVRAM, it attempts to run autoinstall to automatically find an IP address and download a config. The first thing the router does is to detect the encapsulation on its WAN interfaces, which in this case is Frame Relay. Once the router finds that it’s running Frame Relay, it attempts to send a config request via TFTP. In order to do this it needs an IP address, so it sends a BOOTP request out all DLCIs. Since the router doesn’t know what the unicast IP addresses are on the other ends of the circuits, it creates IPv4 mappings to 0.0.0.0 for all circuits and includes the “broadcast” keyword on them. This allows the router to encapsulate the BOOTP request out all DLCIs.
If you haven’t actually configured IP helper-address or a BOOTP server, the operation will fail. The result of this that we see is that when Frame Relay is re-enabled on the interfaces the mappings to 0.0.0.0 reappear. In some versions of IOS this can be fixed by removing Frame Relay and re-applying it, for example:
router#config t router(config)#interface s0/0 router(config-if)#encapsulation ppp router(config-if)#encapsulation frame-relay router(config-if)#end router#
In most versions however this does not work. Therefore the way to fix this is just to have the router not do autoinstall on bootup. Since the router does autoinstall because it doesn’t have a config saved in memory, the only way to 100% fix it is to save your config to NVRAM (wr m), and to reload.
If you are like me, you get network withdrawal if you’re away from the Internet for more than a few minutes at a time. Now thanks to the iWPhone WordPress Plugin you can read our CCIE Blog in an optimized formfor your iPhone or iPod Touch. Simply browse to http://blog.internetworkexpert.com from either of those devices and it will automatically be detected and reformatted.
Also for those of you that didn’t get a chance to join us in Orlando for Cisco Live 2008, the keynote address by John Chambers included a demo of Cisco’s new WebEx Connect, which, through the Unified Communication suite, is highly integrated with Apple’s iPhone now. You can take an IP call from WebEx, send it to your iPhone, and then “throw” the call to another user’s iPhone in the vicinity. You can view the video here of the demonstration.
Everyone has heard things about the CCDE Practical. And how it’s a flash-based, computer-based examination regarding design scenarios. Different people have different views about this. And we’ve seen a few opinions offered on different message boards already! Well, there was a demo of it in the Certifications Booth at Cisco Live (Networkers) this year! Hopefully you got a chance to wander back and see it!
So a couple different things to look at and think about here. Things were discussed during a breakout session about the CCDE. It is a computer-based exam. It will be offered at Vue testing centers. Well, sort of. Don’t freak out or anything yet, because it’s not going to fall victim to any of your typical “shortcut methods” to certification!
It’s going to be given at Vue’s Super Testing Centers. There’s a lot of extra comforts (since you’ll be stuck for 8 hours) and extra security measures. There are very few of these locations to begin with (but more than Cisco has CCIE Lab test locations!), and more so, right now they are looking at one location per quarter (4 times per year then!) in a different location.
There will be changes/updates from one time to the next as well, so even if you heard something (which still isn’t cool to break NDA) it won’t necessarily help anyway!
With this program, Cisco is taking some interesting steps to assure the integrity of the program along with giving the opportunity to reach different geographic areas that may not e conveniently handled by current CCIE Lab locations. Watch for further announcements there!
On a completely different line of thinking was the demo itself. It was pretty slick. There was lots of reading to do (see Michael Morris’ blog on NetworkWorld’s site for some screenshots as well) and tasks associated with it. There was also a LOT of background noise while doing the demo, so hopefully that will not be part of the torture in the real practical!
Another interesting thing (being that it’s a beta), not everything was perfect. Note to self… When you ask a proctor a question, and they smile when they are answering, it may not be entirely honest! It’s all good though! Needless to say, I did not perform in any spectacular fashion on this 8-9 question beta scenario here.
However, the one important thing I did come away with was an idea of what they were grading and HOW they were grading, and the types of things they were looking for. I also had some conversations with people inside the program to further that and I have to say that even though many people downplay the idea of the computer-based testing for design, I think the way they are going about it in detail is really very strong.
It’s definitely unlike any computer-based testing you’ve ever done before!
But that’s half the fun, isn’t it? I’m sure more announcements with this will be coming down the road, but I’m looking forward to being thoroughly abused by eight hours of it in October!
A whole section dedicated just to RIP? RIP can’t possibly cause problems in the CCIE Lab Exam right? You may be surprised… IEWB-RS Volume I Version 5 RIP labs are now posted on the members site. If you are really ready for the lab exam you should be able to look at the topology diagram, read the the lab question, and know exactly what the implications of each configuration are before implementing them. If you can do this without looking at the solutions I would like to hear from you!
Feel free to post questions and comments here on the blog or here on the forum.
We’ve been getting a lot of questions about when the new version 5 content is going to be complete for CCIE R&S Volume 1, and you will all be happy to know that development is quickly proceeding and has integrated some new changes based on the feedback we’ve gotten thus far. A new sample of the final format of the content can be found here. The diagram can be found here. Breakdown content is now much more detailed as you can see from the sample. This format is a lead-in to our new CCIE Routing & Switching Advanced Technologies Class-on-Demand Version 5.0, that will be nearly THREE FULL WEEKS OF CONTENT. While the current 4.1 content is exceptional, there are certain topics that were cut short to fit into the two week format. We envision a 100% complete release of Volume I Version 5.0 and the CoD Version 5.0 within the next six weeks, and optimistically a large portion of the new Volume II Version 5.0 and Volume III Version 5.0 content. Beta testing will begin for all of this material shortly. More information will be posted on how to apply for the beta process.
As the world evolves around us all, so do the topics of the various CCIE lab exams! Networkers did not yield any earth-shattering information that we did not already know, but it highlighted some areas of interest for us.
IPv6 will be coming to a Service Provider CCIE exam near you. This shouldn’t be a surprise as it has been in the R&S CCIE exam for over a year now. What will make it interesting, of course, is just how much EXTRA stuff expanding other topics like MPLS labeling, VPN creation, VPNv6 routes and other stuff like that which will need to be discussed and dissected along the way.
IOS-XR may be coming in at some point. Most likely in the form of a GSR router. No, I have no details on exact models or what exciting level of software/modules/stuff will be included with it! Just watch for further announcements! In my own personal opinion, with the use of the GSR we may also find some SONET links added into our topology with the 7200VXR routers already being used. I have no other basis than my warped sense of humor for that, and thinking that it “just makes sense”.
Those were the techniques discussed during the CCIE Service Provider Labtorial at Networkers this year! Nothing (as of this morning) has made it up on Cisco’s web site, so no official timeframe is established at this point. January 1 seems like an awfully good target, but no official news yet.
The “labtorial” in case you were wondering about that name seems to represent either a shift or a “test the waters” approach to a new way for the CCIE information. Students were given different lab tasks to perform on remote equipment via provided laptops, and from what I hear this was very well received by attendees!
The goal of this article is to discuss how would the following configuration work in the 3560 series switches:
interface FastEthernet0/13 switchport mode access load-interval 30 speed 10 srr-queue bandwidth shape 50 0 0 0 srr-queue bandwidth share 33 33 33 1 srr-queue bandwidth limit 20
Before we begin, let’s recap what we know so far about the 3560 egress queuing:
1) When SRR scheduler is configured in shared mode, bandwidth allocated to each queue is based on relative weight. E.g. when configuring “srr-queue bandwidth share 30 20 25 25″ we obtain the weight sum as 30+20+25+25 = 100 (could be different, but it’s nice to reference to “100”, as a representation of 100%). Relative weights are therefore “30/100”, “20/100”, “25/100”, “25/100” and you can calculate the effective bandwidth *guaranteed* to a queue multiplying this weight by the interface bandwidth: e.g. 30/100*100Mbps = 30Mbps for the 100Mbps interface and 30/100*10Mbps=3Mbps for 10Mbps interface. Of course, the weights are only taken in consideration when interface is oversubscribed, i.e. experiences a congestion.
2) When configured in shaped mode, bandwidth restriction (policing) for each queue is based on inverse absolute weight. E.g. for “srr-queue bandwidth shape 30 0 0 0” we effectively restrict the first queue to “1/30” of the interface bandwidth (which is approximately 3,3Mbps for 100Mbps interface and approximately 330Kbps for a 10Mbps interface). Setting SRR shape weight to zero effectively means no shaping is applied. When shaping is enabled for a queue, SRR scheduler does not use shared weight corresponding to this queue when calculating relative bandwidth for shared queues.
3) You can mix shaped and shared settings on the same interface. For example two queues may be configured for shaping and others for sharing:
interface FastEthernet0/13 srr-queue bandwidth share 100 100 40 20 srr-queue bandwidth shape 50 50 0 0
Suppose the interface rate is 100Mpbs; then queues 1 and 2 will get 2 Mbps, and queues 3 and 4 will share the remaining bandwidth (100-2-2=96Mbps) in proportion “2:1”. Note that queues 1 and 2 will be guaranteed and limited to 2Mbps at the same time.
4) The default “shape” and “share” weight settings are as follows: “25 0 0 0” and “25 25 25 25”. This means queue 1 is policed down to 4Mbps on 100Mpbs interfaces by default (400Kbps on 10Mbps interface) and the remaining bandwidth is equally shared among the other queues (2-4). So take care when you enable “mls qos” in a switch.
5) When you enable “priority-queue out” on an interface, it turns queue 1 into priority queue, and scheduler effectively does not account for the queue’s weight in calculations. Note that PQ will also ignore shaped mode settings as well, and this may make other queues starve.
6) You can apply “aggregate” egress rate-limitng to a port by using command “srr-queue bandwidth limit xx” at interface level. Effectively, this command limits interface sending rate down to xx% of interface capacity. Note that range starts from 10%, so if you need speeds lower than 10Mbps, consider changing port speed down o 10Mbps.
How will this setting affect SRR scheduling? Remember, that SRR shared weights are relative, and therefore they will share the new bandwidth among the respective queues. However, shaped queue rates are based on absolute weights calculated off interface bandwidth (e.g. 10Mbps or 100Mbps) and are subtracted from interface “available” bandwidth. Consider the example below:
interface FastEthernet0/13 switchport mode access speed 10 srr-queue bandwidth shape 50 0 0 0 srr-queue bandwidth share 20 20 20 20 srr-queue bandwidth limit 20
Interface sending rate is limited to 2Mbps. Queue 1 is shaped to 1/50 of 10Mps, which is 200Kbps of bandwidth. The remaining bandwidth 2000-200=1800Kbps is divided equally among other queues in proportion 20:20:20=1:1:1. That is, in case on congestion and all queues filled up, queue 1 will get 200Kbps, and queues 2-4 will get 600Kbps each.
Brian Dennis and I are proud to welcome Scott Morris, four-time CCIE #4713, to the Internetwork Expert team as a new CCIE instructor. Scott Morris has been in the Cisco networking industry for over 12 years and belongs to an elite group of engineers worldwide holding four CCIE certifications. Scott was one of the first individuals to pass the Cisco Design Specialist certification in 1998, and soon after passed the CCIE Lab Exam in Routing and Switching. He then went on to obtain CCIE certifications in ISP-Dial, Security, and Service Provider. Scott is currently preparing for the Voice CCIE, and the newly announced Cisco Certified Design Expert (CCDE).
Prior to joining Internetwork Expert, Scott was Vice President of Technical Training and an Instructor at IPExpert. While working at IPExpert, Scott developed and delivered CCIE classroom training, as well as initiated new product development. Scott is currently a regular columnist for the TCPMag Journal.
Sitting at the airport now at 6am after last night’s CCIE party, with 2 hours sleep, I’m tempted to ask myself, was it worth it…? Absolutely! For those of you that were lucky enough to attend the party, I’m sure you would agree. It’s good to see that once again Cisco is giving something back to the CCIE community – those customers/partners/employees who have always been, and will always be, Cisco’s biggest advocates out there in the market. You know who you are – you think BGP and OSPF are fun, and wake up from a nightmare screaming where the broadcast keyword was left off of a frame-relay map statement
What was the best part of the night you ask? Some may say meeting old friends, making new friends, (drunken) NASCAR simulation driving, or getting the official CCIE beer mug (awesome). Personally I would have to say the best part of the night was when Scott Morris, upon entering, was told at the door that his name wasn’t on the list. After frantically shuffling through the papers at check-in, Scott proclaimed, “I have *4* CCIEs! I should be on *all* the lists!” Needless to say everything worked out, but it was one of those great “you had to be there” moments. A special thanks goes out to the event team that did an excellent job organizing everything, and especially for accomodating those CCIEs (*cough cough*) who didn’t get the invitation email, but were still allowed to attend.
For those of you that Brian and I did get the pleasure of meeting this week and at the CCIE party, thank you as always for your support. If you took pictures at the event last night please email them to me and I’ll post them here on the blog for posterity. For those of you that we missed… San Francisco 2009 is right around the corner!
Keep checking the blog in the next few days for more detailed write-ups on the sessions we attended, including the upcoming CCDE, and for a *very special announcement* that will be posted (hopefully) later today.