Re: rtadvd bug ?
Le 17/06/2018 à 22:57, Sebastian Benoit a écrit :
you have to do check
if (rtm->rtm_flags & RTF_CONNECTED)
The priority of a connected route depends on the interface priority,
see ifconfig(8) on the priority option and wifi and carp interfaces have a
different default prio than other interfacs. So the prio is not an indicator
for the type of the route.
/Benno
/* sanity check for plen */
/* as RFC2373, prefixlen is at least 4 */
if (plen < 4 || plen > 127) {
Hello,
The patch indeed prevent including ospf6d-learned route to be advertised
by rtadvd, as priority is 32 (RTP_OSPF).
I had to add a check on RTM_DELETE: case too, as ospf6d add (an remove)
routes on itself, see this:
fremen# route -n show -inet6|grep ac42
2a01:e35:8aea:ac42::/642a01:e35:8aea:ac42:200:24ff:fed1:420d
UCn12 - 4 em1
2a01:e35:8aea:ac42::/64link#2 UC
00 -32 em1
2a01:e35:8aea:ac42:200:24ff:fed1:420d is em1 address.
without checking priority on RTM_DELETE, stopping ospf6d removes all
prefixes ...
checking rtm_flags & RTF_CONNECTED works too, as Sebastien said.
dhcpv6-pd works regardless of the check (I run it on this router).
--
Bastien
Re: rtadvd bug ?
Be careful not to break dhcpv6-pd.
I suspect the problem is actually in make_prefix() in config.c which
unconditionally sets
onlink and autoconf.
I stared at this for some time but can't figure out how to fix this.
RFC 4861 has this which I don't think rtadvd is implementing correctly:
Prefix Information
These options specify the prefixes that are on-link
and/or are used for stateless address
autoconfiguration. A router SHOULD include all its
on-link prefixes (except the link-local prefix) so
that multihomed hosts have complete prefix
information about on-link destinations for the
links to which they attach. If complete
information is lacking, a host with multiple
interfaces may not be able to choose the correct
outgoing interface when sending traffic to its
neighbors.
On Sun, Jun 17, 2018 at 10:57:57PM +0200, Sebastian Benoit wrote:
> Hi,
>
> Denis Fondras(open...@ledeuns.net) on 2018.06.17 21:45:37 +0200:
> > On Mon, Jun 11, 2018 at 10:13:36AM +0200, Bastien Durel wrote:
> > > Because it's lower than RTP_CONNECTED and I don't know what it is. The
> > > /* local address routes (must be the highest) */ comment makes me think
> > > it MAY be 127.0.0.0/8 or ::1/128 (useless for rtadvd then), but it may
> > > be related to interface addresses; I did not check in the kernel code
> > > how this flag is set. (hence the question marks)
> > >
> >
> > RTP_LOCAL are local addresses, they won't pass the test at L367 of rtadvd.c
> > anyway.
> >
> > Here is a diff if you want to try :
> >
> > Index: if.c
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/if.c,v
> > retrieving revision 1.46
> > diff -u -p -r1.46 if.c
> > --- if.c12 Aug 2017 07:38:26 - 1.46
> > +++ if.c17 Jun 2018 19:37:55 -
> > @@ -285,6 +285,14 @@ get_ifm_flags(char *buf)
> > return (ifm->ifm_flags);
> > }
> >
> > +u_char
> > +get_priority(char *buf)
> > +{
> > + struct rt_msghdr *rtm = (struct rt_msghdr *)buf;
> > +
> > + return (rtm->rtm_priority);
> > +}
> > +
> > int
> > get_prefixlen(char *buf)
> > {
> > Index: if.h
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/if.h,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 if.h
> > --- if.h10 Aug 2017 19:07:14 - 1.14
> > +++ if.h17 Jun 2018 19:37:55 -
> > @@ -45,6 +45,7 @@ struct in6_addr *get_addr(char *);
> > int get_rtm_ifindex(char *);
> > int get_ifm_ifindex(char *);
> > int get_ifam_ifindex(char *);
> > +u_char get_priority(char *);
> > int get_ifm_flags(char *);
> > int get_prefixlen(char *);
> > int prefixlen(u_char *, u_char *);
> > Index: rtadvd.c
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/rtadvd.c,v
> > retrieving revision 1.91
> > diff -u -p -r1.91 rtadvd.c
> > --- rtadvd.c22 Aug 2017 01:44:09 - 1.91
> > +++ rtadvd.c17 Jun 2018 19:37:55 -
> > @@ -309,7 +309,7 @@ rtsock_cb(int fd, short event, void *arg
> > {
> > int n, type, ifindex = 0, oldifflags, plen;
> > char *rtm;
> > - u_char ifname[IF_NAMESIZE];
> > + u_char ifname[IF_NAMESIZE], prio;
> > struct prefix *prefix;
> > struct rainfo *rai;
> > struct in6_addr *addr;
> > @@ -362,6 +362,11 @@ rtsock_cb(int fd, short event, void *arg
> >
> > addr = get_addr(rtm);
> > plen = get_prefixlen(rtm);
> > + prio = get_priority(rtm);
> > +
> > + if (!(prio & RTP_CONNECTED))
> > + break;
> > +
>
>
> you have to do check
>
> if (rtm->rtm_flags & RTF_CONNECTED)
>
> The priority of a connected route depends on the interface priority,
> see ifconfig(8) on the priority option and wifi and carp interfaces have a
> different default prio than other interfacs. So the prio is not an indicator
> for the type of the route.
>
> /Benno
>
> > /* sanity check for plen */
> > /* as RFC2373, prefixlen is at least 4 */
> > if (plen < 4 || plen > 127) {
> >
>
> --
>
--
I'm not entirely sure you are real.
Re: rtadvd bug ?
Hi,
Denis Fondras(open...@ledeuns.net) on 2018.06.17 21:45:37 +0200:
> On Mon, Jun 11, 2018 at 10:13:36AM +0200, Bastien Durel wrote:
> > Because it's lower than RTP_CONNECTED and I don't know what it is. The
> > /* local address routes (must be the highest) */ comment makes me think
> > it MAY be 127.0.0.0/8 or ::1/128 (useless for rtadvd then), but it may
> > be related to interface addresses; I did not check in the kernel code
> > how this flag is set. (hence the question marks)
> >
>
> RTP_LOCAL are local addresses, they won't pass the test at L367 of rtadvd.c
> anyway.
>
> Here is a diff if you want to try :
>
> Index: if.c
> ===
> RCS file: /cvs/src/usr.sbin/rtadvd/if.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 if.c
> --- if.c 12 Aug 2017 07:38:26 - 1.46
> +++ if.c 17 Jun 2018 19:37:55 -
> @@ -285,6 +285,14 @@ get_ifm_flags(char *buf)
> return (ifm->ifm_flags);
> }
>
> +u_char
> +get_priority(char *buf)
> +{
> + struct rt_msghdr *rtm = (struct rt_msghdr *)buf;
> +
> + return (rtm->rtm_priority);
> +}
> +
> int
> get_prefixlen(char *buf)
> {
> Index: if.h
> ===
> RCS file: /cvs/src/usr.sbin/rtadvd/if.h,v
> retrieving revision 1.14
> diff -u -p -r1.14 if.h
> --- if.h 10 Aug 2017 19:07:14 - 1.14
> +++ if.h 17 Jun 2018 19:37:55 -
> @@ -45,6 +45,7 @@ struct in6_addr *get_addr(char *);
> int get_rtm_ifindex(char *);
> int get_ifm_ifindex(char *);
> int get_ifam_ifindex(char *);
> +u_char get_priority(char *);
> int get_ifm_flags(char *);
> int get_prefixlen(char *);
> int prefixlen(u_char *, u_char *);
> Index: rtadvd.c
> ===
> RCS file: /cvs/src/usr.sbin/rtadvd/rtadvd.c,v
> retrieving revision 1.91
> diff -u -p -r1.91 rtadvd.c
> --- rtadvd.c 22 Aug 2017 01:44:09 - 1.91
> +++ rtadvd.c 17 Jun 2018 19:37:55 -
> @@ -309,7 +309,7 @@ rtsock_cb(int fd, short event, void *arg
> {
> int n, type, ifindex = 0, oldifflags, plen;
> char *rtm;
> - u_char ifname[IF_NAMESIZE];
> + u_char ifname[IF_NAMESIZE], prio;
> struct prefix *prefix;
> struct rainfo *rai;
> struct in6_addr *addr;
> @@ -362,6 +362,11 @@ rtsock_cb(int fd, short event, void *arg
>
> addr = get_addr(rtm);
> plen = get_prefixlen(rtm);
> + prio = get_priority(rtm);
> +
> + if (!(prio & RTP_CONNECTED))
> + break;
> +
you have to do check
if (rtm->rtm_flags & RTF_CONNECTED)
The priority of a connected route depends on the interface priority,
see ifconfig(8) on the priority option and wifi and carp interfaces have a
different default prio than other interfacs. So the prio is not an indicator
for the type of the route.
/Benno
> /* sanity check for plen */
> /* as RFC2373, prefixlen is at least 4 */
> if (plen < 4 || plen > 127) {
>
--
Re: rtadvd bug ?
On Mon, Jun 11, 2018 at 10:13:36AM +0200, Bastien Durel wrote:
> Because it's lower than RTP_CONNECTED and I don't know what it is. The
> /* local address routes (must be the highest) */ comment makes me think
> it MAY be 127.0.0.0/8 or ::1/128 (useless for rtadvd then), but it may
> be related to interface addresses; I did not check in the kernel code
> how this flag is set. (hence the question marks)
>
RTP_LOCAL are local addresses, they won't pass the test at L367 of rtadvd.c
anyway.
Here is a diff if you want to try :
Index: if.c
===
RCS file: /cvs/src/usr.sbin/rtadvd/if.c,v
retrieving revision 1.46
diff -u -p -r1.46 if.c
--- if.c12 Aug 2017 07:38:26 - 1.46
+++ if.c17 Jun 2018 19:37:55 -
@@ -285,6 +285,14 @@ get_ifm_flags(char *buf)
return (ifm->ifm_flags);
}
+u_char
+get_priority(char *buf)
+{
+ struct rt_msghdr *rtm = (struct rt_msghdr *)buf;
+
+ return (rtm->rtm_priority);
+}
+
int
get_prefixlen(char *buf)
{
Index: if.h
===
RCS file: /cvs/src/usr.sbin/rtadvd/if.h,v
retrieving revision 1.14
diff -u -p -r1.14 if.h
--- if.h10 Aug 2017 19:07:14 - 1.14
+++ if.h17 Jun 2018 19:37:55 -
@@ -45,6 +45,7 @@ struct in6_addr *get_addr(char *);
int get_rtm_ifindex(char *);
int get_ifm_ifindex(char *);
int get_ifam_ifindex(char *);
+u_char get_priority(char *);
int get_ifm_flags(char *);
int get_prefixlen(char *);
int prefixlen(u_char *, u_char *);
Index: rtadvd.c
===
RCS file: /cvs/src/usr.sbin/rtadvd/rtadvd.c,v
retrieving revision 1.91
diff -u -p -r1.91 rtadvd.c
--- rtadvd.c22 Aug 2017 01:44:09 - 1.91
+++ rtadvd.c17 Jun 2018 19:37:55 -
@@ -309,7 +309,7 @@ rtsock_cb(int fd, short event, void *arg
{
int n, type, ifindex = 0, oldifflags, plen;
char *rtm;
- u_char ifname[IF_NAMESIZE];
+ u_char ifname[IF_NAMESIZE], prio;
struct prefix *prefix;
struct rainfo *rai;
struct in6_addr *addr;
@@ -362,6 +362,11 @@ rtsock_cb(int fd, short event, void *arg
addr = get_addr(rtm);
plen = get_prefixlen(rtm);
+ prio = get_priority(rtm);
+
+ if (!(prio & RTP_CONNECTED))
+ break;
+
/* sanity check for plen */
/* as RFC2373, prefixlen is at least 4 */
if (plen < 4 || plen > 127) {
Re: rtadvd bug ?
Le samedi 09 juin 2018 à 19:23 +0200, Denis Fondras a écrit : > On Thu, Jun 07, 2018 at 04:02:34PM +0200, Bastien Durel wrote: > > shouldn't it check the rtm_priority to be RTP_LOCAL or > > RTP_CONNECTED ?? > > it make no sense to start advertising prefix on an interface if the > > prefix is over a gateway. > > > > Why RTP_LOCAL ? > Because it's lower than RTP_CONNECTED and I don't know what it is. The /* local address routes (must be the highest) */ comment makes me think it MAY be 127.0.0.0/8 or ::1/128 (useless for rtadvd then), but it may be related to interface addresses; I did not check in the kernel code how this flag is set. (hence the question marks) -- Bastien Durel
Re: rtadvd bug ?
On Thu, Jun 07, 2018 at 04:02:34PM +0200, Bastien Durel wrote: > shouldn't it check the rtm_priority to be RTP_LOCAL or RTP_CONNECTED ?? > it make no sense to start advertising prefix on an interface if the > prefix is over a gateway. > Why RTP_LOCAL ?
Re: rtadvd bug ?
Le mercredi 06 juin 2018 à 17:11 +0200, Bastien Durel a écrit : > Le mercredi 06 juin 2018 à 13:55 +0200, Bastien Durel a écrit : > > Hello, > > > > I run rtadvd on a router, which also run ospfd (on 6.3). > > [...] > > if an ospf neighbour start advertising a new network (in my case > > 2001:41d0:fe4b:ecf1::/64), a route is inserted in the kernel: > > > > fremen# route -n show -inet6|grep ecf1 > > 2001:41d0:fe4b:ecf1::/64 fe80::225:22ff:fe1e:bb7%em1U > > G > > 0 594 -32 em1 > > but rtadvd starts advertising it on the link with the said > > neighbour. > > [...] I looked at the code, and see rtadvd monitors the routing table and add new prefix when new route appears. shouldn't it check the rtm_priority to be RTP_LOCAL or RTP_CONNECTED ?? it make no sense to start advertising prefix on an interface if the prefix is over a gateway. I can always put a -s in rtadvd_flags for my use case, I'd prefer a fix ;) Thanks, -- Bastien Durel
Re: rtadvd bug ?
Le mercredi 06 juin 2018 à 13:55 +0200, Bastien Durel a écrit :
> Hello,
>
> I run rtadvd on a router, which also run ospfd (on 6.3).
>
> rtadvd runs with static config (noifprefix):
> fremen# cat /etc/rtadvd.conf
> em0:\
> :rdnss="2a01:e35:8aea:ac42::10":\
> :dnssl="geekwu.org":\
> :addr0="2001:41d0:fe4b:ec21::":\
> :addr1="2a01:0e35:8aea:ac41::":\
> :noifprefix:
> em1:\
> :rdnss="2a01:e35:8aea:ac42::10":\
> :dnssl="geekwu.org":\
> :addr0="2a01:e35:8aea:ac42::":\
> :addr1="2001:41d0:fe4b:ec42::":\
> :noifprefix:
> em5:\
> :rdnss="2001:41d0:fe4b:ec42::10":\
> :dnssl="geekwu.org":\
> :addr0="2a01:e35:8aea:ac43::":\
> :noifprefix:
> em4:\
> :rdnss="2001:41d0:fe4b:ec42::10":\
> :dnssl="geekwu.org":\
> :addr="2001:41d0:fe4b:ecff::":\
> :noifprefix:
>
> if an ospf neighbour start advertising a new network (in my case
> 2001:41d0:fe4b:ecf1::/64), a route is inserted in the kernel:
>
> fremen# route -n show -inet6|grep ecf1
> 2001:41d0:fe4b:ecf1::/64 fe80::225:22ff:fe1e:bb7%em1UG
> 0 594 -32 em1
> but rtadvd starts advertising it on the link with the said neighbour.
>
> I get this from radvdump running on a Linux host on this link:
> #
> # radvd configuration generated by radvdump 2.17
> # based on Router Advertisement from fe80::8621:df60:6d70:8da
> # received by interface enp2s0
> #
>
> interface enp2s0
> {
> AdvSendAdvert on;
> # Note: {Min,Max}RtrAdvInterval cannot be obtained with
> radvdump
> AdvManagedFlag off;
> AdvOtherConfigFlag off;
> AdvReachableTime 0;
> AdvRetransTimer 0;
> AdvCurHopLimit 64;
> AdvDefaultLifetime 1800;
> AdvHomeAgentFlag off;
> AdvDefaultPreference medium;
> AdvSourceLLAddress on;
>
> prefix 2a01:e35:8aea:ac42::/64
> {
> AdvValidLifetime 2592000;
> AdvPreferredLifetime 604800;
> AdvOnLink on;
> AdvAutonomous on;
> AdvRouterAddr off;
> }; # End of prefix definition
>
>
> prefix 2001:41d0:fe4b:ec42::/64
> {
> AdvValidLifetime 2592000;
> AdvPreferredLifetime 604800;
> AdvOnLink on;
> AdvAutonomous on;
> AdvRouterAddr off;
> }; # End of prefix definition
>
>
> prefix 2001:41d0:fe4b:ecf1::/64
> {
> AdvValidLifetime 2592000;
> AdvPreferredLifetime 604800;
> AdvOnLink on;
> AdvAutonomous on;
> AdvRouterAddr off;
> }; # End of prefix definition
>
>
> RDNSS 2a01:e35:8aea:ac42::10
> {
> AdvRDNSSLifetime 900;
> }; # End of RDNSS definition
>
>
> DNSSL geekwu.org
> {
> AdvDNSSLLifetime 900;
> }; # End of DNSSL definition
>
> }; # End of interface definition
>
> Why does rtadvd start advertising this prefix ?
> If I withdraw the prefix from ospf, rtadvd stops advertising it.
>
BTW, radvd emits this log when the prefix is inserted into ospf
rtadvd[33784]: prefix 2001:41d0:fe4b:ecf1::/64 from fe80::225:22ff:fe1e:bb7 on
em1 is not in our list
--
Bastien
rtadvd bug ?
Hello,
I run rtadvd on a router, which also run ospfd (on 6.3).
rtadvd runs with static config (noifprefix):
fremen# cat /etc/rtadvd.conf
em0:\
:rdnss="2a01:e35:8aea:ac42::10":\
:dnssl="geekwu.org":\
:addr0="2001:41d0:fe4b:ec21::":\
:addr1="2a01:0e35:8aea:ac41::":\
:noifprefix:
em1:\
:rdnss="2a01:e35:8aea:ac42::10":\
:dnssl="geekwu.org":\
:addr0="2a01:e35:8aea:ac42::":\
:addr1="2001:41d0:fe4b:ec42::":\
:noifprefix:
em5:\
:rdnss="2001:41d0:fe4b:ec42::10":\
:dnssl="geekwu.org":\
:addr0="2a01:e35:8aea:ac43::":\
:noifprefix:
em4:\
:rdnss="2001:41d0:fe4b:ec42::10":\
:dnssl="geekwu.org":\
:addr="2001:41d0:fe4b:ecff::":\
:noifprefix:
if an ospf neighbour start advertising a new network (in my case
2001:41d0:fe4b:ecf1::/64), a route is inserted in the kernel:
fremen# route -n show -inet6|grep ecf1
2001:41d0:fe4b:ecf1::/64 fe80::225:22ff:fe1e:bb7%em1UG 0
594 -32 em1
but rtadvd starts advertising it on the link with the said neighbour.
I get this from radvdump running on a Linux host on this link:
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::8621:df60:6d70:8da
# received by interface enp2s0
#
interface enp2s0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;
prefix 2a01:e35:8aea:ac42::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
prefix 2001:41d0:fe4b:ec42::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
prefix 2001:41d0:fe4b:ecf1::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
RDNSS 2a01:e35:8aea:ac42::10
{
AdvRDNSSLifetime 900;
}; # End of RDNSS definition
DNSSL geekwu.org
{
AdvDNSSLLifetime 900;
}; # End of DNSSL definition
}; # End of interface definition
Why does rtadvd start advertising this prefix ?
If I withdraw the prefix from ospf, rtadvd stops advertising it.
Thanks,
Bastien
dmesg:
OpenBSD 6.3 (GENERIC.MP) #3: Fri May 18 00:06:26 CEST 2018
r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 519962624 (495MB)
avail mem = 497184768 (474MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.08 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 600MHz, 600.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI
mpbios0: bus 64 is type ISA
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x4115 rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 19,
version 1.0
ohci1 at pci2 dev 2
rtadvd bug ?
Hello,
I run rtadvd on a router, which also run ospfd (on 6.3).
rtadvd runs with static config (noifprefix):
fremen# cat /etc/rtadvd.conf
em0:\
:rdnss="2a01:e35:8aea:ac42::10":\
:dnssl="geekwu.org":\
:addr0="2001:41d0:fe4b:ec21::":\
:addr1="2a01:0e35:8aea:ac41::":\
:noifprefix:
em1:\
:rdnss="2a01:e35:8aea:ac42::10":\
:dnssl="geekwu.org":\
:addr0="2a01:e35:8aea:ac42::":\
:addr1="2001:41d0:fe4b:ec42::":\
:noifprefix:
em5:\
:rdnss="2001:41d0:fe4b:ec42::10":\
:dnssl="geekwu.org":\
:addr0="2a01:e35:8aea:ac43::":\
:noifprefix:
em4:\
:rdnss="2001:41d0:fe4b:ec42::10":\
:dnssl="geekwu.org":\
:addr="2001:41d0:fe4b:ecff::":\
:noifprefix:
if an ospf neighbour start advertising a new network (in my case
2001:41d0:fe4b:ecf1::/64), a route is inserted in the kernel:
fremen# route -n show -inet6|grep ecf1
2001:41d0:fe4b:ecf1::/64 fe80::225:22ff:fe1e:bb7%em1UG
0 594 -32 em1
but rtadvd starts advertising it on the link with the said neighbour.
I get this from radvdump running on a Linux host on this link:
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::8621:df60:6d70:8da
# received by interface enp2s0
#
interface enp2s0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;
prefix 2a01:e35:8aea:ac42::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
prefix 2001:41d0:fe4b:ec42::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
prefix 2001:41d0:fe4b:ecf1::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
RDNSS 2a01:e35:8aea:ac42::10
{
AdvRDNSSLifetime 900;
}; # End of RDNSS definition
DNSSL geekwu.org
{
AdvDNSSLLifetime 900;
}; # End of DNSSL definition
}; # End of interface definition
Why does rtadvd start advertising this prefix ?
If I withdraw the prefix from ospf, rtadvd stops advertising it.
Thanks,
Bastien
dmesg:
OpenBSD 6.3 (GENERIC.MP) #3: Fri May 18 00:06:26 CEST 2018
r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 519962624 (495MB)
avail mem = 497184768 (474MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.08 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 600MHz, 600.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI mpbios0: bus 64 is type ISA ioapic0 at
mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x4115
rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ohci1 at pci2 dev 2
