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 »

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:

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:

• Network Warrior
• Cisco QOS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition) (Exam Certification Guide)
• End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs (Networking Technology)

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 »

How I Passed the CCIE Routing & Switching Lab

January 9th, 2008 neteng

It has been one day since I received the good news and it still hasn’t really sunken in. I find myself re-reading my congratulations email over and over and checking my CCIE status page at Cisco. What a ride it has been to get here. I thought that some people would be interested in what I did to achieve a passing grade on this beast of a exam.

First, let me just say that I did not go in with the expectation that I would pass the first time around. I studied with the intention of not having to come back, but I tried not to get my hopes up, no matter how good I felt after the exam. It was a tough view to maintain though, as after the exam, I felt I did really well. But we’ve all heard the stories of the ~10% pass rate for first-timers and being that I was the only person at the exam who was a first-timer, I assumed that my good feelings right after the exam may have been misplaced. Surely I missed more questions than I thought I had!

But I think my dedication and preparation really paid off and I wanted to share my path to success with you guys. Here are some tips that I hope will benefit you in your studies:

Build a solid foundation

There is simply no way to pass the CCIE lab without having a fundamental knowledge of how networks operate. How does ARP work? How does a switch build it’s MAC address table? How does Spanning Tree protocol decide which ports to open and which ports to shut? How does OSPF communicate and form relationships in different network environments? Without knowing what is going on under the hood, you’ll have a difficult time consistently coming up with a correct answer to a problem. I found the experience that I gained through on-the-job projects as well as through my CCNA & CCNP certification studies to be invaluable. I could not have gotten as far as I did without those things. If you understand the ‘root’ of a certain technology, it makes the rest of that technology ‘tree’ easier to understand. You can’t understand mutual routing protocol redistribution at multiple entrance/exit points if you don’t understand how administrative distance works. You won’t understand administrative distance without understanding how a router chooses which routes to install in it’s routing table… etc, etc.

Tools

I used many different tools to achieve my goal. I used a single lab workbook - Internetwork Expert v4.1 for Dynamips, Part I. It may surprise you that a large amount of variety was included in just these 10 labs. I mainly stuck to this limited amount of labs so that I could work on my configuration speed, which I’ll cover later. I also read a variety of books: the Routing TCP/IP series - Volume I and Volume II, Wendell Odom’s QoS Exam Guide, Cisco LAN Switching, and Developing IP Multicast Networks. One book that I’d like to specifically mention is one that has been helpful throughout my whole Cisco certification journey and career in general - Internetworking with TCP/IP, Vol 1 (5th Edition). It’s has a permanent spot on my bookshelf and probably should have one on yours.

Probably the tool that I owe most of my thanks to is Dynamips (using the Dynagen front-end). It is a godsend for the CCIE candidate. There is no way I would have passed without spending thousands of dollars on my own rack or through online rack rentals. The only time I used rack rentals was when I wanted to perform 3550/3560-only switching tasks. Otherwise, Dynamips was my best friend.

And last, but not least, we can’t forget Cisco’s own documentation. You are provided access to Cisco’s UniverCD in the lab and you will most definitely benefit from knowing your way around it.

Read, Do

As we all know, the CCIE lab exam is a hands-on test. While pure theoretical and book knowledge may have been enough to allow you to ace the written exam, practical experience is a must for the lab. If you’re like most people, you will best grasp an idea by participating in it and seeing it occur through your own eyes. Outside of lab workbooks, I would often formulate my own network topologies and problems, and implement them in Dynamips. Dig around the UniverCD and pick a technology. Read up on some of the commands and implement them. Run some debugs and see how the IOS behaves. It’s a quick and easy way to get your game to where it needs to be.

Read some more, Do some more

I think an example would make this clearer: I started my studies at the switching level and worked my way through routing, QoS, security, IP applications, etc. I found that when doing some of the mock lab exams, I had run into some switching topics that I didn’t even remember covering. As you go through your studies, you’ll probably find the same thing. It helped me to go over each topic in the CCIE Lab blueprint more than once, making sure that I was at least familiar with each feature and where to find it in the Cisco UniverCD.

I also found that when there were problems that could be solved in multiple ways, I may only know 1 out of 3 ways to do it. It’s important that you understand the root cause of a problem and the multitude of ways in which it can be solved. You may run into a question in the lab where you’re not allowed to use the single method you know so well. If you don’t know the other two, you can kiss those points goodbye as well as any other tasks that may rely on correctly answering that question.

Focus on the core

You’ll find that the bulk of your lab points come from your core routing and switching tasks. This is discussed in an excellent CCIE lab strategy presentation put out by InternetworkExpert. By the end of the first half of the lab, you want to have your core up and running smoothly. You don’t want to have to implement a multicast solution and actually configure something that is incorrect, only because your core routing is incorrect. This was a big motivation for using a minimal number of practice labs. I wanted to focus mainly on my speed, not just the variety of technologies. I could easily look up the odd technologies here and there in the UniverCD and create my own scenarios for understanding, but I had to make sure that I could configure all Layer 2 (LAN & WAN), IGP and BGP possibilities like the back of my hand.

For those of you who are on the CCIE journey, I wish you the best of luck. I certainly advise you to try and get as much rest as possible before the momentous day. I found that I was most relaxed by not spending the last few days before my exam doing practice labs and staying up all night reading. I looked over some general notes, made sure I knew my way around the UniverCD and that was it. Remember, this is just a single exam. If you fail, try, try and try again until you conquer the beast. You will win. You just need to be prepared. Easy for me to say, I know; I passed the first time. But I went in with the mindset that if I failed, I would not let that stop me from achieving my goal of CCIE certification. You should come into the lab with the same mindset. Only you will know if you feel ready enough. If you’re not, the CCIE lab will let you know! I would say that you need to feel comfortable with as much as possible in the blueprint. Learn to navigate around the UniverCD and know almost instantly where you will need to go for answers.

Thanks for reading.

neteng

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

Posted in HOWTO | 13 Comments »

Cisco IOS IP SLA (Service Level Agreements) Tool

December 12th, 2007 neteng

In today’s workplace, it’s no longer enough to throw up a couple of routers and switches, establish connectivity and declare that the network is complete. Managed services have become a hot item and Cisco has provided some tools to help us better manage the network and alert us to problems as they arise. In a world of VoIP and video conferencing, the Cisco IOS IP SLA service is indeed a powerful tool to add to your network monitoring toolkit.

Topic

Cisco IOS IP SLAs

Definition

Cisco’s SLA tool allows you to proactively monitor network conditions by generating traffic on a device and responding to that traffic from another device. It makes it easier to do such things as verify your QoS policy is working and make sure you’re meeting uptime agreements. When set up in an end-to-end manner, you can simulate the experience of a user and get a truer picture of their network performance. The SLA feature set is huge and results can be pulled up from the command line or via SNMP.

When configuring SLA entries, we need to have both a transmitter and a responder. The responder setup is very basic. To begin communications, the transmitter sends control messages to the responder. These control messages inform the responder as to what port it should listen on for transmitter requests (UDP or TCP). Enabling the responder service itself may not be necessary for some operations if the device is already listening on ports being tested (i.e. HTTP services).

Once an SLA operation has been configured on the transmitter, it’s operation needs to be scheduled. Statistics will only be gathered when the configuration is operational. Operations can be scheduled to start immediately, at a pre-determined date/time and they can even be triggered to start by certain events.

Instead of reinventing the wheel, I’ll refer you to Cisco’s awesome table of SLA capabilities.

Example

Because of the depth of the SLA tool, I’m going to just restrict myself to a very basic configuration. This will give you just a small glimpse into the possibilities the lie ahead. I recommend reading the references at the end of this article to go a little more in-depth. Here is our three-router topology:

We have OSPF running in a single area for these three routers, providing full end-to-end connectivity. Let’s go ahead and turn on the responder service on R3:

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip sla responder

Let’s verify the service now:

R3#show ip sla responder
IP SLAs Responder is: Enabled
Number of control message received: 0 Number of errors: 0
Recent sources:
Recent error sources:

As you can see, we’re up and running on one end of our network. We have not received any control messages or data from our transmitter though. We’re going to have R1 act as our transmitter and perform the UDP Echo operation. This will measure the end-to-end response time for UDP traffic. First, we’ll configure our operation:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip sla monitor 1
R1(config-ip-sla)#udp-echo 150.1.3.3 1234
R1(config-ip-sla-udp)#frequency 30
R1(config-ip-sla-udp)#exit
R1(config)#

What we’ve done here is configure an operation with an ID of 1, and within that operation, configured the router to send a UDP packet to R3’s Loopback0 address on port 1234. We’ve also set it to send a packet every 30 seconds (versus the default of 60 seconds). After this has been created, we need to schedule it to run:

R1(config)#ip sla schedule 1 life forever start-time now

The operation is scheduled to run immediately and never expire. Let’s take a look at the configuration we’ve just created:

R1#show ip sla configuration 1
IP SLAs, Infrastructure Engine-II.
Entry number: 1
Owner:
Tag:
Type of operation to perform: udp-echo
Target address/Source address: 150.1.3.3/0.0.0.0
Target port/Source port: 1234/0
Request size (ARR data portion): 16
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0×0
Verify data: No
Data pattern:
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 30 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None

I’ve highlighted the pertinent parts of our configuration. Now that we’ve let this run for a bit, lets check the results on both routers:

R1#show ip sla statistics 1

Round Trip Time (RTT) for Index 1
Latest RTT: 68 milliseconds
Latest operation start time: *13:35:48.015 UTC Wed Dec 12 2007
Latest operation return code: OK
Number of successes: 9
Number of failures: 0
Operation time to live: Forever

R3#show ip sla responder
IP SLAs Responder is: Enabled
Number of control message received: 9 Number of errors: 0
Recent sources:
192.168.12.1 [13:36:17.971 UTC Wed Dec 12 2007]
192.168.12.1 [13:35:47.971 UTC Wed Dec 12 2007]
192.168.12.1 [13:35:17.959 UTC Wed Dec 12 2007]
192.168.12.1 [13:34:47.951 UTC Wed Dec 12 2007]
192.168.12.1 [13:34:17.999 UTC Wed Dec 12 2007]
Recent error sources:

Pretty cool, huh? Now you should be asking yourself, “How can I make this information useful?” Good question. One thing we can do is use this SLA entry as an object that can be tracked by other commands. Let’s create a static route that will only be available if the SLA operation we created is successful:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#track 1 rtr 1
R1(config-track)#exit
R1(config)#ip route 123.123.123.0 255.255.255.0 192.168.12.2 track 1

As a side note, you’ll notice that the track statement refers to rtr. This is the old name Cisco used for the SLA tool in previous IOS versions. It stands for Response Time Reporter. As you can see, it’s legacy lives on in the current IOS. We can verify that our static route is currently in R1’s routing table:

R1#sh ip route static
123.0.0.0/24 is subnetted, 1 subnets
S 123.123.123.0 [1/0] via 192.168.12.2

Now let’s shut down our Loopback0 interface on R3 (remember that it’s the target of our SLA operation):

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int lo0
R3(config-if)#shut

This should effectively kill our UDP echo operation:

R1#sh ip sla statistics 1

Round Trip Time (RTT) for Index 1
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *13:48:17.903 UTC Wed Dec 12 2007
Latest operation return code: No connection
Number of successes: 32
Number of failures: 1
Operation time to live: Forever

Interesting! Now let’s see if we still have our static route:

R1#sh ip route 123.123.123.0
% Network not in table

Cool! As you can see, we can really take more control of how our networks behave by utilizing the SLA tool. Once we turn R3’s Loopback0 interface back up, we will see the static route reappear in our routing table after the next UDP echo interval.

References

Cisco IOS IP SLAs Configuration Guide, Release 12.4

Service Assurance Agent (SAA) and the Management Engine

Well folks, that’s just the beginning of what this wonderful tool can do. Be sure to scour the references I’ve linked to and see how you can put it to use in your networks.

neteng

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

Posted in HOWTO, Networking, Routing, Tools | 1 Comment »

Reflexive Access Lists

December 10th, 2007 neteng

Starting with this post, I’m going to attempt a new format to my lab-type articles. I want to try and maintain some consistency between my presentations, in the hope that they will be cleaner and easier to comprehend. With that in mind, let’s get started!

Topic

Reflexive ACLs

Definition

Reflexive ACLs provide network engineers the tools to implement session filtering, albeit rather crudely. Their creation and application are almost identical to standard and extended access lists, but they are used to create dynamic entries for return traffic when an outgoing connection is attempted. Essentially, dynamic ACL entries are built on the return-traffic interface to allow the other side of the traffic pair to come in. This way, you can practically have an ip deny any any rule on your outside interface (untrusted network) and only allow traffic to come in that was initiated from your inside (trusted) network. Now, this can already be achieved somewhat through the established keyword when creating an access-list; but this only applies to TCP traffic. Reflexive ACLs will keep track of traffic pairs for UDP, ICMP, etc.

For TCP sessions, dynamic entries are removed 5 seconds after two FIN flags are detected (the five seconds allows a graceful shutdown window), or immediately after matching a TCP packet with a RST flag. Entries for all protocols will be removed if idle for the timeout period. One gotcha with reflexive ACLs is when using applications that switch port numbers during a session. A key example of this is FTP. Passive-mode FTP must be used so that a dynamic port is not requested for data transfer traffic.

Before deploying reflexive ACLs, you need to look at your network/traffic flows, and determine how to apply them to your interfaces. Logically, you have two types of interfaces: internal and external. The most typical scenario is to apply the ACLs to the untrusted external network interface (i.e. Internet) of your router. If you happen to have multiple interfaces on the router (i.e. internal, external and DMZ), then you will probably want to configure the reflexive ACLs on your trusted internal interface so as not to affect traffic initiated from the outside to your DMZ.

Reflexive ACLs can only be defined through named extended access lists, but they can be called from other types of access-lists (standard numbered, etc.).

Example

In our example, we’re going to use a simple inside/outside interface configuration. The first thing we need to look at is our traffic policy. The IT manager has decided that he wants to only allow people to surf the web (HTTP/HTTPS) and deny all other traffic. With that in mind, we need to construct an outbound access-list that will reflect our outgoing traffic to an inbound access-list. Basically, outgoing entries will be mirrored, with the incoming and outgoing hosts flipped in the ACL statement. Here’s our topology:

Our configuration will go onto R2. We will initiate traffic from R1 to R3.

With the policy in mind, let’s start our configuration off by creating our access-lists:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip access-list extended OUTBOUND
R2(config-ext-nacl)#permit tcp any any eq 80 reflect WEB
R2(config-ext-nacl)#permit tcp any any eq 443 reflect WEB
R2(config-ext-nacl)#deny ip any any

Of course, the deny ip any any statement at the end is implied, but I put it in for clarity. You can see that we are reflecting all outbound HTTP/HTTPS traffic to a dynamic ACL named WEB. What we will now do is reference WEB in the inbound ACL so that it will be evaluated before permitting or denying traffic:

R2(config)#ip access-list extended INBOUND
R2(config-ext-nacl)#evaluate WEB
R2(config-ext-nacl)#deny ip any any

Now let’s apply them to our outside interface (FastEthernet1/0):

R2(config)#int fa1/0
R2(config-if)#ip access-group OUTBOUND out
R2(config-if)#ip access-group INBOUND in

Let’s take a look at our ACLs:

R2#show access-list
Extended IP access list INBOUND
10 evaluate WEB
20 deny ip any any
Extended IP access list OUTBOUND
10 permit tcp any any eq www reflect WEB
20 permit tcp any any eq 443 reflect WEB
30 deny ip any any
Reflexive IP access list WEB

You can see that we our reflexive ACL WEB is listed, but currently is devoid of entries. For our test, lets enable HTTP services on R3:

R3(config)#ip http server

Now let’s initiate some HTTP traffic from R1 to R3 and then take a look at our reflexive ACL again:

R2#show access-lists
Extended IP access list INBOUND
10 evaluate WEB
20 deny ip any any
Extended IP access list OUTBOUND
10 permit tcp any any eq www reflect WEB (8 matches)
20 permit tcp any any eq 443 reflect WEB
30 deny ip any any
Reflexive IP access list WEB
permit tcp host 150.1.3.3 eq www host 192.168.12.1 eq 14867 (12 matches) (time left 294)

And there we have it! You can see that there is a timer associated with the dynamic entry. The default is 5 minutes, but this can be changed with the ip reflexive-list timeout command.

If we tried to send uninitiated traffic from R3 to R1, it would not pass the evaluate statement and therefore, be dropped due to the deny ip any any statement.

Well, that’s about all there is to it folks! Remember, if we ran into a situation where we needed to apply the ACLs to the internal interface, we would simply change the direction in which the reflect and evaluate statements are applied. The reflect statements would now be on the inbound ACL and the evaluate statements would applied to the outbound ACL.

I hope this has been helpful for you!

References

Configuring IP Session Filtering (Reflexive Access Lists) - Cisco.com

neteng

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

Posted in HOWTO, Networking, Security | 1 Comment »

Internetwork Expert - Catalyst QoS Session

December 5th, 2007 neteng

Sorry folks, not much time today (or probably tomorrow - dentist appointment) for an in-depth article. Instead, I figured that I’d post a link to an awesome webinar that was put together by the good folks at Internetwork Expert. This ought to provide some good material for you to digest on the way the Catalyst 3550/3560 switches deal with QoS:

Technology Seminar: CCIE Catalyst QoS_1

neteng

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

Posted in HOWTO, Links | 1 Comment »

TCP Intercept

December 4th, 2007 neteng

On the Internet, TCP is widely used by many applications, web servers being the most obvious. In the early days of the Internet, prior to the plethora of firewalls and security appliances now in place at most companies, it was relatively simple to instigate a Denial of Service (DoS) attack on a server listening on a TCP port. A malicious person could continuously open TCP connections to such a server and render it useless, as the CPU would be pegged trying to process and reply to the connections. Here’s a little reminder of TCP’s three-step handshake process:

Now there are smarter devices out there to mitigate these types of attacks, but in a pinch, IOS can prove to be useful until a more dedicated piece of equipment is in place. If you’re using vanilla-IOS, without the IOS Firewall feature (CBAC), TCP Intercept is your key to protection. It can be configured to run in two modes:

Intercept

Intercept mode is the default. The router will actually intercept incoming SYN packets and sends a SYN/ACK response on behalf of the server. If an ACK is then received by the router, it will forward the original SYN to the server and let the handshake process take it’s natural course.

Watch

In this mode, the router allows the SYN packets to come into the server, but watches the connection until it’s established. If the connection has failed to complete after the watch-timeout expires (default of 30 seconds), the routers sends a RST to the server to clear up the connection.

This is the basic operation of TCP Intercept. To enable it, we first need to define an access-list for the traffic that will be affected. It’s common practice to cover traffic from any source but towards specific destinations (i.e. web servers, terminal servers). Once the access-list is defined, we can enable TCP Intercept with a single command in global configuration mode:

ip tcp intercept list access-list-number

The mode can also be changed:

ip tcp intercept mode {intercept | watch}

As the connection attempts continue to mount and the router begins to sense an attack is in progress, it enters into what’s termed aggressive mode. This mode can be entered through two different ways: The total number of incomplete connections or the number of connection requests within a one-minute period. These values can be adjusted with the following commands:

Total number of incomplete connections

ip tcp intercept max-incomplete high number - Sets the threshold for triggering aggressive mode.
ip tcp intercept max-incomplete low number - Sets the threshold for stopping aggressive mode.

Number of connection requests within one-minute period

ip tcp intercept one-minute low number - Sets the threshold for stopping aggressive mode.
ip tcp intercept one-minute high number - Sets the threshold for triggering aggressive mode.

The three other adjustable timers for TCP Intercept include:

watch-timeout - Default of 30 seconds. This changes the time allowed for the TCP connection to become established.
finrst-timeout - Default of 5 seconds. This changes the time allowed for receipt of a RST or FIN before the connection is dropped.
connection-timeout - Default of 24 hours. This changes the amount of time the router will manage an idle connection.

The last bit of adjustment we can make is the way in which connections are dropped when operating in aggressive mode. The default is to have the oldest connections dropped, but we can change this to random:

ip tcp intercept drop-mode {oldest | random}

As always, let’s get our hands dirty and configure this in a live network:

R1 is acting as our host. We’re going to have him telnet to the telnet server (which is really a router with a loopback interface - 150.1.3.3) and turn on TCP Intercept mode at R2 in the middle.

R2 is configure with the following statements:

access-list 101 permit tcp any any
ip tcp intercept list 101

We’ll initiate a telnet connection from R1. Let’s take a quick peek at our connections and statistics in action:

R2#sh tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode

Established:
Client Server State Create Timeout Mode
192.168.12.1:53517 150.1.3.3:23 ESTAB 00:00:02 23:59:58 I

R2#sh tcp intercept statistics
Intercepting new connections using access-list 101
0 incomplete, 0 established connections (total 0)
0 connection requests per minute

Now to put TCP Intercept to work, I decided to block inbound SYN packets at R1 by configuring an ACL on the outgoing interface:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#access-list 150 deny tcp host 150.1.3.3 any syn
R1(config)#access-list 150 permit ip any any
R1(config)#int fa0/0
R1(config-if)#ip access-group 150 in

Let us once again initiate a telnet session from R1 to our telnet server. Aha! We see a different story on R2:

R2#sh tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode
192.168.12.1:59187 150.1.3.3:23 SYNRCVD 00:00:02 00:00:00 I

Established:
Client Server State Create Timeout Mode

R2#sh tcp intercept statistics
Intercepting new connections using access-list 101
1 incomplete, 0 established connections (total 1)
1 connection requests per minute

There you have it! The basics of TCP Intercept. Something to keep in mind is that this security service is named TCP Intercept for a reason. Any other kind of DoS attack (through UDP or ICMP) that is instigated towards the other side of that router will not be affected as those are connectionless protocols and therefore do not have a state that can be easily tracked.

I hope you enjoyed this article.

neteng

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

Posted in HOWTO, Networking, Security | 1 Comment »

BGP - Confederations

December 3rd, 2007 neteng

Our lab topic for today is BGP confederations. It assumes a familiarity with BGP and it’s operations. Confederations are useful when you have a large AS filled with BGP-enabled routers, but are limited in spots to partial-mesh connectivity. That is to say, your number of iBGP connections is small and/or it also makes sense to create sub-ASes for business policy reasons. Each confederation is composed of one or more sub-AS (though why you’d have a confederation composed of only a single sub-AS, I don’t know). External ASes do not see the internal structure of the confederation. They will see all communication as coming from only the major AS number. Neighboring routers in each sub-AS treat the connection between each other as eBGP except in regards to the following items:

Administrative Distance - routes advertised between confed-AS peers through BGP will still show up with an iBGP AD of 200
Local Preference - Maintained throughout major AS
MEDs - Maintained throughout major AS
Next-hop - Maintained throughout major AS
AS_PATH length - Maintained throughout major AS

Here’s the diagram for this lab (click on the diagram for a larger version):

Let’s take a look at the BGP configuration for our 4 routers and we’ll go through the main points:

R1

router bgp 100
no synchronization
bgp router-id 150.1.1.1
bgp log-neighbor-changes
redistribute connected
neighbor 192.168.12.2 remote-as 200
no auto-summary

R2

router bgp 65002
no synchronization
bgp router-id 150.1.2.2
bgp log-neighbor-changes
bgp confederation identifier 200
bgp confederation peers 65001
redistribute connected
neighbor 192.168.12.1 remote-as 100
neighbor 192.168.23.3 remote-as 65001
no auto-summary

R3

router bgp 65001
no synchronization
bgp router-id 150.1.3.3
bgp log-neighbor-changes
bgp confederation identifier 200
bgp confederation peers 65002
redistribute connected
neighbor 192.168.23.2 remote-as 65002
neighbor 192.168.23.2 send-community
neighbor 192.168.34.4 remote-as 65001
no auto-summary

R4

router bgp 65001
no synchronization
bgp router-id 150.1.4.4
bgp log-neighbor-changes
bgp confederation identifier 200
bgp confederation peers 65002
redistribute connected
neighbor 192.168.34.3 remote-as 65001
neighbor 192.168.34.3 send-community
neighbor 192.168.34.3 route-map SET_COMMUNITY out
no auto-summary

The key commands when configuring BGP confederations are:

router bgp [sub-AS#]
bgp confederation identifier [main-AS#]
bgp confederation peers [confederation peer AS#s]

Remember that you will always create the bgp process in the router with the sub-AS number. The main AS number is identified with the bgp confederation identifier command and all sub-AS peers are identified through the bgp confederation peers command. Also, in this case, all of our routes are originating from a redistribute connected command, which puts the connected networks of each router in the bgp advertisements. The actual networks aren’t important for this lab; they’re just there to put some meat in our routing tables.

From the diagram and configuration, you can see that we have 2 main ASes - AS100 & AS200. Within AS200, we have two sub-ASes - AS65001 & AS65002. Let’s pull up the BGP table on R1:

R1#sh ip bgp
BGP table version is 21, local router ID is 150.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 111.1.1.0/24 0.0.0.0 0 32768 ?
*> 111.2.2.0/24 0.0.0.0 0 32768 ?
*> 113.3.0.0/16 0.0.0.0 0 32768 ?
*> 150.1.1.0/24 0.0.0.0 0 32768 ?
*> 150.1.2.0/24 192.168.12.2 0 0 200 ?
*> 150.1.3.0/24 192.168.12.2 0 200 ?
*> 172.31.1.0/24 0.0.0.0 0 32768 ?
*> 172.31.2.0/24 192.168.12.2 0 0 200 ?
*> 172.31.3.0/24 192.168.12.2 0 200 ?
*> 172.31.4.0/24 192.168.12.2 0 200 ?
* 192.168.12.0 192.168.12.2 0 0 200 ?
*> 0.0.0.0 0 32768 ?
r> 192.168.12.1/32 192.168.12.2 0 0 200 ?
*> 192.168.12.2/32 0.0.0.0 0 32768 ?
*> 192.168.23.0 192.168.12.2 0 0 200 ?
*> 192.168.23.2/32 192.168.12.2 0 200 ?
*> 192.168.23.3/32 192.168.12.2 0 0 200 ?
Network Next Hop Metric LocPrf Weight Path
*> 192.168.34.0 192.168.12.2 0 200 ?
*> 192.168.34.3/32 192.168.12.2 0 200 ?
*> 192.168.34.4/32 192.168.12.2 0 200 ?

Notice that all routes from R2 (R1’s eBGP-connected neighbor) appear to come only from AS200. This tells us that R1 knows nothing about AS200’s internal sub-ASes. You can make a comparison between the way network summarization works and the way confederations work. If one router is summarizing a group of networks to another router, that other router (in most cases) doesn’t care about the individual subnets contained in the summary. The behavior is virtually identical in this case. The AS_PATH variable will only contain the main AS.

Now let’s see what the bgp table looks like on R2:

R2#sh ip bgp
BGP table version is 23, local router ID is 150.1.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 111.1.1.0/24 192.168.12.1 0 0 100 ?
*> 111.2.2.0/24 192.168.12.1 0 0 100 ?
*> 113.3.0.0/16 192.168.12.1 0 0 100 ?
*> 150.1.1.0/24 192.168.12.1 0 0 100 ?
*> 150.1.2.0/24 0.0.0.0 0 32768 ?
*> 150.1.3.0/24 192.168.23.3 0 100 0 (65001) ?
*> 150.1.4.0/24 192.168.34.4 0 100 0 (65001) ?
*> 172.31.1.0/24 192.168.12.1 0 0 100 ?
*> 172.31.2.0/24 0.0.0.0 0 32768 ?
*> 172.31.3.0/24 192.168.23.3 0 100 0 (65001) ?
*> 172.31.4.0/24 192.168.34.4 0 100 0 (65001) ?
* 192.168.12.0 192.168.12.1 0 0 100 ?
*> 0.0.0.0 0 32768 ?
*> 192.168.12.1/32 0.0.0.0 0 32768 ?
r> 192.168.12.2/32 192.168.12.1 0 0 100 ?
* 192.168.23.0 192.168.23.3 0 100 0 (65001) ?
*> 0.0.0.0 0 32768 ?
Network Next Hop Metric LocPrf Weight Path
r> 192.168.23.2/32 192.168.23.3 0 100 0 (65001) ?
*> 192.168.23.3/32 0.0.0.0 0 32768 ?
*> 192.168.34.0 192.168.23.3 0 100 0 (65001) ?
*> 192.168.34.3/32 192.168.34.4 0 100 0 (65001) ?
*> 192.168.34.4/32 192.168.23.3 0 100 0 (65001) ?

What does the (65001) under the Path column mean? When we create a confederation, we introduce two new sub-attributes under the AS_PATH attribute: AS_CONFED_SET & AS_CONFED_SEQ. These attributes are in place to prevent loops which can be introduced in the major AS when you have sub-ASes. We can see that NLRIs from R3 & R4 both exhibit these new sub-attributes.

Now let’s take a look at R3’s BGP table:

R3#sh ip bgp
BGP table version is 23, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 111.1.1.0/24 192.168.12.1 0 100 0 (65002) 100 ?
*> 111.2.2.0/24 192.168.12.1 0 100 0 (65002) 100 ?
*> 113.3.0.0/16 192.168.12.1 0 100 0 (65002) 100 ?
*> 150.1.1.0/24 192.168.12.1 0 100 0 (65002) 100 ?
*> 150.1.2.0/24 192.168.23.2 0 100 0 (65002) ?
*> 150.1.3.0/24 0.0.0.0 0 32768 ?
*>i150.1.4.0/24 192.168.34.4 0 100 0 ?
*> 172.31.1.0/24 192.168.12.1 0 100 0 (65002) 100 ?
*> 172.31.2.0/24 192.168.23.2 0 100 0 (65002) ?
*> 172.31.3.0/24 0.0.0.0 0 32768 ?
*>i172.31.4.0/24 192.168.34.4 0 100 0 ?
*> 192.168.12.0 192.168.23.2 0 100 0 (65002) ?
*> 192.168.12.1/32 192.168.23.2 0 100 0 (65002) ?
*> 192.168.12.2/32 192.168.12.1 0 100 0 (65002) 100 ?
* 192.168.23.0 192.168.23.2 0 100 0 (65002) ?
*> 0.0.0.0 0 32768 ?
*> 192.168.23.2/32 0.0.0.0 0 32768 ?
Network Next Hop Metric LocPrf Weight Path
r> 192.168.23.3/32 192.168.23.2 0 100 0 (65002) ?
* i192.168.34.0 192.168.34.4 0 100 0 ?
*> 0.0.0.0 0 32768 ?
r>i192.168.34.3/32 192.168.34.4 0 100 0 ?
*> 192.168.34.4/32 0.0.0.0 0 32768 ?

We can really see the confederation paradigm at work here. NLRIs originated by R1 show an AS_PATH containing both the AS65002 sub-AS and the originating AS100. Remember that AS65001 sees AS65002 as being external in this regard.

Also, we can verify that the routes are indeed installed in the Cisco RIB with an iBGP AD of 200:

R3#sh ip route bgp
192.168.12.0/24 is variably subnetted, 3 subnets, 2 masks
B 192.168.12.0/24 [200/0] via 192.168.23.2, 02:18:51
B 192.168.12.1/32 [200/0] via 192.168.23.2, 02:18:51
B 192.168.12.2/32 [200/0] via 192.168.12.1, 02:18:46
113.0.0.0/16 is subnetted, 1 subnets
B 113.3.0.0 [200/0] via 192.168.12.1, 02:18:46
172.31.0.0/24 is subnetted, 4 subnets
B 172.31.2.0 [200/0] via 192.168.23.2, 02:18:51
B 172.31.1.0 [200/0] via 192.168.12.1, 02:18:46
B 172.31.4.0 [200/0] via 192.168.34.4, 02:18:51
111.0.0.0/24 is subnetted, 2 subnets
B 111.2.2.0 [200/0] via 192.168.12.1, 02:18:46
B 111.1.1.0 [200/0] via 192.168.12.1, 02:18:46
150.1.0.0/24 is subnetted, 4 subnets
B 150.1.4.0 [200/0] via 192.168.34.4, 02:18:51
B 150.1.2.0 [200/0] via 192.168.23.2, 02:18:51
B 150.1.1.0 [200/0] via 192.168.12.1, 02:18:46

A final interesting caveat to note is that the BGP decision process changes a little when preferring certain routes over others. When using confederations, NLRIs from external eBGP connections are preferred over NLRIs from confederation-based eBGP connections.

I hope you’ve enjoyed this tutorial. Please email me or leave a comment with any suggestions/questions.

neteng

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

Posted in HOWTO, Networking, Routing | 1 Comment »

PIM Sparse Mode - BSR

November 26th, 2007 neteng

Welcome back everyone. I hope you guys were smart enough to avoid following my lead this past weekend and not stuff yourself silly. I’m growing feathers from all the turkey I ate! But I digress…We’re back in action for awhile and I hope to have some good material coming your way.

Let’s begin where we left off and take a look at our common PIM network. We’ve seen static RP assignments and Auto-RP at work, so now we’ll take a look at BSR. It’s really not very complicated if you’re familiar with Auto-RP and you’ll see what I mean as we go through the configuration. The BSR router plays a similar role to the Auto-RP Mapping Agent, but it performs one major function differently. The Auto-RP MA elects an RP based on the announcements it receives from candidate-RPs (C-RP). The BSR router actually sends all mapping possibilities to every PIM router and allows them to elect an RP. They will elect the same RPs for each group though, as every PIM router uses the same hash algorithm.

First, we’ll configure R3 to be our C-RP:

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip pim rp-candidate lo0

Now let’s verify:

R3#sh ip pim rp map
PIM Group-to-RP Mappings
This system is a candidate RP (v2)

Next, let’s configure R2 to be our BSR:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip pim bsr-candidate lo0

Let’s verify that everything is working as it should be now:

R2#sh ip pim rp map
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2
Info source: 192.168.23.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:00:54, expires: 00:01:33

You can see that R3 has been selected as the RP for all multicast groups. Now we’ll ping from our R1 multicast source to R6 and see what happens:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:

Reply to request 0 from 192.168.56.6, 452 ms

You can see that R5 is using R3 as it’s RP. This was learned as the BSR sent the announcement to each PIM router (224.0.0.13), and each PIM router forwarded this announcement to it’s neighbors at the same address. Let’s take a look:

R5#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2
Info source: 150.1.2.2 (?),via bootstrap, priority 0, holdtime 150
Uptime: 00:06:41, expires: 00:02:01

Here’s our mroute table on R5:

R5#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.39.39.39), 01:29:37/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 01:29:37/00:02:31

(192.168.12.1, 239.39.39.39), 00:02:56/00:00:10, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:02:56/00:02:31

(*, 224.0.1.40), 01:30:15/00:02:27, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:30:15/00:02:27

As far as basic BSR setup, that’s all there is to it! If you have multiple BSRs, the one with the highest priority will be elected. If they all have the default Cisco priority of 0, then the BSR candidate with the highest IP address will be chosen. If you have multiple RP candidates seeking election, then the BSR will also elect the RP based on the same priority/IP address system.

I hope you’ve found this series of PIM labs useful. I haven’t quite decided what to tackle next, but have some ideas in mind. Suggestions are always welcome! In the meantime though, expect to see a review of CCNA/CCNP training materials provided by our friends at TrainSignal.

neteng

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

Posted in HOWTO, Multicast, Networking, Routing | 1 Comment »

PIM Sparse Mode - Auto RP

November 21st, 2007 neteng

Ok, so I told a small fib in my last post…But this really is the last post for this week! I finished up this lab and decided to go ahead and post it today. We’re using our familiar topology but we’ll be moving away from static RP assignments and using Cisco’s Auto-RP:

We’ve designated R3 as our Rendezvous Point (RP) and R2 as our Mapping Agent (MA). As a quick refresher, the RP acts as the root of the shared distribution tree and the MA is in charge of mapping RPs to multicast groups and disseminating that information out to multicast-participating routers. The dynamic RP system makes for a much simpler setup when you need to make changes in the future. Instead of having to update each individual router with new RP information, you just need to touch a few pieces.

The first thing we’ll want to do is assign our RP-candidate. We’ll do that as follows:

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip pim send-rp-announce lo0 scope 16

As you can see, we’re having R3 announce it’s loopback address (150.1.3.3) as a candidate for RP assignment. The scope requirement on this command sets the TTL on the announcement packets, in order to limit how far they can go. I just picked an arbitrary number of 16. This command tells the router to send an announcement to 224.0.1.39, which every mapping agent is listening on. Now let’s verify that this router is set to announce itself as an RP:

R3#sh ip pim rp map
PIM Group-to-RP Mapping
This system is an RP (Auto-RP)

Next, we’ll assign the mapping duties to R2:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int lo0
R2(config-if)#ip pim sparse-mode
R2(config-if)#exit
R2(config)#ip pim send-rp-discovery lo0 scope 16

We had to make sure to configure PIM on R2’s loopback interface so it could participate. Now let’s verify that R2 is configured correctly:

R2#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2v1
Info source: 150.1.3.3 (?), elected via Auto-RP
Uptime: 00:00:10, expires: 00:02:49

We now see that R2 is our mapping agent and has already picked up the RP announcement coming from R3. It will now announce the RP assignment to multicast group 224.0.1.40 on which the PIM-configured routers listen. For curiosity’s sake, let’s see what would happen if we also configured R5 to also announce itself as an RP:

R2#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 150.1.5.5 (?), v2v1
Info source: 150.1.5.5 (?), elected via Auto-RP
Uptime: 00:05:50, expires: 00:02:08
RP 150.1.3.3 (?), v2v1
Info source: 150.1.3.3 (?), via Auto-RP
Uptime: 00:24:37, expires: 00:02:23

R5 is now the RP of choice as it won out over R3. This is because of the higher IP address on R5. If R5 were to die, R2 would assign the RP duties to R3 to keep things going.

Ok, let’s take R5 out of the RP game and put things back to where they were. Now we’ll ping from R1 to the 239.39.39.39 group again (of which R6 is a member). Here is what our mroute table will look like on R5:

R5#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.39.39.39), 00:01:29/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:01:29/00:02:23

(192.168.12.1, 239.39.39.39), 00:00:04/00:02:55, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:00:04/00:02:55

….unnecessary info omitted….

Results from our ping:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:

Reply to request 0 from 192.168.56.6, 468 ms

Hope this was informative! We’ll return with a vengeance next week and tackle BSR along with other exciting topics. Enjoy the long weekend…

neteng

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

Posted in HOWTO, Multicast, Networking, Routing | 2 Comments »