- Table of Contents
- Related Documents
-
Title | Size | Download |
---|---|---|
03-iNOF configuration | 426.51 KB |
BFD-based link failure detection
iNOF tasks at a glance in directly-connected iNOF networks
iNOF tasks at a glance in cross-switch iNOF networks
Enabling automatic adding of free hosts to the default iNOF zone
Adding hosts to a user-defined iNOF zone
Display and maintenance commands for iNOF
Directly-connected iNOF network configuration examples
Cross-switch iNOF network configuration examples
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 maintenance—This 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:
· Host—iNOF-capable network servers and disk devices.
· Switch—iNOF-capable switches that provide network access to iNOF hosts.
· Zone—iNOF 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 zone—A user-defined zone is created by users. Users must add hosts into the zone manually according to network requirements.
¡ Default zone—By 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.
|
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
· (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
¡ 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
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
- 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 2—LAN 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:
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.
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 [ 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
# 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
[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