Hi again Kuldeep!
First of all - I would like to know what is behind Switches. I will assume that there are host machines, because if there were some other Routers, things will become more complex.
Moreover, it is pity that we can't use routing protocols here, it would ease the configuration like a lot .
Figure A:
I hate to say it but Figure A is a typical HSRP/GLBP scenario - I will tell you why and then leave it, because you suggested we should not use HSRP in this thread.
You have common IP LAN subnet. Therefore all host machines that are attached to the Switch have to have default gateway configured. But what if one of the gateways become unavaible? Or the link to ISP becomes unavaible? There is no other way to fight this problem than FHRP protocols.
Let's think of following scenario: Router 1 will work, but his link towards ISP1 goes down. Router 1 will still be default gateway for hosts, but can't forward traffic to the internet. So it could have floating static route defined to Router2 and IF Router2 have its connection to ISP2 up - it will forward the traffic instead Router1. But as you see - FHRP would solve the problem better. Now the traffic still have to be sent to Router 1 and then back through LAN to Router 2 to be forwarded to ISP.
So => 1. Floating static route - Could be, but:
But think of this scenario with ONLY floating static routes defined. Router1 has FSR to Router2 and Router2 to Router1 in case of failure of link towards ISPs. But what if both links on R1-ISP1 and R2-ISP2 go down? The traffic will loop between Router1 and Router2 until TTL expires. This is because Router1 is trying to forward all traffic to Router2 because of the static route - Router2 is doing precisely the same. This is a rare scenario - but can occur.
2. IP SLA - Yes, you could improve Floating static route combining it with IP SLA. You will configure floating static route on Router 1 towards Router 2, but Router 1 will monitor Router's2 link towards ISP. Then the floating static route will come up only if the IP SLA test is passed. In such case you will prevent loops in case that both the links to ISPs goes down.
Very brief example (can have some mistakes ):
R1(config)# ip sla 11
R1(config-ip-sla)# icmp-echo 125.36.56.45
R1(config-ip-sla-echo)# frequency 10
R1(config-ip-sla-echo)# exit ! 2x
R1(config)# track 1 ip sla 11 reachability
R1(config-track)# delay down 10 up 1
R1(config-track)# exit
R1(config)# ip sla schedule 11 life forever start-time now
R1(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.3 253 track 1
And I would do similar configuration on Router2.
Explanation:
The first step in this configuration defines the probe.
Probe 11 is defined by the ip sla 11 command.
The test defined with the icmp-echo 125.36.56.45 command specifies that the ICMP echoes are sent to destination 125.36.56.45 to check connectivity.
The frequency 10 command schedules the connectivity test to repeat every 10 seconds.
The ip sla schedule 11 life forever start-time now command defines the start and end time of the connectivity test for probe 11; the start time is now and it will continue forever.
The second step defines the tracking object, which is linked to the probe from the first step.
The track 1 ip sla 11 reachability command specifies that object 1 is tracked; it is linked to probe 11 (defined in the first step) so that the reachability of the 125.36.56.45 is tracked.
The last step defines an action based on the status of the tracking object.
The ip route 0.0.0.0 0.0.0.0 192.168.1.3 254 track 1 command conditionally configures the default route, via 10.1.1.1, with an administrative distance of 2, if the result of tracking object 1 is true.
Thus, if 125.36.56.45 is reachable, a static default route via 192.168.1.3with an administrative distance of 253, is installed in the routing table.
Figure B:
Ok I'm not sure if this Switch is also L3 enabled, or just L3 capable and it is behaving like L2 switch.
If its behaviour is L2 - same as Figure A
If its behaviour is L3 and it is doing routing - you could configure IP SLA + Floating static routes in similar manner like in Fig A.
Switch should have two floating static routes and two IP SLA probes defined.
Figure B:
1. Floating static route - NOt alone
2. IP SLA - Yes, with floating static route
Example:
Switch(config)# ip sla 11
Switch(config-ip-sla)# icmp-echo 78.22.33.3
Switch(config-ip-sla-echo)# frequency 10
Switch(config-ip-sla-echo)# exit ! 2x
Switch(config)# ip sla 22
Switch(config-ip-sla)# icmp-echo 125.36.56.45
Switch(config-ip-sla-echo)# frequency 10
Switch(config-ip-sla-echo)# exit ! 2x
Switch(config)# track 1 ip sla 11 reachability
Switch(config-track)# delay down 10 up 1
Switch(config-track)# exit
Switch(config)# track 2 ip sla 22 reachability
Switch(config-track)# delay down 10 up 1
Switch(config-track)# exit
Switch(config)# ip sla schedule 11 life forever start-time now
Switch(config)# ip sla schedule 22 life forever start-time now
Switch(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.2 2 track 1
Switch(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.3 3 track 2
Figure C:
This one is a little bit tricky. Because you said that there are more different LAN networks. So there must be some VLANs. If connection between Routers and Switch is defined as trunk, you could have Inter VLAN routing going on, known as Router-On-A-Stick. If this is the case - it would be similar to Figure A.
If you don't have Inter VLAN routing in this scenario I can't think of any possible solution here. That's simply because Router1 would not be able to send anything to Router2 (if they were in different VLANs).
Figure D:
Similar to Figure B.
There could be some errors in the example configuration, if so - please feel free to correct me. Please don't take that as 100% accurate, ready to use in live network . Hope that helps.
Best regards,
Jan
