On 2005/09/19 14:30:14, Joe . wrote:
> I would check to make sure the nic is negotiating properly. It might
> be half duplex instead of full or something flakey etc. Check the
> output of ifconfig.
That would show up in netstat -ni (Vinicius says he looked there).
I have just been looking at a nicely-coloured but fairly useless
switch which randomly doesn't forward some packets of ~300+ bytes
and almost all packets >700 bytes or so. Ethernet layer appears
to be clean (at least netstat -ni doesn't show errors) but it's
definitely not forwarding correctly (including to it's own
IP stack). So it's quite possible that the ISP's kit could be
broken in some way that doesn't easily show up.
> > i also enabled STP as my ISP told me it would help their redundancy.
I question this.. STP allows you to put multiple ethernet connections
in place and disable all but one. This means there's a spare path to
an upstream switch in case of link failure. You don't appear to be
doing this, so I don't see how it could help. (I don't see a reason
for it to hurt either, but who knows if you're triggering some switch
vendor's bug).
Have you detected *where* the packets are being dropped?
One simple way is to use hubs (obviously you must not be forcing full-
duplex in this case) in between your transparent-proxying bridge and
the switches it's connecting to (port-mirroring might also be an
option if you have control of the switches). Plug boxes into these
to run tcpdump on, then send and watch for some identifiable traffic
(ICMP or something).
I would be inclined to try:
1. Ask ISP to try at least another switch port, if not another switch.
2. Disable any special options such as STP.
Also check they're not being lost downstream/upstream (e.g. between
the switch and the other host) by checking switch port stats if you can.
> > real mem = 2146459648 (2096152K)
> > cpu3: Intel(R) Xeon(TM) CPU 2.40GHz ("GenuineIntel" 686-class) 2.40 GHz
That's quite some box to see a Realtek attached to ;-)
