netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Szymon Miotk <spam@crocom.com.pl>
To: netdev@oss.sgi.com
Cc: kuznet@ms2.inr.ac.ru
Subject: PROBLEM: Bad ARP requests make an entry in routing cache
Date: Wed, 30 Mar 2005 16:45:48 +0200	[thread overview]
Message-ID: <424ABB9C.7070500@crocom.com.pl> (raw)

[1.] One line summary of the problem:
Bad ARP requests make an entry in routing cache

[2.] Full description of the problem/report:
When there is client/router netmask mismatch (client has wider mask than 
the route), ARP request to non-existing local networks make an entry in 
routing cache on the router.
Example configuration in [6.]

[3.] Keywords (i.e., modules, networking, kernel):
networking, arp, routing

[4.] Kernel version (from /proc/version):
2.6.12-rc1
work also on 2.6.10_rc1_bk17, 2.6.11.
I have not tried earlier versions, because I need some bug-fixes 
introduced in 2.6.10_rc1_bk17

[5.] Output of Oops.. message (if applicable) with symbolic information
      resolved (see Documentation/oops-tracing.txt)
no oops here.

[6.] A small shell script or example program which triggers the
      problem (if possible)
Config:

[CLIENT eth0]-----[eth0 ROUTER eth1]-----internet

CLIENT eth0: 10.1.1.4/16
SERVER eth0: 10.1.1.1/24 (note the different netmasks!)
SERVER eth1: whatever
/proc/sys/net/ipv4/ip_forward=1

The session as follows:
server # route -Cn | grep 44

CLIENT # ping 10.1.44.44

server #  route -Cn |grep 44
10.1.1.4        10.1.44.44      153.19.190.40   i     0      0        2 eth1

The only packet, that arrives to the server is (according to tcpdump)
16:31:46.425917 arp who-has 10.1.44.44 tell 10.1.1.4

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Fedora Core 3

iproute-2.6.11-1 (the freshest I could get from 'developement' branch), 
works with older versions too

It's enough, when you leave
Packet Socket
Unix domain sockets
TCP/IP networking (all sub-options off)
in the 'networking options'.
It must be somewhere in the core networking/routing.

[X.] Other notes, patches, fixes, workarounds:
I have recompiled the kernel serveral times with different options.
No workaround.

The bug is a big problem, when you have netmask mismatch (well, I have 
few hundred clients with it and this cannot be fixed easily). A PC 
infected with a aggresive virus causes hundreds ARP requests per 
seconds, what in turns leads to routing cache overflows. This doesn't 
kill the router, but slows it down and there is significant delay, when 
making a new connection. I would call it 'soft DoS'.

Szymon Miotk

                 reply	other threads:[~2005-03-30 14:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=424ABB9C.7070500@crocom.com.pl \
    --to=spam@crocom.com.pl \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).