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

Wrong NHRP Resolution Reply packet from spoke to spoke when NHRP Authentication is enabled #16507

Closed
2 tasks done
aapostoliuk opened this issue Jul 31, 2024 · 4 comments · Fixed by #16808
Closed
2 tasks done
Labels
triage Needs further investigation

Comments

@aapostoliuk
Copy link
Contributor

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.

  1. I try to generate traffic from SPOKE (FRR) to SPOKE(CISCO)
  2. At first everything went well. I saw NHR Traffic Indiation packets. NHRP Resolution Request packets. And NHRP Resolution Reply packets with code=Success.
  3. But the last NHRP Resolution Reply packet which was sent from FRR Spoke to Cisco Spoke directly was problematic.
  4. Cisco generated NHRP Error Indication Packet and did not add info to the routing table.

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:

table ip dmvpn_multicast {
        chain OUTPUT {
                type filter hook output priority filter; policy accept;
                oifname "tun100" ip daddr 224.0.0.0/24 counter packets 399 bytes 28968 log group 2
                oifname "tun100" ip daddr 224.0.0.0/24 counter packets 399 bytes 28968 drop
        }
}

FRR:

# show run
Building configuration...

Current configuration:
!
frr version 10.2-dev
frr defaults traditional
hostname vyos
log syslog
log facility local7
nhrp multicast-nflog-group 2
service integrated-vtysh-config
!
ip route 10.0.0.0/24 10.0.0.1 200
!
interface eth2
 ip ospf dead-interval 40
 ip ospf passive
exit
!
interface tun100
 ip address 10.0.0.15/32
 ip nhrp authentication test123
 ip nhrp holdtime 450
 ip nhrp map multicast 192.168.100.100
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1 nbma 192.168.100.100
 ip nhrp redirect
 ip nhrp registration no-unique
 ip nhrp shortcut
 ip ospf dead-interval 40
 ip ospf network point-to-multipoint
 no link-detect
 tunnel source eth0
exit
!
router ospf
 ospf router-id 1.1.1.15
 auto-cost reference-bandwidth 100
 timers throttle spf 200 1000 10000
 network 10.0.0.0/24 area 0
 network 10.0.102.0/24 area 0
exit
!
rpki
exit
!
end

Interfaces

# show interface eth0
Interface eth0 is up, line protocol is up
  Link ups:       1    last: 2024/07/31 09:14:03.44
  Link downs:     0    last: (never)
  vrf: default
  index 2 metric 0 mtu 1500 speed 10000 txqlen 1000
  flags: <UP,LOWER_UP,BROADCAST,RUNNING,MULTICAST>
  Ignore all v4 routes with linkdown
  Ignore all v6 routes with linkdown
  Type: Ethernet
  HWaddr: 0c:f0:ec:11:00:00
  inet 192.168.100.15/24
  inet6 fe80::ef0:ecff:fe11:0/64
  Interface Type Other
  Interface Slave Type None
  protodown: off
# show interface eth2
Interface eth2 is up, line protocol is up
  Link ups:       1    last: 2024/07/31 09:14:05.16
  Link downs:     0    last: (never)
  vrf: default
  index 4 metric 0 mtu 1500 speed 10000 txqlen 1000
  flags: <UP,LOWER_UP,BROADCAST,RUNNING,MULTICAST>
  Ignore all v4 routes with linkdown
  Ignore all v6 routes with linkdown
  Type: Ethernet
  HWaddr: 0c:f0:ec:11:00:02
  inet 10.0.102.1/24
  inet6 fe80::ef0:ecff:fe11:2/64
  Interface Type Other
  Interface Slave Type None
  protodown: off

I collect tcpdumps of NHRP packets with NHRP Authentication and without NHRP Authentication on Cisco SPOKE side.
authnhrp.dmp
noauthnhrp.dmp

Version

# show ver
FRRouting 10.2-dev (vyos) on Linux(6.6.36-amd64-vyos).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--sbindir=/usr/lib/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--enable-scripting' '--enable-pim6d' '--disable-grpc' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

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

  • I have searched the open issues for this bug.
  • I have not included sensitive information in this report.
@aapostoliuk aapostoliuk added the triage Needs further investigation label Jul 31, 2024
@aapostoliuk
Copy link
Contributor Author

@dleroy @volodymyrhuti Can you look at it?

@aapostoliuk
Copy link
Contributor Author

It seems that the issue is in a duplicate NHRP Authentication Extension field in this packet.

@donaldsharp
Copy link
Member

To clarify this is not fixed by #16480 ?

@aapostoliuk
Copy link
Contributor Author

#16480 does not fix this issue.
It fixes duplicating if FRR is a HUB. But if FRR is a SPOKE, then no.

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)
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
Labels
triage Needs further investigation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants