[intfmgr] Fix OA crash issue due to link local configurations

[zhenggen-xu]

[intfmgr] Fix OA crash issue due to link local configurations

Signed-off-by: Zhenggen Xu [email protected]

This should be backported to 201811 and 201911.

What I did
Fix OA crash issue due to link local configurations.
In this PR, it will not send the link local configurations towards AppDB as it was configured on HW by default.

Why I did it
In case we have ipv6 link local configuration in configDB, it will crash OA.

How I verified it
configuration:

    "VLAN_INTERFACE": {
        "Vlan100|10.11.10.1/26": {
            "family": "IPv4", 
            "scope": "global"
        }, 
        "Vlan100|2000:11:10::1/64": {
            "family": "IPv6", 
            "scope": "global"
        }, 
        "Vlan100|fe80::1/10": {
            "family": "IPv6", 
            "scope": "local"
        }, 
        "Vlan777|10.11.77.1/26": {
            "family": "IPv4", 
            "scope": "global"
        }, 
        "Vlan777|2000:11:77::1/64": {
            "family": "IPv6", 
            "scope": "global"
        }, 
        "Vlan777|fe80::1/10": {
            "family": "IPv6", 
            "scope": "local"
        }
    }, 

Before fix:

Feb 12 00:15:56.615576 sonic ERR swss#orchagent: :- meta_sai_validate_route_entry: object key SAI_OBJECT_TYPE_ROUTE_ENTRY:{"dest":"fe80::/10","switch_id":"oid:0x21000000000000","vr":"oid:0x300000000
0022"} already exists
Feb 12 00:15:56.615682 sonic ERR swss#orchagent: :- addSubnetRoute: Failed to create subnet route to fe80::/10 from Vlan100, rv:-6
Feb 12 00:15:56.616068 sonic INFO swss#supervisord: orchagent terminate called after throwing an instance of '
Feb 12 00:15:56.621355 sonic INFO swss#supervisord: orchagent std::runtime_error'
Feb 12 00:15:56.621534 sonic INFO swss#supervisord: orchagent   what():  Failed to create subnet route.
Feb 12 00:15:56.621625 sonic INFO swss#supervisord: orchagent 

admin@sonic:~$ redis-cli 
127.0.0.1:6379> keys INT*
1) "INTF_TABLE:Vlan100:10.11.10.1/26"
2) "INTF_TABLE:Vlan100:2000:11:10::1/64"
3) "INTF_TABLE:Vlan777:2000:11:77::1/64"
4) "INTF_TABLE:Vlan100:fe80::1/10"
5) "INTF_TABLE:lo:2000:0:1::1/128"
6) "INTF_TABLE:Vlan777:fe80::1/10"
7) "INTF_TABLE:lo:10.0.1.1/32"
8) "INTF_TABLE_KEY_SET"
9) "INTF_TABLE:Vlan777:10.11.77.1/26"
127.0.0.1:6379> 

After fix:
No crash was seen.

127.0.0.1:6379> keys INTF*
 1) "INTF_TABLE:Vlan100:10.11.10.1/26"
 2) "INTF_TABLE:Vlan100:2000:11:10::1/64"
 3) "INTF_TABLE:Vlan777:2000:11:77::1/64"
 4) "INTF_TABLE:Ethernet116:10.2.1.1/31"
 5) "INTF_TABLE:lo:2000:0:1::1/128"
 6) "INTF_TABLE:Ethernet112:2000:1:1::2/126"
 7) "INTF_TABLE:lo:10.0.1.1/32"
 8) "INTF_TABLE:Vlan777:10.11.77.1/26"
 9) "INTF_TABLE:Ethernet116:2000:2:1::2/126"
10) "INTF_TABLE:Ethernet112:10.1.1.1/31"

Details if related

[prsunny]

Doesn't this fail in kernel as well as it would already have a LL address?

[zhenggen-xu]

Doesn't this fail in kernel as well as it would already have a LL address?

Thanks for reviewing. We need the LL configuration goes to kernel for the interfaces and it won't fail since it is just configuring the interfaces. The OA crash issue was due to fe80::/10 on HW we added by default, and we don't want to do that again in OA by LL configurations.

[prsunny]

@zhenggen-xu , my question is for the interface in kernel, it would already have a link-local address right? So are you trying to configure the same thing? or is it a different link-local address?

[zhenggen-xu]

@zhenggen-xu , my question is for the interface in kernel, it would already have a link-local address right? So are you trying to configure the same thing? or is it a different link-local address?

The link local generated by kernel is already there. We are configuring additional link local address like this "fe80::1/10" for other purpose. Kernel has no issues to handle multiple link local addresses on the same interface.

sudo ifconfig Vlan100
Vlan100: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.11.10.1  netmask 255.255.255.192  broadcast 10.11.10.63
        inet6 2000:11:10::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::2e0:ecff:fe51:5c61  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::1  prefixlen 10  scopeid 0x20<link>
        ether 00:e0:ec:51:5c:61  txqueuelen 1000  (Ethernet)
        RX packets 1807664  bytes 594255986 (566.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1900896  bytes 2106398723 (1.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[zhenggen-xu]

@prsunny Can we get this merged?

[zhenggen-xu]

retest vs please

[prsunny]

Yes, @zhenggen-xu , will wait for tests to be complete

[prsunny]

@zhenggen-xu , can you rebase to latest, not sure why some checks are not completing

[zhenggen-xu]

@zhenggen-xu , can you rebase to latest, not sure why some checks are not completing

I think that must be a different issue. My take is, if no conflicts, the CI pipeline should just pick the diff and apply to the latest code anyways, so rebase from forked repo should not be needed.

[zhenggen-xu]

retest this please

[zhenggen-xu]

@prsunny