The Best Of Networking

The idea of programmability is the basis for the most precise definition of what SDN is: technology that separates the control plane management of network devices from the underlying data plane that forwards network traffic. IDC broadens that definition of SDN by stating: “Datacenter SDN architectures feature software-defined overlays or controllers that are abstracted from …

The post What is SDN? appeared first on Network Solution Blog.

SD-WAN is an acronym for software-defined networking in a wide area network (WAN). SD-WAN simplifies the management and operation of a WAN by decoupling the networking hardware from its control mechanism. This concept is similar to how software-defined networking implements virtualization technology to improve data center management and operation. A key application is to allow companies to build higher-performance WANs using lower-cost and commercially …

The post Do you know what is SD-WAN (Software-defined WAN)? appeared first on Network Solution Blog.

IPTime FBB Solution Course Objectives Upon completion of IPTime FBB Solution course, you will be able to learn about: Service types supported by the FBB solution HSI service configuration VoIP service configuration IPTV service configuration Enterprise Internet service configuration Enterprise Interconnection service configuration Typical FBB Networking : The network FBB solution is an overall solution …

The post IPTime FBB Solution Configuration Guide – Part 1 appeared first on Network Solution Blog.

Entering/Exiting the Command-Line Interface After logging into the router from the Console port, you will enter the user exec mode or user view in case of VRP. To enter or exit the global configuration mode or system view (VRP), use the following cisco vs huawei commands Cisco IOS Huawei VRP Router> [Huawei] Enter the global …

The post Cisco vs Huawei commands mapping appeared first on Network Solution Blog.

test tttt ttt

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

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.

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.

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.

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