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

[Paul Goyette]

If your traffic is transiting an IPsec tunnel, please have
a look at the following tech bulletin:

http://alerts-int.juniper.net/pa/viewalert.jsp?actionBtn=Search&txtAlert
Number=PSN-2008-02-017&viewMode=Return

Paul Goyette
Juniper Networks Customer Service
JTAC Senior Escalation Engineer
PGP Key ID 0x53BA7731 Fingerprint:
  FA29 0E3B 35AF E8AE 6651
  0786 F758 55DE 53BA 7731 

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of 
> Alexandre Snarskii
> Sent: Friday, February 29, 2008 6:51 AM
> To: Juniper-NSP Mailing list
> Subject: [j-nsp] j-series vs. short pings ?
> Importance: High
> 
> 
> 
> Hi!
> 
> During narrowing down one of our problems, I found, that I'm able 
> to ping juniper from directly connected (vlan) subinterface only 
> when ICMP payload size is more or equal 18 bytes... 
> 
> Example:
> 
> root at chumadan:~>ping -s 17 10.21.88.100
> PING 10.21.88.100 (10.21.88.100): 17 data bytes
> ^C
> --- 10.21.88.100 ping statistics ---
> 4 packets transmitted, 0 packets received, 100.0% packet loss
> 
> but when size is 18 (or more) - everything is fine: 
> 
> root at chumadan:~>ping -s 18 10.21.88.100
> PING 10.21.88.100 (10.21.88.100): 18 data bytes
> 26 bytes from 10.21.88.100: icmp_seq=0 ttl=64 time=0.435 ms
> 26 bytes from 10.21.88.100: icmp_seq=1 ttl=64 time=0.395 ms
> 
> 
> At the same time, doing 
> monitor traffic interface ge-0/0/2.468 detail no-resolve matches icmp
> I can see, that when I'm pinging with 17-byte (or less) sized packets,
> juniper sees them with 'broken' ICMP checksum: 
> 
> 17:36:39.959518  In IP (tos 0x0, ttl  64, id 15916, offset 0, 
> flags [none], proto: ICMP (1), length: 45) 10.21.88.99 > 
> 10.21.88.100: ICMP echo request, id 13318, seq 0, length 25 
> (wrong icmp cksum 0 (->d452)!)
> 17:36:40.970227  In IP (tos 0x0, ttl  64, id 15918, offset 0, 
> flags [none], proto: ICMP (1), length: 45) 10.21.88.99 > 
> 10.21.88.100: ICMP echo request, id 13318, seq 1, length 25 
> (wrong icmp cksum 0 (->d1a6)!)
> 17:36:41.949567  In IP (tos 0x0, ttl  64, id 15920, offset 0, 
> flags [none], proto: ICMP (1), length: 45) 10.21.88.99 > 
> 10.21.88.100: ICMP echo request, id 13318, seq 2, length 25 
> (wrong icmp cksum 0 (->ce47)!)
> 
> but when I'm tcpdumping those pings on sending side or on SPAN port
> at the egress from switch to juniper - everything is OK.... 
> 
> Details: Juniper is J6350 running [8.3R1.5] (Export edition), 
> interface 
> is onboard GE-TX, configuration is pretty simple: 
> 
> snar at RT088-002> show configuration interfaces ge-0/0/2   
> description "DOWNLINK to SW088-001 inet";
> vlan-tagging;
> mtu 9018;
> unit 468 {          
>     description IP-MUX;
>     vlan-id 468;    
>     family inet {   
>         mtu 1500;   
>         address 10.21.88.100/24;
>     }               
> }                   
> 
> Question: is there any way to fix this behaviour ? (short ICMP pings
> is the way the RAD IPMux verifies mac-address of his gateway, and
> we're just unable to use IPMux'es as downlinks to Juniper)..
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>