Configuration Guide IRF H3C S7500ESeries Ethernet Switches

Table of Contents

Configuration Guide IRF Virtual Core

H3C S7500ESeries Ethernet Switches

Configuration Guide IRF H3C S7500ESeries Ethernet Switches

Table of Contents

Table of Contents
1 IRF Virtual Core Configuration 1-1 IRF Virtual Core Overview 1-1 Introduction 1-1 Physical Connections 1-1 Application and Advantages 1-2 IRF Virtual Core General Operation and Management 1-4 Topology Collection 1-4 Role Election 1-4 Virtual Core Management 1-5 Virtual Core Maintenance 1-6 IRF Virtual Core Configuration Task List 1-6 Configuring IRF Virtual Core 1-7 Configuring Virtual Core Ports 1-7 Setting a Member ID for a Device 1-8 Specifying a Priority for a Virtual Core Member 1-9 Logging In to an IRF Virtual Core 1-10 Logging In to the Master 1-10 Logging In to a Slave 1-10 Displaying and Maintaining IRF Virtual Core 1-11 IRF Virtual Core Configuration Example 1-11 Specifying the Preservation Time of Virtual Core Bridge MAC Address 1-13 Enabling Auto Upgrade of Boot Files 1-14 Setting the Time Interval for Delayed Report on Link-Down State 1-14

ii

IRF Virtual Core Configuration

When configuring IRF Virtual Core, go to these sections for information you are interested in: IRF Virtual Core Overview IRF Virtual Core IRF Virtual Core Configuration Task List Configuring IRF Virtual Core Logging In to an IRF Virtual Core Displaying and Maintaining IRF Virtual Core IRF Virtual Core Configuration Example

IRF Virtual Core Overview

Introduction
Intelligent Resilient Framework (IRF) allows you to build an IRF Virtual Core, namely a united device, by interconnecting multiple devices through Virtual Core ports. You can manage all the devices in the IRF Virtual Core by managing the united device. In an IRF Virtual Core, every single device is a Virtual Core member, and plays one of the following two roles according to its function:

Master: A Virtual Core member. It is elected to manage the entire Virtual Core. An IRF Virtual Core has only one master at one time. Slave: A Virtual Core member. It is managed by the master and operates as a backup of the master. In an IRF Virtual Core, except for the master, all the other devices are the slaves.

Role election defines the roles of Virtual Core members and is discussed in a later section.

Physical Connections
To make an IRF Virtual Core operate normally, you need to connect the Virtual Core members physically. Physical ports that are dedicated to Virtual Core connection on devices are called physical Virtual Core ports. You can set a physical Virtual Core port to a Virtual Core port, which is a logical port. A Virtual Core port can correspond to one physical Virtual Core port or, to realize link backup, can be aggregated from multiple physical Virtual Core ports (known as aggregate Virtual Core port). The binding between a physical Virtual Core port and a Virtual Core port varies with device models. On a device, the Virtual Core port ID can be either 1 or 2, also known as the left port and the right port. You can connect physical Virtual Core ports with either dedicated cables or fibers. Dedicated cables provide higher reliability and performance; whereas fibers connect physical devices located very far from each other and provide flexible application. An IRF Virtual Core typically has a bus connection or a ring connection:

Bus connection: Given a device, its left port is connected to the right port of another device, and its right port is connected to the left port of a third one, as shown in Figure 1-1. In a bus connection,

1-1

each of the devices across the bus connection is connected with the other devices through only one fabric port.

Ring connection: Given a device, its left port is connected to the right port of another device, and its right port is connected to the left port of a third one, as shown in Figure 1-1.

A ring connection is more reliable than a bus connection. The failure of one link in a ring connection does not affect the function and performance of the Virtual Core, whereas the failure of one link in a bus connection causes the split of the Virtual Core. Figure 1-1 Physical connections of IRF Virtual Core

IRF Core ring topology

IRF Core Chain

Application and Advantages

Typically, you can use an IRF Virtual Core in the distribution layer; and you can also apply it in the access layer. An IRF Virtual Core is a single logical device to the users and devices of the upper layer and lower layer, as shown in Figure 1-2.

1-2

Figure 1-2 IRF Virtual Core networking

IRF Virtual Core has the following advantages:

Simple management

After an IRF Virtual Core is formed, you can log in to the IRF Virtual Core system by connecting to a port of any Virtual Core member. When you log in to the IRF Virtual Core, actually you log in to the master device of the Virtual Core. You can manage all IRF Virtual Core members by configuring the master, for example, allocating IP addresses to the members, interconnecting the members, and running routing protocols.

Powerful network expansion capability

By adding member devices, you can increase the number of Virtual Core ports, expand network bandwidth, and improve processing capability of the Virtual Core system.

High reliability

Not only the physical IRF Virtual Core ports of members can be aggregated, but also the physical links between the Virtual Core system and the upper or lower layer devices can be aggregated, and thus the reliability of the Virtual Core system is increased through the link backup. The IRF Virtual Core system comprises two member devices: the master runs, manages and maintains the Virtual Core, whereas the slave (secondary) process services as well as function as the backups. When the master fails, the Virtual Core system automatically switches over to the secondary Virtual Core member to master immediately so that any service interruption will be prevented and implement 1:N backup.

1-3

IRF Virtual Core General Operation and Management

IRF Virtual Core management can be divided into three stages: topology collection, role election, and Virtual Core maintenance.

Topology Collection
Each device in a Virtual Core exchanges hello packets with the directly connected neighbors to collect topology of the entire Virtual Core. The hello packets carry topology information, including Virtual Core port connection states, member IDs, priorities, and bridge MAC addresses. Each member records its known topology information locally. At the initiation of the collection, the members record their own topology information. When a Virtual Core port of a member becomes up, the member sends its known topology information from this port periodically. Upon receiving the topology information, the directly connected neighbor updates the local topology information. The collection process lasts for a period of time. When all members have obtained the complete topology information (known as topology convergence), the Virtual Core will enter the next stage: role election.

Role Election
A Virtual Core is composed of multiple member devices; and each member has a role, which is either master or slave. The process of defining the role of Virtual Core members is role election. Role election is held when the topology is instable, such as, forming a Virtual Core, adding a new member, Virtual Core split, or Virtual Core merge. The master is elected according to the following principles one by one, until the only winner is found out:

The current master wins, even if a new member has a higher priority. A member with a higher priority wins. A member with the longest system up-time wins. A member with the lowest bridge MAC address wins.

In this stage, member ID collision, software version loading and Virtual Core merging are also handled, which are discussed in the later sections. When a device is booted, it first collects topology information and then participates in the role election. After that, the Virtual Core system can run normally. When the role election is finished, the Virtual Core enters the next stage: Virtual Core maintenance.

1-4

Virtual Core merge: The process of connecting two existing IRF Virtual Cores over fiber or copper links through regular Gigabit or 10 Gigabit ports. After the mergence, Virtual Core election is held, and members of the loser side reboot and join the winner side as slaves.

Virtual Core split: In an IRF Virtual Core, the failure of Virtual Core cables or power-off of a member causes physical disconnection between two devices, and the process is Virtual Core split.

Member number restriction: The number of Virtual Core members has an upper limit, which may vary with device models.

Virtual Core Management

Member ID
A Virtual Core system uses member IDs to uniquely identify and manage member devices. Because a Virtual Core of centralized devices functions like a logical distributed device, each member device is a board of the logical distributed device: the master is the active switching and routing processing unit (SRPU), and a slave is a standby SRPU and functions like a line processing unit (LPU). Therefore, the member ID is also called the slot number. As shown in Figure 1-3, a Virtual Core system comprises four members, which are numbered 1, 3, 4 and 6. After the Virtual Core is established, the Virtual Core system functions like a distributed device: slots 1, 3, 4 and 6 are inserted with boards, and each board has its own power supply unit (PSU), fan, CPU, console port and Ethernet interfaces. Figure 1-3 IRF Virtual Core

Interface name
For a device operating independently (that is, the device does not belong to any Virtual Core), its interface name is in the following format: unit ID/slot number/interface serial number, where

Unit ID is a fixed value of 1.

1-5

Slot number is the number of the slot in which the SRPU resides. For a chassis type device, SRPUs are fixed on the device, so the slot number is a fixed value, and the value varies with device models.

Interface serial number is dependent on the number of interfaces supported by the device. View the silkscreen on the LPU for the number of supported interfaces.

For example, Ethernet 1/1/1 is an interface on the independently operating device Sysname. To set the link type of Ethernet 1/1/1 to trunk, perform the following steps:
<Sysname> system-view [Sysname] interface ethernet 1/1/1 [Sysname-Ethernet1/1/1] port link-type trunk

For a Virtual Core member, the interface name also adopts the previously introduced format: unit ID/slot number/interface serial number, where

Unit ID is the member ID, and identifies the Virtual Core member on which the interface resides Meaning and value of the slot number and the interface serial number are the same as those on an independently operating device.

For example, Ethernet 1/1/1 is an interface on Virtual Core member slave 2 (member ID is 2). To set the link type of Ethernet 1/1/1 to trunk, perform the following steps:
<Master> system-view [Master] interface ethernet 2/1/1 [Master-Ethernet2/1/1] port link-type trunk

Virtual Core Maintenance

In an IRF Virtual Core, direct neighbors exchange hello packets periodically (the period is 200 ms). Without receiving any hello packet from a direct neighbor for ten periods, a member considers that the hello packets timed out, and the Virtual Core isolates the expired device in the topology and updates its topology database. When a Virtual Core port of a member becomes down, the member broadcasts the information to all the other members immediately. If the Virtual Core port of the master is down, an election is triggered.

IRF Virtual Core Configuration Task List

Before configuring an IRF Virtual Core, you need to define the roles and functions of all the members for better planning. Because the configuration of some parameters takes effect after device reboot, you are recommended to first configure parameters, and then connect devices physically, finally add the devices into the Virtual Core. After a device is added into an IRF Virtual Core, you can only perform service configurations on the master, and execute some simple commands on the slaves, like display, terminal, debug, and so on. Complete the following tasks to configure IRF Virtual Core: Task Configuring IRF Virtual Core Configuring Virtual Core Ports Setting a Member ID for a Device Specifying a Priority for a Virtual Core Member Remarks Required Optional Required

1-6

Task Specifying the Preservation Time of Virtual Core Bridge MAC Address Enabling Auto Upgrade of Boot Files Setting the Time Interval for Delayed Report on Link-Down State

Remarks Optional Optional Optional

Connect the physical Virtual Core ports of devices by using Virtual Core cables (a ring connection is recommended), and then power on the devices. Logging In to an IRF Virtual Core Logging In to the Master Logging In to a Slave Required Optional

Configuring IRF Virtual Core

Configuring Virtual Core Ports

Support for this function depends on the device model. For devices that support fixed Virtual Core ports, their Virtual Core ports were bound with their physical Virtual Core ports when they were shipped, and the IRF Virtual Core function was enabled on them. Therefore, these devices do not support Virtual Core port configuration.

A Virtual Core port is a logical concept. IRF Virtual Core can be enabled on a device only after the Virtual Core ports are configured (that is, the Virtual Core ports are bound with physical Virtual Core ports). The number of physical Virtual Core ports that can be bound to a Virtual Core port varies with device models. Some devices support one-to-one binding between the Virtual Core port and the physical port, see Error! Reference source not found. for configuration procedure; and some support one-to-many binding (the aggregation mode) between the Virtual Core port and the physical ports, see Error! Reference source not found. for configuration procedure. Follow these steps to configure Virtual Core ports (one-to-one binding mode) To do Enter system view Use the command system-view Required Bind physical Virtual Core ports to a Virtual Core port, and enable IRF Virtual Core on the Virtual Core port The default value varies with device models. IRF member-id IRF-port IRF-port-id port port-list Whether you can configure one port or multiple ports with the port-list argument depends on the device model. Remarks

1-7

The above configuration takes effect after the reboot of the device. The numbering rules for Virtual Core port and physical Virtual Core port depend on the device model. Typically, when you face the physical Virtual Core port panel, the Virtual Core port at your left hand is numbered 1 and the one at your right hand is numbered 2; the physical Virtual Core port begins numbering with 1 from left to right.

Follow these steps to configure Virtual Core ports (aggregation mode) To do Enter system view Configure aggregation Virtual Core port Use the command system-view IRF member member-id IRF-port IRF-port-id port port-list Required The default value varies with device models. Remarks

The above configuration takes effect after the reboot of the device. An IRF port that is bound with multiple physical IRF ports is an aggregation IRF port, which increases the bandwidth and reliability on the Virtual Core port. The maximum number of physical ports that can be bound with a Virtual Core port depends on the device model.

Setting a Member ID for a Device

The member ID of a device defaults to 1. During the establishment of a Virtual Core, when the devices that form the Virtual Core have duplicated member IDs, the member ID of the master is decided first, and then the member IDs of slaves are decided one by one according to their distances to the master, that is, the nearest slave gets the smallest available ID, and the nearer slave gets the smaller available ID, and so forth; after the Virtual Core is established, if the newly added device and another member have duplicated IDs, the Virtual Core system assigns the smallest available ID for the new member. You can also set the member IDs according to network planning. To avoid member ID collision, you are recommended to set member IDs in the following way: 1) 2) 3) 4) Plan the member IDs in advance. You can view the member IDs of a Virtual Core, and find out an unused ID for the new device. If the device is already a Virtual Core member, plug out the Virtual Core cables. Log in to the device to be added into the Virtual Core, and change its member ID to the unused ID found out in step 1. Save the current configuration. Power off the device, connect the device with Virtual Core cables and power it on. Follow these steps to set a member ID for a device:
1-8

To do Enter system view Set a member ID for a device

Use the command system-view IRF member-id renumber new-id Optional

Remarks

The member ID of a device defaults to 1

The above setting takes effect after the reboot of the device. In an IRF Virtual Core, member IDs are not only used to identify devices, but also used to configure Virtual Core ports and member priorities. Therefore, modifying a member ID may cause device configuration changes or even losses, so modify member ID with caution. For example, three members (of same device model) with the member IDs of 1, 2 and 3 are connected to a Virtual Core port. Suppose that each member has several ports: change the member ID of device 2 to 3, change that of device 3 to 2, reboot both devices, and add them into the Virtual Core again. Then device 2 will use the original port configurations of device 3, and device 3 will use those of device 2.

Specifying a Priority for a Virtual Core Member

Each Virtual Core member has a priority. During the master election, a member with the greatest priority will be elected as the master. The priority of a device defaults to 1. You can modify the priority through command lines. The greater the priority value, the higher the priority. A member with a higher priority is more likely to be a master, and more likely to preserve its ID in a member ID collision. Follow these steps to specify a priority for a Virtual Core member: To do Enter system view Specify a priority for a Virtual Core member Use the command system-view IRF member member-id priority priority Optional The priority of a Virtual Core member defaults to 1 Remarks

You can specify a priority for a member of the current IRF Virtual Core only. The setting of priority takes effect right after your configuration without the need of rebooting the device.

1-9

Logging In to an IRF Virtual Core

Logging In to the Master
After an IRF Virtual Core is formed, you can access the console of the Virtual Core system through the AUX or console port of any member device. Configure an IP address for the Layer 3 Ethernet interface or VLAN interface of a member device and make sure that the route is reachable, and then you can access the Virtual Core system remotely through Telnet, Web, or SNMP. When you log in to the Virtual Core, actually you log in to the master device of the Virtual Core. The master is the configuration and control center of a Virtual Core. After you configure the Virtual Core on the master, the Virtual Core system synchronizes the configurations to the slaves.

Logging In to a Slave
When you log in to a Virtual Core, actually you log in to the master device of the Virtual Core. The operation interface of the access terminal displays the master console. However, the device can redirect you to a specified slave device. After you are redirected to a slave device, the user access terminal displays the console of the slave device instead of that of the master device. The system enters user view of the salve device and the command prompt is changed to <Sysname-member ID>, for example, <Sysname-2>. What you have input on the access terminal will be redirected to the specified slave device for processing. At present, only the following commands are allowed to be executed on a slave device:

display quit return system-view debugging terminal debugging terminal trapping terminal logging

You can press Ctrl+K or use the quit or return command to return to the master console. At this time, the master console is reactivated, and therefore it can output system information and logs. Follow the step below to log in to the specified slave device: To do Use the command Required Log in to the specified slave device of a Virtual Core IRF switch-to member-id By default, you actually log in to the master device of a Virtual Core when you log in to the Virtual Core. Available in user view Remarks

1-10

Because users login to the Virtual Core system occupies large memory space, a Virtual Core system allows at most six users to log in at the same time. The permitted login user types are AUX, console, virtual type terminal (VTY), and true type terminal (TTY).

Displaying and Maintaining IRF Virtual Core

To do Display related information of the Virtual Core Display topology information of the Virtual Core Display the pre-configurations of all members of the Virtual Core (The pre-configuration takes effect after the reboot of the device.) Display the master/slave switchover states of Virtual Core members Use the command display IRF display IRF topology Remarks Available in any view Available in any view

display IRFconfiguration

Available in any view

display switchover state [ member-id ]

Available in any view

IRF Virtual Core Configuration Example

Network requirements
Three devices in an IRF Virtual Core form a bus connection. Their member IDs are 1, 2, and 3. Figure 1-4 Network diagram for IRF Virtual Core

Configuration procedure
1) The two devices are not connected. Power them on and configure them separately.

# Configure Switch 1.
1-11

<Switch1> system-view [Switch1] IRF member 1 renumber 1 Warning: Renumbering the switch number may result in configuration change or loss. Continue?[Y/N]:y [Switch1] IRF member 1 Virtual Core-port 2 port 2

# Configure Switch 2.
<Switch2>system-view [Switch2] IRF member 1 renumber 2 Warning: Renumbering the switch number may result in configuration change or loss. Continue?[Y/N]:y [Switch2] IRF 1 IRF-port 1 port 3

2) 3)

Power off the two devices. Connect them as shown in Figure 1-4 with Virtual Core cables. Power them on, and the Virtual Core is formed. Display IRF topology & Members Priority CPU-Mac 00e0-fc0f-8c06 00e0-fc0f-8c23

[7510-1]dis irf (Members) Switch Slot Role *+1 3 6 5 Slave 1 Master 1

-------------------------------------------------* indicates the device is the master. + indicates the device through which the user logs in. The Bridge MAC of the irf is: 0000-fc00-6504 Auto upgrade Mac persistent : no : no

[7510-IRF-1] dis irf topology Topology Info ------------------------------------------------------------------------irf-Port1 Switch 1 3 Link DIS UP 1 neighbor -UP DIS irf-Port2 Link 3 -neighbor Belong To 00e0-fc0f-8c06 00e0-fc0f-8c06

1-12

Specifying the Preservation Time of Virtual Core Bridge MAC Address

A device uses the bridge MAC address when it communicates with the outside as a network bridge. A bridge device on the network has its unique bridge MAC address. Some Layer 2 protocols (like LACP) use bridge MAC addresses to identify different devices. During the forwarding of Layer 2 packets, if the destination MAC address of a packet is the bridge MAC address of a device, it means that the packet is sent to this device. In an IRF Virtual Core, the bridge MAC address of a member device is called member bridge MAC address. The Virtual Core communicates with the outside as a single device; therefore, it also has a bridge MAC address, which is called the Virtual Core bridge MAC address. Typically, a Virtual Core uses the bridge MAC address of the master device as the Virtual Core bridge MAC address. You are recommended to configure the preservation time of Virtual Core bridge MAC address properly, otherwise, network problems will occur:

If a master leaves a Virtual Core to join another Virtual Core or to operate independently and the Virtual Core is configured to preserve the bridge MAC address permanently, bridge MAC address collision occurs and thus causes network communication problem.

If the master leaves the Virtual Core because of reboot or link failure and the Virtual Core is configured to change the Virtual Core bridge MAC address as soon as the master leaves, the unnecessary switch of bridge MAC address occurs and thus causes flow interruption.

Therefore, configure the preservation time Virtual Core bridge MAC address according to your network status:

Preserve for six minutes: After the master leaves, the bridge MAC address will not change within six minutes. If the master does not come back after six minutes, the Virtual Core system will use the bridge MAC address of the newly elected master as that of the Virtual Core.

Preserve permanently: No matter the master leaves the Virtual Core or not, the Virtual Core bridge MAC address remains unchanged. Not preserved: As soon as the master leaves, the system will use the bridge MAC address of the newly elected master as that of the Virtual Core.

Follow these steps to specify preservation time of Virtual Core bridge MAC address: To do Enter system view Configure the Virtual Core bridge MAC address to be preserved permanently after the master leaves Specify the preservation time of the Virtual Core bridge MAC address as 6 minutes after the master leaves Configure that the Virtual Core bridge MAC address changes as soon as the master leaves Use the command system-view IRF mac-address persistent always Optional IRF mac-address persistent timer By default, Virtual Core bridge MAC address is preserved for 6 minutes after the master leaves. Remarks

undo IRF mac-address persistent

1-13

The change of the bridge MAC address may cause a temporary flow interruption.

Enabling Auto Upgrade of Boot Files

If this function is disabled, when the boot files of slaves and that of the master are in different versions, the new member or the member with a low priority will not boot normally. You need to update the device version manually and add the device into the Virtual Core again. If this function is enabled, as soon as a device is added into a Virtual Core, the system compares its software version with that of the master. If the versions are not consistent, the device downloads the boot file from the master automatically, reboots with the new boot file, and joins the Virtual Core again. If the downloaded boot file and the local boot file have duplicate file names, the local file is overwritten. Follow these steps to enable auto upgrade of boot files in an IRF Virtual Core: To do Enter system view Enable auto upgrade of boot files in an IRF Virtual Core Use the command system-view IRF auto-update enable Optional Enabled by default Remarks

If the device model and the software version of the master have great variance, auto update may not function normally. Therefore, ensure that the device and the master have the same software version before adding the device into the Virtual Core.

After loading the masters boot file automatically, a slave configures the file as the boot file for the next boot and reboots automatically. Because system boot file occupies large memory space, to make the auto upgrade succeed, ensure that there is enough space on the storage media of the slave.

Setting the Time Interval for Delayed Report on Link-Down State

During the suppression time, the system cannot be aware of the switch between Virtual Core link states; after the suppression time, the link layer reports the link state changes to the system. Since unstable link state causes the reboots of devices, use this function to avoid this problem, and thus preventing service interruption. Follow these steps to set the time interval for delayed report on the link-down state of a Virtual Core: To do Enter system view Use the command system-view Remarks

1-14

To do Set the time interval for delayed report on the link-down state of a Virtual Core

Use the command Optional IRF link-delay interval

Remarks

The default value varies with device models.

Do not set the time interval to a very long time; otherwise, the Virtual Core system will not be aware of the Virtual Core topology changes in time and thus the service will be recovered slowly.

1-15