From a previous OSPF related tutorial we’ve learned what is OSPF routing protocol.
How it works , how it is configured and all these helped us to understand how to proceed in rare atypical situations that may occur in real life.
In this tutorial we’ll learn how to use OSPF in order to create a failover network solution by using one trick out of so many tricks that OSPF has in its sleeve.
For this exercise we’ll use below shown topology
You can change the hostname as you please , it does not have any impact on the current failover solution demonstration.
For those PCs depicted in topology I’ve used Windows10 VMs , but VPCs are already available in GNS3 and can be used for that purpose as well.
Now we’ll see what has to be configured step by step
On Mugur_R1 :
interface Loopback100
ip address 10.10.10.10 255.255.255.255
!
interface GigabitEthernet0/0
description link to Mugur_R2 gi0/0
ip address 10.0.10.1 255.255.255.252
no shutdown
!
interface GigabitEthernet1/0
description link to Mugur_R3 GI1/0
ip address 172.16.20.1 255.255.255.252
no shutdown
!
interface GigabitEthernet6/0
description link to LAN1
ip address 192.168.100.1 255.255.255.0
no shutdown
!
ip dhcp pool LAN1
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
lease infinite
!
router ospf 100
router-id 10.10.10.10
priority 100
passive-interface GigabitEthernet6/0
network 10.0.10.0 0.0.0.3 area 0
network 10.10.10.10 0.0.0.0 area 0
network 172.16.20.0 0.0.0.3 area 0
network 192.168.100.0 0.0.0.255 area 0
!
On Mugur_R2 :
interface Loopback200
ip address 20.20.20.20 255.255.255.255
!
interface GigabitEthernet0/0
description link to Mugur_R1 GI0/0
ip address 10.0.10.2 255.255.255.252
no shutdown
!
interface GigabitEthernet1/0
description link to Mugur_R4 gi1/0
ip address 10.0.10.5 255.255.255.252
no shutdown
!
router ospf 200
router-id 20.20.20.20
network 10.0.10.0 0.0.0.3 area 0
network 10.0.10.4 0.0.0.3 area 0
network 20.20.20.20 0.0.0.0 area 0
!
On Mugur_R3 :
interface Loopback300
ip address 30.30.30.30 255.255.255.255
!
interface GigabitEthernet0/0
description link to Mugur_R5 int gi0/0
ip address 172.16.20.5 255.255.255.252
no shutdown
!
interface GigabitEthernet1/0
description link to Mugur_R1 gi1/0
ip address 172.16.20.2 255.255.255.252
no shutdown
!
router ospf 300
router-id 30.30.30.30
network 30.30.30.30 0.0.0.0 area 0
network 172.16.20.0 0.0.0.3 area 0
network 172.16.20.4 0.0.0.3 area 0
!
On Mugur_R4 :
interface Loopback400
ip address 40.40.40.40 255.255.255.255
!
interface GigabitEthernet0/0
description link to Mugur_R6 gi0/0
ip address 10.0.10.9 255.255.255.252
no shutdown
!
interface GigabitEthernet1/0
description link to Mugur_R2 gi1/0
ip address 10.0.10.6 255.255.255.252
no shutdown
!
router ospf 400
router-id 40.40.40.40
network 10.0.10.4 0.0.0.3 area 0
network 10.0.10.8 0.0.0.3 area 0
network 40.40.40.40 0.0.0.0 area 0
!
On Mugur_R5 :
interface Loopback500
ip address 50.50.50.50 255.255.255.255
!
interface GigabitEthernet0/0
description link to Mugur_R3 gi0/0
ip address 172.16.20.6 255.255.255.252
no shutdown
!
interface GigabitEthernet1/0
description link to Mugur_R6 gi1/0
ip address 172.16.20.9 255.255.255.252
no shutdown
!
router ospf 500
router-id 50.50.50.50
network 50.50.50.50 0.0.0.0 area 0
network 172.16.20.4 0.0.0.3 area 0
network 172.16.20.8 0.0.0.3 area 0
!
On Mugur_R6 :
interface Loopback666
ip address 66.66.66.66 255.255.255.255
!
interface GigabitEthernet0/0
description link to Mugur_R4 gi0/0
ip address 10.0.10.10 255.255.255.252
no shutdown
!
interface GigabitEthernet1/0
description link to Mugur_R5 gi1/0
ip address 172.16.20.10 255.255.255.252
no shutdown
!
interface GigabitEthernet6/0
description LAN2
ip address 192.168.200.1 255.255.255.0
no shutdown
!
ip dhcp pool LAN2
network 192.168.200.0 255.255.255.0
default-router 192.168.200.1
lease infinite
!
router ospf 666
router-id 66.66.66.66
passive-interface GigabitEthernet6/0
network 10.0.10.8 0.0.0.3 area 0
network 66.66.66.66 0.0.0.0 area 0
network 172.16.20.8 0.0.0.3 area 0
network 192.168.200.0 0.0.0.255 area 0
!
After doing all the above mentioned configurations we should have end to end reachability we can test that actually with those two PCs added to the mix , PCs which should get their IPs via DHCP and we can see which direction is preferred by each PC to reach the other one PC. The purpose of this tutorial is to force the traffic to flow via Mugur_R2>Mugur_R4 by default and only if something makes this way to be unavailable to switch traffic to flow via Mugur_R3>Mugur_R5 towards Mugur_R6.
As we can notice from this screenshot is that PC1 prefers to reach PC2 via Mugur_R2>Mugur_R4>Mugur_R6 , but PC2 prefers to reach PC1 via Mugur_R5>Mugur_R3>Mugur_R1.
In this case what can we do to mark the path via Mugur_R3>Mugur_R5 towards Mugur_R6 as a backup path that should be used only if an incident makes path Mugur_R2>Mugur_R4 unavailable?
For the sake of this exercise the answer would be simple :)
I’ve already mentioned that we’ll use one of OSPFs tricks to do that .
So what trick am I talking about then ?
We can manipulate traffic flow with OSPF by using the cost per link , if the cost is high then that respective link would be less preferred to go through.
Now let’s see how do we configure this in addition to what we already configured
On Mugur_R1:
Mugur_R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Mugur_R1(config)#int gi1/0
Mugur_R1(config-if)#ip ospf cost 5000
Mugur_R1(config-if)#^Z
Mugur_R1#
*Dec 9 15:48:31.986: %SYS-5-CONFIG_I: Configured from console by console
Mugur_R1#wr
Building configuration...
[OK]
Mugur_R1#
On Mugur_R3:
Mugur_R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Mugur_R3(config)#int gi1/0
Mugur_R3(config-if)#ip ospf cost 5000
Mugur_R3(config-if)#exit
Mugur_R3(config)#int gi0/0
Mugur_R3(config-if)#ip ospf cost 5000
Mugur_R3(config-if)#exit
Mugur_R3(config)#exit
Mugur_R3#wr
*Dec 9 15:50:08.242: %SYS-5-CONFIG_I: Configured from console by console
Mugur_R3#wr
Building configuration...
[OK]
Mugur_R3#
On Mugur_R5 :
Mugur_R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Mugur_R5(config)#int gi0/0
Mugur_R5(config-if)#ip ospf cost 5000
Mugur_R5(config-if)#exit
Mugur_R5(config)#int gi1/0
Mugur_R5(config-if)#ip ospf cost 5000
Mugur_R5(config-if)#exit
Mugur_R5(config)#exit
Mugur_R5#wr
*Dec 9 15:52:32.418: %SYS-5-CONFIG_I: Configured from console by console
Mugur_R5#wr
Building configuration...
[OK]
On Mugur_R6 :
Mugur_R6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Mugur_R6(config)#int gi1/0
Mugur_R6(config-if)#no ip ospf cost 5000
Mugur_R6(config-if)#^Z
Mugur_R6#wt
*Dec 9 15:21:22.622: %SYS-5-CONFIG_I: Configured from console by console
Mugur_R6#wr
Building configuration...
[OK]
Mugur_R6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Mugur_R6(config)#int gi1/0
Mugur_R6(config-if)#ip ospf cost 5000
Mugur_R6(config-if)#EXIT
Mugur_R6(config)#exit
Mugur_R6#wr
*Dec 9 15:54:31.266: %SYS-5-CONFIG_I: Configured from console by console
Mugur_R6#wr
Building configuration...
[OK]
Mugur_R6#
After performing the additional configuration let’s see which path are choosing those two PCs to reach each other .
What do we notice from this screenshot : that now both PCs are choosing the path via Mugur_R2>Mugur_R4 to reach each other
Now let’s do the failover test .How do we test that ?
We’ll use the ping command on both PCs , repeated for 100 packets and after starting the ping command we’ll simulate an incident by shutting down the R2s interface toward R4.
By doing so we’ll see how long it’ll take to commute traffic from one path to another path and also after doing that we’ll check using traceroute command to see if traffic is going via backup path.
What are we observing from this screenshot: that commuting from “main” path to “backup” path was so rapid that losing 2 packets out of 100 packets means that this ”incident” was not even felt by end user .
After testing the connectivity using tracert(traceroute) command we are seeing that traffic flows now via Mugur_R3>Mugur_R5 path.
Now let’s “repair” the R2s interface and notice how long it takes to commute back from “backup” path to “main” path.
We’ll proceed in same manner to test that by using ping an tracert (traceroute) commands.
When commuting back the packet loss is almost zero so again the user is not aware that something weird just happened.
As we can see from this traceroute capture now traffic flows again through designated main path.
Hope that tutorial has been useful or it’ll be useful to you.
Thanks for watching it 😊