A brief overview

GNS3 is an excellent platform for simulating a good sized router environment for testing and more importantly for preparing for your CCIE lab. There are, however, some known limitations. The Dynamips software does not currently support more up to date switches like the 3560s used in version 4 of the CCIE Routing and Switching lab. In GNS3 on Ubuntu, you were provided with guidance on setting up GNS3 on Ubuntu GNU/Linux. You were shown how to run it as root and also introduced to the .net file that ultimately drives your lab topology. Dynamips and GNS3 (for the purpose of this article we will refer to it simply as GNS3) both support extending your virtual topology to your physical Ubuntu host. This gives us some very creative options for merging our virtual topology with physical hardware. We will use this article to demonstrate one of two different ways to extend your virtual topology to your physical hardware via some simple .net file adjustments and network configurations. You should already have a reasonable understanding of the fundamentals of Dynamips, GNS3, and the .net files before going too deep into this. You also are expected to have a reasonable knowledge of GNU/Linux and of course Cisco switching. Remember. Google is your friend.

Getting the virtual portion of our GNS3 lab up and running

Let’s start off with a simple setup. This will consist of just a few routers and switches. This will give you insight into the logic and a chance to understand the .net file layout without burying you in a complicated setup. We will get to that later.  Here’s a sample config below showing a collection of routers. R3 is acting as a switch. This is completely virtual within GNS3. Nothing physical is being used yet. Here (below) is our GNS3 visual reference:

Below is our complimenting .net file:
Note: All file paths you see in configuration are relative to the host we are using for this article. Please make sure to adjust your paths accordingly.

autostart = False
[localhost:7200]
    workingdir = /tmp
    udp = 10000
    [[3725]]
        image = /home/foo/GNS3/images/c3725-advipservicesk9-mz.124-15.T14-uncompressed.bin
        ram = 256
        ghostios = True
        sparsemem = True
    [[ROUTER R1]]
        model = 3725
        console = 2001
        f0/0 = R3 f1/1
        x = -362.0
        y = -214.0
    [[ROUTER R2]]
        model = 3725
        console = 2002
        f0/0 = R3 f1/2
        x = -119.0
        y = -214.0
    [[ROUTER R3]]
        model = 3725
        console = 2003
        f1/1 = R1 f0/0
        f1/2 = R2 f0/0
        slot1 = NM-16ESW
        x = -240.0
        y = -17.0

Notice on R3, we have populated slot1 with a NM-16ESW card. Without the ability to emulate a newer switch (like a 3560) this is really the best option for defining a VLAN and bridging between R1 and R2 across R3. The problem is that R3 is still a router. The NM-16ESW card does not give R3 the full flexibility and feature set of a switch. Only some of the more primitive switching options can be accomplished. We can’t test a lot of switch related features that we need to master for our labs. This is our dilemma.

Options for integrating physical components into your GNS3 environment

There are two main ways to integrate physical switches into your lab topology. Both have pros and cons.
1. Bind every respective Ethernet port on every virtual router to a dedicated physical interface on your Ubuntu host. Each dedicated interface would then connect to its respective downstream switchport thus connecting “R1 f0/0 to Cat2 f0/1” transparently thru the host. This could be done with 4xFE PCI cards or with USB-Ethernet cards as long as your operating system recognizes the hardware. The biggest pro for this solution would be that there is no need for a breakout switch. If cost is an issue, this may be the cheaper option. The con would be that it requires extra hardware and wiring and extra configuration on your host. For a full IPexpert lab we used 5 4xFE cards in a 6U server. Either that or several USB bridges would be required to set everything up. This option will be discussed in a separate article.
2. Create an 802.1q trunk between your GNS3 environment and a physical “breakout switch”. Each virtual router port gets assigned to a VLAN on a virtual switch. That VLAN is tagged and fed to the breakout switch via a single trunk link. The breakout switch then distributes the VLANs accordingly to downstream switches that are part of your lab. The biggest pro would be that you only need a single connection between your Ubuntu host and your distribution switch. Thus, this could be accomplished on a beefy laptop/desktop with ease. The con would be that you need an extra switch sitting between your virtual routers and your lab switches and this may cause you some L2 headaches depending on your hardware. This is what we are going to go over in this article. More pros/cons/details in the main sections.

Configuring a single trunk port to a “breakout switch”

So the previous three router setup was pretty simple. In the drawing below, I’ve laid out the groundwork for how we will redesign this to utilize 802.1q trunking and QnQ to take advantage of some physical switches. Let’s take a look at our physical and logical components and how they are setup. This might help you visualize what we are accomplishing.

In our drawing above, we still have R1 and R2, but we have deleted R3, we’ll get to that in a minute. R1 and R2 are still virtual routers created by GNS3 and residing on the Ubuntu host. The FE ports on R1 and R2 are now connected to a virtual switch in GNS3. That virtual switch has a “dot1q” port that is bound to the physical Eth1 interface on our Ubuntu Host. From there, the Host is connected to the Breakout Switch and then on to Lab Switch 1. Our objective is to transparently bridge the two routers traffic to Lab Switch 1. We don’t want to see the host or the Breakout Switch when doing our labs. This must be transparent so that the layer2 protocols can function properly and we aren’t distracted with inconsistencies in the setup.

R1 – Fa0/0 will connect to Lab Switch 1 Gi0/13
R2 – Fa0/0 will connect to Lab Switch 1 Gi0/14

Again, when it’s all said and done, the virtual Vswitch and the physical Breakout Switch will be transparent. From the routers viewpoint as well as the lab switches viewpoint, the will be next hops for each other.

First, we need an additional package for 802.1q support on our Ubuntu host. This is assuming that you are already running hardware that supports it.

FROM: Ubuntu Forum

The first line will install the VLAN package so you can support trunking on your host.

sudo apt-get install vlan

The second will load the 8021q kernel module immediately by adding it to /etc/modules.

sudo modprobe 8021q

The last line adding the package to /etc/modules is permanent and will make sure it is there when you reboot.

sudo  sh -c 'grep -q 8021q /etc/modules || echo 8021q >> /etc/modules'

While we are at it, let’s go ahead and set the MTU on the Ubuntu host up to a higher than default value to prevent headaches.

sudo ifconfig eth1 mtu 1536

This command is also temporary. To make it permanent, you would need to add either:

“/sbin/ifconfig eth1 mtu 1536” to your /etc/rc.local
OR
“mtu 1536” to your eth1 interface under /etc/network/interfaces

For the configuration above, we need to delete R3 and create a virtual switch. This virtual switch will receive the connection from R1 and R2. It will assign each of them a unique VLAN. Then, it will dump that onto a trunk port which continues on to the physical Ubuntu host and is passed to the breakout switch.

Back to our .net config. We are going to pull R3 out completely. Then add the vswitch and tag everything coming from the routers so that we can pass it to the Breakout Switch. You can do this directly in the .net file or you can do this via the GNS3 GUI. I’m more of a CLI guy so I edited the .net file first. Take a look at the result:

autostart = False
[localhost:7200]
    workingdir = /tmp
    udp = 10000
    [[3725]]
        image = /home/foo/GNS3/images/c3725-advipservicesk9-mz.124-15.T14-uncompressed.bin
        ram = 256
        ghostios = True
        sparsemem = True
    [[ETHSW SW0]]
        1 = access 101
        ! READ AS PORT 1 IS AN ACCESS PORT. VLAN 101
        2 = access 102
        ! READ AS PORT 2 IS AN ACCESS PORT. VLAN 102
        99 = dot1q 1 nio_linux_eth:eth1
        ! READ AS PORT 99 IS A TRUNK. ITS NATIVE VLAN IS VLAN 1. IT CONNECTS TO HOST
        ! ETH1 VIA A NIO_LINUX_ETH VIRTUAL/PHYSICAL “ADAPTER”
        x = -234.5
        y = -47.0
        hx = 12.0
        hy = -35.0
    [[ROUTER R1]]
        model = 3725
        console = 2001
        f0/0 = SW0 1
        ! READ AS F0/0 CONNECTS TO SW0 PORT 1
        x = -362.0
        y = -214.0
    [[ROUTER R2]]
        model = 3725
        console = 2002
        f0/0 = SW0 2
        x = -119.0
        y = -214.0
[GNS3-DATA]
        ! BELOW IS STRICTLY FOR GNS3 FOR VISUAL PURPOSES
    [[Cloud C0]]
        ! MAKE ME A PRETTY CLOUD AND CALL IT C0
        x = -274.5
        y = 100.0
        hx = 48.5
        hy = -24.0
        connections = SW0:99:nio_linux_eth:eth1
        ! THAT CLOUD WILL BIND SW0 PORT 99 TO HOST ETH1

Notice our configuration changes. We have deleted R3. R1 and R2 now have their f0/0 going to port one and port two on our vswitch. The vswitch has assigned port 1 as an access port under VLAN 101. Port 2 is assigned as an access port under VLAN 102. So we have two routers connecting to a switch. Also from the switch is the beginning of our trunk. Under the switch config you see port 99 (it’s virtual. Remember.) and that port is defined as a dot1q trunk and is bound to our Ubuntu host on eth1. I recommend leaving the native VLAN on the trunk port set to 1. So there is no confusion on the Host. So a packet leaving R1 is picked up the vswitch. The vswitch tags it VLAN101 (unbeknownst to the router) and forwards it to eth1 on the host. The host will not manipulate the frame at all. It will simply dump it out eth1 and onto the physical wire. The Breakout Switch will pick it up, honor the tag, and forward it appropriately to its respective interfaces within the same VLAN. The egress port on the breakout switch is configured as an access port and will therefore strip the tag. Loaded into the GNS3 application will give you something like this:

We are halfway there!

Now we will move on to the Breakout Switch. There are many different options available to use as a Breakout Switch. Our effort is to emulate as much of the R&S lab as possible. For that reason, we are using a Cisco 3750 as a Breakout Switch. You can use pretty much any old switch as a breakout switch and all your L3 traffic should be fine. However, in testing for this article, the best QnQ support for L2 protocols such as CDP, VTP, STP, etc. was achieved with a 3750 and a 4948. The older 3550 and 3560 switches (or 2900s) don’t seem to handle the QnQ configuration as smoothly. The result may be L2 protocols such as CDP only working in one direction. So we’ll use the 3750. Let’s take a look at our relevant configuration on the Breakout Switch:

NOTE: MTU adjusted here as well. This will require a reboot. Don’t forget

hostname BREAKOUT-SWITCH-1
!
system mtu routing 1546
vtp mode transparent
!
!
vlan 101-102
!
!
interface FastEthernet1/0/1
 description UP TO UBUNTU HOST
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 101-102
 switchport mode trunk
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 no cdp enable
 spanning-tree portfast
!
interface FastEthernet1/0/13
 description DOWN TO LAB-SWITCH-1 (gi0/13)
 switchport access vlan 101
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 no cdp enable
 spanning-tree portfast
!
interface FastEthernet1/0/14
 description DOWN TO LAB-SWITCH-1 (gi0/14)
 switchport access vlan 102
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 no cdp enable
 spanning-tree portfast

What have we accomplished? A packet leaving R1 is tagged by the vswitch. It is forward out the trunk port of the vswitch and off the eth1 on the Ubuntu host. The host dumps it onto the physical wire. It is picked up by the Breakout Switch on a L2 tunnel port. So, it forwards the traffic on to gi0/13 without manipulating it. Gi0/13 strips the tag since it is an access port and forwards it on to the downstream Lab Switch 1. The two endpoints (R1 and Lab Switch 1) aren’t aware of the tagging in the middle. The result? Transparency. This is crucial for when you are ready to study your L2 functions in your lab. CDP. STP. VTP. They all work bidirectionally as needed. You’ve now extended your virtual architecture to your physical hardware!

R1#sho debug
CDP:
  CDP packet info debugging is on
  CDP events debugging is on
  CDP neighbor info debugging is on
  CDP IP info debugging is on
R1#
*Mar  1 00:33:27.839: CDP-IP: Cannot find stub network
*Mar  1 00:33:27.839: CDP-PA: version 2 packet sent out on FastEthernet0/0
*Mar  1 00:33:34.235: CDP-PA: Packet received from LAB-SWITCH-1 on interface FastEthernet0/0
*Mar  1 00:33:34.239: **Entry NOT found in cache**
*Mar  1 00:33:34.239: CDP-EV: Lookup for ip phone with idb= FastEthernet0/0 ip= 1.1.1.2
mac= 0019.06a8.b1c1 platform= cisco WS-C3560G-24TS
R1#
R1#
R1#sho cdp ne
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
LAB-SWITCH-1     Fas 0/0            141          S I      WS-C3560G Gig 0/13
R1#

Turning off CDP on all the interfaces of the Breakout Switch assures us there will be no duplication of CDP entries and confusion on the lab equipment.

NOTE: Often when configuring the end to end solution for something like this, you may get duplex or speed complaints on the virtual router and/or physical switch. We have:

 Router-FE
     |
  Host-GE
     |
BreakSW-FE
     |
Lab-SW1-GE

So there is plenty of room for confusion. The best thing to do is to adjust your speed and duplex settings on the breakout switch interfaces. This way you can configure them in a way that makes the messages go away on your more important lab components. If you don’t know how to troubleshoot speed and duplex settings, you might not be ready for your lab. 

The BIG PICTURE (Preparing an IPexpert .net file with physical switches)

So you’ve played around with your .net file and breakout switch and you’re pretty comfortable. It’s time to move up to the big league. We’re going to build out the IPexpert Version 4 Volume 1 workbook topology. Remain calm. Remember that just like the lab itself, all we are doing is adding layers. The fundamental technology remains the same. Here are our L2 and L3 topologies for reference. We will need to configure the virtual routers and make sure that the slots are assigned properly so that our ports match up as best as possible. We need to configure our frame-relay topology. We need to map all of the router-to-switch interfaces to unique VLANs to trunk them to the breakout switch. Then we need to assign the correct access ports on the breakout switch to be connected to our downstream 3560s. Good stuff.

If you’ve ever manually wired up a large lab you know that attention to detail can be the difference between your first four hours spent playing or your first four hours spent reverse engineering your bad cabling. This is no different. You have additional complexity of maintaining the transparent infrastructure in the middle. It’s not impossible. It’s actually easy. But good notes and attention to detail will makes things much easier. You’ve been warned.

Here we go…..

Referencing:

IPexpert Routing & Switching Physical Connections Diagram

Matching up the slots/ports for everything in your lab can be difficult. Maybe impossible depending on the lab. GNS3 is somewhat limited in the layout of slots on the virtual routers. I’ve never not been able to test functionality. But sometimes, you can’t match up a lab diagram perfectly. In the past, what I have often found easiest is to pick a connection type and see if I can match all of that up. Say Ethernet. Can I match up all the Ethernet connections in the diagram to the slots/ports on virtual routers on GNS3? If so, I focus on that. Then, for the serial ports if I can’t match them up perfectly I will draw up a reference sheet that sits beside me when I’m doing my labs. If a workbook says S0/1/0 I immediately queue in on the serial reference and I know that in my GNS3 lab, the serial ports are close just remove the preceding 0 and make them S1/0 for example, etc. And I check my reference sheet to make sure I’m matching everything up. This works fine and I promise you won’t even notice it once you are waist deep in your layer three topology.

So let’s go ahead and build out the serial portion of the lab. This is contained completely within GNS3 and is the easiest to setup.

Note: My serial port assignments do NOT perfectly match up with the IPexpert topology above.

autostart = False
[localhost:7200]
    workingdir = /home/foo/GNS3/working
    udp = 10000
    [[7200]]
        image = /home/foo/GNS3/images/c7200-jk9o3s-mz.124-25-uncompressed.bin
        idlepc = 0x60678af0
        ghostios = True
        sparsemem = True
    [[3640]]
        chassis = 3640
        disk0 = 32
        image = /home/foo/GNS3/images/c3640-jk9s-mz.124-13a-uncompressed.bin
        ram = 256
        ghostios = True
        sparsemem = True
        idlepc = 0x607a012c
    [[ROUTER R1]]
        console = 2001
        x = -599.040764008
        y = -249.61731573
   [[ROUTER R2]]
        console = 2002
        slot1 = PA-4T+
        slot2 = PA-4T+
        s1/0 = FRSW 2
        s2/0 = R5 s2/0
        x = -594.586355052
        y = 166.881377145
    [[ROUTER R4]]
        console = 2004
        slot0 = PA-4T+
        s0/0 = FRSW 4
        x = -599.326980614
        y = -67.5875676485
    [[ROUTER R5]]
        console = 2005
        slot1 = PA-4T+
        slot2 = PA-4T+
        s1/0 = FRSW 5
        s2/0 = R2 s2/0
        x = -413.582473102
        y = 168.527112893
    [[ROUTER R6]]
        console = 2006
        slot1 = PA-4T+
        slot2 = PA-4T+
        s1/0 = FRSW 6
        s2/0 = R9 s2/0
        s2/1 = R9 s2/1
        x = -411.475729945
        y = -58.4042176954
    [[ROUTER R7]]
        console = 2007
        slot0 = PA-4T+
        s0/0 = R8 s0/0
        x = 99.8068941512
        y = -143.60076707
    [[ROUTER R8]]
        console = 2008
        slot0 = PA-4T+
        s0/0 = R7 s0/0
        x = 99.9323601145
        y = 40.3514410148
    [[ROUTER R9]]
        console = 2009
        slot2 = PA-4T+
        s2/0 = R6 s2/0
        s2/1 = R6 s2/1
        x = -410.810872155
        y = -242.328637006
    [[ROUTER BB1]]
        model = 3640
        console = 2011
        slot0 = NM-4E
        x = -165.043722602
        y = -158.154328933
    [[ROUTER BB2]]
        model = 3640
        console = 2012
        slot0 = NM-4E
        x = -160.81412458
        y = -40.6010542815
    [[ROUTER BB3]]
        model = 3640
        console = 2013
        slot0 = NM-4E
        x = -155.040421025
        y = 94.9776619695
    [[FRSW FRSW]]
        2:204 = 4:402
        2:205 = 5:502
        2:206 = 6:602
        2:214 = 4:412
        2:215 = 5:512
        2:216 = 6:612
        2:224 = 4:422
        2:225 = 5:522
        2:226 = 6:622
        4:402 = 2:204
        4:405 = 5:504
        4:406 = 6:604
        4:412 = 2:214
        4:415 = 5:514
        4:416 = 6:614
        4:422 = 2:224
        4:425 = 5:524
        4:426 = 6:624
        5:502 = 2:205
        5:504 = 4:405
        5:506 = 6:605
        5:512 = 2:215
        5:514 = 4:415
        5:516 = 6:615
        5:522 = 2:225
        5:524 = 4:425
        5:526 = 6:625
        6:602 = 2:206
        6:604 = 4:406
        6:605 = 5:506
        6:612 = 2:216
        6:614 = 4:416
        6:615 = 5:516
        6:622 = 2:226
        6:624 = 4:426
        6:625 = 5:526
        x = -498.492430622
        y = 56.7107926745
[GNS3-DATA]
    workdir = ../working

Notice I have only assigned serial ports and complimenting DLCIs on the frame switch. No Ethernet yet. Notice also that my serial connections do not perfectly match up with the port references in the lab. Again, this is relatively minor. You just need to remember it. For my own sanity, I assigned a PA-4T+ as needed on all my routers. That way, whenever you have a serial connection in your topology, you know it’s going to be x/y in your GNS3 setup. I’ve also drawn it into a Visio Diagram so I have it for a quick reference. Below is the GNS3 buildout and below that is my Visio Diagram.

Take a look at this copy (below) of the primary frame relay cloud:

For my personal reference, in the IPexpert workbook, R5 is attached to the Frame Cloud via S0/1/0. But I don’t have port 0/1/0 available. I put all my serials in slot 1 of my virtual routers. No problem. I’ll use port 1/0 instead. And I’ll document it on my Visio Diagram with “S 0/1/0 – 1/0” so I know that “port 0/1/0 on the workbook is actually port 1/0 on my virtual router”. Now I keep this Visio Diagram as a reference when I’m doing my labs. Usually, I only need it for less than an hour while I’m building my frame infrastructure.

Now let’s move on to the Ethernet connectivity. First, we know we are going to need several VLANs for the assignments from the vswitch downstream. Let’s go ahead and just map everything out in advance. We’ll document each routers Ethernet ports and give them a VLAN number. That will make configuring the vswitch much easier. While we are at it, let’s give them vswitch port assignments too. Remember that this is transparent to the actual lab equipment so VLAN assignment is arbitrary.

R1 0/0 – v102 – port 2
R1 0/1 – v103 – port 3
R2 0/0 – v104 – port 4
R2 0/1 – v105 – port 5
R4 0/0 – v106 – port 6
R4 0/1 – v107 – port 7
R5 0/0 – v108 – port 8
R5 0/1 – v109 – port 9
R6 0/0 – v110 – port 10
R6 0/1 – v111 – port 11
R7 0/0 – v112 – port 12
R7 0/1 – v113 – port 13
R8 0/0 – v114 – port 14
R8 0/1 – v115 – port 15
R9 0/0 – v116 – port 16
R9 0/1 – v117 – port 17
BB1 0/0 –v 118 – port 18
BB2 0/0 – v119 – port 19
BB3 0/0 – v120 – port 20

So let’s incorporate this into our .net file. First, the vswitch:

[[ETHSW SW0]]
2 = access 102
3= access 103
4= access 104
5= access 105
6= access 106
7= access 107
8= access 108
9= access 109
10= access 110
11= access 111
12= access 112
13= access 113
14= access 114
15= access 115
16= access 116
17= access 117
18= access 118
19= access 119
20= access 120
99 = dot1q 1 nio_linux_eth:eth1

Make sense? Good! Now let’s build out the full .net file!
Note: Sometimes when you save your file via GNS3 it moves some of the routers around in your config. Remain calm. It’s normal and ok. Go with it.

autostart = False
[localhost:7200]
    workingdir = /home/foo/GNS3/working
    udp = 10000
    [[7200]]
        image = /home/foo/GNS3/images/c7200-jk9o3s-mz.124-25-uncompressed.bin
        idlepc = 0x60678af0
        ghostios = True
        sparsemem = True
    [[3640]]
        chassis = 3640
        disk0 = 32
        image = /home/foo/GNS3/images/c3640-jk9s-mz.124-13a-uncompressed.bin
        ram = 256
        ghostios = True
        sparsemem = True
        idlepc = 0x607a012c
    [[ROUTER R1]]
        console = 2001
        f0/0 = SW0 2
        f0/1 = SW0 3
        x = -599.040764008
        y = -249.61731573
    [[ROUTER R2]]
        console = 2002
        f0/0 = SW0 4
        ! SEND ALL TRAFFIC FROM Fa0/0 TO PORT 4 ON THE VSWITCH. R2 KNOWS NOTHING OF ANY
        ! VLANS OR TAGGING.
        f0/1 = SW0 5
        slot1 = PA-4T+
        slot2 = PA-4T+
        s1/0 = FRSW 2
        s2/0 = R5 s2/0
        x = -594.586355052
        y = 166.881377145
    [[ROUTER R4]]
        console = 2004
        f0/0 = SW0 6
        f0/1 = SW0 7
        slot0 = PA-4T+
        s0/0 = FRSW 4
        x = -599.326980614
        y = -67.5875676485
    [[ROUTER R5]]
        console = 2005
        f0/0 = SW0 8
        f0/1 = SW0 9
        slot1 = PA-4T+
        slot2 = PA-4T+
        s1/0 = FRSW 5
        s2/0 = R2 s2/0
        x = -413.582473102
        y = 168.527112893
    [[ROUTER R6]]
        console = 2006
        f0/0 = SW0 10
        f0/1 = SW0 11
        slot1 = PA-4T+
        slot2 = PA-4T+
        s1/0 = FRSW 6
        s2/0 = R9 s2/0
        s2/1 = R9 s2/1
        x = -411.475729945
        y = -58.4042176954
    [[ROUTER R7]]
        console = 2007
        f0/0 = SW0 12
        f0/1 = SW0 13
        slot0 = PA-4T+
        s0/0 = R08 s0/0
        x = 99.8068941512
        y = -143.60076707
    [[ROUTER R8]]
        console = 2008
        f0/0 = SW0 14
        f0/1 = SW0 15
        slot0 = PA-4T+
        s0/0 = R7 s0/0
        x = 99.9323601145
        y = 40.3514410148
    [[ROUTER R9]]
        console = 2009
        f0/0 = SW0 16
        f0/1 = SW0 17
        slot2 = PA-4T+
        s2/0 = R6 s2/0
        s2/1 = R6 s2/1
        x = -410.810872155
        y = -242.328637006
    [[ROUTER BB1]]
        model = 3640
        console = 2011
        slot0 = NM-4E
        f0/0 = SW0 18
        x = -165.043722602
        y = -158.154328933
    [[ROUTER BB2]]
        model = 3640
        console = 2012
        slot0 = NM-4E
        f0/0 = SW0 19
        x = -160.81412458
        y = -40.6010542815
    [[ROUTER BB3]]
        model = 3640
        console = 2013
        slot0 = NM-4E
        f0/0 = SW0 20
        x = -155.040421025
        y = 94.9776619695
    [[ETHSW SW0]]
        1 = access 101
        2 = access 102
        3 = access 103
        4 = access 104
        ! ON THE VSWITCH, THE CONNECTION IS RECEIVED AND A TAG IS APPLIED
        5 = access 105
        6 = access 106
        7 = access 107
        8 = access 108
        9 = access 109
        10 = access 110
        11 = access 111
        12 = access 112
        13 = access 113
        14 = access 114
        15 = access 115
        16 = access 116
        17 = access 117
        18 = access 118
        19 = access 119
        20 = access 120
        99 = dot1q 1 nio_linux_eth:eth1
        ! THAT TAGGED TRAFFIC IS DUMPED TO THIS TRUNK PORT, THEN FED TO HOST ETH1,
        ! THEN OFF TO YOUR BREAKOUT SWITCH WITH THE TAG STILL APPLIED.
        x = -246.5
        y = -269.0
    [[FRSW FRSW]]
        2:204 = 4:402
        2:205 = 5:502
        2:206 = 6:602
        2:214 = 4:412
        2:215 = 5:512
        2:216 = 6:612
        2:224 = 4:422
        2:225 = 5:522
        2:226 = 6:622
        4:402 = 2:204
        4:405 = 5:504
        4:406 = 6:604
        4:412 = 2:214
        4:415 = 5:514
        4:416 = 6:614
        4:422 = 2:224
        4:425 = 5:524
        4:426 = 6:624
        5:502 = 2:205
        5:504 = 4:405
        5:506 = 6:605
        5:512 = 2:215
        5:514 = 4:415
        5:516 = 6:615
        5:522 = 2:225
        5:524 = 4:425
        5:526 = 6:625
        6:602 = 2:206
        6:604 = 4:406
        6:605 = 5:506
        6:612 = 2:216
        6:614 = 4:416
        6:615 = 5:516
        6:622 = 2:226
        6:624 = 4:426
        6:625 = 5:526
        x = -498.492430622
        y = 56.7107926745
[GNS3-DATA]
    workdir = ../working
    [[Cloud C0]]
        x = -54.5
        y = -285.0
        connections = SW0:99:nio_linux_eth:eth1

Loaded into GNS3, your topology may look something like:

OK! Our virtual lab is looking good. In theory, everything virtual is in place. Traffic leaving any Ethernet interface on any router will be tagged at the vswitch and dumped out eth1 of the Ubuntu host. Now, let’s move on to the Breakout Switch config. This is another place where a little pre-planning can save us. Refer to the cheat sheet we used to configure the vswitch for the .net file. We need to get each VLAN to a specific interface that strips the tag and dumps it out to the correct port on the lab 3560 at the other end.

Note: Don’t forget to adjust the MTU and reboot if you haven’t already!

!
hostname BREAKOUT-SWITCH-1
!
system mtu routing 1546
vtp mode transparent
!
!
vlan 102-120
!
!
interface FastEthernet1/0/1
 description UP TO UBUNTU HOST
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 102-120
! ALL THE TAGGED FRAMES ARE RECEIVED HERE AND PROCESSED PROPERLY ACCORDING TO THE CONFIG
 switchport mode trunk
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 no cdp enable
 spanning-tree portfast
 no shut
!
interface range fa1/0/2 – 21
 no cdp enable
 spanning-tree portfast
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 switchport mode dot1q-tunnel
 no shut
!
interface FastEthernet1/0/2
 description GNS3-R1-Fa0/0 To Physical Switch Cat1-Fa0/1
 switchport access vlan 102
 ! THE VLAN TAG IS STRIPPED HERE BEFORE BEING DUMPED TO THE DOWNSTREAM
 ! LAB SWITCH. SO THE LAB SWITCH NEVER SEES ANYTHING “ODD”!
!
interface FastEthernet1/0/3
 description GNS3-R1-Fa0/1 To Physical Switch Cat2-Fa0/1
 switchport access vlan 103
!
interface FastEthernet1/0/4
 description GNS3-R2-Fa0/0 To Physical Switch Cat1-Fa0/2
 switchport access vlan 104
!
interface FastEthernet1/0/5
 description GNS3-R2-Fa0/1 To Physical Switch Cat2-Fa0/2
 switchport access vlan 105
!
interface FastEthernet1/0/6
 description GNS3-R4-Fa0/0 To Physical Switch Cat1-Fa0/4
 switchport access vlan 106
!
interface FastEthernet1/0/7
 description GNS3-R4-Fa0/1 To Physical Switch Cat3-Fa0/4
 switchport access vlan 107
!
interface FastEthernet1/0/8
 description GNS3-R5-Fa0/0 To Physical Switch Cat1-Fa0/5
 switchport access vlan 108
!
interface FastEthernet1/0/9
 description GNS3-R5-Fa0/1 To Physical Switch Cat3-Fa0/5
 switchport access vlan 109
!
interface FastEthernet1/0/10
 description GNS3-R6-Fa0/0 To Physical Switch Cat2-Fa0/6
 switchport access vlan 110
!
interface FastEthernet1/0/11
 description GNS3-R6-Fa0/1 To Physical Switch Cat4-Fa0/6
 switchport access vlan 111
!
interface FastEthernet1/0/12
 description GNS3-R7-Fa0/0 To Physical Switch Cat2-Fa0/7
 switchport access vlan 112
!
interface FastEthernet1/0/13
 description GNS3-R7-Fa0/1 To Physical Switch Cat4-Fa0/7
 switchport access vlan 113
!
interface FastEthernet1/0/14
 description GNS3-R8-Fa0/0 To Physical Switch Cat2-Fa0/8
 switchport access vlan 114
!
interface FastEthernet1/0/15
 description GNS3-R8-Fa0/1 To Physical Switch Cat4-Fa0/8
 switchport access vlan 115
!
interface FastEthernet1/0/16
 description GNS3-R9-Fa0/0 To Physical Switch Cat2-Fa0/9
 switchport access vlan 116
!
interface FastEthernet1/0/17
 description GNS3-R9-Fa0/1 To Physical Switch Cat4-Fa0/9
 switchport access vlan 117
!
interface FastEthernet1/0/18
 description GNS3-BB1-E0/0 To Physical Switch Cat1-Fa0/11
 switchport access vlan 118
!
interface FastEthernet1/0/19
 description GNS3-BB2-E0/0 To Physical Switch Cat2-Fa0/12
 switchport access vlan 119
!
interface FastEthernet1/0/20
 description GNS3-BB3-E0/0 To Physical Switch Cat2-Fa0/13
 switchport access vlan 120
!

That’s it. Nothing is configured on the end “lab” switches. Remember, those are for actual lab work so you need to be able to erase/reload/etc. on a regular basis. The Breakout Switch config is static and once you are up and running you shouldn’t be messing with that config much unless you are modifying the actual topology of your lab.

Let’s update our Visio Diagram. We aren’t including the transparent gear in this for a reason. We just want to see our lab. All the Ethernet connections match up so it should look pretty good.

Download as a PDF Here

Looks pretty good! We are basically running a full IPexpert topology with a single Ubuntu host and 5 switches. 1 Breakout and our 4 lab switches are all we needed to complete this. Now get to studying!

Easy Bonus Points

First, in case it wasn’t already clear, it is very easy to save your configs. When you are finished with a lab and want to save the configs to reload them later:
1. Write your configs to memory like normal.
2. On the top of your GNS3 GUI is a yellow arrow. In newer versions of GNS3 the icon has changed but not the location. It is for “Extract/Import startup configs”.
3.
4. Click it.
5. Select Export.
6. Select the directory you want to save your configs to.
7. That’s it. Shut down your GNS3 topology and clear it.
8. When you are ready to get back to work load your topology, import your configs back, then turn on all your devices.
Don’t forget your switches aren’t part of your GNS3 topology. You need to save them as well.

Second, even with a beefy workstation GNS3 can put a lot of load on your PC. We aren’t here to get into tuning options. That’s a different article. But when you load up your routers with BGP and OSPF they can get a little sluggish. This is one of the reasons a dedicated PC is better. Even if your dedicated PC is running 60-80% with a GNS3 lab, you can still telnet to the virtual routers consoles remotely from your LAN/WAN. In the full .net file a little ways up, you can see R4s console in the .net file defined as 2104. That’s all you need. If your Ubuntu host has two NICs, Eth1 will be dedicated to the lab. Eth0 will be connected to your LAN/WAN. If it’s address is 192.168.1.123, then you can telnet to the console of R4 simply by telnetting to 192.168.1.123 port 2104. So you can sit comfortably at your work laptop while your noisy dedicated PC is in the other room. Most folks don’t think about this but the capability is there and very easy. For access to the switches, a terminal server with 5 ports will have you can access everything via “console” remotely.

Third,
If you can connect a lab switch and it’s transparent, what else? PIXs? ASAs? Servers? IP phones? Can you attach VMs to your virtual routers? Yes. Yes. Yes. Think about it. You can spin up a very nice Security lab. Or a Voice Lab. Or a Service Provider Lab. Or…….

Notes:

Speed. As mentioned previously, speed can be tricky. We have FE interfaces on all the main routers. The BB routers are all 10Mbps interfaces. R2 has a GE interface. This are passed to a virtual switch and then on down to a Gig port on the Ubuntu Host. From there, a 100Mbps Breakout Switch and then off to Gigabit lab switches. Confused? So was I. My recommendation when implementing GNS3 with physical gear and transparent equipment in the middle is to just forget about playing with speed. You still have your gig link between S1 and S2 that is completely on the physical infrastructure and you can use that along with your 100mbps links to test STP and loop avoidance. If you see speed/dup issues on your gear, adjust your breakout switch accordingly and don’t waste time playing with non lab related stuff.

Quarks. Many people on the forums and study lists complain of inconsistencies with using GNS3. It is very rare that I see an issue with this. If you use your Ubuntu host for other applications there is always potential for problems. I always recommend a dedicated machine. It’s not that much of an investment for what your end goal is. If you catch something odd in your labbing, think thru it. Is it a “network” issue? If so, it’s probably part of your lab. Seriously. If it’s something in the frame such as an odd message, think it thru. If you are positive it’s not your lab (workbook assignment) and it’s interfering with your work, save your configs and bounce the topology. It won’t hurt and you’ll be back up and running in the time it takes you to go get another Jolt cola.

Ubuntu, GNS3 and Q&Q. It’s really cool what you can accomplish with this setup. We haven’t even touched the beginning of it. But this has NOTHING to do with your R&S exam. DON’T LOSE FOCUS. Get it up and running and stable and then leave it alone. Focus on your workbooks and studying. Play with Ubuntu after you have your number.

Resources. They are out there. A few are listed below. There are many people out there that know more than you or I ever will. Reach out to them. Mind the forum rules. Check your math first. Then ask. Someone is always standing by to help.

https://www.ipexpert.com/
http://onlinestudylist.com/
http://ubuntuforums.org
http://7200emu.hacki.at/
http://www.gns3.net/phpBB/?sid=937c1a825da13d4f700e468e543d29c1

Tyson Scott
CCIE # 13513 R&S, Security, and SP

Print Friendly

You can add regular expressions to NBAR class-maps for HTTP URL matching protocol maps.

Let’s do an example

class-map match-all CODE-RED
 match protocol http url (*(default|cmd|root)\.(ida|exe)*)
!
policy-map MQC
 class CODE-RED
  drop
!
interface Serial0/1/0.256
 service-policy output MQC

And Testing

R2(config-subif)#do sh policy-map int s0/1/0.256 out

Serial0/1/0.256 

  Service-policy output: MQC

    Class-map: CODE-RED (match-all)
      13 packets, 3743 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http url "(*(default|cmd|root)\.(ida|exe)*)"
      drop

     Class-map: class-default (match-any)
      447 packets, 48085 bytes
      5 minute offered rate 3000 bps, drop rate 0 bps
      Match: any
R2(config-subif)#

Regards,

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Print Friendly

With the continuing growth of the IT industry it seems that often the push is to do more with less. As a Network Administrator there are common tasks that many do day to day that really are a waste of time. In my opinion anything you can automate will help in removing mundane tasks you do from day to day and decrease your workload. So learning automated tools that can decrease your workload is one of the best steps you can take for yourself.

In this tutorial I will show an example script and walk through the script to hopefully enable you to better understand EEM TCL Scripting.

So here is the Script to Start with:

EEM_L2VPN_SCRIPT.tcl

::cisco::eem::event_register_timer watchdog time $EEM_L2VPN_SCRIPT_INTERVAL
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
if {![info exists EEM_L2VPN_SCRIPT_INTERVAL]} {
 set result "Policy cannot be run: variable EEM_L2VPN_SCRIPT_INTERVAL has not been set"
 error $result $errorInfo
}
if [catch {context_retrieve "EEM_RECEIVE_COUNTER" "count"} result] {
 set receivecounter 0
} else {
 set receivecounter $result
}
if [catch {cli_open} result] {
 error $result $errorInfo
} else {
 array set cli $result
}
if [catch {cli_exec $cli(fd) "show mpls l2transport vc 171533 detail | incl byte total"} result] {
 error $result $errorInfo
} else {
 set cmd_output $result
}
set count ""
catch [regexp {receive ([0-9]+),} $cmd_output} ignore count]
set count
set diff [expr $count - $receivecounter]
if {$diff == 0} {
 action_syslog priority emergencies msg "Receive Counter for L2VPN VC 10\
		has not Incremented.  Shutting down Interface."
		cli_exec $cli(fd) "enable"
		cli_exec $cli(fd) "configure terminal"
		cli_exec $cli(fd) "interface FastEthernet0/1.1533"
		cli_exec $cli(fd) "shutdown"
		cli_exec $cli(fd) "end"
}
if [catch {cli_close $cli(fd) $cli(tty_id)} result] {
 error $result $errorInfo
}
context_save EEM_RECEIVE_COUNTER count

I would like to dissect the script and talk about each component. Hopefully you will better understand this example so you can customize and use things like this for yourself as well.

::cisco::eem::event_register_timer watchdog time $EEM_L2VPN_SCRIPT_INTERVAL
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*

To start the script I need to define system variables, and pre-defined EEM data that I would like to use. The command ::cisco::eem::event_register_timer defines how I will be running the script. Here I have stated that I want it to run at time intervale $EEM_L2VPN_SCRIPT_INTERVAL. This variable needs to be defined in the global configuration of the router, which will be shown later.

namespace is used to import pre-defined processes that are part of the EEM feature on the router. Here I have imported both the cisco::eem::* and cisco::lib::*. I actually only used settings from cisco::eem but it is OK to do both. Now you will also note I did the * as a wild card. I could have done namespace import ::cisco::eem::cli_open as en example but using the wildcard saved me from typing each process I want to use in the script.

The following are the processes used in this script called from “namespace import ::cisco::eem::*
cli_close
cli_exec
cli_open

if {![info exists EEM_L2VPN_SCRIPT_INTERVAL]} {
 set result "Policy cannot be run: variable EEM_L2VPN_SCRIPT_INTERVAL has not been set"
 error $result $errorInfo
}

Above is simply a check to make sure the global configuration variable “EEM_L2VPN_SCRIPT_INTERVAL” was defined in router configuration. If it is not defined send the result “Policy..” to the syslog of the system.

if [catch {context_retrieve "EEM_RECEIVE_COUNTER" "count"} result] {
 set receivecounter 0
} else {
 set receivecounter $result
}

Now I am going to create a variable called receivecounter. There is a loop process at the bottom of this script called context_save that will be used to save the results of the show output for the next time the script runs. If the script has not run yet it will set it to 0. If it has run before it will use the previous count result that was saved to EEM_RECEIVE_COUNTER.

if [catch {cli_open} result] {
 error $result $errorInfo
} else {
 array set cli $result
}

This is self explanatory but use the cli_open process to open a exec session on the router. The results of this are saved to the variable cli that will be used to send and receive data from the IOS.sh. This array of information are as follows:

if [catch {cli_exec $cli(fd) "show mpls l2transport vc 171533 detail | incl byte total"} result] {
 error $result $errorInfo
} else {
 set cmd_output $result
}

Now with the cli_exec I can execute commands thru the VTY session that was open on the router. I need to call my $cli(fd) variable, fd=CLI Channel Handler to send the command to the exec prompt.
Note: The command by default will be sent from the privilege 1 prompt.

Once executed I will capture the command output and put it into the variable cmd_output

set count ""
catch [regexp {receive ([0-9]+),} $cmd_output} ignore count]
set count
set diff [expr $count - $receivecounter]

Now we need to parse the command output and gather the information we are looking for. To do this we compare the output to the string “receive ([0-9]+)”. The parenthesis around the number string will be set as variable count in the second line. Now the cmd_output will be shown in the ignore variable and the expression I have in the parenthesis will be sent to count.

We then can subtract using the expr command the old receivecounter from the new count value and create the variable diff.

if {$diff == 0} {
 action_syslog priority emergencies msg "Receive Counter for L2VPN VC 10\
		has not Incremented.  Shutting down Interface."
		cli_exec $cli(fd) "enable"
		cli_exec $cli(fd) "configure terminal"
		cli_exec $cli(fd) "interface FastEthernet0/1.1533"
		cli_exec $cli(fd) "shutdown"
		cli_exec $cli(fd) "end"
}

If the variable diff is not 0 then ignore and close the script. If it is equal to zero then we will take the actions on the script.

These defined actions are the send a syslog and shutdown FastEthernet0/1.1533

if [catch {cli_close $cli(fd) $cli(tty_id)} result] {
 error $result $errorInfo
}

We close the cli session and save the count variable to EEM_RECEIVE_COUNTER

context_save EEM_RECEIVE_COUNTER count

Now we can test it. We will need to copy this file to the flash of a router.

Configure the router with the following commands:

event manager environment EEM_L2VPN_SCRIPT_INTERVAL 30
event manager directory user policy "flash:/"
event manager policy EEM_L2VPN_SCRIPT.tcl

And Test it out

cmh-2811(config)#event manager policy EEM_L2VPN_SCRIPT.tcl
cmh-2811(config)#
Feb  8 22:29:59: %HA_EM-6-LOG: EEM_L2VPN_SCRIPT.tcl: 71980
Feb  8 22:29:59: %HA_EM-6-LOG: EEM_L2VPN_SCRIPT.tcl: New count = 71980, Old Count = 0,
difference = 71980
cmh-2811(config)#
Feb  8 22:30:29: %HA_EM-6-LOG: EEM_L2VPN_SCRIPT.tcl: 71980
Feb  8 22:30:29: %HA_EM-6-LOG: EEM_L2VPN_SCRIPT.tcl: New count = 71980, Old Count = 71980,
difference = 0
cmh-2811(config)#
Feb  8 22:30:29: %HA_EM-0-LOG: EEM_L2VPN_SCRIPT.tcl: Receive Counter for L2VPN VC 10 has not
Incremented.  Shutting down Interface.
cmh-2811(config)#
Feb  8 22:30:30: %SYS-5-CONFIG_I: Configured from console by  on vty2 (EEM:EEM_L2VPN_SCRIPT.tcl)
cmh-2811(config)#no event manager policy EEM_L2VPN_SCRIPT.tcl
cmh-2811(config)#do sh run int f0/1.1533
Building configuration...

Current configuration : 123 bytes
!
interface FastEthernet0/1.1533
encapsulation dot1Q 1533
shutdown
xconnect 10.200.245.6 171533 encapsulation mpls
end

cmh-2811(config)#

Note: When tested there were two commands that I removed to make sure I was getting the expected output these were:
puts $count
puts “New count = $count, Old Count = $receivecounter, difference = $diff”

Regards,

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Print Friendly

Unfortunately Source Specific Multicast doesn’t work with this test as SSM relies on the requester to specify the Unicast Source to receive the multicast traffic from. I responded with this same information on OSL but am posting it here to have a more readable format and better archiving for access in the future.

Here is the setup I will work with for this example:

So we will have three Routers and a Sender and Receiver. To allow the sender and receiver to communicate there are a few requirements for this setup.
1. All Router interfaces should be configured for PIM Sparse-Mode. (I could also use Sparse-dense-mode but there really is no reason to have dense in the topology)
2. Enable PIM SSM default on all the routers. Although only the receiver’s closest router requires this command I would recommend adding it to the entire topology.
3. Enable IMGPv3 on client facing interfaces. I also have added this to all my interfaces as it quicker for me to copy and paste the same commands on all interfaces but only the client interface requires it.

I am not going to describe the other configuration such as routing and base configuration as that is not relevant to this setup. So let’s Do the configuration.

R2

ip multicast-routing
!
interface Serial0/1/0.256
 ip pim sparse-mode
 ip igmp version 3
!
interface Virtual-Template 1
 ip pim sparse-mode
 ip igmp version 3
!
ip pim ssm default

R4

ip multicast-routing
!
interface FastEthernet0/1
 ip pim sparse-mode
 ip igmp version 3
!
interface Virtual-Template 1
 ip pim sparse-mode
 ip igmp version 3
!
ip pim ssm default

R5

ip multicast-routing
!
interface FastEthernet0/1
 ip pim sparse-mode
 ip igmp version 3
!
interface Serial0/1/0
 ip pim sparse-mode
 ip igmp version 3
!
ip pim ssm default

Now to send the traffic. As I have already mentioned ping isn’t going to work for us in this instance. So I have downloaded a few free tools I found on the internet to assist me in completing this test.

http://www-personal.umich.edu/~bdr/et/mcast-windows.html#download

http://www.videolan.org/vlc/download-windows.html

The Multicast tool from the University of Michigan website is useful for generating the Multicast traffic into the network and seeing if it is received. The shortcoming of the tool is it only supports IGMPv2. Since SSM relies on IGMPv3 messages for communication I needed the second VLC tool to generate the IGMPv3 membership messages so that the XP workstation would make the request to receive multicast traffic for the group. Without using VLC I would see messages as follows on the receiving router:

R4(config-if)#
Feb  5 01:37:26.187: IGMP(0): Received Group record for group 232.10.45.10, mode 2 from
192.1.49.100 for 0 sources
Feb  5 01:37:26.187: IGMP(0): Group Record mode 2 for SSM group 232.10.45.10 from 192.1.49.100
on FastEthernet0/1, ignored
R4(config-if)#

Now lets run the test configuration

On the Server I installed the application and changed to the directory and ran the test.

c:\mcast\bin\msender 232.10.45.10 10000
send multicast packet 1 to 232.10.45.10 10000 bytes 32
send multicast packet 2 to 232.10.45.10 10000 bytes 32
send multicast packet 3 to 232.10.45.10 10000 bytes 32
send multicast packet 4 to 232.10.45.10 10000 bytes 32
send multicast packet 5 to 232.10.45.10 10000 bytes 32
send multicast packet 6 to 232.10.45.10 10000 bytes 32
send multicast packet 7 to 232.10.45.10 10000 bytes 32
send multicast packet 8 to 232.10.45.10 10000 bytes 32
send multicast packet 9 to 232.10.45.10 10000 bytes 32
send multicast packet 10 to 232.10.45.10 10000 bytes 32
send multicast packet 11 to 232.10.45.10 10000 bytes 32
send multicast packet 12 to 232.10.45.10 10000 bytes 32
send multicast packet 13 to 232.10.45.10 10000 bytes 32
send multicast packet 14 to 232.10.45.10 10000 bytes 32
send multicast packet 15 to 232.10.45.10 10000 bytes 32

Now I will check R5 and see if he is receiving the traffic from the sender. It won’t be sending out any interface yet as the client hasn’t requested to join the group and we are running Sparse-Mode.

R5(config-router-af)#do 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,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(4.4.4.4, 232.0.0.1), 1w2d/00:02:48, flags: sTIZ
  Incoming interface: Serial0/1/0, RPF nbr 100.100.100.2
  Outgoing interface list:
    MVRF VRFA, Forward/Sparse, 1w2d/00:02:35

(5.5.5.5, 232.0.0.1), 1w2d/00:03:07, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1/0, Forward/Sparse, 1w2d/00:02:47

(10.1.1.100, 232.10.45.10), 00:01:23/00:02:56, flags: sPT
  Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(*, 224.0.1.40), 1w2d/00:02:37, RP 0.0.0.0, flags: DPL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

R5(config-router-af)#

So we know the multicast traffic is being received by the originating router. Now we can configure The receiver to request the group traffic. First I can turn a debug on R4 to see the Join Request using the command “debug ip igmp”:

 R4(config-if)#
Feb  5 01:39:58.275: IGMP(0): Received v3 Report for 1 group on FastEthernet0/1 from 192.1.49.100
Feb  5 01:39:58.275: IGMP(0): Received Group record for group 232.10.45.10, mode 3 from
192.1.49.100 for 1 sources
Feb  5 01:39:58.279: IGMP(0): WAVL Insert group: 232.10.45.10 interface: FastEthernet0/1
Successful
Feb  5 01:39:58.279: IGMP(0): Create source 10.1.1.100
Feb  5 01:39:58.279: IGMP(0): Updating expiration time on (10.1.1.100,232.10.45.10) to 180 secs
Feb  5 01:39:58.279: IGMP(0): Setting source flags 4 on (10.1.1.100,232.10.45.10)
Feb  5 01:39:58.279: IGMP(0): MRT Add/Update FastEthernet0/1 for (10.1.1.100,232.10.45.10) by 0
R4(config-if)#
Feb  5 01:39:59.187: IGMP(0): Received v3 Report for 1 group on FastEthernet0/1 from 192.1.49.100
Feb  5 01:39:59.187: IGMP(0): Received Group record for group 232.10.45.10, mode 3 from
192.1.49.100 for 1 sources
Feb  5 01:39:59.187: IGMP(0): MRT Add/Update FastEthernet0/1 for (10.1.1.100,232.10.45.10) by 0
Feb  5 01:39:59.187: IGMP(0): Updating expiration time on (10.1.1.100,232.10.45.10) to 180 secs
R4(config-if)#

Notice that the receiver with the VLC player makes the Group request for 232.10.45.10 now

Looking at the MROUTE table for R4 I see the following

R4(config-if)#do sh ip mroute ssm
(5.5.5.5, 232.0.0.1), 1w2d/00:02:55, flags: sTIZ
  Incoming interface: Virtual-Access3, RPF nbr 100.100.24.2
  Outgoing interface list:
    MVRF VRFA, Forward/Sparse, 1w2d/00:02:51

(4.4.4.4, 232.0.0.1), 1w2d/00:03:25, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Virtual-Access3, Forward/Sparse, 1w2d/00:02:37

(10.1.1.100, 232.10.45.10), 00:07:44/00:02:56, flags: sTI
  Incoming interface: Virtual-Access3, RPF nbr 100.100.24.2
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse, 00:00:31/00:02:43

R4(config-if)#

Notice that R4 is receiving the stream now from the originating PIM router

R5(config-if)#do sh ip mroute ssm
(4.4.4.4, 232.0.0.1), 1w2d/00:02:36, flags: sTIZ
  Incoming interface: Serial0/1/0, RPF nbr 100.100.100.2
  Outgoing interface list:
    MVRF VRFA, Forward/Sparse, 1w2d/00:02:05

(5.5.5.5, 232.0.0.1), 1w2d/00:03:26, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1/0, Forward/Sparse, 1w2d/00:03:05

(10.1.1.100, 232.1.1.100), 03:36:15/00:02:56, flags: sPT
  Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(10.1.1.100, 232.10.45.10), 01:04:03/00:03:27, flags: sT
  Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1/0, Forward/Sparse, 00:20:17/00:02:36

R5(config-if)#

And for a very brief time I can use the multicast tool from University of Michigan to test receiving traffic from the sender as well.

C:\mcast\bin>mreceiver 232.10.45.10 10000
packet 1 - received group 232.10.45.10 from 10.1.1.100:10000 32 bytes
packet 2 - received group 232.10.45.10 from 10.1.1.100:10000 32 bytes
packet 3 - received group 232.10.45.10 from 10.1.1.100:10000 32 bytes
packet 4 - received group 232.10.45.10 from 10.1.1.100:10000 32 bytes
^C
C:\mcast\bin>

So we were able to successfully send and receive Multicast packets through our PIM SSM Sparse-Mode domain.

I hope this helps to show sometimes you need to do a little digging to find ways to test technologies to better understand what you are configuring for the CCIE Exam.

Regards,

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Print Friendly

I noticed in my last bootcamp when trying to demonstrate the consent auth-proxy feature there have been some minor modifications in the function of it. I want to go thru and explain each part to show how to do it and to give you the full configuration. Let’s first start by discussing each of the components of the configuration.

Auth-Proxy is used to prevent access to network resources until a user has authenticated. Following are the components of the configuration

Admission Rule – Associate the authentication List and Parameter Map to the profile to control access
Authentication List – What traffic you want to force to be authenticated
Parameter-Map type Consent – Allows you to add a custom web page for Proxy-Authentication.
Pre-Authentication List – Access-List defining what traffic should be allowed without authenticating

Let’s perform a simple configuration example

Authentication List

ip access-list extended MATCH
 deny   ip host 192.1.4.10 any
 deny   ip host 192.1.4.4 any
 permit ip 192.1.4.0 0.0.0.255 any

Pre-Authentication List

ip access-list extended PRE_AUTH
 permit icmp any any
 permit ip host 192.1.4.10 any
 permit ip host 192.1.4.4 any
 deny   ip 192.1.4.0 0.0.0.255 any
 permit ip any any

Parameter Map

parameter-map type consent AUTH
 logging enabled

Admission Rules

ip admission name AUTH consent  inactivity-time 60 list MATCH param-map AUTH
ip admission name AUTH proxy http inactivity-time 60 list MATCH
ip admission auth-proxy-banner http ^C
You Must accept these rules Prior to Authenticating
^C

Note:

unlike what is shown in the configuration guide on Cisco.com you need to define both the consent and proxy admission rule together

AAA Policy

aaa authentication login default group radius
aaa authorization auth-proxy default group radius
!
ip radius source-interface Loopback0
radius-server host 10.1.1.100 auth-port 1645 acct-port 1646 key ipexpert

Added a User to ACS and the router as a AAA Client

Username: proxyuser
password: cisco

Cisco-AV-Pair Attributes Configuration on ACS

auth-proxy:priv-lvl=15
auth-proxy:proxyacl#1=permit ip any any

Not directly related but you must enable the HTTP server. If you want the credentials to be passed securely you must enable the secure HTTP server. We used a trustpoint created for the PKI infrastructure.

ip http server
ip http secure-server
ip http secure-trustpoint PKI-SERVER

Now we can test the configuration. Here we attempt a connection through the Consent Proxy Server.  We will start by putting the radio button in Don’t accept.

Not that due to not accepting the consent rule we failed authentication.  Now we will accept it and retest

And Our Results:

R1#show ip admission cache
Authentication Proxy Cache
 Client Name proxyuser, Client IP 192.1.4.2, Port 1099, timeout 60, Time Remaining 59, state ESTAB

R1#show ip access-list PRE_AUTH
     permit ip host 192.1.4.2 any (8 matches)
    10 permit icmp any any (999863 matches)
    20 permit ip host 192.1.4.10 any
    30 permit ip host 192.1.4.4 any
    40 deny ip 192.1.4.0 0.0.0.255 any
    50 permit ip any any (394149 matches)
R1#

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Print Friendly

When traffic is destined to the ASA it required processor time to decide what to do with the traffic. This could potentially impact the performance or functions of the ASA. Thus there may be times you will want to control what traffic you will allow to terminate on the ASA. Access-Lists applied to interfaces control traffic flowing through the ASA. To control traffic to the ASA you use Access-Lists with the control-plane option.

So as an example we can use an access-list to control IPsec terminations allowed to the ASA. Below is an example.

object-group network ALLOWED_CLIENTS
 network-object 62.135.20.0 255.255.252.0
!
aaccess-list VPN_CONTROL extended permit esp object-group ALLOWED_CLIENTS host 74.126.20.10
access-list VPN_CONTROL extended deny esp any any
access-list VPN_CONTROL extended permit udp object-group ALLOWED_CLIENTS host 74.126.20.10
access-list VPN_CONTROL extended deny udp any any eq isakmp
!
access-group VPN_CONTROL in interface outside control-plane

This then allows only IPsec clients on the 62.135.20.0/22 network to connect to the ASA for EZVPN access. Testing this I can initiate a connection from a client on the 192.1.49.0/24 network and see what the results are.

ASA1(config)# sh log | incl Deny|500
%ASA-4-106023: Deny udp src outside:192.1.49.100/1185 dst identity:74.126.20.10/500 by access
-group "VPN_CONTROL" [0x5c69e5e6, 0x0]
%ASA-7-710005: UDP request discarded from 192.1.49.100/1185 to outside:74.126.20.10/500
%ASA-4-106023: Deny udp src outside:192.1.49.100/1185 dst identity:74.126.20.10/500 by access
-group "VPN_CONTROL" [0x5c69e5e6, 0x0]
%ASA-7-710005: UDP request discarded from 192.1.49.100/1185 to outside:74.126.20.10/500
%ASA-4-106023: Deny udp src outside:192.1.49.100/1185 dst identity:74.126.20.10/500 by access
-group "VPN_CONTROL" [0x5c69e5e6, 0x0]
%ASA-7-710005: UDP request discarded from 192.1.49.100/1185 to outside:74.126.20.10/500
%ASA-4-106023: Deny udp src outside:192.1.49.100/1185 dst identity:74.126.20.10/500 by access
-group "VPN_CONTROL" [0x5c69e5e6, 0x0]
%ASA-7-710005: UDP request discarded from 192.1.49.100/1185 to outside:74.126.20.10/500
ASA1(config)#

Now if I add the network above to my access-list

ASA1(config)# object-group network ALLOWED_CLIENTS
ASA1(config-network)# network-object 192.1.49.0 255.255.255.0

SA1(config-network)# sh log
Syslog logging: enabled
Facility: 20
Timestamp logging: disabled
Standby logging: disabled
Debug-trace logging: disabled
Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 75739 messages logged
Trap logging: disabled
History logging: disabled
Device ID: disabled
Mail logging: disabled
ASDM logging: disabled
100, processing VID payload
%ASA-7-715049: IP = 192.1.49.100, Received NAT-Traversal ver 02 VID
%ASA-7-715047: IP = 192.1.49.100, processing VID payload
%ASA-7-715049: IP = 192.1.49.100, Received Cisco Unity client VID
%ASA-7-713906: IP = 192.1.49.100, Connection landed on tunnel_group TEST_GROUP
%ASA-7-715047: Group = TEST_GROUP, IP = 192.1.49.100, processing IKE SA payload
%ASA-7-715028: Group = TEST_GROUP, IP = 192.1.49.100, IKE SA Proposal # 1, Transform # 1
acceptable  Matches global IKE entry # 1
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing ISAKMP SA payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing ke payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing nonce payload
%ASA-7-713906: Group = TEST_GROUP, IP = 192.1.49.100, Generating keys for Responder...
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing ID payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing hash payload
%ASA-7-715076: Group = TEST_GROUP, IP = 192.1.49.100, Computing hash for ISAKMP
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing Cisco Unity VID payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing xauth V6 VID payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing dpd vid payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing NAT-Traversal VID ver 02
payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing NAT-Discovery payload
%ASA-7-713906: Group = TEST_GROUP, IP = 192.1.49.100, computing NAT Discovery hash
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing NAT-Discovery payload
%ASA-7-713906: Group = TEST_GROUP, IP = 192.1.49.100, computing NAT Discovery hash
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing Fragmentation VID + extended
capabilities payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing VID payload
%ASA-7-715048: Group = TEST_GROUP, IP = 192.1.49.100, Send Altiga/Cisco VPN3000/Cisco ASA GW VID
%ASA-7-713236: IP = 192.1.49.100, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA
(1) + KE (4) + NONCE (10) + ID (5) + HASH (8) + VENDOR (13) + VENDOR (13) + VENDOR (13) +
VENDOR (13) + NAT-D (130) + NAT-D (130) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 444
%ASA-7-713236: IP = 192.1.49.100, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR +
HASH (8) + NOTIFY (11) + NAT-D (130) + NAT-D (130) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 168
%ASA-7-715047: Group = TEST_GROUP, IP = 192.1.49.100, processing hash payload
%ASA-7-715076: Group = TEST_GROUP, IP = 192.1.49.100, Computing hash for ISAKMP
%ASA-7-715047: Group = TEST_GROUP, IP = 192.1.49.100, processing notify payload
%ASA-7-715047: Group = TEST_GROUP, IP = 192.1.49.100, processing NAT-Discovery payload
%ASA-7-713906: Group = TEST_GROUP, IP = 192.1.49.100, computing NAT Discovery hash
%ASA-7-715047: Group = TEST_GROUP, IP = 192.1.49.100, processing NAT-Discovery payload
%ASA-7-713906: Group = TEST_GROUP, IP = 192.1.49.100, computing NAT Discovery hash
%ASA-7-715047: Group = TEST_GROUP, IP = 192.1.49.100, processing VID payload
%ASA-7-715038: Group = TEST_GROUP, IP = 192.1.49.100, Processing IOS/PIX Vendor ID payload
(version: 1.0.0, capabilities: 00000408)
%ASA-7-715047: Group = TEST_GROUP, IP = 192.1.49.100, processing VID payload
%ASA-7-715049: Group = TEST_GROUP, IP = 192.1.49.100, Received Cisco Unity client VID
%ASA-6-713172: Group = TEST_GROUP, IP = 192.1.49.100, Automatic NAT Detection Status:
Remote end is NOT behind a NAT device     This   end is NOT behind a NAT device
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing blank hash payload
%ASA-7-715046: Group = TEST_GROUP, IP = 192.1.49.100, constructing qm hash payload
%ASA-7-713236: IP = 192.1.49.100, IKE_DECODE SENDING Message (msgid=96dc0ca6) with payloads :
HDR + HASH (8) + ATTR (14) + NONE (0) total length : 72
%ASA-7-111009: User 'enable_15' executed cmd: show logging
ASA1(config-network)#

So a Control-Plane Access-List can be used to help protect resources on the ASA.

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Print Friendly

I will outline the process I followed to determine match a MAC address.

The first step is to load the Protocol Header Definition Files from the system folder.

load protocol system:/fpm/phdf/ether.phdf
load protocol system:/fpm/phdf/ip.phdf

Next to start at the Layer 2 header of a packet with FPM we need to use a stack class-map to let the system know to start at Layer 2 Header.

class-map type stack match-all IP-TYPE
stack-start l2-start

Now it becomes somewhat problematic. Typically FPM is intuitive in how to match information but it seems the MAC field was not well defined. Looking at the options:

R5(config-cmap)#match field ETHER source-mac ?
eq      eq
gt      gt
lt      lt
neq     neq
range   range
regex   regex
string  string

R5(config-cmap)#match field ETHER source-mac eq ?
<0-65535>  Value to be Matched

R5(config-cmap)#

A MAC is typically in the format of XXXX.XXXX.XXXX. In a packet the periods are not included but we have a problem. 0-65535 doesn’t include any A-F letters. So this means we need to match the MAC in the payload using either the STRING or REGEX option.

To see what the MAC looks like in the payload of the packet we can use the Embedded Packet Capture feature to see the raw packet data.

R5#monitor capture buffer TEST
R5#monitor capture point ip cef TEST Fa0/1
R5#monitor capture point associate TEST TEST

And the output:

49D6E260:          000AB819 C8F0000A B82DCB48      ..8.Hp..8-KH
49D6E270: 08004500 00640086 0000FE01 FCA4C001  ..E..d....~.|$@.
49D6E280: 3907C001 06640800 9A72001A 00040000  9.@..d...r......
49D6E290: 00000A69 D950ABCD ABCDABCD ABCDABCD  ...iYP+M+M+M+M+M
49D6E2A0: ABCDABCD ABCDABCD 00                 +M+M+M+M.

Looking at the RAW output can be somewhat confusing. But the layer 2 header is the first 14 bytes of data. 6 byte destination MAC, 6 byte source address, and 2 byte protocol identifier. So in the payload the Layer 2 portion is here “..8.Hp..8-KH..”. So if we want to match the source MAC in this example it is shown as ..8-KH. Let’s build the configuration now.

class-map type stack match-all IP-TYPE
 stack-start l2-start
 match field ETHER type eq 0x800 next ETHER
class-map type access-control match-all MAC-ADD
 match field ETHER source-mac regex "\.\.-KH"
policy-map type access-control TOP
 class MAC-ADD
   log
policy-map type access-control FPM
 class IP-TYPE
  service-policy TOP
interface FastEthernet0/0
 service-policy type access-control input FPM

And does it work?

R5#show policy-map type access-control interface FastEthernet0/0
 FastEthernet0/0 

  Service-policy access-control input: FPM

    Class-map: IP-TYPE (match-all)
      85381 packets, 6333463 bytes
      5 minute offered rate 0 bps
      Match: field ETHER type eq 0x800 next ETHER

      Service-policy access-control : TOP

        Class-map: MAC-ADD (match-all)
          85379 packets, 6332974 bytes
          5 minute offered rate 0 bps
          Match: field ETHER source-mac regex "\.\.-KH"
      log

        Class-map: class-default (match-any)
          2 packets, 489 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any 

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
R5#

Looks like it.

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Print Friendly

Marko has posted several blogs on how to connect to proctorlabs using SecureCRT (Windows/MAC_and_Linux) and how to connect using Putty Connection Manager with the Database File.

I would like to add to these posts by giving a script that will allow for some automation while working on Proctorlabs, (And this script can actually be ported to use within your own company if you are interested.)

Each time I connect to the devices for a new session there are a few commands I always enable on the devices. For instance setting the logging to synchronous and disabling the idle timeout timer on the console, creating aliases, and disabling domain lookup. Instead of having to enter these commands each time I connect to Proctorlabs I have created a small expect script to automatically connect and post these commands for me each time I start a new vrack session.

Download Files Here:

The Script
The Commands File

Make sure to remove the .txt extension on the script file
This script will work on Linux/Unix/OSx. Some of the script structure is a little more advanced than you necessarily need to know but there is little you need to edit to get it working for yourself.

First if running one of the above operating systems you need to first be sure that the TCL and Expect libraries are installed and operational. To test that they are installed and working you can enter “expect” at the prompt and it should enter you into the expect program.

tyson@atr-lnx:~> expect
expect1.1> exit
tyson@atr-lnx:~>

Seeing this is successful you will then need to check to find where the binaries are located

tyson@atr-lnx:~> which expect
/usr/bin/expect
tyson@atr-lnx:~> which bash
/bin/bash
tyson@atr-lnx:~> which telnet
/usr/bin/telnet
tyson@atr-lnx:~>

Note the location of the above binaries as you will need to update the script with these locations in the script for it to work. Next go ahead and download the script from here and the commands file from here. I recommend putting these two files in your home directory. Make sure that the “t” script is only executable and readable by you. simply typing “chmod 700 t” and “chmod 600 commands” should set the permissions you need on each file.

There are a few lines you will need to update before using the script listed below:

#!/usr/bin/expect

set FOLDER "/home/tyson"
set env(PATH) "/bin:/sbin/:/usr/bin/:/usr/sbin:/home/tyson/:"
set env(SHELL) "/bin/bash"

set tac_user "[insert_your_username]"
set tac_pass "[insert_your_password]"

set hostname "pod101ts1.proctorlabs.com"
set termserv2 "pod101ts2.proctorlabs.com"

The first line to update in the script is the expect executable location. This is line 1 and should be updated with the location found from running the “which” command above. Next make sure in the env(PATH) variable that you have included the location of the telnet executable and the folder in which you are placing all the “t” and “commands” files (I put /home/tyson/ as this is my home folder and I put the two files here). /bin/bash is typically the Shell for Linux so that should be good for most of you but you may update if necessary. Last replace the tac_user and tac_pass variables with the correct information.

The last two lines define the terminal servers for the racks I will be working on. This can be updated each time you rent a session with the correct terminal servers. If you aren’t using a security rack rental session then you don’t have to worry about the second line.

Edit the commands file and update with whatever commands you want to run on the routers after login to the devices. At this point you should be ready to go.

Let’s go through a few instructions on how to enter the command. The Structure is

t [hostname],port,[autocommands yes [1] or no [blank]]

So if I wanted to connect to pod101ts1.proctorlabs.com I would simply type

tyson@atr-lnx:~>t pod101ts1.proctorlabs.com

To connect to pod101ts1.proctorlabs.com Port 2001, I would type:

tyson@atr-lnx:~>t pod101ts1.proctorlabs.com,2001

To connect to pod101ts1.proctorlabs.com Port 2001 and send the commands in the command folder, I would type:

tyson@atr-lnx:~>t pod101ts1.proctorlabs.com,2001,1

I also created a few shortcuts to make it even more simple when connecting to the console lines. Instead of having to type out the full hostname I created a variable in the script, which I mentioned above, allowing you to use shortcuts to connect to each device. For example to connect to R1-R9 you only have to put in 1,2,3,4,5,6,7,9 as the hostname. For example:

t 1

This would connect to pod101ts1.proctorlabs.com port 2001

t c1

Would connect to pod101ts1.proctorlabs.com port 2010.

The options you have for shortcuts are:
1 = [variable hostname] port 2001 (R1)
2 = [variable hostname] port 2002 (R2)
3 = [variable hostname] port 2003 (R3)
4 = [variable hostname] port 2004 (R4)
5 = [variable hostname] port 2005 (R5)
6 = [variable hostname] port 2006 (R6)
7 = [variable hostname] port 2007 (R7)
8 = [variable hostname] port 2008 (R8)
9 = [variable hostname] port 2009 (R9)
c1 = [variable hostname] port 2010 (Cat1)
b1 = [variable hostname] port 2011 (BB1)
b2 = [variable hostname] port 2012 (BB2)
b3 = [variable hostname] port 2013 (BB3)
c2 = [variable hostname] port 2014 (Cat2)
c3 = [variable hostname] port 2015 (Cat3)
c4 = [variable hostname] port 2016 (Cat4)
a1 =[variable termserv2] port 2001 (ASA1)
a2 = [variable termserv2] port 2002 (ASA2)
i = [variable termserv2] port 2003 (IPS)

Last for commands file you can use the shortcuts and still send the commands:

t 1,,1

As 1 creates the hostname variable with port I simply need to enter 1 for yes to send commands and it will work, the port field is left blank. Here is output showing the script in example:

Here is an example of Connecting to pod101ts1.proctorlabs.com port 2001

tyson@atr-lnx:~> t 1
spawn /usr/bin/telnet pod101ts1.proctorlabs.com 2001
Trying 10.200.4.101...
Connected to pod101ts1.proctorlabs.com.
Escape character is '^]'.

          ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
       WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

     WARNING:  This system is for the use of authorized clients only.
           Unauthorized access is a violation of federal, state,
                         civil and criminal laws.

http://www.ProctorLabs.com

Username: reload
Password: 

             You are on line number: 1

R1(config)#
R1(config)#
R1(config)#
telnet> quit
Connection closed.

Here is an example of Connecting to pod102ts1.proctorlabs.com port 2001

tyson@atr-lnx:~> t pod102,2001
spawn /usr/bin/telnet pod102 2001
Trying 10.200.4.102...
Connected to pod102.
Escape character is '^]'.

          ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
       WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

     WARNING:  This system is for the use of authorized clients only.
           Unauthorized access is a violation of federal, state,
                         civil and criminal laws.

http://www.ProctorLabs.com

User Access Verification

Username: reload
Password: 

             You are on line number: 1

Router#
Router#
Router#
telnet> quit
Connection closed.

Here is an example of Connecting to pod101ts1.proctorlabs.com port 2010 and sending the commands in the commands file

tyson@atr-lnx:~> t c1,,1
spawn /usr/bin/telnet pod101ts1.proctorlabs.com 2010
Trying 10.200.4.101...
Connected to pod101ts1.proctorlabs.com.
Escape character is '^]'.

          ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
       WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

     WARNING:  This system is for the use of authorized clients only.
           Unauthorized access is a violation of federal, state,
                         civil and criminal laws.

http://www.ProctorLabs.com

User Access Verification

Username: reload
Password: 

             You are on line number: 10

Cat1#
Cat1#
Cat1#enable
Cat1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Cat1(config)#line con 0
Cat1(config-line)#logging synchronous
Cat1(config-line)#no ip domain lookup
Cat1(config)#ip tcp synwait 5
Cat1(config)#alias exec c config t
Cat1(config)#alias exec s show run
Cat1(config)#alias exec srs show run | section
Cat1(config)#alias exec srb show run | begin
Cat1(config)#alias exec si show run interface
Cat1(config)#alias exec sri show run | include
Cat1(config)#alias exec siib show ip interface brief | excl admin
Cat1(config)#alias exec sir show ip route
Cat1(config)#alias exec sib show ip bgp
Cat1(config)#alias exec sio show ip ospf
Cat1(config)#alias exec sie show ip eigrp
Cat1(config)#end
Cat1#
*Mar  3 18:50:13.716: %SYS-5-CONFIG_I: Configured from console by console
Cat1#
telnet> quit
Connection closed.

Here is an example of Connecting to pod101ts2.proctorlabs.com port 2001

tyson@atr-lnx:~> t a1
spawn /usr/bin/telnet pod101ts2.proctorlabs.com 2001
Trying 10.200.4.201...
Connected to pod101ts2.proctorlabs.com.
Escape character is '^]'.
CC

         ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
      WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

    WARNING:  This system is for the use of authorized clients only.
          Unauthorized access is a violation of federal, state,
                        civil and criminal laws.

http://www.ProctorLabs.com

User Access Verification

Username: reload
Password:
CC

            You are on line number: 1

ciscoasa#
ciscoasa#
ciscoasa#
telnet> quit
Connection closed.
tyson@atr-lnx:~>

I then simply have a Tabbed emulator that allows me to have all the connections open. As Shown in the Image Below

Hopefully this will help you all save some time while beginning your labs practice labs.

Regards,

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Print Friendly

I have erased the configurations and created a very similar configuration shown below, (It should be essentially the same only names have possibly changed). My configuration on the vlecture was good but something was causing R2 to ignore the incoming traffic.

Here is the configuration and the verification output

R1

ip vrf RED
 rd 7018:12
!
crypto keyring VRF
 pre-shared-key address 12.12.12.2 key ipexpert
!
crypto isakmp profile VRF
 vrf RED
 keyring VRF
 match identity address 12.12.12.2 255.255.255.255
!
crypto ipsec transform-set STRONG esp-aes 192 esp-sha-hmac
!
crypto map L2L 10 ipsec-isakmp
 set peer 12.12.12.2
 set transform-set STRONG
 set isakmp-profile VRF
 match address L2L
!
interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip vrf forwarding RED
 ip address 10.10.10.1 255.255.255.0
!
interface FastEthernet0/0.12
 encapsulation dot1Q 12
 ip address 12.12.12.1 255.255.255.0
 crypto map L2L
!
router rip
!
 address-family ipv4 vrf RED
  redistribute static metric 3
  network 10.0.0.0
  no auto-summary
  version 2
  exit-address-family
!
ip route vrf RED 20.0.0.0 255.0.0.0 12.12.12.2 global
!
ip access-list extended L2L
 permit ip 10.0.0.0 0.255.255.255 20.0.0.0 0.255.255.255

R2

ip vrf RED
 rd 7018:12
!
crypto keyring VRF
 pre-shared-key address 12.12.12.1 key ipexpert
!
crypto isakmp profile VRF
 vrf RED
 keyring VRF
 match identity address 12.12.12.1 255.255.255.255
!
crypto ipsec transform-set STRONG esp-aes 192 esp-sha-hmac
!
crypto map L2L 10 ipsec-isakmp
 set peer 12.12.12.2
 set transform-set STRONG
 set isakmp-profile VRF
 match address L2L
!
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip vrf forwarding RED
 ip address 20.20.20.2 255.255.255.0
!
interface GigabitEthernet0/0.12
 encapsulation dot1Q 12
 ip address 12.12.12.2 255.255.255.0
 crypto map L2L
!
router rip
!
 address-family ipv4 vrf RED
  redistribute static metric 3
  network 20.0.0.0
  no auto-summary
  version 2
  exit-address-family
!
ip route vrf RED 10.0.0.0 255.0.0.0 12.12.12.1 global
!
ip access-list extended L2L
 permit ip 20.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

Cat1 Test

Cat1#ping 20.20.20.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.2, timeout is 2 seconds:
...!!
Success rate is 40 percent (2/5), round-trip min/avg/max = 1/1/1 ms
Cat1#ping 20.20.20.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
Cat1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
R    20.0.0.0/8 [120/3] via 10.10.10.1, 00:00:20, Vlan10
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.1.1.10/32 is directly connected, Loopback0
C       10.10.10.0/24 is directly connected, Vlan10
Cat1#ping 20.20.20.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.14, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/9 ms
Cat1#ping 20.2.2.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.2.2.14, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms
Cat1#

R1 Verification

R1(config-isakmp)#do sh crypto is sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
12.12.12.2      12.12.12.1      QM_IDLE           4002    0 ACTIVE

IPv6 Crypto ISAKMP SA

R1(config-isakmp)#do sh crypto ipsec sa

interface: FastEthernet0/0.12
Crypto map tag: L2L, local addr 12.12.12.1

protected vrf: RED
local  ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
remote ident (addr/mask/prot/port): (20.0.0.0/255.0.0.0/0/0)
current_peer 12.12.12.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 22, #pkts encrypt: 22, #pkts digest: 22
#pkts decaps: 17, #pkts decrypt: 17, #pkts verify: 17
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 8, #recv errors 0

local crypto endpt.: 12.12.12.1, remote crypto endpt.: 12.12.12.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0.12
current outbound spi: 0x3EF35910(1056135440)

inbound esp sas:
spi: 0xC1B4A3B7(3249841079)
transform: esp-192-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: AIM-VPN/EPII-PLUS:1, crypto map: L2L
sa timing: remaining key lifetime (k/sec): (4462220/2791)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x3EF35910(1056135440)
transform: esp-192-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: AIM-VPN/EPII-PLUS:2, crypto map: L2L
sa timing: remaining key lifetime (k/sec): (4462219/2791)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:
R1(config-isakmp)#

If you haven’t already taken a chance to watch the free vlecture please do. You can access the recording for this vlecture here

Regards,

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Print Friendly

L2-Protocol Tunnels and 802.1q tunnels seems to be a topic that often confuse people and people misunderstand the requirements to run these services.

The 802.1q tunnel feature allows a provider to tunnel customer traffic thru the provider network without revealing the underlying L2 architecture of the provider network.  In addition many customers will likely share the same L2 VLAN’s thus there is a need to keep the customer VLAN traffic separated.

With 802.1q tunneling the PE devices will add a second dot1q header, which is the access VLAN configured on the switchport, to the customer traffic to allow the traffic to be tunneled thru the provider cloud.  This may be referred to as a Metro tag or double tagging traffic.  Now obviously when you add additional headers to traffic you need to account for these extra tags in the size of the frames.  Meaning make sure you remember to increase the system mtu of the devices to at least 1504, I personally typically like to use 1508.

One pitfall to be aware of when configuring 802.1q tunnels is the native VLAN.  If a customers native VLAN is the same as the access VLAN configured for the tunnel port the Metro tag will not be added to traffic of the native VLAN when using default 802.1q values on the Metro devices.  There are two ways to avoid this pitfall.

1. Use ISL trunking in the Metro Ethernet
2. Configure the Provider devices with the command “vlan dot1q tag native”.  This causes the native VLAN to also be tagged with the dot1q header on trunk ports.

It is also important to understand some of the limitations of 802.1q tunnels. Namely:

• They do not support carrying VTP, DTP, or CDP packets to the remote device
• Spanning-tree filtering is automatically enabled on the PE (Provider Edge) port.
• Layer 3 features on the  PE ports are not supported such as L3 QoS and L3 ACL’s
• Fallback bridging is not supported for VLAN’s carrying customer traffic in the Metro Ethernet

Now to address a few of these shortcomings we have the additional L2 Protocol tunneling feature.  The L2 Protocol tunneling feature allows for traffic that would typically be terminated on the switchport for evaluation to be carried to the remote PE (Provider Edge) port for evaluation by the remote customer device.  Such as:

• Spanning-tree traffic can now be carried between each site to allow for properly building the spanning-tree topology between both sites.
• CDP packets can now be carried between devices to properly recognize the “Pseudo” connected device.
• VTP can be carried between both sites
• LACP PAGP and UDLD traffic can be shared between two point-to-point interfaces.

If both Customer devices terminate on the same provider device L2 Protocol tunneling can be used independently of 802.1q tunneling but if you must traverse more than 1 switch then the two should be used in conjunction.

Example

So let’s work thru an example of configuring these two features with an EtherChannel between two switches that is carried over a provider cloud.  Below is a basic diagram of our topology we will work with.

Diagram

Now there are a few configuration requirements we should keep in mind as we work thru this example.

• System MTU on Metro Switches must be increased to 1504 or more. (Remember this needs a reboot.)
• We are using 802.1q trunks so we need to command “vlan dot1q tag native”

Configuration

Following is the configuration for each device

Cat1

vlan 14
!
interface FastEthernet0/23
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port
 channel-group 14 mode active
!
interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port
 channel-group 14 mode active
!
interface Vlan14
 ip address 10.1.14.1 255.255.255.0
!

Cat2

vlan dot1q tag native
system mtu 1508
! ### remember reboot
!
interface FastEthernet0/19
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree portfast trunk
!
interface FastEthernet0/20
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree portfast trunk
!
interface FastEthernet0/23
 switchport access vlan 114
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 l2protocol-tunnel point-to-point lacp
 l2protocol-tunnel point-to-point udld
 no cdp enable
!
interface FastEthernet0/24
 switchport access vlan 124
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 l2protocol-tunnel point-to-point lacp
 l2protocol-tunnel point-to-point udld
 no cdp enable
!

Cat3

vlan dot1q tag native
system mtu 1508
! ### remember reboot
!
interface FastEthernet0/19
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree portfast trunk
!
interface FastEthernet0/20
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree portfast trunk
!
interface FastEthernet0/23
 switchport access vlan 114
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 l2protocol-tunnel point-to-point lacp
 l2protocol-tunnel point-to-point udld
 no cdp enable
!
interface FastEthernet0/24
 switchport access vlan 124
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 l2protocol-tunnel point-to-point lacp
 l2protocol-tunnel point-to-point udld
 no cdp enable
!

Cat4

vlan 14
!
interface FastEthernet0/23
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port
 channel-group 14 mode active
!
interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port
 channel-group 14 mode active
!
interface Vlan14
 ip address 10.1.14.4 255.255.255.0
!

Let’s talk about a few of the key configuration components here.  When I gave the background information above on L2 Protocol Tunneling, note that LACP and UDLD are only support in a point-to-point operation.  This is the reason we used two different VLAN’s, 114 and 124, for the two ports connected to the customer.

The L2 Protocol tunneling allows us to carry the CDP, LACP, spanning-tree, UDLD, and VTP packets between Cat1 and Cat4.  The 802.1q handles the carrying of the traffic between the two ports by adding the Metro Tag of 114 and 124 to traffic coming in from Cat1 and Cat4 respectively.

The reason that running UDLD is important is we are load balancing traffic between two ports.  Because our neighboring device is not directly connected we need to be aware of a device failure on the remote end.  UDLD provides this function by testing the neighboring device and taking down a port in the event of a failure on the remote end or in the provider path.  You could compare this to FREEK in reference to Frame-Relay technologies.

Now let’s test it out and see how things are working.

Cat1#show udld neighbors
Port     Device Name   Device ID     Port ID    Neighbor State
----     -----------   ---------     -------    --------------
Fa0/23   CAT1029ZJBJ     1            Fa0/23     Bidirectional
Fa0/24   CAT1029ZJBJ     1            Fa0/24     Bidirectional
Cat1#show udld Fa0/23
Interface Fa0/23
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5
Entry 1
---
Expiration time: 39
Device ID: 1
Current neighbor state: Bidirectional
Device name: CAT1029ZJBJ
Port ID: Fa0/23
Neighbor echo 1 device: CAT1029ZJD6
Neighbor echo 1 port: Fa0/23
Message interval: 15
Time out interval: 5
CDP Device name: Cat4
Cat1#show udld Fa0/24
Interface Fa0/24
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5
Entry 1
---
Expiration time: 37
Device ID: 1
Current neighbor state: Bidirectional
Device name: CAT1029ZJBJ
Port ID: Fa0/24
Neighbor echo 1 device: CAT1029ZJD6
Neighbor echo 1 port: Fa0/24
Message interval: 15
Time out interval: 5
CDP Device name: Cat4
Cat1#show spanning-tree vlan 14
VLAN0014
Spanning tree enabled protocol ieee
Root ID    Priority    32782
Address     0019.0606.7180
Cost        12
Port        160 (Port-channel14)
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Bridge ID  Priority    32782  (priority 32768 sys-id-ext 14)
Address     0019.060c.5e80
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po14                Root FWD 12        128.160  P2p
Cat1#show int trunk
Port        Mode             Encapsulation  Status        Native vlan
Po14        on               802.1q         trunking      1
Port        Vlans allowed on trunk
Po14        1-4094
Port        Vlans allowed and active in management domain
Po14        1,14
Port        Vlans in spanning tree forwarding state and not pruned
Po14        1,14
Cat1#ping 10.1.14.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.14.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms
Cat1#show cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
Cat4             Fas 0/24          121           S I      WS-C3560- Fas 0/24
Cat4             Fas 0/23          120           S I      WS-C3560- Fas 0/23
Cat1#show etherchannel summary
Flags:  D - down        P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3      S - Layer2
U - in use      f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators:           1
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
14     Po14(SU)        LACP      Fa0/23(P)   Fa0/24(P)

Looks like it worked just as expected.  Thanks for Reading.

–
Tyson Scott – CCIE # 13513 (R&S/Security/SP)
Managing Partner / Sr. Technical Instructor – IPexpert Inc.
Mailto: tscott@ipexpert.com

Print Friendly