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.
RB PB VPN Route based and policy based IPSec vpns between Cisco IOS and Juniper ScreenOS

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!

Tagged with:  

Saving and running TCL scripts from flash

On August 23, 2012, in CCIE, by Darren

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 :)

Tagged with:  

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:
reliable static Reliable static routing without the need for the data license

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.

Tagged with:  

What exactly is NAT?

On November 29, 2010, in Fundamentals, by Darren

So we all use NAT daily, but what is it really doing? This is more of a ‘beginners’ guide than anything else. The IPv4 address space is rapidly running out. A long time ago, if you were a company with 150 users needing internet access, you would need a /24 public IP block. Essentially any device needing internet access would need to have a public, routable IP. Bigger companies needed much bigger blocks and so some were even given /16′s – Enough addresses to give 65536 devices a public IP. However this was never going to work forever. The IPv4 block is limited in size so we could not simply give all companies /16′s – Not only that but home users started needing more than a single IP address. ISP’s did not have enough IP’s to give each customer 8 or 16 addresses. S NAT was introduced. Essentially NAT ‘translates’ an IP address from one to another. This allows you to use RFC1918 addresses internally. Essentially this gives you 16 843 007 addresses to use, and that can all be ‘translated’ behind a single public IP address (or range, it doesn’t matter) Not only that, but that SAME RFC1918 address space can be used by everyone. It doesn’t matter it my home PC and your home PC are both 192.168.1.1, as these will be translated when going off to the internet. But what exactly is happening? I think we need an analogy here. Let’s imagine that you and I live in the same street. Let’s also imagine that you and I both live in an apartment block (or flat as well call it in the U.K.) natex1 What exactly is NAT? Let’s also say that I live in apartment 10 in my building and you live in apartment 10 in yours. How will the postman be able to deliver our post correctly if we both live at number 10 in the same street? That’s easy in the real world. Each building on the street will have it’s own number. All the public numbers on the street have to be unique. You can’t have 2 number 10 Bond Streets. A similar thing is happening when you NAT traffic, but your router/firewall/NAT device is going to do all the hard work for you. Let’s way through an example. I’m now at home and want to go to Cisco.com. My PC’s IP address is 192.168.1.10. Let’s also say my wife wants to get to Cisco.com at the same time. Her laptop’s IP address is 192.168.1.20. My laptop will source an IP packet that has a source address of 192.168.1.10 and a destination of 88.221.176.170. My wife’s laptop will source an IP packet with a source of 192.168.1.20 and a destination of 88.221.176.170. natex22 What exactly is NAT? Let’s pretend that my public IP is 1.1.1.1 – When these packets hit my router, the router will take my packet and change the source IP to 1.1.1.1 and use a high random port number (eg: 1.1.1.1:5000) and then send the packet off to Cisco.com. It will then take my wife’s packet and do the same, but use a different port. As an example let’s use 1.1.1.1:600 and also send it off to Cisco.com. natex3 What exactly is NAT? Cisco.com now receives both packets, and responds to both of them. When responding to mine, it’ll reply with a destination of 1.1.1.1:500. when it replies to my wife’s, it’ll reply with a destination of 1.1.1.1:600 natex4 What exactly is NAT? As this is a public address, it goes back to my router. Once there, the router will check the destination port. When it sees a port of 500, it knows that it created this port session earlier, and the original IP was 192.168.1.10. It will strip the destination IP address and insert 192.168.1.10 and then send it off on the LAN. The same thing happens for the next packet. The router will convert 1.1.1.1:600 to 192.168.1.20 and send it off to the LAN. natex5 What exactly is NAT?

Let’s have a look at a real world example. I’ve set up NAT through a Juniper SSG and these are the logs:

NATtablejuniper What exactly is NAT?

Here I’ve initiated pings from 2 internal machines to the same external IP address. You can see 10.1.1.50 is my first machine and 10.1.1.51 is my second. As far as 88.221.176.170 is concerned, all these pings are coming from the same 192.168.1.3 external address. The firewall will keep a session table and will know what to change the destination IP to when the packet comes back. Unfortunately I cannot actually show this in the picture above :(

Note that NAT can actually be used more than once in the same path. If you notice in the picture above I’m actually getting to 88.221.176.170 via 192.168.1.3. How is that possible when 192.168.1.3 is a private address? I’m actually NAT’d once more through a ZyXEL router. NAT can be layered many times, but it’s not something I would do.

Tagged with:  

HSRP Object tracking

On October 11, 2010, in CCIE, by Darren

HSRP can track interfaces, which is pretty handy if they are tracking the WAN interface to get out the network. There are times when tracking the interface itself is not enough. This is a great example:
HSRPObject1 HSRP Object tracking

Our customer is running HSRP between 2 routers connected to his local LAN. All PC’s connected to his switch are using 10.1.1.254 as their default gateway. R1 is the primary HSRP router and R2 is the backup.

HSRP allows you to track an interface and lower the priority if this happens. So let’s say R1′s WAN interface goes down, HSRP will notice that, and allow R2 to take over the HSRP group. This allows the customer to continue to get to the cloud. A basic config here:
R1:

interface FastEthernet0/1
 description LAN
 ip address 10.1.1.1 255.255.255.0
 standby version 2
 standby 1 ip 10.1.1.254
 standby 1 priority 110
 standby 1 preempt
 standby 1 track FastEthernet0/0 65

R2:

interface FastEthernet0/1
 description LAN
 ip address 10.1.1.2 255.255.255.0
 standby version 2
 standby 1 ip 10.1.1.254
 standby 1 preempt
 standby 1 track FastEthernet0/0 50

What happens if the interface stays up though? In the above diagram, R1′s WAN interface connects to a switch. Now this could be a local switch or a 3rd party NTE (which often happens on leased lines) – The circuit from the switch to the cloud could be down, but the port between the router and switch are still up.HSRPObject2 HSRP Object tracking
As far as HSRP is concerned, that interface is up and healthy. All LAN PC’s will continue to send traffic to R1, but that traffic gets dropped at the switch. Another case is if you’ve got some sort of MPLS/VPLS solution with your provider. They could have a problem and all traffic is getting black-holed inside their network. But R1 still thinks the link is healthy and sends it on it’s way.

There is a better way of doing this.

IOS allows you to track object. An object could be an IP SLA instance. That IP SLA instance could very easily be an ICMP echo from another device in the cloud. See where I’m going here?

Assume R3 has a rock solid connection. We could assume is a big bad router with multiple power feeds on multiple phases with multiple WAN connections. 192.168.1.1 is the loopback of this device accessible from multiple connections. Basically we assume that 192.168.1.1 is ALWAYS available.

Let’s create an IP SLA instance that tests connectivity to 192.168.1.1. We then tell HSRP to track reachability to that instance. If it cannot get to the instance, we can assume that the link to it is dead, regardless of whether R1′s WAN interface is up or not. First up is the IP SLA instance:

ip sla monitor 10
 type echo protocol ipIcmpEcho 192.168.1.1
 frequency 5
ip sla monitor schedule 10 life forever start-time now

Here we’ve told the router to ping 192.168.1.1 every 5 seconds and never stop. If I get a reply, consider the SLA a success. If I get no response, consider it a failure.

Now we tell IOS that we want to create an object and track this IP SLA instance:

track 100 rtr 10

I create an object labelled 100 that is tracking instance 10 of IP SLA we created above.

We now amend R1′s HSRP config as follows:

interface FastEthernet0/1
 description LAN
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 standby version 2
 standby 1 ip 10.1.1.254
 standby 1 priority 110
 standby 1 preempt
 standby 1 track FastEthernet0/0 65
 standby 1 track 100 decrement 65

I’ve kept the interface tracking there as if it goes down, why wait for IP SLA to timeout?

But does it work? Let’s have a look and see. Let’s kill S1′s connection into the cloud. Once that’s done, let’s have a look at R1:

R13#sh standby
FastEthernet0/1 - Group 1 (version 2)
  State is Standby
    7 state changes, last state change 00:01:08
  Virtual IP address is 10.1.1.254
  Active virtual MAC address is 0000.0c9f.f001
    Local virtual MAC address is 0000.0c9f.f001 (v2 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.052 secs
  Preemption enabled
  Active router is 10.1.1.2, priority 100 (expires in 9.052 sec)
  Standby router is local
  Priority 45 (configured 110)
    Track interface FastEthernet0/0 state Up decrement 65
    Track object 100 state Down decrement 65
  IP redundancy name is "hsrp-Fa0/1-1" (default)

R1#sh int fa0/0
FastEthernet0/0 is up, line protocol is up

IOS is telling us that although the interface is up, it’s passed the HSRP group to R2. Now we don’t have to worry about traffic getting black-holed!

btw, if you need to ping an address and can’t guarantee 100% availability, you could just as easily track 2 objects. Weight it so that only if pings fail to both will the HSRP group failover.

Tagged with:  

© 2009-2014 Darren O'Connor All Rights Reserved