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

Bookmark It

Hide Sites

Posted in Dynamips, HOWTO, Tools | 16 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

Bookmark It

Hide Sites

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

Dynagen - Dynamips Front End

May 8th, 2007 neteng

Dynagen makes your life a whole lot easier when it comes to creating your Cisco Lab-In-a-Box. It gives you the ability to create and modify networks through simple text files. It has the ability to automatically choose appropriate network modules based on the type of connectivity you’re providing between your virtual routers. Packet capturing is a snap, for further review of what’s happening in this network you’ve created. And it also simplifies the optimization process when running the routers on your PC (via idle-pc values).

As an example of the uber-cool capturing capabilities, I’ve attached some screenshots of Wireshark, showing RIP activity on a small network of 3 routers:

(click to enlarge)

This is all happening on my Dell laptop. Pretty cool, huh?

neteng

Bookmark It

Hide Sites

Posted in HOWTO, Networking, Tools | 1 Comment »

Dynamips - Cisco IOS Emulator

May 7th, 2007 neteng

A little more then a year ago, I posted a link to a Cisco 7200 emulator. Since that time, the emulator has evolved, and continues to evolve, into an excellent educational and simulation tool. My next few blog posts will be filled with tips on how to optimize the back end as well as how to put together a small (or large) network with various pieces of Cisco equipment. You will see how this tool has not only become an invaluable tool in my CCIE studies, but has also been extremely useful during my ‘day job’ as a network consultant. It is my hope that you will discover the same advantages; maybe even some that I have not yet found.

So keep an eye out and your RSS readers subscribed!

neteng

Bookmark It

Hide Sites

Posted in Networking, Tools | 1 Comment »

Cisco 7200 Simulator

April 28th, 2006 neteng

Now this is cool! I can’t wait to see what will become of this. I’m envisioning a fully fledged datacenter all within my laptop… Much thanks to Cisco Blog for bringing this to my attention.

neteng

Bookmark It

Hide Sites

Posted in Links, Tools | 1 Comment »

VPN - Virtual Private Network

February 17th, 2006 neteng

My manager and I have both been rather busy so it doesn’t look like I’ll get to the chapter 2 review before next week. But in the meantime, I’ve decided to throw up some information on VPNs and their uses. I could go into excruciating detail about the actual process, but why reinvent the wheel? There are lots of great resources already out there that discuss the ins and outs of this vital technology and that’s what I’m going to share with you:

http://www.howstuffworks.com/vpn.htm - One of my favorite resources for a general overview on lots of topics, HowStuffWorks.com has a great little write up on the basics of VPNs in all of their incarnations.

http://www.tcpipguide.com/free/t_IPSecurityIPSecProtocols.htm - This section of a great TCP/IP reference has lots of information on IPSec-based VPNs. It really helped me grasp the fundamentals at the heart of IPSec.

http://ipsec-wit.antd.nist.gov/ - This was a really unique tool that I stumbled across. It actually enables you to form a security association between your equipment and a NIST device. This can help troubleshoot tunnel issues to make sure your configuration conforms to the proper IETF standards.

http://nirlog.com/2006/01/23/secure-remote-access-ssl-vpn/ - My good friend Niranjan has a great article on SSL VPNs in particular. Check it out to bring yourself up to speed.

If anyone has other links or information that would be useful, please post a comment!

Thanks all,

neteng

Bookmark It

Hide Sites

Posted in Links, Tools | 1 Comment »

RANCID

January 10th, 2006 neteng

- RANCID

The Really Awesome New Cisco confIg Differ (man, what a stretch just so you can have an acronym) is another tool that I have come to know and love for network configuration backups. According to the website:

Rancid monitors a router’s (or device’s) configuration, including software and hardware (cards, serial numbers, etc), using CVS. Rancid currently supports Cisco routers, Juniper routers, Catalyst switches, Foundry switches, Redback NASs, ADC EZT3 muxes, MRTd (and thus likely IRRd), Alteon switches, and HP procurve switches and a host of others.

Let me tell you, this is a great piece of software. You need to have a *nix box to run it (or Cygwin for you Microsoft Windows users) and it can be pretty difficult to configure if you’re just jumping into it. But once you’ve read the documentation, it’s a cinch to mold it to your needs. The installation docs are okay, but this quick HOWTO really helped out. I have it run every weekday at midnight and spit out the differentials to my email address. This has become invaluable if something is working one day and it’s broken the next. “Oh, there was a typo in that routing statement.” This makes it really easy to find something like that, especially when you’re not the only person touching the equipment.

Now this is probably overkill for those with small shops, but in my current environment, I need to monitor changes made to over 250 network devices. Before discovering this tool, I wasted time backing up (or sometimes just not backing up.. big NO-NO) and maintaining a manual change control system. It’s a godsend, no doubt!

I hope you find it useful as well,

neteng

Bookmark It

Hide Sites

Posted in Tools | 1 Comment »

Traceroute

January 6th, 2006 neteng

- traceroute.org

This is a tool that won’t be helpful for everyone, but let me explain how it’s come to be a near and dear friend to me. I work in a situation where my company has many clients connecting to a hosted environment through IPSec-based VPNs over the Internet. This is a pretty standard setup for a lot of ASPs. A common customer service call occurs as follows:

Customer: “Hello, I’m getting a really slow response from your software and we’re getting kicked out left and right. What are you #%*(! monkeys doing over there!?!”

Ever since we started using this tool, we’ve found that about 85% of the time, the issue is outside of our domain of control. It’s been very easy for us to either gently and diplomatically point the finger back at the customer or find a larger problem with one of the Internet peering networks (ie. Sprint). Traceroute.org provides a fantastic collection of links that allow me to run traceroutes from multiple locations across multiple paths on the Internet. So let’s say Joe Blow calls up with this problem from a remote location with the VPN device terminating at IP address 1.2.3.4. I’ve thrown this fake address in at the end of a real traceroute run from the University of Arizona:

trace output from netops.Telcom.Arizona.EDU to 1.2.3.4:

traceroute to 216.77.85.33 (216.77.85.33), 30 hops max, 38 byte packets
1  woody.telcom.arizona.edu (128.196.128.253)  0.381 ms  0.319 ms  0.235 ms
2  tuco.telcom.arizona.edu (128.196.24.167)  0.612 ms  0.608 ms  0.617 ms
3  westgate.telcom.Arizona.EDU (192.80.43.58)  0.615 ms  0.612 ms  0.616 ms
4  207-250-65-133.gen.twtelecom.net (207.250.65.133)  1.623 ms  2.856 ms  2.366 ms
5  dist-01-ge-3-0-0-510.tcsn.twtelecom.net (66.192.253.240)  1.119 ms  1.233 ms  0.993 ms
6  core-02-ge-0-2-1-2.lsag.twtelecom.net (66.192.251.7)  24.729 ms  24.837 ms  25.351 ms
7  peer-01-so-0-0-0-0.palo.twtelecom.net (66.192.250.44)  26.101 ms  26.341 ms  26.221 ms
8  66.192.252.21 (66.192.252.21)  26.355 ms  26.586 ms  29.974 ms
9  65.83.236.183 (65.83.236.183)  82.816 ms  79.931 ms  79.440 ms
10  axr00msy-0-3-1.bellsouth.net (65.83.236.46)  500.583 ms  863.001 ms  322.453 ms
11  axr01msy-1-2-0.bellsouth.net (65.83.236.43)  95.560 ms  93.545 ms  92.929 ms
12  ixc01bhm-6-0-1.bellsouth.net (65.83.237.43)  98.683 ms  98.783 ms  98.551 ms
13  1.2.3.4 (1.2.3.4)  *     *     *

As you can see, there appears to be a big bottleneck at hop 10 at the user’s ISP.

Me: “Hi, this is Jim Joebob from ######. I’ve just emailed you a detailed troubleshooting report of where your problem lies. Please contact your ISP to reach a resolution.”

This of course takes a grand total of around 5 minutes to complete (I already have a troubleshooting report template), therefore leaving you with more time to focus on items of greater importance.

I hope you’ve found this helpful! As always, feedback and experiences are appreciated.

Thanks,

neteng

Network Troubleshooting & Analysis Template

Bookmark It

Hide Sites

Posted in HOWTO, Tools | 1 Comment »

Textpad

January 5th, 2006 neteng

- TextPad

While I still use the Windows Notepad when the quick import and export of information will suffice, TextPad is my tool of choice when I need to do any sort of text manipulation. Before I was strictly focused on network tasks, I used to dabble in web page editing via HTML and PHP. TextPad was priceless as a PHP IDE with it’s ability to import various syntax definitions and implement highly configurable macro capabilities.

And now I’ve found that it is just as valuable of a tool for my current line of work as it was for me then. I can easily pull the configuration files out of a Cisco router or switch and with some pre-recorded macros, create a CSV file with IP route and gateway information. This makes documenting your network such an easy task, it’s made me kick myself for the times I hadn’t created decent documentation. It can also be used as a rough instrument for change control though I prefer another utility for that which I will discuss later on.

In the meantime, if you have not had the pleasure to use this application, please take the time to download it and be amazed.

Thanks,

neteng

Bookmark It

Hide Sites

Posted in Tools | 1 Comment »

RRDtool

January 4th, 2006 neteng

-RRDtool

RRD stands for Round Robin Database. This is how the tool operates and can be used to store and graph any kind of time-related data you can plug into it. It’s an offshoot of MRTG which, while useful in it’s day, just isn’t as pretty as RRDtool.

For the network engineering field, data pulled from SNMP is the preferred source. If you’re not familiar with SNMP, get familiar! It can be of great usefulness when trying to extract performance metrics from not only network devices, but host devices as well. You say you want to know if your CPU is being overtaxed during a certain time period? No problem. You say you want to be alerted when a mission-critical link goes down? Piece of cake. In my opinion, SNMP is an absolutle can’t-live-without tool for the network engineer.

I have found RRDtool to be quite invaluable when hard measurements are needed. Our department has plans to use this in order to help justify budgeting. These are the types of things that the bean counters look for and it makes it easier for us to say, “Hey, we need to upgrade this frame relay link. As you can see, capacity is almost maxed out and we’re seeing performance degradation as a result. This could cause our customers to be unhappy, and unhappy customers == unhappy revenue numbers.” The message gets across pretty quickly.

Those of you who have experience with this tool, please share any insight, tips, etc that you might have!

Thanks,

neteng

Bookmark It

Hide Sites

Posted in Tools | 1 Comment »