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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox