Hi folks...

I'm having a problem with mrouted and v4-in-v4 tunnels that I need
some input on.

Some background -- I have a VPN comprised of several small networks.  The
routers for these networks are NetBSD systems which do all of the data
encryption before tunneling the packets over the Internet.  These small
network gateways are connected to one or more intermediate routers, also
running NetBSD.  These intermediate routers are fully cross-connected.

Routing on this VPN is being done with RIPv2.  In order to make this work,
the encrypted tunnels are done using gif interfaces and using ESP transport
mode between the two tunnel endpoints.  We can't use ESP tunnel mode
because it doesn't provide a network interface that the routing daemon likes
to have as a rounting handle.

These gif tunnel interfaces are set up as "unnumbered" point-to-point
links, i.e.:

fxp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:d0:b7:88:11:31
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.0.0.254 netmask 0xffffff00 broadcast 10.0.0.255

gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
        tunnel inet xx.xx.xx.xx --> xx.xx.xx.xx
        inet 10.0.0.254 -> 10.0.2.254 netmask 0xffffff00

gif1: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
        tunnel inet xx.xx.xx.xx --> xx.xx.xx.xx
        inet 10.0.0.254 -> 10.0.1.254 netmask 0xffffff00

..etc.

Now, when firing up mrouted, I get:

Aug 31 09:53:23 zzz mrouted[1388]: mrouted version 3.8
Aug 31 09:53:23 zzz mrouted[1388]: warning - ignoring fxp2, same subnet as fxp2
Aug 31 09:53:23 zzz mrouted[1388]: warning - ignoring gif0, same subnet as fxp2
Aug 31 09:53:23 zzz mrouted[1388]: warning - ignoring gif1, same subnet as fxp2
Aug 31 09:53:23 zzz mrouted[1388]: can't forward: only one enabled vif

I'm guessing I could probably bypass the check for "same subnet as" if
the interface is marked IFF_POINTOPOINT (make it deal with the "unnumbered"
point-to-point interface case), but I'm wondering how IGMP and the multicast
forwarding code are going to deal with this...

Note that I haven't really looked into the depths of this yet... I'm just
wanting to get some input before I go running off in the wrong direction :-)

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>