LARTC - Nov 2006 - netmask 255.255.255.255 vs ip route add via ... (bug?)

Greetings routing folks,

I want to use the netmask 255.255.255.255 to insulate (not quite 
isolate) machines on a shared subnet from each other.  This works 
just fine on win XP, but Linux iproute will not acccept the 
gateway address in one step -- neither on the command line nor 
via DHCP:

Here''s the interface, set up with a netmask of /32:

     # ip addr
     ...
     2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
         link/ether 00:08:74:48:1f:0c brd ff:ff:ff:ff:ff:ff
         inet 192.168.1.6/32 brd 192.168.1.255 scope global eth0
         inet6 fe80::208:74ff:fe48:1f0c/64 scope link
            valid_lft forever preferred_lft forever
     ...

And here''s me trying to add the route:

     # ip route add default via 192.168.1.17
     RTNETLINK answers: Network is unreachable

Hmm ... erk ... workaround ... add a host route first, then add 
it as a default route ...

     # sudo ip route add 192.168.1.17 dev eth0
     # sudo ip route add default via 192.168.1.17

And this is what we get ... (yep, it works)

     # ip route ls
     192.168.1.17 dev eth0  scope link
     default via 192.168.1.17 dev eth0

But wait!  We can delete the host route! And it works just fine 
(you *can* try this at home folks).

     # sudo ip route del 192.168.1.17
     # ip route ls
     default via 192.168.1.17 dev eth0

So why did we need that host route?

It should be possible to add the gateway directly, or it should 
be impossible to delete it once something "depends" on it.  The 
current behaviour seems a little unbalanced (and, for my strange 
purposes, inconvenient :)

   Tested on Ubuntu 6.06 Dapper (Kernel: 2.6.15, iproute2 20041019)
   Looks the same on Fedora Core 3, (Kernel 2.6.11.8, iproute2 2.6.9)

&:-)


-- 
Disclaimer: this disclaimer and your base are us

Does it work if you do this?

Ip route add -net x.x.x.x netmask 255.255.255.255 gw x.x.x.x 


Jon Flechsenhaar
Boeing WNW Team
Network Services
(714)-762-1231
202-E7

-----Original Message-----
From: Andrew McGill [mailto:andrewm@intoweb.co.za] 
Sent: Tuesday, November 14, 2006 5:49 AM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

Greetings routing folks,

I want to use the netmask 255.255.255.255 to insulate (not quite
isolate) machines on a shared subnet from each other.  This works just
fine on win XP, but Linux iproute will not acccept the gateway address
in one step -- neither on the command line nor via DHCP:

Here''s the interface, set up with a netmask of /32:

     # ip addr
     ...
     2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen
1000
         link/ether 00:08:74:48:1f:0c brd ff:ff:ff:ff:ff:ff
         inet 192.168.1.6/32 brd 192.168.1.255 scope global eth0
         inet6 fe80::208:74ff:fe48:1f0c/64 scope link
            valid_lft forever preferred_lft forever
     ...

And here''s me trying to add the route:

     # ip route add default via 192.168.1.17
     RTNETLINK answers: Network is unreachable

Hmm ... erk ... workaround ... add a host route first, then add it as a
default route ...

     # sudo ip route add 192.168.1.17 dev eth0
     # sudo ip route add default via 192.168.1.17

And this is what we get ... (yep, it works)

     # ip route ls
     192.168.1.17 dev eth0  scope link
     default via 192.168.1.17 dev eth0

But wait!  We can delete the host route! And it works just fine (you
*can* try this at home folks).

     # sudo ip route del 192.168.1.17
     # ip route ls
     default via 192.168.1.17 dev eth0

So why did we need that host route?

It should be possible to add the gateway directly, or it should be
impossible to delete it once something "depends" on it.  The current
behaviour seems a little unbalanced (and, for my strange purposes,
inconvenient :)

   Tested on Ubuntu 6.06 Dapper (Kernel: 2.6.15, iproute2 20041019)
   Looks the same on Fedora Core 3, (Kernel 2.6.11.8, iproute2 2.6.9)

&:-)


--
Disclaimer: this disclaimer and your base are us
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

It works because linux (and XP too) maintain a cache of all routes learned. 
Try:  ip route show cache.
You can clean this cache:  ip route flush cache.

From:  Andrew McGill 
To:  lartc@mailman.ds9a.nl
Subject:  [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)
Date:  Tue, 14 Nov 2006 15:48:41 +0200 (SAST)
>Greetings routing folks,
>
>I want to use the netmask 255.255.255.255 to insulate (not quite 
>isolate) machines on a shared subnet from each other.  This works 
>just fine on win XP, but Linux iproute will not acccept the gateway 
>address in one step -- neither on the command line nor via DHCP:
>
>Here''s the interface, set up with a netmask of /32:
>
>     # ip addr
>     ...
>     2: eth0:  mtu 1500 qdisc pfifo_fast 
>qlen 
1000
>         link/ether 00:08:74:48:1f:0c brd ff:ff:ff:ff:ff:ff
>         inet 192.168.1.6/32 brd 192.168.1.255 scope global eth0
>         inet6 fe80::208:74ff:fe48:1f0c/64 scope link
>            valid_lft forever preferred_lft forever
>     ...
>
>And here''s me trying to add the route:
>
>     # ip route add default via 192.168.1.17
>     RTNETLINK answers: Network is unreachable
>
>Hmm ... erk ... workaround ... add a host route first, then add it 
>as a default route ...
>
>     # sudo ip route add 192.168.1.17 dev 
eth0
>     # sudo ip route add default via 192.168.1.17
>
>And this is what we get ... (yep, it works)
>
>     # ip route ls
>     192.168.1.17 dev eth0  scope link
>     default via 192.168.1.17 dev eth0
>
>But wait!  We can delete the host route! And it works just fine (you 
>*can* try this at home folks).
>
>     # sudo ip route del 192.168.1.17
>     # ip route ls
>     default via 192.168.1.17 dev eth0
>
>So why did we need that host route?
>
>It should be possible to add the gateway directly, or it should be 
>impossible to delete it once something "depends" on it.  The
current
>behaviour seems a

little unbalanced (and, for my strange purposes, 
>inconvenient :)
>
>   Tested on Ubuntu 6.06 Dapper (Kernel: 2.6.15, iproute2 20041019)
>   Looks the same on Fedora Core 3, (Kernel 2.6.11.8, iproute2 
>2.6.9)
>
>&:-)
>
>
>--
>Disclaimer: this disclaimer and your base are us
>_______________________________________________
>LARTC mailing list
>LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

MSN Amor Busca tu ½ naranja 

--===============1049191912=Content-Type: text/plain;
charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

--===============1049191912==--

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings Andrew McGill,

 : I want to use the netmask 255.255.255.255 to insulate (not quite 
 : isolate) machines on a shared subnet from each other.  This works 
 : just fine on win XP, but Linux iproute will not acccept the 
 : gateway address in one step -- neither on the command line nor 
 : via DHCP:

Try using the onlink nexthop flag for your route:

  # ip route add onlink default via 192.168.1.17

This marks the route for entry even though the local routing table 
may not have a route to the nexthop destination.  In your case, this 
is a valid parameter, and should prevent the need for you to add the 
host route only to remove it.

 : So why did we need that host route?

You need the host route to the destination as a simple sanity check.  
- From the perspective of the kernel, there''s no route to 192.168.1.17 
if the IP bound to your interface is a /32.  When you add the route, 
the sanity check succeeds.

Essentially, you are suppressing this sanity check by using the 
onlink parameter, which says "Yes, I know there''s no route to IP 
192.168.1.17 out this interface, but I know the IP is there on this 
link layer anyway, so set the route anyway and stop griping."*

Good luck,

- -Martin

 * RTNETLINK answers: Network is unreachable

- -- 
Martin A. Brown
http://linux-ip.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)

iD8DBQFFWnH+HEoZD1iZ+YcRAsu2AKDixJF7A0LMClN8snQVq1zk9DV4dQCeIW7R
HMtOMud8Kt5yQLskMK7HwDY=PVyl
-----END PGP SIGNATURE-----

Martin A. Brown wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings Andrew McGill,
>
>  : I want to use the netmask 255.255.255.255 to insulate (not quite 
>  : isolate) machines on a shared subnet from each other.  This works 
>  : just fine on win XP, but Linux iproute will not acccept the 
>  : gateway address in one step -- neither on the command line nor 
>  : via DHCP:
>
> Try using the onlink nexthop flag for your route:
>
>   # ip route add onlink default via 192.168.1.17
>   
shouldn''t be

# ip route add onlink default via 192.168.1.17 dev $DEV
?

Because from the point of view of the kernel, 192.168.1.17 is unreachable, it
must know the interface.

> This marks the route for entry even though the local routing table 
> may not have a route to the nexthop destination.  In your case, this 
> is a valid parameter, and should prevent the need for you to add the 
> host route only to remove it.
>
>  : So why did we need that host route?
>
> You need the host route to the destination as a simple sanity check.  
> - From the perspective of the kernel, there''s no route to
192.168.1.17
> if the IP bound to your interface is a /32.  When you add the route, 
> the sanity check succeeds.
>
> Essentially, you are suppressing this sanity check by using the 
> onlink parameter, which says "Yes, I know there''s no route to
IP
> 192.168.1.17 out this interface, but I know the IP is there on this 
> link layer anyway, so set the route anyway and stop griping."*
>
> Good luck,
>
> - -Martin
>
>  * RTNETLINK answers: Network is unreachable
>
> - -- 
> Martin A. Brown
> http://linux-ip.net/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)
>
> iD8DBQFFWnH+HEoZD1iZ+YcRAsu2AKDixJF7A0LMClN8snQVq1zk9DV4dQCeIW7R
> HMtOMud8Kt5yQLskMK7HwDY> =PVyl
> -----END PGP SIGNATURE-----
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexandru,

 : >   # ip route add onlink default via 192.168.1.17
 : >   
 : shouldn''t be
 : 
 : # ip route add onlink default via 192.168.1.17 dev $DEV
 : ?
 : 
 : Because from the point of view of the kernel, 192.168.1.17 is 
 : unreachable, it must know the interface.

Absolutely!  Thank you for the correction of my ommission.

- -Martin

- -- 
Martin A. Brown
http://linux-ip.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)

iD8DBQFFWx5ZHEoZD1iZ+YcRAizdAKCM9yVTH40l60mbxFx05ftapB9bPwCg4jKh
AGbZhbm15DCRTrtwnBtAlpk=yAvc
-----END PGP SIGNATURE-----

On Wednesday Nov 15, 2006 around 8:04am, Martin A. Brown wrote,

...
> : # ip route add onlink default via 192.168.1.17 dev $DEV
> : ?
> :
> : Because from the point of view of the kernel, 192.168.1.17 is
> : unreachable, it must know the interface.
>
> Absolutely!  Thank you for the correction of my ommission.
Is there a reason that ''onlink'' is not the default behaviour
when
the device is specified?  Would onlink add some information that 
is missing? e.g.
 	ip route add 12.0.0.0/8 via 5.5.5.5 dev eth0
should mean that 5.5.5.5 is directly connected to eth0 (rightly 
or wrongly).

&:-)

--
Overflow in kitchen sink. Do you want to report this error?