I have seen this problem a number of times on our Cisco 897 routers. if the ATM interface flaps the virtual interface comes back up but the Dialer interface stays down. It seems the only way to recover is to reload the router. below is relevant config and output fro sh int di 1 when down   anybody else seen this problem?   interface ATM0  no ip address  no atm ilmi-keepalive ! interface ATM0.1 point-to-point  pvc 8/35   encapsulation aal5mux ppp dialer   dialer pool-member 1  ! interface Dialer1  ip address negotiated  ip access-group Internet-ACL in  ip nat outside  ip virtual-reassembly in  encapsulation ppp  ip tcp adjust-mss 1452  dialer pool 1  dialer idle-timeout 0  dialer down-with-vInterface  dialer-group 1  ppp authentication chap callin  ppp chap hostname xxxx.xxx  ppp chap password yyyyyy   below is sh int di 1 Dialer1 is down, line protocol is down   Hardware is Unknown   Internet address is xx.xx.xx.xx/32   MTU 1500 bytes, BW 56 Kbit/sec, DLY 20000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation PPP, LCP Closed, loopback not set   Keepalive set (10 sec)   DTR is pulsed for 1 seconds on reset   Interface is bound to Vi2   Last input never, output never, output hang never   Last clearing of "show interface" counters 07:24:21   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0   Queueing strategy: fifo   Output queue: 0/40 (size/max)   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      300842 packets input, 210743258 bytes      305884 packets output, 64407064 bytes Bound to: Virtual-Access2 is up, line protocol is up   Hardware is Virtual Access interface   MTU 1500 bytes, BW 747 Kbit/sec, DLY 20000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation PPP, LCP Open   Stopped: CDPCP   Open: IPCP   PPPoATM vaccess, cloned from Dialer1   Vaccess status 0x44   Bound to ATM0.1 VCD: 1, VPI: 8, VCI: 35, loopback not set   Keepalive set (10 sec)   DTR is pulsed for 5 seconds on reset   Interface is bound to Di1 (Encapsulation PPP)   Last input 00:00:03, output never, output hang never   Last clearing of "show interface" counters 07:22:33   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0   Queueing strategy: fifo   Output queue: 0/40 (size/max)   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      304391 packets input, 210956216 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      305936 packets output, 64408106 bytes, 0 underruns      0 output errors, 0 collisions, 0 interface resets      0 unknown protocol drops      0 output buffer failures, 0 output buffers swapped out      0 carrier transitions ... View more

We have a number of remote sites that communicate to the Anchor WLC thru  VPNs, Now some of these VPNs are thru 4G and tend to flap (perhaps 5 or 6 times per hour) and we loose control and data path between the anchor and the remote site.Now some sites seem to recover ok, but others dont these sites the only way to recover is to delete the site at the anchor, and delete the anchor at the site, then reconfigure. The control and data path will then come up for a while before it fails again. Is  there anyway to improve error recovery? BTW all the WLCs are 2504 running 8.2.110   ... View more

I have ISR 4331 doing policy map out of gi0/0/1 interface when I do a sh policy-map int gi0/0/1 see relevant part below the Route-out class should match all CS6 packets but seeing some in Default class the Interactivehigh-out class should match all cos3 prec 3 and dscp cs3 but seeing some in default class why is this?             Class-map: Route-out (match-all)             209 packets, 15466 bytes           30 second offered rate 0000 bps, drop rate 0000 bps           Match:  dscp cs6 (48)           Match: protocol eigrp           Queueing           queue limit 64 packets           (queue depth/total drops/no-buffer drops) 0/0/0           (pkts output/bytes output) 0/0           bandwidth 2% (3900 kbps)         Class-map: Interactivehigh-out (match-any)             22147 packets, 6345734 bytes           30 second offered rate 41000 bps, drop rate 0000 bps           Match:  dscp cs3 (24)           Match: ip precedence 3           Match: cos  3           Queueing           queue limit 203 packets           (queue depth/total drops/no-buffer drops) 0/0/0           (pkts output/bytes output) 22147/6345734           bandwidth 25% (48750 kbps)         Class-map: class-default (match-any)             379973 packets, 416764318 bytes           30 second offered rate 1393000 bps, drop rate 0000 bps           Match: any           Queueing           queue limit 256 packets           (queue depth/total drops/no-buffer drops) 0/0/0           (pkts output/bytes output) 379955/416756830           shape (average) cir 195000000, bc 1950000, be 0           target shape rate 195000000                        Exp-weight-constant: 4 (1/16)             Mean queue depth: 0 packets             dscp       Transmitted         Random drop      Tail drop          Minimum        Maximum     Mark                     pkts/bytes            pkts/bytes       pkts/bytes          thresh         thresh     prob                          default   324873/339535312       0/0              0/0                 64           256  1/10             3           54947/77209296        0/0              0/0                 64           128  1/10             4               2/252             0/0              0/0                 64           128  1/10             cs6          133/11970           0/0              0/0                112           128  1/10   ... View more

I am trying to find an answer to this question, We have just started looking after a remote site, that has 7960 and 7941 SIP phones that are registered to an external SIP (asterisk) server. The phones IP addresses are Natted on a Cisco 897 thru to the Internet. Now the 7960s work ok. But the 7941s cannot receive calls just make calls. I have searched for a definitive answer to why it is not working  but have not found one. looking at the ip nat translations below there are many more for the 7941 compared to the 7960 the .2,3 and 4 are 7960 and .5 is a 7941, all 7941s have a lot of entries Any help appreciated   udp 49.xx.xx.xx:1032   10.xx.xx.2:5060       110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:1024   10.xx.xx.3:5060       110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:1139   10.xx.xx.4:5060       110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:19224  10.xx.xx.4:19224      110.xx.xx.xx:15204 110.xx.xx.xx:15204 udp 49.xx.xx.xx:19226  10.xx.xx.4:19226      110.xx.xx.xx:19228 110.xx.xx.xx:19228 udp 49.xx.xx.xx:19228  10.xx.xx.4:19228      110.xx.xx.xx:14256 110.xx.xx.xx:14256 udp 49.xx.xx.xx:1037   10.xx.xx.5:5060       110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:1036   10.xx.xx.5:49158      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51673  10.xx.xx.5:51673      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51674  10.xx.xx.5:51674      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51675  10.xx.xx.5:51675      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51676  10.xx.xx.5:51676      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51677  10.xx.xx.5:51677      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51678  10.xx.xx.5:51678      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51679  10.xx.xx.5:51679      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51680  10.xx.xx.5:51680      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51681  10.xx.xx.5:51681      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51682  10.xx.xx.5:51682      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51683  10.xx.xx.5:51683      110.xx.xx.xx:5060  110.xx.xx.xx:5060 udp 49.xx.xx.xx:51684  10.xx.xx.5:51684      110.xx.xx.xx:5060  110.xx.xx.xx:5060 ... View more