[LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

[LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

[Andrew McGill]

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

RE: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

[Flechsenhaar, Jon J]

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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

RE: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

[Pio Mendez]

[-- Attachment #1: Type: text/html, Size: 3828 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

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

Re: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

[Martin A. Brown]

-----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-----
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

[Alexandru Dragoi]

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
>   

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

Re: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

[Martin A. Brown]

-----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-----
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] netmask 255.255.255.255 vs ip route add via ... (bug?)

[Andrew McGill]

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?
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc