[dhcp6relay][202012] dhcp_relay container is down due to the wrong generated config in config_db

[dgsudharsan]

Description

This is due to PR sonic-net/sonic-utilities#2336

config vlan dhcp_relay add 1679 2000:1::2 generates incorrect config in config_db
"VLAN": {
"Vlan1679": {
"dhcp_servers": [ <<< --- Mistake is here
"2000:1::2"
],
"vlanid": "1679"
}
},

Steps to reproduce the issue:

1. config vlan dhcp_relay add 1679 2000:1::2

Describe the results you received:

DHCP relay container is down

Describe the results you expected:

DHCP relay container shouldn't be down.

Output of show version:

SONiC Software Version: SONiC.202012_9_RC_1.3-23b38b2a7_Internal
Distribution: Debian 10.13
Kernel: 4.19.0-12-2-amd64
Build commit: 23b38b2a7
Build date: Thu Oct 20 14:37:15 UTC 2022
Built by: sw-r2d2-bot@r-build-sonic-ci03-244

Platform: x86_64-mlnx_msn3700-r0
HwSKU: ACS-MSN3700
ASIC: mellanox
ASIC Count: 1
Serial Number: MT1932X22252
Uptime: 19:01:13 up  1:39,  1 user,  load average: 0.49, 0.36, 0.30

Docker images:
REPOSITORY                    TAG                                  IMAGE ID            SIZE
docker-sonic-mgmt-framework   202012_9_RC_1.3-23b38b2a7_Internal   f15ae3c36ff5        702MB
docker-sonic-mgmt-framework   latest                               f15ae3c36ff5        702MB
docker-sflow                  202012_9_RC_1.3-23b38b2a7_Internal   14a7bf838b5f        388MB
docker-sflow                  latest                               14a7bf838b5f        388MB
docker-teamd                  202012_9_RC_1.3-23b38b2a7_Internal   65f2d1e5d307        387MB
docker-teamd                  latest                               65f2d1e5d307        387MB
docker-platform-monitor       202012_9_RC_1.3-23b38b2a7_Internal   93ab5161524c        694MB
docker-platform-monitor       latest                               93ab5161524c        694MB
docker-orchagent              202012_9_RC_1.3-23b38b2a7_Internal   16f6181893ac        403MB
docker-orchagent              latest                               16f6181893ac        403MB
docker-fpm-frr                202012_9_RC_1.3-23b38b2a7_Internal   257b74129626        405MB
docker-fpm-frr                latest                               257b74129626        405MB
docker-syncd-mlnx             202012_9_RC_1.3-23b38b2a7_Internal   7b48583e1b15        882MB
docker-syncd-mlnx             latest                               7b48583e1b15        882MB
docker-nat                    202012_9_RC_1.3-23b38b2a7_Internal   f9fde76c4e54        390MB
docker-nat                    latest                               f9fde76c4e54        390MB
docker-router-advertiser      202012_9_RC_1.3-23b38b2a7_Internal   7d76270820b9        375MB
docker-router-advertiser      latest                               7d76270820b9        375MB
docker-snmp                   202012_9_RC_1.3-23b38b2a7_Internal   faabcb106e2c        419MB
docker-snmp                   latest                               faabcb106e2c        419MB
docker-lldp                   202012_9_RC_1.3-23b38b2a7_Internal   962ff5ce0432        415MB
docker-lldp                   latest                               962ff5ce0432        415MB
docker-database               202012_9_RC_1.3-23b38b2a7_Internal   54229a1b34d0        375MB
docker-database               latest                               54229a1b34d0        375MB
docker-dhcp-relay             202012_9_RC_1.3-23b38b2a7_Internal   6b5db941d41f        389MB
docker-dhcp-relay             latest                               6b5db941d41f        389MB
docker-sonic-telemetry        202012_9_RC_1.3-23b38b2a7_Internal   aa4b3d1116c8        465MB
docker-sonic-telemetry        latest                               aa4b3d1116c8        465MB
docker-mux                    202012_9_RC_1.3-23b38b2a7_Internal   fd850eb0fa1c        428MB
docker-mux                    latest                               fd850eb0fa1c        428MB

Output of show techsupport:

(paste your output here or download and attach the file here )

Additional information you deem important (e.g. issue happens only occasionally):

sonic_dump_qa-eth-vt03-4-3700v_20221024_190100.tar.gz

[arlakshm]

@dgsudharsan add the details here. @yxieca to discuss with @kellyyeh

[dgsudharsan]

We do have dhcpv6_servers in master and 202205 as well

sonic-buildimage/dockers/docker-dhcp-relay/cli/config/plugins/dhcp_relay.py

Line 27 in 3058fb6

dhcpv6_servers = vlan.get('dhcpv6_servers', [])

Reverting it in 202012 will lead to functional issue. For now having dhcpv6_servers is not going to cause any issues and will help backward compatibility of show and config commands. Later when we have full CLI support to work properly with DHCP_RELAY table I suggest we can revert sonic-net/sonic-utilities@17284d0

[vivekrnv]

Few more details: From this commit, sonic-net/sonic-utilities#2271 the cli started to add even the ipv6 addresses to the dhcp_servers@ field and when there are only ipv6 addresses present under dhcp_servers@ field under a VLAN table, the supervisord.conf file is not properly generated from the template and is the reason why the container is down.

I understand the rationale why this was reverted in 202012. It’s because everything related to dhcpv6 only uses DHCP_RELAY table for now on and does require dhcpv6_servers field in the VLAN table. Reverting this PR would mean the address will be redirected to dhcpv6_servers@ field and since no one uses it it shouldn't cause any problems. An alternative would be to raise a different PR to 202012 to modify CLI which rejects ipv6 address.

However as Sudharsan pointed out, even the master & 202205 CLI code still has the logic to redirect the ipv6 address to dhcpv6_servers@ field, so i think reverting this sonic-net/sonic-utilities#2271 would keep the implementation consistent.