Bug 1697595

Summary:	RFE: Extend ndptool to specify source address for NA
Product:	Red Hat Enterprise Linux 8	Reporter:	Andreas Karis <akaris>
Component:	libndp	Assignee:	Hangbin Liu <haliu>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	unspecified	Docs Contact:	Parth Shah <pashah>
Priority:	unspecified
Version:	8.0	CC:	haliu, jmaxwell, lmanasko, vbenes
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	8.2
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libndp-1.7-3.el8	Doc Type:	Enhancement
Doc Text:	.ndptool can now specify a destination address in IPv6 header With this update, the `ndptool` utility can send a Neighbor Solicitation (NS) or a Neighbor Advertisement (NA) message to a specific destination by specifying the address in the IPv6 header. As a result, a message can be sent to addresses other than just the link-local address.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-28 16:46:29 UTC	Type:	Enhancement
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1738635

Description Andreas Karis 2019-04-08 19:09:32 UTC

Description of problem:
https://access.redhat.com/solutions/1467893

When sending an unsolicited Neighbour Advertisement when performing IP address failover on IPv6, there is no easy way to send an NA from addresses different than the link-local address.

The article recommends to run:
~~~
ndptool -t na -U -i vlan495 send
~~~

But this only sends out an advertisement for the link-local address:
~~~
(...)
8: eth1.905@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2000:10::250/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe91:a4ec/64 scope link 
       valid_lft forever preferred_lft forever
(...)
 [root@undercloud-1 ~]# tcpdump -nne -ieth1.905 icmp6 &
[1] 21088
 [root@undercloud-1 ~]# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.905, link-type EN10MB (Ethernet), capture size 262144 bytes

 [root@undercloud-1 ~]#  ndptool -t na -U -i eth1.905 send
14:55:07.793683 52:54:00:91:a4:ec > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 78: fe80::5054:ff:fe91:a4ec > ff02::1: ICMP6, neighbor advertisement, tgt is ::, length 24
~~~

We need an option `-s`, the same as in arping:
~~~
       -s source
              IP source address to use in ARP packets.  If this option is absent, source address is:

              · In DAD mode (with option -D) set to 0.0.0.0.

              · In Unsolicited ARP mode (with options -U or -A) set to destination.

              · Otherwise, it is calculated from routing tables.
~~~

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 4 Jonathan Maxwell 2019-08-13 01:05:23 UTC

Take

Comment 5 Jonathan Maxwell 2019-08-13 01:10:23 UTC

(In reply to Jonathan Maxwell from comment #4)
> Take

Reverting assignee to Eric. I hit the wrong button when mirroring the bz.

Comment 12 Hangbin Liu 2019-12-13 01:21:16 UTC

Yes, It looks good to me, thanks for the update.

Comment 13 Vladimir Benes 2020-01-09 17:58:13 UTC

working well with:
ndptool -i veth0 -t na -D fe80::200:ff:fe00:2 -T fe80::200:ff:fe00:1 send

covered in automation

Comment 15 errata-xmlrpc 2020-04-28 16:46:29 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1808