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.
While going through the CCIE 4th edition cert guide, I’ve come across something that is potentially a very big problem. Currently if you want to authenticate OSPF and EIGRP neighbours you can do so via plain-text or MD5 passwords. With IPv6 you need to use OSPFv3 and EIGRP. Here’s where it get’s bad. OSPFv3 does NOT give you the option to use authentication in the OSPFv3 configuration section. Rather it relies on IPv6′s inherent authentication properties.
However!
In order to use IPv6′s authentication properties, you NEED a crypto license on your device. This means you can no longer authenticate OSPF for IPv6 with a base license IOS. EIGRP on the other hand still allows you to authenticate with MD5 and plain-text. Let’s put this to the test.
I’ve got a vanilla Cisco 1941 here with the base license.
1941test(config-if)#ipv6 ospf ?
<1-65535> Process ID
cost Route cost of this interface
database-filter Filter OSPF LSA during synchronization and flooding
dead-interval Interval after which a neighbor is declared dead
demand-circuit OSPF demand circuit
flood-reduction OSPF Flood Reduction
hello-interval Time between HELLO packets
mtu-ignore Ignores the MTU in DBD packets
network Network type
priority Router priority
retransmit-interval Time between retransmitting lost link state
advertisements
transmit-delay Link state transmit delay
What I’m looking for is the ipv6 ospf authentication ipsec command. As I have no security license, it’s not there.
1941test(config-router)#ipv6 router ospf 1 1941test(config-rtr)#area 0 ? default-cost Set the summary default-cost of a NSSA/stub area nssa Specify a NSSA area range Summarize routes matching address/mask (border routers only) stub Specify a stub area
No area 0 authentication option!
Interestingly enough, EIGRP for IPv6 still uses EIGRP’s internal authentication algorithm.
interface GigabitEthernet0/1 ip address 10.0.4.254 255.255.255.252 ipv6 address 2001:D08::C671:FEFF:FE65:55A1/64 ipv6 eigrp 1 ipv6 authentication mode eigrp 1 md5 ipv6 authentication key-chain eigrp 1 chain ! key chain chain key 1 key-string 7 010703174F
The problem with authentication being left to IPv6 itself, is shown in this very example. As far as I can see, unless you’re buying an expensive security license for each and every OSPF router, you can forget about authenticating your OSPF adjacencies!
I hope I’m mistaken. If anyone has a way of getting it to work, I’d like to know.
Updated post here: http://mellowd.co.uk/ccie/?p=1421
I’ve been wanting to do more Juniper studies. Unfortunately at work we only have 2 Junipers on the BGP edge so we don’t exactly get to play with them.
I’ve known about olives on the PC for a while, but I wanted something better. I could not afford to buy a J2300 so I went he next best route – The 1U Olive
I’ve just got it working too!
root> show version Model: olive JUNOS Base OS boot [7.1R2.2] JUNOS Base OS Software Suite [7.1R2.2] JUNOS Kernel Software Suite [7.1R2.2] JUNOS Packet Forwarding Engine Support (M20/M40) [7.1R2.2] JUNOS Routing Software Suite [7.1R2.2] JUNOS Online Documentation [7.1R2.2] JUNOS Crypto Software Suite [7.1R2.2] root> show interfaces terse Interface Admin Link Proto Local Remote dsc up up fxp0 up down fxp1 up down fxp2 up down gre up up ipip up up lo0 up up lo0.16385 up up inet inet6 fe80::200:ff:fe00:1 lsi up up mtun up up pimd up up pime up up tap up up
I’ve got a couple of other IP330′s so I just need to replicate this. I’ll stick this in the lab. This essentially gives 4 me Juniper routers!
The next step is to upgrade the JUNOS version on this one and do a few more. Then put them together and see what happens.
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 was tasked without setting up some IP SLA’s over our network to check performance at various points in the network. I’m not going to go hardcore into how to configure it, as Cisco has an excellent guide right here: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsjitter.html
There is something I wanted to point out though. I installed a 3750 in the core running the actual tests. IP SLA requires another Cisco router to actually respond to those tests, basically an IP SLA Responder. It seemed to me that a lot of devices we had simply did not support IP SLA, or at least I though.
IP SLA used to be called something completely different. In IOS release 12.1 (4) they released a feature called SAA Monitor. The commands used to configure it were completely different to IP SLA. Basically instead of typing:
Cisco(config)#ip sla responder
The command was instead:
Cisco(config)#rtr responder
Comments