Page MenuHomeVyOS Platform

Denest IPv6 router-advert from Interfaces to general service
Closed, ResolvedPublicFEATURE REQUEST


rewrite/replace vyatta-ipv6-rtradv


Difficulty level
Hard (possibly days)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Improvement (missing useful functionality)

Event Timeline

hagbard triaged this task as Normal priority.
hagbard created this task.
hagbard changed Difficulty level from Unknown (require assessment) to Hard (possibly days).

How is it planned to implement this in the new style configuration? As own service bound to interfaces (denest) or as part of an interface?

Yes, I think set service ra interface ... or something like that might be the best option. That would eliminate the template generator script all together and I was thinking to remove interface by interface from the generator, as the rewrite progresses.
Since it needs a migrator script for each interface then as well, even if the option are the same.

aone migrator for all interfaces is sufficient (see mew bridge interface and migrator 0-to-1 in interfaces)

On the other hand it still can live in the interface directly which would spare the migrator. VLANs are a good example - I‘ve written a common function to parse it in each interface. I am not fully convinced on any implementation be it under an interface or as dedicated service.

Other vendors like cisco place it under each and every interface.

Also the XML definition could live in a central place and included as e.g. via GCC preprocessor so it is defined only once though. It eliminates a lot of duplicated information. Makefile then can piece it together.

Btw, doesnt FRR come with RA,too?

@dmbaturin advice?

Hmm, that's actually a good point ( I started with implementing it as service, it has the advantage that you don't have the duplicated template code. I would lean the towards implementing it for frr rather then using radvd. I currently have set service ipv6-ra interface eth3 ... as CLI path which I would stay with, or should it then be moved into protocol? I'll focus on implementing it for frr, since the CLI path is different the current as well as a new implementation could coexist for testing so we can find the best way out.

very basic example (uses default paramaters):

 service {
+    ipv6-ra {
+        interface eth3 {
+            disable
+            prefix 2001:db8:cafe:beef::/64 {
+            }
+            prefix 2001:db8:dead:beef::/64 {
+            }
+        }
+    }

syning against frr ist the harder part compared to rewriting a conf file and restart radvd or stop is if all configs are removed. I'll try to get it done using frr, if it's in a new path anyway it won't really matter. If it works well, it would give us the advantage of a) remove radvd entirely from the iso and b) having a central backend.

  • What other nodes will be unter the prefix tagNode?
  • How would namesevrers be configured?

Currently I use:

vyos@vyos# show interfaces ethernet eth0 vif 500 | strip-private
 address xxxx:xxxx:200:50::FFFF/64
 ipv6 {
     dup-addr-detect-transmits 1
     router-advert {
         cur-hop-limit 64
         link-mtu 0
         managed-flag true
         max-interval 600
         other-config-flag false
         prefix xxxx:xxxx:200:50::/64 {
             autonomous-flag true
             on-link-flag true
             valid-lifetime 2592000
         reachable-time 0
         retrans-timer 0
         send-advert true

I just have a gut feeling its better suited under the interface instead of a dedicated service. For FRR, have a look into the BFD implementation

You can announce multiple prefixes with different options. If you leave for each interface all the options need to be generated (like it is right now), or manually setup or generate for vyos-1x. Also you need to consider that you may send RAs on vif and stuff like that only. dup-addr-detect-transmits has not real anything to do with sending RAs.

DNS and DNSSL is basically encapsulated into the interface defintion.
set service ipv6-ra interface ethx dssl (tagnode) and teh same for DNS.

This comment was removed by hagbard.

I just tested frr sending RAs, setup manually which works quite well. So, now it needs the determined what path it should go (stay in interface or move out to service) and if we go with frr for it or stay with radvd. I would be in favor of frr.

If FRR has all we need we should use it - drops one additional dependency

Yup, I tested almost all parameters we have currently in our cli, works all quite well. So, I'm going to implement it under service then?

Personally I would keep it under the interface itself but @dmbaturin should have the final decission

hagbard changed the task status from Open to On hold.Dec 3 2019, 9:30 PM
hagbard renamed this task from radvd rewrite to FRR: implementation ipv6 RAs via FRR.Dec 11 2019, 4:09 PM
hagbard changed the status of subtask T1832: radvd adding feature DNSSL to existing package from Needs testing to Backport candidate.
hagbard changed the task status from On hold to In progress.Dec 13 2019, 7:46 PM

current hop limit is per default set to 64, but can't be set in frr while is was/is possible for radvd. I'd propose to use the the frr options only and not using the current existing ones, that way migration will become easier since the option 'current hop limit' could be just skipped and removed during migration.
Any ideas? Or should we stay with radvd for that purpose?
I would only do it for 1.3 and not backport into 1.2-rolling.


hagbard changed the task status from In progress to On hold.Dec 16 2019, 7:57 PM

Turns out that it might not be a smart move to keep it under interfaces, as it would have to implemented within the ethernet script or if it's a separate one, it needs to be called with VYOS_TAGNODE_VALUE, otherwise there won't be a way to find out what interface needs to be configured. If placed under service or any other path, it can be integrated into the config itself e.g. set service ipv6-ra interface eth0 <more options>, set service ipv6-ra interface eth1 <more options> etc.
That would only required to parse and compare configs for 2 interfaces which can be determined from the config.

end: sudo sh -c "VYOS_TAGNODE_VALUE='$VAR(../../@)' ${vyos_conf_scripts_dir}/" would have to be in /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/ipv6/router-advert/node.def
I can set that statically, which removes then the benefit for the use of other passes, IPv6 RAs can be sent over quite some interfaces.

c-po renamed this task from FRR: implementation ipv6 RAs via FRR to Denest IPv6 router-advert from Interfaces to general service.Mar 24 2020, 1:56 PM
c-po claimed this task.
c-po updated the task description. (Show Details)
c-po changed Version from - to 1.3-rolling.
c-po changed the task status from On hold to Needs testing.Mar 24 2020, 6:53 PM
c-po reopened this task as Needs testing.
c-po moved this task from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
c-po updated the task description. (Show Details)
erkin set Issue type to Improvement (missing useful functionality).Aug 31 2021, 6:13 PM