I am working on setting up an ASA5520 to use the TRACK and SLA MONITOR function to support failover to a backup DSL link.  The route injection is showing metric of 1 for the backup link when primary service is restored, even though static route shows metric of 254. I have the configuration, it works well and routes are going to the right place during normal operations.   If I pull the plug on the primary link, all traffic switches over to go out the DSL link as expected.  The show route command shows the new default gateway is the DSL connection. When I put the primary ethernet link back in I can see the arp-cache entry for the primary ISP, and i can ping the ISP's CPE address  HOWEVER, the default-gateway route is still going out the DSL link - -  even though i can ping the primary next-hop gateway. The only (convenient and non-intrusive) recovery is to "clear route" in the firewall and then the service goes back out the (much faster) primary link. Here are some configuration snippets: interface GigabitEthernet0/0  nameif outside  security-level 0  ip address X.X.X.50 255.255.255.252 ! interface GigabitEthernet0/1  nameif inside  security-level 100  ip address 192.168.120.1 255.255.255.0 ! interface GigabitEthernet0/2  nameif DSL  security-level 0  ip address dhcp setroute route outside 0.0.0.0 0.0.0.0 x.x.x.49 1 track 1 route DSL 0.0.0.0 0.0.0.0 192.168.1.1 254 (Note the metric is 254 here) sla monitor 1  type echo protocol ipIcmpEcho 142.254.183.169 interface outside (This address is one hop beyond my ISP CPE)  num-packets 2  frequency 5 sla monitor schedule 1 life forever start-time now track 1 rtr 1 reachability route outside 0.0.0.0 0.0.0.0 x.x.x.49 1 track 1 route DSL 0.0.0.0 0.0.0.0 192.168.1.1 254 route outside 142.254.183.169 255.255.255.255 x.x.x.49 1 Here's the status of the SLA: MRW-TR# sh sla monitor operational-state Entry number: 1 Modification time: 18:41:13.932 UTC Sat Sep 17 2016 Number of Octets Used by this Entry: 1480 Number of operations attempted: 540 Number of operations skipped: 5 Current seconds left in Life: Forever Operational state of entry: Active Last time this entry was reset: Never Connection loss occurred: FALSE Timeout occurred: FALSE Over thresholds occurred: FALSE Latest RTT (milliseconds): 1 Latest operation start time: 19:26:33.936 UTC Sat Sep 17 2016 Latest operation return code: OK RTT Values: RTTAvg: 1       RTTMin: 1       RTTMax: 1 NumOfRTT: 2     RTTSum: 2       RTTSum2: 2 So this is the routing table when it is all happy: Gateway of last resort is x.x.x.49 to network 0.0.0.0 C    192.168.120.0 255.255.255.0 is directly connected, inside C    x.x.x.48 255.255.255.252 is directly connected, outside S    192.168.110.0 255.255.255.0 [1/0] via 192.168.1.1, outside                                  [1/0] via x.x.x.49, outside S    142.254.183.169 255.255.255.255 [1/0] via x.x.x.49, outside S    172.16.110.0 255.255.255.0 [1/0] via 192.168.1.1, outside                                 [1/0] via x.x.x.49, outside S    10.1.110.0 255.255.255.0 [1/0] via 192.168.1.1, outside                               [1/0] via x.x.x.49, outside S    10.10.110.0 255.255.255.0 [1/0] via 192.168.1.1, outside                                [1/0] via x.x.x.49, outside C    192.168.1.0 255.255.255.0 is directly connected, DSL S*   0.0.0.0 0.0.0.0 [1/0] via x.x.x.49, outside This is the routing table when the primary Ethernet is unplugged and then it is plugged back in (service restored) Gateway of last resort is 192.168.1.1 to network 0.0.0.0 C    192.168.120.0 255.255.255.0 is directly connected, inside C    x.x.x.48 255.255.255.252 is directly connected, outside S    192.168.110.0 255.255.255.0 [1/0] via 192.168.1.1, outside                                  [1/0] via x.x.x.49, outside S    142.254.183.169 255.255.255.255 [1/0] via x.x.x.49, outside S    172.16.110.0 255.255.255.0 [1/0] via 192.168.1.1, outside                                 [1/0] via x.x.x.49, outside S    10.1.110.0 255.255.255.0 [1/0] via 192.168.1.1, outside                               [1/0] via x.x.x.49, outside S    10.10.110.0 255.255.255.0 [1/0] via 192.168.1.1, outside                                [1/0] via x.x.x.49, outside C    192.168.1.0 255.255.255.0 is directly connected, DSL S*   0.0.0.0 0.0.0.0 [1/0] via x.x.x.49 , outside My observations In order to recover from the static route going out the wrong door, i can do a "clear route" command and everything bounces back to the primary link. Even though my static route statement has a metric of 254 on it, why does the routing table show a metric of 1 for the backup link? I can change the static route metric for the backup link to any number other than 1 in the command line, however, it will always show up as 1 in the route table. And what's up with the routing table (restored service version)? Thanks for your help! Chris ... View more

This is an odd one.   I have my lab setup where i have a 2801 communicating to a UC540.  When the 2801 was on 12.4.24T8 things worked fine.  Once i migrated to 15.1.4 things changed. The setup i have is the 2801 has an FXO port facing the PSTN.  I have a paralell hunt group that rings a phone on the 2801 and two phones across the "wan" on the UC540 simultaneously. When the 2801 was on the 12.4 image, all of this works fine.  Once migrated to 15.1 the call comes in, the hunt-group does its job and all phones ring.  HOWEVER, when you pick up the call on the UC540 side, the call comes in and it is stable and shows connected on the phone.  But once you say more than 5 seconds of anything calling into that POTS on the 2801, the call drops. the 'debug voip ccapi inout' looks ok and shows a normal call disconnect.  I do see an odd outcall from the UC540 from the extension that picks up the call to 'nowhere'. Any suggestions of where i should look? Thanks Chris ... View more

Hello there.  I ran into an interesting problem.  I have this UC520 here that I wanted to update with the 8.6.0 package.  So, I let CCA go to town and to the upgrade.  However, upon final reboot, nothing was happening.  So i got into the serial interface and the UC520 was stuck in rommon> mode.  I tried to issue the boot command and it go through and complained about a software forced crash.  in fact the actual checksum error message was as follows: rommon 31 > reset System Bootstrap, Version 12.4(11r)XW, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 2007 by cisco Systems, Inc. UC500 series platform with 262144 Kbytes of main memory Readonly ROMMON initialized program load complete, entry point: 0x80015000, size: 0xb700 program load complete, entry point: 0x80015000, size: 0xb700 program load complete, entry point: 0x80020000, size: 0x280c288 Self decompressing the image : ##################################################################################################################################################################################################################################################################################################################################################################################################################### [OK] Error : uncompressed image checksum is incorrect 0xC8778C32         Expected a checksum of 0xC8778B92 *** System received a Software forced crash *** signal= 0x17, code= 0x9, context= 0x80026434 PC = 0x0, Vector = 0x0, SP = 0x0   I then extracted the IOS image from the UC540 version of the 8.6 package, installed it using rommon tftpdnld and booted with that.  I get the same error. I then extracted the IOS image from the 8.2 package and installed on a flash and that boots fine. If anyone has suggestions or has seen this error before and has a workaround, i would love to hear about your experiences. BTW - I have successfully installed that 8.6 image on several UC540's - just not UC520 boxes. Chris ... View more