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:  

OSPF Area 0.0.0.0?

On October 2, 2010, in CCIE, by Darren

I quite often run OSPF on Juniper SSG’s – When configuring OSPF it requires you to put interfaces in areas in the format of x.x.x.x – for example 0.0.0.0

But what exactly does Area 0.0.0.0 compare to Area 0? And for that matter, where exactly does Area 10.1.1.1 fit in?

For this post, I’ll be using a simple topology. 2 Routers connected via OSPF, both redistributing their loopback addresses. If we see R2′s routes on R1 and vice-versa, we know OSPF is working. This is the topology:area0.0.0.0 1 OSPF Area 0.0.0.0?

OSPF actually sees areas in hex. This means that it considers Area 0 to be Area 0×00000000. OSPF will also convert dotted decimal to hex. This means that Area 0.0.0.0 is also equal to Area 0×00000000. Let’s test this to prove that it works.
R1:

router ospf 1
 log-adjacency-changes
 redistribute connected subnets
 network 172.16.1.1 0.0.0.0 area 0

R2:

router ospf 1
 log-adjacency-changes
 redistribute connected subnets
 network 172.16.1.2 0.0.0.0 area 0.0.0.0

Do they form an adjacency?
R1:

R1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.1.1.1          1   FULL/BDR        00:00:35    172.16.1.2      FastEthernet0

R2:

R2#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.10.1      1   FULL/DR         00:00:38    172.16.1.1      FastEthernet0

Do we have routes?

R1#sh ip route ospf
O E2    10.1.1.0 [110/20] via 172.16.1.2, 00:02:27, FastEthernet0
R2#sh ip route ospf
O E2 192.168.10.0/24 [110/20] via 172.16.1.1, 00:02:45, FastEthernet0

They see each others routes just fine. What’s also interesting is that IOS will continue to show you information in the correct format depending on the OSPF configuration on that link. For example, R2 is in Area 0.0.0.0 – If we look on R2 to check it’s neighbours details more carefully, IOS will show us the area according to R2:

R2#sh ip ospf neighbor 192.168.10.1
 Neighbor 192.168.10.1, interface address 172.16.1.1
    In the area 0.0.0.0 via interface FastEthernet0

Same with R1:

R1#sh ip ospf neighbor 10.1.1.1
 Neighbor 10.1.1.1, interface address 172.16.1.2
    In the area 0 via interface FastEthernet0

Going back to the beginning of the article, how does area 10.1.1.1 fit in? We need to convert 10.1.1.1 to decimal if we want them to match. As an easier example at first, consider Area 0.0.0.50 – That would match Area 50. What about Area 0.0.1.1 ? – That would match Area 257 (both of these match Area 0×00000101 according to OSPF)

Area 10.1.1.1 converts to Area 167837953. OSPF sees both of these areas as Area 0x0a010101 – but are we sure? Let’s test to find out!

router ospf 1
 log-adjacency-changes
 redistribute connected subnets
 network 172.16.1.1 0.0.0.0 area 167837953
router ospf 1
 log-adjacency-changes
 redistribute connected subnets
 network 172.16.1.2 0.0.0.0 area 10.1.1.1

Does it work?

R1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.1.1.1          1   FULL/BDR        00:00:35    172.16.1.2      FastEthernet0

R1#sh ip route ospf
O E2    10.1.1.0 [110/20] via 172.16.1.2, 00:01:10, FastEthernet0

R1#sh ip ospf neighbor 10.1.1.1
 Neighbor 10.1.1.1, interface address 172.16.1.2
    In the area 167837953 via interface FastEthernet0
R2#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.10.1      1   FULL/DR         00:00:33    172.16.1.1      FastEthernet0

R2#sh ip route ospf
O E2 192.168.10.0/24 [110/20] via 172.16.1.1, 00:02:04, FastEthernet0

R2#sh ip ospf neighbor 192.168.10.1
 Neighbor 192.168.10.1, interface address 172.16.1.1
    In the area 10.1.1.1 via interface FastEthernet0

It all works just fine! If you’ve got a well designed network, then using dotted decimal as areas has it’s advantages. 2 Areas that look different to you could very easily speak over OSPF if they match.

Tagged with:  

© 2009-2014 Darren O'Connor All Rights Reserved