On Wed, Jul 18, 2018 at 11:03:46AM +0200, Sebastien Marie wrote:
> On Wed, Jul 18, 2018 at 08:54:51AM +0200, Florian Obser wrote:
> > During g2k18 I commited rad(8).
> > 
> > The latest amd64 and i386 snapshots should contain it with enough
> > features to replace rtadvd(8). If you are using rtadvd(8) I'd
> > appreciate if you could switch to rad(8) and report back if any
> > features are missing.
> > 
> > The plan is to unhook rtadvd(8) from the build sooner rather than
> > later and to ship 6.4 with rad(8) only.
> > 
> 
> Hi,
> 
> I switched my gateway to use rad instead of rtadvd.

thank you for testing!

> 
> So, some questions :-)
> 
> First the topology:
> - internet connection on pppoe0
> - 2 lan interfaces with ipv6: vlan92 and vlan110
> 
> I obtain ipv6 on pppoe0 with DHCPv6-PD.
> 
> My upstream send me also router-advertisement on this interface.
> 
> tcpdump output:
>       fe80::2a6f:7fff:fe0e:ae80 > ff02::1: icmp6: router 
> advertisement(chlim=64, O, pref=medium, router_ltime=1800, reachable_time=0, 
> retrans_time=0)(mtu: mtu=1492)(rdnss: lifetime=400s, 
> addr=XXXX:XXXX:XXXX:XXXX::1, addr=XXXX:XXXX:XXXX:XXXX::1) [icmp6 cksum ok] 
> [class 0xe0] (len 64, hlim 255) 
> 
> 
> On the gateway, I use the following rad.conf file:
> 
> interface vlan92 {
>         dns {
>                 resolver "XXXX:XXXX:XXXX:XX5c:cabe:19ff:fee2:2ced"
>         }
> }
> 
> interface vlan110 {
>         dns {
>                 resolver "XXXX:XXXX:XXXX:XX6e:cabe:19ff:fee2:2ced"
>         }
> }
> 
> 
> $ ifconfig vlan92
> vlan92: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
>         lladdr c8:be:19:e2:2c:ed
>         index 16 priority 0 llprio 3
>         encap: vnetid 92 parent re0
>         groups: vlan
>         media: Ethernet autoselect (1000baseT full-duplex)
>         status: active
>         inet 192.168.92.2 netmask 0xffffff00 broadcast 192.168.92.255
>         inet6 fe80::7f08:c8d1:d9fd:1581%vlan92 prefixlen 64 scopeid 0x10
>         inet6 XXXX:XXXX:XXXX:XX5c:cabe:19ff:fee2:2ced prefixlen 64
>         inet6 XXXX:XXXX:XXXX:XX5c::1 prefixlen 64 pltime 599160 vltime 2586360
> 
> For now, it works well. But I see the following in syslog:
> 
> Jul 18 10:28:05 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan92               # from itself
> Jul 18 10:28:06 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan110      # from itself
> Jul 18 10:29:24 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0               # not managed interface
> Jul 18 10:31:12 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::f280:16b4:9c3b:5f8f on vlan92       
> Jul 18 10:32:19 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0               # not managed interface
> Jul 18 10:33:33 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan92               # from itself
> Jul 18 10:35:28 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0               # not managed interface
> Jul 18 10:36:49 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan110      # from itself
> Jul 18 10:38:04 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0               # not managed interface
> Jul 18 10:40:08 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan92               # from itself
> Jul 18 10:40:47 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0               # not managed interface
> Jul 18 10:41:58 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::61fd:ac94:2a15:bd0b on vlan92

I just switched the log_warnx to log_debug, that was an oversight on
my part, this is mostly normal operation

> 
> rad(8) seems to log RA/RS from all interfaces:
> - from interface not configured for being managed by itself, like pppoe0
> - from interface managed by itself and RA sent by itself (shouldn't it
>   know it sent it ?)

Yes, and it should not receive them. I believe this is the
IPV6_MULTICAST_LOOP socketopt missing on the icmp6 socket.
I'll probably fix it this evening.

> - from interface managed by itself and RA/RS sent by someone else
> 
> I am unsure about the purpose of this log: it seems to be an
> unconditional log on RA/RS reception.
> 
> It could have value for RA/RS where it isn't sent by rad(8) itself, and
> if it is on some configured interface for rad(8). For others cases, I am
> unsure.

rad(8) receiving RAs on all interfaces is for future work. As said
above, it doesn't need to see it's own RAs, but all the others.

Router advertisement messages are supposed to contain all prefixes
this router knows about. Hosts can form addresses from some of these
prefixes (iff the A flag is set) or add more specific routes for
others.

Let's assume a slightly different topology. Assume you have a two
routers, one on vlan92 and one on vlan110 and their upstream
interfaces are connected to a switch together with your ISP's gateway:


                +--------------+
             +--+em0 R1 vlan110|
             |  +--------------+
+--------+   |
|ISP wan0+---+
+--------+   |
             |  +--------------+
             +--+em0 R2 vlan92 |
                +--------------+

R1 and R2 do DHCPv6-PD on their own for their respective vlan interfaces.
Now, if a host behind R1 wants to talk to a host behind R2 the traffic
will go host1 -> R1 -> isp -> R2 -> host2

What should happen is that R1 (and R2) announce their prefixes on em0
as well without the A flag set. The other router can then install a
more specific and traffic will not go to the default gateway.

This is not implemented in rad(8) yet. rtadvd(8) has parts of this
implemented but I believe it does it wrong (see "rtadvd bug ?" on
misc). One problem is that rtadvd sets the A flag on each and every
prefix, no matter where it comes from. So hosts suddenly start to form
addresses from prefixes that are not onlink.

(alternatively you could run another dynamic routing protocol like ospf6d).

Hope this helps.

> 
> Thanks for the clarification.
> -- 
> Sebastien Marie
> 

-- 
I'm not entirely sure you are real.

Reply via email to