Chainring Circus

I came across GNS3Vault by accident and thought I would pass it along. I’ve been doing these labs for fun at lunch or in the afternoon on a slow day and have been enjoying them. I’ve learned some new commands and have been turning up the debug output to see how everything interacts. It’s nice because there aren’t many routers involved so you can usually isolate the communication of whatever process you are configuring.

The only complaint I have for some of the labs is that there is so much of what I consider pre-configuration. I don’t want to have to play with adding IP addresses to interfaces. If you’re going to make me, at least give me some random subnet masks to make it interesting.

My hat is off to Rene for such a great resource.

I doubt many home labs match hardware exactly with whatever the vendor has recommended. As a result most of us must script around or manually edit vendor configuration files. Here are some of my earlier scripts that I have shared that have been updated and a couple of new ones.

tl-checklist — TestLab CheckList
So that others will be able to understand the process, I have decided to walk you through the use of these scripts. The first one started out as a checklist of changes to make to each different device for every lab, but that was quickly replaced with a script. Funny thing about scripts like this, it should have probably been written in Perl but I did not expect it to grow to this size.

Each lab has its own directory of configuration files and this script works its way through each configuration file making changes as it goes. Here is an output of the usage example.

I have tried to make the script idiot proof for my own sake. The first thing it does is make a copy of the directory so that a backup of the original exists. Then it puts a marker in the directory so that the script knows whether it has updated those configuration files before. If you have run the script on that directory it will fail gracefully.

Finally it loops through each device and makes changes that are need for each device to work properly with the other scripts and for the configuration to actually match my hardware connections.

The long term reader will recognize that this script dovetails nicely with the previous testlab scripts. For instance, the backbone routers and catalyst switches are renamed to match the hostname expected in the upgrade scripts. It also uses the same command line switches so that it integrates with some of the earlier scripts.

tl-update-router — TestLab Update Router
The next script draws on tlue (testlab update expect) to go through and upgrade any number of switches or routers.

The final line of the usage example is how I normally run this script. This particular example tells the script to upgrade all of the switches and routers to the initial configuration for LAB-1.

In doing so it will first run a configure replace command loading the flash:def file, then it will load the LAB-1 configuration file from the console. The reason I moved from configure replace of a tftp copied file onto flash was because I was not getting consistent results. If, however, I went back and pasted the switch or router configuration over the console input the configuration would take and as a result I just switched to having the script input the configuration over the console session.

tlue — TestLab Update Expect
The tlue script handles the interaction of the switches and routers through expect. A friend gave me a more thorough example but it seemed overkill for my purposes. By this time I know where I usually have problems, the serial interface of R2, but other than that this script works well.

This procedure in the tlue script is the one that sends the configuration over the console cable.

If your hardware matches that of your vendor I would recommend running tl-update-route with the configure replace option, otherwise it is porbably best to configure it from the console.

tl — TestLab
Finally, this is the last script I run which logs me into each every router or switch. It uses tlr for each terminal instance to log into the correct device, then changes the title accordingly. I do not use a “&” at the end of the command to execute in a subshell because it will not automatically log out of every session when terminating the window. Regardless, control of the terminal will be returned to you.

I spent the last week fighting our ASA. We have an old VPN 3000 Concentrator and I am slowly moving all of the tunnels to our ASA. But I needed to to do some NAT over a few VPN tunnels and eventually had to call for help. Since I am not the only person trying to do this, and I had little luck finding instructions, I am writing this post. Ironically, once you know how to do it, it’s simple and makes sense. Probably why I could never find someone who had taken the time to document the process.

Here are the basic steps:
1. Enable IPSec on the Outside interface.
2. Run the IPSec VPN wizard.
3. Create the static policy NAT.
4. Create a static route if needed.
5. Add a firewall rule if needed.

Here is a diagram of what we are trying to do:

Notice that we are NAT’ing from 192.168.181.2 to 192.168.81.2, there is only one digit different, but it makes a big difference.

1. Enable IPSec
First we enable IPSec on the Outside interface:

Code to enable IPSec:

2. IPSec VPN Wizard
Second we fire up the IPSec VPN Wizard:

Notice the pointer in this screenshot. If you are going to NAT over the VPN tunnel, make sure this is not checked. You can delete it later, all it does is make a NAT for you, we will make our own policy NAT instead. Also please take note that the interesting traffic defined is the NAT’ed addresses not the actual IP address of the host.

The resulting code from the VPN Wizard:

3. Static Policy NAT
Although it is not on the diagram, I am adding two NAT rules to the ASA:
192.168.181.2 –> 192.168.81.2 if going to 172.22.108.201
192.168.181.3 –> 192.168.81.3 if going to 172.22.108.201

The code to add a policy NAT.

The code to add another policy NAT.

4. Add a Static Route
This step depends upon your routing table.

The code to add a static route:

5. Add a firewall rule.
Once again, this step depends upon the rules in our firewall. This rule is very permissive, we are testing.

The code to add a firewall rule:

And finally, the test ping from 192.168.181.2 to 172.22.108.201:

Cisco documentation is expansive, it is both broad and has great depth, as a result finding what you need is not easy. When you watch a CCIE navigate the “Doc CD” or documentation website you realize how deeply they understand the documentation website.

I watched the free Doc CD lecture the other day at INE, I wish I could find the link sorry, then I watched the IPE documentation tutorial and have been forcing myself to use the site hierarchy rather than searching. I thought I would share some notes.

For instance, today I wanted to look at VACLs so I went:

• Cisco.com
  • Documentation
    • Products
      • Switches
        • LAN Switches Access
          • Catalyst 3560-E
            • Configuration Guides
              • Catalyst 3750-E and 3560-E Switch Configuration Guide

Then clicked around on different VLAN topics. Nothing.

So I fell back to the standard Google search:

Clicked I’m Feeling Lucky. But I wanted to learn where it was really located, so I backtracked by looking at the navigation bar on the left side.

But to really learn the documentation it doesn’t end there. I go back through the Doc CD:

• Cisco.com
  • Documentation
    • Technology
      • LAN Switching
        • LAN Security
          • VACLs
            • Securing Networks with Private VLANs and VLAN Access Control Lists

General Notes
Below are my notes on where to find different documentation on the Cisco website. I actually have this written long hand in a notebook that I still refer to when navigating around. I believe the key is repetition so I try and force myself to navigate “properly.”

This is the site I have bookmarked for the DocCD.

• Cisco.com
  • Documentation
    • Cisco IOS and NX-OS Software
      • Cisco IOS
        • Cisco IOS Software Release 12.4 Family
          • Cisco IOS Software Releases 12.4 T

You can tell from the purple links where I surf.

The links that are the most useful.

• Master Index
• Command References
• Configuration Guides

Master Index
This is useful if you know the command but just want to confirm what it does.  The other day I looked up:

Just click the on the Master Index and the correct alphabetical range, then use find in your browser to find the command you need to reference. It provides a different interface into the Command References.

Command References
Gives a short description of the command and what it does.  Then it breaks out the syntax and the options involved.  Finally it explains when the feature was added and a revision history.  I always wondered how people knew when what command had been implemented and was amazed at their recall.  Now I know, just look at the command reference.  Duh.

Configuration Guides
These are the more in depth guides. They usually start with a technology overview and provide a simple scenario and configuration. Then they get into the details of different commands and option and often include more examples with multiple routers or switches using some of the more advanced configuration options of the technology discussed. This is where I spend most of my time now, however, in the future I hope to be referencing the Master Index more than the Configuration Guides.

Below is an outline of where to find some of the technologies I reference most often.

• Dial Technologies
  • PPP
• IP
  • IP Addressing Services
    • IP Addressing
    • ARP
    • DHCP
    • DNS
    • NAT
  • Application Services
    • SLA
    • Enhanced Object Tracking
    • First Hop Redundancy Protocols
    • UDP
  • Multicast
  • IP Routing: X Protocol
  • IP Switching
    • CEF
  • IPv6
  • OER
• Long Reach Ethernet
  • Broadband Access
    • PPPOE
• MPLS
• Network Management
  • Network Management
    • EEM
• QoS
• Security and VPN
  • Securing the Control Plane
    • Control Plane Policing
  • Securing the Data Plane
    • ACLs
    • CBAC
    • IPS
• System Management
• WAN
  • Frame Relay
  • Layer 2 Tunneling Protocol Version 3
• Additional Legacy Protocols
  • Terminal Services
    • Appendix
      • Regular Expressions

I wrote a couple more scripts this week. These two little gems update my entire lab by running one command from the testlab tftp server. I pass the main script a lab name and it proceeds to update every router and switch in the testlab to the new initial lab configuration. I have tested it on at least one 1841, 2611, 3640, 3550 and 3560. I probably spent more time writing the scripts than it would have taken me to upgrade the testlab by hand for each lab, but I guess I’ll never know. You can download the scripts here.

Let me explain how it is done. Every router and switch has a configuration file named flash:def. When the whole lab has flash:def loaded they can all get to the tftp server for the lab. First side note: it was named flash:default but default is a reserved word in expect so I had to change the name, def is short for default.

In the first round of interaction the script saves every running-config to flash:new and then does a configure replace flash:def. If you just wanted to reset your lab each time, you could stop the script there. You should make sure that the switches all get changed to a VTP mode transparent and set to a new VTP domain, oddly enough I used def as my VTP domain. By making all of the switches transparent if the new config loads any VLANs or changes the domain your VTP domain will be reset. Second side note: I was going to save the original running-config as flash:save, that would still be a trivial change to make and then you could go back and review the config if you needed, but some labs build on top of the next, so I didn’t.

After each router and switch has the def configuration file loaded the script does an ls of the correct lab directory on the tftp server and proceeds to tftp the new configuration file as flash:new, overwriting the previously saved running-config. The tftp server is hooked to the switch named Cat4 which is the last host upgraded by the script so all devices can get to the tftp server.

Finally the script goes back through each device doing a round of configure replace:new. The best part of this is that there is no reload. The 2611 can take nearly 10 minutes to reload so I did not want to have to reload any devices.

In summary this is the process:
1. Save every running-config as flash:new.
2. Load the default configuration flash:def that allows for tftp access for the entire lab.
3. Copy the initial configuration for the new lab to flash:new on the routers that need it, overwriting the saved flash:new.
4. Run configure replace flash:new on ever device, bringing up the newest lab.

Here is a listing of the files on R2.

This is the tlu script. It is just the simple front end to the tlue script.

The expect script is the one that does all of the work and took the most time to write.

I wrote a couple of scripts for the testlab this week and figured I would share them. You can download them here. These could be modified for a GNS3 lab setup easily as well. Not wanting to reinvent the wheel I googled around and started hacking another script. It started off with something like this:

But gnome-terminal sets the environmental variable WINDOWID so I began by changing it to:

But then I read the gnome-terminal manpage to see what other environmental variables it set and decided all the xdotool commands were too much for what I needed. So I simplified into two main scripts, one to handle the gnome-terminal interactions and one to handle the router interactions.

The expect script to handle the interaction with the 2511-RJ getting logged into the router.

And finally the script that logs into every router in the lab, renaming the tab title to match the router name.

IPV6 Addressing
• 128 bit addresses.
• Simplified header with fewer fields; IPv4 has 12 fields, IPv6 has 5 fields;
• No checksum in the header. This results in more efficient process because in IPv4 the TTL is decremented at each hop, the checksum had to be recalculated at each hop, that is not the case with IPv6.
• No packet fragmentation done by the router, instead an ICMP “packet too big” message is sent to the client. Fragmentation information has been moved to an extension header.

Types of IPv6 Addresses
• Unicast — Send to one interface.
• Multicast — Send to many hosts in a group in the FF00::/8 address range.
• Anycast — Send to the nearest host in a group.

Abbreviate IPv6 Addresses
• Leading zeros in a field can be omitted.
• Contiguous fields containing zeros can be abbreviated with “::”.
• eui-64 addresses use the MAC address for the lower 64 bits of an IPv6 address. The MAC address is split in half and FFFE is placed between the two halves to make the 48 bit MAC into 64 bits, universal/local (U/L) flag (bit 7) in the OUI portion of the address is flipped as well.

Troubleshoot IPv6
sh ipv6 int — Validates the IPv6 and status of interfaces.
sh ipv6 routers — Displays IPv6 router advertisements.
sh ipv6 route — Shows the routing table. DUH.
sh ipv6 protocols — Shows parameters and state of the active IPv6 protocols.
debug ipv6 nd — Debug IPv6 neighbor discovery.
debug ipv6 routing — Display debugging messages for IPv6 routing table and route cache updates.
debug ipv6 packet — Displays the debugging messages for IPv6 packets.

IPv6 Configuration
ipv6 cef
ipv6 unicast-routing
ipv6 address xxxx::xxxx/xxx

OSPFv3
Configure OSPFv3
ipv6 router ospf 6
router-id 10.1.1.10
log-adjacency-changes

interface Tunnel0
no ip address
ipv6 address 2026::34:2/122
ipv6 ospf 6 area 34

Troubleshoot OSPFv3
sh ipv ospf neigh
sh ipv ospf
sh ipv ospf int

sh ipv ospf neigh

sh ipv ospf

sh ipv ospf int

RIPng
• IPv6 multicast address FF02::9 is the destination address for RIPng update messages.
• Link-local addresses used for next-hop addresses
• Metric is hop count and 15 is still the maximum, 16 is unreachable.
• Distance-vector

Configure RIPng
To set up a 3560 switch for IPv6 you must first configure the switch database management (SDM) template to one that supprts IPV6. The rest of the configuration is the same on a router and a layer 3 switch.

Troubleshoot RIPng
sh ipv6 protocols — What protocols are running on what interfaces.
sh ipv6 rip RIP_ZONE — Show general RIPng information concerning the specific RIP_ZONE.
sh ipv6 rip database — Shows the routes in the RIB.
sh ipv6 rip next-hops — Next hops out of this router as seen by RIPng.

sh ipv6 protocols

sh ipv6 rip RIP_ZONE

sh ipv6 rip database

In short, I returned my e-book to Narbik. I would recommend Micronicstraining to anyone. In fact I am now even more likely to go to Narbik’s class then I was before this incident.

The long version.
Later that day I called Micronicstraining to discuss my misgivings with them and actually spoke with Narbik. He was very helpful and understood my concerns saying that there would be no problem giving me licenses for more than one computer. With that I got off the phone placated to some extent. I tried to install LockLizard onto Wine and figured I would just deal with the inconvenience. But the installation onto Wine failed and I did not install LockLizard on Windows nor did I try to open the e-book. I didn’t even unrar the files.

That night I tossed and turned, woke up in the middle of the night and pondered my predicament. I figured I had nothing to loose by asking for my money back. That next morning I sent an email to Narbik explaining my dilemma. It is below.

Sir,

Regretfully I am writing to you to request a refund. I have not
activated my LockLizard license and am requesting that you have it
deactivated.

I would like to thank you for taking the time with me on the phone
yesterday. I had fewer misgivings concerning the number of computers
I would be allowed to study on after our conversation, however, I have
developed a study routine over the past 18 months and shoehorning
Windows into that process would not be beneficial at this time. I do
realize the lab PC runs Windows but I had already decided the last few
months of lab practice would be done in a Windows environment, not the
core of my studies.

I am truly disappointed. I downloaded the free workbook and have done
a number of labs from it. Because of that previous experience with
Micronics I did not expect the type of copy protection used in the
workbook as there is no mention of LockLizard on the Micronics
website. Over the past few months I have frequently visited the table
of contents for your workbook to map out my studies. My work
environment is based upon Linux, I do not have a Windows PC at home,
and I would be forced to change my study process in order to use the
workbook.

If you decide to change your copy protection to something more along
the lines of O’Reilly Media or Internetwork Expert please contact me,
I will be the first to purchase your workbook in a more portable
format. If you need to speak with me directly, my office phone number
is (xxx) xxx-xxxx and my cell phone number is (xxx) xxx-xxxx.

Sincerely,

Jud Bishop

Yesterday I ordered the Advanced CCIE Routing & Switching 2.0 Work Book from Narbik and figured I would share my experience.

If you have read my post on the TSHOOT book you have an understanding of my disdain for DRM and the reasons for it. It boils down to the fact that I use Linux as my primary environment at work and home, we don’t even have a Windows PC at home, and most of the DRM out there requires Windows. So then I have to load whatever I need on my work laptop, but if I am studying at home I have to make sure I bring my laptop home.

Imagine my disappointment when I got the following email from Micronics after I spent $350 on an e-book. I could not find anything on the Micronics website that says the DRM is this draconian.

If you follow the link inside the quote, it says you must use either Windows or a Mac. I am going to say this again, get SafariBooksOnline, O’Reilly is a company that understands technical people and caters to them. I am sure that Narbik is a great teacher and I hope these books are as good as they say, otherwise I will know I got ripped off.

Dear Student,

You will receive three separate emails.
1. Locklizard License
2. Vol. I & II
3. Vol. III

Since you will have only one license, choose a PC or Laptop that your Secured File will reside.

Please follow these procedures before you open the attached file:
1. First you need to open, Download and Install Lizard Safeguard Secure PDF Viewer Email (sometimes this email is considered a SPAM and if you have Gmail it goes to “7 or More” section of your Gmail).

2. Once you completed this step, you need to scroll down the page and double click on the .llv file and download.

3. After installing your PDF Viewer, open the Secured PDF Files that you have received as an attachment.

You can check the operating systems requirement on the following link:

http://www.locklizard.com/LockLizard_Secure_PDF_Viewer_v25.pdf

If you have difficulty opening your files you contact me as soon as possible so we can walk you through this process.

Thank you for your business – we appreciate it very much.

Janet Kocharians
Director of Marketing & Sales
Micronics Inc.
Mobile: (818) 331-2419
Fax: (818) 249-8388

I have had a hard time figuring out how they are going to test us for voice troubleshooting when the only real command they cover is auto qos and and the MQC. As a result I’m going to concentrate on the definitions.

Voice Definitions
Gatekeeper — provides bandwidth management through call admission control (CAC).
Gateway — ensures interoperability between VOIP and the public switched telephone network (PSTN).
Jitter (delay variation) — When consecutive packets experience different amounts of delay. Data applications tend to be much more forgiving of jitter than voice and video.
Delay — There are multiple types of delay in a network. Some are standard or fixed and some are variable in their affects, the TSHOOT book describes delay as propagation delay, the time it takes to get a bit from one end of a link to the other.
Drops — Congested packets overflow a buffer.

Cisco Phone Boot Process
1. Power, PoE
2. Load firmware from flash.
3. Catalyst switch informs the phone it’s voice VLAN.
4. DHCP for ip address and TFTP server.
5. Downloads configuration using TFTP.
6. Registers with call agent or Call Manager.

QoS Metrics for Video

Sources:
1 — ONT Certification Guide p.62
2 — Cisco DocWiki
3 — Enabling VOIP
4 — TSHOOT Book

Multicasting
Class D IP address in the range 224.0.0.0 through 239.255.255.255. Source sends one packet stream to the multicast address and all hosts that have joined that group receive that packet.

Internet Group Management Protocol (IGMP)
Hosts join a multicast group by sending an IGMP join message to router, which then knows to send multicast messages out that interface. IGMP snooping allows a switch to learn which interfaces desire multicast traffic by listening for IGMP traffic between routers and hosts. This stops the switch from flooding multicast traffic out all ports.

IGMP Version 1 — Hosts join a multicast group by sending a membership report to its local router. Every 60 seconds the querier router sends a messages to all-hosts 224.0.0.1 to ensure that there is a host on that network segment that is still in the group. IGMPv1 does not have a mechanism for hosts to leave a group, and it takes three query intervals (3 minutes) to stop sending multicast traffic to a segment.

IGMP Version 2 — Adds the ability for routers to query a specific multicast group, elect a querier for a segment and allows a host to send a leave group message to the all routers address 224.0.0.2. All routers start as queriers, however, if a router hears a query from another router, the router with the highest IP address on the segment becomes the querier for that segment.

Reverse Path Forwarding (RPF) — Verifies that multicast traffic flows away from the source or root and is flowing toward the branch or host.

Protocol Independent Multicast (PIM) — Allows multicast to build distribution trees regardless of the unicast routing protocol which is running such as EIGRP or OSPF.

PIM Dense Mode (PIM-DM) — Uses a source distribution tree. At first all routers receive traffic for the group, but if no host joins using IGMP the router sends a prune message so that unnecessary traffic does not continue. Most often used when recipients are on every subnet, densely populated.

PIM Sparse Mode (PIM-SM) — Uses a shared tree with a root router or rendezvous point (RP) that is not necessarily the multicast source but is usually centrally located on the network. All multicast streams go through this router, hence the name share tree or shared distribution tree. A router only joins the tree when a host has joined the multicast group. It is built opposite of dense mode, the tree is built from the leaves to the root, it is only when a host joins a multicast group that the router forwards the membership report to the RP.

PIM Sparse-Dense Mode — Allows a router to use sparse or dense-mode or both at the same time. Dense mode is used to flood RP discovery and announcement messages so that the client can find the RP and use the RP to find the multicast server.

Multicast Configuration

switch(config)# ip igmp snooping
switch(config)# ip igmp snooping vlan x

router(config)# ip multicast-routing
router(config)# ip pim {dense-mode | sparse-mode | sparse-dense-mode}
router(config)# ip pim version {1 | 2}

Multicast Troubleshooting
ip igmp join-group — Let’s a router join a group in order to test.
sh ip igmp group — Shows the groups a router has joined.
sh ip igmp interface — Shows IGMP information for each interface.

sh ip mroute
ping multicast address
sh ip pim rp
sh ip rpf

sh ip igmp group

sh ip igmp interface

sh ip mroute

ping multicast address