Been having troubles with Cisco 870 (877) routers with recent IOS revisions.
Earlier revisions had lots of bugs, some nasty and some cosmetic but the real need for a recent release is the improvement in SIP ALG and the addition of several features. Unfortunately the newer releases aren’t much better.
Seeing serious issues with 12.4(22)T where after a month or so the router runs out of contiguous memory and stops. It doesn’t reload – it just becomes incapacitated, which is much worse than a reload. Syslogs show increasing memory fragmentation (rather than a leak per-se).
12.4(24)T is worse – it reloads every half-hour. Haven’t been able to grab the console debug yet.
Another bloke has blogged similar issues – I’ve pinged it here http://www.alcatron.net/wp-trackback.php?p=154
Update:
c870-advipservicesk9-mz.124-24.T1 is stable, both on NAT and SIP ALG.

A warning if you use Cisco IOS-based PPTP VPN’s.

I’ve got a 2651XM running 12.4(15)T5. I was having terrible trouble establishing a vpn from Visa SP1 – the tunnel would just not work, the "verifying username and password" prompt just timed out. I was using the config I posted in another blog entry which worked fine on a c837.

I tried everything – pulling MPPE and using PAP – to no avail.

Turns out the command "ppp lcp predictive" under the Virtual-Template was killing it – and no debug would clearly show what was going on.

So beware…

CAVEAT: ppp lcp predictive doesn’t work on all IOS’s!

Like the rest of the world, I found Windows Mobile 6.1 would not connect to a Cisco VPDN server over PPTP.

I really needed this, so I struggled with it (for days). Finally I got it working! Sadly this means every customer I need to connect to must have this config.. grrr.

The issue seems to be the WM PPTP client is limited in its capabilities – it isn’t very flexible in what it negotiates with the server.

The main trouble was MPPE/MPPC negotiation – WM only supports stateful (or maybe only stateless but not both) MPPE.

PPP negotiation debugs showed a long back and forth CONFREQ CONFNAK sequence where WM just wouldn’t accept any offered types.

This behaviour was observed with 12.4(5b) on a c837.

Note you must use MS-CHAP-v2 only on the router. The easiest way is to use MS IAS on the server and configure that properly along with the router’s RADIUS config (another blog post later to describe how to get this working!)

In short, here’s the relevant Virtual Template config, along with some recommendations for PPTP:

vpdn-group <vpdn group>

accept-dialin
protocol pptp
virtual-template 10
pptp tunnel echo 30
ip tos reflect
ip tos 15
ip precedence critical
ip pmtu
ip mtu adjust

interface Virtual-Template10
mtu 1380
ip unnumbered Ethernet0
no ip proxy-arp
no ip route-cache same-interface
ip tcp header-compression
peer default ip address pool <your IP pool>
keepalive 20
compress mppc
ppp lcp predictive
ppp encrypt mppe 128 passive
ppp authentication ms-chap-v2 <your authentication list to RADIUS>

ppp authorization <your authorization list to RADIUS>
ppp ipcp mask 255.255.0.0
ppp ipcp predictive
ppp link reorders

Let me know how this works for you. And curse you MS and Cisco, so much for the ‘pledge to make products work together’.

Keywords: PPTP, VPN, VPDN, LCP, MPPC, MPPE, MS-CHAP-v2, IOS, CISCO, WM, WM6.1, Windows Mobile,, compression, encryption

Comments

Ben Ryan – 13/02/2009 1:15:39 PM

This is a snip of a successful negotiation:
1643181: Feb 9 08:11:07.122: Vi6 PPP: Phase is UP
1643182: Feb 9 08:11:07.122: Vi6 IPCP: O CONFREQ [Closed] id 1 len 16
1643183: Feb 9 08:11:07.122: Vi6 IPCP: CompressType VJ 15 slots CompressSlot ID (0x0206002D0F01)
1643184: Feb 9 08:11:07.122: Vi6 IPCP: Address 172.17.1.1 (0x0306AC110101)
1643185: Feb 9 08:11:07.122: Vi6 CCP: O CONFREQ [Closed] id 1 len 10
1643186: Feb 9 08:11:07.122: Vi6 CCP: MS-PPC supported bits 0x00000001 (0x120600000001)
1643187: Feb 9 08:11:07.126: Vi6 PPP: Process pending ncp packets
1643188: Feb 9 08:11:07.310: Vi6 CCP: I CONFREQ [REQsent] id 0 len 10
1643189: Feb 9 08:11:07.310: Vi6 CCP: MS-PPC supported bits 0x00000001 (0x120600000001)
1643190: Feb 9 08:11:07.314: Vi6 CCP: O CONFACK [REQsent] id 0 len 10
1643191: Feb 9 08:11:07.314: Vi6 CCP: MS-PPC supported bits 0x00000001 (0x120600000001)
1643192: Feb 9 08:11:07.330: Vi6 IPCP: I CONFREQ [REQsent] id 0 len 40
1643193: Feb 9 08:11:07.330: Vi6 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
1643194: Feb 9 08:11:07.330: Vi6 IPCP: Address 0.0.0.0 (0x030600000000)
1643195: Feb 9 08:11:07.334: Vi6 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
1643196: Feb 9 08:11:07.334: Vi6 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
1643197: Feb 9 08:11:07.334: Vi6 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
1643198: Feb 9 08:11:07.334: Vi6 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
1643199: Feb 9 08:11:07.334: Vi6 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 0.0.0.0
1643200: Feb 9 08:11:07.334: Vi6 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want 0.0.0.0
1643201: Feb 9 08:11:07.338: Vi6 IPCP: Pool returned 172.17.0.129
1643202: Feb 9 08:11:07.338: Vi6 IPCP: O CONFREJ [REQsent] id 0 len 10
1643203: Feb 9 08:11:07.338: Vi6 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
1643204: Feb 9 08:11:07.338: Vi6 IPCP: O CONFNAK [REQsent] id 1 len 28
1643205: Feb 9 08:11:07.338: Vi6 IPCP: Address 172.17.0.129 (0x0306AC110081)
1643206: Feb 9 08:11:07.342: Vi6 IPCP: PrimaryDNS 172.17.2.10 (0x8106AC11020A)
1643207: Feb 9 08:11:07.342: Vi6 IPCP: PrimaryWINS 172.17.2.10 (0x8206AC11020A)
1643208: Feb 9 08:11:07.342: Vi6 IPCP: SecondaryDNS 172.17.1.2 (0x8306AC110102)
1643209: Feb 9 08:11:07.342: Vi6 IPCP: O CONFACK [REQsent] id 2 len 34
1643210: Feb 9 08:11:07.342: Vi6 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
1643211: Feb 9 08:11:07.346: Vi6 IPCP: Address 172.17.0.129 (0x0306AC110081)
1643212: Feb 9 08:11:07.346: Vi6 IPCP: PrimaryDNS 172.17.2.10 (0x8106AC11020A)
1643213: Feb 9 08:11:07.346: Vi6 IPCP: PrimaryWINS 172.17.2.10 (0x8206AC11020A)
1643214: Feb 9 08:11:07.346: Vi6 IPCP: SecondaryDNS 172.17.1.2 (0x8306AC110102)
1643215: Feb 9 08:11:07.350: Vi6 IPV6CP: I CONFREQ [Not negotiated] id 0 len 14
1643216: Feb 9 08:11:07.350: Vi6 IPV6CP: Interface-Id 0218:41FF:FEAC:A676 (0x010A021841FFFEACA676)
1643217: Feb 9 08:11:07.354: Vi6 LCP: O PROTREJ [Open] id 3 len 20 protocol IPV6CP (0x80570100000E010A021841FFFEACA676)
1643218: Feb 9 08:11:07.354: Vi6 IPCP: I CONFACK [ACKsent] id 1 len 16
1643219: Feb 9 08:11:07.354: Vi6 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)
1643220: Feb 9 08:11:07.354: Vi6 IPCP: Address 172.17.1.1 (0x0306AC110101)
1643221: Feb 9 08:11:07.354: Vi6 IPCP: State is Open
1643222: Feb 9 08:11:07.362: Vi6 IPCP: Install route to 172.17.0.129
1643223: Feb 9 08:11:07.362: Vi6 IPCP: Add link info for cef entry 172.17.0.129
1643224: Feb 9 08:11:07.370: Vi6 CCP: I CONFACK [ACKsent] id 1 len 10
1643225: Feb 9 08:11:07.370: Vi6 CCP: MS-PPC supported bits 0x00000001 (0x120600000001)
1643226: Feb 9 08:11:07.370: Vi6 CCP: State is Open
1643227: Feb 9 08:11:07.490: Vi6 IPCP: I CONFREQ [Open] id 1 len 34
1643228: Feb 9 08:11:07.490: Vi6 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
1643229: Feb 9 08:11:07.490: Vi6 IPCP: Address 0.0.0.0 (0x030600000000)
1643230: Feb 9 08:11:07.494: Vi6 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
1643231: Feb 9 08:11:07.494: Vi6 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
1643232: Feb 9 08:11:07.494: Vi6 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
1643233: Feb 9 08:11:07.494: Vi6 IPCP: Ignoring predicted packet, state is Open
1643234: Feb 9 08:11:07.530: Vi6 IPCP: I CONFREQ [Open] id 2 len 34
1643235: Feb 9 08:11:07.530: Vi6 IPCP: CompressType VJ 15 slots (0x0206002D0F00)
1643236: Feb 9 08:11:07.530: Vi6 IPCP: Address 172.17.0.129 (0x0306AC110081)
1643237: Feb 9 08:11:07.534: Vi6 IPCP: PrimaryDNS 172.17.2.10 (0x8106AC11020A)
1643238: Feb 9 08:11:07.534: Vi6 IPCP: PrimaryWINS 172.17.2.10 (0x8206AC11020A)
1643239: Feb 9 08:11:07.534: Vi6 IPCP: SecondaryDNS 172.17.1.2 (0x8306AC110102)
1643240: Feb 9 08:11:07.534: Vi6 IPCP: Ignoring predicted packet, state is Open
1643251: Feb 9 08:11:08.114: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access6, changed state to up

I’ve noticed one of my switches is broadcasting ATMARP frames every 10 seconds to all switchports.. I had no idea why, as the switch has no ATM interfaces (naturally) nor does the IOS support ATM/LANE. CDP and STP was disabled.

I think these frames are being mis-decoded in Network Monitor – they also showed as loopback frames in the trace (even though classified as ATMARP), which led me to this page http://www.ams-ix.net/technical/config_guide/config_guide.htm#commonly_seen_illegal_traffic_and_setup

Aha! These frames are sent by default every 10 secs on each ethernet interface as a soft connectivity testing mechanism.

This is an example of someone seeing this kind of traffic – http://www.velocityreviews.com/forums/t38199-damn-loop.html

To disable an interface’s soft loopback diagnostic frame capability, configure "no keepalives" on the interface.

The downside to configuring this is the interface will always show UP/UP when any media is connected – speed/duplex issues will not trigger UP/DOWN.

Wonderful mysteries and magics of IT :)