radvd icon indicating copy to clipboard operation
radvd copied to clipboard

controlling the LLA used by radvd for RAs

Open Supermathie opened this issue 4 years ago • 1 comments

TL;DR: We are running into a situation where radvd is picking the source IP for outgoing advertisements that don't want it to use.

radvd version: 2.17, debian package 1:2.17-2

Our setup:

  • each server has a globally routable /64 network configured on a local bridge (for docker containers)
  • this network is advertised to other servers via radvd:
    interface int {
        AdvDefaultLifetime 0;
        AdvSendAdvert on;
        MaxRtrAdvInterval 12;
        route 2001:db8:f00:d2::/64 {
            AdvRouteLifetime 900;
        };
    };
    
  • our edge servers also have this but also have a VRRP IP configured for outbound traffic
  • IPv6 VRRP requires the first address in a VRRP group be an LLA for the VRRP router (we choose fe80::ffff:ff here)
     inet6 fe80::ffff:ff/64 scope link nodad
        valid_lft forever preferred_lft forever
     inet6 fe80::5054:ff:feed:f5a6/64 scope link
        valid_lft forever preferred_lft forever
    

The end result that we want to change is:

  • radvd chooses the fe80::ffff:ff address for its advertisements instead of fe80::5054:ff:feed:f5a6

This is bad for us since that's a VIP and can move between machines.

Things we've tried:

  • changing the VRRP configuration so that the address is /128 and marked as deprecated:
     inet6 fe80::ffff:ff/128 scope link nodad deprecated
        valid_lft forever preferred_lft 0sec
     inet6 fe80::5054:ff:feed:f5a6/64 scope link
        valid_lft forever preferred_lft forever
    
    result: no change; fe80::ffff:ff is still picked as the outbound address

Any suggestions here to accomplish what we want with radvd as-is?

Can we tell radvd to use a specific address as the advertisement source for this route?

Should it be modified to not choose deprecated or /128 addresses as the source for advertisements?

Supermathie avatar Nov 20 '20 18:11 Supermathie

#127 will help with this issue, but probably further work is needed, as you also want to avoid /128 addresses, and that code is driven by lifetime, not the /128 or the deprecated flag (which can be present even with a high lifetime)

robbat2 avatar Jan 25 '21 00:01 robbat2