In a message dated: Mon, 25 Nov 2002 22:09:35 EST
[EMAIL PROTECTED] said:
>On Mon, 25 Nov 2002, at 3:29pm, [EMAIL PROTECTED] wrote:
>> However, by ssh'ing to systemB, and from there to systemC, I run 'tcpdump
>> -i eth1 icmp' and I can see that systemC *is* in fact receiving the "icmp
>> echo request" packets. systemC just isn't replying to them!
>
> That is significant.
>
> There are two possibilities. One: The system is receiving those packets,
>but thinks it should not reply to them. Two: The system is replying, but
>you are not seeing the replies.
[snip]
> Just to satisfy paranoia, use another system to sniff the Ethernet that
>"system C" is plugged into. If "system C" is plugged into a switch, add a
>repeater for "system C" and the sniffer.
Errrr. You're going to make walk to the other end of the building!? ;)
> Is the system multi-homed? If so, is there any chance it is sending the
>packets out the wrong interface?
Yes it is multi-homed, that's how I ssh to it. I ssh to systemB on
it's external interface, then to C on the internal interface.
I've run tcpdump on all three of of it's interfaces searching for
icmp packets. They only show up on the external interface which is
exibiting problems. The third interface is not currently configured,
so it's rather tough to tcpdump an interface which is down ;)
> You said these systems are running Linux, right? Create firewall rules
>that log ICMP packets but don't specify a jump target. That will show you
>what the kernel router *thinks* is going on. This has the added benefit of
>not watching a particular interface.
True, but that also means I need to now re-compile the kernel for
firewall support (which I should probably do anyway...), and that
may take a while.
> Assuming you find no evidence of replies going into a blackhole, that
>means the system must not be replying for some reason. Why?
>
> If "system C" thinks the packet is for a different host, the packet will
>be dropped. Since it sometimes *does* reply, I cannot see how this could be
>the cause.
Agreed.
> Firewall rules could do this, but you've already checked that. What about
>ICMP rate limiting? Does the kernel do anything like that outside of
>IPTABLES? I don't think it does, but maybe?
It's a pretty generic kernel, and unless icmp rate limiting is turned
on by default, I don't believe I'm using it. Also, keep in mind,
this system is actually one of 7. All 7 are identical hardware, and
were all installed using FAI, and from an kernel config POV, are also
identical. The only differences are the layered sw they're running
(apache1.x vs. apache2.x vs. bind9, etc.) Of the 7 systems, there is
1 which never exibits this problem, 2 which occassionally exhibit
this problem, 1 which almost *always* exhibits this problem
(systemC), and 3 which I haven't done enough testing of to determine
whether or not they exhibit this problem consistently.
> If the packet's checksum is bad, the packet will be silently dropped. If
>it has a header somewhere that is somehow bad, it may be silently dropped.
>Is something somewhere (router) corrupting the packets? Try dumping the
>full packet structure. Ethereal (or tethereal) is great for this. Look for
>any reason the packet might be considered invalid.
Good idea. Of course, I don't know what a corrupt packet looks like,
but I assume if I see one, I'll know it :)
> If the system thinks the packet is part of an incomplete fragment, it will
>hold it in memory for reassembly. According to your tcpdump output, the DF
>(Don't Fragment) bit is set... is a router somewhere ignoring that bit?
Entirely possible, it's a Cisco, and we all know how they feel about
standard protocols ;)
Thanks!
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
_______________________________________________
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
