[c-nsp] GigE woes

[tkapela at gmail.com]

Tim,

Assuming the Rx counters on your side(s) are all zeros, then we could move to consider perhaps their equipment has a layer 1.5 or PLCP issue -- failing to transport small and non-line-rate frames could be related to:

-slightly broken Rx pll or ifg detection in their rx path; whereby it locks "better" for longer/more frequent payloads than it will for small.

-"near Rx threshold condition" at the receiver on either side of your link, whereby FEC and block interleave codes "fail" with smaller frames, but can operate with larger, low entropy data.

Since this case is so odd, I also suggest you try ping with more "random" data -- ascii doesn't really involve that many bits in each byte. Perhaps this can tease out further detail after testing whether payload content has any bearing on success.

-Tk

-----Original Message-----
From: Aaron <dudepron at gmail.com>
Date: Mon, 17 May 2010 11:09:42 
To: Alexander<ecralar at hotmail.com>
Cc: <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] GigE woes

I wouldn't expect DWDM/Trasmission gear to have that kind of impact. That
equipment doesn't have that kind of intelligence. It has to be the end
equipment.

On Sun, May 16, 2010 at 03:50, Alexander <ecralar at hotmail.com> wrote:

> Tim,
> I am willing to bet that DWDM/transmission eqmt in between is waiting to
> "lump" several small packets together before attempting to send.
> Hence ping timeouts with small packets and no timeouts with large ones.
> Seen this before with ATM cells in Juniper ATM-1 PIC.
> HTH
> Regards
> Alex
>
>
> --------------------------------------------------
> From: "Tim Durack" <tdurack at gmail.com>
> Sent: Friday, May 14, 2010 7:53 PM
> To: <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] GigE woes
>
>
>  I've got a crazy GigE circuit that's having problems:
>>
>> RTR-1#ping vrf v10 10.241.1.10 repeat 10000 df-bit size 9000 timeout 1
>>
>> Type escape sequence to abort.
>> Sending 10000, 9000-byte ICMP Echos to 10.241.1.10, timeout is 1 seconds:
>> Packet sent with the DF bit set
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!
>> Success rate is 100 percent (587/587), round-trip min/avg/max = 8/18/408
>> ms
>>
>> RTR-1#ping vrf v10 10.241.1.10 repeat 10000 df-bit size 200 timeout 1
>>
>> Type escape sequence to abort.
>> Sending 10000, 200-byte ICMP Echos to 10.241.1.10, timeout is 1 seconds:
>> Packet sent with the DF bit set
>> ..!..!..!.!....!..!..!.!!..!...!..!..!..!..!.!!...!.!..!..!....!..!..!
>> ..!..!....!..!..!..!.!.!..!....!.!..!..!..!..!....!..!..!..!..!.!.!..!
>> .!..!..!..!..!....!..!..!..!..!....!!..!.!..!....!.!!....!..!..!..!..!
>> ....!.!..
>> Success rate is 32 percent (72/219), round-trip min/avg/max = 4/160/1180
>> ms
>>
>> RTR-1#ping vrf v10 10.241.1.10 repeat 10000 df-bit size 9000 timeout 1
>>
>> Type escape sequence to abort.
>> Sending 10000, 9000-byte ICMP Echos to 10.241.1.10, timeout is 1 seconds:
>> Packet sent with the DF bit set
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> Success rate is 100 percent (255/255), round-trip min/avg/max = 12/16/228
>> ms
>>
>> Ping with large frame size appears to pass. Small frame size results
>> in packet loss and unusually high rtt.
>>
>> Additionally, traffic must be present in both directions for any
>> traffic to cross the link. I have to start the ping on both routers
>> simultaneously. If the ping is stopped on one side, the ping from the
>> other side stops returning.
>>
>> Have mostly ruled out my equipment, but the carrier doesn't believe
>> there is anything wrong on their side. They strap a GigE tester across
>> the path and of course it works just fine. But try convincing arp/ospf
>> to work across such a link.
>>
>> The link appears to be a muxponder over the carriers DWDM network, so
>> it is mostly optical, possibly only two OEO points at the customer
>> hand off.
>>
>> Anyone seen anything like this before?
>>
>> --
>> Tim:>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>  _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/