Hi, Has anybody noticed that when: ip addr add 192.168.0.1/32 dev eth0 ip route add 192.168.0.2/32 dev eth0 The system will not respond to arprequests from 192.168.0.2, even when rp_filter=0, proxy_arp=1, etc... I will investigate it further at another time, but this has caused me a lot of headaches... Grrr... -- mail up 170+00:33, 7 users, load 0.16, 0.22, 0.17 mistar1 up 28+18:37, 17 users, load 0.22, 0.08, 0.04 Let your government know you value your freedom: sign the petition: http://petition.eurolinux.org _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Ard van Breemen wrote:> Hi, > Has anybody noticed that when: > ip addr add 192.168.0.1/32 dev eth0 > ip route add 192.168.0.2/32 dev eth0/32? this would be a subnetmask with one host per subnet - so how could the host communicate with a router in it''s own subnet? not at all. it seems to me this doesn''t make much sense. maybe i just haven''t got the point. greetings, ulric -- ulrich schwarz, computing center, university of ulm, germany _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Mon, May 05, 2003 at 01:21:52PM +0200, ulrich schwarz wrote:> Ard van Breemen wrote: > >Hi, > >Has anybody noticed that when: > >ip addr add 192.168.0.1/32 dev eth0 > >ip route add 192.168.0.2/32 dev eth0 > > /32? this would be a subnetmask with one host per subnet - so how could > the host communicate with a router in it''s own subnet? not at all.The use of whatever ip address to bind an interface to the ip stack should not have any consequences to the arp behaviour if rp_filter=0. If I said: ip addr add 127.0.0.1/32 dev eth0 ip link set up eth0 echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter it should answer any arp request for any of it''s ip addresses. Adding a route to a device only makes sure that you can make rp_filter=1. At least that used to be the behaviour before 2.4.20. I''ve tested a lot of this stuff, and it is used in a lot of places (not only by me). It would hurt a lot of people if it does not work any more.> it seems to me this doesn''t make much sense. maybe i just haven''t got > the point.Split a /24 in a lot of smaller subnets on a firewall with > 50 interfaces. -- mail up 170+01:42, 8 users, load 0.08, 0.14, 0.20 mistar1 up 28+19:46, 17 users, load 0.02, 0.01, 0.00 Let your government know you value your freedom: sign the petition: http://petition.eurolinux.org _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello, On Mon, 5 May 2003, Ard van Breemen wrote:> Hi, > Has anybody noticed that when: > ip addr add 192.168.0.1/32 dev eth0 > ip route add 192.168.0.2/32 dev eth0It should respond after "ip route flush cache", you are missing something, I assume eth0 is not down. Regards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tue, May 06, 2003 at 12:07:32AM +0300, Julian Anastasov wrote:> On Mon, 5 May 2003, Ard van Breemen wrote: > > > Hi, > > Has anybody noticed that when: > > ip addr add 192.168.0.1/32 dev eth0 > > ip route add 192.168.0.2/32 dev eth0 > > It should respond after "ip route flush cache",Grrrr, thanks Julian.> you are missing something, I assume eth0 is not down.Correct. This was just the educational example... Pfff, I thought I was going insane.... I had a 2.4.18 kernel talking to a 2.4.20 kernel, except that the 2.4.20 kernel did not reply on the arps... Now to find something soft to bounce my head against (I already have the headache, so I don''t want it to hurt extra...). Eh, just curious in how arp depends on routing... I''ve already seen how neigh/gc_thresh[123] can influence the reachability of a host, and that the routing cache can lock entries in the neigh table while they are being flushed, filling up the neigh table etc... -- mail up 171+00:12, 7 users, load 0.08, 0.20, 0.16 mistar1 up 29+18:16, 17 users, load 0.02, 0.04, 0.00 Let your government know you value your freedom: sign the petition: http://petition.eurolinux.org _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello, On Tue, 6 May 2003, Ard van Breemen wrote:> Eh, just curious in how arp depends on routing... I''ve already > seen how neigh/gc_thresh[123] can influence the reachability of a > host, and that the routing cache can lock entries in the neigh > table while they are being flushed, filling up the neigh table > etc...When ARP packet is received the ARP code uses "input routing" lookup (which can return cached entry) to determine what IP is resolved. The result can be "local delivery", "forward", etc but there are additional conditions that determine whether we reply to this probe. In short, ARP follows the IPv4 routing with additional checks. In your case I assume we already have cached entry and without flushing it we can not provide actual/valid lookup result. The rule is that if you care, after adding new route you have to flush the cache. After adding IP addresses the flush is automatically performed from the kernel but it is not true for the routes. Regards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/