Configuring a 1921 router with T1 interface and 4G eHWIC LTE V as failover.
Anyone have an idea of how to configure a 1921 router with a serial T1 interface and eHWIC 4G LTE V as a failover? Below is a portion of the current config with just the serial T1 interface set up. I have read through the documentation for Cisco but they only mention a failover for a DSL line. I'm not sure if I can use the same idea for a T1 interface or any other type of interface other than DSL.
! ! ! ! interface GigabitEthernet0/0 ip address A.x.x.241 255.255.255.248 no ip redirects no ip unreachables no ip proxy-arp duplex auto speed auto ! interface GigabitEthernet0/1 no ip address no ip redirects no ip unreachables no ip proxy-arp ! interface Serial0/0/0 ip address A.x.x.42 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp encapsulation ppp no fair-queue no cdp enable ! ip forward-protocol nd ! no ip http server no ip http secure-server ! ip route 0.0.0.0 0.0.0.0 A.x.x.41
There are several approaches which could work to achieve failover. I think that the most simple one would be to configure a floating static default route pointing to the 4G next hop (a floating static is a static route which includes an administrative distance and might look something like 0.0.0.0 0.0.0.0 B.B.B.B 250).
As Rick mentioned you can use a floating route. One issue you would need to watch out for is if the carrier (ISP) had a logical outage that did not bring the T1 interface to a DOWN state. If that happens the higher metric route would not kick in.
Below is an outline of a dynamic fail-over fail-back for the default route config using boolean and SLA tracking. Basically the three SLA's will ping a tracking object every 10sec, if the tracked object does not respond that SLA will go to a down state. The reason for having three and using boolean is for redundancy. If SLA 100, 22.214.171.124 (a DNS server), goes down but SLA 200 (Google) and SLA 300 OpenDNS are still up then do nothing because the link is still up and the issue may be with that one tracked object. If all three SLA's go to a down state, TRACK 500 considers the link to be logically unavailable and your floating route then is injected. Once the tracked object/s come one-line again the default route will fail back to your main default route. This design will cover physical and logical outages on the ISP side.
Note: It is important to have your static routes in place for the SLA/s, if you do not the SLA/Tracking mechanism will not function correctly since once the fail-over happens the SLA's would go to an UP state and want to fail back bla bla bla
Note2: Once your core is in place you could layer on WAN ACL's, Inspection et certera. Of course you can modify this example in may ways i.e. more/less SLAs, different tracking objects, using DNS verses ICMP but generally the below has worked well for me in many designs.
ip sla 200 icmp-echo 126.96.36.199 source-interface <LAN INTERFACE> tag PerfMon/TRACKING 188.8.131.52 threshold 1500 timeout 1500 frequency 10 ip sla schedule 200 life forever start-time now
ip sla 300 icmp-echo 184.108.40.206 source-interface <LAN INTERFACE> tag TRACKING 220.127.116.11 threshold 1500 timeout 1500 frequency 10 ip sla schedule 300 life forever start-time now
ip sla 400 icmp-echo 18.104.22.168 source-interface <LAN INTERFACE> tag TRACKING 22.214.171.124 threshold 1500 timeout 1500 frequency 10 ip sla schedule 400 life forever start-time now
track 200 ip sla 200 delay down 60 up 60 ! track 300 ip sla 300 delay down 60 up 60 ! track 400 ip sla 400 delay down 60 up 60 ! track 500 list boolean or object 200 object 300 object 400
ip route 0.0.0.0 0.0.0.0 <primary T1 gateway> track 500 ip route 0.0.0.0 0.0.0.0 <4G LTE Gateway/interface> 250 ip route 126.96.36.199 255.255.255.255 <primary T1 gateway> permanent ip route 188.8.131.52 255.255.255.255 <primary T1 gateway> permanent ip route 184.108.40.206 255.255.255.255 <primary T1 gateway> permanent
show track xxx is good to check the status of the tracking/sla
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...