Troubleshooting Guide for Common IPv6 Faults on Routers
This document describes IPv6 basics about routers and the troubleshooting roadmap and methods for typical IPv6 problems, providing reference for maintenance engineers to troubleshoot IPv6 faults on live networks.
This document describes IPv6 basics about routers and the troubleshooting roadmap and methods for typical IPv6 problems, providing reference for maintenance engineers to troubleshoot IPv6 faults on live networks.
Troubleshooting Guide for Common IPv6 Faults on Routers
- IPv6 Basics
- Common IPv6 Fault Locating Commands
- Troubleshooting Guidelines for IPv6 ND Negotiation Failures
- Troubleshooting Guidelines for IPv6 Ping Failures
- Troubleshooting Guidelines for IPv6 BGP Peer Relationship Establishment Failures
- Troubleshooting Guidelines for IPv6 BGP Traffic Interruptions or Flapping
IPv6 Basics
This document describes IPv6 basics about routers and the troubleshooting roadmap and methods for typical IPv6 problems, providing reference for maintenance engineers to troubleshoot IPv6 faults on live networks.
This document applies to the ME60/NE40E/NE20E/NetEngine 8000 series routers running V800R012 or a later version. The commands and command output may vary according to the device model or version. For details about the commands to be used, see the product documentation of the corresponding version.
- Some fault locating steps in this document use commands in the diagnostic view for device fault diagnosis. Running certain commands in the diagnostic view may cause device exceptions or service interruptions. If you need to use commands in the diagnostic view, contact Huawei engineers and use the commands under their guidance.
- Some troubleshooting steps may require you to enable the debugging function, which affects the system performance. Therefore, exercise caution when enabling this function.
IPv6 Address Formats
Differences Between IPv6 and IPv4
Internet Protocol version 6 (IPv6), also called IP Next Generation (IPng), is a second-generation network layer protocol and an upgraded version of Internet Protocol version 4 (IPv4). It is designed by the Internet Engineering Task Force (IETF).
The most obvious difference between IPv4 and IPv6 is that IPv4 addresses are of 32 bits whereas IPv6 addresses are of 128 bits. IPv6 is more competitive in future markets with its simplified header, sufficient address space, hierarchical address structure, flexible extension header, and enhanced neighbor discovery mechanism.
Written Formats of an IPv6 Address
A 128-bit IPv6 address can be expressed in either of the following formats:
- X:X:X:X:X:X:X:X
- An IPv6 address in this format is written as eight groups of four hexadecimal digits (0 to 9, A to F), with each group separated by a colon (:). Each "X" represents a group of hexadecimal digits. An IPv6 address example is as follows:
2001:0db8:130F:0000:0000:09C0:876A:130B
For convenience, leading zeros of each group can be omitted. Therefore, the preceding address can be written as:
2001:db8:130F:0:0:9C0:876A:130B
- Any number of consecutive groups of 0s can be replaced with two colons (::). Therefore, the given example can be written as:
2001:db8:130F::9C0:876A:130B
An IPv6 address can contain only one double-colon substitution. Otherwise, when the compressed address is restored to 128 bits, the number of 0s in each segment cannot be determined.
- An IPv6 address in this format is written as eight groups of four hexadecimal digits (0 to 9, A to F), with each group separated by a colon (:). Each "X" represents a group of hexadecimal digits. An IPv6 address example is as follows:
- X:X:X:X:X:X:d.d.d.d
IPv4-mapped IPv6 address: The format of an IPv4-mapped IPv6 address is 0:0:0:0:0:FFFF:IPv4-address. This type of IPv6 address is used to represent the addresses of IPv4 nodes.
"X:X:X:X:X:X" represents the high-order six groups of digits, with each "X" standing for 16 bits, which are represented by hexadecimal digits. "d.d.d.d" represents the low-order four groups of digits, with each "d" standing for 8 bits, which are represented by decimal digits. "d.d.d.d" is a standard IPv4 address.
IPv6 Address Structure
An IPv6 address is divided into two parts:
- Network prefix: equivalent to the network ID of an IPv4 address, which is of n bits.
- Interface ID: equivalent to the host ID of an IPv4 address, which is of (128 – n) bits.
The following figure shows the structure of the address 2001:A304:6101:1::E0:F726:4E58/64.
IPv6 Address Classification
IPv6 addresses are classified as unicast, anycast, and multicast addresses.
- Unicast address: uniquely identifies an interface and is similar to an IPv4 unicast address. A packet destined for a unicast address is transmitted to the unique interface identified by this address.
A global unicast address cannot be the same as its network prefix, because this type of address is a subnet-router anycast address reserved for a device. However, this rule does not apply to an IPv6 address with a 127-bit network prefix.
- Anycast address: identifies a group of interfaces (which usually belong to different nodes). A packet destined for an anycast address is transmitted to only one of the interfaces — the nearest one according to distance as defined by the routing protocol.
Application scenario: When a mobile host communicates with the mobile agent on the home subnet, it uses the anycast address of the subnet's routing device.
Address specifications: Anycast addresses do not have independent address space. They can use the format of any unicast address. Syntax is required to differentiate an anycast address from a unicast address.
As IPv6 defines, an IPv6 address with the interface identifier of all 0s is a subnet-router anycast address. As shown in the following figure, the subnet prefix is an IPv6 unicast address prefix which is specified when an IPv6 unicast address is configured.
Figure 1-2 Format of a subnet-router anycast address![]()
![]()
An anycast address is not necessarily a subnet-router anycast address and can also be a global unicast address.
- Multicast address: identifies a group of interfaces that belong to different nodes. It is similar to an IPv4 multicast address. A packet destined for a multicast address is transmitted to all the interfaces identified by this address.
IPv6 does not involve broadcast addresses, but it can use multicast addresses to provide broadcast address functions.
Unicast Addresses
The following table lists the types of unicast addresses.
Address Type |
Binary Prefix |
IPv6 Prefix Identifier |
|---|---|---|
Link-local unicast address |
1111111010 |
FE80::/10 |
Unique local address (ULA) |
1111110 |
FC00::/7 |
Loopback address |
00...1 (128 bits) |
::1/128 |
Unspecified address |
00...0 (128 bits) |
::/128 |
Global unicast address |
Others |
- |
The meaning of each type of address is as follows:
- Link-local unicast address: used in the neighbor discovery protocol and in the communication between nodes on the local link during stateless address autoconfiguration. The packets with link-local addresses as source or destination addresses are forwarded only on the local link. The link-local unicast address can be automatically configured on an Ethernet interface using the link-local prefix FE80::/10 (1111 1110 10) and an EUI-64 interface ID (the 48-bit MAC address of an interface can be converted into a 64-bit interface ID according to IEEE EUI-64).
The conversion between an interface MAC address and a local unicast address is as follows:
The 64-bit interface ID in an IPv6 address identifies a unique interface on a link. This address is derived from the link-layer address (such as a MAC address) of the interface. The interface ID in an IPv6 address has 64 bits, whereas a MAC address has 48 bits. Therefore, a hexadecimal number needs to be inserted in the middle of the MAC address to convert a MAC address into an EUI-64 interface ID. The U/L bit (the most significant seventh bit) is set to 1. An EUI-64 interface ID is then obtained.
If an interface has been configured with a MAC address, an EUI-64 address is generated based on the MAC address of the interface, with FFFE added in the middle.
If an interface has not been configured with a MAC address, an EUI-64 address is generated based on the following rules:
- The EUI-64 address of a Layer 3 physical interface and its sub-interface is generated based on the MAC address of the physical interface, with FFFE added in the middle.
- For a loopback, VBDIF, or tunnel interface, an EUI-64 address is generated based on the MAC address of the interface, with the last two bytes following the interface index added in the middle.
- For an Eth-Trunk interface and its sub-interface, global VE sub-interface, VE sub-interface, or VLANIF interface, an EUI-64 address is generated based on the MAC address of the interface, with FFFE added in the middle.
Taking the insertion of a hexadecimal number FFFE (1111 1111 1111 1110) into the middle as an example, see Figure 1-3 for the detailed conversion procedure.
- Unique local unicast address: identifies a single site and has a globally unique prefix. Sites use unique local unicast addresses to establish private connections, without incurring address conflicts. Even if routes destined for unique local unicast addresses leak, the routes do not conflict with Internet routes. Upper-layer applications use unique local unicast addresses as global unicast addresses.
- Loopback address: It is 0:0:0:0:0:0:0:1 or ::1 and not assigned to any interface. Similar to the IPv4 loopback address 127.0.0.1, the IPv6 loopback address is used by a node to send packets to itself.
- Unspecified address (::): can neither be assigned to any node nor function as a destination address. The unspecified address can be used in the Source Address field of the IPv6 packet sent by an initializing host before it has learned its own address. During DAD, the Source Address field of an NS message is an unspecified address.
- Global unicast address: equivalent to an IPv4 public network address. Global unicast addresses are used on links that can be aggregated, and are provided to Internet service providers (ISPs). The structure of global unicast addresses enables route prefix aggregation, which maximizes the number of global routing entries. A global unicast address contains a 48-bit routing prefix managed by a carrier, a 16-bit subnet ID managed by a local site, and a 64-bit interface ID. Unless otherwise specified, global unicast addresses include site-local unicast addresses.
Multicast Addresses
Figure 1-4 shows the format of an IPv6 multicast address.
An IPv6 multicast address starts with FF.
- Identifier field, which contains four bits — 0RPT:
- 0: This most significant bit is reserved and has a fixed value of 0.
- R: indicates whether the multicast address is embedded with an RP address. If the value is 1, the multicast address is embedded with an RP address.
- P: indicates whether the address is a unicast prefix-based multicast address. If the value is 1, the address is a unicast prefix-based multicast address.
- T: indicates whether a multicast address is a permanent multicast group address. If the value is 0, the address is a multicast address is a permanent multicast group address or a well-known multicast address defined by the IANA.
- The scope field (4 bits) indicates whether a multicast group contains any node in the global address space or only the nodes of the same local network, the same site, or the same organization. The values of this field are defined as follows:
0: reserved for other multicast protocols
1: node/interface-local scope
2: link-local scope
3: reserved for other multicast protocols
4: admin-local scope
5: site-local scope
8: organization-local scope
E: global scope
F: reserved for other multicast protocols
Other value: unassigned and can be used as a common address
Table 1-2 describes the ranges and meanings of fixed IPv6 multicast addresses.
Scope |
Meaning |
|---|---|
FF0x::/32 |
Well-known multicast addresses defined by the IANA.
|
FF1x::/32 (x cannot be 1 or 2) FF2x::/32 (x cannot be 1 or 2) |
Any-source multicast (ASM) address. The addresses in this scope are valid on the entire network. |
FF3x::/32 (x cannot be 1 or 2) |
Source-specific multicast (SSM) address. This is the default SSM group address scope, which is valid on the entire network. |
ICMPv6 Message Format
Internet Control Message Protocol version 6 (ICMPv6) (ICMPv6) is a basic IPv6 protocol. It provides functions similar to ICMP on an IPv4 network.
The ICMPv6 type number (Next Header field value in an IPv6 packet) is 58. Figure 1-6 shows the ICMPv6 message format.
The following describes each of the fields in an ICMPv6 message:
- Type: indicates a message type. Values 0 to 127 indicate the error message type, and values 128 to 255 indicate the information message type.
- Code: creates an additional level of message granularity.
- Checksum: indicates the ICMPv6 message checksum.
ICMPv6 Message Format Example
Ethernet II, Src: HuaweiTe_57:28:ca (00:18:82:57:28:ca), Dst: Spv_2b:cb:8e (38:c8:5c:2b:cb:8e)
Destination: Spv_2b:cb:8e (38:c8:5c:2b:cb:8e)
Address: Spv_2b:cb:8e (38:c8:5c:2b:cb:8e)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: HuaweiTe_57:28:ca (00:18:82:57:28:ca)
Address: HuaweiTe_57:28:ca (00:18:82:57:28:ca)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IPv6 (0x86dd)
Trailer: a15b641f
Internet Protocol Version 6, Src: 2001::1 (2001::1), Dst: 2001::2 (2001::2)
0110 .... = Version: 6
[0110 .... = This field makes the filter "ip.version == 6" possible: 6]
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)
.... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set
.... .... ...0 .... .... .... .... .... = ECN-CE: Not set
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 64
Next header: ICMPv6 (0x3a)
Hop limit: 64
Source: 2001::1 (2001::1)
[Source Teredo Server IPv4: 0.0.0.0 (0.0.0.0)]
[Source Teredo Port: 65535]
[Source Teredo Client IPv4: 255.255.255.254 (255.255.255.254)]
Destination: 2001::2 (2001::2)
[Destination Teredo Server IPv4: 0.0.0.0 (0.0.0.0)]
[Destination Teredo Port: 65535]
[Destination Teredo Client IPv4: 255.255.255.253 (255.255.255.253)]
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0xb01b [correct]
Identifier: 0xabce
Sequence: 1
Data (56 bytes)
Data: 23f432fa000102030405060708090a0b0c0d0e0f10111213...
[Length: 56]
ND Message Exchange Process
Neighbor Discovery (ND) defines a group of messages and processes that discover relationships between neighboring nodes. ND provides similar functions as the Address Resolution Protocol (ARP) and ICMP router discovery in IPv4, as well as additional functions.
- Router Solicitation (RS) messages: After a host starts, it sends an RS message to a router and waits for a Router Advertisement (RA) from the router.
- RA messages: A router periodically advertises RA messages, which contain prefix and identifier information.
- Neighbor Solicitation (NS) messages: An IPv6 node uses NS messages to obtain the link-layer address of its neighbor, check whether the neighbor is reachable, and detect address conflicts.
- Neighbor Advertisement (NA) messages: After receiving an NS message, an IPv6 node responds with an NA message. In addition, the IPv6 node initially sends NA messages when the link layer changes.
Router Discovery
Router discovery is used to locate a neighboring router and learn the address prefix and configuration parameters related to address autoconfiguration. IPv6 router discovery is implemented based on the following messages:
Router Solicitation (RS) message
When a host is not configured with a unicast address, for example, when the host has just started, it sends an RS message. The RS message helps the host rapidly perform address autoconfiguration without waiting for the RA message that is periodically sent by an IPv6 routing device. An RS message is of ICMPv6 type 133.
Router Advertisement (RA) message
Interfaces on each IPv6 routing device periodically send RA messages when they are enabled to do so. After receiving an RS message from an IPv6 node on the local link, a routing device responds with an RA message. The RA message is sent to the multicast address FF02::1 of all nodes or to the IPv6 unicast address of the node that sent the RS message. An RA message is of ICMPv6 type 134.
After an IPv6 host on the local link receives an RA message, it learns the updated default router list, prefix list, and other configurations from the message.
Neighbor Discovery
Similar to ARP in IPv4, IPv6 Neighbor Discovery (ND) parses the neighbor addresses and detects the availability of neighbors based on NS and NA messages.
When a node needs to obtain the link-layer address of another node on the same local link, it sends an NS message of ICMPv6 type 135. This message is similar to an ARP request message in IPv4. The difference is that this message uses a multicast address instead of a broadcast address. Only nodes with the last 24 bits of their addresses the same as the multicast address of the message will receive this message, reducing the possibility of broadcast storms. A destination node fills its link-layer address in an NA message.
An NS message is also used to detect the availability of a neighbor when the link-layer address of the neighbor is known. An IPv6 NA message is sent in response to an IPv6 NS message. After receiving an NS message, a destination node responds with an NA message of ICMPv6 type 136 along the local link. After receiving the NA message, the source node can communicate with the destination node. When the link-layer address of a node on the local link changes, the node also proactively sends an NA message.
NUD
ND uses NS and NA messages to verify the reachability of neighboring nodes. After determining the link-layer address of a neighbor, a node traces the status of the neighbor cache entry and sends NS messages periodically. If the neighbor cannot receive or send response messages in a specified reachability period, the node deletes the neighbor cache entry.
Hardware faults and hot swapping of interface cards interrupt communication with neighboring devices. Communication cannot be restored if the destination of a neighboring device becomes invalid, but it can be restored if the path fails. So the device needs to maintain a neighbor table to monitor the state of each neighboring device.
There are five neighbor states:
INCMP: The neighbor is unreachable. This state indicates that the device is parsing the neighbor's link-layer address. If the device parses the address successfully, the device sets the neighbor state to REACH.
REACH: The neighbor is reachable. If the entry is not used before the neighbor reachable time (20 minutes by default) expires, the device sets the neighbor state to STALE.
STALE: The neighbor reachability is unknown. In the STALE state, NS messages are sent to detect whether the neighbor is reachable. After sending NS messages to detect whether the neighbor is reachable, the device sets the neighbor state to DELAY. If the entry is not used after the aging time (20 minutes by default) expires, the device also sets the neighbor state to DELAY.
DELAY: The neighbor reachability is unknown. If the device does not receive a response within a specified period (5 seconds by default) after sending an NS message, the device sets the neighbor state to PROBE. If the device receives an NA message, it sets the neighbor state to REACH.
PROBE: The neighbor reachability is unknown. The device sends unicast NS messages at the interval specified by the Retrans Timer of the RA message or at the user-defined interval. If no response is received, the device deletes the entry; otherwise, it sets the neighbor state to REACH.
DAD
Duplicate address detection (DAD) is performed before an interface uses an IPv6 unicast address to detect whether the address is used by another node. The temporary address to be used must be unique on the local link, and has not been used by another node. DAD is required if IPv6 addresses are configured automatically. An IPv6 unicast address that is assigned to an interface but not verified by DAD is called a tentative address. An interface cannot use such an address for unicast communication but will join two multicast groups: all-nodes multicast group and solicited-node multicast group.
In Figure 1-8, the IPv6 address 2001:db8:1::1 is assigned to HostA as a tentative IPv6 address. To check the validity of this address, HostA sends an NS message containing the requested address 2001:db8:1::1 to the solicited-node multicast group to which 2001:db8:1::1 belongs. Because 2001:db8:1::1 is not specified, the source address of the NS message is an unspecified address. After receiving the NS message, HostB processes the message as follows:
- If 2001:db8:1::1 is a tentative or unused address of HostB, HostB does not use this address as an interface address, nor does it send an NA message.
- If HostB checks that 2001:db8:1::1 is a used address, it sends an NA message that contains 2001:db8:1::1 to 2001:db8:2::1. After receiving the message, HostA finds that its tentative address is duplicate.
Common IPv6 Fault Locating Commands
Commands for Checking IPv6 Interface States
Command |
Description |
|---|---|
display ipv6 interface brief |
This command displays the brief state and configuration information of an interface. !down indicates that the interface is Down because the number of route prefixes in the FIB exceeds the upper limit. If an IPv6 address conflict occurs on an interface, the link-local address is displayed. For example: <HUAWEI> display ipv6 interface brief *down: administratively down !down: FIB overload down (l): loopback (s): spoofing Interface Physical Protocol VPN GigabitEthernet 1/0/1 up up l3vpn [IPv6 Address/Prefix Length] 2001:db8:3c4d::/48 GigabitEthernet 1/0/2 up up -- [IPv6 Address/Prefix Length] FE80::CA8D:83FF:FEF1:12C6 |
display ipv6 interface |
This command displays the detailed IPv6 state and configuration information of an interface. If the IPv6 address of the interface is followed by [DUPLICATED], the IPv6 address state is incorrect and a conflict occurs. For example: <HUAWEI> display ipv6 interface
GigabitEthernet1/0/0 current state : UP
IPv6 protocol current state : UP
IPv6 is enabled, link-local address is FE80::3ABA:1800:324:8801
Global unicast address(es):
2001:db8::1, subnet is 2001:db8::/32 [DUPLICATE]
Joined group address(es):
FF02::1:FF00:1
FF02::1:FFB6:1
FF02::2
FF02::1
MTU is 4470 bytes
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 1200000 milliseconds
ND retransmit interval is 1000 milliseconds
Hosts use stateless autoconfig for addresses
|
Commands for Checking Statistics About Sent and Received IPv6 Packets
Command |
Description |
|---|---|
display ipv6 neighbors |
This command displays information about dynamic and static neighbor entries through which you can check the neighbor state (unreachable, reachable, or unknown). The State field, indicating the neighbor state, has one of the following values. REACH: indicates that the neighbor is reachable.
For example: <HUAWEI> display ipv6 neighbors gigabitethernet 1/0/1 ----------------------------------------------------------------------------- IPv6 Address : 2001:DB8::1 Link-layer : 00e0-fc12-3456 State : INCMP Interface : GE1/0/1 Age : - VLAN : - CEVLAN : - VPN name : vpn1 Is Router : TRUE Secure FLAG : SECURE Source IP : - Destination IP: - VNI : - BD : - ----------------------------------------------------------------------------- Total: 1 Dynamic: 0 Static: 1 Remote:0 |
display icmpv6 statistics interface |
This command displays ICMPv6 traffic statistics to check whether ICMPv6 response packets are properly sent and received. For example: <HUAWEI> display icmpv6 statistics interface gigabitEthernet 1/0/1
ICMPv6 protocol:
Sent packets:
Total : 27
Unreached : 0 Prohibited : 0
Hop count exceeded : 0 Parameter problem : 0
Too big : 0 Echoed : 12
Echo replied : 5 Router solicit : 0
Router advert : 0 Neighbor solicit : 5
Neighbor advert : 5 Redirected : 0
Rate limited : 0
Received packets:
Total : 23 Format error : 0
Checksum error : 0 Too short : 0
Bad code : 0 Bad length : 0
Unknown info type : 0 Unknown error type : 0
Unreached : 0 Prohibited : 0
Hop count exceeded : 0 Parameter problem : 0
Too big : 0 Echoed : 5
Echo replied : 12 Router solicit : 0
Router advert : 0 Neighbor solicit : 3
Neighbor advert : 3 Redirected : 0
Rate limited : 0
|
display ipv6 statistics interface |
This command displays traffic statistics of an interface. For example: <HUAWEI> display ipv6 statistics interface gigabitEthernet 1/0/1
IPv6 protocol:
Sent packets:
Total : 17
Local sent out : 17 Forwarded : 0
Raw packets : 17 Discarded : 0
Fragmented : 0 Fragments : 0
Fragments failed : 0 Multicast : 17
Received packets:
Total : 5 Local host : 5
Hop count exceeded : 0 Header error : 1
Too big : 0 Routing failed : 0
Address error : 1 Protocol error : 0
Truncated : 0 Option error : 0
Fragments : 0 Reassembled : 0
Reassembly timeout : 0 Multicast : 5
Extension header:
Hop-by-hop options : 0 Mobility header : 0
Destination options : 0 Routing header : 0
Fragment header : 0 Authentication header : 0
Encapsulation header : 0 No header : 0
TLV length error : 0 Header length error : 0
Unknown header type : 0 Unknown TLV type : 0
|
display ipv6 nd packet statistics |
This command displays ND message statistics. <HUAWEI> display ipv6 nd packet statistics
Sent Packet Statistics:
-------------------------------------------------------------------------------
Type NS NA RS RA
-------------------------------------------------------------------------------
Total 0 0 0 0
Source IP
Unspecified 0 - - -
Destination IP
Unicast 0 0 - 0
Multicast 12 0 0 0
Target IP
Linklocal 0 0 - -
Global 0 0 - -
-------------------------------------------------------------------------------
Received Packet Statistics:
--------------------------------------------------------------------------------------
Type NS NA RS RA ND_MISS
--------------------------------------------------------------------------------------
Recv Total 0 0 0 0 0
Valid Total 0 0 0 0 0
Source IP
Unspecified 0 - - - -
Destination IP
Unicast 0 12 0 0 -
Multicast 0 0 0 0 -
Target IP
Linklocal 0 0 - - -
Global 0 0 - - -
--------------------------------------------------------------------------------------
|
Commands for Checking IPv6 Route Information
Command |
Description |
|---|---|
display ipv6 routing-table |
This command displays information about the IPv6 routing table. <HUAWEI> display ipv6 routing-table
Routing Table : _Public_
Destinations : 1 Routes : 1
Destination : 2001:db8:1::1 PrefixLength : 128
NextHop : 2001:db8:2::1 Preference : 0
Cost : 0 Protocol : Direct
RelayNextHop : :: TunnelID : 0x0
Interface : InLoopBack0 Flags : D
|
display bgp ipv6 peer |
This command displays information about BGP IPv6 peers. If State is Established, the peer relationship is established. The options of State are as follows: Idle: BGP denies any connection request. This is the initial state of BGP. Connect: BGP waits for a TCP connection to be established before performing further actions. Active: BGP attempts to establish a TCP connection. This is an intermediate state of BGP. OpenSent: BGP has sent one Open message to its peer and is waiting for an Open message from the peer. OpenConfirm: BGP is waiting for a Notification or Keepalive message. Established: BGP peers can exchange Update, Notification, and Keepalive messages. No neg: The address family is not enabled on the BGP peer. For example: <HUAWEI> display bgp ipv6 peer BGP Local router ID : 10.0.0.1 local AS number : 100 Total number of peers : 1 Peers in established state : 1 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 2001:DB8:20::21 4 200 17 19 0 00:09:59 Established 3 |
display bgp vpnv6 all peer |
This command displays information about BGP VPNv6 peers. If State is Established, the peer relationship is established. For example: <HUAWEI> display bgp vpnv6 all peer
BGP local router ID : 10.1.1.1
Local AS number : 100
Total number of peers : 2 Peers in established state : 2
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
10.2.2.2 4 100 210 220 0 02:42:55 Established 1
Peer of IPv6-family for vpn instance :
VPN-Instance vpn1 :
2001:DB8:2000::2 4 65410 205 178 0 02:42:53 Established 0
|
display bgp ipv6 peer log-info |
This command displays log information about BGP IPv6 peers. Determine the cause of a peer relationship establishment failure based on the Error Code and Error Subcode fields. For example: <HUAWEI> display bgp ipv6 peer 2001:DB8:1::2 log-info Peer : 2001:DB8:1::2 Date/Time : 2021/6/09 11:58:21 State : Up Date/Time : 2021/6/09 11:58:09 State : Down Error Code : 6(CEASE) Error Subcode: 6(Other Configuration Change) Notification : Receive Notification Date/Time : 2021/6/09 10:39:05 State : Up |
display bgp vpnv6 peer log-info |
This command displays log information about BGP VPNv6 peers. Determine the cause of a peer relationship establishment failure based on the Error Code and Error Subcode fields. For example: <HUAWEI> display bgp ipv6 peer 2001:DB8:1::2 log-info Peer : 2001:DB8:1::2 Date/Time : 2021/6/09 11:53:21 State : Up Date/Time : 2021/6/09 11:53:09 State : Down Error Code : 6(CEASE) Error Subcode: 6(Other Configuration Change) Notification : Receive Notification Date/Time : 2021/6/09 10:34:05 State : Up |
display bgp ipv6 routing-table |
This command is used to check whether route learning is normal on both ends of a peer relationship. For example: <HUAWEI> display bgp ipv6 routing-table
BGP Local router ID is 10.1.1.2
Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V - valid, I - invalid, N - not-found
*>i Network : 2001:DB8:100::100 PrefixLen : 128
NextHop : 2001:DB8:12::1 Duration : 0d05h46m16s
Peer : 2001:DB8:12::1
Path/Ogn : ?
* i
NextHop : 2001:DB8:112::1 Duration : 0d05h46m16s
Peer : 2001:DB8:112::1
Path/Ogn : ?
*>i Network : 2001:DB8:111::111 PrefixLen : 128
NextHop : 2001:DB8:12::1 Duration : 0d05h46m16s
Peer : 2001:DB8:12::1
Path/Ogn : ?
|
Commands for Checking the Statistics About IPv6 Packets Sent to the CPU by CPCAR
Command |
Description |
|---|---|
ATN series products: display icmpv6 rate-limit statistics |
This command displays statistics of packets sent to the CPU by CPCAR on each interface. For example: <HUAWEI> display icmpv6 rate-limit statistics Interface Total-Packets Passed-Packets Dropped-Packets -------------------------------------------------------------------------------- GigabitEthernet0/2/1 13 13 0 GigabitEthernet0/2/2 0 0 0 GigabitEthernet0/2/3 0 0 0 |
Router series products (diagnostic view): display cpu-defend statistics-all |
This command displays CPU-defense packet statistics of CPCAR in a specified slot. For example: <HUAWEI> system-view [~HUAWEI] diagnose [~HUAWEI-diagnose]display cpu-defend statistics-all slot 1 Index CarID Packet-Info Passed Packets Dropped Packets ============================================================================================== ... 625 314 MAC_ADD_MSG 1 0 684 645 IPV6_MC_NS 12 0 1161 334 SAID_BIGHEART_PKT 247 0 1231 234 IGP_Maintain_Unit Packet 8 0 |
Debugging Commands for IPv6 Packets
Command |
Description |
|---|---|
debugging ipv6 packet |
This command enables debugging for IPv6 packets, helping you locate faults. For example: <HUAWEI> debugging ipv6 packet interface gigabitethernet 1/0/1 verbose 64 number 100 |
debugging ipv6 nd |
This command displays information about IPv6 ND messages and the ND state machine, helping you locate faults. For example: <HUAWEI> debugging ipv6 nd interface gigabitethernet 1/0/1 verbose 64 number 100 |
Troubleshooting Guidelines for IPv6 ND Negotiation Failures
Symptom
After the IPv6 ND protocol is configured, one or both ends of a neighbor relationship fail to learn ND entries.
Troubleshooting Roadmap
The troubleshooting roadmap for this type of fault is as follows:
- Check whether the neighbor is reachable.
- Check whether the IPv6 state of the interface is normal.
- Check whether the number of ND entries exceeds the limit.
- If the interface state is normal, perform a ping operation to trigger ND message negotiation. Then, check the statistics about NS and NA messages sent and received to determine whether the fault occurs in the direction from the source end to the destination end or in the reverse direction.
- Enable ND message debugging and perform a ping operation to locate the fault based on message sending and receiving information.
- Query the statistics about IPv6 packets of CPCAR to check whether packets are sent to the CPU normally.
Procedure
Save the results of each troubleshooting step. If the fault persists after following this procedure, these results are needed for further troubleshooting.
- Run the display ipv6 neighbors command to check neighbor entries. Determine the neighbor state (unreachable, reachable, or unknown) based on dynamic and static neighbor entries displayed in the command output. If State is REACH, the neighbor is reachable.There are five neighbor states:
- INCMP: The neighbor is unreachable. This state indicates that the device is parsing the neighbor's link-layer address. If the device parses the address successfully, the device sets the neighbor state to REACH.
- REACH: The neighbor is reachable. If the entry is not used before the neighbor reachable time (20 minutes by default) expires, the device sets the neighbor state to STALE.
- STALE: The neighbor reachability is unknown. In the STALE state, NS messages are sent to detect whether the neighbor is reachable. After sending NS messages to detect whether the neighbor is reachable, the device sets the neighbor state to DELAY. If the entry is not used after the aging time expires, the device also sets the neighbor state to DELAY.
- DELAY: The neighbor reachability is unknown. If the device does not receive a response within a specified period after sending an NS message, the device sets the neighbor state to PROBE. If the device receives an NA message, it sets the neighbor state to REACH.
- PROBE: The neighbor reachability is unknown. The device sends unicast NS messages at the interval specified by the Retrans Timer of the RA message or at the user-defined interval. If no response is received, the device deletes the entry; otherwise, it sets the neighbor state to REACH.
<HUAWEI> display ipv6 neighbors gigabitethernet 1/0/0 ----------------------------------------------------------------------------- IPv6 Address : 2001:DB8::1 Link-layer : 00e0-fc89-fe6e State : REACH Interface : GE1/0/0 Age : - VLAN : - CEVLAN : - VPN name : vpn1 Is Router : TRUE Secure FLAG : SECURESource IP : - Destination IP: - VNI : - BD : - ----------------------------------------------------------------------------- Total: 1 Dynamic: 0 Static: 1 Remote:0
- Run the display ipv6 interface [ interface-name | interface-type interface-number ] command to check whether the IPv6 state of the interface is normal.
- Check whether the physical state of the interface is up. If the state is displayed as DOWN, check whether the physical connection is normal.
- Check whether IPv6 is enabled on the interface. If not, run the ipv6 enable command to enable it.
- Check whether the IPv6 address state of the interface is normal.
- If the IPv6 address is not followed by [TENTATIVE] or [DUPLICATE], the IPv6 address state is normal.
- If the IPv6 address is followed by [DUPLICATE], an IPv6 address conflict exists. Run the undo ipv6 address command in the interface view to delete the IPv6 address configured for the interface, and then run the ipv6 address command to configure a new IPv6 address in the same network segment for the interface.
- Generally, link-local addresses are automatically calculated based on MAC addresses and do not conflict with each other. In normal cases, [DUPLICATE] is not displayed. If it is displayed, check whether the MAC addresses of the two ends conflict and whether a loop exists on the intermediate Layer 2 network to eliminate the MAC address conflict.
<HUAWEI> display ipv6 interface gigabitethernet 1/0/0 gigabitethernet 1/0/0 current state : UP IPv6 protocol current state : DOWN IPv6 is enabled, link-local address is FE80::CA8D:83FF:FEF1:12C6 Global unicast address(es): 2001::1, subnet is 2001::/32 [DUPLICATE] Joined group address(es): FF02::1:FF24:8801 FF02::2 FF02::1 MTU is 6000 bytes ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 1200000 milliseconds ND retransmit interval is 1000 milliseconds Hosts use stateless autoconfig for addresses
- Check whether the ND_1.3.6.1.4.1.2011.5.25.332.2.3 hwInterfaceNDThresholdExceedAlarm alarm is generated. If so, the number of ND entries on the interface has exceeded the specified number. If the number of ND entries on the interface reaches the maximum number, the interface cannot learn more ND entries.
- If the number of ND entries has not reached the maximum number, go to Step 4.
- If the number of ND entries has reached the maximum number, go to Step 7.
- If the interface state is normal and the number of ND entries does not reach the maximum number, check whether the fault occurs in the direction from the source end to the destination end or in the reverse direction.
Run the reset ipv6 statistics command on the source and destination ends to delete IPv6 statistics, run the ping ipv6 command to trigger ND message negotiation, and then run the display icmpv6 statistics [ interface interface-type interface-number ] command to check the statistics about ICMPv6 messages sent and received on the interface.
- If the value of Neighbor solicit under the Sent packets field on the source end does not increase, the source end does not send NS messages. This indicates that the fault occurs in the direction from the source end to the destination end.
- If the value of Neighbor solicit under the Sent packets field on the source end increases but the value of Neighbor advert under the Received packets field on the source end, the value of Neighbor advert under the Sent packets field on the destination end, and the value of Neighbor solicit under the Received packets on the destination end do not increase, the source end has sent NS messages, but the destination end does not receive them. This indicates that the fault occurs in the direction from the source end to the destination end.
- If the value of Neighbor solicit under the Sent packets field on the source end and the value of Neighbor solicit under the Received packets field on the destination end increase but the value of Neighbor advert under the Received packets field on the source end and the value of Neighbor advert under the Sent packets field on the destination end do not increase, the source end has sent NS messages but does not receive NA messages; the destination end has received NS messages but does not send NA messages. This indicates that the fault occurs in the direction from the destination end to the source end.
- If the value of Neighbor solicit under the Sent packets field on the source end, the value of Neighbor advert under the Sent packets field on the destination end, and the value of Neighbor solicit under the Received packets field on the destination end increase but the value of Neighbor advert under the Received packets field on the source end does not increase, the source end has sent NS messages but does not receive NA messages; the destination end has received NS messages and sent NA messages. This indicates that the fault occurs in the direction from the destination end to the source end.
- If the values of Neighbor solicit under the Sent packets field and Neighbor advert under the Received packets field on the source end and the values of Neighbor advert under the Sent packets field and Neighbor solicit under the Received packets field on the destination end all increase, the source end has sent NS messages and received NA messages; the destination end has received NS messages and sent NA messages. This indicates that messages are sent and received normally in both directions.
<HUAWEI> display icmpv6 statistics interface gigabitethernet 1/0/0 ICMPv6 protocol: Sent packets: Total : 12 Unreached : 0 Prohibited : 0 Hop count exceeded : 0 Parameter problem : 0 Too big : 0 Echoed : 0 Echo replied : 0 Router solicit : 0 Router advert : 0 Neighbor solicit : 12 Neighbor advert : 0 Redirected : 0 Rate limited : 0 Received packets: Total : 0 Format error : 0 Checksum error : 0 Too short : 0 Bad code : 0 Bad length : 0 Unknown info type : 0 Unknown error type : 0 Unreached : 0 Prohibited : 0 Hop count exceeded : 0 Parameter problem : 0 Too big : 0 Echoed : 0 Echo replied : 0 Router solicit : 0 Router advert : 0 Neighbor solicit : 0 Neighbor advert : 0 Redirected : 0 Rate limited : 0Then, run the display ipv6 statistics [ interface interface-name | interface interface-type interface-number ] command to check IPv6 traffic statistics. The type of NS message, such as Multicast, should be displayed.<HUAWEI> display ipv6 statistics interface gigabitethernet 1/0/0 IPv6 protocol: Sent packets: Total : 12 Local sent out : 12 Forwarded : 0 Raw packets : 12 Discarded : 0 Fragmented : 0 Fragments : 0 Fragments failed : 0 Multicast : 12 Received packets: Total : 0 Local host : 0 Hop count exceeded : 0 Header error : 0 Too big : 0 Routing failed : 0 Address error : 0 Protocol error : 0 Truncated : 0 Option error : 0 Fragments : 0 Reassembled : 0 Reassembly timeout : 0 Multicast : 0 Extension header: Hop-by-hop options : 0 Mobility header : 0 Destination options : 0 Routing header : 0 Fragment header : 0 Authentication header : 0 Encapsulation header : 0 No header : 0 TLV length error : 0 Header length error : 0 Unknown header type : 0 Unknown TLV type : 0
- Locate the direction in which the fault occurs. You can also run the reset ipv6 nd packet statistics all command on the source and destination ends to clear IPv6 traffic statistics, run the ping ipv6 command to trigger ND message negotiation, and then run the display ipv6 nd packet statistics command to check ND message statistics. If the NS message count is the same as the NA message count, they are sent and received properly.
<HUAWEI> display ipv6 nd packet statistics Sent Packet Statistics: ------------------------------------------------------------------------------- Type NS NA RS RA ------------------------------------------------------------------------------- Total 0 0 0 0 Source IP Unspecified 0 - - - Destination IP Unicast 0 0 - 0 Multicast 12 0 0 0 Target IP Linklocal 0 0 - - Global 0 0 - - ------------------------------------------------------------------------------- Received Packet Statistics: -------------------------------------------------------------------------------------- Type NS NA RS RA ND_MISS -------------------------------------------------------------------------------------- Recv Total 0 0 0 0 12 Valid Total 0 0 0 0 12 Source IP Unspecified 0 - - - - Destination IP Unicast 0 12 0 0 - Multicast 0 0 0 0 - Target IP Linklocal 0 0 - - - Global 0 0 - - -
- Locate the faulty node along the direction in which the fault occurs.Enable ND message debugging and then run the ping ipv6 -c echo-number destination-ipv6-address command. Check whether the source end has sent NS messages and received NA messages and whether the destination end has received NS messages and sent NA messages. Locate the faulty node based on the message sending and receiving information.
<HUAWEI> debugging ipv6 nd interface gigabitethernet 1/0/0 <HUAWEI> terminal debugging <HUAWEI> terminal monitor <HUAWEI> ping ipv6 -c 1 2001:db8::2 PING 2001:db8::2 : 56 data bytes, press CTRL_C to break Request time out ---2001:db8::2 ping statistics--- 1 packet(s) transmitted 0 packet(s) received 100.00% packet loss round-trip min/avg/max=0/0/0 ms Mar 30 2021 08:37:20.623 HUAWEI %%01ND/7/packet(d):CID=0x80730411;On The Interface gigabitethernet 1/0/0, Received NDMISS: 2001:db8::2 Mar 30 2021 08:37:20.623 HUAWEI %%01ND/7/packet(d):CID=0x80730411;On The Interface gigabitethernet 1/0/0, Adding NB Entry: 2001:db8::2 NB State : INCOMPLETE Mar 30 2021 08:37:20.623 HUAWEI %%01ND/7/packet(d):CID=0x80730411;On The Interface gigabitethernet 1/0/0, Sending NS to 2001:db8::FF00:2, IP6(Version = 6, TrafficClass = 192, FlowLabel = 0, PayloadLength = 32, HopLimit = 255, NextHeader = 58, Src = 2001:db8::1, Dst = 2001:db8::FF00:2), ICMP6(Type = 135(NS), Code = 0, Checksum = 0x8E98, Reserved = 0, TargetAddr = 2001:db8::2, Type = 1, Length = 1, SrcLLAddr = 00e0-fc12-3456) Mar 30 2021 08:37:20.713 HUAWEI %%01ND/7/packet(d):CID=0x80730411;On The Interface gigabitethernet 1/0/0, Sending NS to 2001:db8::FF00:2, IP6(Version = 6, TrafficClass = 192, FlowLabel = 0, PayloadLength = 32, HopLimit = 255, NextHeader = 58, Src = 2001:db8::1, Dst = 2001:db8::FF00:2), ICMP6(Type = 135(NS), Code = 0, Checksum = 0x8E98, Reserved = 0, TargetAddr = 2001:db8::2, Type = 1, Length = 1, SrcLLAddr = 00e0-fc12-3456)
- Check the IPv6 packet statistics of CPCAR to determine whether packets are sent to the CPU normally.
For router series products, run the display cpu-defend statistics-all command in the diagnostic view to check the attack-defense packet statistics of CPCAR.
[~HUAWEI-diagnose] display cpu-defend statistics-all slot 2 Index CarID Packet-Info Passed Packets Dropped Packets ============================================================================================== ... 625 314 MAC_ADD_MSG 1 0 684 645 IPV6_MC_NS 12 0 1161 334 SAID_BIGHEART_PKT 247 0 1231 234 IGP_Maintain_Unit Packet 8 0
For ATN series products, run the display icmpv6 rate-limit statistics command to check the statistics about IPv6 packets sent to the CPU by CPCAR.<HUAWEI> display icmpv6 rate-limit statistics Interface Total-Packets Passed-Packets Dropped-Packets -------------------------------------------------------------------------------- GigabitEthernet0/2/9 0 0 0 GigabitEthernet0/2/23 17 17 0 GigabitEthernet0/2/7 0 0 0 Eth-Trunk5 0 0 0 Eth-Trunk0 0 0 0 -------------------------------------------------------------------------------- Total 17 17 0
- If the fault persists, contact technical support and provide the following information:
- Results of the preceding steps
- Configuration file, logs, and alarms of the device
Troubleshooting Guidelines for IPv6 Ping Failures
Symptom
After IPv6 is configured, a destination IP address fails to be pinged. Specifically, after sending a ping request, a device does not receive a response from the peer.
Troubleshooting Roadmap
The troubleshooting roadmap for this type of fault is as follows:
- Check whether the interface state is normal, whether the IPv6 function is enabled, and whether the IPv6 address is valid.
- Check whether routes are normal.
- Check whether ND negotiation is normal.
- Check whether the total number of packets sent and the total number of packets received are correct to determine whether the fault occurs in the direction from the source end to the destination end or in the reverse direction. As a fault may occur in either the packet transmit or receive direction of any device, determine the direction and node where the fault occurs so as to narrow down the fault scope.
- Perform a tracert operation to locate the node where packets are lost. Then, check the routing information and packet receiving status on the faulty node.
- Configure a traffic policy on the faulty node. Then, check the traffic statistics of this policy to determine whether packets are sent and received normally.
Procedure
Save the results of each troubleshooting step. If the fault persists after following this procedure, these results are needed for further troubleshooting.
- Run the display ipv6 interface interface-type interface-number command to check whether the interface state is normal.
- Check whether the physical state of the interface is up. If the state is displayed as DOWN, check whether the physical connection is normal.
- Check whether IPv6 is enabled on the interface. If not, run the ipv6 enable command to enable it.
- Check whether the IPv6 address of the interface is correct.
<HUAWEI> display ipv6 interface GigabitEthernet 0/2/2 GigabitEthernet0/2/2 current state : UP IPv6 protocol current state : DOWN IPv6 is enabled, link-local address is FE80::3ABA:1800:324:8801 Global unicast address(es): 2001:db8::1, subnet is 2001:db8::/32 Joined group address(es): FF02::1:FF00:1 FF02::2 FF02::1 FF02::1:FFE1:4929 MTU is 1500 bytes ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds ND retransmit interval is 1000 milliseconds
- Run the display ipv6 routing-table destination-address command to check whether there is a route to the destination address.
- If a route does not exist, go to Step 3.
- If a route exists, go to Step 4.
<HUAWEI> display ipv6 routing-table Routing Table : _Public_ Destinations : 1 Routes : 1 Destination : 2001:db8:1::1 PrefixLength : 128 NextHop : 2001:db8:2::1 Preference : 0 Cost : 0 Protocol : Direct RelayNextHop : :: TunnelID : 0x0
- Run the display ipv6 neighbors command to check information about the IPv6 neighbor. IPv6 Address indicates the neighbor's IPv6 address, and Link-layer indicates the neighbor's MAC address. State indicates the state of the neighbor relationship, with REACH meaning that the neighbor is reachable. If State is REACH, protocol packets are sent and received normally. If State is not REACH, ND negotiation is abnormal. Rectify faults by referring to Troubleshooting Guidelines for IPv6 ND Negotiation Failures.
<HUAWEI> display ipv6 neighbors ----------------------------------------------------------------------------- IPv6 Address : 2001:db8::1 Link-layer : 00e0-fc12-3456) State : REACH Interface : GE0/2/2 Age : 0 VLAN : 1 CEVLAN : - VPN name : - Is Router : TRUE Secure FLAG : UN-SECURE BD : - ----------------------------------------------------------------------------- Total: 1 Dynamic: 1 Static: 0
- Check whether the fault occurs in the direction from the source end to the destination end or in the reverse direction.
Run the reset ipv6 statistics command on the source and destination ends to delete existing IPv6 statistics, run the ping ipv6 command to perform a ping operation, and then run the display icmpv6 statistics [ interface interface-type interface-number ] command to check the statistics about ICMPv6 messages sent and received on the interface.
- If the value of Echoed under the Sent packets field on the source end does not increase, the source end does not send IPv6 packets to the destination end. This indicates that the fault occurs in the direction from the source end to the destination end.
- If the value of Echoed under the Sent packets field on the source end increases but the value of Echo replied under the Received packets field on the source end, the value of Echo replied under the Sent packets field on the destination end, and the value of Echoed under the Received packets on the destination end do not increase, the source end has sent requests; the destination end does not receive them. This indicates that the fault occurs in the direction from the source end to the destination end.
- If the value of Echoed under the Sent packets field on the source end and the value of Echoed under the Received packets field on the destination end increase but the value of Echo replied under the Received packets field on the source end and the value of Echo replied under the Sent packets field on the destination end do not increase, the source end has sent requests; the destination end has received the requests, but does not respond to them. This indicates that the fault occurs in the direction from the destination end to the source end.
- If the value of Echoed under the Sent packets field on the source end, the value of the Echo replied field under the Sent packets field on the destination end, and the value of Echoed under the Received packets field on the destination end increase but the value of Echo replied under the Received packets field on the source end does not increase, the source end has sent requests, but does not receive responses; the destination end has received the requests and sent responses. This indicates that the fault occurs in the direction from the destination end to the source end.
- If the values of Echoed under the Sent packets field and Echo replied under the Received packets field on the source end and the values of Echo replied under the Sent packets field and Echoed under the Received packets field on the destination end all increase, the source end has sent requests and received responses; the destination end has received requests and sent responses. This indicates that packets are sent and received normally in both directions. In this case, the ping failure may be caused by a long link transmission delay. Run the ping ipv6 -t timeout command to increase the timeout period for responding to ICMPv6 packets.
<HUAWEI> display icmpv6 statistics interface GigabitEthernet0/2/2 ICMPv6 protocol: Sent packets: Total : 12 Unreached : 0 Prohibited : 0 Hop count exceeded : 0 Parameter problem : 0 Too big : 0 Echoed : 12 Echo replied : 0 Router solicit : 0 Router advert : 0 Neighbor solicit : 12 Neighbor advert : 0 Redirected : 0 Rate limited : 0 Received packets: Total : 0 Format error : 0 Checksum error : 0 Too short : 0 Bad code : 0 Bad length : 0 Unknown info type : 0 Unknown error type : 0 Unreached : 0 Prohibited : 0 Hop count exceeded : 0 Parameter problem : 0 Too big : 0 Echoed : 0 Echo replied : 0 Router solicit : 0 Router advert : 0 Neighbor solicit : 0 Neighbor advert : 0 Redirected : 0 Rate limited : 0
- Locate the faulty node according to the direction in which the fault occurs. If the fault occurs in the direction from the source end to the destination end, check the source end first. If the fault occurs in the direction from the destination end to the source end, check the destination end first.
Run the tracert ipv6 dest-ip-address command to locate the position where packets are lost. The following output indicates that the problem occurs on the next hop (IP address: 3 * * *) of 2001:DB8:2::2. Repeat Step 2 to Step 5 on the faulty node to check whether routing and packet sending and receiving are normal.
<HUAWEI> tracert ipv6 2001:DB8:2::1 traceroute to 2001:DB8:2::1 64 hops max,60 bytes packet 1 2001:DB8:1::2 81 ms 1 ms 1 ms 2 2001:DB8:2::2 142 ms 1 ms 2 ms 3 * * *
- Configure a traffic policy on the faulty node. Then, check the traffic statistics of this policy to determine whether packets are sent and received normally.
- Run the rule command in the ACL6 view to configure rules, and then define and apply a traffic policy.
<HUAWEI> system-view [~HUAWEI] acl ipv6 number 3333 [*HUAWEI-acl6-advance-3333] rule 5 permit icmpv6 source 2001:db8:1::1 64 destination 2001:db8:2::1 64 icmp6-type echo [*HUAWEI-acl6-advance-3333] rule 10 permit icmpv6 source 2001:db8:1::1 64 destination 2001:db8:2::1 64 icmp6-type echo-reply [*HUAWEI-acl6-advance-3333] rule 15 permit icmpv6 source 2001:db8:2::1 64 destination 2001:db8:1::1 64 icmp6-type echo [*HUAWEI-acl6-advance-3333] rule 20 permit icmpv6 source 2001:db8:2::1 64 destination 2001:db8:1::1 64 icmp6-type echo-reply
[~HUAWEI] traffic classifier c1 operator or [*HUAWEI-classifier-c1] if-match ipv6 acl 3333
[~HUAWEI] traffic behavior b1 [*HUAWEI-behavior-b1] permit
[~HUAWEI] traffic policy p1 [*HUAWEI-trafficpolicy-p1] classifier c1 behavior b1 [~HUAWEI] interface gigabitethernet 0/1/0 [~HUAWEI-GigabitEthernet0/1/0] traffic-policy p1 inbound
- Run the ping ipv6 command, with the number of ICMPv6 echo request packets to be sent being specified. Then, run the display traffic policy statistics interface command to check the traffic statistics of the policy in the inbound and outbound directions, so that you can determine whether packets are sent and received normally.Configure the device to send a specified number of ICMPv6 echo request packets to check whether an IPv6 host is reachable.
[~HUAWEI-classifier-3333] ping ipv6 -c 1 2001::2 PING 2001::2 : 56 data bytes, press CTRL_C to break Reply from 2001::2 bytes=56 Sequence=1 hop limit=64 time=7 ms --- 2001::2 ping statistics--- 1 packet(s) transmitted 1 packet(s) received 0.00% packet loss round-trip min/avg/max=7/7/7 msCheck detailed traffic statistics of the policy in the inbound direction of the interface.[~HUAWEI-classifier-3333] display traffic policy statistics interface GigabitEthernet 0/2/2 inbound verbose rule-based Interface: GigabitEthernet0/2/2 Traffic policy inbound: 3333 Traffic policy applied at 2021-07-09 17:01:46 Statistics enabled at 2021-07-09 17:01:46 Statistics last cleared: Never Rule number: 0 IPv4, 4 IPv6 Current status: OK! Classifier: 3333 operator or if-match ipv6 acl 3333 rule 5 permit icmpv6 source 2001::1/128 destination 2001::2/128 icmp6-type echo 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 10 permit icmpv6 source 2001::1/128 destination 2001::2/128 icmp6-type echo-reply 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 15 permit icmpv6 source 2001::2/128 destination 2001::1/128 icmp6-type echo 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 20 permit icmpv6 source 2001::2/128 destination 2001::1/128 icmp6-type echo-reply 126 bytes, 1 packets Last 30 seconds rate 0 pps, 0 bpsCheck detailed traffic statistics of the policy in the outbound direction of the interface.[~~HUAWEI-classifier-3333] display traffic policy statistics interface GigabitEthernet 0/2/2 outbound verbose rule-based Interface: GigabitEthernet0/2/2 Traffic policy outbound: 3333 Traffic policy applied at 2021-07-09 17:01:47 Statistics enabled at 2019-21-09 17:01:47 Statistics last cleared: Never Rule number: 0 IPv4, 4 IPv6 Current status: OK! Classifier: 3333 operator or if-match ipv6 acl 3333 rule 5 permit icmpv6 source 2001::1/128 destination 2001::2/128 icmp6-type echo 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 10 permit icmpv6 source 2001::1/128 destination 2001::2/128 icmp6-type echo-reply 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 15 permit icmpv6 source 2001::2/128 destination 2001::1/128 icmp6-type echo 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 20 permit icmpv6 source 2001::2/128 destination 2001::1/128 icmp6-type echo-reply 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps - Run the ping ipv6 command, with the interface for receiving ICMPv6 echo request packets being specified. Then, run the display traffic policy statistics interface command to check the traffic statistics of the policy in the inbound and outbound directions of the interface, so that you can determine whether the packets received from the interface are forwarded normally.Configure the device to receive ICMPv6 echo request packets from a specified interface to check whether an IPv6 host is reachable.
[~HUAWEI-classifier-3333] ping ipv6 -si GigabitEthernet 0/2/2 -c 1 2001::2 PING 2001::2 : 56 data bytes, press CTRL_C to break Reply from 2001::2 bytes=56 Sequence=1 hop limit=64 time=6 ms --- 2001::2 ping statistics--- 1 packet(s) transmitted 1 packet(s) received 0.00% packet loss round-trip min/avg/max=6/6/6 msCheck detailed traffic statistics of the policy in the inbound direction of the interface.[~HUAWEI-classifier-3333] display traffic policy statistics interface GigabitEthernet 0/2/2 inbound verbose rule-based Interface: GigabitEthernet0/2/2 Traffic policy inbound: 3333 Traffic policy applied at 2021-07-09 17:01:46 Statistics enabled at 2021-07-09 17:01:46 Statistics last cleared: Never Rule number: 0 IPv4, 4 IPv6 Current status: OK! Classifier: 3333 operator or if-match ipv6 acl 3333 rule 5 permit icmpv6 source 2001::1/128 destination 2001::2/128 icmp6-type echo 126 bytes, 1 packets Last 30 seconds rate 1 pps, 48 bps rule 10 permit icmpv6 source 2001::1/128 destination 2001::2/128 icmp6-type echo-reply 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 15 permit icmpv6 source 2001::2/128 destination 2001::1/128 icmp6-type echo 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 20 permit icmpv6 source 2001::2/128 destination 2001::1/128 icmp6-type echo-reply 252 bytes, 2 packets Last 30 seconds rate 1 pps, 96 bpsCheck detailed traffic statistics of the policy in the outbound direction of the interface.[~HUAWEI-classifier-3333] display traffic policy statistics interface GigabitEthernet 0/2/2 outbound verbose rule-based Interface: GigabitEthernet0/2/2 Traffic policy outbound: 3333 Traffic policy applied at 2021-07-09 17:01:47 Statistics enabled at 2021-07-09 17:01:47 Statistics last cleared: Never Rule number: 0 IPv4, 4 IPv6 Current status: OK! Classifier: 3333 operator or if-match ipv6 acl 3333 rule 5 permit icmpv6 source 2001::1/128 destination 2001::2/128 icmp6-type echo 126 bytes, 1 packets Last 30 seconds rate 1 pps, 40 bps rule 10 permit icmpv6 source 2001::1/128 destination 2001::2/128 icmp6-type echo-reply 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 15 permit icmpv6 source 2001::2/128 destination 2001::1/128 icmp6-type echo 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps rule 20 permit icmpv6 source 2001::2/128 destination 2001::1/128 icmp6-type echo-reply 0 bytes, 0 packets Last 30 seconds rate 0 pps, 0 bps
- Run the rule command in the ACL6 view to configure rules, and then define and apply a traffic policy.
- If the fault persists, contact technical support and provide the following information:
- Results of the preceding steps
- Configuration file, logs, and alarms of the device
Troubleshooting Guidelines for IPv6 BGP Peer Relationship Establishment Failures
Symptom
After basic IPv6 BGP functions are configured on an IPv6 BGP network, a BGP peer relationship fails to be established between two devices.
Troubleshooting Roadmap
The troubleshooting roadmap for this type of fault is as follows:
- Check the BGP IPv6 peer relationship state.
- Ping the peer to check the network connectivity.
- Check the IPv6 TCP connection state and information about TCP IPv6 packets sent and received to determine the state of packet exchange on the IPv6 BGP connection.
Procedure
Save the results of each troubleshooting step. If the fault persists after following this procedure, these results are needed for further troubleshooting.
- Check whether the peer relationship is normal.
- For a public network peer, run the display bgp ipv6 peer command to check whether the BGP IPv6 peer relationship is in the Established state. If the state is not Established, the peer relationship is abnormal.
- For a private network peer, run the display bgp vpnv6 all peer command to check whether the BGP IPv6 peer relationship is in the Established state. If the state is not Established, the peer relationship is abnormal.
<HUAWEI> display bgp ipv6 peer BGP Local router ID : 10.0.0.1 local AS number : 100 Total number of peers : 1 Peers in established state : 1 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 2001:DB8:20::21 4 200 17 19 0 00:09:59 Established 3
<HUAWEI> display bgp vpnv6 all peer BGP local router ID : 10.1.1.1 Local AS number : 100 Total number of peers : 2 Peers in established state : 2 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.2.2.2 4 100 210 220 0 02:42:55 Established 1 Peer of IPv6-family for vpn instance : VPN-Instance vpn1 : 2001:DB8:1::2 4 65410 205 178 0 02:42:53 Established 0
- Run the ping ipv6 command to check whether the connectivity between the two devices. You may also specify the source address to check whether routing is normal.
- If the ping succeeds, there are reachable routes between the BGP peers. In this case, go to Step 3.
- If the ping fails, rectify faults by referring to Troubleshooting Guidelines for IPv6 Ping Failures.
<HUAWEI> ping ipv6 -a 2001:db8:2::1 -dscp 8 2001:db8:1::1 PING 2001:db8:1::1: 56 data bytes, press CTRL_C to break Reply from 2001:db8:1::1 bytes=56 Sequence=1 hop limit=62 time = 170 ms Reply from 2001:db8:1::1 bytes=56 Sequence=2 hop limit=62 time = 140 ms Reply from 2001:db8:1::1 bytes=56 Sequence=3 hop limit=62 time = 150 ms Reply from 2001:db8:1::1 bytes=56 Sequence=4 hop limit=62 time = 140 ms Reply from 2001:db8:1::1 bytes=56 Sequence=5 hop limit=62 time = 170 ms --- 2001:db8:1::1 ping statistics --- 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 140/154/170 ms
- Run the display tcp ipv6 status command to check the IPv6 TCP connection state. If State is Established, the connection has been established. If the TCP connection is abnormal, run the debugging tcp ipv6 packet src-ip src-address6 dest-ip dest-address6 and debugging tcp packet dest-ip dest-address6 > src-ip src-address6 commands to check information about TCP IPv6 packets sent and received. Then, go to Step 4.
<HUAWEI> display tcp ipv6 status * - MD5 Authentication is enabled. # - Keychain Authentication is enabled. ------------------------------------------------------------------------------------------------------- Cid/SocketID Local Address Foreign Address VPNID State ------------------------------------------------------------------------------------------------------- 0x8093041E/3 ::->830 ::->0 4294967295 Established 0x8093041E/5 ::->22 ::->0 4294967295 Established -------------------------------------------------------------------------------------------------------
- If the fault persists, contact technical support and provide the following information:
- Results of the preceding steps
- Configuration file, logs, and alarms of the device
Troubleshooting Guidelines for IPv6 BGP Traffic Interruptions or Flapping
Symptom
After IPv6 BGP is configured, a BGP peer relationship is torn down or alternates between up and down. As a result, services are interrupted.
Troubleshooting Roadmap
The troubleshooting roadmap for this type of fault is as follows:
- Check whether both ends of the peer relationship can learn routes normally.
- Check the log information about the BGP peer and locate the fault according to the cause of the relationship teardown.
- Check whether import and export policies are configured and whether BGP packets sent from and to the peer are filtered out by them.
Procedure
Save the results of each troubleshooting step. If the fault persists after following this procedure, these results are needed for further troubleshooting.
- Run the display bgp ipv6 routing-table command to check whether the two ends of the peer relationship learn routes normally.
- If their routing tables do not contain routes to BGP next hops, they do not learn routes normally. In this case, rectify route learning faults.
- If route learning is normal, go to Step 2.
<HUAWEI> display bgp ipv6 routing-table BGP Local router ID is 10.1.1.2 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete RPKI validation codes: V - valid, I - invalid, N - not-found *>i Network : 2001:DB8:100::100 PrefixLen : 128 NextHop : 2001:DB8:12::1 Duration : 0d05h46m16s Peer : 2001:DB8:12::1 Path/Ogn : ? * i NextHop : 2001:DB8:112::1 Duration : 0d05h46m16s Peer : 2001:DB8:112::1 Path/Ogn : ? *>i Network : 2001:DB8:111::111 PrefixLen : 128 NextHop : 2001:DB8:12::1 Duration : 0d05h46m16s Peer : 2001:DB8:12::1 Path/Ogn : ?
- Check the log information about the peer. Rectify faults according to the information displayed.
- For a BGP IPv6 peer, run the display bgp ipv6 peer log-info command to check the log information of the peer.
- For a BGP VPNv6 peer, run the display bgp vpnv6 peer log-info command to check the log information of the peer.
Check the cause of the peer relationship teardown according to the Error Code and Error Subcode fields. For example, the value 6(Other Configuration Change) indicates that the peer relationship is torn down due to configuration changes. For details about the Error Subcode field, see en-us_topic_0000001387225566.xml#EN-US_TOPIC_0000001387225566/tab_error_code.
Common causes of peer relationship teardown and corresponding troubleshooting methods are as follows:
- If Error Code is 4 and Error Subcode is 0, the hold timer has expired. Run the display bgp routing-table verbose command on both ends to check whether the route timestamp is changed at the fault or recovery time. If it is changed, the problem occurs because routes are deleted or changed. In this case, rectify routing faults.
- If Error Code is 5 and Error Subcode is 0, the finite state machine is abnormal. On the peer device, check the log information of its peer.
- If Error Code is 5 and Error Subcode is 0 on the peer device and the relationship teardown time is the same as that on the local device, check whether both BGP ends are configured to perform MD5 authentication when a TCP connection is established. If MD5 authentication is not configured, TCP attacks may occur. Run the peer password command on both ends to configure MD5 authentication.
- If Error Code is not 5 and Error Subcode is not 0, analyze and rectify faults on the peer device.
- If Error Code is 6 and Error Subcode is 1, the number of prefixes has exceeded the maximum value, which may be because an excessive number of routes are received. In this case, check whether the peer route-limit command is run on the peer to limit the number of routes that can be received from the specified peer. If the command is run, reduce the number of routes that can be sent from the peer. Alternatively, run the peer route-limit alert-only command. With this command executed, when the number of received routes reaches the maximum number, the device sends an alarm and stops receiving excess routes, but does not tear down the peer relationship.
- If Error Code is 6 and Error Subcode is 3, the peer is de-configured. View logs to check whether the undo peer enable command has been run to disable the device from exchanging routing information with the peer. If the command has been run, run the peer enable command again to restore the configuration.
- If Error Code is 6 and Error Subcode is 9, the BFD session is disconnected, which may be because the BFD session is down. Restore the BFD session based on the BFD_1.3.6.1.4.1.2011.5.25.38.3.13 hwBfdIPv6SessDown alarm information.
- If both Error Code and Error Subcode are 6, other configurations have been changed. Run the display interface command and use the Last line protocol up time field to determine whether the interface has ever gone down. If so, the problem will be automatically resolved when the interface goes up. If not, go to Step 3.
- For other causes of peer relationship teardown, go to Step 4.
<HUAWEI> display bgp ipv6 peer 2001:DB8:1::2 log-info Peer : 2001:DB8:1::2 Date/Time : 2021/06/09 11:53:21 State : Up Date/Time : 2021/06/09 11:53:09 State : Dow Error Code : 6(CEASE) Error Subcode: 6(Other Configuration Change) Notification : Receive Notification Date/Time : 2021/06/09 10:34:05 State : Up
Table 1-8 Description of BGP error codesError Code
Error Subcode
1: message header error
1: connection unsynchronized
2: incorrect message length
3: incorrect message type
2: Open message error
1: unsupported version number
2: incorrect peer AS
3: incorrect BGP identifier
4: unsupported optional parameter
5: authentication failure
6: unacceptable hold time
7: unsupported capability
3: Update message error
1: malformed attribute list
2: unrecognized well-known attribute
3: missing well-known attribute
4: incorrect attribute flag
5: incorrect attribute length
6: Invalid Origin attribute
7: AS routing loop
8: invalid Next_Hop attribute
9: incorrect optional attribute
10: invalid network field
11: malformed AS_Path
4: hold timer timeout
0: no special error subcode defined
5: finite state machine error
0: no special error subcode defined
6: termination
1: prefix excess
2: administrative shutdown
3: peer de-configured
4: administrative reset
5: connection failure
6: other configurations changed
7: connection conflict
8: resource shortage
9: BFD session disconnection
- Run the display current-configuration configuration bgp command on both ends to check whether export and import policies are configured.
- If export and import policies are configured on both ends, check whether the target route is filtered out by the policies. If this is the case, modify the policies.
- If export and import policies are not configured on the two ends, go to Step 3.
<HUAWEI> display current-configuration configuration bgp # bgp 100 peer 2001:db8:1::1 as-number 100 # ipv6-family unicast undo synchronization filter-policy ipv6-prefix aaa import filter-policy ipv6-prefix aaa export peer 2001:db8:1::1 enable peer 2001:db8:1::1 filter-policy acl-name acl5 import peer 2001:db8:1::1 filter-policy acl-name acl6 export peer 2001:db8:1::1 as-path-filter 1 import peer 2001:db8:1::1 as-path-filter 1 export
- If the fault persists, contact technical support and provide the following information:
- Results of the preceding steps
- Configuration file, logs, and alarms of the device
- IPv6 Basics
- Common IPv6 Fault Locating Commands
- Troubleshooting Guidelines for IPv6 ND Negotiation Failures
- Troubleshooting Guidelines for IPv6 Ping Failures
- Troubleshooting Guidelines for IPv6 BGP Peer Relationship Establishment Failures
- Troubleshooting Guidelines for IPv6 BGP Traffic Interruptions or Flapping