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

Reply via email to