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!

Well, I am feeling a lot better. Whatever I had was horrible, and took about 7-9 days to get rid of. I don’t feel 100% yet, but I’m back at work for better or worse. Figured I would make a post with my current status as it relates to CCIE study. I’ve been studying cisco docs a lot lately, mostly centered around Frame Relay. I haven’t labbed much in the past week since I have been sick, and not gotten a lot of sleep. I plan on labbing tomorrow morning, but we’ll see how I feel after I get off work. Right now I work 7:30pm till 7:30am, so when I get home I’m usually ready to crash! Here’s some other updates:

• 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!

Well, I wish I had more to update you all with. I got very sick last week, with a temp of 102F, chills, body aches, and all the general symptoms that come with being “really” sick. I guess this was my karma, as I had been joking about how the H1N1 (formerly the “swine flu”) virus was being blown up by the media. Shortly after I got hit with whatever this is, and it hit me hard. I never saw the doctor, but I am recovering slowly, so it looks like I’ll live.

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..

Alright, this isn’t a straight tech article, but I just wanted to post showing that I’ve made progress. I finished 100% of IEWB Vol I frame relay labs three times now, the first using help and looking up articles to get things straight, and the last two with no outside help, just trying to make sure I understand why things are happening and doing lots of verification. I decided to move onto the RIP labs again, because last time I did them they were over P2P serial links, not a FR cloud. The biggest thing I’ve noticed with Frame relay..be patient. Verification is key with FR, and patience is important as well. I’ve noticed on several occasions where a PVC would not come up, and a simple “shut/no shut” or “Clear frame inarp” was required. A couple of times just waiting was all it took for the PVC to come up. A lot of this comes from Inverse-ARP, which from what I’ve read/heard can really mess you up on the lab if enabled, but still, it’s good to know! Anyway, I’ll post more once I get a little further. I’m also in the process of watching Jeremy Ciora’s CBT nuggets for the CCIE, as well as reading.

For more on adding Frame Relay to your CCIE studies, see CT’s (Cisco_trooper) blog

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.