[c-nsp] 7206 pppoe concentrator and vpn issues

Frank Bulk frnkblk at iname.com
Wed Apr 19 09:44:10 EDT 2006


I've been having problems with a customer who tries to retrieve his HP
Openmail/Exchange over his corporate Nortel Contivity VPN connection and the
email sync traffic always grinds to a halt, even though web browsing works
perfect.  He says it works from late at night to early in the morning, and
every other hotspot he uses, but not against our service.  We have the same
router (at a different release) and changing the local MTU hasn't seemed to
make a different except break the VPN when I set it to 1000.  I'm starting
to suspect that perhaps the corporate email server is not negotiating a low
enough MTU, for whatever the reason.

How are you detecting these ICMP packets going down the PPPoE tunnel rather
than back to the originator?  Do you have an access list set up against that
interface?

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Code Monkey
Sent: Wednesday, April 19, 2006 7:37 AM
To: Alain Cocconi
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 7206 pppoe concentrator and vpn issues

On 8/17/05, Alain Cocconi <cocconi at canl.net> wrote:
> Hello,
>
> I'm terminating 2000 pppoe connexions using a 7206 NPE-G1, all is ok 
> except some customers who have problems with vpn and games like World 
> of Wordcraft. It seems that Checkpoint's vpn only have problems (I'm 
> not sure about this). Checkpoint says it is like a mtu/mss problem, 
> but I've check all and I can not see any issue in my config, if 
> someone has idea about this , thanks.

On a 7206 12.2 T, I've seen problems with the ICMP packets saying "packet
too big and DF set".

The too big packets come in from Internet, they don't fit into the pppoe
tunnel, the ICMP is generated correctly... and routed down the pppoe link
instead of back to the originator. I suppose the IOS code had already set
the output interface, or something like that.

If the CPE routes the packet out again, you won't detect a problem, but
(too-)smart (firewalling and/or antispoofing) CPEs will drop the packets,
breaking PMTUD.

I twigged to this when I had PMTUD problems, couldn't understand why I got
ICMP must fragment for certain clients and not for others, managed to find
one misbehaving link with a firewall I could configure myself, and enabled
"really-full" logging on it.

Couldn't find a Cisco bug ID specifically for that, ISTR there were some
about the must fragment not being generated.

HTH

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list