Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
maq123 opened this issue Sep 14, 2017 · 8 comments
Open

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

maq123 opened this issue Sep 14, 2017 · 8 comments

Comments

@maq123
Copy link

maq123 commented Sep 14, 2017

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
Copy link

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
Copy link
Author

maq123 commented Jul 3, 2018

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
Copy link

@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
Copy link
Author

maq123 commented Jan 30, 2019

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
Copy link

vemulabalaji commented Feb 1, 2019 via email

@mslocrian
Copy link

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
Copy link

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
Copy link
Author

maq123 commented Feb 5, 2019

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.

sachinholla pushed a commit to sachinholla/SONiC that referenced this issue Jul 2, 2021
PIM HLD Minor updates (Yang changes updates & show cmds spacing updates)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants