[j-nsp] j-series vs. short pings ?

[Alexandre Snarskii]

On Fri, Feb 29, 2008 at 09:31:42AM -0800, Paul Goyette wrote:
> > > If your traffic is transiting an IPsec tunnel, please have
> > > a look at the following tech bulletin:
> > 
> > IPSec is not involved in this setup, lab topology is as simple as
> > notebook(freebsd) - switch(catalyst 2960) - juniper 6350. 
> 
> Hmmm.  Sounds like something isn't padding the Ethernet frame
> to the minimum frame-length of 64 bytes, or is ignoring the
> VLAN tag when calculating the minimum acceptable frame length.
> 
> 	MAC header   14
> 	IP header    20
> 	ICMP header  12
> 	ICMP payload 17
> 	---------------
> 	Total        63
> 
> Check for runts on the J-6350 router, as well as verify that
> frames are arriving.  Also check to see if it still fails with
> non-VLAN-tagged interface.  And maybe put a sniffer on the
> line to see if the frames are being padded, and by how much.

Frames arriving to J6350 well. No problems with padding found. 
No problems with runtime errors too. Have'nt checked untagged
packets yet...

Interesting enough, that when I make interface member of vrf-type 
routing-instance - problem disappears... 
And, I can confirm that I have no problems with transit packets, 
and that I have no problems with 'unrouteable'/'firewalled' frames 
(in that case I'm getting RE(or fwdd?)-generated ICMP host unreachables, 
just as I should). So, the problem is limited to: short frames AND destined 
to routing engine AND arriving in 'default' routing table. Put any reason
off - and problem disappears. 
Looks much more likely that there is some bug in JUNOS (8.3R1.5, export 
edition) than any other reason...

PS: example of broken packet: 

19:48:54.250389  In PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 26604, offset 0, flags [none], proto: ICMP (1), length: 28) 10.11.12.14 > 10.11.12.13: ICMP echo request, id 35437, seq 1, length 8 (wrong icmp cksum 0 (->6d91)!)
                         0200 0000 4500 001c 67ec 0000 4001 e6c4
                         0a0b 0c0e 0a0b 0c0d 0800 0000 8a6d 0001
                         0000 0000 0000 0000 0000 0000 0000 c1fd
                         684d

shows that ICMP checksum is really wrong. May be it's just stripped
off by Marvel chip or by fwdd before forwarding to RE and RE code
is not expecting it to be stripped in some (rare enough, I admit) 
situations. 

PPS: example of 'firewalled' ping and ICMP response:
ping packet: 

21:41:01.954515 00:e0:00:82:34:c6 > 00:19:e2:45:e3:82, ethertype IPv4 (0x0800), length 59: (tos 0x0, ttl 64, id 6924, offset 0, flags [none], proto ICMP (1), length 45) 10.11.12.14 > 10.21.88.100: ICMP echo request, id 49494, seq 0, length 25
        0x0000:  4500 002d 1b0c 0000 4001 e732 0a0b 0c0e  E..-.... at ..2....
        0x0010:  0a15 5864 0800 dbfb c156 0000 47cc 463d  ..Xd.....V..G.F=
        0x0020:  000e 9065 0809 0a0b 0c0d 0e0f 10         ...e.........

response packet: 

21:41:01.977917 00:19:e2:45:e3:82 > 00:e0:00:82:34:c6, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) 10.11.12.13 > 10.11.12.14: ICMP host 10.21.88.100 unreachable - admin prohibited filter, length 36
        (tos 0x0, ttl 64, id 6924, offset 0, flags [none], proto ICMP (1), length 45) 10.11.12.14 > 10.21.88.100: ICMP echo request, id 49494, seq 0, length 25
        0x0000:  4500 0038 0000 0000 fe01 9094 0a0b 0c0d  E..8............
        0x0010:  0a0b 0c0e 030d 57a0 0000 0000 4500 002d  ......W.....E..-
        0x0020:  1b0c 0000 4001 e732 0a0b 0c0e 0a15 5864  .... at ..2......Xd
        0x0030:  0800 dbfb c156 0000                      .....V..

- you can see, that in response at offset 0x32 there is correct checksum,
0xdfdb, copied from original packet (originally at offset 0x16).