[j-nsp] Ip header problem - G/E 1000Base-LX

Thu Apr 6 05:44:38 EDT 2006

Well probably you are right, i can't see any visible hardware damage but 
who knows...
and it is really surprising to me that reseting the pic might cause that 
interface is working fine,

Thanks a lot

Piotr

> I had almost exactly the same issue with a GE PIC...
>
> Turns out that someone "didn't know" that you have to pull the 
> ejection lever before installing the PIC, so they put it in the 
> chassis and pushed -- when it wouldn't slide in easily, he sat on the 
> floor, put his feet on the PIC and pushed as hard as he could -- it 
> hopped the rails and slid against the next PIC / rail...
>
> Link would come up but I would get weird short packets -- lots of 
> truncated  / corrupted packets (usually just after the ethernet header 
> (MPLS or IP)) , runts, etc.
> Reseating the PIC (or sometimes just offline/online cycles) would fix 
> it for a bit...
>
> Here is a photo of the damage: 
> http://www.kumari.net/gallery2/main.php?g2_itemId=698
>
> I suspect you PIC is borked....
>
> Warren
>
>
> On Apr 5, 2006, at 3:33 AM, Piotr S wrote:
>
>> Hi,
>> i have very strange and interesting problem with juniper g/e 
>> interface. When
>> i am connecting this g/e to another device (juniper or cisco) the 
>> link seems
>> to come up, everything looks fine but the ip layer is not working. On
>> juniper side i can monitor traffic and everything looks fine, but the 
>> other
>> side just cannot see juniper packets. After many hours of 
>> investigation (and
>> port monitoring) it turned out that Juniper sends ip packets with bad IP
>> header - the length field is set to 16 (should be 20 - beside this
>> everything is just fine). What is more after many request online/offline
>> commands it sometimes start to send wrong arp replies, well the arp 
>> reply is
>> correct but the source address  is incorrect (zeros on 3 octet). You 
>> can see
>> that in ethereal capture below.
>> This interface had similar problem in the past but many online/offline
>> requests seemd to help (for one year)
>> It hapened in both m10 and m20, with different software, rebooting the
>> router didn't change anything. It seems like it have to "come up" and 
>> then
>> there are no problem with it.
>>
>> It looks like a magic to me, any ideas what's going on?
>>
>>
>>
>> Bogus ip header seen in ethereal:
>> No.     Time        Source                Destination           Protocol
>> Info
>>       1 0.000000    JuniperN_3a:ec:bc     00:14:6a:2e:8a:c2     IP
>> Bogus IP header length (16, must be at least 20)
>>
>> Frame 1 (98 bytes on wire, 98 bytes captured)
>>     Arrival Time: Mar 28, 2006 02:32:42.975550000
>>     Time delta from previous packet: 0.000000000 seconds
>>     Time since reference or first frame: 0.000000000 seconds
>>     Frame Number: 1
>>     Packet Length: 98 bytes
>>     Capture Length: 98 bytes
>> Ethernet II, Src: 00:90:69:3a:ec:bc, Dst: 00:14:6a:2e:8a:c2
>>     Destination: 00:14:6a:2e:8a:c2 (00:14:6a:2e:8a:c2)
>>     Source: 00:90:69:3a:ec:bc (JuniperN_3a:ec:bc)
>>     Type: IP (0x0800)
>> Internet Protocol
>>     Version: 4
>>     Header length: 16 bytes (bogus, must be at least 20)
>>
>> 0000  00 14 6a 2e 8a c2 00 90 69 3a ec bc 08 00 45 00   ..j.....i:....D.
>> 0010  00 54 9c 49 00 00 fe 01 08 89 0a ea 00 01 0a ea   .T.I............
>> 0020  00 02 08 00 dd 7f 8e 6a 01 00 2a 84 28 44 40 4a   .......j..*.(D at J
>> 0030  0d 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15   ................
>> 0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !"#$%
>> 0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345
>> 0060  36 37                                             67
>>
>>
>> Wrong arp response:
>> No.     Time        Source                Destination           Protocol
>> Info
>>       8 23.090667   00:14:6a:2e:8a:c3     Broadcast             
>> ARP      Who
>> has 10.1.1.1?  Tell 10.1.1.2
>>
>> Ethernet II, Src: 00:14:6a:2e:8a:c3, Dst: ff:ff:ff:ff:ff:ff
>>     Destination: ff:ff:ff:ff:ff:ff (Broadcast)
>>     Source: 00:14:6a:2e:8a:c3 (00:14:6a:2e:8a:c3)
>>     Type: ARP (0x0806)
>>     Trailer: 00000000000000000000000000000000...
>> Address Resolution Protocol (request)
>>     Hardware type: Ethernet (0x0001)
>>     Protocol type: IP (0x0800)
>>     Hardware size: 6
>>     Protocol size: 4
>>     Opcode: request (0x0001)
>>     Sender MAC address: 00:14:6a:2e:8a:c3 (00:14:6a:2e:8a:c3)
>>     Sender IP address: 10.1.1.2 (10.1.1.2)
>>     Target MAC address: 00:00:00:00:00:00 (00:00:00_00:00:00)
>>     Target IP address: 10.1.1.1 (10.1.1.1)
>>
>> No.     Time        Source                Destination           Protocol
>> Info
>>       9 23.091781   JuniperN_3a:ec:bc     00:14:6a:2e:8a:c3     ARP
>> 10.1.0.1 is at 00:90:69:3a:ec:bc
>>
>> Ethernet II, Src: 00:90:69:3a:ec:bc, Dst: 00:14:6a:2e:8a:c3
>>     Destination: 00:14:6a:2e:8a:c3 (00:14:6a:2e:8a:c3)
>>     Source: 00:90:69:3a:ec:bc (JuniperN_3a:ec:bc)
>>     Type: ARP (0x0806)
>>     Trailer: 0A020000000000000000000000000000...
>> Address Resolution Protocol (reply)
>>     Hardware type: Ethernet (0x0001)
>>     Protocol type: IP (0x0800)
>>     Hardware size: 6
>>     Protocol size: 4
>>     Opcode: reply (0x0002)
>>     Sender MAC address: 00:90:69:3a:ec:bc (JuniperN_3a:ec:bc)
>>     Sender IP address: 10.1.0.1 (10.1.0.1)
>>     Target MAC address: 00:14:6a:2e:8a:c3 (00:14:6a:2e:8a:c3)
>>     Target IP address: 10.1.1.2 (10.1.1.2)
>>
>>
>> Regars
>> Piotr Szafran
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> --"He who laughs last, thinks slowest."
>     -- Anonymous
>
>
>