As per attached diagram, I have configured 'reliable static routing' to route between two different ISP'S and internet connections. This gives the user some resillience when connecting to a remote server (AS400).
The problem I have is when a user has a session open on the remote server (AS400) using telnet or IBMS client software, the sessions drop during a failover to the secondary link and they have to re-connect.
Reliable Static Routing is configured on both routers in the diagram which track (poll) each others f0 interfaces. If the routers cannot see each other, they instantly point their default-gateways at the secondary firewall each end.
Failover appears to take 3-4 seconds and tunnels on both primary and secondary firewalls are contstantly active.
Im trying to find out why the user sessions are dropping during failover and what config I could possibly put in place on each cisco router to help prevent sessions dropping.
One of my routers configs .
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
enable secret xxx
enable password xxx
no aaa new-model
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no ip domain lookup
ip sla monitor 1
type echo protocol ipIcmpEcho 192.168.43.2 source-ipaddr 192.168.99.66
ip sla monitor schedule 1 life forever start-time now
Although I find your config very nice, I think that you cannot expect that both sides will make the switch-over at exactly the same time. This will result in unrecoverable packet loss or out of sequence packets. Both of these are likely to cause the problems as described.
When I configure a similar solution I always use GRE tunneling (with IPsec if needed) and a routing protocol to detect link failures. Cisco calls this "DMVPN" nowadays. ;-) I suggest that you should look in that direction also.
The GRE is just a different solution for tunneling. I use it because it allows multicast traffic. (EIGRP/OSPF hello)
Preserving Internet connectivity is more about IP routing. If you are reaching the Internet via a proxy that is reachable over the tunnel this will work the same as the current solution. If you are breaking out locally on a router, users may lose connections due to the change-over of their nat-ip adress.
The problem you are facing is a perennial problem in the Internet. TCP sessions are bound to the end-point IP addresses and if these change, as is the case with your NAT'ed addresses, the session will drop.
There is currently some work going on in the IETF Shim6 group to get around this problem but I'm afraid that is only for IPv6. So you are stuck with this problem - there isn't much you can do to get around this issue.
Reliable static routing gives you the ability to switch links dynamically and that is all it does - the alternative is to have to do it manually.
The continued internet access is not that important. What is important is users losing their sessions to the remote server accross the vpn when failing over. In this scenairio there is no natting. I guess telnet and client products using telnet are very sensitive.
Not being a 'routing protocol genius' which would you recomend for my scenairio igrp/eigrp/ospf, based on the following requirements.
1. provide connectivity to remote server using both primary and secondary (for backup)
2. provide internet connectivity through either link. (there is no proxy server)
It is important to use a routing protocol that has a short convergence time. EIGRP and OSPF can both deliver this. I would suggest using EIGRP as it is easier to configure.
Providing redundant Internet connectivity is a long standing challenge while it is typically delivered via static routing which is not ideal when there is no connectivity but the interface is not physically down.
I hope that you can sucessfully deliver your server connectivity using this solution, for the second part of your question you should probably look for the most suitable compromise.
maybe a combination of both reliable static routing and eigrp might work.
'reliable static routing' tracking a public address which if fails to respond, replaces the default-gateway to the secondary link. Doesn't matter whether physical interface is up or down in this scenairio, works great !
'eigrp' could be used to monitor only static routes to the remote server
I will have to look into eigrp. Can it be configured to exchange information with a specific remote router, which I assume would also have to be running eigrp.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...