Re: route command cannot set up route through point-to-point interface

[Sogabe Takashi <sogabe%iij.ad.jp@localhost>]

Technically, it is sufficient to create a route.

I think freebsd-route is more convenient to use routing protocols
such as quagga, xorp, etc.

For example,
- a. netbsd-route
  # ifconfig gif0 tunnel 10.0.0.1/24 10.0.0.2
  # ifconfig gif0 1.1.1.1/30 1.1.1.2
  # netstat -nrfinet
    Destination        Gateway        Flags ... Interface
    1.1.1.2            1.1.1.1        UH        gif0
    ...
  # route add -net 1.1.1.0/30 -iface -interface gif0
    route: bad value: gif0
  # route add -net 1.1.1.0/30 -iface -interface 1.1.1.2
  add net 1.1.1.0: gateway 1.1.1.2
  # netstat -nrfinet
    Destination        Gateway        Flags ... Interface
    1.1.1/30           1.1.1.2        US        gif0
    1.1.1.2            1.1.1.1        UH        gif0
    ...

- b. patched-route
  # ifconfig gif0 tunnel 10.0.0.1/24 10.0.0.2
  # ifconfig gif0 1.1.1.1/30

  (in quagga)
  # telnet localhost 2601
  > show ip route 1.1.1.0/30 longer-prefixes
    C>* 1.1.1.0/30 is directly connected, gif0

  # route add -net 1.1.1.0/30 -iface -interface gif0
  add net 1.1.1.0: gateway gif0
  # netstat -nrfinet
    Destination        Gateway        Flags ... Interface
    1.1.1/30                          US        gif0
    ...

In quagga-RIB, nexthop of 1.1.1.0/30 points to gif0, not 1.1.1.2.
Both route works well, but I think b. is more natural to describe.


> > Netbsd's route command seems to reject route through point-to-point
> > interface.
>
> That's odd; it's always worked fine for me.  Could you give a specific
> example, showing the configuraitno, the route command attempted, and
> the failure message?
>
> > I checked out difference of the source code between netbsd and
> > freebsd, and maked following patch.
>
> I'm guessing here, trying to reverse-engineer the behaviour you don't
> like from the patch, but it looks almost as though you're expecting to
> specify the _local_, not _remote_, address of the .2. interface on the
> route command.  If so, I'd say the bug is in your expectations; in
> other cases, the gateway given to route(8) is the (non-local) address
> of the next-hop machine, not an address on the local machine.

-
Takashi Sogabe (sogabe%iij.ad.jp@localhost)