Date: Mon, 2 Jul 2001 16:58:18 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Iasen Kostoff <tbyte@tbyte.org> Cc: net@FreeBSD.ORG Subject: Re: Indirect route with also indirect gateway Message-ID: <20010702165817.B96697@sunbay.com> In-Reply-To: <Pine.BSF.4.21.0107021534090.8303-100000@shadow.otel.net>; from tbyte@tbyte.org on Mon, Jul 02, 2001 at 04:34:40PM %2B0300 References: <20010702152631.C77685@sunbay.com> <Pine.BSF.4.21.0107021534090.8303-100000@shadow.otel.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 02, 2001 at 04:34:40PM +0300, Iasen Kostoff wrote: > > > 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: > [...] > default 212.36.8.129 UGSc 16 1612418 xl0 > 212.36.8 link#1 UCSc 28 0 xl0 => > This case indeed should be allowed. Your ``default'' route isn't with "indirect gateway", because the gateway route (route to 212.36.8.129) doesn't have the `G' flag set. An example of "indirect route with also indirect gateway" would be: # route -n get -net 10 route to: 10.0.0.0 destination: 10.0.0.0 mask: 255.0.0.0 gateway: 1.2.3.4 interface: rl0 flags: <UP,GATEWAY,DONE,STATIC,PRCLONING> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 # route -n get 1.2.3.4 route to: 1.2.3.4 destination: default mask: default gateway: 192.168.4.65 interface: rl0 flags: <UP,GATEWAY,DONE,STATIC,PRCLONING> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 Or, in netstat(1) equivalent: default 192.168.4.65 UGSc 4 0 rl0 10 1.2.3.4 UGSc 0 0 rl0 192.168.4.65 0:d0:b7:16:9c:c6 UHLW 3 4055 rl0 1108 I.e., the gateway for net 10 is 1.2.3.4, where 1.2.3.4 is *indirectly* reachable via the `default' route with gateway 192.168.4.65. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age 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?20010702165817.B96697>