Professional Documents
Culture Documents
Table of Contents
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
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
1-2
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.
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
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.
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
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
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
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
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.
Remarks
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.
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 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).
display IRFconfiguration
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
-------------------------------------------------* 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
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
1-13
The change of the bridge MAC address may cause a temporary flow interruption.
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.
1-14
To do Set the time interval for delayed report on the link-down state of a Virtual Core
Remarks
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