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.

Happy labbing!

Brian

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.

Read the rest of this entry »