-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Wrong NHRP Resolution Reply packet from spoke to spoke when NHRP Authentication is enabled #16507
Closed
2 tasks done
Labels
triage
Needs further investigation
Comments
@dleroy @volodymyrhuti Can you look at it? |
It seems that the issue is in a duplicate NHRP Authentication Extension field in this packet. |
To clarify this is not fixed by #16480 ? |
#16480 does not fix this issue. |
garyachy
added a commit
to garyachy/frr
that referenced
this issue
Sep 12, 2024
When an NHRP peer was forwarding a message, it was copying all extensions from the originally received packet. The authentication extension must be regenerated hop by hop per RFC2332. This fix checks for the auth extension when copying extensions and omits the original packet auth and instead regenerates a new auth extension. Fix bug FRRouting#16507 Signed-off-by: Denys Haryachyy <[email protected]>
mergify bot
pushed a commit
that referenced
this issue
Sep 13, 2024
When an NHRP peer was forwarding a message, it was copying all extensions from the originally received packet. The authentication extension must be regenerated hop by hop per RFC2332. This fix checks for the auth extension when copying extensions and omits the original packet auth and instead regenerates a new auth extension. Fix bug #16507 Signed-off-by: Denys Haryachyy <[email protected]> (cherry picked from commit 8e3c278)
mergify bot
pushed a commit
that referenced
this issue
Sep 13, 2024
When an NHRP peer was forwarding a message, it was copying all extensions from the originally received packet. The authentication extension must be regenerated hop by hop per RFC2332. This fix checks for the auth extension when copying extensions and omits the original packet auth and instead regenerates a new auth extension. Fix bug #16507 Signed-off-by: Denys Haryachyy <[email protected]> (cherry picked from commit 8e3c278)
mergify bot
pushed a commit
that referenced
this issue
Sep 13, 2024
When an NHRP peer was forwarding a message, it was copying all extensions from the originally received packet. The authentication extension must be regenerated hop by hop per RFC2332. This fix checks for the auth extension when copying extensions and omits the original packet auth and instead regenerates a new auth extension. Fix bug #16507 Signed-off-by: Denys Haryachyy <[email protected]> (cherry picked from commit 8e3c278)
This was referenced Sep 13, 2024
mergify bot
pushed a commit
that referenced
this issue
Sep 13, 2024
When an NHRP peer was forwarding a message, it was copying all extensions from the originally received packet. The authentication extension must be regenerated hop by hop per RFC2332. This fix checks for the auth extension when copying extensions and omits the original packet auth and instead regenerates a new auth extension. Fix bug #16507 Signed-off-by: Denys Haryachyy <[email protected]> (cherry picked from commit 8e3c278)
choppsv1
pushed a commit
to LabNConsulting/frr
that referenced
this issue
Sep 14, 2024
When an NHRP peer was forwarding a message, it was copying all extensions from the originally received packet. The authentication extension must be regenerated hop by hop per RFC2332. This fix checks for the auth extension when copying extensions and omits the original packet auth and instead regenerates a new auth extension. Fix bug FRRouting#16507 Signed-off-by: Denys Haryachyy <[email protected]>
zice312963205
pushed a commit
to wenwang00/frr
that referenced
this issue
Nov 28, 2024
When an NHRP peer was forwarding a message, it was copying all extensions from the originally received packet. The authentication extension must be regenerated hop by hop per RFC2332. This fix checks for the auth extension when copying extensions and omits the original packet auth and instead regenerates a new auth extension. Fix bug FRRouting#16507 Signed-off-by: Denys Haryachyy <[email protected]>
zice312963205
pushed a commit
to wenwang00/frr
that referenced
this issue
Nov 28, 2024
When an NHRP peer was forwarding a message, it was copying all extensions from the originally received packet. The authentication extension must be regenerated hop by hop per RFC2332. This fix checks for the auth extension when copying extensions and omits the original packet auth and instead regenerates a new auth extension. Fix bug FRRouting#16507 Signed-off-by: Denys Haryachyy <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
I have tested 6186368 in the lab wich was described in #16371. It works if VyOS as hub and Cisco as Spokes.
I added to my lab FRR as a Spoke with NHRP Authentication. And I got an issue.
I have tested without NHRP Authentication and did not get this issue.
FRR HUB and CISCO SPOKE configuration exists in #16371
FRR SPOKE configuration
Netfilter:
FRR:
Interfaces
I collect tcpdumps of NHRP packets with NHRP Authentication and without NHRP Authentication on Cisco SPOKE side.
authnhrp.dmp
noauthnhrp.dmp
Version
How to reproduce
The main part of the lab exists in #16371
addition was described in the description part
Expected behavior
SPOKES must have direct conversations. It works without NHRP Authentication.
Actual behavior
Cisco SPOKE sends an NHRP Error Indication Packet as a behavior on receiving the NHRP Resolution Reply packet from FRR as a SPOKE. As a result, Cisco SPOKE does not add routes to its routing table.
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: