Re: 1841 Packet loss

Hi Andrey, thanks for the help,

Well, I think it's the 1841 because the packet loss occurs accros the WAN point to point as the pps increase, so this would seem to eliminate anything beyond (LAN Wise) The duplex is hardcoded 100/full everywhere, the LAN side switch has been changed. The other side of the WAN is a 6509 (layer2), and a GSR (layer 3)so I doubt that's the issue. There is no queing at all on the router, all it's doing is passing the traffic to the LAN, the config is very very simple. The WAN is capped by the telco providing the link. Not sure how, but we proved that out to 18Mbps.

I suspect this has to do with the fact that the packet are tranversing both integrated FE ports and that they share some sort of processing. But so far Cisco TAC hasn't been answer that question.

Thanks for your help

Hello, Scott! You wrote on 30 Mar 2005 08:20:28 -0800:

S> Hi Andrey, thanks for the help,

S> Well, I think it's the 1841 because the packet loss occurs accros S> the WAN point to point as the pps increase, so this would seem to S> eliminate anything beyond (LAN Wise)

How did you find this out?

S> The duplex is hardcoded 100/full everywhere, the LAN side switch has been S> changed. The other side of the WAN is a 6509 (layer2), and a GSR (layer 3)so S> I doubt that's the issue. There is no queing at all on the router, S> all it's doing is passing the traffic to the LAN, the config is S> very very simple. The WAN is capped by the telco providing the S> link. Not sure how, but we proved that out to 18Mbps.

S> I suspect this has to do with the fact that the packet are S> tranversing both integrated FE ports and that they share some sort S> of processing. But so far Cisco TAC hasn't been answer that S> question.

Well, if you have spare 1841 or can take this one out of the service for a 30 minutes, you can use iperf to either confirm this problem or rule 1841 out. Just use -l to tune packet size.