I have a single 3945 which has 2 x Fibre providers terminating onto it (say Gi0/1 and Gi0/2). There are multiple VLAN's and subnets on the router, one of which is solely dedicated to Gi0/2. Gi0/2 lives in a VRF with its own DHCP/NAT/Crypto maps (and a single VLAN dot1q sub interface). Both providers are statically routed to via a default route, and there is no option for BGP here nor any other dynamic routing protocol (they are totally different ISP's).    They were put on the same device after being migrated from two individual routers, and at the request of the client, they wanted one to be ISP to be totally segregated for their own discrete/private use (Gi0/2).   They've now requested they'd like either link to failover to the other, in the event of an outage. They're not fussed if their VPN fails, so long as internet connectivity is maintained in some form.   Is there an easy way to failover from a Gi0/1 in no VRF to Gi0/2 in a VRF (or vice versa)? I could potentially place Gi0/1 into another VRF if required, but it seems excessive.    After advice on the best way to do this, and any possible configuration suggestions/examples.    Thanks! ... View more

I've been doing some research on trying to get a pair of ASR1001-X's into an Active/Standby type configuration.   There's various reports around of using application groups for SSO from one to another, but it looks like mLACP is the ideal solution.   At present, I have a single 1K with a port channel to a pair of stacked Cisco switches which works just fine. I was hoping to introduce the second 1K in a similar configuration and put them into a redundant mode with mLACP, but the Cisco configuration guides are referencing commands that are not available under 'redundancy' on the 1K's I have. Both are running 16.6.4.   asr1k-1((config)#redundancy asr1k-1((config-red)#interchassis ? % Unrecognized command asr1k-1(config-red)#? Redundancy configuration commands: application Enter application redundancy group mode default Set a command to its defaults exit Exit from redundancy configuration mode main-cpu Enter main-cpu mode mode redundancy mode for this chassis no Negate a command or set its defaults policy redundancy policy enforcement timer Select a timer to configure The documents i've looked at suggest 16.6.4 should be fine, but am I missing something glaringly obvious?   Happy to entertain another way of doing this too. VRRP/HSRP is not an option, owing to some /31's I have in use on the current 1k with Port-Channel that cannot be changed.  ... View more

Unusual one that's just recently surfaced.    We are using a certain SIP provider for outbound calls, which up until recently appears to have been working fine.   We have two gateways, which sit directly behind our border routers to the internet. They're 3825's with CUBE on them, both running a variant of 15.1. They are used exclusively for this one provider.    Both have simple unauthenticated SIP Trunks, with ACL restrictions.    We can initiate a call, and it works fine. If the called party hangs up first, under 7 minutes, we receive the BYE from the remote party.    When the call exceeds 7 minutes (approximately, not a hard number, just somewhere over 7-9 minutes), we do not see the BYE back. The SIP trunk provider has given us pcap's of the call, and they are sending the BYE repeatedly when the called party terminates. At 9 minutes plus it's happening 100% of the time.   There is not NAT at play, and the remote SIP provider is connecting to the binds on each gateay (via a loopback). These two gateways have a near identical configuration to every other gateway in our network on other providers, all of which are working fine. The provider with the problem says it's not their problem, and the fact that it seems to be only longer calls with the issue would suggest it could be a Cisco problem, but i'm not so sure.    Anyone seen anything like this? We do see the following in the logs, but it's not a very helpful error (and happens frequently in other places)   Aug 13 22:03:31: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: Aug 13 22:03:31: //-1/xxxxxxxxxxxx/SIP/Error/HandleUdpIPv4SocketReads: SIP Message incomplete, trashed Aug 13 22:03:31: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: Aug 13 22:03:31: //-1/xxxxxxxxxxxx/SIP/Error/HandleUdpIPv4SocketReads: SIP Message incomplete, trashedterm no mon I don't think these messages are related, but included them as it's all that the debugs are showing.    Any help/suggestions appreciated.  ... View more

Curly one for the experts around here:) I decided recently to switch out our border router (1841 12.4 advsecurity) with a shiny new 1941 (15.2 SEC/K9) as the CPU upgrade was needed. In doing so, I seem to have introduced some strange issues. The core below acts as a VPN end point to various other remote offices we have, all of which have a similar network design at each end (and all entirely managed by me). All of these are still running 1841's with 12.4 advsecurity on them as well. These are all GRE tunnels with ipsec procection on them (not crypto maps). Before the change out, the network looked like this: ---x------#---------X bdr       fw         core where: bdr is a 1841 with advsecurity 12.4 on it fw is a linux fw with iptables core is an 1841 with advsecurity 12.4 on it. If I swap out the bdr with a 1941 running SEC/K9 on 15.1 (or 15.2)T, I see issues. The IPSEC establishment from the core to the remote site starts, and I see the phase I packet on the remote. The remote sees it, and replies, but the bdr is either not seeing it, or is dropping it entirely. I've gone through caveats and all, and not seen anything in 15.1/2 that may cause this (and trying to search for anything anywhere is near impossible. FWIW, there are statics everywhere to ensure that the path from internet to core and vice versa, take this exact path (so there's symmetric routing). If I change nothing and put the 1841 back in, I see things come straight back. The GRE tunnels are using RFC1918 /30's for the tunnels themselves, but public IP for the end points obviously, via a loopback for each tunnel on the core. On the bdr, there's a static route for the public IP towards the core, via the fw (and the fw has a static to an RFC1918 on the core). The public IP is a loopback on the core (so say Loopback10 on core is 144.12.13.14 which is routed to the bdr via a /29, and then the bdr has a static for 144.12.13.14 to 192.168.0.1 on the fw, and the fw has a static for 144.12.13.14 to 192.168.0.5 on the core, where the loopback is). This is how all my tunnels are setup, and they all worked, until the swap-out. Here's the relevent parts of the 1941 config: version 15.2 service nagle no service pad service tcp-keepalives-in service tcp-keepalives-out service timestamps debug datetime msec show-timezone service timestamps log datetime msec show-timezone service password-encryption no service dhcp ! hostname routername ! boot-start-marker boot system flash:c1900-universalk9-mz.SPA.152-3.T1.bin boot-end-marker ! logging buffered 16000 logging console critical enable secret <removed> !         ipv6 spd queue min-threshold 62 ipv6 spd queue max-threshold 63 no ipv6 cef no ip source-route ip auth-proxy max-login-attempts 5 ip admission max-login-attempts 5 !         no ip bootp server ip inspect log drop-pkt ip inspect one-minute low 2000 ip inspect one-minute high 2500 ip inspect tcp idle-time 7500 ip inspect name STATEFUL h323 ip inspect name STATEFUL realaudio ip inspect name STATEFUL rtsp ip inspect name STATEFUL icmp ip inspect name STATEFUL sip ip inspect name STATEFUL udp ip inspect name STATEFUL tcp ip ips notify SDEE ip ips name IDS-WATCH ip cef ip cef accounting per-prefix non-recursive prefix-length ! multilink bundle-name authenticated parameter-map type inspect global log dropped-packets enable ! vpdn enable ! license udi pid CISCO1941/K9 sn <removed> license boot module c1900 technology-package securityk9 ! archive log config   hidekeys ! redundancy ! ip tcp selective-ack ip ssh time-out 60 ip ssh authentication-retries 2 ! class-map match-any torrent ! policy-map no-torrent class torrent   drop ! interface Loopback0 ip address ip.address.goes.here/32 no ip proxy-arp ! interface Null0 no ip unreachables ! interface Embedded-Service-Engine0/0 no ip address shutdown ! interface GigabitEthernet0/0 description stuff ip address ip.address.goes.here/26 ip access-group stuff-in in no ip redirects no ip proxy-arp ip nbar protocol-discovery ip nat inside no ip virtual-reassembly in standby 1 HSRP.ip.here.blah standby 1 priority 105 standby 1 preempt standby 1 authentication keyhere ip tcp adjust-mss 1452 ip policy route-map stuff-route-map load-interval 30 duplex auto speed auto no cdp enable service-policy input no-torrent service-policy output no-torrent ! interface GigabitEthernet0/1 no ip address shutdown duplex auto speed auto ! interface ATM0/0/0 no ip address load-interval 30 no atm ilmi-keepalive snmp ifindex persist hold-queue 224 in interface ATM0/0/0.835 point-to-point pvc 8/35   encapsulation aal5snap   pppoe-client dial-pool-number 1 ! interface Dialer1 mtu 1452 ip address negotiated ip access-group Internet-in in ip access-group Internet-out out no ip unreachables ip accounting output-packets ip accounting access-violations ip nbar protocol-discovery ip flow ingress ip nat outside ip inspect STATEFUL out ip virtual-reassembly in encapsulation ppp ip policy route-map nachi-worm load-interval 30 dialer pool 1 ppp authentication pap callin ppp chap refuse <auth string here> ppp ipcp route default no cdp enable service-policy input no-torrent service-policy output no-torrent ! ip forward-protocol nd ! no cdp run ! end (this is copied and pasted directly from the 1841, with the exception of the 15.2 line obviously, and all lines were applied without error). Everything else works fine (NAT, route-maps etc), it's just these IPSEC/isakmp tunnels that are not playing ball. Anyone seen anything like this before? It's definitely not an ARP issue (all arps were cleared) and ICMP appears to work fine (ie, I can ping the remote tunnel's public IP endpoint from the core using the loopback for that tunnel as the source). I am suspecting it's something strange with the stateful firewall config, but I did try and apply ipsec and isakmp-msft to the ip inspect list, with no success. ... View more