18-Intelligent Lossless Network Configuration Guide

HomeSupportConfigure & DeployConfiguration GuidesH3C S6805 & S6825 & S6850 & S9850 Configuration Guides-Release 6715-6W10018-Intelligent Lossless Network Configuration Guide
03-iNOF configuration
Title Size Download
03-iNOF configuration 426.51 KB

Configuring iNOF

About iNOF

Background

In Ethernet storage scenarios, the server side connects to the storage side over Ethernet. Traditionally, to achieve high throughput with packet loss during traffic transmission, the network server are configured to discover disk devices and establish long connections with them. If the server has not received any packets from a disk device for a long time, it considers the disk device as faulty and forwards storage traffic along the backup path. The traditional Ethernet storage network solution has the following disadvantages:

·     Unintelligent management and maintenanceThis solution requires manual management and maintenance.

·     Slow discovery of new disk devices—This solution cannot discover new disk devices in time.

·     Slow reaction to disk device exceptions—This solution cannot discover disk device exceptions in time. Traffic loss will occur as long as the server cannot switch to the backup forwarding path quickly.

Intelligent Lossless NVMe Over Fabric (iNOF) cooperates with Link Layer Discovery Protocol (LLDP) to implement intelligent and lossless Ethernet storage. The devices in an iNOF zone can perceive the existence of each other. They can automatically adjust their Ethernet storage settings to accommodate the change as soon as a device is added into or removed from the zone. iNOF-powered traffic transmission over Ethernet is characterized by zero packet loss and high throughput.

Elements

An iNOF network includes the following elements:

·     HostiNOF-capable network servers and disk devices.

·     Switch—iNOF-capable switches that provide network access to iNOF hosts.

·     ZoneiNOF introduces the concept of zone to manage hosts. An iNOF zone has multiple hosts. When you add a new host into or remove a host from the zone, iNOF informs this event to other hosts in that zone. iNOF zones are divided into the following types:

¡     User-defined zoneA user-defined zone is created by users. Users must add hosts into the zone manually according to network requirements.

¡     Default zoneBy default, an iNOF switch has a default iNOF zone that cannot be deleted. Users can select whether to enable automatic adding of free hosts to the default zone. A free host refers to a host that is not a member of any user-defined zones.

Network types

Directly connected network

As shown in Figure 1, the hosts in an iNOF zone connect to the same iNOF switch. Each host exchanges Layer 2 packets with the switch to ensure they are aware of the state changes of connected hosts. Switches do not exchange iNOF information with each other. This iNOF network type is applicable to small networks.

Figure 1 Directly connected network

 

Cross-switch network

As shown in Figure 2, the hosts in the same iNOF zone can connect to different iNOF switches. These switches exchange dynamic host information. This iNOF network type is applicable to large-scale data centers with multiple hosts from different organizations or departments. The hosts in the same organization or department connect to different iNOF switches.

A cross-switch iNOF network is established as follows:

·     Each host directly connects to an iNOF switch. They communicate with each other in the same way as they do on the directly connected iNOF network.

·     The iNOF switches establish IBGP sessions to each other and use route reflection to simplify the network. Other switches can promptly receive the state changes of iNOF hosts connected to a switch. In BGP iNOF address family, iNOF switches exchange iNOF route information that includes dynamic iNOF host information and iNOF configuration information.

Figure 2 Cross-switch network

 

NOTE:

·     To simplify a cross-switch iNOF network, configure a minimum of one switch as the iNOF reflector and the rest of switches on that network as iNOF clients. All clients establish iNOF connection with the iNOF reflector and each host directly connects to an iNOF reflector or client. To avoid unexpected or unsolvable issues during frequent route changes, do not establish any iNOF connections between clients.

·     To improve network availability, you can specify multiple route reflectors for an iNOF zone. The failure of a reflector does not affect service continuity, because other reflectors still run normally. These route reflectors and their clients automatically form a cluster. The route reflectors in the cluster must have the same cluster ID to avoid routing loops.

BFD-based link failure detection

When iNOF reflectors run on a network, they rely on BGP, and thus support BFD configuration.

Bidirectional forwarding detection (BFD) provides millisecond-level link failure detection. It can detect and monitor the connectivity of forwarding paths to detect communication failures quickly. Once a communication failure is detected, BFD can report the failure to upper-layer applications.

The collaboration between iNOF and BFD is to associate BFD with iNOF through BGP and achieve fast failure detection for the links between iNOF switches.

The collaboration between iNOF and BFD functions as follows:

1.     BGP-BFD collaboration.

a.     After the local BGP device establishes an IBGP peer session to another BGP device, the local device delivers information about the IBGP peer to the BFD module. IBGP peer information includes destination address and source address.

b.     On receipt of IBGP peer information, the BFD module automatically establishes a BFD session to the IBGP peer.

c.     If the BFD module detects a link failure along the link to the IBGP peer, it will notify the local BGP device to tear down the IBGP peer session.

2.     BGP-iNOF collaboration.

a.     BGP notifies the iNOF module to delete the IBGP peer's iNOF information and sends withdrawal messages to those peers that received the IBGP peer's iNOF information from BGP.

b.     After the iNOF connection to the IBGP peer goes down, the iNOF process considers that IBGP peer offline. iNOF then advertises this change to each host that meets the following requirements:

-     Has a direct connection to the local BGP device.

-     Belongs to the same iNOF zone as the local BGP device.

-     Has subscribed to network change information.

For more information about BFD, see BFD configuration in High Availability Configuration Guide.

Benefits

iNOF has the following basic benefits:

·     Plug and play

The iNOF switch can discover a new host as soon as the host accesses the iNOF network. Then, it synchronizes this change to other switches on the network and other hosts in the iNOF zone to which the new host belongs. Hosts in the same zone will automatically establish connections with the new host to ensure fast storage service expansion.

·     Fast network failure detection

The iNOF switch can detect network failures promptly and forward this event to other switches on the network and the hosts connected to that switch. Hosts disconnect from the storage devices affected by network failures and use redundant paths to ensure service continuity.

The hybrid of BGP and iNOF in the cross-switch iNOF network has the following additional benefits:

·     Stable iNOF information transmission

To implement stable iNOF information transmission, iNOF switches establish BGP-based iNOF connections with each other and run TCP in the transport layer.

·     Nonstop iNOF information transmission

With BGP GR and NSR, iNOF information transmission is not interrupted when iNOF switches are having a master-backup switchover or BGP is restarting.

·     Flexible iNOF route filtering and selection

With BGP, iNOF switches can filter and select iNOF routes flexibly.

·     Simplified network configuration

The application of BGP route reflection in large-scale iNOF networks can reduce the cost of network maintenance by simplifying the network topology. After you complete iNOF zone configuration and host configuration on the reflector, the configuration will be synchronized to clients. This can ease the workload of iNOF configuration.

·     Fast link failure detection

You can configure BFD for BGP to detect link failures promptly in iNOF networks.

·     High data security

There are various encryption methods for BGP sessions, including MD5 authentication, GTSM, and keychain authentication. These encryption methods enhance the data security among iNOF switches.

Protocols

The iNOF switch selects one of the following protocols to exchange packets with hosts after negotiating with them.

·     ODCC-2020-05016: NVMe over RoCEv2

·     China Mobile RoCE-SAN Solution v03 20210817

License requirements

To configure and use the iNOF feature, first install a license. For more information about licenses, see license management configuration in Fundamentals Configuration Guide.

Restrictions and guidelines

Hosts and memory arrays can establish iNOF connections to the network devices enabled with iNOF only after you enable Storage Network Smart Discovery (SNSD) for them.

VPN instances do not support iNOF.

Although iNOF supports adding IPv4 hosts and IPv6 hosts as iNOF zone members, iNOF switches only support IPv4 BGP in the current software version. These switches use IPv4 BGP routes to exchange information about IPv4 iNOF hosts and IPv6 iNOF hosts.

When you configure two iNOF reflectors on a cross-switch iNOF network, follow these guidelines:

·     To ensure correct iNOF information reflection, configure each reflector as the client of another and make sure they have the same clients except the reflector and the same cluster ID.

·     Either of the reflectors can synchronize its iNOF configuration information to its clients. The iNOF configuration information includes user-defined zone configuration, configuration of automatic host adding to the default zone, and hard zoning configuration. To implement disaster recovery, configure the same iNOF settings on each reflector separately.

iNOF tasks at a glance

iNOF tasks at a glance in directly-connected iNOF networks

·     Enabling iNOF

·     (Optional.) Enabling automatic adding of free hosts to the default iNOF zone

Each iNOF host must be a member of one iNOF zone. If no user-defined iNOF zones exist in the network, you must perform this task. Make sure all iNOF switches have the same iNOF zone configuration.

·     (Optional.) Configuring user-defined iNOF zones

¡     Creating an iNOF zone

¡     Adding hosts to a user-defined iNOF zone

¡     Configuring iNOF hard zoning

iNOF tasks at a glance in cross-switch iNOF networks

1.     Configuring iNOF clients

¡     Configuring an iNOF client

¡     Enabling iNOF

2.     Configuring iNOF reflectors

¡     Configuring an iNOF reflector

¡     (Optional.) Enabling automatic adding of free hosts to the default iNOF zone

Each iNOF host must be a member of one iNOF zone. If no user-defined iNOF zones exist in the network, you must perform this task.

¡     (Optional.) Configuring user-defined iNOF zones

-     Creating an iNOF zone

-     Adding hosts to a user-defined iNOF zone

-     Configuring iNOF hard zoning

Prerequisites

Perform the following LLDP configuration tasks:

·     Enable LLDP globally on the iNOF switch.

·     Enable LLDP on the switch-facing interface for the iNOF host.

·     Configure the LLDP operating mode as Rx or Txrx to ensure the device can receive LLDP packets.

These tasks enable the iNOF switch to detect iNOF host connections and disconnections.

For more information about LLDP, see LLDP configuration in Layer 2LAN Switching Configuration Guide.

Configuring an iNOF client

Restrictions and guidelines

IPv6 networks do not support iNOF. You can use only IPv4 addresses to create BGP peers.

To ensure iNOF clients receive iNOF routes only from iNOF reflectors, do not establish any BGP sessions between clients in BGP iNOF address family.

For more information about the commands for iNOF client configuration, see the following:

·     iNOF commands in Intelligent Lossless Network Command Reference.

·     BGP commands in Layer 3—IP Routing Command Reference.

Procedure

1.     Enter system view.

system-view

2.     Configure a global BGP router ID.

router id router-id

By default, no global router ID is configured.

If no global router ID is configured, the following rules apply:

¡     If loopback interfaces configured with an IP address exist, BGP uses the highest loopback interface IP address as the router ID.

¡     If no loopback interface IP address is available, BGP uses the highest physical interface IP address as the route ID regardless of the interface status.

3.     Enter BGP instance view.

bgp as-number [ instance instance-name ]

By default, BGP is disabled and no BGP instances exist.

4.     (Optional.) Configure a router ID for the BGP instance.

router-id router-id

By default, no router ID is configured for a BGP instance, and the BGP instance uses the global router ID configured by the router-id command in system view.

5.     Configure BFD for the link to an IPv4 BGP peer.

peer ipv4-address [ mask-length ] bfd [ echo | multi-hop | single-hop ]

By default, BFD is disabled.

6.     Configure the iNOF reflector as a BGP IPv4 peer and specify its AS number.

peer ipv4-address [ mask-length ] as-number as-number

7.     Enter BGP iNOF address family view.

address-family inof

8.     Configure the iNOF role of the device as iNOF client.

role reflect-client

By default, the iNOF role of the device is not configured.

9.     Enable the device to exchange BGP iNOF routes with the iNOF reflector.

peer ipv4-address [ mask-length ] enable

By default, the device cannot exchange BGP iNOF routes with the iNOF reflector.

Configuring an iNOF reflector

Restrictions and guidelines

IPv6 networks do not support iNOF. You can use only IPv4 addresses to create BGP peers.

For more information about the commands for iNOF reflector configuration, see the following:

·     iNOF commands in Intelligent Lossless Network Command Reference.

·     BGP commands in Layer 3—IP Routing Command Reference.

Procedure

1.     Enter system view.

system-view

2.     Configure a global BGP router ID.

router id router-id

By default, no global router ID is configured.

If no global router ID is configured, the following rules apply:

¡     If loopback interfaces configured with an IP address exist, BGP uses the highest loopback interface IP address as the router ID.

¡     If no loopback interface IP address is available, BGP uses the highest physical interface IP address as the route ID regardless of the interface status.

3.     Enter BGP instance view.

bgp as-number [ instance instance-name ]

By default, BGP is disabled and no BGP instances exist.

4.     (Optional.) Configure a router ID for the BGP instance.

router-id router-id

By default, no router ID is configured for a BGP instance, and the BGP instance uses the global router ID configured by the router-id command in system view.

5.     (Optional.) Configure BFD for the link to an IPv4 BGP peer.

peer ipv4-address [ mask-length ] bfd [ echo | multi-hop | single-hop ]

By default, BFD is disabled.

6.     Configure other iNOF switches as BGP IPv4 peers and specify their AS numbers.

peer ipv4-address [ mask-length ] as-number as-number

7.     Enter BGP iNOF address family view.

address-family inof

8.     Enable the device to exchange BGP iNOF routes with a BGP IPv4 peer.

peer ipv4-address [ mask-length ] enable

By default, the device cannot exchange BGP iNOF routes with any BGP IPv4 peers.

9.     Configure the iNOF role of the device as iNOF reflector.

role reflector

By default, the iNOF role of the device is not configured.

10.     Configure the device as an iNOF reflector and specify the directly-connected iNOF switches as its clients.

peer ipv4-address [ mask-length ] reflect-client

11.     (Optional.) Configure the cluster ID of the iNOF reflector.

reflector cluster-id { cluster-id | ipv4-address }

By default, an iNOF reflector uses its own router ID as the cluster ID.

When a minimum of two reflectors exist in the iNOF network, use this command instead of the peer cluster-id command to configure the same cluster ID for them.

Enabling iNOF

To enable iNOF, perform the following tasks:

12.     Enter system view.

system-view

13.     Enable iNOF and enter its view.

inof enable

By default, iNOF is disabled.

Enabling automatic adding of free hosts to the default iNOF zone

About this task

The default iNOF zone does not support manual adding of online hosts. The iNOF switch enabled with this feature adds a host to the default iNOF zone when the following conditions exist:

·     The host is directly connected to the switch and comes online.

·     The host is a free host that is not a member of any user-defined iNOF zone.

Restrictions and guidelines

If an iNOF reflector exists in the network, you must enable this feature on the iNOF reflector. For an iNOF client on such a network, whether to add free hosts to the default zone depends on the configuration of this feature for the iNOF reflector. If you enable or disable this feature directly on the client, the configuration cannot take effect.

Procedure

1.     Enter system view.

system-view

2.     Enter iNOF view.

inof enable

3.     Enable automatic adding of free hosts to the default zone.

default-zone enable

By default, the device adds free hosts to the default zone.

Creating an iNOF zone

To create an iNOF zone, perform the following tasks:

4.     Enter system view.

system-view

5.     Enter iNOF view.

inof enable

6.     Create an iNOF zone.

zone zone-name

Adding hosts to a user-defined iNOF zone

To add hosts to a user-defined iNOF zone, perform the following tasks:

7.     Enter system view.

system-view

8.     Enter iNOF view.

inof enable

9.     Enter iNOF zone view.

zone zone-name

10.     Add hosts to the user-defined iNOF zone.

host [ ipv6 ] { ip-address | ip-address1 to ip-address2 }

By default, a user-defined iNOF zone has no hosts.

You can add a host into multiple user-defined iNOF zones.

Configuring iNOF hard zoning

About this task

If iNOF hard zoning is enabled, the following rules apply:

·     Hosts in the same iNOF zone can access each other.

·     Hosts in different iNOF zones cannot access each other.

Restrictions and guidelines

If an iNOF reflector exists in the network, you must enable this feature on the iNOF reflector. For an iNOF client on such a network, the status of iNOF hard zoning depends on the configuration of this feature for the iNOF reflector. If you enable or disable this feature directly on the client, the configuration cannot take effect.

Procedure

1.     Enter system view.

system-view

2.     Enter iNOF view.

inof enable

3.     Enable iNOF hard zoning.

hard-zoning enable

By default, iNOF hard zoning is disabled.

Display and maintenance commands for iNOF

After you complete iNOF configuration, you can use display commands in any view to verify the configuration.

To reset the sessions in BGP iNOF address family, use reset commands in user view.

For more information about BGP iNOF commands except for the display bgp inof command, see BGP commands in Layer 3—IP Routing Command Reference.

 

Task

Command

Display iNOF configuration information.

display inof configuration

Display information about user-defined iNOF zones.

display inof [ ipv6 ] configuration zone [ zone-name ] [ inconsistent ]

Display iNOF host information.

display inof [ ipv6 ] information host [ local | remote | ip-address ]

Display iNOF reflector information.

display inof reflector

Display BGP iNOF route information.

display bgp [ instance instance-name ] inof [ inof-prefix | peer ipv4-address  { advertised | received } [ statistics ] | statistics ]

Display BGP iNOF peer information.

display bgp [ instance instance-name ] peer inof [ ipv4-address mask-length | ipv4-address log-info | [ ipv4-address ] verbose ]

Display update group information for BGP iNOF address family.

display bgp [ instance instance-name ] update-group inof [ ipv4-address ]

Reset sessions for BGP iNOF address family.

reset bgp [ instance instance-name ] { as-number | ipv4-address [ mask-length ] | all | external | internal } inof

iNOF configuration examples

Directly-connected iNOF network configuration examples

Network configuration

As shown in Figure 3, the network server and the disk device are connected through Device A and Device B. When the disk device fails, the server can detect the failure promptly.

Figure 3 Directly-connected iNOF network diagram

Procedure

1.     Configure Device A.

# Create iNOF zone 1 on Device A and add the network server and the disk device into the zone.

<DeviceA> system-view

[DeviceA] inof enable

[DeviceA-inof] zone 1

[DeviceA-inof-zone-1] host 10.1.1.10

[DeviceA-inof-zone-1] host 10.1.1.20

[DeviceA-inof-zone-1] quit

[DeviceA-inof] quit

# Enable LLDP globally.

[DeviceA] lldp global enable

# Enable LLDP on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 and configure the LLDP operating mode as Rx. By default, LLDP is enabled on an interface.

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] lldp enable

[DeviceA-GigabitEthernet1/0/1] lldp admin-status rx

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] lldp enable

[DeviceA-GigabitEthernet1/0/2] lldp admin-status rx

[DeviceA-GigabitEthernet1/0/2] quit

2.     Configure Device B.

Details are not shown. The configuration of Device B is the same as that of Device A.

Verify the configuration

# Display information about user-defined iNOF zones.

[DeviceA] display inof configuration zone

Total Zone number: 2

iNOF Default-Zone: Enable

ZoneName                          Host             Learned-From

Default                           --               Local

1                                 10.1.1.10        Local

1                                 10.1.1.20        Local

Cross-switch iNOF network configuration examples

Network configuration

As shown in Figure 3, network server 100 and disk devices 101 to 105 are members of iNOF zone 1. Network server 200 and disk device 201 are members of the default iNOF zone. Device A and Device D are iNOF clients, Device B and Device C are iNOF reflectors. Hosts in different iNOF zones can exchange Layer 3 packets with each other. When a disk device fails or is added into an iNOF zone, the server in the same iNOF zone can detect the event promptly.

Figure 4 Cross-switch iNOF network diagram

 

Procedure

1.     Configure Device A.

# Assign IP addresses to VLAN-interface 10 and VLAN-interface 30. These interfaces are used for BGP connections.

<DeviceA> system-view

[DeviceA] vlan 10 30

[DeviceA] interface vlan 10

[DeviceA-Vlan-interface10] ip address 10.1.1.2 24

[DeviceA-Vlan-interface10] quit

[DeviceA] interface vlan 30

[DeviceA-Vlan-interface30] ip address 30.1.1.2 24

[DeviceA-Vlan-interface30] quit

# Specify Device B and Device C as BGP peers of Device A.

[DeviceA] bgp 100

[DeviceA-bgp-default] peer 10.1.1.1 as-number 100

[DeviceA-bgp-default] peer 10.1.1.1 bfd

[DeviceA-bgp-default] peer 30.1.1.1 as-number 100

[DeviceA-bgp-default] peer 30.1.1.1 bfd

[DeviceA-bgp-default] address-family inof

[DeviceA-bgp-default-inof] role reflect-client

[DeviceA-bgp-default-inof] peer 10.1.1.1 enable

[DeviceA-bgp-default-inof] peer 30.1.1.1 enable

[DeviceA-bgp-default-inof] quit

[DeviceA-bgp-default] quit

# Enable LLDP globally.

[DeviceA] lldp global enable

# Enable iNOF.

[DeviceA] inof enable

[DeviceA-inof] quit

2.     Configure Device B (iNOF reflector 1).

# Assign IP addresses to VLAN-interface 10, VLAN-interface 20, and VLAN-interface 100. These interfaces are used for BGP connections.

<DeviceB> system-view

[DeviceB] vlan 10 20 100

[DeviceB] interface vlan 10

[DeviceB-Vlan-interface10] ip address 10.1.1.1 24

[DeviceB-Vlan-interface10] quit

[DeviceB] interface vlan 20

[DeviceB-Vlan-interface20] ip address 20.1.1.1 24

[DeviceB-Vlan-interface20] quit

[DeviceB] interface vlan 100

[DeviceB-Vlan-interface100] ip address 100.1.1.1 24

[DeviceB-Vlan-interface100] quit

# Specify Device A, Device C, and Device D as BGP peers of Device B, and specify them as clients of Device B.

[DeviceB] bgp 100

[DeviceB-bgp-default] peer 10.1.1.2 as-number 100

[DeviceB-bgp-default] peer 10.1.1.2 bfd

[DeviceB-bgp-default] peer 20.1.1.2 as-number 100

[DeviceB-bgp-default] peer 20.1.1.2 bfd

[DeviceB-bgp-default] peer 100.1.1.2 as-number 100

[DeviceB-bgp-default] peer 100.1.1.2 bfd

[DeviceB-bgp-default] address-family inof

[DeviceB-bgp-default-inof] role reflector

[DeviceB-bgp-default-inof] peer 10.1.1.2 enable

[DeviceB-bgp-default-inof] reflector cluster-id 88.88.88.88

[DeviceB-bgp-default-inof] peer 10.1.1.2 reflect-client

[DeviceB-bgp-default-inof] peer 20.1.1.2 enable

[DeviceB-bgp-default-inof] peer 20.1.1.2 reflect-client

[DeviceB-bgp-default-inof] peer 100.1.1.2 enable

[DeviceB-bgp-default-inof] peer 100.1.1.2 reflect-client

[DeviceB-bgp-default-inof] quit

[DeviceB-bgp-default] quit

# Enable LLDP globally.

[DeviceB] lldp global enable

# Enable iNOF.

[DeviceB] inof enable

# Create iNOF zone 1.

[DeviceB-inof] zone 1

[DeviceB-inof-zone-1] host 10.10.1.100 to 10.10.1.105

[DeviceB-inof-zone-1] quit

[DeviceB-inof] quit

3.     Configure Device C (iNOF reflector 2).

 

 

NOTE:

To implement iNOF disaster recovery, the iNOF zone configuration on reflector 1 and reflector 2 must be the same.

 

# Assign IP addresses to VLAN-interface 30, VLAN-interface 40, and VLAN-interface 100. These interfaces are used for BGP connections.

<DeviceC> system-view

[DeviceC] vlan 30 40 100

[DeviceC] interface vlan 30

[DeviceC-Vlan-interface30] ip address 30.1.1.1 24

[DeviceC-Vlan-interface30] quit

[DeviceC] interface vlan 40

[DeviceC-Vlan-interface40] ip address 40.1.1.1 24

[DeviceC-Vlan-interface40] quit

[DeviceC] interface vlan 100

[DeviceC-Vlan-interface100] ip address 100.1.1.2 24

[DeviceC-Vlan-interface100] quit

# Specify Device A, Device B, and Device D as BGP peers of Device C, and specify them as clients of Device C.

[DeviceC] bgp 100

[DeviceC-bgp-default] peer 30.1.1.2 as-number 100

[DeviceC-bgp-default] peer 30.1.1.2 bfd

[DeviceC-bgp-default] peer 40.1.1.2 as-number 100

[DeviceC-bgp-default] peer 40.1.1.2 bfd

[DeviceC-bgp-default] peer 100.1.1.1 as-number 100

[DeviceC-bgp-default] peer 100.1.1.1 bfd

[DeviceC-bgp-default] address-family inof

[DeviceC-bgp-default-inof] role reflector

[DeviceC-bgp-default-inof] reflector cluster-id 88.88.88.88

[DeviceC-bgp-default-inof] peer 30.1.1.2 enable

[DeviceC-bgp-default-inof] peer 30.1.1.2 reflect-client

[DeviceC-bgp-default-inof] peer 40.1.1.2 enable

[DeviceC-bgp-default-inof] peer 40.1.1.2 reflect-client

[DeviceC-bgp-default-inof] peer 100.1.1.1 enable

[DeviceC-bgp-default-inof] peer 100.1.1.1 reflect-client

[DeviceC-bgp-default-inof] quit

[DeviceC-bgp-default] quit

# Enable LLDP globally.

[DeviceC] lldp global enable

# Enable iNOF.

[DeviceC] inof enable

# Create iNOF zone 1.

[DeviceC-inof] zone 1

[DeviceB-inof-zone-1] host 10.10.1.100 to 10.10.1.105

[DeviceC-inof-zone-1] quit

[DeviceC-inof] quit

4.     Configure Device D.

# Assign IP addresses to VLAN-interface 20 and VLAN-interface 40. These interfaces are used for BGP connections.

<DeviceD> system-view

[DeviceD] vlan 20 40

[DeviceD] interface vlan 20

[DeviceD-Vlan-interface20] ip address 20.1.1.2 24

[DeviceD-Vlan-interface20] quit

[DeviceD] interface vlan 40

[DeviceD-Vlan-interface40] ip address 40.1.1.2 24

[DeviceD-Vlan-interface40] quit

# Specify Device B and Device C as BGP peers of Device D.

[DeviceD] bgp 100

[DeviceD-bgp-default] peer 20.1.1.1 as-number 100

[DeviceD-bgp-default] peer 20.1.1.1 bfd

[DeviceD-bgp-default] peer 40.1.1.1 as-number 100

[DeviceD-bgp-default] peer 40.1.1.1 bfd

[DeviceD-bgp-default] address-family inof

[DeviceD-bgp-default-inof] role reflect-client

[DeviceD-bgp-default-inof] peer 20.1.1.1 enable

[DeviceD-bgp-default-inof] peer 40.1.1.1 enable

[DeviceD-bgp-default-inof] quit

[DeviceD-bgp-default] quit

# Enable LLDP globally.

[DeviceD] lldp global enable

# Enable iNOF.

[DeviceD] inof enable

[DeviceD-inof] quit

Verify the configuration

# Display iNOF reflector information on Device A.

<DeviceA> display inof reflector

Index   ReflectorIP           DefaultZone           HardZoning

1       10.1.1.1              Enabled               Disabled

2       10.1.1.2              Enabled               Disabled

# Display iNOF reflector information on Device B.

<DeviceB> display inof reflector

Index   ReflectorIP           DefaultZone           HardZoning

1       Local                 Enabled               Disabled

2       10.1.1.2              Enabled               Disabled

# Display information about user-defined iNOF zones on Device B.

<DeviceB> display inof configuration zone

Total Zone number: 2

iNOF Default-Zone: Enable

ZoneName                          Host             Learned-From

Default                           10.10.1.200      100.1.1.2

Default                           10.10.1.201      100.1.1.2

1                                 10.10.1.100      10.1.1.2

1                                 10.10.1.101      10.1.1.2

1                                 10.10.1.102      20.1.1.2

1                                 10.10.1.103      20.1.1.2

1                                 10.10.1.104      Local

1                                 10.10.1.105      Local

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become A Partner
  • Partner Policy & Program
  • Global Learning
  • Partner Sales Resources
  • Partner Business Management
  • Service Business
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网