2016

Example for Configuring BGP Auto FRR

As shown in Figure 1, Router A belongs to AS 100; Router B, Router C, and Router D belong to AS 200. BGP Auto FRR needs to be configure so that the route from Router A to Router D can have backup forwarding information.

Figure 1 Networking diagram of configuring BGP Auto FRR

Configuration Roadmap

The configuration roadmap is as follows:

Configure EBGP connections between Router A and Router B and between Router A and Router C. Configure IBGP connections between Router D and Router B, and between Router D and Router C.
Configure routing policies on Router B and Router C to change the MED values of routes to Router D to facilitate route selection.
Configure BGP Auto FRR on Router A.

Data Preparation

To complete the configuration, you need the following data:

Router IDs and AS numbers of Router A, Router B, Router C, and Router D
Names of routing policies and MED values of routes on Router B and Router C

Procedure

Configure IP addresses for interfaces. The configuration details are not mentioned here.
Configure EBGP connections between Router A and Router B, and between Router A and Router C. Configure IBGP connections between Router B and Router D, and between Router C and Router D. # Configure EBGP connections on Router A.
```
<RouterA> system-view
```
```
[RouterA] bgp 100
```
```
[RouterA-bgp] router-id 1.1.1.1
```
```
[RouterA-bgp] peer 10.1.1.2 as-number 200
```
```
[RouterA-bgp] peer 10.2.1.2 as-number 200
```
NOTE:

The configurations of Router B and Router C are the same as that of Router A, and the detailed configurations are not mentioned here.

# Configure IBGP connections on Router D.
```
<RouterD> system-view
```
```
[RouterD] bgp 200
```
```
[RouterD-bgp] router-id 4.4.4.4
```
```
[RouterD-bgp] peer 10.3.1.1 as-number 200
```
```
[RouterD-bgp] peer 10.4.1.1 as-number 200
```
NOTE:

The configurations on Router B and Router C are similar, and the detailed configurations are not mentioned here.

Configuring routing policies on Router B and Router C so that the MED values of routes to Router D are different # Configure a routing policy on Router B.

<RouterB> system-view

[RouterB] route-policy rtb permit node 10

[RouterB-route-policy] apply cost 80

[RouterB-route-policy] quit

[RouterB] bgp 200

[RouterB-bgp] ipv4-family unicast

[RouterB-bgp-af-ipv4] peer 10.1.1.1 route-policy rtb export

# Configure a routing policy on Router C.

<RouterC> system-view

[RouterC] route-policy rtc permit node 10

[RouterC-route-policy] apply cost 120

[RouterC-route-policy] quit

[RouterC] bgp 200

[RouterC-bgp] ipv4-family unicast

[RouterC-bgp-af-ipv4] peer 10.2.1.1 route-policy rtc export

# Advertise a route to 4.4.4.4/32 on Router D.

[RouterD] bgp 200

[RouterD-bgp] ipv4-family unicast

[RouterD-bgp] network 4.4.4.4 32

# Run the display ip routing-table verbose command on Router A to check detailed information about the learned route to 4.4.4.4/32.

<RouterA> display ip routing-table 4.4.4.4 32 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1

Destination: 4.4.4.4/32
     Protocol: BGP             Process ID: 0
   Preference: 255                   Cost: 80
      NextHop: 10.1.1.2         Neighbour: 10.1.1.2
        State: Active Adv             Age: 00h00m12s
          Tag: 0                 Priority: low
        Label: NULL               QoSInfo: 0x0
   IndirectID: 0x4
 RelayNextHop: 0.0.0.0          Interface: Pos1/0/0
     TunnelID: 0x0                  Flags:  D

Because the MED value of the route learnt from Router B is smaller, on Router A, the route to 4.4.4.4/32 selects the path RouterA→RouterB→RouterD. Because FRR is not configured, no backup information is available.

Enabling BGP Auto FRR on Router A, and checking the routing information # Enable BGP Auto FRR on Router A.

<RouterA> system-view

[RouterA] bgp 100

[RouterA-bgp] ipv4-family unicast

[RouterA-bgp-af-ipv4] auto-frr

# After the configuration, run the display ip routing-table verbose command on Router A to check the routing information.

<RouterA> display ip routing-table 4.4.4.4 32 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1

Destination: 4.4.4.4/32
     Protocol: BGP             Process ID: 0
   Preference: 255                   Cost: 80
      NextHop: 10.1.1.2         Neighbour: 10.1.1.2
        State: Active Adv             Age: 00h52m45s
          Tag: 0                 Priority: low
        Label: NULL               QoSInfo: 0x0
   IndirectID: 0x4
 RelayNextHop: 0.0.0.0          Interface: Pos1/0/0
     TunnelID: 0x0                  Flags:  D
    BkNextHop: 10.2.1.2       BkInterface: Pos2/0/0
      BkLabel: NULL           SecTunnelID: 0x0
 BkPETunnelID: 0x0        BkPESecTunnelID: 0x0
 BkIndirectID: 0x2

The preceding information shows that Router A has a backup next hop and a backup outbound interface to 4.4.4.4/32.

Configuration Files

Configuration file of Router A

#
 sysname RouterA
#
interface Pos1/0/0
 ip address 10.1.1.1 255.255.255.0
#
interface Pos2/0/0
  ip address 10.2.1.1 255.255.255.0
#
bgp 100
 router-id 1.1.1.1
 peer 10.1.1.2 as-number 200
 peer 10.2.1.2 as-number 200
#
 ipv4-family unicast
    auto-frr
#
return

Configuration file of Router B

#
 sysname RouterB
#
interface Pos1/0/0
 ip address 10.1.1.2 255.255.255.0
#
interface Pos2/0/0
  ip address 10.3.1.1 255.255.255.0
#
bgp 200
 router-id 2.2.2.2
 peer 10.1.1.1 as-number 100
 peer 10.3.1.2 as-number 200
#
 ipv4-family unicast 
    peer 10.1.1.1 route-policy rtb export
#
route-policy rtb permit node 10
 apply cost 80
#
return

Configuration file of Router C

#
 sysname RouterC
#
interface Pos1/0/0
 ip address 10.2.1.2 255.255.255.0
#
interface Pos2/0/0
 ip address 10.4.1.1 255.255.255.0
#
bgp 200
 router-id 3.3.3.3
 peer 10.2.1.1 as-number 100
 peer 10.4.1.2 as-number 200
 #
 ipv4-family unicast
    peer 10.2.1.1 route-policy rtc export
#
route-policy rtc permit node 10
 apply cost 120
#
return

Configuration file of Router D

#
 sysname RouterD
#
interface Pos1/0/0
 ip address 10.3.1.2 255.255.255.0
#
interface Pos2/0/0
  ip address 10.4.1.2 255.255.255.0
#
interface LoopBack1
 ip address 4.4.4.4 255.255.255.255
#
bgp 200
 router-id 4.4.4.4
 peer 10.3.1.1 as-number 200
 peer 10.4.1.1 as-number 200
 #
 ipv4-family unicast
  network 4.4.4.4 255.255.255.255
#
return

BGP Auto FRR

As a protection measure against faults over links, BGP Auto Fast Reroute (FRR) is applicable to networks with primary and backup links. With BGP Auto FRR, traffic can be switched between two BGP peers or next hops within sub-seconds.
With BGP Auto FRR, if a peer has multiple routes with the same prefix that are learned from different peers, the peer uses the optimal route as the primary link to forward packets and the less optimal route as a backup link. If the primary link fails, the peer rapidly notifies other peers that the BGP route has become unreachable and then switches traffic from the primary link to the backup link.

Usage Scenario

On the network shown in Figure 1, Device Y advertises a learned BGP route to Device X2 and Device X3 in AS 100; Device X2 and Device X3 then advertise the BGP route to Device X1 through RR. Therefore, Device X1 receives two routes whose next hops are Device X2 and Device X3 respectively. Then, Device X1 selects a route based on a configured routing policy. Assume that the route sent by Device X2 (Link A) is preferred. The route sent by Device X3 (Link B) then functions as a backup link.

Figure 1 Networking for BGP Auto FRR

If a node along Link A fails or faults occur on Link A, the next hop of the route from Device X1 to Device X2 becomes unavailable. If BGP Auto FRR is enabled on Device X1, the forwarding plane then quickly switches to Link B the traffic from Device X1 to Device Y, which ensures uninterrupted traffic transmission. In addition, Device X1 reselects the route sent by Device X3 based on the forwarding prefixes and then updates the FIB table.

BGP GR "Graceful Restart "

Graceful restart (GR) is one of the high availability (HA) technologies, which comprise a series of comprehensive technologies such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic engineering. As a fault-tolerant redundancy technology, GR ensures normal forwarding of data during the restart of routing protocols to prevent interruption of key services. Currently, GR has been widely applied to the master/slave switchover and system upgrade.
GR is usually used when the active route processor (RP) fails because of a software or hardware error, or used by an administrator to perform the master/slave switchover.

Prerequisite for Implementation

On a traditional routing device, a processor implements both control and forwarding. The processor finds routes based on routing protocols, and maintains the routing table and forwarding table of the device. Mid-range and high-end devices generally adopt the multi-RP structure to improve forwarding performance and reliability. The processor in charge of routing protocols is located on the main control board, whereas the processor responsible for data forwarding is located on the interface board. The design helps to ensure the continuity of packet forwarding on the interface board during the restart of the main processor. The technology that separates control from forwarding satisfies the prerequisite for GR implementation.
At present, a GR-capable device must have two main control boards. In addition, the interface board must have an independent processor and memory.

Related Concepts

The concepts related to GR are as follows:

GR Restarter: indicates a device that performs master/slave switchover triggered by the administrator or a failure. A GR Restarter must support GR.
GR Helper: indicates the neighbor of a GR Restarter. A GR Helper must support GR.
GR session: indicates a session, through which a GR Restarter and a GR Helper can negotiate GR capabilities.
GR time: indicates the time when the GR Helper finds that the GR Restarter is Down but keeps the topology information or routes obtained from the GR Restarter.
End-of-RIB (EOR): indicates BGP information, notifying a peer BGP that the first route upgrade is finished after the negotiation.
EOR timer: indicates a maximum time of a local device waiting for the EOR information sent from the peer. If the local device does not receive the EOR information from the peer within the EOR timer, the local device will select an optimal route from the current routes.

Principles

Principles of BGP GR are as follows:

During BGP peer relationship establishment, devices negotiate GR capabilities by sending supported GR capabilities to each other.
When detecting the master/slave switchover of the GR Restarter, a GR Helper does not delete the routing information and forwarding entries related to the GR Restarter within the GR time, but waits to re-establish a BGP connection with the GR Restarter.
After the master/slave switchover, the GR Restarter receives routes from all the negotiated peers with GR capabilities before the switchover, and starts the EOR timer. The GR Restarter selects a route when either of the following conditions is met:
- The GR Restarter receives the EOR information of all peers and the EOR timer is deleted.
- The EOR timer times out but the GR Restarter receives no EOR information from all peers.
The GR Restarter sends the optimal route to the GR Helper and the GR Helper starts the EOR timer. The GR Helper quits GR when either of the following conditions is met:
- The GR Helper receives the EOR information from the GR Restarter and the EOR timer is deleted.
- The EOR timer times out and the GR Helper receives no EOR information from the GR Restarter.

GR Reset

Currently, BGP does not support dynamic capability negotiation. Therefore, each time a new BGP capability (such as the IPv4, IPv6, VPNv4, and VPNv6 capabilities) is enabled on a BGP speaker, the BGP speaker tears down existing sessions with its peer and renegotiates BGP capabilities. This process will interrupt ongoing services.
To prevent the service interruptions, the CX600 provides the GR reset function that enables the CX600 to reset a BGP session in GR mode. With the GR reset function configured, when you enable a new BGP capability on the BGP speaker, the BGP speaker enters the GR state, resets the BGP session, and renegotiates BGP capabilities with the peer. In the whole process, the BGP speaker re-establishes the existing sessions but does not delete the routing entries for the existing sessions, so that the existing services are not interrupted.

Benefits

Through BGP GR, the forwarding is not interrupted. In addition, the flapping of BGP occurs only on the neighbors of the GR Restarter, and does not occur in the entire routing domain. This is important for BGP that needs to process a large number of routes.

MP-BGP

Conventional BGP-4 manages only IPv4 unicast routing information, and inter-AS transmission of packets of other network layer protocols, such as IPv6 and multicast, is limited.
To support multiple network layer protocols, the Internet Engineering Task Force (IETF) extends BGP-4 to Multiprotocol Extensions for BGP-4 (MP-BGP). RFC 4760 defines the MP-BGP standard. MP-BGP is forward compatible. Specifically, CX devices supporting MP-BGP can communicate with the CX devices that do not support MP-BGP.

Extended Attributes

BGP-4 Update packets carry three IPv4-related attributes: NLRI (Network Layer Reachable Information), Next_Hop, and Aggregator. Aggregator contains the IP address of the BGP speaker that performs route aggregation.
To carry information about multiple network layer protocols in NLRI and Next_Hop, MP-BGP introduces the following route attributes:

MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to advertise a reachable route and its next hop.
MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to delete an unreachable route.

The preceding two attributes are optional non-transitive. Therefore, the BGP speakers that do not support MP-BGP will ignore the information carried in the two attributes and do not advertise the information to other peers.

Address Family

The Address Family Information field consists of a 2-byte Address Family Identifier (AFI) and a 1-byte Subsequent Address Family Identifier (SAFI).
BGP uses address families to distinguish different network layer protocols. For the values of address families, see RFC 3232 (Assigned Numbers). The CX600 supports multiple MP-BGP extension applications, such as VPN extension and IPv6 extension, which are configured in their respective address family views.

Example for Configuring a Manual IPv6 over IPv4 Tunnel

Networking Requirements

As shown in Figure 1, two IPv6 networks are connected to Device B on the IPv4 backbone network through Device A and Device C. To interconnect the two IPv6 networks, configure a manual IPv6 over IPv4 tunnel between Device A and Device C.

Figure 1 Configuring a manual IPv6 over IPv4 tunnel

Precautions

When configuring a manual IPv6 over IPv4 tunnel, note the following points:

Create a tunnel interface and set parameters for the tunnel interface.
Perform the following configuration on both Device A and Device C. The source address of the local end is the destination address of the remote end of the tunnel. Similarly, the destination address of the local end is the source address of the remote end.
Configure IP addresses for the tunnel interface to support routing protocols.

Configuration Roadmap

The configuration roadmap is as follows:

Assign an IP address to each physical interface.
Configure the IPv6 address, source interface number, and destination address for the tunnel interface.
Set the protocol type is IPv6-IPv4.

Data Preparation

To complete the configuration, you need the following data:

IP addresses of interfaces
IPv6 address, source interface number, and destination address of the tunnel

Procedure

Configure Device A.

# Configure an IP address for Device A's interface that connects to Device C.

<HUAWEI> system-view

[~HUAWEI] sysname DeviceA

[*HUAWEI] commit

[~DeviceA] interface gigabitethernet 0/1/0

[~DeviceA-GigabitEthernet0/1/0] ip address 192.168.50.2 255.255.255.0

[*DeviceA-GigabitEthernet0/1/0] undo shutdown

[*DeviceA-GigabitEthernet0/1/0] quit

# Set the protocol type to IPv6-IPv4.

[*DeviceA] interface tunnel 1

[*DeviceA-Tunnel1] tunnel-protocol ipv6-ipv4

# Configure the IPv6 address, source interface number, and destination address for the tunnel interface.

[*DeviceA-Tunnel1] ipv6 enable

[*DeviceA-Tunnel1] ipv6 address 2001:db8::1 64

[*DeviceA-Tunnel1] source 192.168.50.2

[*DeviceA-Tunnel1] destination 192.168.51.2

[*DeviceA-Tunnel1] quit

# Configure a static route.

[*DeviceA] ip route-static 192.168.51.2 255.255.255.0 192.168.50.1

[*DeviceA] commit

Configure Device B.

# Configure IP addresses for Device B's interfaces that connect to Device A and Device C.

<HUAWEI> system-view

[~HUAWEI] sysname DeviceB

[*HUAWEI] commit

[~DeviceB] interface gigabitethernet 0/1/0

[~DeviceB-GigabitEthernet0/1/0] ip address 192.168.50.1 255.255.255.0

[*DeviceB-GigabitEthernet0/1/0] undo shutdown

[*DeviceB-GigabitEthernet0/1/0] quit

[*DeviceB] interface gigabitethernet 0/2/0

[*DeviceB-GigabitEthernet0/2/0] ip address 192.168.51.1 255.255.255.0

[*DeviceB-GigabitEthernet0/2/0] undo shutdown

[*DeviceB-GigabitEthernet0/2/0] commit

[~DeviceB-GigabitEthernet0/2/0] quit

# Configure Device C.

# Configure an IP address for Device C's interface that connects to Device A.

<HUAWEI> system-view

[~HUAWEI] sysname DeviceC

[*HUAWEI] commit

[~DeviceC] interface gigabitethernet 0/1/0

[~DeviceC-GigabitEthernet0/1/0] ip address 192.168.51.2 255.255.255.0

[*DeviceC-GigabitEthernet0/1/0] undo shutdown

[*DeviceC-GigabitEthernet0/1/0] quit

# Set the protocol type to IPv6-IPv4.

[*DeviceC] interface tunnel 1

[*DeviceC-Tunnel1] tunnel-protocol ipv6-ipv4

# Configure the IPv6 address, source interface number, and destination address for the tunnel interface.

[*DeviceC-Tunnel1] ipv6 enable

[*DeviceC-Tunnel1] ipv6 address 2001:db8::2 64

[*DeviceC-Tunnel1] source 192.168.51.2

[*DeviceC-Tunnel1] destination 192.168.50.2

[*DeviceC-Tunnel1] quit

# Configure a static route.

[*DeviceC] ip route-static 192.168.50.2 255.255.255.0 192.168.51.1

[*DeviceC] commit

Verify the configuration.

# Ping the IPv4 address of GE 0/1/0 on Device A from Device C, and the ping operation is successful.

[~DeviceC] ping 192.168.50.2

  PING 192.168.50.2: 56  data bytes, press CTRL_C to break

    Reply from 192.168.50.2: bytes=56 Sequence=1 ttl=254 time=84 ms

    Reply from 192.168.50.2: bytes=56 Sequence=2 ttl=254 time=27 ms

    Reply from 192.168.50.2: bytes=56 Sequence=3 ttl=254 time=25 ms

    Reply from 192.168.50.2: bytes=56 Sequence=4 ttl=254 time=3 ms

    Reply from 192.168.50.2: bytes=56 Sequence=5 ttl=254 time=24 ms

  --- 192.168.50.2 ping statistics ---

    5 packet(s) transmitted

    5 packet(s) received

    0.00% packet loss

    round-trip min/avg/max = 3/32/84 ms

# Ping the IPv6 address of Tunnel 1 on Device A from Device C, and the ping operation is successful.

[~DeviceC] ping ipv6 2001:db8::1

  PING 2001:db8::1 : 56  data bytes, press CTRL_C to break

    Reply from 2001:db8::1

    bytes=56 Sequence=1 hop limit=64  time = 28 ms

    Reply from 2001:db8::1

    bytes=56 Sequence=2 hop limit=64  time = 27 ms

    Reply from 2001:db8::1

    bytes=56 Sequence=3 hop limit=64  time = 26 ms

    Reply from 2001:db8::1

    bytes=56 Sequence=4 hop limit=64  time = 27 ms

    Reply from 2001:db8::1

    bytes=56 Sequence=5 hop limit=64  time = 26 ms

    5 packet(s) transmitted

    5 packet(s) received

    0.00% packet loss

round-trip min/avg/max = 26/26/28 ms

Configuration Files

Device A configuration file

 sysname DeviceA

admin

interface GigabitEthernet0/1/0

 undo shutdown

 ip address 192.168.50.2 255.255.255.0

interface Tunnel 1

 ipv6 enable

 ipv6 address 2001:db8::1/64

 tunnel-protocol ipv6-ipv4

 source 192.168.50.2

 destination 192.168.51.2

ip route-static 192.168.51.0 255.255.255.0 192.168.50.1

return

Device B configuration file

 sysname DeviceB

admin

interface GigabitEthernet0/1/0

 undo shutdown

 ip address 192.168.50.1 255.255.255.0

interface GigabitEthernet0/2/0

 undo shutdown

 ip address 192.168.51.1 255.255.255.0

return

Device C configuration file

 sysname DeviceC

admin

interface GigabitEthernet0/1/0

 undo shutdown

 ip address 192.168.51.2 255.255.255.0

interface Tunnel 1

 ipv6 enable

 ipv6 address 2001:db8::2/64

 tunnel-protocol ipv6-ipv4

 source 192.168.51.2

 destination 192.168.50.2

ip route-static 192.168.50.0 255.255.255.0 192.168.51.1

return

Example for Configuring IPv6 Addresses for Interfaces

Networking Requirements

As shown in Figure 1, Device A and Device B are connected through GE interfaces. To check the connectivity between the two interfaces, configure global unicast IPv6 addresses 2001:db8::1/32 and 2001:db8::2/32 for the GE interfaces.

Figure 1 Configuring IPv6 addresses for interfaces

Device Name	Interface	IP Address
DeviceA	GE0/1/0	2001:db8::1/32
DeviceB	GE0/1/0	2001:db8::2/32

Precautions

None

Configuration Roadmap

The configuration roadmap is as follows:

Enable IPv6 forwarding on the two Devices.
Configure global unicast IPv6 addresses for interfaces.

Data Preparation

To complete the configuration, you need global unicast IPv6 addresses of the interfaces.

Procedure

Configure global unicast IPv6 addresses for interfaces.

# Configure Device A.

<HUAWEI> system-view

[~HUAWEI] sysname DeviceA

[*HUAWEI] commit

[~DeviceA] interface GigabitEthernet 0/1/0

[~DeviceA-GigabitEthernet0/1/0] ipv6 enable

[*DeviceA-GigabitEthernet0/1/0] ipv6 address 2001:db8::1 32

[*DeviceA-GigabitEthernet0/1/0] undo shutdown

[*DeviceA-GigabitEthernet0/1/0] commit

[~DeviceA-GigabitEthernet0/1/0] quit

# Configure Device B.

<HUAWEI> system-view

[~HUAWEI] sysname DeviceB

[*HUAWEI] commit

[~DeviceB] interface GigabitEthernet 0/1/0

[~DeviceB-GigabitEthernet0/1/0] ipv6 enable

[*DeviceB-GigabitEthernet0/1/0] ipv6 address 2001:db8::2 32

[*DeviceB-GigabitEthernet0/1/0] undo shutdown

[*DeviceB-GigabitEthernet0/1/0] commit

[~DeviceB-GigabitEthernet0/1/0] quit

Verify the configuration.

If you can view the configured unicast global addresses and that the interfaces and the IPv6 protocol are in the Up state, it indicates that the configuration is successful.

# Display the interface information of Device A.

[~DeviceA] display ipv6 interface GigabitEthernet 0/1/0

GigabitEthernet0/1/0 current state : UP

IPv6 protocol current state : UP

link-local address is FE80::C964:0:B8B6:1

  Global unicast address(es):

    2001:db8::1, subnet is 2001:db8::/32

  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 30000 milliseconds

  ND retransmit interval is 1000 milliseconds

  Hosts use stateless autoconfig for addresses

# Display the interface information of Device B.

[~DeviceB] display ipv6 interface GigabitEthernet 0/1/0

GigabitEthernet0/1/0 current state : UP

IPv6 protocol current state : UP

link-local address is FE80::2D6F:0:7AF3:1

  Global unicast address(es):

    2001:db8::2, subnet is 2001:db8::/32

  Joined group address(es):

    FF02::1:FF00:2

    FF02::1:FFF3:1

    FF02::2

    FF02::1

  MTU is 4470 bytes

  ND DAD is enabled, number of DAD attempts: 1

  ND reachable time is 30000 milliseconds

  ND retransmit interval is 1000 milliseconds

  Hosts use stateless autoconfig for addresses

# Ping the link-local address of Device B from Device A. Note that you need to use the parameter -i to specify the interface corresponding to the link-local address.

[~DeviceA] ping ipv6 fe80::2d6f:0:7af3:1 -i GigabitEthernet 0/1/0

  PING FE80::2D6F:0:7AF3:1 : 56  data bytes, press CTRL_C to break

    Reply from FE80::2D6F:0:7AF3:1

    bytes=56 Sequence=1 hop limit=64  time = 60 ms

    Reply from FE80::2D6F:0:7AF3:1

    bytes=56 Sequence=2 hop limit=64  time = 50 ms

    Reply from FE80::2D6F:0:7AF3:1

    bytes=56 Sequence=3 hop limit=64  time = 50 ms

    Reply from FE80::2D6F:0:7AF3:1

    bytes=56 Sequence=4 hop limit=64  time = 30 ms

    Reply from FE80::2D6F:0:7AF3:1

    bytes=56 Sequence=5 hop limit=64  time = 1 ms

  --- FE80::2D6F:0:7AF3:1 ping statistics ---

    5 packet(s) transmitted

    5 packet(s) received

    0.00% packet loss

    round-trip min/avg/max = 1/38/60 ms

# Ping the global unicast IPv6 address of Device B from Device A.

[~DeviceA] ping ipv6 2001:db8::2

  PING 2001:db8::2 : 56  data bytes, press CTRL_C to break

    Reply from 2001:db8::2

    bytes=56 Sequence=1 hop limit=64  time = 30 ms

    Reply from 2001:db8::2

    bytes=56 Sequence=2 hop limit=64  time = 50 ms

    Reply from 2001:db8::2

    bytes=56 Sequence=3 hop limit=64  time = 50 ms

    Reply from 2001:db8::2

    bytes=56 Sequence=4 hop limit=64  time = 20 ms

    Reply from 2001:db8::2

    bytes=56 Sequence=5 hop limit=64  time = 40 ms

  --- 2001:db8::2 ping statistics ---

    5 packet(s) transmitted

    5 packet(s) received

    0.00% packet loss

    round-trip min/avg/max = 20/38/50 ms

Configuration Files

Device A configuration file

 sysname DeviceA

admin

interface GigabitEthernet0/1/0

undo shutdown

ipv6 enable

ipv6 address 2001:db8::1/32

return

Device B configuration file

 sysname DeviceB

admin

interface GigabitEthernet0/1/0

undo shutdown

ipv6 enable

ipv6 address 2001:db8::2/32

return

IPv6 Features

IPv6 supports the following features:

Hierarchical address structure

The IPv6 hierarchical address structure facilitates route search, reduces the IPv6 routing table size using route aggregation, and improves the forwarding efficiency of CX devices.
Automatic address configuration

IPv6 supports stateful and stateless address autoconfiguration to simplify the host configuration process.
- In stateful address autoconfiguration, the host obtains the address and configuration from a server.
- In stateless address autoconfiguration, the host automatically configures an IPv6 address that contains the prefix advertised by the local CX device and interface ID of the host. If no CX device exists on the link, the host can only configure the link-local address automatically to interwork with local nodes.
Selection of source and destination addresses

When network administrators need to specify or plan source and destination addresses of packets, they can define a group of address selection rules. An address selection policy table can be created based on these rules. Similar to a routing table, this table is queried based on the longest matching rule. The address is selected based on the source and destination addresses.

Select a source address using the following rules in descending order of priority:
1. Prefer a source address that is the same as the destination address.
2. Prefer an address in an appropriate address range.
3. Avoid selecting a deprecated address.
4. Prefer a home address.
5. Prefer an address of the outbound interface.
6. Prefer an address whose label value is the same as that of the destination address.
7. Use the longest matching rule.
NOTE:
The candidate address can be the unicast address that is configured on the specified outbound interface. If a source address that has the same label value and is in the same address range with the destination address is not found on the outbound interface, you can select such a source address from another interface.

Select a destination address using the following rules in descending order of priority.
1. Avoid selecting an unavailable destination address.
2. Prefer an address in an appropriate address range.
3. Avoid selecting a deprecated address.
4. Prefer a home address.
5. Prefer an address whose label value is the same as that of the source address.
6. Prefer an address with a higher precedence value.
7. Prefer native transport to the 6over4 or 6to4 tunnel.
8. Prefer an address in a smaller address range.
9. Use the longest matching rule.
10. Leave the order of address priorities unchanged.
QoS

In an IPv6 header, the new Flow Label field specifies how to identify and process traffic. The Flow Label field identifies a flow and allows aCX device to recognize packets in the flow and to provide special processing.

QoS is guaranteed even for the packets encrypted with IPsec because the IPv6 header can identify different types of flows.
Built-in security

An IPv6 packet contains a standard extension header related to IPsec, and therefore IPv6 can provide end-to-end security. This provides network security specifications and improves interoperability between different IPv6 applications.
Fixed basic header

A fixed basic header helps improve forwarding efficiency.
Flexible extension header

An IPv4 header only supports the 40-byte Options field, whereas the size of the IPv6 extension header is limited only by the IPv6 packet size.

In IPv6, multiple extension headers are introduced to replace the Options field of the IPv4 header. This improves packet processing efficiency, enhances IPv6 flexibility, and provides better scalability for the IP protocol. Figure 1 shows an IPv6 extension header.

Figure 1 IPv6 extension header

When multiple extension headers are used in the same packet, the headers must be listed in the following order:

IPv6 basic header
Hop-by-hop extension header
Destination options extension header
Routing extension header
Fragment extension header
Authentication extension header
Encapsulation security extension header
Destination options extension header (options to be processed at the destination)
Upper layer extension header

Not all extension headers must be examined and processed by CX devices. When a CX device forwards packets, it determines whether or not to process the extension headers based on the Next Header value in the IPv6 basic header.

The destination options extension header appears twice in a packet: one before the routing extension header and one after the upper layer extension header. All other extension headers appear only once.

Pages

Example for Configuring BGP Auto FRR

Configuration Roadmap

Data Preparation

Procedure

Configuration Files

BGP Auto FRR

Usage Scenario

BGP GR "Graceful Restart "

Prerequisite for Implementation

Related Concepts

Principles

GR Reset

Benefits

MP-BGP

Extended Attributes

Address Family

Example for Configuring a Manual IPv6 over IPv4 Tunnel

Networking Requirements

Precautions

Configuration Roadmap

Data Preparation

Procedure

Configuration Files

Example for Configuring IPv6 Addresses for Interfaces

Networking Requirements

Precautions

Configuration Roadmap

Data Preparation

Procedure

Configuration Files

IPv6 Features