MPLS Series

January 29th, 2008 neteng

I’ve been thinking of starting a new series of articles focused on building an MPLS network. I’d like to start with a basic MPLS configuration inside a fictional ISP and from there, work my way towards topics such as MPLS VPNs and Traffic Engineering. But I’d like to gauge the reader interest in this topic. If you’d like to see some material on this, please leave a comment or shoot me an email!

Thanks,
neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in MPLS | 8 Comments »

Cisco Nexus 7000 Series Switch

January 28th, 2008 neteng

Cisco Nexus 7000

drool….

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in News | 1 Comment »

Monday Morning Networking - 1/28/2008

January 28th, 2008 neteng

Welcome back to the daily grind. Not much interesting happened this past weekend. Ran some errands, did some reading, spent some time in the gym and played some Xbox 360. Overall, a very relaxing weekend. So on to this morning’s networking news:

Enjoy your week!

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in MMNN | 1 Comment »

Friday Morning Fun - 1/25/2008

January 25th, 2008 neteng

Another weekend has arrived! I hope everyone’s week went smoothly. I’m looking forward to posting some of the things I’ve learned about MPLS next week.

Enjoy your two days off!

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in FMF | No Comments »

Dynamips on Two Dual-Core Computers

January 24th, 2008 neteng

I’ve recently had some emails asking how I managed to get Dynamips (Dynagen) to run over two dual-core PCs, sharing the load over all four CPUs. I decided it would be a good idea to put together a quick post on how I got this working. I won’t go into much detail on the basics as they are more than covered by other sources. I’ve posted the .CMD files used on each PC as well as a modified version of InternetworkExpert’s .NET file that needs to reside on both machines. This concept can certainly be applied to other .NET setups as well. Also, this was done on two Windows XP machines. I cannot guarantee that this will work for Linux, but I don’t see why not. Supposedly Dynamips runs much better over Linux, so you may not even need two machines if your single PC is running Linux and is powerful enough.

One of the most important things to remember is to make sure you do not have any firewalls blocking communication between the two machines. Either disable the firewalls or open the appropriate ports.

I initially ran into problems running the processes on the same control ports, thinking that it would work okay since they were on different machines. I seemed to resolve the issue by running each process on a unique control port. The .CMD files I have are as follows:

PC1:

@echo off
rem Launch a local copy of dynamips
set dynamips=%CD%\dynamips.exe
cd %TEMP%
start /belownormal /B /min “Dynamips” “%dynamips%” -H 7200
start /belownormal /B /wait “Dynamips” “%dynamips%” -H 7201
pause

PC2:

@echo off
rem Launch a local copy of dynamips
set dynamips=%CD%\dynamips.exe
cd %TEMP%
start /belownormal /B /min “Dynamips” “%dynamips%” -H 7202
start /belownormal /B /wait “Dynamips” “%dynamips%” -H 7203
pause

So you can see that we have each machine running two separate Dynamips processes, one for each CPU. The first machine is using ports 7200 and 7201. The second machines is using ports 7202 and 7203.

Here is my modified .NET file with key parts highlighted:

##############################################################################################
#
# Internetwork Expert Routing & Switching topology Version 4.0 mappings for dynamips/dynagen
# by: Brian McGahan, CCIE #8593
# bmcgahan@internetworkexpert.com
#
# For more information:
# Dynamips: http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator
# Dynagen: http://dyna-gen.sourceforge.net/
# Hacki’s Forum: http://hacki.at/7200emu/index.php
# Internetwork Expert’s Forum: http://forum.internetworkexpert.com
#
##############################################################################################

##################################################
#
# Define global router parameters for instance 1
#
##################################################

autostart=false
[localhost:7200]
udp = 11000

workingdir = C:\Program Files\Dynamips\sample_labs\internetworkexpert\working

[[3640]]
#
# Specify 3640 IOS image on Windows here:
image = C:\Program Files\Dynamips\images\C3640-IK.BIN
#
# Specify 3640 IOS image on Linux here:
# image = /ios/c3640-jk9o3s-mz.123-14.T7.extracted.bin
#
ram = 128
disk0 = 0
disk1 = 0
# Choose an idlepc value from the below
# idlepc = 0×60530870
# idlepc = 0×60530890
# idlepc = 0×60530a58
# idlepc = 0×60530abc
# idlepc = 0×605310c4
# idlepc = 0×605e92e8
# idlepc = 0×605e9364
# idlepc = 0×60531394
# idlepc = 0×605313d0
# idlepc = 0×605313ec
mmap = true
# ghostios = true

###########################
#
# Define router instances
#
###########################

[[Router R1]]
model = 3640
console = 2001
autostart = false
slot0 = NM-1FE-TX
slot1 = NM-4T
F0/0 = SW1 F1/1
S1/0 = FRSW 1
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\R1.initial.config.txt

[[Router R2]]
model = 3640
console = 2002
autostart = false
slot0 = NM-1FE-TX
slot1 = NM-4T
F0/0 = SW2 F1/2
S1/0 = FRSW 2
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\R2.initial.config.txt

[[Router R3]]
model = 3640
console = 2003
autostart = false
slot0 = NM-4E
slot1 = NM-4T
S1/0 = FRSW 3
S1/1 = FRSW 13
S1/2 = R1 S1/1
S1/3 = R2 S1/1
E0/0 = SW1 F1/3
E0/1 = SW3 F1/3
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\R3.initial.config.txt

[[Router R4]]
model = 3640
console = 2004
autostart = false
slot0 = NM-4E
slot1 = NM-4T
E0/0 = SW2 F1/4
E0/1 = SW4 F1/4
S1/0 = FRSW 4
S1/1 = R5 S1/1
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\R4.initial.config.txt

##################################################
#
# Define global router parameters for instance 2
#
##################################################

[localhost:7201]
udp = 11250

workingdir = C:\Program Files\Dynamips\sample_labs\internetworkexpert\working

[[3640]]
#
# Specify 3640 IOS image on Windows here:
image = C:\Program Files\Dynamips\images\C3640-IK.BIN
#
# Specify 3640 IOS image on Linux here:
# image = /ios/c3640-jk9o3s-mz.123-14.T7.extracted.bin
#
ram = 128
disk0 = 0
disk1 = 0
# Choose an idlepc value from the below
# idlepc = 0×60530870
# idlepc = 0×60530890
# idlepc = 0×60530a58
# idlepc = 0×60530abc
# idlepc = 0×605310c4
# idlepc = 0×605e92e8
# idlepc = 0×605e9364
# idlepc = 0×60531394
# idlepc = 0×605313d0
# idlepc = 0×605313ec
mmap = true
# ghostios = true

###########################
#
# Define router instances
#
###########################

[[Router R5]]
model = 3640
console = 2005
autostart = false
slot0 = NM-4E
slot1 = NM-4T
E0/0 = SW1 F1/5
E0/1 = SW3 F1/5
S1/0 = FRSW 5
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\R5.initial.config.txt

[[Router R6]]
model = 3640
console = 2006
autostart = false
slot0 = NM-4E
slot1 = NM-4T
E0/0 = SW2 F1/6
E0/1 = SW4 F1/6
S1/0 = FRSW 6
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\R6.initial.config.txt

[[Router SW1]]
model = 3640
console = 2007
autostart = false
slot1 = NM-16ESW
F1/7 = SW2 F1/7
F1/8 = SW2 F1/8
F1/9 = SW2 F1/9
F1/10 = SW3 F1/7
F1/11 = SW3 F1/8
F1/12 = SW3 F1/9
F1/13 = SW4 F1/7
F1/14 = SW4 F1/8
F1/15 = SW4 F1/9
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\SW1.initial.config.txt

##################################################
#
# Define global router parameters for instance 3
#
##################################################

[192.168.1.143:7202]

udp = 11500

workingdir = C:\Program Files\Dynamips\sample_labs\internetworkexpert\working

[[3640]]
#
# Specify 3640 IOS image on Windows here:
image = C:\Program Files\Dynamips\images\C3640-IK.BIN
#
# Specify 3640 IOS image on Linux here:
# image = /ios/c3640-jk9o3s-mz.123-14.T7.extracted.bin
#
ram = 128
disk0 = 0
disk1 = 0
# Choose an idlepc value from the below
# idlepc = 0×60530870
# idlepc = 0×60530890
# idlepc = 0×60530a58
# idlepc = 0×60530abc
# idlepc = 0×605310c4
# idlepc = 0×605e92e8
# idlepc = 0×605e9364
# idlepc = 0×60531394
# idlepc = 0×605313d0
# idlepc = 0×605313ec
mmap = true
# ghostios = true

###########################
#
# Define router instances
#
###########################

[[Router SW2]]
model = 3640
console = 2008
autostart = false
slot1 = NM-16ESW
F1/10 = SW3 F1/10
F1/11 = SW3 F1/11
F1/12 = SW3 F1/12
F1/13 = SW4 F1/10
F1/14 = SW4 F1/11
F1/15 = SW4 F1/12
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\SW2.initial.config.txt

[[Router SW3]]
model = 3640
console = 2009
autostart = false
slot1 = NM-16ESW
F1/13 = SW4 F1/13
F1/14 = SW4 F1/14
F1/15 = SW4 F1/15
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\SW3.initial.config.txt

[[Router SW4]]
model = 3640
console = 2010
autostart = false
slot1 = NM-16ESW
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\SW4.initial.config.txt

[[Router BB1]]
model = 3640
console = 2011
autostart = false
slot1 = NM-4T
S1/0 = BB3 S1/0
S1/1 = FRSW 21
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\BB1.initial.config.txt

##################################################
#
# Define global router parameters for instance 4
#
##################################################

[192.168.1.143:7203]
udp = 11750

workingdir = C:\Program Files\Dynamips\sample_labs\internetworkexpert\working

[[3640]]
#
# Specify 3640 IOS image on Windows here:
image = C:\Program Files\Dynamips\images\C3640-IK.BIN
#
# Specify 3640 IOS image on Linux here:
# image = /ios/c3640-jk9o3s-mz.123-14.T7.extracted.bin
#
ram = 128
disk0 = 0
disk1 = 0
# Choose an idlepc value from the below
# idlepc = 0×60530870
# idlepc = 0×60530890
# idlepc = 0×60530a58
# idlepc = 0×60530abc
# idlepc = 0×605310c4
# idlepc = 0×605e92e8
# idlepc = 0×605e9364
# idlepc = 0×60531394
# idlepc = 0×605313d0
# idlepc = 0×605313ec
mmap = true
# ghostios = true

###########################
#
# Define router instances
#
###########################

[[Router BB2]]
model = 3640
console = 2012
autostart = false
slot0 = NM-4E
E0/0 = SW2 F1/0
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\BB2.initial.config.txt

[[Router BB3]]
model = 3640
console = 2013
autostart = false
slot0 = NM-4E
slot1 = NM-4T
E0/0 = SW3 F1/0
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\BB3.initial.config.txt

[[Router TermServ]]
model = 3640
console = 2000
autostart = false
#
# Specify your local host’s loopback here from the network device list
# Too add a loopback in windows:
# http://support.microsoft.com/kb/839013
#
# E0/0 = NIO_gen_eth:\Device\NPF_{4065B11C-2A6C-4FD2-8204-A12A9A8328A4}
cnfg = C:\Program Files\Dynamips\sample_labs\internetworkexpert\initial.configs\RSTermServ.initial.config.txt

[[FRSW FRSW]]

# R1 to FRSW
1:102 = 2:201
1:103 = 3:301
1:113 = 13:311
1:104 = 4:401
1:105 = 5:501

# R2 to FRSW
2:203 = 3:302
2:213 = 13:312
2:204 = 4:402
2:205 = 5:502

# R3 to FRSW
3:304 = 4:403
3:305 = 5:503
13:314 = 4:413
13:315 = 5:513

# R4 to FRSW
4:405 = 5:504

# R6 to FRSW
6:51 = 21:51
6:100 = 21:100
6:101 = 21:101
6:201 = 21:201
6:301 = 21:301
6:401 = 21:401

If you compare this to IE’s initial .NET configuration, you’ll see that I’ve basically split the statements to run on four separate processes. So my setup is as follows:

PC1 - Process 1 R1, R2, R3, R4
PC1 - Process 2 R5, R6, SW1
PC2 - Process 1 SW2, SW3, SW4, BB1
PC2 - Process 2 BB2, BB3, TermServ, FRSW

You may also notice that I’ve split the UDP ports for NIOs apart by 250 integers. I ran into problems when I initially configured these to just be sequential: 11000, 11001, 11002, 11003. I believe this is because Dynamips dynamically creates UDP sockets for each ‘device’ under a process and by having them so close together, I was running into a problem of duplicating these port mappings. Once I separated them by a larger amount, I had no problem getting things running.

Once this configuration has been completed, launch both .CMD files and then launch the .NET file on the first PC (the one running on the control ports referenced by localhost). If everything cooperates, you’ll be up and running!

I hope you all find this article useful. Any feedback is appreciated.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in Dynamips, HOWTO, Tools | 16 Comments »

CCDE

January 24th, 2008 neteng

Well, I think I’ve been swayed as to where I’ll focus my future study efforts. Yes, the CCDE. Cisco has 19 books on its recommended reading list and whole lot of RFCs. I’ve already read two of the books (Jeff Doyle’s excellent Routing TCP/IP series), so that leaves me with 17. Guess I had better get started. :)

The first book I’m tackling is MPLS and VPN Architectures Vol. I and Vol. II by Ivan Pepelnjak. I’ll blog as much as possible about what I’m currently learning and it should be interesting to see the whole process take place. So far, I’ve covered the first few chapters of the first volume. It details why MPLS was introduced, the problems that it solves and how it operates over different media (i.e. Frame Mode vs. Cell Mode).

You’ll be hearing a lot more from me over 2008 about the various topics, so strap in for an exciting ride!

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in CCDE | No Comments »

R.I.P. Pix?

January 23rd, 2008 neteng

RIP PIX

I was just informed that in an effort to push their new ASA 5580 series security appliances, Cisco will be announcing the End of Sale of the PIX on January 28th. I would just like to say a few words…

“PIX. Sometimes you were a pain in the butt. Sometimes you wouldn’t cooperate with the rest of the network. But you were always there. When you did come through, you came through in spades! You will be missed.”

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in News | 1 Comment »

Monday (Tuesday) Morning Networking - 1/22/2008

January 22nd, 2008 neteng

Good morning everyone. My apologies for the late posting as yesterday was a vacation day for me (Martin Luther King Jr. Day). But it’s back to the daily grind!

Enjoy!

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in MMNN | No Comments »

Friday Morning Fun - 1/18/2008

January 18th, 2008 neteng

Happy Friday everyone! Looking forward to another full lab-free weekend. :) I’m a big ol’ nerd, so I will be checking out the local Star Trek Tour going on in Long Beach tomorrow. They’ll have sets from the original Star Trek, Star Trek: The Next Generation and more. Should be a lot of fun for a Trekkie (or Trekker, some people take real offense to Trekkie…those people are often crazy) like myself.

Have a great weekend folks.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in FMF | No Comments »

Basic QoS

January 17th, 2008 neteng

One topic I haven’t covered much is QoS. It’s something that I struggled with when first studying for the CCIE as there are a lot of different aspects to it. Thankfully, you won’t need to use some of the legacy stuff in today’s network. With that in mind, I’d like to cover some basics of modern implementations with this article, of course providing an example through Cisco IOS.

Now, I’m sure my audience knows better, but a lot of folks out there have great misconceptions as to what QoS actually does in the network. Firstly, QoS isn’t a tangible thing itself but is really a set of mechanisms that work together to manipulate traffic behavior. It’s composed of various functions such as congestion management (queuing), congestion avoidance (packet-drop behavior within a queue), traffic shaping (maintaining an average transfer rate using queuing), and traffic policing (maintaining an average transfer rate by dropping or remarking certain traffic).

Secondly, to many people’s dismay, QoS does not magically increase application speed and suddenly make T1 users think they’re running over an OC-48. QoS functions don’t really start to kick in until certain thresholds are met. For myself, I see two main reasons to implement QoS in the network (there are always exceptions):

  • Audio/Video streaming - When it comes to applications that are absolutely intolerant of any sort of jitter, delay or packet loss, video and audio streaming take the cake. These typically run over a connectionless protocol such as UDP, therefore bypassing the overhead required for a smarter protocol like TCP. A single late or dropped streaming media packet can greatly affect and annoy users. When you have this type of traffic on your network, QoS is essential so that typical data traffic does not impede performance. You always want to give this type of media traffic priority in your network.
  • Temporary solution - If your network is saturated, that means that you must either increase your bandwidth or reduce your traffic. It’s typical to do the first and not the second. There’s really no substitution for a bigger pipe. You can only prioritize and compartmentalize so much before your QoS policy starts to look ridiculously long and becomes self-defeating.

Occasionally, you’ll see some legacy QoS methods implemented throughout a network (priority queueing, custom queueing, etc.). I’d like to delve into the Class-Based Weighted Fair Queuing (CBWFQ), and Low Latency Queueing (LLQ) that you’ll see implemented in most networks today. For clarification, LLQ is just CBWFQ, but with a priority queue added in the mix. This queue will always be serviced before others, and that is why you will typically see it in use on unified networks (a fancy-schmancy name for a network containing data and multimedia traffic).

Topic

CBWFQ & LLQ

Definition

The are 3 keys to implementing CBWFQ/LLQ:

  1. Classify traffic that you would like to match.
  2. Create a policy that tells the router what to do with the traffic you’ve classified.
  3. Apply this QoS policy to an interface.

This traffic you want to match is put into a class-map. There are a variety of ways to match traffic. You can do it based on QoS markings such as DSCP, IP Precedence and CoS. You can match based on Layer 3 addressing and Layer 4 port information. You can match by protocol type. The list goes on. I recommend checking out the references at the end of this article for further details. Something to remember is that all traffic not matched by a class-map is put into a default class, labeled class-default.

Once you’ve created your class-map, you need to define what you want to do with that traffic. Typically, you will assign this traffic a certain amount of bandwidth (based on actual numbers or percentages) or assign the traffic to a priority queue. This is done through a policy-map.

After you’ve classified your traffic and applied it to a policy-map, it’s time to determine which interface you want this QoS policy to take place on. It’s importat to realize that you can only apply CBWFQ to outbound traffic. If you think about it, for the most part, inbound traffic can’t be controlled by the router (unless you’re using some end-to-end QoS solution like RSVP). It has a much greater ability to affect outgoing traffic.

Example

Here’s a simple network:

Basic QOS - LLQ

Let’s say that we’ve come up with the following QoS policy:

  • Voice traffic is to be guaranteed priority service and at least 40% of the outgoing bandwidth.
  • HTTP traffic to “blog.humanmodem.com” is to be guaranteed 50% of the outgoing bandwidth (Hey, this is my fake policy. I can do what I want! :) ).
  • The rest of the traffic is guaranteed the last 10% of available outgoing bandwidth.

After getting our policy down in plain English, it’s time to translate that to IOS-speak. We’ll being by defining the classes:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#class-map VOIP
R1(config-cmap)#match dscp ef
R1(config-cmap)#exit
R1(config)#class-map HTTP
R1(config-cmap)#match protocol http url “*blog.humanmodem.com*”
R1(config-cmap)#exit
R1(config)#class class-default
R1(config-pmap-c)#fair-queue
R1(config-cmap)#exit

There are a few things I want to highlight here before we move on. First, you’ll see that in our VOIP class, we are matching DSCP EF. This DSCP value is based on widely-used standards for Voice RTP traffic. Note that this only effects actual voice packets; not the control packets used to set up, maintain and tear down VoIP connections.

Secondly, we are using the Cisco-proprietary NBAR (Network Based Application Recognition) mechanism to match traffic in our HTTP class. This makes it easy for us to narrow down what we want to match concerning web-based traffic.

Lastly, you’ll see that we’ve configured a class named class-default. This is a class created by the Cisco router that matches all traffic not defined by other classes. We applied the fair-queue command to this class so that the queuing is consistent with the other classes. The class-default will normally run in FIFO mode unless configured otherwise.

Okay, so now we’ve defined our traffic. Let’s tell the router what we want to do with it:

R1(config)#policy-map QOS
R1(config-pmap)#class VOIP
R1(config-pmap-c)#priority percent 40
R1(config-pmap-c)#class HTTP
R1(config-pmap-c)#bandwidth percent 50
R1(config-pmap)#exit

As you can see, the configuration here is very basic. We’ve created our policy-map and named it QOS. We simply enter the class sub-configuration for each class and apply our policy. We’ve applied priority queuing to the VOIP class, therefore employing LLQ. The use of the priority command also has certain implications for this traffic. While the bandwidth statement guarantees a certain amount of a bandwidth to that class of traffic, the priority command acts as a policer to guarantee that it does not starve the other queues from being serviced. So if the link where this policy is applied is running at full capacity, you can feel secure in the knowledge that your voice traffic will never completely impede your other traffic and will be capped at 40% of the available bandwidth.

Another important thing to remember when configuring your policy is that you cannot mix-and-match how you apply the bandwidth command. That is to say, if I apply a percentage to one class, I cannot apply a static rate to another class. I must either use all percentages or all static rates.

Time to apply our policy-map to the FastEthernet1/0 interface:

R1(config)#int fa1/0
R1(config-if)#service-policy output QOS
I/f FastEthernet1/0 class HTTP requested bandwidth 50%, available only 35%

Eh? “What’s this”, you ask? Something that we need to remember is that by default, Cisco only allows you to reserve up to 75% of an interface’s bandwidth. We created a policy where we’re trying to reserve 90% of the bandwidth. After first reserving 40% for the VoIP traffic, the router tries to allocate 50% for the HTTP traffic and fails because only 35% is left to be allocated. This can be easily changed with the following command:

R1(config)#int fa1/0
R1(config-if)#max-reserved-bandwidth 90
R1(config-if)#service-policy output QOS
R1(config-if)#

And there we have it. No problemo. Let’s verify that our QoS configuration took:

R1#sh int fa1/0
FastEthernet1/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is ca00.0ee8.0008 (bia ca00.0ee8.0008)
Internet address is 192.168.12.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of “show interface” counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 2/2 (allocated/max allocated)
Available Bandwidth 0 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
807 packets output, 76917 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

We can also view our applied policy-map:

R1#show policy-map int fa1/0
FastEthernet1/0

Service-policy output: QOS

Class-map: VOIP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
Queueing
Output Queue: Conversation 265
Bandwidth 40 (%)
Bandwidth 40000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http url “*blog.humanmodem.com*”
Queueing
Output Queue: Conversation 266
Bandwidth 50 (%)
Bandwidth 50000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
316 packets, 29622 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing

Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0

References

Books:

Configuring Weighted Fair Queuing

NBAR Information

An Expedited Forwarding PHB

This example was very basic, but anything more complex would use the same tools. As always, the most important thing you can do when putting implementing QoS is to have a solid plan in place and written policies. This gives you a strong base to consistently refer to as you complete the process.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in HOWTO, Networking, QoS | 1 Comment »