Radvd sending advertisement even though deactivated

Hi,
I'm running OpenWrt 19.07.1 on an Edgerouter X.
There are several downstream interfaces. For my lan interface IPv6 Router Advertisements are activated and work beautifully.
On another downstream interface though (DMZ) IPv6 Router Advertisements or DHCPv6 server is completely disabled since I configure addresses statically.
Regardless the Router sends a Router Advertisement package every 10 minutes out on the DMZ interface, anouncing the prefix from the LAN if wtf :dizzy_face:
I'm completely stuck and do not understand how this can happen.

network config:


config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd07:7b79:7577::/48'

config interface 'lan'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '10.10.101.199'
	option ip6assign '64'
	option ip6hint '1b'
	option ifname 'eth0.5'

config device 'lan_dev'
	option name 'eth0.1'
	option macaddr 'fc:ec:da:7b:37:98'

config interface 'wan'
	option ifname 'eth0.99'
	option proto 'pppoe'
	option username 'user'
	option password 'pw'
	option service 'ISP'
	option ipv6 'auto'

config device 'wan_dev'
	option name 'eth0.2'
	option macaddr 'fc:ec:da:7b:37:99'

config interface 'wan6'
	option proto 'dhcpv6'
	option ifname 'eth0.99'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option vid '5'
	option ports '6t 2t 1'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '99'
	option ports '6t 0'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '41'
	option ports '6t 4'

config switch_vlan
	option device 'switch0'
	option vlan '4'
	option vid '42'
	option ports '6t 3'

config switch_vlan
	option device 'switch0'
	option vlan '5'
	option vid '43'
	option ports '6t'

config interface 'down1'
	option type 'bridge'
	option proto 'static'
	option ifname 'eth0.41'
	option ipaddr '10.10.102.33'
	option netmask '255.255.255.224'
	option ip6assign '64'

config interface 'down2'
	option type 'bridge'
	option proto 'static'
	option ifname 'eth0.42'
	option ipaddr '10.10.102.65'
	option netmask '255.255.255.224'
	option ip6assign '64'

config interface 'down3'
	option type 'bridge'
	option proto 'static'
	option ifname 'eth0.43'

config interface 'site2site'
	option proto 'none'
	option ifname 'tun0'

config interface 'wan62'
	option proto 'static'
	list ip6addr '2001:1111:af0e:2222::1111'
	option ifname 'pppoe-wan'

config switch_vlan
	option device 'switch0'
	option vlan '6'
	option ports '6t 2t'
	option vid '13'

config interface 'DMZ'
	option proto 'static'
	option ifname 'eth0.13'
	option ipaddr '10.10.133.1'
	option ip6assign '64'
	option netmask '255.255.255.0'
	option ip6hint '5000'

config switch_vlan
	option device 'switch0'
	option vlan '7'
	option ports '6t 2t'
	option vid '10'

config interface 'FFWAN'
	option ifname 'eth0.10'
	option proto 'static'
	option ip6assign '64'
	option ip6hint '6002'
	option ipaddr '10.10.151.254'
	option netmask '255.255.255.0'

config interface 'wan_wg'
	option ifname 'pppoe-wan'
	option proto 'static'
	list ip6addr '2001:1111:af0e:2222::a0ae'

config wireguard_Roadwarrior
	option public_key 'bla='
	option description 'pixel'
	list allowed_ips '2001:1111:2222::2'
	option endpoint_port '51820'

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option localservice '1'
	option rebind_protection '0'
	list server '213.123.112.60'
	list server '2001:1111:100:1020:53:2:0:2'
	list server '194.8.114.60'
	list server '2001:1111:100:1020:53:2:0:1'
	option domain 'sub.domain.net'
	option local '/sub.domain.net/'
	option serversfile '/tmp/adb_list.overall'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv6 'server'
	option ra 'server'
	option ra_management '1'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'down1'
	option start '100'
	option leasetime '12h'
	option limit '150'
	option interface 'down1'
	option ra 'server'
	option dhcpv6 'server'
	option ra_management '1'

config dhcp 'down2'
	option start '100'
	option leasetime '12h'
	option limit '150'
	option interface 'down2'
	option ra 'server'
	option dhcpv6 'server'
	option ra_management '1'

config domain
	option name 'filer'
	option ip '10.10.101.101'

config dhcp 'FFWAN'
	option interface 'FFWAN'
	option ra 'server'
	list dns '2001:1111:100:1234:53:2:0:2'
	list dns '2001:1111:100:1234:53:2:0:1'
	option dhcpv6 'server'
	option ra_management '1'
	option ignore '1'

config dhcp 'DMZ'
	option start '100'
	option leasetime '12h'
	option limit '150'
	option interface 'DMZ'

config host
	option duid '000450b4a99282050aed6629e2cab65e9acc'
	option dns '1'
	option name 'xps13'
	option mac '34:13:E8:53:E6:F2'
	option leasetime '24h'
	option ip '10.10.101.188'
	option hostid '123'

config interface 'DMZ'
	option ip6assign '64'
	option ip6hint '5000'

This configuration is delegating my downstream interface an IP like this:
my prefix:5000::1/64
It's called DHCPv6 Prefix Delegation. It has nothing to do with NDP or Router Advertisement.
And even if it would send out Router Advertisements, why would it use the network identifier of another Interface at all?

Ummmmm...

  1. it is sending them (as you say)
  2. because it's a router...how else would it tell it's upstream that there's in fact a subnet there?

...something called a "Router Advertisement" seems correct, doesn't it?

  • See if you can block that traffic; and if your ISP stops giving you a PD.
  • Check if you are receiving a Router Solicitation from the ISP - proper protocol requires your device to respond with an RA

See:

The devices in DMZ get their IP addresses configured manually, that's how they know.
It seems you don't understand the problem actually.

Let's just look at the two downstream interfaces, allright?

  1. LAN having myprefix:1b::/64
  2. DMZ having myprefix:5000::/64

Hosts in DMZ are receiving Router Advertisements, ok. I deactivated the router to send Router Advertisements on that interfaces but hey, ok, it's a router - as you say.
But why the heck, does it announce myprefix:1b:: on DMZ??? I ran tcpdump on a client device and yes, it does receive those Advertisement from the router.
Here's a screenshot:

What does this have to do with a router sending a RA for a subnet it actually possesses, regardless of address assignment??? :thinking:

I understood that already.

I understood that too.

So you completely turned off/disabled this process, firewalled it (as I suggested) or what?

...and if so, how does DHCPv6 PD work on your device - which uses the same program?

I do say.

That's not what I asked; but OK. I'm asking if you see RS packets from whatever interface; but you keep saying you disabled RAs.

I hope you find out your problem, since you claim I don't understand.

Is this what you mean by "disabled"???? :man_facepalming:

Yes, you have disabled RAs to clients! :heavy_check_mark:

OK. It's not disabled. Please read the Wikipedia page.

OK, I read the Wikipedia page. It doesn't answer why I'm having this problem, well actually those two problems:

  1. Having OpenWrt sending RA even though it's deactivated and
  2. Sending RA with the wrong network ID.

With other routers like Cisco or Nokia it's no problem to deactivate RA on a downstream Interface at all. Are you trying to say with OpenWrt I cannot disable them?

OK, cool - thank you for reading the Wiki, I'll try my best to explain.

  • First, I believe you can disable them; but I don't believe you truly desire this.
  • You did disable "on a downstream interface"...I think you just want all packets to disappear, regardless of the protocol
  • The other issue (in my mind) is perhaps Cisco or Noika runs the DHCPv6-PD "magic" in another process than default OpenWrt software

I offered what I believe to be the easiest suggestions to troubleshoot:

  • Verify some NA, or RS, then maybe block them
  • Block TX of the RA

Not exactly.

I agree you want them to stop. So, can you try to actually disable the process odhcpd in System > Startup - reboot, and see if this is provides the affect you desire?

Again, I suggest the firewalling first; as I don't think the DHCPv6PD will work after truly disabling.

What do you actually mean by this?

I thought we covered this, that's untrue - disabling the process odhcpd should do that. In addition, you seem unwilling to identify the actual packets that prompt routers to respond with an RA.

Router Advertisements communicate a specific prefix to a client so they know within which prefix they shall claim themselves an IP address. For my lan interface for example an advertisement is sent with the prefix myprefix:1b::/64. As a result the clients will claim an IP like this:
myprefix:1b:34da:7d23:17af:2383
That's exactly what I want and is expected behaviour.

As OpenWrt sends such an advertisement not only on my LAN interface but also DMZ, clients within this DMZ domain also get these packages and assign themselves an IP. Well them getting an automatic IP per se is not the problem but the actual problem is that within the DMZ domain (which is 5000, not 1b) they also receive such packets with 1b instead of 5000 in the header. I strongly believe this is a bug, since I can't find a problem in my config whatsoever.
As a result my host in DMZ will get an IP myprefix:1b:x:y:z:1 which is 100% wrong, because those addresses belong to the LAN domain of my network. Thus, their IPv6 connectivity is completely lost because they try to communicate with that IP and that - of course - cannot work.

I could of course just block those packages at the clients but it's some kind of vicious circle because I run my network IPv6 only and I automatically deploy hosts with Ansible. The hosts are not reachable anymore that moment the host in DMZ receives a RA and assigns itself a wrong IP.

This is not necessarily true nor the only purpose of an RA packet; but I follow your statement...

I was gonna continue; but are we serious right now!?!?

Have you tried removing the invalid configuration in your network file then?

(I assume your OpenWrt also gets the wrong IP requesting on a "disabled" interface?)

What about my config is invalid? I'm totally serious about that.
On my upstream I get delegated a /48 prefix statically. The way I configure my downstream interface (DMZ) is perfectly legitimate.
Do you think I have to assign the IP on DMZ manually instead? I mean I could try that but that's not the way IPv6 is supposed to work. Prefix Delegation is a superb mechanism and I would like to use it.
Still, advertising 1b on DMZ is just wrong, even with my current configuration.

You're giving a hint and seeking a prefix on an interface you also want RAs disabled on - which you also state is statically assigned. You don't see the problem?

Okay.

Then you need no hints and prefixes, you just assign an IP (and obviously a prefix) in a /64, from the /48 - to the DMZ interface. If you have static assignments as you say, simply remove the dynamic configs if you don't want dynamic stuff on your DMZ. Let's test something to see if it actually stops.

OK, sure.

I think this is the crux of the matter. You want RAs but they should be for the prefix ...:5000 not ...:1b

Or if they are for 1b they should not have the onlink bit set, so they just inform your DMZ that they can reach 1b via the router

I do see the probem, which is the router sending RAs while it's actually deactivated for the downstream interface.

Yeah, that's another way of doing it, but the more cumbersome, since it's harder to deploy.
I just tested it though. Problem persists.

Yeah it is. A's a workaround I tried to disable RA for the DMZ interface completely which in the end just doesn not stop sending RAs. Maybe some people have another definition of "disabled" than I have :laughing:
I can't find anything in OpenWrt's documentation about onlink bit. Can you please point me?

You can't really expect to have ipv6 without RAs as far as I know. Even with static assignment I'm not sure what happens if a client does NDP asking for a router and the router doesn't respond.

But the thing you're seeing is NOT normal. Lots of people have multiple ipv6 subnets and don't get RAs for the wrong prefix on the wrong subnet. So, I'm not sure what's happening, but basically it's not normal, it's a specific bug in your setup somewhere.

I would also check that the trunk port that carries the LAN and DMZ vlans doesn't leak.
Is there any native vlan applied there?

1 Like

LAN2 is connected to switch port 1
See my vlan configuration attached.


This is the PVID of switch port 1:
vlan_pvid
this is vlan 5 setting of the switch:
vlan5
this is the vlan 13 setting of the switch:
vlan13_dmz

Install tcpdump on the router, if not already installed, and run the following.
tcpdump -xvvn -i eth0.13 icmp6 and ip6[40] == 134
Let it run till you get the packet captured and post here the output.

This problem still exists with git. But its buggier than described here: With several Vlan interfaces with different prefixes (hint), instantly after an "service dnsmasq restart" every vlan gets every prefix announced. Also the one which should not get RA at all
I tried with dnsmasq and odhcp, same result. But dnsmasq works less good: Even if dns-server announcement is disabled, it announces itself