Impossible to add static route via interface

[ppikh]

Description

Impossible to add static route via interface, for example via Vlan interface or Ethernet.

Steps to reproduce the issue:

1. sudo config vlan add 40
2. sudo config vlan member add 40 Ethernet0
3. sudo config route add prefix 1.2.3.4/32 nexthop dev Vlan40

Describe the results you received:

Command in step 3 failed, static route not added.

Usage: config route add [OPTIONS] prefix [vrf <vrf_name>] <A.B.C.D/M> nexthop
                        <[vrf <vrf_name>] <A.B.C.D>>|<dev <dev_name>>
Try "config route add -h" for help.

Error: interface Vlan40 doesn`t exist

Describe the results you expected:

Command passed, static route added successfully. Static route available in "show ip route" output

Output of show version:

SONiC Software Version: SONiC.master.638-ea803257
Distribution: Debian 10.9
Kernel: 4.19.0-12-2-amd64
Build commit: ea803257
Build date: Sat May 15 07:55:09 UTC 2021
Built by: johnar@jenkins-worker-2

Platform: x86_64-mlnx_msn2410-r0
HwSKU: ACS-MSN2410
ASIC: mellanox
ASIC Count: 1
Serial Number: MT1921X01546
Uptime: 14:15:25 up  3:23,  1 user,  load average: 4.39, 6.91, 6.91

Docker images:
REPOSITORY                    TAG                   IMAGE ID            SIZE
docker-syncd-mlnx             latest                6712ad2ec159        672MB
docker-syncd-mlnx             master.638-ea803257   6712ad2ec159        672MB
docker-snmp                   latest                0e8c17057014        448MB
docker-snmp                   master.638-ea803257   0e8c17057014        448MB
docker-teamd                  latest                a8839ff37a7f        418MB
docker-teamd                  master.638-ea803257   a8839ff37a7f        418MB
docker-nat                    latest                6107f1cd36dc        420MB
docker-nat                    master.638-ea803257   6107f1cd36dc        420MB
docker-router-advertiser      latest                881f7ccd3c98        407MB
docker-router-advertiser      master.638-ea803257   881f7ccd3c98        407MB
docker-platform-monitor       latest                7e26a28eb2d2        704MB
docker-platform-monitor       master.638-ea803257   7e26a28eb2d2        704MB
docker-lldp                   latest                a89cf79099ac        447MB
docker-lldp                   master.638-ea803257   a89cf79099ac        447MB
docker-dhcp-relay             latest                48d1ae3862c4        414MB
docker-dhcp-relay             master.638-ea803257   48d1ae3862c4        414MB
docker-database               latest                ab94b14802a3        407MB
docker-database               master.638-ea803257   ab94b14802a3        407MB
docker-orchagent              latest                3c9d5bdc0511        436MB
docker-orchagent              master.638-ea803257   3c9d5bdc0511        436MB
docker-macsec                 latest                9280c796c856        421MB
docker-macsec                 master.638-ea803257   9280c796c856        421MB
docker-sonic-telemetry        latest                4f4075abc928        496MB
docker-sonic-telemetry        master.638-ea803257   4f4075abc928        496MB
docker-sonic-mgmt-framework   latest                4a9a608e9924        627MB
docker-sonic-mgmt-framework   master.638-ea803257   4a9a608e9924        627MB
docker-fpm-frr                latest                c7a625c2f4c8        436MB
docker-fpm-frr                master.638-ea803257   c7a625c2f4c8        436MB
docker-sflow                  latest                882158712b3c        419MB
docker-sflow                  master.638-ea803257   882158712b3c        419MB

Output of show techsupport:

[sonic_dump_r-spider-05_20210518_141021.tar.gz](https://github.com/Azure/sonic-buildimage/files/6502000/sonic_dump_r-spider-05_20210518_141021.tar.gz)

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

Issue looks like caused by commit: sonic-net/sonic-utilities#1534

[liat-grozovik]

@d-dashkov could you please check this one? the above flow worked before, not it is not.
if we decide to change behaviour as part of this commit lets make sure it is aligned and we communicate it properly.

[prsunny]

Agree that it might have been working before when called directly via vtysh, but just curious, what is the use-case here, for a route pointing to L2 Vlan?

[anshuv-mfst]

Hi @d-dashkov - this is related to #1619, please assign the issue to yourself, thanks.