arp entry is not learned on a vlan subinterface (dot1q tagged)

[maq123]

Hi,

I am trying to get ping working between a sonic switch and an external device.
I manually create vlan 30 subinterface with the following cmds:

ip link add link Ethernet4 name Ethernet4.30 type vlan id 30
ip link set dev Ethernet4.30 up
ip addr add 3.3.3.3/24 dev Ethernet4.30

Then issuing ping to the external host:

ping 3.3.3.1 -I Ethernet4.30

On the external host I see the following traffic, which confirms that it replies to Sonic's ARP request

root@OPX-S6000-ON:~# tcpdump -i e101-001-0.30 -nnn -v
tcpdump: listening on e101-001-0.30, link-type EN10MB (Ethernet), capture size 262144 bytes
14:18:54.446897 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 3.3.3.1 tell 3.3.3.3, length 50
14:18:54.446956 ARP, Ethernet (len 6), IPv4 (len 4), Reply 3.3.3.1 is-at ec:f4:bb:fb:d2:f9, length 28
14:18:55.447186 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 3.3.3.1 tell 3.3.3.3, length 50
14:18:55.447243 ARP, Ethernet (len 6), IPv4 (len 4), Reply 3.3.3.1 is-at ec:f4:bb:fb:d2:f9, length 28
^C

However Sonic does not process the reply, and arp table looks as the following:

root@sonic:/var/log# arp -a | grep 3.3.3.
? (3.3.3.1) at <incomplete> on Ethernet4.30

[vemulabalaji]

Hi,

Are you still observing this issue?
In my case ARP table is getting updated, but SONiC is not getting the ICMP Reply messages from HW.

Regards,
Balaji

[maq123]

hi,
yeah, this was in regard to older sonic version.
now trunking should work just fine and I have it running.
probably you misconfigured the stuff.

[mslocrian]

@maq123 , were you actually able to get dot1q subint working on sonic? I've tested this config on my switch, and it's not working for me. I don't know if it's a functioning feature of sonic at this time, or not.

If it is working for you, I would love to see your config.

For me, tcpdump is showing the ICMP packet go through tagged, an arp request from the other side, and the arp response go out untagged.

[maq123]

hi @mslocrian , yeah it worked.
What is your device and which SONIC version were you using this is the most important question.

1. Can you see the subinterface configured on the ASIC level, with respective ASIC vendor debug tools (I can help you with that I think)
2. Check the swss daemon logs once you apply the configuration, aren't there any errors?

I don't have a config file at hand at the moment, would need to check if I logged it somewhere.

[vemulabalaji]

Hi, I was trying on Mellanox platform, and subinterface is not getting synced to ASIC level. L2 VLAN interface is shown in HW. L3 VLAN interface is not shown in HW. So the when a packet is received on HW, the same is not lifted to control plane. root@test-bed-1:~# show version SONiC Software Version: SONiC.HEAD.798-afb0ed0 Distribution: Debian 9.6 Kernel: 4.9.0-7-amd64 Build commit: afb0ed0 Build date: Sun Nov 18 13:29:21 UTC 2018 Built by: johnar@jenkins-worker-4 Any pointers ? Regards, Balaji

…

On Thu, Jan 31, 2019 at 4:05 AM maq123 ***@***.***> wrote: hi @mslocrian <https://github.com/mslocrian> , yeah it worked. What is your device and which SONIC version were you using this is the most important question. 1. Can you see the subinterface configured on the ASIC level, with respective ASIC vendor debug tools (I can help you with that I think) 2. Check the swss daemon logs once you apply the configuration, aren't there any errors? I don't have a config file at hand at the moment, would need to check if I logged it somewhere. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Am5VfRoCJE6HTtk3HYrJSF5T-24GzEmzks5vIh4hgaJpZM4PXqVB> .

[mslocrian]

hi @mslocrian , yeah it worked.
What is your device and which SONIC version were you using this is the most important question.

1. Can you see the subinterface configured on the ASIC level, with respective ASIC vendor debug tools (I can help you with that I think)
2. Check the swss daemon logs once you apply the configuration, aren't there any errors?

I don't have a config file at hand at the moment, would need to check if I logged it somewhere.

Hi @maq123,

Thanks for replying!

I'm running on the x86_64-accton_as7712_32x-r0 with a build from 2 days ago (SONiC.add_frr_reload.0-dirty-20190128.181135 ... my own branch for another PR (sonic-net/sonic-buildimage#2462).)

Would you be able to point me in the right direction for the vendor debug tools? This asic debugging is something I'm not very familiar with. In knowing that, I can work towards seeing if changes are pushed further down.

Currently I'm not seeing any swss log updates ( from tail -f /var/log/swss/*.rec). Other logs under /var/log are pretty uninteresting as well.

Thanks for your pointers on this one. Looking forward to learning how to dig into low level asic stuff!

[mslocrian]

I should also say, that at the time when I initially responded to the ticket, I was running a build that was also a couple of days old (from master). I haven't tried to replicate the issue over this latest build that I'm running, but I anticipate similar issues.

Learning how to utilize tools to debug asic level stuff would probably be the best path forward in seeing if changes are getting propagated. I'll be able to come back with some better information.

thanks!

[maq123]

hi @mslocrian, I don't have the SONIC switch at hand so I will write down what I have in my notes:

Try running the following command bcmcmd 'l2 show' This should show you VLANs associated with a physical interface.
Also you should not inspect the *.rec files. The files where the actual errors regarding the asic api are is /var/log/swss/sairedis.rec, you may grep it by 'orchagent' keyword. Once you configure the vlans and apply the config you should see some info regarding this stuff being configured into your switch's asic.