I had to train some NOC’ers a couple of days ago and I came up with a few scenarios we come across often, and how we would ensure the VPNs work.
We currently predominantly use Juniper’s ScreenOS range for IPSec VPNs. 3rd parties use anything from Juniper, Cisco, Checkpoint, etc. The most common is Cisco, and it’s also the one that causes the most issues from my experience.
Let’s use the following topology. 10.0.0.0/24 represents the public internet. Each site needs to have connectivity to the other through an IPSec VPN tunnel.
Both IOS and ScreenOS allow you to create both policy-based and route-based VPNs. From my experience, most people seem to do policy-based VPNs. I much prefer route-based VPNs. In fact I have not created a policy-based VPN in a number of years as I always find route-based to be far superior.
There are a number of differences, but in essence in goes like this. With policy-based, interesting traffic going over the regular interface will be encrypted and sent to the other side of the tunnel. Interesting traffic is defined in an ACL. With route-based, you actually create a layer 3 interface and any traffic going through that tunnel is subject to encryption.
The great thing about route-based tunnels is that you can run routing protocols over them. You can also send any traffic you like over it and you know it’ll be encrypted. You can also easily attach service policies to a tunnel interface. In essence, you get a fully routable layer3 interface. A policy-based VPN simply doesn’t give you this capability.
Note that I’m going to use some generic phase 1 and phase 2 settings. You can of course add loads of different options, but that’s up to you.
Let’s start with the Juniper ScreenOS device. eth0/5 is my untrust interface.
set interface tunnel.1 zone untrust set interface tunnel.1 ip unnumbered interface ethernet0/5 set ike gateway "VPN_P1" address 10.0.0.2 Main outgoing-interface "ethernet0/5" (continued form line above) preshare vpnblog proposal "pre-g2-3des-sha" set vpn "VPN_P2" gateway "VPN_P1" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha" set vpn "VPN_P2" bind interface tunnel.1 set route 192.168.0.0/24 interface tunnel.1
In the above I’ve created Tunnel 1. I then created my phase 1 and phase 2 settings and binded the tunnel interface to the phase 2 set up. I then create a static route to send traffic going to 192.168.0.0/24 over the tunnel.
Let’s now move over to the Cisco. Pretty much the same thing I’m doing, but the config looks a little different:
crypto isakmp policy 1 encr 3des authentication pre-share group 2 crypto isakmp key vpnblog address 10.0.0.1 ! crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac ! crypto ipsec profile VPN_P2 set transform-set ESP-3DES-SHA ! interface Tunnel0 ip unnumbered FastEthernet0/0 tunnel source 10.0.0.2 tunnel destination 10.0.0.1 tunnel mode ipsec ipv4 tunnel protection ipsec profile VPN_P2 ! ip route 172.16.0.0 255.255.255.0 Tunnel0
Both my hosts can now ping each other. You can verify the VPN is up as follows:
ScreenOS SSG5-> get ike cookies IKEv1 SA -- Active: 1, Dead: 0, Total 1 80182f/0003, 10.0.0.1:500->10.0.0.2:500, PRESHR/grp2/3DES/SHA, xchg(5) (VPN_P1/grp-1/usr-1) resent-tmr 26233316 lifetime 28800 lt-recv 28800 nxt_rekey 28373 cert-expire 0 initiator, err cnt 0, send dir 0, cond 0x0 nat-traversal map not available ike heartbeat : disabled ike heartbeat last rcv time: 0 ike heartbeat last snd time: 0 XAUTH status: 0 DPD seq local 0, peer 0
IOS
Cisco#sh crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 10.0.0.2
(removed for brevity)
inbound esp sas:
spi: 0x1DCD78DB(500005083)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3001, flow_id: FPGA:1, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4469954/3330)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound esp sas:
spi: 0x3593AF04(898871044)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3002, flow_id: FPGA:2, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4469953/3329)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
Of course the best thing about using a tunnel interface is that you can use it like a regular layer 3 interface. If both sides are under the same administrative control why not just run OSPF instead of the static routes?
ScreenOS set protocol ospf set enable set interface trust protocol ospf area 0.0.0.0 set interface trust protocol ospf passive set interface trust protocol ospf enable set interface tunnel.1 protocol ospf area 0.0.0.0 set interface tunnel.1 protocol ospf enable set interface tunnel.1 mtu 1443 unset route 192.168.0.0/24 interface tunnel.1
IOS interface FastEthernet0/1 ip ospf 1 area 0 ! interface Tunnel0 ip ospf 1 area 0 ! no ip route 172.16.0.0 255.255.255.0 Tunnel0
Cisco#sh ip route 172.16.0.0
O 172.16.0.0 [110/11112] via 10.0.0.1, 00:01:19, Tunnel0
SSG5-> get route ip 192.168.0.0
Dest for 192.168.0.0
--------------------------------------------------------------------------------------
trust-vr : => 192.168.0.0/24 (id=9) via 0.0.0.0 (vr: trust-vr)
Interface tunnel.1 , metric 2
I had to change the MTU of the ScreenOS tunnel as they report their sizes a bit differently.
So the above is all very simple, as long as both sides are using route-based VPN tunnels. Unfortunately 90% of the time I see the 3rd party creating a policy-based tunnel. While you can match it to be a policy-based tunnel on the ScreenOS side, you can actually still run a route-based VPN. No you won’t be able to run a routing protocol over it, but it will keep your configuration clean.
Cisco crypto isakmp policy 1 encr 3des authentication pre-share group 2 crypto isakmp key vpnblog address 10.0.0.1 ! ! crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac ! crypto map VPN_P2 10 ipsec-isakmp set peer 10.0.0.1 set transform-set ESP-3DES-SHA set pfs group2 match address 100 ! interface FastEthernet0/0 crypto map VPN_P2 ! access-list 100 permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255
The ScreenOS config is the same, except for the fact that I’ve re-added that static route over the tunnel.
Unfortunately the VPN does not come up, but if you check the ScreenOS event log it’s quite clear what’s happening:
Rejected an IKE packet on untrust from 10.0.0.2:500 to 10.0.0.1:500 with cookies 39baf5f7 and 9e7b3f4ab8141de4 because The peer sent a proxy ID that did not match the one in the SA config. IKE 10.0.0.2 Phase 2: No policy exists for the proxy ID received: local ID (172.16.0.0/255.255.255.0, 0, 0) remote ID (192.168.0.0/255.255.255.0, 0, 0).
The ScreenOS box is complaining that the proxy-id received does not match it’s own. The Cisco proxy-id is made up from the ACL we defined above. As the ScreenOS box is running a route-based VPN, it’s proxy-id is essentially 0.0.0.0/0 0.0.0.0/0
To fix it, we can very easily ‘fake’ our proxy-id on the ScreenOS box:
set vpn "VPN_P2" proxy-id local-ip 172.16.0.0/24 remote-ip 192.168.0.0/24 "ANY"
As soon as this command is entered, both VPN tunnels come straight up.
What is quite common is for multiple subnets from one side needing access to multiple subnets to the other and vice-versa. Now a route-based VPN on both sides would run this extremely easily with a single IPSec tunnel. If the remote party is determined to use policy-based VPNs on their Cisco device, you can still run multiple tunnels to them.
A great feature as of ScreenOS 6.3 onwards is that you can create multiple proxy-ids per phase 2 tunnel. With each proxy-id it’ll spawn a new phase 2 tunnel, but the only configuration you need to do is to add another proxy-id to the existing tunnel. Nice and Easy!
Anyone who is studying for the CCIE knows a lot about TCL scripting. Most certainly a big timesaver.
Of course TCL scripts can also be used in the real world. You don’t want to have to type our your script all the time, so is there a better way?
Over at networking-forum.com I asked if someone could come up with a script that would check for a route in any given subnet and return a ‘No route found’ for any IP address not in my global route table. I forgot who came up with it for me (sorry) but here is an example. Let’s say I wanted to check what routes I had for the range 10.20.16.0/20 – Of course usually this would be for a public range, but work with me here. This is the script:
#set the starting IP address octets
set firstoctet 10
set secondoctet 20
set thirdoctet 16
set fourthoctet 0
#while we're less than 10.20.31.255
while { $thirdoctet <= 31 } {
while { $fourthoctet <= 255 } {
set ipaddr $firstoctet.$secondoctet.$thirdoctet.$fourthoctet
set results [exec "show ip route $ipaddr"]
if { [regexp "not in table" $results] } {
puts "No route found for $ipaddr"
}
incr fourthoctet
}
#if out of the inner loop, reset the fourth back to 0 and increment the second octet
set fourthoctet 0
incr thirdoctet
}
This script works wonders, but it's pretty big to have to even copy and paste in each time I want to run it.
What I've now done is save the above script into a simple text file and renamed it to 10_20_16_0.tcl - I then tftp'd is to the flash on my router
There are now a couple of ways to run this file. The first way is to manually run it when I need to. How? Like so:
Router#tclsh flash:/10.20.16.0.tcl No route found for 10.20.16.40 No route found for 10.20.16.41
The source will simply load and execute the tcl script straight away. This is certainly handy for those scripts you only want to run now and then.
What if you want to run a script automatically? Why not use EEM :)
event manager applet TCL_RUN event none action 1.0 cli command "enable" action 1.1 cli command "tclsh flash:/10_20_16_0.tcl"
The beauty of using EEM is that it can track all kinds of things, and based on those events it can run tcl scripts for you.
To actually run the EEM script yourself you can do so like this:
event manager run TCL_RUN
Nice and easy :)
The subinterface is an invaluable tool in your belt. I pretty must use subinterfaces whenever I connect routers to each other via ethernet, even if initially they are only going to have a single point-to-point connection to each other.
Why? Well a subinterface allows you to stick a dot1q header on your frames. Just like running a trunk between 2 switches, it allows you to run multiple logical links between 2 routers. As noted above, even if you only have a single point-to-point connection between 2 routers I still run them. In the past I’ve had to change or add to a design. If I was running just the physical interfaces and needed to change it, I would require downtime and possibly even going to site to actually reconfigure the CPE device. If I used subinterfaces from the start I can just add another subinterface to the mix. There is ways to get around this though.
You can also mix regular and subiterfaces together on the same interface. You can also tag a subinterface as the native vlan. Let’s look at a couple of different examples and see what we see.
Let’s just start with a simple physical interface setup.
R1:
interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.0
R2:
interface FastEthernet0/0 ip address 192.168.1.2 255.255.255.0
R1#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/25/68 ms
Let’s say now that for whatever reason we need to run another logical link between these 2 routers. Let’s also say that R2 happens to be on the other side of the country and we need to do this now. Well I did note above that there is a workaround for this as you can run both a physical and subinterface on the router at the same time. Let’s leave the above config in and add this:
R1:
interface FastEthernet0/0.10 encapsulation dot1Q 10 ip address 10.0.0.1 255.255.255.0
interface FastEthernet0/0.10 encapsulation dot1Q 10 ip address 10.0.0.2 255.255.255.0
R1#ping 10.0.0.2 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 28/28/28 ms R1#ping 192.168.1.2 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 24/24/24 ms
Both still work. Now you could log onto R2 via the 10.0.0.2 link and remove the 192.168.1.0/24 address if you wanted without worry. Wireshark shows traffic going over the physical interface has no dot1q tag, while the subinterface has a dot1q tag of 10:
Now let’s mix it up a bit. I can say that a subinterface is tagged with the native vlan. i.e. no vlan tag:
R1:
interface FastEthernet0/0.20 encapsulation dot1Q 20 native ip address 20.20.20.1 255.255.255.0
R2:
interface FastEthernet0/0 ip address 20.20.20.2 255.255.255.0 secondary ip address 192.168.1.2 255.255.255.0
R1#ping 20.20.20.2 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 20.20.20.2, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 24/24/24 ms
On R1 I created a subinterface with the native vlan. On R2 I added a secondary IP address. Traffic for the 20.20.20.0/24 range goes over the wire without a dot1q tag. Why not just use a secondary address? Well you can stick a subinterface into a vrf, while you can’t do that with a secondary address. Your IGP behavior also changes somewhat.
I don’t quite like doing the above though. I don’t like have layer2 seperation between networks that should be separated. However it proves the point that a native subinterface’s traffic outbound is exactly the same format as a physical interface. Just a standard ethernet layer2 header with no dot1q tag.
There is another advantage to using a native subinterface. If I want to shut down the link for 20.20.20.0/24, on R1 I can shut down the subinterface. All other subinterfaces stay up. If I do this on R2 however, all subinterfaces go down:
R1:
R1(config)#int fa0/0.20 R1(config-subif)#shut R1(config-subif)#end R1# *Mar 1 00:33:31.023: %SYS-5-CONFIG_I: Configured from console by console R1#sh ip int brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.1.1 YES manual up up FastEthernet0/0.10 10.0.0.1 YES manual up up FastEthernet0/0.20 20.20.20.1 YES manual administratively down down
R2(config)#int fa0/0 R2(config-if)#shut R2(config-if)#end R2# *Mar 1 00:34:51.955: %SYS-5-CONFIG_I: Configured from console by console R2#sh ip int *Mar 1 00:34:53.347: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down *Mar 1 00:34:54.347: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down R2#sh ip int brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.1.2 YES manual administratively down down FastEthernet0/0.10 10.0.0.2 YES manual administratively down down
So while the native subinterface and physical interface send traffic the same, I can shut a native subinterface without affecting any other subinterface, while the shutting down of a physical interface shuts down all the subinterfaces attached to it
Now let’s get deeper…
R1:
interface FastEthernet0/0.10 encapsulation dot1Q 10 native ip address 10.10.10.1 255.255.255.0
R2:
interface FastEthernet0/0.10 encapsulation dot1Q 10 ip address 10.10.10.2 255.255.255.0
Here I have R1 configured with a native subinterface, while R2 is configured with a dot1q header of 10. You would expect there would be no communication between them, but you would be incorrect. I’m going to turn on debug ip packet on both routers for this to see who sees what
R1:
R1#ping 10.10.10.2 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: *Mar 1 00:08:07.763: IP: tableid=0, s=10.10.10.1 (local), d=10.10.10.2 (FastEthernet0/0.10), routed via FIB *Mar 1 00:08:07.763: IP: s=10.10.10.1 (local), d=10.10.10.2 (FastEthernet0/0.10), len 100, sending. Success rate is 0 percent (0/1)
So the ping failed, but look more closely. R1 was able to encapsulate the packet, which means it has a MAC address. Let’s look at the ARP table:
R1#sh arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.10.10.1 - c200.3e78.0000 ARPA FastEthernet0/0.10 Internet 10.10.10.2 2 c201.3e78.0000 ARPA FastEthernet0/0.10
Let’s try the other way around now.
R2:
R2#ping 10.10.10.1 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds: *Mar 1 00:11:20.807: IP: tableid=0, s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), routed via RIB *Mar 1 00:11:20.811: IP: s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), len 100, sending *Mar 1 00:11:20.815: IP: s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), len 100, encapsulation failed. Success rate is 0 percent (0/1)
Let’s have a look at the ARP cache:
R2#sh arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.10.10.1 0 Incomplete ARPA Internet 10.10.10.2 - c201.3e78.0000 ARPA FastEthernet0/0.10
Somehow R1 learned R2′s MAC address so communication was there, but it seems it’s only one way. Let’s clear the ARP cache on both and debug ARP to see what happens.
The first thing you notice when you clear the ARP cache is that the local router will send a gratuitous ARP out to let everyone else know about it. Let’s see what we see on R1 when we clear R2′s cache:
R2:
R2#clear arp
R2#
*Mar 1 00:18:45.135: ARP: flushing ARP entries for all interfaces
*Mar 1 00:18:45.143: IP ARP: sent rep src 10.10.10.2 c201.3e78.0000,
dst 10.10.10.2 ffff.ffff.ffff FastEthernet0/0.10
R1:
R1# *Mar 1 00:18:31.231: IP ARP: rcvd rep src 10.10.10.2 c201.3e78.0000, dst 10.10.10.2 FastEthernet0/0.10
R1 receives this gratuitous ARP and installs the MAC address into it’s ARP cache. Wireshark shows that R2 is sending this gratuitous ARP with a dot1q tag:
What about the other way?
R1:
R1#clear arp
R1#
*Mar 1 00:20:53.847: ARP: flushing ARP entries for all interfaces
*Mar 1 00:20:53.855: IP ARP: sent rep src 10.10.10.1 c200.3e78.0000,
dst 10.10.10.1 ffff.ffff.ffff FastEthernet0/0.10
R2:
R2# *Mar 1 00:21:07.831: IP ARP rep filtered src 10.10.10.1 c200.3e78.0000, dst 10.10.10.1 ffff.ffff.ffff wrong cable, interface FastEthernet0/0
R2 complains that this ARP is coming in on ‘the wrong cable’ while wireshark shows the gratuitous ARP being sent without a dot1q header as expected.
What can we get from this? Well if you have a native subinterface, it will accept both untagged AND tagged frames in the vlan, vlan 10 in my example above. However it will only SEND untagged traffic. Good to know. It can also explain why you sometimes see an ARP entry on one side, while not on the other.
Sometimes it’s required that you have a number of static routes on a router, maybe for management or some other reason. If the static route point to a next-hop, but the exit interface stays up, there is no way for the router to know that it’s sending traffic down a black hole. Let’s show the following diagram as an example:
R2 is a CPE on site. It has a primary link on fa0/0 connected to both R3 and R4 through a switch/VPLS. R2 is running OSPF with R3 and R4 and also has a floating static default route to R4′s fa0/0 interface. If this link goes down, the floating static route should come into play and take over. While the link is up we have a static route on R2 that sends our management traffic (10.0.0.0/24) to R4′s fa0/0 interface.
R3 is originating a default route via OSPF.
But does this actually work? Let’s configure it up quickly first and then break R2′s primary link.
R3:
interface FastEthernet0/0 ip address 192.168.234.3 255.255.255.0 ip ospf 1 area 0 ! router ospf 1 default-information originate always
R4:
interface FastEthernet0/0 ip address 192.168.234.4 255.255.255.0 ip ospf 1 area 0 ! interface Serial0/0 ip address 24.24.24.4 255.255.255.0
R2
interface FastEthernet0/0 ip address 192.168.234.2 255.255.255.0 ip ospf 1 area 0 ! interface Serial0/0 ip address 24.24.24.2 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 24.24.24.4 200 ip route 10.0.0.0 255.255.255.0 192.168.234.4
Let’s have a look at R2′s routing table:
R2# sh ip route | begin Gate
Gateway of last resort is 192.168.234.3 to network 0.0.0.0
C 192.168.234.0/24 is directly connected, FastEthernet0/0
24.0.0.0/24 is subnetted, 1 subnets
C 24.24.24.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
S 10.0.0.0 [1/0] via 192.168.234.4
O*E2 0.0.0.0/0 [110/1] via 192.168.234.3, 00:01:22, FastEthernet0/0
All looks good. I have my OSPF default route and I also have my management range route to R4.
Now for some reason, R2′s primary link fails. The fa0/0 interface stays up however.The link is dodgy, r there is a mess-up with the VPLS, it doesn’t really matter. What happens then?
R2 loses it’s adjacency with R4, but what about our management traffic?
R2# sh ip route | begin Gate
Gateway of last resort is 24.24.24.4 to network 0.0.0.0
C 192.168.234.0/24 is directly connected, FastEthernet0/0
24.0.0.0/24 is subnetted, 1 subnets
C 24.24.24.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
S 10.0.0.0 [1/0] via 192.168.234.4
S* 0.0.0.0/0 [200/0] via 24.24.24.4
The problem is that we are still sending management traffic off to R4. This is the problem with a static route, it’s static! R2 has a next-hop of 192.168.234.4 – It’s interface in this subnet is still up, and so the router is trying to ARP for 192.168.234.4. Of course R4 never responds but the router will continue to try. It’ll never fail over to the backup.
Now with reliable static routing you are able to generate an IP Sla object which consistently pings another interface. If you get no response you cause the track object to go down and hence the static route goes down. The problem with this is that you need an expensive data license for the privilege of doing this.
But track objects can track a lot more than just IP Sla objects. You can also track routes. So why not track the default route considering we are learning that through the primary link? If the primary fails and OSPF times out, we will remove the OSPF default. Let’s try and see what happens:
R2:
track 1 ip route 0.0.0.0 0.0.0.0 reachability ! ip route 10.0.0.0 255.255.255.0 192.168.234.4 track 1
Some of you may see a problem here, but bear with me.
Let’s see if this has fixed the problem:
R2# sh ip route | begin Gate
Gateway of last resort is 24.24.24.4 to network 0.0.0.0
C 192.168.234.0/24 is directly connected, FastEthernet0/0
24.0.0.0/24 is subnetted, 1 subnets
C 24.24.24.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
S 10.0.0.0 [1/0] via 192.168.234.4
S* 0.0.0.0/0 [200/0] via 24.24.24.4
Hmm, we are still sending traffic to R4′s fa0/0 interface. Why is this?
R2#sh track 1
Track 1
IP route 0.0.0.0 0.0.0.0 reachability
Reachability is Up (static)
1 change, last change 00:04:22
First-hop interface is Serial0/0
Tracked by:
STATIC-IP-ROUTING 0
The problem is that our floating static route went live. As soon as it did we had a default route again and hence the track object is now UP.
But you don’t HAVE to track a default route. Why don’t we simply inject a phantom prefix on R3? One that will simply be used for tracking?
R3:
interface Loopback1 ip address 3.3.3.3 255.255.255.255 ip ospf 1 area 0
R2:
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#no track 1 R2(config)#track 1 ip route 3.3.3.3/32 reachability
R2 is now tracking the loopback route from R3:
R2#sh track 1
Track 1
IP route 3.3.3.3 255.255.255.255 reachability
Reachability is Up (OSPF)
2 changes, last change 00:00:03
First-hop interface is FastEthernet0/0
Tracked by:
STATIC-IP-ROUTING 0
R2# sh ip route | begin Gate
Gateway of last resort is 192.168.234.3 to network 0.0.0.0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/11] via 192.168.234.3, 00:00:24, FastEthernet0/0
C 192.168.234.0/24 is directly connected, FastEthernet0/0
24.0.0.0/24 is subnetted, 1 subnets
C 24.24.24.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
S 10.0.0.0 [1/0] via 192.168.234.4
O*E2 0.0.0.0/0 [110/1] via 192.168.234.3, 00:00:24, FastEthernet0/0
R2 now loses OSPF adjacency:
R2#
*Mar 1 00:38:51.919: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.234.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R2#
*Mar 1 00:38:55.239: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.234.4 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R2#
*Mar 1 00:39:05.307: %TRACKING-5-STATE: 1 ip route 3.3.3.3/32 reachability Up->Down
R2#
R2#sh track 1
Track 1
IP route 3.3.3.3 255.255.255.255 reachability
Reachability is Down (no route)
3 changes, last change 00:00:11
First-hop interface is unknown
Tracked by:
STATIC-IP-ROUTING 0
R2# sh ip route | begin Gate
Gateway of last resort is 24.24.24.4 to network 0.0.0.0
C 192.168.234.0/24 is directly connected, FastEthernet0/0
24.0.0.0/24 is subnetted, 1 subnets
C 24.24.24.0 is directly connected, Serial0/0
S* 0.0.0.0/0 [200/0] via 24.24.24.4
R2 loses the track route, removes the static and install the floating static route. All is good :)
I know there are better ways of doing the above. As in advertise management ranges via OSPF or running BFD, but not all of these are always available, especially over back up links.
I know the title is quite a mouthful, but I did want to cover all the above in this post. Daniel asked me to check a few things as I have ready access to real switches.
You learn in your studies that layer 2 control packets are ‘special’ – Special in the way that traffic going over the trunk between 2 switches does not follow the standard practice. Let’s use wireshark to see exactly what is going on in a bunch of scenarios. It’ll also give me the opportunity to do a bit of testing with SPAN and RSPAN.
Let’s use the basic topology:
Let’s first set up a span session on the 3750. I will monitor port gi1/0/9 in both directions and send that traffic to gi1/0/24 to be picked up by the laptop.
monitor session 1 source interface Gi1/0/9 monitor session 1 destination interface Gi1/0/24
The first thing I noticed when I plug in my laptop however is that Windows of course is very noisy. Already my capture is filling up with stuff that Windows is sending out. And so I’ve downloaded an NST ISO which I’ll listen with on the laptop.
So now that I’ve booted up into NST and got Wireshark running, I hardly see anything at all happening between the 2 switches. Where is all the layer 2 control traffic? Well the problem is that control traffic is not automatically replicated to a SPAN port. You need to enable encapsulation replication in order for it to work. Let’s do so:
C3750#conf t C3750(config)#monitor session 1 destination interface gi1/0/24 encapsulation replicate
Let’s verify:
C3750#sh monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/9
Destination Ports : Gi1/0/24
Encapsulation : Replicate
Ingress : Disabled
I can now see lot’s of control traffic in my Wireshark capture.
Both switches are already connected to each other. By default they’ll create a trunk link and vlan 1 will be the native vlan. I’ll then configure the switches to tag the native vlan and see what happens.
Let’s ensure the native vlan is not currently tagged:
C3750#sh vlan dot1q tag native dot1q native vlan tagging is disabled
So what does my CDP/STP/DTP control packets look like in Wireshark? Note that I’m running the default mode of STP on the switch for now
I do see something odd. I am seeing an STP packet that has a dot1q tag of 1, 10 and an untagged packet. 10 I can understand because I have created vlan 10 and it has a separate STP instance. But why would the main one be tagged with vlan 1 if vlan 1 is the native vlan?
dot1q vlan 1
dot1q vlan 10
no dot1q tag
What about DTP and CDP?
DTP
CDP
Both CDP and DTP are currently sent with no vlan tag at all. CDP does carry information about the native vlan in it’s packet which is why CDP does complain when these don’t match on either end. But the important thing is that both are untagged.
Let’s now tag the native vlan and see what happens.
C3750(config)#vlan dot1q tag native C3750#sh vlan dot1q tag native dot1q native vlan tagging is enabled
Let’s bring up the interfaces again and see what we see.
DTP
CDP
Interesting. DTP has not tag, but CDP is using a tag of 1.
What about STP?
I’m seeing the same as what I saw above. I see a tagged vlan 1 STP frame, a tagged vlan 10 STP frame, and finally an untagged STP frame
What happens if I change the native vlan to 10? Well no need to paste output because it’s exactly the previous example. i.e. vlan 10 is now the native vlan and tagged, but CDP is still using a tag value of 1. STP and DTP remain unchanged.
Now let’s try something else. Let’s keep vlan 10 as the tagged native, but let’s remove vlan 1 from the trunk:
interface GigabitEthernet1/0/9 switchport trunk encapsulation dot1q switchport trunk native vlan 10 switchport trunk allowed vlan 2-4094
DTP is unchanged. i.e. it’s still sending untagged traffic. CDP however is sending tagged traffic. In vlan 1!
As a quick test I created int vlan 1 on both switches in the same subnet and tried to ping accross. I could not. Therefore it looks like Cisco will use vlan 1 tagged to send certain control data, even if vlan 1 is pruned, but no user data will be allowed on that vlan.
For STP I still have the same 3 outputs. A tagged vlan 1 STP frame, A tagged vlan 10 STP frame, and an untagged STP frame.
One last thing I wanted to test now was RSPAN config. I’ve always been a little confused as to the correct config on a switch that is the RSPAN end-point, and is also sending traffic to be monitored. i.e. Let’s say that the 3550 above is monitoring traffic on vlan 2 with a destination of remote span vlan 500. The 3750 is the rspan endpoint who monitoring rspan vlan 500 and sends it out to a local port on the switch. What happens if the 3750 is also monitoring vlan 2 on it’s own ports and sending out. Do we configure the destination to vlan 500 or straight to a local port?
Let’s configure it like so:
C3750#sh monitor session all
Session 1
---------
Type : Remote Source Session
Source Ports :
Both : Gi1/0/9
Dest RSPAN VLAN : 500
Session 2
---------
Type : Remote Destination Session
Source RSPAN VLAN : 500
Destination Ports : Gi1/0/24
Encapsulation : Replicate
Ingress : Disabled
I’ve tested sending it to RSPAN vlan 500 and I don’t see any traffic at all. As soon as I change it to send traffic directly to the port it works.
EDIT (05/06/12) – I’ve uploaded my captures to Cloudshark so you can take them apart to do your own research
Untagged native vlan 1
Tagged native vlan 1
Tagged native vlan 10
Tagged native vlan 10 with vlan 1 removed from trunk
Comments