Discussion:
AW: "onlink" option for ip route
C***@NDSatcom.com
2001-03-23 10:02:52 UTC
Permalink
Have a look to "Tunnels over IP in Linux-2.2" (ip-tunnels.ps, part of the
iproute package). They use 'onlink' to switch off the consistency check for
gateway reachability during tunnel setup.

Regards,
Carsten
-----Ursprüngliche Nachricht-----
Gesendet am: Mittwoch, 21. März 2001 09:23
Betreff: [LARTC] "onlink" option for ip route
Hi.
Would someone be so kind to explain "onlink" option to me? Upon
reading "ip command" ref.man. I still don't understand what this
option is intended for. A example where this option may be useful
would be appreciated.
Regards.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
** RoMaN SoFt / LLFB **
http://pagina.de/romansoft
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
http://ds9a.nl/2.4Routing/
RoMaN SoFt / LLFB!!
2001-03-24 11:43:07 UTC
Permalink
Post by C***@NDSatcom.com
Have a look to "Tunnels over IP in Linux-2.2" (ip-tunnels.ps, part of the
iproute package). They use 'onlink' to switch off the consistency check for
gateway reachability during tunnel setup.
Please, couldn't you summarize the meaning of "onlink" option? Is it
necessary or could I remove it in my multipath setting? See my former
posts; basically it's a default route with two nexthops for traffic
balancing between them:

linux balancer --> gatewayY
(192.168.0.1) (192.168.5.Y)

(where Y= 1, 2)

Balancer as well as gateway's are all connected to the same switch.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
** RoMaN SoFt / LLFB **
***@madrid.com
http://pagina.de/romansoft
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bert hubert
2001-03-24 21:36:27 UTC
Permalink
Post by RoMaN SoFt / LLFB!!
Please, couldn't you summarize the meaning of "onlink" option? Is it
necessary or could I remove it in my multipath setting? See my former
posts; basically it's a default route with two nexthops for traffic
If someone manages to write a reasonable explanation for the 'onlink'
option, I'll put it in the HOWTO ASAP.

Regards,

bert
--
http://www.PowerDNS.com Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
Rogerio Brito
2001-03-25 03:43:07 UTC
Permalink
Post by bert hubert
If someone manages to write a reasonable explanation for the
'onlink' option, I'll put it in the HOWTO ASAP.
As far as I understand it, the situation is as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sometimes, you may want to send packets via a machine
(i.e., a gateway) which is physically connected to your
network, but to which you don't specifically have a route in
your kernel routing table.

In a situation like this, if you try to add a route through
such a gateway, the kernel will perform consistency checks on
the route you're trying to add and will detect that it doesn't
know how to send packets to that gateway, rejecting the route.

The "onlink" option of the "ip" command tells the kernel that
the it does not have to check if the gateway is reachable
directly by the current machine (i.e., the kernel does not
need to check if the gateway is attached to the local
network), so that you can insert your route in the kernel
table without it being complained about.

One possible use of this feature is when you're setting up a
tunnel: you have to tell the kernel in some way that the other
side of the tunnel is the gateway for your tunneled
connection. But this other side is frequently very, very far
away, only reachable via your default route (and, thus, the
kernel doesn't have a direct route to it). So, to tell the
kernel that the rest of your tunneled connection is reachable
via this distant machine, you use the "onlink" option when
you're setting this special kind of route.

Of course, "onlink" should be used with caution.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Please let me know if this is acceptable. I could write with
more details (giving a more concrete example), but I'm very
busy right now. :-(

I hope that this serves at least as a first approximation to
the text that will be featured on the HOWTO.


Hope this helps, Roger...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - ***@iname.com - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
bert hubert
2001-03-25 14:14:16 UTC
Permalink
Post by Rogerio Brito
Post by bert hubert
If someone manages to write a reasonable explanation for the
'onlink' option, I'll put it in the HOWTO ASAP.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sometimes, you may want to send packets via a machine
(i.e., a gateway) which is physically connected to your
network, but to which you don't specifically have a route in
your kernel routing table.
I'm more confused then ever!

Alexey says this:
A: Yes, in 2.2 the rule that {\em normal} gateway must reside on directly
connected network has not any exceptions. You may tell kernel, that
this particular route is {\em abnormal}:
\begin{verbatim}
ifconfig tunl0 10.0.0.1 netmask 255.255.255.255
ip route add 10.0.0.0/8 via 193.233.7.65 dev tunl0 onlink
\end{verbatim}
Note keyword \verb|onlink|, it is the magic key that orders kernel
not to check for consistency of gateway address.
Probably, after this explanation you have already guessed another method
to cheat kernel:
\begin{verbatim}
ifconfig tunl0 10.0.0.1 netmask 255.255.255.255
route add -host 193.233.7.65 dev tunl0
route add -net 10.0.0.0 netmask 255.0.0.0 gw 193.233.7.65
route del -host 193.233.7.65 dev tunl0
\end{verbatim}
Well, if you like such tricks, nobody may prohibit you to use them.
Only do not forget
that between \verb|route add| and \verb|route del| host 193.233.7.65 is
unreachable.

However, our HOWTO says this:

ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb

We don't use onlink - might it be that 'onlink' is only useful for ipip
tunnels?
Post by Rogerio Brito
Please let me know if this is acceptable. I could write with
more details (giving a more concrete example), but I'm very
busy right now. :-(
Once this is cleared up, your text will do fine. Thanks!

Regards,

bert
--
http://www.PowerDNS.com Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
Guy Van Den Bergh
2001-03-25 17:25:08 UTC
Permalink
I'll try to give an example to see what the onlink option really does:

You have configured eth0 (on your machine) with an ip address/mask:
192.168.0.1/24

For some reason, you want to use a gateway on the physical LAN of eth0
which has an inconsistent configuration. Assume it has an address
10.0.10.1/24, which does not match the 192.168.0.1/24 configuration you
gave your own machine.

If you say:

ip route add default dev eth0 via 10.0.10.1

then you will get an error response (network unreachable or something).
Why? Because (strictly speaking) it does not make sense to have
a machine 10.0.10.1 on the eth0 lan, because you told your computer this
lan's network address is 192.168.0.0/24.

But here it comes: if you add "onlink" to the command, like this:

ip route add default dev eth0 via 10.0.10.1 onlink

then the route is accepted.

But now we come to another question: What does the kernel do if a packet
has to routed to this "onlink" gateway? I checked (by experiment), and
this is the result:
The kernel sends an arp request on the eth0-lan asking "who-has
10.0.10.1", which is the "onlink" gateway you configured. When it
receives a response, he has a MAC address where he can send his packets
to and routing will be performed.

This means: when the gateway's address doesn't match the lan
configuration on your computer (eth0), you can force the kernel to use
this gateway by adding "onlink" to the statement.

I guess there very rare situations where you have to use this feature.
Situations where you need the onlink option will mostly be a case of
poor network design... I don't think the average tunnel setup needs
"onlink" either.

Regards,
Guy
Post by bert hubert
Post by Rogerio Brito
Post by bert hubert
If someone manages to write a reasonable explanation for the
'onlink' option, I'll put it in the HOWTO ASAP.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sometimes, you may want to send packets via a machine
(i.e., a gateway) which is physically connected to your
network, but to which you don't specifically have a route in
your kernel routing table.
I'm more confused then ever!
A: Yes, in 2.2 the rule that {\em normal} gateway must reside on directly
connected network has not any exceptions. You may tell kernel, that
\begin{verbatim}
ifconfig tunl0 10.0.0.1 netmask 255.255.255.255
ip route add 10.0.0.0/8 via 193.233.7.65 dev tunl0 onlink
\end{verbatim}
Note keyword \verb|onlink|, it is the magic key that orders kernel
not to check for consistency of gateway address.
Probably, after this explanation you have already guessed another method
\begin{verbatim}
ifconfig tunl0 10.0.0.1 netmask 255.255.255.255
route add -host 193.233.7.65 dev tunl0
route add -net 10.0.0.0 netmask 255.0.0.0 gw 193.233.7.65
route del -host 193.233.7.65 dev tunl0
\end{verbatim}
Well, if you like such tricks, nobody may prohibit you to use them.
Only do not forget
that between \verb|route add| and \verb|route del| host 193.233.7.65 is
unreachable.
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb
We don't use onlink - might it be that 'onlink' is only useful for ipip
tunnels?
Post by Rogerio Brito
Please let me know if this is acceptable. I could write with
more details (giving a more concrete example), but I'm very
busy right now. :-(
Once this is cleared up, your text will do fine. Thanks!
Regards,
bert
Loading...