top of page
paulcapatana

Building a Resilient Network Infrastructure OSPF- Based Redundancy Design

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 😊

12 views0 comments

Comentários


Post: Blog2_Post
bottom of page