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

[Alexandre Snarskii]

On Fri, Feb 29, 2008 at 08:18:22AM -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. 

> 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
> > 
>