I just caught a router in this state with the 3G interface not responding. The cellular interface is UP and an IP address is still bound to dialer2 yet it wont pass any traffic. If I shut, then no shut the cellular interface it will then function correctly again. Any thoughts, anyone seen this before with an 887?  Perhaps the telco (Telstra) is timing out the connection?  I also have an IP SLA probe running over the link to ensure there is always traffic, but this doesnt help.  I have the same config and issue at several sites. My workarounfdis an EEM script to shut / no shut the interface when the IP SLA probe fails.  But I would like to find the root cause of this. surfers-887#sh cellular 0 connection Data Transmitted = 1093613685 bytes, Received = 609039408 bytes Profile 1, Packet Session Status = ACTIVE     IP address = 192.168.210.7     Negotiated QOS Parameters:     Precedence = Normal Priority, Delay = Class 2     Reliability = Unack GTP, LLC, Ack RLC, Protected data     Peak = 256 kB/sec, Mean = 50000 kB/hr     Traffic Class = Interactive     Uplink Max = Unknown, Guaranteed = 1.8Mbps     Downlink Max = Unknown, Guaranteed = 1.8Mbps     Max SDU size = 1500 bytes     SDU error ratio = 1E-4, BER = 1E-5 surfers-887#sh cellular 0 radio Radio power mode = ON Current Band = WCDMA 850, Channel Number = 4436 Current RSSI = -108 dBm Band Selected = Auto Number of nearby cells = 2 Cell 1     Primary Scrambling Code = 0x94     RSCP = -107 dBm, ECIO = -13 dBm Cell 2     Primary Scrambling Code = 0x9C     RSCP = -111 dBm, ECIO = -14 dBm surfers-887#sh int cellular 0 Cellular0 is up, line protocol is up   Hardware is 3G Modem-HSPA/UMTS/EDGE/GPRS-850/900/1800/1900/2100MHz / Global   Description: Telstra 3G to Private WAN   MTU 1500 bytes, BW 5760 Kbit/sec, DLY 20000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation PPP, LCP Open   Open: IPCP, loopback not set   Keepalive not supported   Interface is bound to Di2 (Encapsulation PPP)   Last input 00:00:00, output 02:57:19, output hang never   Last clearing of "show interface" counters never   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 9582   Queueing strategy: fifo   Output queue: 10/10 (size/max)   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      7530981 packets input, 616597453 bytes, 0 no buffer      Received 0 broadcasts (0 IP multicasts)      0 runts, 0 giants, 0 throttles      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      2656764 packets output, 1096274832 bytes, 0 underruns      0 output errors, 0 collisions, 17 interface resets      0 unknown protocol drops      0 output buffer failures, 0 output buffers swapped out      0 carrier transitions      DCD=up  DSR=up  DTR=up  RTS=up  CTS=up ... View more

I have just encountered a similar situation.  It seems to work near enough, but I still consider it a hack.   Also if the second peer (887 router in this case) attempts to bring up the IPSec tunnel the ASA drops the the primary tunnel and restablishes it causing brief packet loss during the tunnel bounce.  A debug shows an error that it thinks the peer IP has changed, hence the tunnel should be dropped!!! Im just using HRSP on the access site between 2 x 887's tracking the WAN interface.  On the ASA side I have both peers defined in the same way "crypto map cccccc 10 set peer 2.2.2.2 1.3.3.3". The ASA feature set just hasnt improved in this space since the VPN3000 days, it may have actually gone backwards. Introduction of VTI interfaces and support for routing protocols over tunnels should have been introduced into the ASA years ago, but from what I understand has been put in the too hard basket. Cheers Kent. ... View more

Yes that does sound viable Peter.  I'll sleep on it and discuss with the team.  Thanks for the advice. I also read that not using area 0 for the PE-CE links changes things but its not clear if this will help at all as all the CPE will still be in the same area.  I would expect the same behavior as we see now.  See http://sites.google.com/site/amitsciscozone/home/important-tips/mpls-wiki/ospf-as-pe-ce-routing-protocol-in-mpls-vpn " PEs and OSPF Area 0 The PE/CE link can belong to  any area including area 0 for an OSPF domain. If the PE attaches to the  CE using a non-zero area, then the PE router acts as an ABR for that  area. The MPLS VPN backbone acts as a Super Backbone If  the OSPF domain has area 0 routers other than PE routers, then one of  those must be CE router and must have an area 0 link to atleast one PE  router using virtual-link to the PE router. This is necessary because  Area 0 should be contiguous and so that inter-area and external routes  can be leaked between PE routers and the non-PE OSPF backbone. " ... View more

Hi Peter, Hopefully the attached helps a little. The classic sham link scenario does not really apply here.  Both routers are in each case at the same site and are directly connected to each other and the local site /24 subnet.  Its a active / backup setup.  Where is all cases the PPP ADSL service is the backup only. All is working as expected now with the additions of the distribute-lists.  Its just very config intensive and bound to break as things change.  There must be a better way (dont use OSPF). Cheers Kent. ... View more

Ive implemented what I consider to be a workaround, but it does now work as expected.  I had to filter the updates received by the PE from the primary CPE at each site to only accept the LAN range from that site, not the LAN range from other sites that it was learning via the backup CPE, via PE, via other site backup router.  I think I was barking up the wrong tree re the downward bit.  This issue is because there is indirect OSPF connectivity between all the CPE's connected to the same PE. Basically the PE needs to never pass on LSA's learnt from one CPE to another CPE then we would be all ok. I still have an issue to solve for PPP xDSL services as they all share the one loopback as an ip unnumbered interface on the PE.  The same distribute list approach wont work there. Here is what I have done.  There must be a less config intense and flexible approach to this.  router ospf 116 vrf RED distribute-list prefix RED-acacia-ospf-subnets-inbound in GigabitEthernet1/0/1.3681 distribute-list prefix RED-acacia-ospf-subnets-inbound in GigabitEthernet1/0/1.3682 distribute-list prefix RED-geebung-ospf-subnets-inbound in GigabitEthernet1/0/1.3684 distribute-list prefix RED-kawana-ospf-subnets-inbound in GigabitEthernet1/0/1.3685 distribute-list prefix RED-goldcoast-ospf-subnets-inbound in GigabitEthernet1/0/1.3686 ip prefix-list RED-geebung-ospf-subnets-inbound permit 192.168.103.0/24 ip prefix-list RED-acacia-ospf-subnets-inbound permit 192.168.100.0/24 ip prefix-list RED-acacia-ospf-subnets-inbound permit 0.0.0.0/32 ip prefix-list RED-kawana-ospf-subnets-inbound permit 192.168.104.0/24 ip prefix-list RED-goldcoast-ospf-subnets-inbound permit 192.168.101.0/24 ... View more

Hi Peter, OSPF RID 10.200.4.229 is the WAN Interface of a PPP ADSL service at the access site in question.  It is the DR for the local LAN subnet 192.168.104.0/24.  This device should be originating this route. OSPF router 10.200.212.116 is a loopback and the router RID of the PE / LNS whrere the above PPP ADSL service terminates.  Not the 7609 in the original outputs I provided.  It looks like the downward bit is being set correctly here, however the route is also being learnt direct from other CPE's (via ospf on the PE) and not the actual redistributed route. ie all access sites are using area 0 and can all see each others LSA's via OSPF running on the PEs.  I think this is the issue. What I would really like is a good doc that shows best practice use of OSPF as the CE - PE routing protocol where you have dual attached access sites - in our case each service terminates on a different PE and is a different type of link, typically from different layer 2 providers. Cheers Kent. ... View more

Hi Peter, No its not running vrf-lite.  Its a full PE with MPLS to the core. We are just atempting to setup dual attached sites with OSPF failover but its not so smooth with OSPF as the PE-CE routing protocol.  BGP seems to be a lot smoother for this but in this case Im stuck with OSPF. Kent. ... View more