-Read up to page 85 on the CCIE Exam Cert Guide (4th edition)

-Read 10-20 pages of the BCMSN book, used it to review on some layer 2 topics that the exam cert guide didn’t go into to much detail with

-Did up to page 40′ish on the INE Volume I labs. I’ve been taking my time to make sure I have the verification commands down, and know that I’m “good” at certain technologies. This is especially important to me, since switching is doubtedly a core topic..everything else would break without it!

ip access-list log-update threshold X

I stumbled onto this command thanks to the INE ATC. By default, when you add the “log” keyword to an access-list entry, it will log the first hit, and subsequent identical hits will be logged at 5 minute intervals. Great for the real world (sometimes), not so great for the lab. I find it helpful to know one-for-one, that I have a packet passing through that meets that particular ACL. By entering this command, and putting a “1″ where the X is, it will log hits 1-for-1. Pretty helpful I think.

Anyway, back to studying. I’m now entering the world of STP, so if you don’t hear from me, send help ASAP I’ll be fine.

More to come soon! I’m really going to be hitting it hard these next couple of months.

R&S Written exam: June 15th (or sooner)

R&S Lab exam: June 15th, 2011 (12 months after the written)

Study materials (written): IEWB Vol I, the typical CCIE books…too many, dynamips, some rack rentals. I learn best by doing, so I’ll be reading and labbing in betwee, although I won’t be doing any full labs during this phase.

Study materials (lab): IEWB Vol I/II/III, Maybe IPexpert Vol II labs, some rack rentals, as wel as dynamips for focused study on individual technologies. I’ll also be putting together my own lab (see below):

My lab (proposed): It will essentially consist of several 1841 routers, 2 3550′s, 2 3560′s, a terminal server, along with a couple of 2620′s to fill in the gaps, and a couple of BB routers. Total cost will come in at somewhere around $5-6k when it’s all said and done. I’ll be piecing it together over the next 6-9 months (while I’m studying for the written). During the early stages of my lab prep, I’ll rely on dynamips and rack rentals, and once my home lab is complete, use that.

Because of the OEQs and troubleshooting sections, I plan on integrating some book study with my lab study time..possibly a couple of hours a week throughout the entire lab prep process. I’m hoping this will keep me sharp, and give me an edge on the troubleshooting section.

As I said, I take my CCDA in a week. I have studied that book inside and out, and am ready to take it. I’m bored with it infact..so I’m starting to read Routing TCP/IP Vol I from cover to cover. I’ll be doing plenty of dynamips labs while reading this book. For anyone who cares, I’m running Ubuntu 9.04 with GNS3, on an Intel 2.4ghz dual core w/ 4GB RAM. It’s a nice setup, but I want real hardware, so I can just fire it up and kind of eliminate the issue of troubleshooting dynamips/ubuntu.

Not sure how much I’ll be posting while prepping for the written (at least in the next month), since I need to review a lot of material. I’m rusty on my routing topics..but I feel good with switching, so that’s good. Anyway, as I learn more, I’ll post more

This comes because I’ve recently spoke to a guy who had been after the CCIE for a while, and after hearing about the high number of 4.0 failures since the inception of the new version on October 18th- he decided to alter his path. I can’t blame him. This particular individual was making just short of what the average CCIE salary is, and doesn’t stand a whole lot to gain when you consider the amount of work required for the CCIE. In his case, the return on investment (ROI) just wasn’t worth it. Naturally, after hearing his story, I can’t help but think “man, maybe I was wrong“, after my opinionated post about the 4.0 possibly being easier.

All I’m saying is- evaluate your reasons for going after the CCIE. A  gentleman I knew at one time was ex-special forces. This guy and I were talking one time about SFAS- the highly elite (and difficult) Army Special Forces Assessment- the first step to becoming Army Special forces. The pass rate at that course is something like 25% the first time through..very similar to the CCIE lab..although highly demanding in different ways. Anyways, he told me in reference to school: “You better have one good reason you’re there, because when it comes down to the wire, that one reason is what’s going to push you through..if you don’t have a good reason, you’ll fall out with the rest”. What’s your reason? Is it enough? I am not trying to dissuade anyone from going after the CCIE- on the contrary, I am saying, GO FOR IT!..but in a targeted manner, with your eye on the prize, and realize what it will take long before you embark on this journey.

Well, I’m getting back into things. My life has been very busy in the last month or so. My older brother, Dan, is getting married in less then a month, I’m getting married myself in less than 2 months, going to Jamaica for a week, etc.  That being said, it’s time to hone in and get back to basics. I’m going to start at block A, and re-read the CCIE exam cert guide (v3.0, unfortunately..I will fill in the gaps with online docs, videos, and hands on experimentation), then take the CCIE written. My tentative goal is to take it just barely after the new year. If all goes well, I’ll pass it within a couple of weeks of us breaking into 2010. I hope then to take the ONT exam quickly, and schedule the CCIE lab exam for somewhere around late 2010.  I need to get back on the horse, because for a while, I lost my focus, and got a little overconfident I think. Now that I am back in the right mindset, I need to re-focus, and assess where I stand, and get to work. Just wanted to let everyone know that I’m still rolling, albeit very slowly.

Look for an article or two to show up in the next week or two if things go right. Not sure what subject it’ll be on yet. Take care…..stay classy, san diego.

Traffic Shaping

Let me paint a picture for you. Here in Florida, we have a lot of toll plaza’s. You know, you drive up, pay some absurd amount, then continue on your journey. Now let’s picture that there is a toll plaza, and 2 miles down the road there has been an accident. Thankfully, the accident did not block all 4 lanes of traffic, but instead only 3. Traffic is moving along but very slowly. As a result, there is heavy congestion at the scene of the accident. The city, having some foresight, doesn’t want the congestion at the scene to get any worse…and decides to only send one car through the toll plaza every 30 seconds. Since they are putting slowing the rate of traffic at the booth, it allows things to clear up a bit at the end, and traffic to flow smoothly again- although at a slower rate.

So how does that apply to shaping in a network? Well, in a nutshell, shaping will enqueue excess packets (above the configured rate), and ‘release’ them onto the wire at the configured shaping rate. As a result, you can slow your transmit rate without just cutting off any traffic above a certain rate. Let’s say you administer a spoke that heads into a frame relay cloud- Your negogiate a CIR (committed information rate- the rate you wish to send under stable conditions) of 64k. Let’s assume your access rate, or AR, is 192k. You want to configure shaping at 64k, so that you don’t send more data then the distant end can handle..which may result in delay, jitter, or even loss of packets due to policing. Speaking of policing…

Policing (“Oh S!)%!! Not another ticket..”

How many of you reading this have seen speed traps setup by the local law enforcement officers? I’m sure anyone who has driven a car once or twice in their lifetime has. Let’s imagine we have a rookie right out of the academy, a little bit hot headed and power hungry. For the sake of this article (and to plug a hilarious movie), we’ll call the rookie “Farva”. Farva decides he wants to hit the roads and setup a speed trap. Since the speed limit is 55 Mph, he decides to not only ticket, but arrest anybody going over 55 Mph. This means 56 Mph gets you a cell next to a fellow named “Tiny” with a propensity for middle-aged caucasian males.

Once again, how does this apply to our network? Well, remember how we shaped the traffic leaving the spoke towards the frame relay network to 64k? Let’s imagine that we hadn’t shaped it at all. The service provider said “you get 64k to us, that’s it”. Well, in the event we start sending what our actual AR (access rate, remember? the line rate..) is, 192k in this case…then the service provider is going to implement policing and drop any traffic above the configured CIR. Obviously they could drop traffic at whatever rate they chose to, but in our example, it’s anything above the agreed upon CIR. In summation, policing enforces the CIR, making sure that nothing extra gets sent through. It is worth a brief mention that policing can be configured to mark down a packets IP Precedence or DSCP value so that it will get through, but later stands a better chance at being dropped then other packets. In times of network congestion, this will ensure the marked down packets are dropped first, but still allow them through if traffic is not heavy.

Bc…just a little info..

This is generally the place where I would discuss different shaping terminology, but I already described some of them here: FRTS, so check that out if you feel the need. I will, however give you this:

To calculate Bc, there’s a couple of ways to do it. For the sake of the following conversation, lets say our CIR is 64Kbps, and we are using the default Tc values of 125ms (over 8 intervals). What’s our Bc? There’s a few ways to do it:

Bc = Tc (125ms) x CIR (64) = 8000 bits per interval

OR

Bc = CIR (64000) / 8 (amount of intervals) = 8000 bits per interval

As you can see, both are correct. Whichever one you use is really up to you. Either way, our Bc will be the amount of data sent per time interval in order to conform to our shaping rate.

Congestion Avoidance

When the queues on an interface fill, by default, the next packets that try to be added to that queue will be tail dropped. In order to solve the problem of tail drop, you can either configure the queues to be larger, or use congestion avoidance. Here’s the idea: When tail drop is employed, all packets are treated as equals..not good! This means that delay-sensitive traffic such as VoIP/Video is no different then say Limewire, or HTTP traffic.  This means that several TCP segments can be dropped at once, causing those hosts to reduce their send window, then raise each of their transmit rates at the same time..resulting in bandwidth utilization that looks like a very sharp wave of high utilization and very low utilization. Congestion avoidance techniques such as WRED will help us avoid these issues. We’ll discuss those later, but first, let’s go over exactly why the default behavior of tail drop is bad.

Tail drop, and why it’s bad

Tail drop has several downfalls. The first one that comes to mind is that tail drop treats all packets as equals (as mentioned above). The second, is that with tail drop you are open to TCP synchronization and not efficiently using your links. TCP Synchronization, is cause by the natural behavior of TCP segments. A TCP segment will begin opening it’s window, gradually increasing it’s transmit rate, until it drops segments, then reduce the window by 50%.  The TCP hosts will build their transmit rate (open their window) slowly again, and upon reaching the maximum utilization, it will repeat this process. Now once you throw in multiple TCP sessions, you encounter TCP synchronization. The downfall to this is that when all of the sessions cut their window by 50%, you have a period of relative quiet in the network where very little traffic is being sent, followed by bursts of TCP traffic. The final issue with tail drop is that the more aggressive traffic (say, HTTP or limewire traffic, as mentioned above) will fill the queues quickly, leaving the less aggressive flows to be tail dropped.

Weighted Random Early Detection (RED/WRED)

WRED is based on RED. The basic idea behind RED is this- as the router’s queue’s fill, RED randomly selects TCP packets to be dropped, thus preventing synchronization as described above, and preventing congestion and eventually tail drop. What WRED does differently then RED, however, is allow you to be a more precise when dropping traffic. WRED joins with the powers of IP Precedence/DSCP to allow you to drop the lower precedence packets first, while allowing the higher precedence traffic to pass. In essence, WRED ‘predicts’ congestion, and gives you some decision on what can be dropped if the network is experiencing congestion. Based on statistics, WRED will drop traffic more often from a high volume sender then a low. What this means is, the more ‘offending’ TCP hosts will have their traffic lost as they cross the threshold (more on that in a minute), as opposed to the low volume sender. Now, it is important to remember that we are dealing with TCP packets here. If the bulk of the traffic is UDP, WRED will not be effective.

Now, it’s important to note that the ‘core’ of WRED is no different then RED. The only difference is that WRED is more selective about what is dropped, not how. Here’s a rough framework of how these techniques operate:

• Packet is received, and the average queue depth is checked. If it’s below the minimum threshold, it is queued and sent out the proper interface. If it’s above the minimum threshold, it is either queued or dropped on a percentage based on the MPD (Mark probablity denominator). The MPD simply put, is the maximum percentage of packets that WRED will discard. If MPD is 16, using the forumlua of 1/MPD (1/16 in our example), the max discard rate would be 6%. If we made the MPD 10, it would be 10% (1 divided by 10).

Here is a collection of random notes I have thrown together as it relates to RED/WRED:

• RED/WRED use an exponential weighting constant to determine the average queue depth. The lower this is, the more quickly the average queue depth will change, and by raising it it will react slower. By default it is 9, and can be changed with the random-detect exponential-weighting-constant X command
• RED differs from tail drop in the sense that tail drop occurs when the queue is full- RED may begin dropping all incoming packets even if the queue is not full…if you set the max threshold low, it will discard them even if the queue isn’t full.
• RED drops above the min threshold at a linear rate, based on the MPD (1/MPD is the formula, so default MPD of 10 means 1/10, or 10% max discard rate)
• WRED cannot operate with other queuing techniques at the physical interface. If you configure CBWFQ/LLQ, you must configure WRED within each individual class. When WRED is enabled on the physical interface, only FIFO queuing is used. This can be seen with a show queueing interface s1/0
• WRED weights packets on the following: Average queue depth (found using the exponential weighting constant, default of 9), Min & Max threshold (dependent upon the DSCP/Precedence value), MPD (see two bullets above)
• Enabling WRED (random-detect) disables WFQ
• WRED defaults to being IP Precedence based, but you can specify it to work on DSCP instead with random-detect dscp-based
• If using DSCP based WRED, you use the following command to alter the thresholds per DSCP value: random-detect dscp af21 40 50. This command would make the DSCP value AF21′s minimum threshold at 40, and maximum at 50. You can see the effect of this command by doing a show queueing interface s1/0 again.

Below you’ll find a graph that I created to demonstrate RED’s behavior. You can see that when traffic crosses the minimum threshold, RED begins dropping traffic at a linear rate, up to the maximum discard rate, or MPD, which is by default, 10%. After that, it will cross the max threshold, and drop all traffic.

Link Efficiency Mechanisms

• Multilink PPP (MLP)
• Frame Relay Fragmentation (End to End FRF.12)
• Header Compression (RTP Header compression, TCP header compression)

Link Efficiency

Link efficiency may not strike you as an important feature of QoS, however it is when you are the one paying for the bandwidth! In these days of the rough economy and financial uncertainty- getting the most out of our money is key..especially when it comes to business. Bandwidth costs money, after all. Link efficiency can be broken down into a couple of categories, Compression, and link fragmentation/interleaving tools. Compression is the act of compressing the packet (or the number of bytes in the packet), so there is fewer bytes to transmit across the link. Fragmentation is essentially chopping up the larger packets into smaller ones. To understand interleaving, let’s say we have a large packet waiting to transmit, with a small packet that is delay-sensitive (such as voice) waiting behind it. If the small packet waits for the large packet to serialize (be put onto the wire), it may wait too long and exceed the acceptable delay/jitter. By fragmentation and interleaving, we are chopping the large packets into smaller pieces, and inserting parts of the voice packet in between the large one. Let’s first discuss compression..

Compression is not difficult to understand..well, the concept at least- agreed? There are a couple types of compression I’d like to discuss, Payload compression, and Header compression. Here’s a quick rundown:

Payload compression: Compresses the headers and user data. Uses more CPU cycles.  Here I am mostly referring to Layer 2 compression such as ‘Stacker’ or ‘Predictor’. Stacker is more CPU intensive but uses less memory. Use “compress stac” at the interface to use stacker. Predictor is more memory intensive. Use “compress predictor” to use Predictor. It is worth mentioning that predictor only supports PPP and LAPB, whereas Stacker supports most Point-to-point layer 2 protocols.

Header Compression: If you were to examine packets, you’d see that the headers are very similar..header compression is based on this..and as a result uses very little CPU. The two common types of header compression are TCP and RTP header compression. TCP is best used with relatively small TCP packets, since it reduces the header from 40 bytes to anywhere from 3 to 5 bytes. The best way to see why TCP header compression is not so great with larger packets, is to consider that we saved about 35 bytes in our header compression of say a 56 byte packet (40 bytes being in the header)..but what if our packet was 1300 byes? We’d compress about the same amount of bytes, and it would be a relatively small savings byte-wise..almost not worth it. RTP header compression is best with voice traffic, and will generally compress the headers a little bit more then TCP (2-4 bytes down from 40). An interesting note, if fast switching or CEF is not enabled on an interface, and then you enable RTP header compression, the interface will process-switch the traffic. NOT good!

Multilink PPP

Out of the few link efficiency mechanisms listed above, this is the one many people have heard of- usually before the others. Let’s say you have two slow serial links, both running PPP to the same location..Multilink PPP allows you to bundle them and treats them as one link. This provides layer 2 redundancy as one of those links can drop and traffic will still flow- although at the much slower speed of the single link. There’s several other benefits that multilink provides which we’ll go over..

Multilink interleaving- Interleaving simply takes two separate streams of data, and ‘interleaves’ them, sending (in our case) delay-sensitive traffic in between the large datagrams. As you may have guessed, this is especially helpful with delay sensitive applications.

Multilink fragmentation- Multilink Fragmentation is ‘chopping up’ large datagrams into several smaller ones, but using multilink headers on each of the smaller datagrams.

As a side note, me being a frame relay nut, love things like MLP over Frame relay (MLPoFR). If you’re interested in that stuff too, check out what cisco.com has to say. I could probably dedicate a whole article to MLP, so I would look for that in the future..

Designing and Deploying Multilink PPP over Frame Relay and ATM

That is all for now, folks. I was going to go into FRF.12 and MLP LFI into detail, but I ran out of steam to be quite honest. More to come at another time most likely! Enjoy…

1. High speed interface –> Low speed interface:  Picture you have one node connecting to the frame relay cloud at 1.544 Mbps, and the router at the far end connecting to the cloud at only 54Kbps. You are essentially creating a bottleneck in this scenario, and will surely experience congestion due to the downstream router having a lower access rate. Shaping the traffic ensures you are sending the data at a speed the other end can handle.
2. Oversubscription: Let’s say your access rate (the max rate that you can send to the provider) is 128Kbps, but your CIR is only 32Kbps. You can burst above the CIR, but if congestion occurs drop back to your CIR. This ensures that bandwidth is not sitting idle and going unused..the idea is that not all users will require 100% of their bandwidth all of the time.

The information I’m going to present is mostly aimed at the first scenario. Let’s say we have a topology as such:

In such a scenario, the Access rate- or the maximum rate that the user can send data, is found on the serial links above. R1 can access the FR cloud at 256K, however R2 can only access it at 128K. Because of this mismatch, it would experience congestion at the interface leaving the FR cloud onto R2′s serial link. Let’s get some terminology out of the way that we must take care of.

AR- Access-rate- The maximum rate the user can inject data into the FR network

CIR- Committed Information Rate- The rate you would like to send under regular conditions to the service provider

Mincir- The actual guaranteed rate by the service provider. Sending less then this means you are not getting the bandwidth you have paid for. We can use mincir to “fall back” in times of congestion, and when things clear up bring our rate back to the CIR.

Tc- Time interval- By default, the service provider will divide one second into 8 parts, of 125ms in each “section”.

Bc- Committed Burst- CIR/Tc. What’s this mean? Say we have a CIR of 56000, then we divide that by the number of Tc intervals..by default 8. That means our Bc is 56000/8 = 7000 bits per timing interval. This means that every timing interval will send 7000 bits, 8 times to make up our CIR of 56000. Of course, we don’t have to send at that rate..if we don’t, the unused bandwidth can go to your token bucket filter..which allows you to burst above your Bc…this burst above Bc is called Be, or Excess burst.

Be- Excess Burst- Data sent above the Bc (Committed burst) per Tc (Timing interval).

Be (Excess Burst) Breakdown: If you are sending below your CIR, you can accrue “tokens” in your token bucket, to use at a time you need to burst above your Bc. It is important to note that you should only configure a Be value (the amount you want to burst above Bc..provided you have the credit available in your token bucket) if your CIR is LESS then your AR. This makes sense, if your AR (access rate) is 56k, and your CIR is 56k..you don’t want to try to burst above that. It will not work!

Case study: Without going into the configuration yet, the above example uses the adaptive shaping becn command. This causes the router to react to becn’s and adjust it’s throughput on the fly. Using the diagram above, let’s review what exactly is going on. In the first interval (0-125ms), we use our token bucket credit, and send our Bc plus our Be, with our total throughput for that interval being 24k..for that ONE interval. After the first time interval, we start sending at our CIR, which is 128k divided by the amount of time intervals- by default this is 8. That means we are sending 16000 bits per interval. The best way to think about this is that CIR is your regular throughput- over the period of 1 second. Your Bc is simply your CIR but broken up into time intervals.

Now, you’ll see at 500ms that we receive a BECN. FRTS throttles the transmit rate 25% once per interval, upon each BECN received until it reaches the Min CIR value, which in our case is 56k, or 7000 bits per interval. After throttling down to Min CIR, the router must allow 16 time intervals (2 seconds by default) to pass with no BECN’s being received, before ramping the transmit rate back up to the normal CIR. The amount it will increase by is called the byte limit, and can be seen with a show frame pvc X.

Interesting notes regarding FRTS:

• If you configure “frame-relay traffic-shaping” under the interface but with no map-class configured/specified, the default CIR value will be 56000 bps.
• By default, Min CIR is 1/2 of CIR (although in the above example we did it a little bit different)
• You cannot configure the interval (Tc). The router calculates Tc based on CIR/Bc values..so although you can’t explicitly configure Tc, you can influence it by CIR/Bc values..although this also has other implications.
• Bc = CIR/8 (by default), ie: 56000/8 = 7000 (Bc)
• After fully configuring FRTS, if you do a “show frame pvc x“, it will show “traffic shaping inactive”. It will not show active until traffic passes that fall within the scope of the shaping.
• Shaping activates upon the following events: BECN’s received and the DLCI is configured for adaptive shaping (BECN), FRF.12 fragmentation is configured with packets waiting to be fragmented, the number of bytes waiting to leave the interface is more then the byte limit (available credit)
• FRTS allows you to control per-VC shaping/traffic
• Can use WFQ/CQ/PQ or FIFO (FIFO by default)
• In addition to configuring adaptive shaping on BECN receipt, you can configure the interface to react to interface congestion

That’s all I really have for now. There’s a lot of little details for FRTS that can be kind of tricky, but as a whole it’s fairly straightforward. I hope to post several configuration examples in the next post, although I personally feel the difficulty in FRTS lies in the terminology/concepts. Once you get those the rest is cake. Take care!

• The free CCNA audio nuggets are somewhat on the back burner right now. I have the class layout drawn up, and it’s ready to be recorded, but time has been so short lately, and the CCIE study takes precedence over those. Once things free up a bit I’m going to record that and post it.
• I attended Jared Scrivener’s (Triple CCIE from IPexpert) Ask the expert session on Prefix-lists as it relates to BGP the other day. It was pretty good. I definitely left that session with a better understanding of prefix-lists. The following morning I labbed some BGP to play with prefix-lists a bit and get a more functional understanding of them. I think the key without doubt to prefix-lists is knowing your binary. If you know your binary and the layout of a prefix-list, you can figure it out. Maybe I’ll post something up once more time allows.
• I’m realistically about 50-60% done with Switching and Frame Relay as far as technology based labs. I’ve completed all of the tasks in IE Vol I, but I’m going through the Cisco docs and using those as my yardstick. Once I feel like I’ve got the majority of topics covered I’ll move on to IGP.

That’s about it for now. I am going to hop off here and get back to reading. I make it a point to pick a subject each night at work and read about it in the cisco docs. Don’t know how much it’s helping, but it certainly can’t hurt!

Being sick has put a damper in my studies for sure. I haven’t had any energy, let alone motivation, and as a result haven’t gotten much done. I did review some RIP/Frame Relay/Switching tech labs a little. I plan on getting a frame relay article up soon, so look for that. It won’t be so much a “how to”, but more of a “things to know..” type format.

At the moment I am beginning to get into the EIGRP tech labs. They shouldn’t be too bad, but we’ll see. I have always used OSPF, not EIGRP in enterprise environments, so this will be my first time really diving deep into the protocol.

Anyway, more to come in a little while. It’s time for me to transition from SGT CCIE to the daycare taxi for the little one..