[j-nsp] strange packet loss without impact

[Matthias Brumm]

Hello!

At the moment I am monitoring it with top on UNIX shell, do you have another
suggestion? In top this process is idleing.

Regards,

Matthias

2011/7/4 Christian <cdebalorre at neotelecoms.com>

> Hi,
> Try to monitor the fwdd process - when running high it causes packet to
> drop on these pc's.
>
> Christian
>
>
> Le 04/07/2011 13:11, Adam Leff a écrit :
>
>  I realize this will sound silly, but have you checked for half-duplex
>> on your interfaces?
>>
>> Those onboard J6350 interfaces are actually 10/100/1000, so if you
>> don't have the speed and link-mode hardcoded,  do a show interfaces
>> extensive ge-0/0/# and check the link partner section to ensure you're
>> running full-duplex.
>>
>> Adam
>>
>> On Jul 4, 2011, at 7:01, Matthias Brumm<matthias at brumm.net>  wrote:
>>
>>  Hello!
>>>
>>> Since some weeks now, we have a strange packet loss on one of our edge
>>> locations.
>>>
>>> A few days ago an IX informed us about packet loss on our router. The
>>> router
>>> in place is a J6350. We have a 1 Gig line to us and two 1 Gig lines to
>>> some
>>> uplinks. Every communication goes through a 1 Gig copper link to a
>>> ProCurve
>>> 2810-24G. So the external links are connected to the switch and the
>>> switch
>>> via one cable with the router.
>>>
>>> The packet loss is strange, because:
>>>
>>> 1. In smokeping during the busy hours of the day, there are losses of
>>> about
>>> 5%
>>> 2. From my workstation I get packet loss of about 10 up to 50%
>>> 3. There are no errors on the switch or router interface (except i.e.
>>> VLAN
>>> errors)
>>> 4. no customers have reported any problems. But there are many customers
>>> relying on real time communication (VoIP/RDP)
>>> 5. The switch port with the router is showing maximum 200 Mbit
>>> 6. The router is showing 20% real-time threads
>>>
>>> According to the datasheet the J-Series should be able to deliver this
>>> performance easily. Or are the onboard Gig-Interfaces the problem? Of
>>> course
>>> I know, that this physical configuration is a bad idea, and I will change
>>> is
>>> very soon to ease the load on this particular port.
>>>
>>> Any other ideas?
>>>
>>> Regards,
>>>
>>> Matthias
>>> ______________________________**_________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>>
>> ______________________________**_________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>
> ______________________________**_________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>