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’ve got a spare Juniper M10 in my lab, and I wanted to upgrade JUNOS to version 10. With JUNOS you can only upgrade 3 minor revisions at a time, so I needed to go up to 8.5 first. However I got this error:
WARNING: This installation will not succeed. WARNING: The boot device is less than 256M. WARNING: A hardware upgrade is required.
8.5 requires a 256MB boot partition. 9.0 requires a flash card of at least 512MB and 10.0+ needs a Gig card.
These old routing engines are not the easiest to upgrade. You need to take out the routing engine from the back of the M10 and physically remove 2 boards from each other. You can find a detailed description of how to remove it over here: http://juniper.cluepon.net/Replacing/upgrading_the_CF_on_a_RE
This is what the original internal card looks like:
Once I get the old card out (96MB) I decided on trying a couple I had lying around. The first one I tried was a Kingston 2GB card:
I stuck the routing engine back into the M10 and booted it up. Please note you WILL need console access for these next steps.
When booting up, it’ll try and boot up from the compact flash card. It’ll sit here for a good 5 minutes or so, just leave it be. It’ll eventually reboot and boot off the internal hard disk. Once booted, you’ll need to issue ‘request system snapshot partition’
root> request system snapshot partition
Clearing current label...
Partitioning compact-flash media (ad0) ...
Partitions on snapshot:
Partition Mountpoint Size Snapshot argument
a / 1024MB root-size
e /config 198MB config-size
f /var 760MB var-size
Running newfs (1024MB) on compact-flash media / partition (ad0s1a)...
Running newfs (198MB) on compact-flash media /config partition (ad0s1e)...
Running newfs (760MB) on compact-flash media /var partition (ad0s1f)...
Copying '/dev/ad1s1a' to '/dev/ad0s1a' .. (this may take a few minutes)
Copying '/dev/ad1s1e' to '/dev/ad0s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config
The above will take quite a while, but it’ll partition up the flash card, and then copy the boot partitions over to the flash disk. You can see that it automatically created a boot partition of 1GB – I’m not sure if you can manually adjust this.
Now all you need to do it reboot:
root> request system reboot Reboot the system ? [yes,no] (no) yes
You should see this on startup:
Trying to Boot from Compact Flash... Loading /boot/loader Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 (builder@vouivre.juniper.net, Thu Apr 12 00:09:54 GMT 2007) Loading /boot/defaults/loader.conf /kernel text=0x4bbe0b data=0x3ca74+0x62caa syms=[0x4+0x5a9c0+0x4+0x6a58f] Hit [Enter] to boot immediately, or space bar for command prompt.
Looks fine to me. You can also verify from the cli:
root> show system storage Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1.7G 49M 1.5G 3% /
ad0 is the flash card. Finally you can verify with the show system boot-messages command:
root> show system boot-messages Copyright (c) 1996-2001, Juniper Networks, Inc. All rights reserved. . . . [removed to make it easier to read] . . ad0: 1983MB [4029/16/63] at ata0-master PIO4 ad1: 11513MB [23392/16/63] at ata0-slave UDMA33 Mounting root from ufs:/dev/ad0s1a
Finally, can I now install higher versions of JUNOS?
root> show version Model: m10 JUNOS Base OS boot [8.5R2.10] JUNOS Base OS Software Suite [8.5R2.10]
root> show version Model: m10 JUNOS Base OS boot [9.3R4.4] JUNOS Base OS Software Suite [9.3R4.4]
root> show version Model: m10 JUNOS Base OS boot [10.0R4.7] JUNOS Base OS Software Suite [10.0R4.7]
Works perfectly fine. 1 thing I have noticed is that upgrading the JUNOS image took a while, but it’s not something you do everyday. I’ve now gone JUNOS 10 on this box :)
EDIT (11/01/11): I was trying to upgrade from 10.1 to 10.2 and noticed that I suddenly had no space in /var – Checking the logs I see this:
ad1: 11513MBat ata0-slave UDMA33
root> show system storage Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1.7G 168M 1.4G 10% / devfs 1.0K 1.0K 0B 100% /dev devfs 1.0K 1.0K 0B 100% /dev/ /dev/md0 34M 34M 0B 100% /packages/mnt/jbase /dev/md1 232M 232M 0B 100% /packages/mnt/jkernel-10.0R4.7 /dev/md2 16M 16M 0B 100% /packages/mnt/jpfe-M10-10.0R4.7 /dev/md3 5.5M 5.5M 0B 100% /packages/mnt/jdocs-10.0R4.7 /dev/md4 60M 60M 0B 100% /packages/mnt/jroute-10.0R4.7 /dev/md5 15M 15M 0B 100% /packages/mnt/jcrypto-10.0R4.7 /dev/md6 36M 36M 0B 100% /packages/mnt/jpfe-common-10.0R4.7 /dev/md7 63M 8.0K 58M 0% /tmp /dev/md8 63M 13M 45M 22% /mfs /dev/ad0s1e 195M 12K 179M 0% /config procfs 4.0K 4.0K 0B 100% /proc
root> request system partition hard-disk mount: /dev/ad1s1e : No such file or directory
Hmm, BIOS sees the hard drive, but I can’t use it. this was easily fixed though:
root> request system snapshot partition
Clearing current label...
Partitioning hard-disk media (ad1) ...
Partitions on snapshot:
Partition Mountpoint Size Snapshot argument
a / 1024MB root-size
e /config 1GB config-size
f /var 9GB var-size
Running newfs (1024MB) on hard-disk media / partition (ad1s1a)...
Running newfs (1GB) on hard-disk media /config partition (ad1s1e)...
Running newfs (9GB) on hard-disk media /var partition (ad1s1f)...
Copying '/dev/ad0s1a' to '/dev/ad1s1a' .. (this may take a few minutes)
Copying '/dev/ad0s1e' to '/dev/ad1s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config
root> request system partition hard-disk WARNING: The hard disk is about to be partitioned. The contents WARNING: of /altroot and /altconfig will be saved and restored. WARNING: All other data is at risk. This is the setup stage, the WARNING: partition happens during the next reboot. Setting up to partition the hard disk ... WARNING: A REBOOT IS REQUIRED TO PARTITION THE HARD DISK. Use the WARNING: 'request system reboot' command when you are ready to proceed WARNING: with the partitioning. To abort the partition of the hard disk WARNING: use the 'request system partition abort' command. root> request system reboot Reboot the system ? [yes,no] (no) yes
I then rebooted
root> show system storage Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1.7G 168M 1.4G 10% / devfs 1.0K 1.0K 0B 100% /dev devfs 1.0K 1.0K 0B 100% /dev/ /dev/md0 34M 34M 0B 100% /packages/mnt/jbase /dev/md1 232M 232M 0B 100% /packages/mnt/jkernel-10.0R4.7 /dev/md2 16M 16M 0B 100% /packages/mnt/jpfe-M10-10.0R4.7 /dev/md3 5.5M 5.5M 0B 100% /packages/mnt/jdocs-10.0R4.7 /dev/md4 60M 60M 0B 100% /packages/mnt/jroute-10.0R4.7 /dev/md6 15M 15M 0B 100% /packages/mnt/jcrypto-10.0R4.7 /dev/md7 36M 36M 0B 100% /packages/mnt/jpfe-common-10.0R4.7 /dev/md8 1006M 8.0K 926M 0% /tmp /dev/md9 1006M 1.2M 925M 0% /mfs /dev/ad0s1e 195M 12K 179M 0% /config procfs 4.0K 4.0K 0B 100% /proc /dev/ad1s1f 8.2G 12M 7.5G 0% /var
All fixed
I’m going to start blogging about various design stuff that I do these days at work. Maybe you can get some ideas from these types of posts.
I’m going to run this simple topology:
The client has 2 networks at the first site – 192.168.1.0/24 and 10.10.10.0/24. These are both connected to R1 and R2 (via a switch not shown) – R1 and R2 are running MHSRP, with R1 being the master of 192.168.1.254 and R2 being the master of 10.10.10.254. Both routers are the backup of each others group.
I want the link from R1 to be used for 192.168.1.0 and I want the link from R2 to be used for 10.10.10.0. I also want return traffic to take the same path. i.e. if R3 needs to send traffic to 10.10.10.0 – it needs to prefer the direct path to R2.
Another constraint is that I need convergence to be fast, therefore I’m not going to run HSRP on the WAN side of R1 and R2 and have to wait for the IGP to re-converge.
The final constraint is that I don’t want to have to use route-map’s on R3 itself. Let’s pretend there are going to be a lot more routers connected to OSPF area 0. I want to make it as simple as possible when newer routers come into the area. Therefore all this routing needs to be controlled by R1 and R2 themselves.
So far, pretty simple. So let’s get cracking!
Let’s do R1 first, this is the relevant config:
interface FastEthernet0/1 ip address 10.10.10.1 255.255.255.0 secondary ip address 192.168.1.1 255.255.255.0 standby version 2 standby 1 ip 192.168.1.254 standby 1 priority 110 standby 1 preempt standby 1 track FastEthernet0/0 50 standby 2 ip 10.10.10.254 standby 2 preempt standby 2 track FastEthernet0/0 50
And now R2:
interface FastEthernet0/1 ip address 10.10.10.2 255.255.255.0 ip address 192.168.1.2 255.255.255.0 secondary standby version 2 standby 1 ip 192.168.1.254 standby 1 preempt standby 1 track FastEthernet0/0 50 standby 2 ip 10.10.10.254 standby 2 priority 110 standby 2 preempt standby 2 track FastEthernet0/0 50
Now let’s set up OSPF. Remember that I want 192.168.1.0 traffic to go via R1 and 10.10.10.0 to go via R2. There are a number of ways of doing this.
First let’s try and set up regular OSPF with a metric:
router ospf 1 R1(config-router)#network 10.10.10.0 0.0.0.255 area 0 ? cr> R1(config-router)#network 10.10.10.0 0.0.0.255 area 0
OSPF will not allow you to specify a metric under the network command!
There is another way. Run 2 OSPF processes and redistribute with a higher metric.
router ospf 1 redistribute ospf 2 metric 50 metric-type 1 subnets network 1.1.1.0 0.0.0.255 area 0 network 192.168.1.0 0.0.0.255 area 0 ! router ospf 2 network 10.10.10.0 0.0.0.255 area 0
Let’s check R3′s routing table:
R3#sh ip route
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.50.0 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/51] via 1.1.1.1, 00:00:39, FastEthernet0/0
O 192.168.1.0/24 [110/2] via 1.1.1.1, 00:00:39, FastEthernet0/0
It works, but I think its messy. We could also use route-maps which would give us a lot finer control over newer subnets that may be added (without having to run more OSPF processes)
Let’s remove that OSPF config from R1 and do the following:
router ospf 1 redistribute connected metric-type 1 subnets route-map 10_HIGH network 1.1.1.0 0.0.0.255 area 0 ! ip prefix-list 10NET seq 5 permit 10.10.10.0/24 ! route-map 10_HIGH permit 10 match ip address prefix-list 10NET set metric +100 ! route-map 10_HIGH permit 20
Now we do this on R2:
router ospf 1 redistribute connected metric-type 1 subnets route-map 192_HIGH network 1.1.1.0 0.0.0.255 area 0 ! ip prefix-list 192NET seq 5 permit 192.168.1.0/24 ! route-map 192_HIGH permit 10 match ip address prefix-list 192NET set metric +100 ! route-map 192_HIGH permit 20
This will ensure R1 redistributes the 10.10.10.0 network with a higher metric to R3, and vice-versa for R2. R3 will have a possible route in it’s database, but won’t use it until the preferred link is down/
Let’s have a look at R3′s routing table:
R3#sh ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/21] via 1.1.1.2, 00:00:28, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:28, FastEthernet0/0
Excellent, just what we want. but do the backups work correctly? Let’s shut down R1′s interface to the customer LAN and see what happens:
R1(config)#int fa1/0 R1(config-if)#shut R1(config-if)# *Mar 1 00:34:20.711: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Active -> Init *Mar 1 00:34:20.723: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Standby -> Init *Mar 1 00:34:22.723: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state to administratively down *Mar 1 00:34:23.723: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down
What does R3 see?
R3#sh ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/21] via 1.1.1.2, 00:00:18, FastEthernet0/0
O E1 192.168.1.0/24 [110/101] via 1.1.1.2, 00:00:18, FastEthernet0/0
Both are now going via R2, which is exactly what we wanted. Let’s now reconnect R1 and disconnect R2′s WAN link:
R1(config-if)#int fa1/0 R1(config-if)#no shut R1(config-if)# *Mar 1 00:35:47.775: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Listen -> Active *Mar 1 00:35:47.859: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up *Mar 1 00:35:48.859: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
R2(config)#int fa0/0 R2(config-if)#shut R2(config-if)# *Mar 1 00:36:16.179: %TRACKING-5-STATE: 1 interface Fa0/0 line-protocol Up->Down *Mar 1 00:36:16.187: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Mar 1 00:36:16.187: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Mar 1 00:36:18.179: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down *Mar 1 00:36:18.231: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Active -> Speak *Mar 1 00:36:19.179: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
What does R3 see this time?
R3#sh ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/101] via 1.1.1.1, 00:00:03, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:03, FastEthernet0/0
Great. Let’s just make sure it all works properly again if all links are up:
R2(config-if)#int fa0/0 R2(config-if)#no shut R2(config-if)# *Mar 1 00:37:53.291: %TRACKING-5-STATE: 1 interface Fa0/0 line-protocol Down->Up *Mar 1 00:37:54.235: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Standby -> Active *Mar 1 00:37:55.287: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up *Mar 1 00:37:56.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R3#sh ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/21] via 1.1.1.2, 00:00:06, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:06, FastEthernet0/0
Let’s see what happens when a client is pinging a network directly connected to R3 over the 192.168.1.0 network. I’ll be using a router as a client, so it’ll be a ping flood.
R4#ping 172.16.50.1 repeat 1000
I’ll quickly shut R1′s LAN interface. Wait a bit, and then no shut it. What happens to R4′s pings?
Sending 1000, 100-byte ICMP Echos to 172.16.50.1, timeout is 2 seconds: !!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 99 percent (998/1000), round-trip min/avg/max = 1/44/160 ms
I lost only 2 pings! Once when I shut the interface, and the second when it came back up again. Pretty good!
It wont be as fast if the WAN link goes down though. R2 will take over for sending packets out, but return traffic will still go to R1. Why? Well remember R3 still thinks R1 is there. Unless they were directly connected, or you wait for OSPF to realise the peer is down, it’ll continue to send traffic that way. You can speed this up by reducing your OSPF hello timers though. This will need to be balanced on how much OSPF traffic you want going across your WAN link.
While studying for my CCNP I created a large amount of practice labs. I used these on the lab I created at work. The labs themselves fit into this topology but feel free to change it to fit yours. I’ll post a couple each day that focuses on a specific technology or procedure for 1 exam.
This is the topology I used:
Before starting an exam I’m sure to remove all old config (as well as doing a delete vlan.dat on the switches.) I also shut down all ports on the switches using the port range command and only open the ports needed for the particular lab. This prevents packets from leaking out when I’ve switched off 1 port hoping to cut a connection. Remember switches have all ports open by default, unlike routers which are admin shut by default
Comments