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

[action] [PR:17052] [FRR][patch] Add encap type when building packet for FPM #17145

Merged
merged 1 commit into from
Nov 11, 2023

Conversation

mssonicbld
Copy link
Collaborator

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.

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012
  • 202106
  • 202111
  • 202205
  • 202211
  • 202305

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

…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.
@mssonicbld
Copy link
Collaborator Author

Original PR: #17052

@mssonicbld mssonicbld merged commit 94b520b into sonic-net:202305 Nov 11, 2023
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants