Date: Mon, 2 Jul 2001 16:34:40 +0300 (EEST) From: Iasen Kostoff <tbyte@tbyte.org> To: Ruslan Ermilov <ru@FreeBSD.ORG> Cc: net@FreeBSD.ORG Subject: Re: Indirect route with also indirect gateway Message-ID: <Pine.BSF.4.21.0107021534090.8303-100000@shadow.otel.net> In-Reply-To: <20010702152631.C77685@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Jul 2001, Ruslan Ermilov wrote:
> On Mon, Jul 02, 2001 at 01:16:19PM +0300, Iasen Kostoff wrote:
> >
> >
> > On Mon, 2 Jul 2001, Ruslan Ermilov wrote:
> >
> > > On Mon, Jul 02, 2001 at 12:49:44PM +0300, Iasen Kostoff wrote:
> > > >
> > > >
> > > > On Mon, 2 Jul 2001, Ruslan Ermilov wrote:
> > > >
> > > > > On Sun, Jul 01, 2001 at 03:15:56PM -0600, Wes Peters wrote:
> > > > > > Ruslan Ermilov wrote:
> > > > > > >
> > > > > > > BTW, Wes, I'm still waiting for a working example of an indirect route
> > > > > > > with also indirect gateway.
> > > > > >
> > > > > > Any indirect route via the opposite end of a point-to-point connection.
> > > > > > Right?
> > > > > >
> > > > > You probably meant that the gateway is accessible via the opposite end.
> > > > >
> > > > > But the gateway value on a P2P link is a no-op. Whatever gateway you
> > > > > specify, the actual gateway is always the "opposite end". Here, the
> > > > > gateway only helps the routing code to select the right interface.
> > > > > I.e., on a 1.1.1.1 -> 2.2.2.2 configured tun0 interface, the following
> > > > > two commands are equivalent:
> > > > >
> > > > > route add -net 10 2.2.2.2
> > > > > route add -net 10 -iface tun0
> > > > >
> > > > > Funny though that you're giving this example, as it only works starting
> > > > > with revision 1.62 (from June 4, 2001) of sys/net/route.c. Before this,
> > > > > routing code incorrectly set up the interface based on destination, not
> > > > > the gateway:
> > > > >
> > > > > # ifconfig tun0
> > > > > tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
> > > > > inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000
> > > > >
> > > > > # netstat -rn
> > > > > Routing tables
> > > > >
> > > > > Internet:
> > > > > Destination Gateway Flags Refs Use Netif Expire
> > > > > default 192.168.4.65 UGSc 1 0 rl0
> > > > > 2.2.2.2 1.1.1.1 UH 0 0 tun0
> > > > > 3.3.3.3 tun0 UHS 1 0 tun0
> > > > > 127.0.0.1 127.0.0.1 UH 1 6 lo0
> > > > > 192.168.4 link#1 UC 3 0 rl0 =>
> > > > > 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 2 1576 rl0 899
> > > > > 192.168.4.115 0:c0:df:3:2d:79 UHLW 2 2 lo0
> > > > >
> > > > > # route add -net 10 3.3.3.3
> > > > > add net 10: gateway 3.3.3.3
> > > > >
> > > > > # netstat -rn | grep 3.3.3.3
> > > > > 3.3.3.3 tun0 UHS 1 0 tun0
> > > > > 10 3.3.3.3 UGSc 0 0 rl0
> > > > > ^^^^ oops
> > > > >
> > > > > I still think we should disallow such routes on non-P2P interfaces, at
> > > > > least. What do you think?
> > > > >
> > > > If you speek about disallowing routes like : route add -net 10 3.3.3.3
> > > > I don't think we should. I'm using such routes now (ethernet bridges for
> > > > leased lines) and don't want to loose this functionality.
> > > >
> > > Could you please describe your setup in more details?
> > >
> > > I would like to disallow such routes for broadcast-like interfaces like
> > > Ethernet, because on these interfaces, adding such a route results in:
> > >
> > > arplookup 3.3.3.3 failed: host is not on local network
> > > arpresolve: can't allocate llinfo for 3.3.3.3rt
> > >
> > > It is a MUST here that the gateway should be directly connected
> > > (via ARP).
> > >
> > If you have this route :
> > 3.3.3.3 link#1 UC 1 0 rl0 =>
> >
> > it won't result in this error message.
> >
> Having this host entry with the RTF_CLONING flag set, as you have shown
> it, is impossible. It could only have been "cloned" from a network-type
> routing table entry, as shown in the commit log for revision 1.50 of
> route/route.c, and this case shouldn't be affected by that change.
> Or like this:
>
> 3.3.3/24 link#1 UCSc 1 0 rl0
> 3.3.3.3 link#1 UHLW 1 1 rl0
> 10 3.3.3.3 UGSc 0 11 rl0
>
> But then again, this means that the gateway (3.3.3.3) is directly reachable
> (think one hop) on one of the attached networks (rl0), but the ARP reply
> haven't been (yet) received, due to the host being down, as indicated by
> ping(8):
>
> # ping 10.0.0.1
> PING 10.0.0.1 (10.0.0.1): 56 data bytes
> ping: sendto: No route to host
> ping: sendto: No route to host
> ^C
> --- 10.0.0.1 ping statistics ---
> 6 packets transmitted, 0 packets received, 100% packet loss
>
> 3.3.3.3 link#1 UHRLW 1 0 rl0
>
> (Note that `R' (RTF_REJECT) flag is set by arpresolve() after
> net.link.ether.inet.maxtries unsuccessful ARP request tries.)
>
>
That is my interface config:
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 212.36.9.113 netmask 0xffffff00 broadcast 212.36.9.255
ether 00:04:76:22:15:83
media: autoselect (100baseTX <full-duplex>) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX
10baseT/UT
P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
xl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113
ether 00:10:5a:21:73:55
media: autoselect (100baseTX) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX
10baseT/UT
P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
xl2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113
ether 00:10:4b:b8:65:2c
media: autoselect (10baseT/UTP) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX
10baseT/UT
P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113
ether 00:40:05:60:f8:d8
and the static routes:
#:> netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif
Expire
default 212.36.8.129 UGSc 16 1612418 xl0
127.0.0.1 127.0.0.1 UH 4 14226 lo0
212.36.8 link#1 UCSc 28 0 xl0 =>
212.36.9 link#1 UC 4 0 xl0 =>
212.36.9.113 0:10:5a:21:73:55 UHLW 0 123 lo0 =>
212.36.9.113/32 link#2 UC 1 0 xl1 =>
212.36.9.114 0:0:b4:59:dc:91 UHLS 2 1257089 ed0
212.36.9.115 0:0:b4:59:dc:91 UHLS 0 21764 ed0
212.36.9.119 0:80:ad:7c:2c:8c UHLS 0 616255 xl1
212.36.9.126/31 212.36.9.124 UGSc 0 40 xl0
212.36.9.128/31 212.36.9.124 UGSc 0 0 xl0
212.36.9.130/31 link#3 UCSc 1 0 xl2 =>
You see that I don't have iface from 212.36.8 network but just a route to
it (that is an example I know taht I can set netmask /23 but if other net
is 193.xxx.xxx or something ?) and default gw is from that (212.36.8) net
(which ofcourse is directly reachable)(ofcourse there was a problem
setting that route before I write a patch which you commit (kern/27852))
And there is a problem whith setting route :
route add -host foo -iface bar
It set the GW to this host foo to be iface bar but not to route packet
throw this iface to host foo.If you want to set this route you should set
the lladdr of host foo in arp table by hand (in cisco routers you
should'n do it that way , there it's straight forward routine)
The right way (cisco's way) setting a route throw gw that is not
local(mean from it's subnet) to any iface but is direcly reachable should
be :
route add -host foo_gw -iface bar
route add -net foo_net foo-gw
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0107021534090.8303-100000>