We will migrate from static to OSPF and add secondary site with same IP. How could I configure when the server in primary site down it swap to secondary site? Or still use static is easier?
Thank you very much.
Using static routing is much easier and probably much safer as you control by configuration when to start your disaster scenario.
If you want to automate that, you could announce the network from the secondary site with high cost and do a conditional announcement on the primary site while the server is reachable. And also ask your application team if that is really a good idea to automate that.
@Karsten Iwen wrote:
do a conditional announcement on the primary site while the server is reachable.
Could you please share how to do?
Thank you very much.
I have no working example and it would also be highly dependent on the rest of your network.
Two ways to achieve that come to my mind:
If that all sounds too weird, stick with static routing as it's much less complex.
So to confirm you are introducing a 2nd site with a server that will have the same ip address as a server that resides in site 1?
How do users connect to this server, what does this server provide?
If I am understanding the drawing correctly site CE3 has 172.16.0.0/16. site CE1 has 172.16.22.200 mask not specified. And site CE2 also has 172.16.22.200 mask not specified. Can we get clarification about how the devices at CE1 and CE2 are connected and what mask they use? Also can we get verification that the address block used at CE1 and CE2 is not in use at CE3? And while we are at it can we get clarification about what other address blocks are used at CE1 and CE2?
It seems to me that one potential solution might be implemented like this:
1) on CE3 configure OSPF to advertise 172.16.0.0/16 as an internal route.
2) on CE1 make sure that there is not a network statement for the subnet containing 172.16.22.200.
3) on CE1 configure a static route perhaps for the host specific 172.16.22.200 or perhaps for the local subnet containing that address.
4) on CE1 configure IP SLA to monitor reachability of 172.16.22.200 and to withdraw the static route if the server is not reachable.
5) on CE1 configure OSPF to redistribute static, specifying that the redistributed route will be E2 and specifying a metric to be used in the redistribution. If there is more than one static route configured on CE1 then the redistribution logic will need to be adjusted to treat the server address differently than the other static routes. (or perhaps it is fine to have all these static routes as E2 with that metric)
6) Now we have a situation where CE3 is advertising the complete subnet of 172.16.0.0/16 and CE1 is advertising a more specific route for 172.16.22.200. Since more specific routes are preferred any traffic for 172.16.22.200 will be forwarded to CE1 while other traffic for 172.16.0.0 is sent to CE3. And if the server becomes not available the route is withdrawn.
7) on CE2 make sure that there is not a network statement for the subnet containing 172.16.22.200.
8) on CE2 configure a static route perhaps for the host specific 172.16.22.200 or perhaps for the local subnet containing that address.
9) on CE2 configure IP SLA to monitor reachability of 172.16.22.200 and to withdraw the static route if the server is not reachable.
10) on CE2 configure OSPF to redistribute static, specifying that the redistributed route will be E2 and specifying a metric to be used in the redistribution which is noticeably higher than the metric specified on CE1. If there is more than one static route configured on CE2 then the redistribution logic will need to be adjusted to treat the server address differently than the other static routes. (or perhaps it is fine to have all these static routes as E2 with that metric)
11) Now we have a situation where CE3 is advertising the complete subnet of 172.16.0.0/16, CE1 is advertising a more specific route for 172.16.22.200, and CE2 is advertising a similar E2 route with a higher metric. Since more specific routes are preferred and E2 with lower metric is preferred over E2 with higher metric, any traffic for 172.16.22.200 will be forwarded to CE1 if it is available and otherwise will be forwarded to CE2 while other traffic for 172.16.0.0 is sent to CE3. And if the server becomes not available the route is withdrawn.
This is current configuration:
track 1 ip sla 11 reachability
delay down 10 up 1
ip route 172.16.22.128 255.255.255.128 FastEthernet0/1.22 track 1
ip sla 11
icmp-echo 172.16.22.200 source-ip 172.16.22.254
ip sla schedule 11 life forever start-time now
ip address 10.10.10.3 255.255.255.248
ip access-group Block_echo_22.254 in
ip access-list extended Block_echo_22.254
deny icmp host 172.16.22.254 host 172.16.22.200 echo
permit ip any any
I found the 2 issues:
Should we block the ICMP Echo like the CE2 configuration above to prevent IP SLA reachability from CE1 when server under CE1 down?
Thank you very much.
The most recent post says here is the configuration, but there is no configuration information.
For the 2 issues:
1) I think that you should block the ICMP like CE2.
2) I do not understand the question. My suggestions included a static route on CE1 more specific than the connected /24. Have you done that? Are you saying that does not work?
It really would help if we had some specifics of the configurations.
@Richard Burts wrote:
When the 22.200 under the CE1 come back, it can't ping to the gateway.
This is the routing table on CE1:
I tried to 'clear ip ospf process' on CE2, the 22.200 under the CE1 can ping to the gateway. How should I do?
Thank you very much.
Am I correct in understanding that the ping that you posted was generated on 172.16.22.200? In that case the error message from 172.16.22.200 destination host unreachable is especially interesting.
It looks like CE2 has a static route for 172.16.22.128/25 that is being redistributed into OSPF. Is that correct? Is there a similar static route on CE1?
My suggestion was to have equivalent static routes on CE1 and CE2 and to redistribute these routes into OSPF as E2 routes and specifying a metric on CE2 that is higher than the metric used on CE1. If that is done correctly then when CE1 is up it should be used, if CE1 is not up then CE2 should be used, and when CE1 becomes available again then it should be used.
My suggestion mentions perhaps using a host specific static route or perhaps a static route for the local subnet. You have implemented the static route for /25 which is not quite either and that seems perhaps to have created a problem. Perhaps you might change the static route and try the host specific static route and see if it works better.
Am I correct in understanding that CE1, and CE2, and CE3 all have 172.16.22.0 as a local network? That creates a bit of a challenge. If that is the case then it is a good reason to use the host specific static route.