zebra: Add encap type when building packet for FPM #14675
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently in the single nexthop case w/ evpn sending down via the FPM the encap type is not being set for the nexthop. This looks like the result of some code reorg for the nexthop happened but the fpm failed to be accounted for. Let's just move the encap type encoding to where it will happen. Signed-off-by: Donald Sharp <[email protected]>
|
Placing a Do Not Merge as that I don't have easy ability to test this. Going to ask the person who indicated this to me to test it and once they say it's ready I'll remove the label |
|
@donaldsharp Tested this patch in SONiC and confirmed the issue is solved. Thanks |
|
ci:rerun |
mjstapp
approved these changes
Oct 30, 2023
|
@Mergifyio backport dev/9.1 |
✅ Backports have been created
|
|
CI:rerun |
riw777
approved these changes
Oct 31, 2023
11 tasks
donaldsharp
added a commit
that referenced
this pull request
Oct 31, 2023
zebra: Add encap type when building packet for FPM (backport #14675)
|
@Mergifyio backport stable/8.5 stable/9.0 |
✅ Backports have been created
|
This was referenced Nov 8, 2023
donaldsharp
added a commit
that referenced
this pull request
Nov 8, 2023
zebra: Add encap type when building packet for FPM (backport #14675)
donaldsharp
added a commit
that referenced
this pull request
Nov 8, 2023
zebra: Add encap type when building packet for FPM (backport #14675)
StormLiangMS
pushed a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Nov 11, 2023
Back port a patch from upstream FRR - FRRouting/frr#14675 Why I did it The EVPN route is not treated correctly and thus leading to messages: Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop 30.0.0.2@Vlan200 for 20.0.0.2/32, resolving neighbor Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop 30.0.0.2@Vlan200 for 200.0.0.0/24, resolving neighbor Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop ::ffff:30.0.0.2@Vlan200 for 200::/64, resolving neighbor Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop ::ffff:30.0.0.2@Vlan200 for 20::/64, resolving neighbor Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop ::ffff:30.0.0.2@Vlan200 for 20::2/128, resolving neighbor This happens because fpmsyncd does not get encap type field in FPM message. Work item tracking Microsoft ADO (number only): How I did it Backport fix from FRR. How to verify it EVPN scenario.
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Nov 11, 2023
…7052) Back port a patch from upstream FRR - FRRouting/frr#14675 Why I did it The EVPN route is not treated correctly and thus leading to messages: Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop 30.0.0.2@Vlan200 for 20.0.0.2/32, resolving neighbor Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop 30.0.0.2@Vlan200 for 200.0.0.0/24, resolving neighbor Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop ::ffff:30.0.0.2@Vlan200 for 200::/64, resolving neighbor Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop ::ffff:30.0.0.2@Vlan200 for 20::/64, resolving neighbor Oct 30 11:40:00.494083 r-tigris-22 INFO swss#orchagent: :- addRoute: Failed to get next hop ::ffff:30.0.0.2@Vlan200 for 20::2/128, resolving neighbor This happens because fpmsyncd does not get encap type field in FPM message. Work item tracking Microsoft ADO (number only): How I did it Backport fix from FRR. How to verify it EVPN scenario.
11 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently in the single nexthop case w/ evpn sending down via the FPM the encap type is not being set
for the nexthop.
This looks like the result of some code reorg for the nexthop happened but the fpm failed to be accounted for. Let's just move the encap type encoding to where it will happen.