Valid range is 30-15300 seconds in multiples of 30 secondsįrom 10.x we got better way of handling failover as that would be hitless with cluster being built and configured on headend VPNC side.
User-idle-timeout User idle timeout value. –failover-internet-check-timeout=4 à This is ICMP packet timeout, default is 10 seconds –Make sure preemption enabled on fail over. –failover-internet-check-timeout=300 à This is ICMP packet timeout, default is 10 seconds Valid range is 30-15300 seconds in multiples of 30 seconds * (VPN Authentication Profile "default-iap") # * (config) #aaa authentication vpn default-iap User-idle-timeout” in “default-iap” VPN authentication profile.
TUNNEL CORE VPN UPDATE
– VPNC2 should be advertising routes for the IAP during this time but the upstream routers may not update their route table until VPNC1 stops advertising the routes –IAP is setting up tunnel to VPNC2 around 20-30 seconds after VRRP failover and registering with it but may taking 5 minutes for VPNC1 to remove the routes and stop advertising the routes upstream. – VPNC1 is disconnected from WAN link (still connected to core switch) and VRRP failover happens to VPNC2. After this timeout, tunnel is removed from ipsec crypto table, auth notifies IAP manager and IAP manager removes the datapath routes. –On the Gateway, default timeout for IPsec tunnel down for IAP tunnel is 5 min. Root cause for example in this case of VRRP Tips & Tricks for IAP failover best practices config tweaks
IAP forms IPSec tunnel to the VPNC again, registers the branch and then the OSPF/BGP route advertisements will point to the new tunnel. failover-internet-pkt-send-freq 30 à ICMP packets are sent once every 30 seconds. failover-internet-pkt-lost-cnt 10 à This is the number of ICMP packets that are allowed to be lost to determine if AP must switch to a different uplink connection. So the primary uplink tunnel shows as up on VPNC for about 5 minutes after the primary uplink went down - since IAP is the tunnel initiator, VPNC does not monitor the tunnel status and continues to send route advertisements during this period. This illustrates 30x10 = 300 seconds for the IAP to detect the primary uplink is down and initiate switch to backup uplink. IAP-VPN tunnel stays up on the primary VPNC (as well as the new tunnel on the backup) for 5 or 6 minutes – and while it is up still on the primary, the VPNC continues to advertise a route to the 元 networks – these routes may not work, and we would expect an outage for 5-6 minutes. This key can be a passphrase or pre-shared key (PSK) known by both. But, the IAP-VPN tunnel stays up on the primary (as well as the new tunnel on the backup) VPNC for 5 or 6 minutes – and while it is up still on the primary, the VPNC continues to advertise a route to the 元 networks – these routes don’t work and we see an outage for 5-6 minutes. When a Mobile VPN tunnel is created, the identity of each endpoint must be verified. When failing the primary broadband, the SD-Branch tunnels go down and come up on the backup and the routing mostly works, pretty quickly. Failover outages and pitfalls on IAP VPN deployments
0 kommentar(er)
