**Disclaimer: This is my story. These are my opinions. I feel strongly about them, since I have lived these words, and they’ve served me well. I’m telling my story not to boost my own ego up, but to help others attain the same satisfaction as I’ve attained. Ultimately it comes down to this: I like helping people. So I’m trying to help. If you don’t need help, or don’t care to hear my story..read no further. Else…enjoy!**

At 16, I had my first job. KFC. It is the only job I can think of where I didn’t learn anything. I was only there three months until my family moved.

Shortly after leaving KFC, I got hired at Pizza Hut as a cook. Within 6 months, at 16 years old, I was a shift manager. Right after turning 17, I was promoted to assistant store manager. I learned a lot of valuable lessons here. Most important, hard work does pay off sooner or later. If I hadn’t been a hard worker, there’s no way as a 16 year old I would have been promoted to shift manager. Sure, it’s only Pizza Hut, but it’s more than that. I gained the trust of senior management, because I delivered. They could see past my age, and look at the results I delivered. Unfortunately, not all employers are like this, but the good ones are.

Right before I became the Asst. Store manager, I dropped out of high school to get my GED. Long story short, I homeschooled for one year, and the school board refused to give me credit, It was either GED, or extra year in high school. I got my GED 2 weeks later, and began thinking of college. While being the Asst. Store manager was great at 17, I needed to go to school. I was already into networking as a hobby, but had no experience. All the job postings for entry level positions required experience. One day, I drove an hour to register at a technical college. I was ecstatic. I then met with the financial aid counselor, and learned they would not provide enough money for me to afford going to school there. I left the college devastated, rethinking every decision I made up until this point.

On the way back home from the college, I stopped to use the restroom at a gas station. On the way out, a yellow flier fell off the wall, and gently landed right at my feet (cliche..but it really happened). I picked it up, and it was a U.S. Army Reserves flier. They could pay for my school, and I could work on getting a networking job. GREAT! I called the recruiter, and scheduled for him to come over. A few days later, he showed up. We talked, and after he left, I thought about it for 2 months before making a decision. I gave my notice at Pizza Hut, and left for the Army shortly after.

I won’t go into the details of joining the Army, because it’s not really relevant. I worked hard there, just like I did at Pizza Hut. I strived to learn new things each day, and to help others along the way.Fast forward a few years in the Army, I was on active duty, a 25B (Information Systems Analyst), but pretty much stuck to networking, because I got my CCNA while deployed to Iraq. Once I got my CCNA, my peers (and leadership) instantly recognized me as “the network guy,” which helped me immensely. At this point in my life (about 22 years old), I learned that sacrifice is a key part to success. Whether I was studying for promotion, or more certifications, or just to learn- I sacrificed free-time for the greater purpose (my future). For example, I’d have friends begging me to go partying, and I’d pass, to study OSPF. I didn’t WANT to study OSPF, but I didn’t WANT to be a failure even more. So, the fear of failure overpowered everything. I studied, studied, drank a little, studied some more.

Don’t get me wrong, I had a life. But the point is, I made select sacrifices in order to hopefully one day make it to the life I imagined for myself.

I then got assigned to Tampa, FL, in what basically amounts to a NOC Manager job. It could have sucked bad. Initially, it did suck. A lot. I was spending my time reporting to leadership on network events, doing trend reporting, and pretty much acting like a manager instead of an engineer. I then re-evaluated my situation. I had never had this view of a network before. I then realized, the ball was in my court. So, I got my CCNP. When I got my CCNP, I then became the guy the network folks would turn to for advice..essentially getting myself more experience. Additionally, I realized one day: most engineers cannot relate complex concepts to customers and/or leadership. So, I made it a point EVERY DAY to get better at this. By the time I left this job, I could explain anything to anyone.

It was during the previous job, I was preparing to get out of the Army. I knew I needed to make at least 65k to survive, preferably 75k to be in good shape, and ideally, 80-85k/yr. I got a lot of hits on my applications, and I attribute most of that to my resume writing skills. Eventually, I picked a job with a large service provider who basically makes mobile data work between telecom carriers. The pay was 70k/yr, but I could work from home, and I got a lot of perks. I jumped at it. There’s a few points I’ve learned up until this point:

• Take all the advantages you can get. A good resume, dressing sharply, knowing how to speak well, understanding business objectives..these are ALL free (well, minus the clothes if you don’t own them)..why not take every advantage you can get when seeking employment in the IT field?
• Do what you say. If you tell a potential employer you’ll get back with them tomorrow, get back with them. If you don’t, this says “I’m unreliable, and you haven’t even hired me yet”
• Learn how to translate previous experiences into resume candy. For example, if you have experience running cable, don’t leave it at “ran cable for X company”- instead, something like: “Experience performing Layer 1 installation/troubleshooting for customers, ensuring the availability of key IT services”..some crap like that at least. The point is, speak like management. If you speak like you’re a minimum waige worker, why should they hire you for this 65k/yr job?
• If you don’t have experience, don’t lie. But don’t just say “no experience” either. If you’re a new CCNA, with no job experience, get some equipment if you don’t have it. Setup a network at home with domain and all if you have to. Volunteer. Do what you have to do. Articulate all of this very well on your resume, and stress that “although I don’t have production experience, I have done everything I can to gain experience on my own, including working in my home lab, and volunteering to provide IT services to so-and-so’s small business. Given the opportunity, I will absolutely learn everything I can, and excel at it”
• Ask questions in your interview. By saying “nope, no questions at all,” it’s easy to come across as uninterested. You want them to realize you’re just as interested in the company as they are in you. There should be a mutual interest.

So moving forward, I’m at this great service provider job, and I hit a major roadblock with management. Long story short, they expected me to be on-call 24×7 365 days a year (not agreed to prior to hiring), and have articulated several times to me, that family should come AFTER work. No thanks. As soon as my manager said these words (roughly), I started looking elsewhere. The days are gone of “get a great job stay at the same company for 20 yrs“, the market is too unstable for that. Now, it’s “get the best opportunity you have, add to your resume, and keep your eyes open.”

So I found a position that seemed to fit, so I submitted my resume. The next day, a phone call. I ended up not showing up to the interview, because I had cold feet about leaving a brand new employer. Once I came to my senses, I called them back, and went for the interview. After nailing the interview, I was offered the job on the spot. I accepted, for a 40% raise, which put me just shy of making 100k/yr.

So if anyone is keeping track, I went from making 48k/yr in the Army, to 70k 2 weeks later, to almost 100k onemonth later. Was it luck? Partially. Was it skill? Arguably. Could I have gotten the same position if I had not worked hard for the 6 years that built up to it? Possibly..but the bottom line is, I will never know. All I know, is I did everything I could, and the end result is this amazing opportunity.

It should be noted, that I do not have the mindset of “I’ve made it,” on the contrary- I have a LOT of work to do now. I’m stepping up the CCIE studies, and setting my sights on two, hopefully. I once heard successful people are generally pessimists by nature, because they never think they’re doing good enough. I tend to believe this.

Only one day after I landed this new position, I have the urge to do more, because I don’t want to become obsolete- so to speak. So that’s it. There’s a lot of details left out, but I’ve included the pertinent details/lessons I could think of at the time I wrote this. I hope someone else gets something out of this, and does well for themselves.

Regardless of the state of the economy, the state of IT, whatever..there will always be jobs for the right candidate. Make yourself that candidate. Be the solution to that companies issues.

Those of you “new” to the Cisco world, or those who simply don’t have experience in the layer 2 world may not have heard of errdisable (or simply might refer to it as the proper term, error-disable)- but any seasoned tech knows what a pain it is to check your port and see errdisable. Back when I was a network technician for the Air Force, I remember going to a building on a trouble ticket, only to find a couple of cisco 4500 (if I recall correctly), with no less than 200 cables running to them..you literally could not see the ports themselves, or the RJ-45 connectors. After digging around, I did indeed find a switch hidden back there. After seeing the dreaded orange light on the port LED (signaling errdisable), I consoled into the switch. At the time, I knew errdisable was bad, but that’s about it. This article would have helped tremendously if I had seen it already. Hopefully someone out there reads it in time!

What IS errdisable?

Errdisable, or error-disable, is a feature that allows the switch to detect certain error conditions on interfaces and disable them before the particular condition has a chance to affect the rest of the network. Basically, Errdisable says “Wait, something isn’t right..I’m going to shut this down so it doesn’t break anything else.” An example of some of the errdisable conditions(but not a comprehensive list) can be found below. For a more thorough list, check out cisco.com, and search for errdisable.

• Port-security violation
• Etherchannel flapping
• Invalid GBIC
• DTP flapping (trunk negotiation)

As I said, there’s more reasons, but those are some of the more common violations. In my experience, Port-security has been the largest- although you can configure error-disable to do what you want after noticing the “error condition”, this action it takes AFTER the error condition is known as the method of recovery. There are two types- manual, and automatic. Manual requires a shut/no shut on the interface; automatic recovery can recover the port itself after a specified interval.

How to tell if a port is in errdisable:

To tell if a port is in errdisable or not, do a show int status, or you can do a “show int fx/x status”. You should see “err-disable” if it is indeed, disabled. From here, depending on your recovery method, you either enable it with a shut/no shut, or let it recover automatically.

ErrDisable key commands:

Enable errdisable (already enabled by default for UDLD/Port-security):

Switch(config)#errdisable detect cause {all | arp-inspection | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap}

Configure automatic recovery from errdisable:

Switch(config)# errdisable recovery cause {all | arp-inspection | bpduguard | channel-misconfig | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap | pesecure-violation | security-violation | storm-control | udld | unicastflood | wmps}

Configure recovery interval (only applies to conditions for which automatic recovery is enabled):

Switch(config)#errdisable recovery interval 120 (seconds)

To check Errdisable config:

Switch(config)#Show errdisable detect

ErrDisable Reason              Detection Status

———————                ——————

udld                                          Enabled

bpduguard                              Enabled

security-violation                 Enabled

psecure-violation                 Enabled

…and so on

Switch(config)#Show errdisable recovery

ErrDisable Reason               Timer status

———————                —————

udld                                          Enabled

bpduguard                              Enabled

……………..

Timer interval: 120 seconds

Interfaces that will be enabled at the next timeout:

Interface        ErrDisable reason          Time left(sec)

———-        ———————          —————

f1/1                  security-violation                   34

Final point

ErrDisable is a good mechanism to help you find problems in your network- and to protect it- however, you should ultimately search for the root cause if you experience recurring errdisable conditions on certain ports. This is key, or your network will certainly not be operating efficiently.

In the previous installment of this series (QoS: Essentials, Part II), we discussed types of marking, NBAR,  and Congestion management/queuing techniques. With part III, I intend on discussing Traffic shaping /policing, Congestion avoidance, and link efficiency mechanisms. Because of the sheer amount of information in QoS, I cannot cover all of the QoS spectrum, but I hope to instill the foundational information that QoS is built upon. As usual, without further ado, let’s get to it!

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…

While at a first glance, Frame Relay Traffic Shaping (or FRTS) seems daunting..it’s really not bad. For those of you unfamiliar with FRTS, I’ll present a couple of scenarios where you may need to configure it.

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!

I have done my share of work in the networking field, and had never heard of this command. I have also not been exposed to a wide variety of layer 2 technologies, but I must say, that this is a very cool command. Granted, it could be considered old- or not on par with private VLAN’s (which take the same idea of isolating particular ports a little bit further), but I like it’s simplicity. However, it IS available in older catalyst switches that may not support Private VLAN’s, so that is a bonus. Last but not least,  knowing how to configure PVLAN’s and protected ports, you can accomplish- to some degree- the same thing in two different ways- which is always a plus. This article will primarily function as a basic overview of the command, although I will briefly flyby the configuration as it is fairly straightforward. Let’s get to it. First, I’ll present you a scenario that will demonstrate what switchport protected does.

Let’s say you have a Cisco 3550 in a closet somewhere, and for whatever reason want two hosts coming off of that 3550 to have no traffic pass between them. Switchport protected will enable you to do just that. The idea is simple: Any protected port can not talk to any other protected port, but can talk with any unprotected port. The idea here is the same as private VLAN’s somewhat..just a more basic method. There’s a few caveats worth mentioning regarding protected ports:

• The protection is only local to that switch. If you have User A on SW1, and User B on SW1, both on VLAN 100, configured with switchport protected..they will not talk. However, if you split the two users up on two switches that are trunking, but still within VLAN 100…they WILL talk. The protection does not span multiple switches!
• The protection is limited to Layer 2. Once the frame becomes a packet at Layer 3, it will allow the two hosts to communicate.
• To block traffic at Layer 3 also, you would need to look at ACL’s, or Vlan Access-lists, or other methods of access control.

So how do we configure a port to be protected? It’s cake. See below:

Switch(config)# interface fa0/1

Switch(config-if)# switchport protected

That is it! I know, almost a letdown, right? Well, the plus is, there’s more! Commonly when implementing protected ports, you will want to also block unknown unicast/multicast traffic. Why? Think about the basic nature of a switch when it receives an unknown unicast frame..it will flood it out all ports except the one it was received. This could introduce a possible avenue for attack. To mitigate this risk, we can block unknown unicast/multicasts on these ports by using the following configuration.

Switch(config-if)#switchport block {multicast | unicast}

That’s all there really is to it. I hope this short article has at least given you a small insight into small lesser-known features the Cisco IOS has to offer. I look forward to finding the next one to share with all of you!

While reading through my Cisco Press CCIE lab workbook, I came upon a section of the configs that kind of threw me off. The lab asked you to configure RIP to unicast updates without using the neighbor/passive-interface command. For those of you unfamiliar with the “neighbor” way of doing things, here’s how it goes. You configure “neighbor x.x.x.x” as the neighbors address (obviously). This will unicast updates, however, it will also broadcast (for RIPv1) or multicast (for RIPv2) updates regardless. See below.

The following shows

Apr  9 17:29:42.815: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (10.25.1.1)

R1(config-router)#neighbor 10.25.1.2 (added the neighbors IP here)

*Apr  9 17:31:04.575: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (10.25.1.1)
*Apr  9 17:31:04.583: RIP: sending v2 update to 10.25.1.2 via Serial1/0 (10.25.1.1)

As you can see,  unicast RIP updates are being sent, but the multicast updates are still going out. How do we stop them? Using the passive-interface command.

R1(config-router)#passive-interface s1/0

*Apr  9 17:34:50.887: RIP: sending v2 update to 10.25.1.2 via Serial1/0 (10.25.1.1)

As you can see, RIP updates are no longer being multicasted now, however the unicast ones are still exiting the interface..success! That’s fine and dandy, but let’s see another tricky way to pull this off. What happens if the lab says you cannot use the neighbor statement?…

Enter NAT.  I won’t lie, NAT is one of my least favorite subjects due to the unfamiliarity, but I’m sure after reading the following text, you’ll be impressed. I found this to be a sneaky way of unicasting RIP updates. Here’s the idea, since the neighbor statement is out of the question, we’ll use NAT to translate any outgoing traffic on UDP port 520 (RIP updates) to multicast address 224.0.0.9 into our neighbors interface address..in this case 10.25.1.2. Here is the configuration.

R1(config)#int s1/0

R1(config-if)#ip nat outside

Above, we simply identified our s1/0 as the outside interface for NAT purposes. Next, we’ll create our NAT statement which will do the magic.

R1(config)#ip nat outside source static udp 10.25.1.2 520 224.0.0.9 520

Here’s the catch. If we look at R1′s debug ip packet detail output:

*Apr  9 17:49:04.739: IP: s=10.25.1.2 (Serial1/0), d=224.0.0.9, len 52, rcvd 2
*Apr  9 17:49:04.743:     UDP src=520, dst=520

My first impression was: “damn, not working”. Then I checked R2′s debug ip packet detail output..low and behold..

*Apr  9 17:51:13.915: IP: s=10.25.1.1 (Serial1/0), d=10.25.1.2 (Serial1/0), len52, rcvd 3
*Apr  9 17:51:13.915:     UDP src=520, dst=520

Ah ha! The RIP updates sourced from R1 (10.25.1.1) are being sent to 10.25.1.2..or unicasted. We can verify this is unicast only, because without the NAT configuration, you will see the destination as the RIP multicast address, or 224.0.0.9. Pretty sneaky! Now, why can’t we see this NAT solution in R1 through debug ip rip, or debug ip packet det? It all comes down to the NAT order of operation. When performing NAT inside-to-outside translation, routing is done before NAT (with good reason)..therefore your RIP output shows that it is addressed to the 224.0.0.9 address, but by looking at debug ip nat detail on R1, we could see the NAT translation taking place.

*Apr  9 17:56:45.843: NAT: i: udp (10.25.1.1, 520) -> (224.0.0.9, 520) [0]

*Apr  9 17:56:17.815: NAT: s=10.25.1.1, d=224.0.0.9->10.25.1.2 [0]

There you have it! The lesson learned here is to 1) use 100% of the debug commands available, and 2) sometimes debugging from a neighboring router will help troubleshoot the node with an issue.

Edit:  Although I used RIPv2 in the example above, you can do the same with RIPv1, but instead of putting the RIPv2 multicast address in the NAT statement, use the broadcast address. It is key to note that you have to specify UDP port 520, or else you will translate all broadcast traffic that leaves the router instead of just RIP updates!

In QoS: Essentials, Part I, we discussed what QoS is, classifying/marking traffic, and trust boundaries. In Part II, we will get into the actual types of marking, do an overview of NBAR, and finally get into Congestion management/Queuing. Ready?

Types of Marking:

There are several different ways to mark, and each one is suited for a special situation. For example, if you’re running QoS over frame relay, you’d use the Frame Relay DE (discard elgibility) bit, whereas if you’re using ATM, you’d opt for the CLP (Cell loss priority) bit, etc. For now, we are going to simply discuss the different types. First, it is important to note ahead of time that we are going to be discussing markings that are used on layer 2, and some that are used on layer 3. Here are the breakdowns:

NBAR: Digging deep…

Prepare to be amazed! NBAR, also known as Network Based Application Recognition..is incredible. NBAR is a feature found in Cisco IOS, which can allow you to check traffic statistics, protocol discovery, and classify your traffic…for you! Let’s say you decide you want to implement QoS on your network. The first step is to identify traffic and requirements, right? Well, with NBAR, you can simply issue the following on the interface you wish to monitor:

SGTccie(config-if)#ip nbar protocol-discovery

In order to actually see the traffic statistics, we’d then issue the following command from enable mode:

It is worth mentioning CEF is required to run NBAR. Also, when using the “show ip nbar protocol-discovery” command, it will show you all interfaces unless you add “interface X” after it. NBAR can also save you a lot of time. Once we get to QoS configuration, you will see. The old way of doing things was to configure extended ACL’s listing port numbers and IP’s, and etc. Instead of “access-list 101 permit ip any host 192.168.1.1 eq www”, we now use “match protocol http”. Nice!

Congestion Management/Queuing…waiting in line…

Ahh, congestion management. Running fiber everywhere along with 1GB ethernet everywhere is great..but congestion still happens. Why? Many reasons, really..poor QoS implementation (or none!), poorly designed networks, outdated equipment, etc..the list goes on and on. Generally, however, the point of congestion is almost always where traffic from multiple sources aggregate onto a single link. Picture 10 access-layer switches connecting to one distribution-layer switch, which only has a 100MB link to the core. You could easily have 400 users’ traffic flowing to the core on that one link. Another scenario would be where you have a slow WAN link (pretty common!). Another way you could think of it is: Congestion occurs when the rate of input for incoming traffic exceeds the rate of output. In english? When going from high speed interfaces down to low speed interfaces you are prone to congestion. It’s no different then a theatre filled with people trying to get out of two doors at once..they can only move so fast!

Queuing is a temporary form of congestion management. It will ease some issues with congestion, but the long-term fix is fairly obvious- getting more capacity. This is not always feasible, unfortunately. So what can we do? We can alter the order that traffic leaves the node, so the low-priority traffic will be dropped first, and not the high priority (VoIP, critical applications, etc) traffic. By default, however, you will experience FIFO (First In, First Out) on interfaces that are faster then 2.048Mbps. Weighted Fair Queuing is used on interfaces slower then 2.048Mbps by default..but we’ll get into that in a bit. Depicted below is the way FIFO software queuing works. It is key to mention that there is only one hardware queue..and it uses FIFO. When we discuss creating new queues, and assigning traffic to certain queues, we are discussing the software queue only. As you can see below, FIFO treats all traffic equally, meaning the sensitive VoIP traffic will have to wait in line behind the web traffic. Not ideal!

Priority Queuing

Priority Queuing, or PQ, consists of four queues: high, medium, normal, and low. By default, all packets will be assigned to the normal queue when using PQ. PQ is a pretty harsh Queuing method, which generally leaves lower-priority queues starved. PQ works by always giving the high priority queue the right of way, so to speak. If there is something in the high queue, it is sent before any other traffic. If the high queue is empty, it will check the medium queue..send one packet from there, then move down to the low, and start the cycle over. What you get is the possibility of the queues below high not getting enough bandwidth, since the high queue is taking it all. The idea is almost right (treating the high priority traffic as such), but the implementation is a little off. Let’s look at some better options.

Round Robin (RR)

Round robin contrasts heavily in comparison to Priority Queuing. The Round Robin process passes one packet from one queue at a time, effectively (almost) dividing the bandwidth almost equally. This is assuming the packet sizes are almost the same size, however. If one queue consistently has packet sizes much larger then the rest, it will take more bandwidth then the rest. RR does a good job of dealing with queue starvation, but does not prioritize at all. It can also be somewhat unpredictable as to actual queue usage.

Weighted Round Robin (WRR)

WRR is a modification of RR, where each queue receives a weight, and as a result of the weight, receives that portion of the bandwidth. WRR allows you to prioritize to some degree, but can also be somewhat unpredictable as some queues may use more bandwidth then planned.

Weighted Fair Queuing (WFQ)

As I mentioned before, WFQ is the default queuing method used on interfaces that are slower then 2.048Mbps. WFQ is important to know because as we’ll find later, it is implemented in both LLQ and CBWFQ..which are popular methods of queuing these days. WFQ is flow-based, meaning that once it receives a flow, it is assigned to a FIFO queue. A flow consists of packets that have the same source IP, destination IP, Layer 4 protocol (TCP/UDP), IP Precedence, TCP/UDP source and destination ports. WFQ creates queues on the fly for each flow, so the number of queues can vary greatly.

Class-Based Weighted Fair Queueing (CBWFQ)

CBWFQ divides traffic into classes (that are configured by the user), which are assigned their own respective queue. Although each queue can use more bandwidth then configured for, they can have a minimum bandwidth guarantee, so that even in times of congestion, they will get that amount of bandwidth. CBWFQ can create up to 64 queues, with each one being a FIFO queue. It is worth noting that you can configure the class-default queue to be a WFQ. The class-default queue is used for all undefined traffic. Bear in mind that while the CBWFQ functions with WFQ as a whole, once the traffic has been divided up into it’s respective queue, they are FIFO. Think of it like this, you are sending traffic into separate lines based on preference, but once in that line, they are considered equal. CBWFQ is a big improvement over previous queuing methods, however it still falls short as it relates to voice or video applications. You’ll note that CBWFQ provides no method of identifying a priority queue..this can hurt applications sensitive to delay. To solve these issues we move on to LLQ!

Low Latency Queuing (LLQ)

At this point we can agree what we need is a queuing method that will give priority to delay-sensitive traffic, but at the same time not leave all other queues starved for bandwidth. Do you remember the issue with priority queuing? PQ gives priority to one queue- which is great, but leaves the other queues starved in times of congestion. WFQ is good, as it doesn’t leave flows starved, but it also provides no guarantee to any particular queues. LLQ solves these issues. LLQ is essentially a CBWFQ with at least one strict-priority queue. What does this mean? It means one queue receives priority, however that queue is policed, meaning in times of congestion it cannot use more bandwidth than is configured.

Ahhh..sigh of relief!

Here we are, at the end of Part II! As you have noticed by now, QoS can definitely be daunting, but if you take the time to tackle the theory behind it, it really isn’t that difficult. The difficulty (for me at least), has always been in the theory as opposed to the implementation! In Part III we will discuss Traffic shaping/policing, link efficiency, and congestion avoidance. Look forward to seeing you!

Many of you reading this have been mystifyed by terms like WFQ, WRED, Jitter, or DiffServ. My aim in Part I of QoS: Essentials, is to take some of the mystique surrounding Quality of Service away. Let’s get to it!

What is QoS?
While in Iraq, we stayed in tiny trailers with 2 soldiers sharing a room. It wasn’t horrible, but let’s just say you got to know your roommate a little bit more then you wanted to due to the close proximity. Two people was OK, compared to what some people had to do! Our commander was given his own trailer, because well, he was more important then the “foot soldiers” or “average joes”. If something happened to most people in my unit, the position can be filled. If something happens to the commander, it’s not quite as easy. Moving on, the commander receives his own room, thus putting a soldier out, and forcing him to move in with two guys already occupying a trailer. Their beds were nearly touching…for 15 months. What happened? QoS…sort of. Here’s what cisco has to say about QoS:

“QoS is the ability of the network to provide better or special service to a set of users or applications or both to the detriment of other users or applications or both.“

Based on that statement, we can agree that Quality of Service is essentially improving service for one service, while limiting the service of other users/applications. Think about it, you run a network with 1,000+ systems, and run a special application we’ll call AppX that the companies employee’s practically live on. You also have employee’s who are running P2P file transfer programs such as Gnutella, Kazaa, or Limewire. Without a QoS policy in place, heavy P2P use will prove to be detrimental to AppX, and thus decrease company productivity, resulting in less earnings, and ultimately hurt everyone! In the above scenario, using QoS, it would be completely possible to limit the P2P users to only using a percentage of the available bandwidth, and simultaneously guarantee a percentage of bandwidth to AppX..even in times of network congestion. Pretty outstanding!

Before we get into the options QoS provides you with, we must first understand the basic QoS models available to you as the network engineer.

• Best Effort: No QoS policy is implemented. All packets receive the same level of service.

• Integrated Services Model (IntServ): the first real end-to-end QoS solution. IntServ is based on a per-flow basis, where a “flow” is defined as a stream of packets with a common source, destination, and port number. Does not scale well, as each router using IntServ is required to maintain per flow state information.

• Differentiated Services (DiffServ): Not a guaranteed service model. Flows are combined into “classes”, and are treated on a per class basis. DiffServ is very scalable, and flexible. Packet classification, marking, and conditioning is done at the edge, where the core handles QoS on a Per-Hop Behavior (PHB) based on the packet’s class. DiffServ is highly scalable

QoS: Steps to implementation

There are three broad steps required to implement QoS. While the methods of implementation vary, the idea behind each is the same. They are as follows:

1. Identify traffic types and requirements

The first step consists of evaluating business requirements, and the applications/services currently in use on the network- then determining the requirements of each one. The idea behind this step is to later place apps/services with similar requirements into the same class, and then apply policies to each class. For example, if you have VoIP traffic, and have several other important, but not critical applications, you would give priority to the VoIP traffic (therefore getting it’s own class), and give the lower-priority traffic it’s own class.

2. Classifying traffic based on the requirements

Classifying traffic is essentially taking a group of applications and placing them into several classes. Marking is also usually done after classifying. Why should you mark? If you don’t, each device in your network that handles QoS will have to perform a deep-packet inspection along each hop. If you mark at the edge, each device that sees that marking (or “color”) after that will know what treatment it should receive already. Classification can be based on the incoming interface, Class of Service (CoS, Layer 2 marking) value, source or destination IP address, IP Precedence/DSCP value, MPLS EXP, or by the application type.

3. Define Policies for each class

Now that you’ve identified business/network requirements, we’ve classified and marked (you did mark your traffic, didn’t you?) our traffic..we must do something with all of it! This is where the action happens. This is where you can set a maximum/minimum bandwidth for a class to use, define a priority, or apply congestion management/avoidance (in other words, how to act when there is congestion present..which traffic should be dropped first, etc).

Trust Boundaries

So you know the steps to implementing QoS, and classifying/marking..but where do we start? The point at which traffic is marked in our network is defined as the “trust boundary”, or where the QoS markings are “trusted”. You should always try to mark closest to the source if possible. A common scenario I hear is network admins installing Cisco VoIP phones, with a PC connected to the 3-port switch on the phone. Most Cisco phones will provide a CoS (Layer 2 marking)/IP Precedence (Layer 3 marking) of 5 by default. If you “trust” the incoming values at the access switch, your trust boundary is at the IP phone/access switch.  This is ideal. This type of configuration ensures that all of your core/distribution nodes do nothing more then quickly read the markings, and act on the necessary policy for that class instead of deep packet inspection. In the diagram below, we see three different possibilities for trust boundaries:

A) In this scenario, the IP phone marks it’s own traffic. This is ideal, however not all IP phones can mark.

B) This option is still good, and is a pretty common place to mark- at the access layer. This is generally where you would mark if you just had a regular PC attached, or a phone not capable of marking it’s own traffic.

C) This one is OK. Generally the congestion in networks occur at the WAN links, so as long as you mark before it hits the WAN link, you should still be OK. This is why you generally want to mark as close to the source as possible.

Although this has not been a complete overview of QoS, I hope it’s cleared some things up for those new to QoS. In Part II we’ll discuss QoS policy, Congestion avoidance/management, and Queueing.