Date: Mon, 2 Jul 2001 15:26:31 +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: <20010702152631.C77685@sunbay.com> In-Reply-To: <Pine.BSF.4.21.0107021312150.8303-100000@shadow.otel.net>; from tbyte@tbyte.org on Mon, Jul 02, 2001 at 01:16:19PM %2B0300 References: <20010702130910.A77685@sunbay.com> <Pine.BSF.4.21.0107021312150.8303-100000@shadow.otel.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) 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?20010702152631.C77685>