From: Guy Van Den Bergh <guy.vandenbergh@pandora.be>
To: lartc@vger.kernel.org
Subject: Re: Request for TEXT: [LARTC] "onlink" option for ip route
Date: Sun, 25 Mar 2001 17:25:08 +0000 [thread overview]
Message-ID: <marc-lartc-98554493630908@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98546988301347@msgid-missing>
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
bert hubert wrote:
> On Sun, Mar 25, 2001 at 12:43:07AM -0300, Rogerio Brito wrote:
>
>> On Mar 24 2001, bert hubert wrote:
>>
>>> 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.
>
>
> 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?
>
>
>> 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
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
prev parent reply other threads:[~2001-03-25 17:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-24 21:36 Request for TEXT: [LARTC] "onlink" option for ip route bert hubert
2001-03-25 3:43 ` Rogerio Brito
2001-03-25 14:14 ` bert hubert
2001-03-25 17:25 ` Guy Van Den Bergh [this message]
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=marc-lartc-98554493630908@msgid-missing \
--to=guy.vandenbergh@pandora.be \
--cc=lartc@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.