-
Notifications
You must be signed in to change notification settings - Fork 537
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
[orchagent]: VXLAN: Fix oper_status and tunnel encapsulation TTL #3383
base: master
Are you sure you want to change the base?
Conversation
1cd531b
to
603980f
Compare
This fixes 2 issues across a range of open tickets building upon patches created by others with modifications as requested by @VladimirKuk. The first issue this resolves is the status shown for remote vteps which in the fact that it is wrong makes debugging nearly impossible: ``` +------------+------------+-------------------+--------------+ | SIP | DIP | Creation Source | OperStatus | +============+============+===================+==============+ | 172.16.0.1 | 172.16.0.2 | EVPN | oper_down | +------------+------------+-------------------+--------------+ Total count : 1 ``` The VTEP is really up. Original PR for that is sonic-net#2080. Also fixes sonic-net/sonic-buildimage#10004 or at least the error message which hurts debugging. The next issue is in reachabiity across VXLANs. This fixes IP/MAC learning via ARP. The original PR for that is sonic-net#3216, however it appears it has its origins in sonic-net/sonic-buildimage#10050 which goes into greater detail about the issue itself. Also there is talk about it here kamelnetworks/sonic#9 as well as another similar patch here: kamelnetworks@02ee3e3 Fixes sonic-net#3216 Fixes sonic-net#2080 Fixes sonic-net/sonic-buildimage#10050 Fixes sonic-net/sonic-buildimage#10004 Signed-off-by: Brad House (@bradh352)
603980f
to
75c4f03
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
@VladimirKuk any idea if those test failures are actually a symptom of the patch itself? Or is it just common for things to fail in the tests from time to time? |
Tests do fail from time to time. |
@prsunny please review |
Thank you for pushing this forward! |
@prsunny ping |
What I did
This fixes 2 issues across a range of open tickets building upon patches created by others with modifications as requested by @VladimirKuk.
The first issue this resolves is the status shown for remote vteps which in the fact that it is wrong makes debugging nearly impossible:
The remote VTEP is really up.
Original PR for that is #2080.
Also fixes sonic-net/sonic-buildimage#10004 or at least the error message which hurts debugging.
The next issue is in reachabiity across VXLANs. This fixes IP/MAC learning via ARP. The original PR for that is #3216, however it appears it has its origins in
sonic-net/sonic-buildimage#10050 which goes into greater detail about the issue itself. Also there is talk about it here kamelnetworks/sonic#9 as well as another similar patch here: kamelnetworks@02ee3e3
Why I did it
Fixes #3216
Fixes #2080
Fixes sonic-net/sonic-buildimage#10050
Fixes sonic-net/sonic-buildimage#10004
How I verified it
Pulled into my private sonic-swss fork:
https://github.com/bradh352/sonic-swss/commits/202405-broadcom
Which is pulled in by my private sonic-buildimage fork:
https://github.com/bradh352/sonic-buildimage/tree/202405-broadcom
Which is then automatically built when changes are made. Then the uploaded asset of sonic-broadcom.bin is installed onto Dell S5248F and N3248TE switches and tested.
Details if related
Signed-off-by: Brad House (@bradh352)
This should also be backported to 202405