Neighbor Discovery Protocol on Cisco Router

ibmufa · January 5, 2017, 6:15pm

I am using Packet tracer and enabled IPv6 as described in the lesson. When I attempt to ping the neighbor using the auto-generated address I get error message below:

Router#ping FE80::201:42FF:FE0D:7101
% Unrecognized host or address or protocol not running.
After playing around with the router config, I realized I wasn’t getting anywhere. So I decided to just configure a global address and attempted pinging again and it worked

Is this unique only to Packet Tracer or is that how it should be configured? I noticed you didn’t have to do that when you demonstrated. I had to do the same on the neighboring router for ping to work.

I enabled debug but I don’t see all the messaged that you demonstrated. I only see the below messages and that’s it. I see the same on the neighbor. Is this also unique to Packet Tracer that I only see few messages?

Router(config-if)#do ping FE80::201:42FF:FE0D:7101
Output Interface: gigabitethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::201:42FF:FE0D:7101, timeout is 2 seconds:
*Mar 1 11:05:48.537: ICMPv6-ND: Sending NS for FE80::201:42FF:FE0D:7101 on GigabitEthernet0/0
*Mar 1 11:05:48.539: ICMPv6-ND: Received NA for FE80::201:42FF:FE0D:7101 on GigabitEthernet0/0 from FE80::201:42FF:FE0D:7101
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/7 ms

Your demonstration shows all the back and forth below messages:

R1#
ICMPv6-ND: DELETE → INCMP: FE80::C002:3FF:FEE4:0
ICMPv6-ND: Sending NS for FE80::C002:3FF:FEE4:0 on FastEthernet0/0
ICMPv6-ND: Received NA for FE80::C002:3FF:FEE4:0 on FastEthernet0/0 from FE80::C002:3FF:FEE4:0
ICMPv6-ND: Neighbour FE80::C002:3FF:FEE4:0 on FastEthernet0/0 : LLA c202.03e4.0000
ICMPv6-ND: INCMP → REACH: FE80::C002:3FF:FEE4:0
ICMPv6-ND: Received NS for FE80::C001:2FF:FE40:0 on FastEthernet0/0 from FE80::C002:3FF:FEE4:0
ICMPv6-ND: Sending NA for FE80::C001:2FF:FE40:0 on FastEthernet0/0

Question 2

During Neighbor solicitation, you mentioned that the destination address is the Neighbor’s Solicited Multicast Address. And that the sender knows about the neighbor address because it was given to it. How was the sender notified of the solicited multicast address? You also mention that the sender computes the neighbor solicited multicast address. Why would it need to compute it if it was already supplied/given to it already?

lagapidis · January 8, 2017, 5:20pm

Hello Ibmufa!

I just tried what you suggested on Packet Tracer and everything seems to work fine. I was trying to recreate what you decribe by removing the global ipv6 unicast-routing or the ipv6 enable interface commands, however I was unable to reproduce your results. I am using Packet Tracer version 7.X. To troubleshoot your issue more thouroughly, can you share some more of your configuration?

Concerning your other questions:

During Neighbor solicitation, you mentioned that the destination address is the Neighbor’s Solicited Multicast Address. And that the sender knows about the neighbor address because it was given to it. How was the sender notified of the solicited multicast address?

When IPv6 is enabled on an interface, several things begin to happen. It obtains a link-local address and it also computes and joins the solicited node multicast group address. How is this determined? Well, here’s an example:

Assume a host needs to make a local delivery to another host on the local network, and the target host has an IPv6 address of fe80::2aa:ff:fe28:9c5a. In order to make a Layer-2 (e.g. Ethernet) delivery, it needs to know the target host’s hardware address (e.g. “Ethernet MAC address”). But in order to do this, it must first determine which hardware address to send it to. To do this, an IPv6 host will construct the Solicited-node Multicast Address related to the target address.

We can see this clearly if we look at an example using the equivalent uncompressed IPv6 address.

fe80::2aa:ff:fe28:9c5a                      Target address (compressed notation)
fe80:0000:0000:0000:02aa:00ff:fe28:9c5a     Target address (uncompressed notation)
                                -- ----     the last 24-bits
ff02::1:ff00:0/104                          Solicited-node Multicast Address prefix
ff02:0000:0000:0000:0000:0001:ff00:0000/104 (uncompressed)
---- ---- ---- ---- ---- ---- --            The first 104 bits
ff02:0000:0000:0000:0000:0001:ff28:9c5a     Result
ff02::1:ff28:9c5a                           Result (compressed notation)

The result of this process is the IPv6 link-local solicited node multicast address that the Neighbor Solicitation packet is sent to.

You also mention that the sender computes the neighbor solicited multicast address. Why would it need to compute it if it was already supplied/given to it already?

To clarify once again, the Solicited Multicast Address is not “given” to it, but it is obtained by computing it.

I hope this has been helpful.

Laz

ibmufa · January 9, 2017, 2:50pm

Thank you Laz!!! for the clarification on Solicited Node Multicast Address. On the other question with error, perhaps it’s because of the version of packet Tracer - I am using 6.3.0.0008.

lagapidis · January 10, 2017, 3:33pm

Hello Ibmufa

It may be the version of packet tracer I don’t know. However, it still sounds like a very strange error. Have you tried redoing the lab on packet tracer again since then? Give us an update when you can…

Thanks!

Laz

talk2ajeet911 · January 22, 2019, 7:55pm

Hi Rene and Laz,

In a paragraph, you mentioned
“It can calculate the solicited node multicast address of the remote host since it knows about the multicast group address and it knows the IPv6 address that it wants to reach.”

Is the IPv6 destination address provided by the Application? Is this the IPv6 address by EUI-64?
Also, how does the sending host know about the solicited node multicast group address of the destination host?
Which solicited node multicast group address of the destination host does the sending host get to know? Is it the link-local multicast address or the Unique local multicast address or the Global unique multicast address?
Which multicast groups become common for hosts on a local LAN network so that they can communicate?

Sorry about these many questions but I really want to get a clear light on this.

Thanks
Ajeet

lagapidis · January 25, 2019, 7:05am

Hello Ajeet

First of all, no need to apologise for the many questions. That’s what we’re here for!

I’ll address your questions individually below:

First let’s clarify that the purpose of an NS message is to find the Layer 2 address, or MAC address of the connected node. This means we already know the IPv6 address. How do we know this address? In the example in the lesson, we have two routers. So this is most likely one hop in a series of many hops to get the actual payload to the destination. In this case, it may be that R1, using a routing protocol, determines that the next hop router is R2. It knows the next hope IP address either because it is statically configured or because it has learned it from a routing protocol. If it doesn’t know the MAC address, it will then go into the process of sending the NS.

The sending host knows the next hop IP address it wants to reach, most likely because it is statically or dynamically placed in the routing table as a next hop IP. It als knows that all multicast group addresses begin with FF02::1:FF /104. So it will take this multicast group address and add the last 6 hex characters from its already known IPv6 address. So it has all the information it needs to compute this solicited-node multicast address.

According to RFC2373, a solicited-node multicast address is calculated by each router for itself for every unicast address it has. This includes both link local and the global unicast addresses. So both multicast addresses would work in this case. However, when routers are communicating with each other over IPv6, they usually prefer to use the link-local addresses. These will always take precedence in such transactions. Only if there is no link-local address (explicitly configured) would it use the global unicast solicited-node multicast address.

Multicast ranges for IPv6 have been reserved much like they have for IPv4. There are various ranges, however, the ffx3::/16 scope is the equivalent of the 239.255.0.0/16 mutlicast range for IPv4. There are also ranges such as ffxe::/16 which are eligible to be used as multicast over the public Internet. You can find out more information about multicast for IPv6 at this lesson:

I hope this has been helpful!

Laz

talk2ajeet911 · January 25, 2019, 7:19am

Hi Laz,
Thanks a lot for such a detailed explanation. The process of NDP is very clear to me.

brandubh628 · July 7, 2024, 7:41pm

Hello Rene, Laz and forummembers,

I made a lab yesterday which is functioning in GNS3 but it doesn’t in CML. See below for the configurations. Any input will be appreciated.

Configuration

R1 & R2

(config)#interface FastEthernet 0/0
(config-if)#ipv6 enable

When I enter these commands in CML 2.61 I get this message when try to ping R2:

R1(config)#interface gigabitEthernet 0/0
R1(config-if)#no ip address
R1(config-if)#ipv6 enable
R1(config-if)#exit
R1(config)#exit
R1#
*Jul  7 19:31:19.852: %SYS-5-CONFIG_I: Configured from console by console
R1#
R1#ping FE80::5054:FF:FE15:455F
Output Interface: gigabitEthernet0/0
*% IPv6 isn't enabled on this interface* :face_with_diagonal_mouth:
Output Interface: 
% Interface required

R2#ping FE80::5054:FF:FE15:5DB9      
Output Interface: gigabitEthernet0/0 
% IPv6 isn't enabled on this interface
Output Interface: GigabitEthernet0/0
% IPv6 isn't enabled on this interface :face_with_diagonal_mouth:
Output Interface:

I enabled both interfaces (No Ip address ; IPv6 enable.

Is this a bug?

Same configuration GNS3 works like a charm.

lagapidis · July 9, 2024, 7:19am

Hello Michel

Hmm, that’s strange. I tried to recreate your results, but I was unable to. In CML, I was able to get it to work as expected.

When you issue the show ipv6 interface brief command on R1, what do you see? Do you see Gi0/0 with a link local address assigned? Also, check to see if the interface has been enabled with the “no shutdown” command. In CML, when you create a new topology, and you configure a router port, they are always shutdown until you enable them. If you don’t enable the interface, you do get the “IPv6 isn't enabled on this interface” error message. Check it out and let us know!

I hope this has been helpful!

Laz

brandubh628 · July 9, 2024, 6:53pm

Hello Laz,

Indeed, I didn’t enable the interfaces in CML (thought they were enabled). Must have neglected the message that the interface was down. Though in GNS3 I didn’t neglect the message.

I guess I need some more sleep

Both are working fine now. Thank you for your advice.

CML:

R1(config)#interface gigabitEthernet 0/0
R1(config-if)#no ip address
R1(config-if)#ipv6 enabled     
R1#show ipv6 interface brief
GigabitEthernet0/0     [administratively down/down]
    FE80::5054:FF:FE15:5DB9
GigabitEthernet0/1     [administratively down/down]
    unassigned
GigabitEthernet0/2     [administratively down/down]
    unassigned
GigabitEthernet0/3     [administratively down/down]
    unassigned
R1(config-if)#no shut
*Jul  9 19:00:12.735: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*Jul  9 19:00:13.735: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
                         
R1(config-if)#do ping FE80::5054:FF:FE15:455F
Output Interface: GigabitEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::5054:FF:FE15:455F, timeout is 2 seconds:
Packet sent with a source address of FE80::5054:FF:FE15:5DB9%GigabitEthernet0/0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

GNS3:

R1(config-if)#ipv6 enable
R1(config-if)#do show ipv6 interface brief
FastEthernet0/0            [administratively down/down]
    FE80::CE01:5FF:FEFD:0
R1(config-if)#
R1#
*Mar  1 00:01:00.323: %SYS-5-CONFIG_I: Configured from console by console
R1#ping ipv6 FE80::CE02:6FF:FE1F:0
Output Interface: fastethernet0/0
% No valid source address for destination
R1(config)#interface fastEthernet 0/0
R1(config-if)#no shut
R1(config-if)#
*Mar  1 00:02:56.003: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:02:57.003: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R1(config-if)#exit
R1(config)#exit
R1#ping ipv6 FE80::CE02:6FF:FE1F:0
*Mar  1 00:03:31.511: %SYS-5-CONFIG_I: Configured from console by console
R1#ping ipv6 FE80::CE02:6FF:FE1F:0
Output Interface: fastethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE02:6FF:FE1F:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:5FF:FEFD:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/32/56 ms

Best regards,
Michel