On Mon, 2 Jul 2001, Ruslan Ermilov wrote:
> 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.
>
>
Yes the gateway should be directly reachable throw interface.
And I'm agree that this indirect gateway should be disallowed by some
error message like : "gateway is not direcly reachable" or something.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
