[j-nsp] Re: ICMPv6 "packet too big" not being emitted

[Daniel Roesen]

On Tue, Jan 10, 2006 at 08:06:21PM +0200, Pekka Savola wrote:
> IPv6-in-IPv4 tunneling on Juniper has worked fine for us for a long 
> time (maybe from around 5.4R era) after glueing in MTU=1480. 
> Otherwise, it'd cause the exact PMTUD issues you describe, which we 
> finally got through as PR65486.

Well, I guess your problem was because of the tunnel payload MTU being
derrived from the underlying egress interface MTU? That's known
behaviour of both Cisco and Juniper. So manually configuring the payload
mtu (as I wrote in the email) is always a good idea.

> First off, I assume you're talking about v6 packet of at least 1481 
> bytes coming from a native interface to the tunnel interface with 
> MTU=1480 (that's the case we were looking at), instead of juniper 
> decapsulating too big packets.

Correct. Specifically (for my tests) ICMPv6 echo requests, sent with a
Fedora Core 4 box ping6 using parameter -s 1432, which results in 1480
octet packets (40 octets IPv6 header, 8 octets ICMPv6 echo request
header, 1432 ICMP echo request payload). Those do pass fine and I get
the echo reply from the other end of the tunnel. But as soon as I raise
-s to 1433 or higher, I do NOT get an "packet too big, mtu=1480" from
the Juniper terminating the tunnel. Other routers I tested with ip- and
gr- tunnels work fine for that:

[dr at srv01 dr]$ ping6 -s 1432 2001:5001:103:98::2
PING 2001:5001:103:98::2(2001:5001:103:98::2) 1432 data bytes
1440 bytes from 2001:5001:103:98::2: icmp_seq=0 ttl=63 time=23.5 ms

[dr at srv01 dr]$ ping6 -s 1433 2001:5001:103:98::2
PING 2001:5001:103:98::2(2001:5001:103:98::2) 1433 data bytes
>From 2001:5001:103:2101::1 icmp_seq=0 Packet too big: mtu=1480

> I'd check 3 things (these are rather straightforward and you've 
> probably already done them but just to be sure..):
>   - verify the scenario: encapsulating to a tunnel or decapsulating 
> from the tunnel? (in the latter case, there may also be MRU issues)

It's while encapsulating a >1480 IPv6 packet received from a MTU 1500
native interface into an IPv6-in-IPv4 tunnel with payload MTU 1480.

>   - check that the packets are actually what they should be (both ICMP 
> and data) and they get sent, are received and not get lost in the 
> network.  In particular, verify the packet sizes.

Check.

>   - try setting the MTU at the other end of the tunnel as well if 
> that'd help

It's set fixed 1480 there too as I'm told. Folks on the remote network
actually had problems accessing content (e.g. webserver) here, their
HTTP requests were dying with the usual symptoms, also proven via
tcpdump. So either my side of the tunnel (not actually on my own
network) doesn't emit ICMPv6 "packet too big" for the large web server
HTTP responses, or the tunnel ingress would have a payload MTU not
matching the underlying IPv4 end-to-end MTU of the tunnel - which is
verified to be 1500 (thus tunnel payload MTU configured to 1480).

==> I'm quite sure now that I do actually see erratic behaviour on this
Juniper, but I cannot observer the same behaviour on another router
using same code, and I cannot replicate it with my own Junis running
7.2 code. These others all do properly emit the "packet too big,
mtu=1480" responses (or mtu=1476 for GRE).

Short of asking my uplink to "reboot your router" I would like to find
out if that's a known bug. :-)


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0