[201811] [radvd] Build radvd from source; Patch so as not to treat out-of-range MTU as an error

[jleveque]

- What I did

• Download radvd source from Debian repo, apply a patch such that if radvd finds a MTU value in the config file which is out-of-range (i.e., greater than MTU configured in the kernel for that interface), it will not treat it as an error. Thus, radvd _will_send router advertisements on the interface and it will also not continually reload its config file and spam the syslog with error messages. This is a temporary workaround until we are able to properly configure the MTU value in the kernel. [Root problem is that when any member interfaces are added/removed from a VLAN, the kernel sets the VLAN's MTU to the default value, 1500, which is smaller than our expected MTU, 9100]

NOTE: This patch is essentially the same as the patch for the 201803 branch (#2552)

- How to verify it

• Ensure router advertisements are sent on VLAN interfaces within the configured interval (currently 10 minutes):

root@sonic:/home/admin# tcpdump -nevvv -i Vlan1000 ip6 -Qout
tcpdump: listening on Vlan1000, link-type EN10MB (Ethernet), capture size 262144 bytes
01:40:57.877994 ec:f4:bb:fe:80:90 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 118: (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::eef4:bbff:fefe:8090 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 64
        hop limit 64, Flags [managed], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2603:10a0:312:140b::/64, Flags [onlink], valid time infinity, pref. time infinity
            0x0000:  4080 ffff ffff ffff ffff 0000 0000 2603
            0x0010:  10a0 0312 140b 0000 0000 0000 0000
          mtu option (5), length 8 (1):  9100
            0x0000:  0000 0000 238c
          source link-address option (1), length 8 (1): ec:f4:bb:fe:80:90
            0x0000:  ecf4 bbfe 8090
01:49:46.898809 ec:f4:bb:fe:80:90 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 118: (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::eef4:bbff:fefe:8090 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 64
        hop limit 64, Flags [managed], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2603:10a0:312:140b::/64, Flags [onlink], valid time infinity, pref. time infinity
            0x0000:  4080 ffff ffff ffff ffff 0000 0000 2603
            0x0010:  10a0 0312 140b 0000 0000 0000 0000
          mtu option (5), length 8 (1):  9100
            0x0000:  0000 0000 238c
          source link-address option (1), length 8 (1): ec:f4:bb:fe:80:90
            0x0000:  ecf4 bbfe 8090
02:01:52.348106 ec:f4:bb:fe:80:90 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 118: (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::eef4:bbff:fefe:8090 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 64
        hop limit 64, Flags [managed], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2603:10a0:312:140b::/64, Flags [onlink], valid time infinity, pref. time infinity
            0x0000:  4080 ffff ffff ffff ffff 0000 0000 2603
            0x0010:  10a0 0312 140b 0000 0000 0000 0000
          mtu option (5), length 8 (1):  9100
            0x0000:  0000 0000 238c
          source link-address option (1), length 8 (1): ec:f4:bb:fe:80:90
            0x0000:  ecf4 bbfe 8090

[lguohan]

do we have this for the master branch?

[jleveque]

@lguohan: PR for master branch: #2795