From: Federico Montesino Pouzols <p5087@quintero.fie.us.es>
To: lartc@vger.kernel.org
Subject: [LARTC] Strange behaviour of 'ip' with gateways inside non-main tables
Date: Thu, 31 May 2001 12:58:00 +0000 [thread overview]
Message-ID: <marc-lartc-99131425907007@msgid-missing> (raw)
Hi, Folks!
This post deals with ip:
~# ip -V
ip utility, iproute2-ss001007
I want to do this: The box (A) I try to configure has three
network interfaces (eth1, eth2 and eth3) connected through a switch to
a router (let's say 192.168.100.20). Depending on the source ip
(192.168.100.11 or 192.168.100.12 or 192.168.100.13) I want to send to
the router the packets through one and only one interface, for
instance:
packets from 192.168.100.11 go through eth1
packets from 192.168.100.12 go through eth2
packets from 192.168.100.13 go through eth3
<parenthesis>
Before attempting it, let's do a similar thing but sending the
packets to a directly connected host (for example, B). This can easily
be accomplished with three rules and three tables, one rule and one
table for every source address. I have been using this for a long time
and it works fine:
------- ---------
|eth1-192.168.100.11 --------- | |
|----------------------| | | |
BOX A | | | | BOX B |
|eth2-192.168.100.12 | | | |
|----------------------|switch |-------| 192.168.100.2
| | | | |
|eth3-192.168.100.13 | | | |
|----------------------| | | |
------- --------- ---------
# ip rule add from 192.168.100.11 lookup 11
# ip rule add from 192.168.100.12 lookup 12
# ip rule add from 192.168.100.13 lookup 13
# ip ro a 192.168.100.2 dev eth1 t 11
# ip ro a 192.168.100.2 dev eth2 t 12
# ip ro a 192.168.100.2 dev eth3 t 13
</parenthesis>
The problem arises when I insert a router between my box A and my
box B, then I have to use 'via'...
------ ----------
|eth1-192.168.100.11 --------- | |
|----------------------| | | |
BOX A| | | | ROUTER |
|eth2-192.168.100.12 | | | |
|----------------------|switch |-------|192.168.100.20
| | | | |
|eth3-192.168.100.13 | | | | -------
|----------------------| | | |-------| |
------ --------- ---------- | |
|BOX B|
| |
| |
-------
192.168.100.2
I try:
# ip ro a 192.168.100.20 dev eth1 t 11
# ip ro a 192.168.100.20 dev eth2 t 12
# ip ro a 192.168.100.20 dev eth3 t 13
No problem, but...
# ip ro a 192.168.100.2 via 192.168.100.20 dev eth1 table 11
RTNETLINK answers: Network is unreachable
It seemed ip requires a route to 192.168.100.20 _____in the
main table_____. So, before doing this, I try to deceive 'ip', making
a fake route that I will delete soon:
# ip ro a 192.168.100.20 dev eth1
then,
# ip ro a 192.168.100.2 via 192.168.100.20 dev eth1 t 11
works fine.
And so on with the other two interfaces:
# ip ro change 192.168.100.20 dev eth2
# ip ro a 192.168.100.2 via 192.168.100.20 dev eth2 t 12
# ip ro change 192.168.100.20 dev eth3
# ip ro a 192.168.100.2 via 192.168.100.20 dev eth2 t 13
Finally, I delete the fake route from the main table,
# ip ro del 192.168.100.20
and, fortunately, get the desired state:
~# ip ru s
0: from all lookup local
32763: from 192.168.100.13 lookup 13
32764: from 192.168.100.12 lookup 12
32765: from 192.168.100.11 lookup 11
32766: from all lookup main
32767: from all lookup default
~# ip r s t 11
192.168.100.20 dev eth1 scope link
default via 192.168.100.20 dev eth1
~# ip r s t 12
192.168.100.20 dev eth2 scope link
default via 192.168.100.20 dev eth2
~# ip r s t 13
192.168.100.20 dev eth3 scope link
default via 192.168.100.20 dev eth3
~# ip r s
~# ip r get 192.168.100.20
RTNETLINK answers: Network is unreachable
~# ip r get 192.168.100.20 from 192.168.100.11
192.168.100.20 from 192.168.100.11 dev eth1
cache mtu 1500
~# ip r get 192.168.100.20 from 192.168.100.12
192.168.100.20 from 192.168.100.12 dev eth2
cache mtu 1500
~# ip r get 192.168.100.20 from 192.168.100.13
192.168.100.20 from 192.168.100.13 dev eth3
cache mtu 1500
So, it works, but I can only configure my routing tables deceiving 'ip'
with the false routes in the main table, that finally I can delete without
any trouble.
Conclussion: It works but the way it is configured is pretty ugly.
I have tried doing 'ip r flush cache' between one 'route add' and
the following 'route add', also I have tried adding a ____'from
192.168.100.x'___ and a ___'t 1x'___ qualifier to the 'ip route add
.... via ...' commands; none of these solved the problem.
*** Q: I wonder if this is a bug of 'ip' (it seems to check routes
to desired gateways looking up the main table only and ignoring rules
and source qualifiers) or if I am doing something wrong.
Thanks in advance for any feedback.
Read you soon!
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
reply other threads:[~2001-05-31 12:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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-99131425907007@msgid-missing \
--to=p5087@quintero.fie.us.es \
--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.