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:
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.
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.
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:
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.
Comments