Bug 1697595 - RFE: Extend ndptool to specify source address for NA
Summary: RFE: Extend ndptool to specify source address for NA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libndp
Version: 8.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 8.2
Assignee: Hangbin Liu
QA Contact: Desktop QE
Parth Shah
Depends On:
Blocks: 1738635
TreeView+ depends on / blocked
Reported: 2019-04-08 19:09 UTC by Andreas Karis
Modified: 2020-04-28 16:46 UTC (History)
4 users (show)

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.
Clone Of:
Last Closed: 2020-04-28 16:46:29 UTC
Type: Enhancement
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:1808 0 None None None 2020-04-28 16:46:35 UTC

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

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

              · 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:

Actual results:

Expected results:

Additional info:

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

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.


Note You need to log in before you can comment on or make changes to this bug.