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,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
