HP FlexFabric 12900 IRF Configuration Guide
HP FlexFabric 12900 Switch Series
IRF
Configuration Guide
Part number: 5998-6237
Software version: Release 1135
Document version:6W100-20150427
Legal and notice information
© Copyright 2015 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or
use of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained
herein.
Contents
IRF overview ································································································································································· 3
Hardware compatibility ···················································································································································· 3
IRF benefits ········································································································································································· 3
Application scenario ························································································································································· 3
Network topologies ·························································································································································· 4
Basic concepts ··································································································································································· 4
Operating mode ······················································································································································· 5
IRF member roles ······················································································································································ 5
IRF member ID ··························································································································································· 6
MPU roles ·································································································································································· 6
IRF port ······································································································································································ 6
IRF physical interface ··············································································································································· 7
IRF domain ID ··························································································································································· 7
IRF split ······································································································································································ 7
IRF merge ·································································································································································· 8
Member priority ························································································································································ 8
Master election ·································································································································································· 8
IRF connection error notification ······································································································································ 9
IRF multi-active detection ·················································································································································· 9
Multi-active handling procedure ····························································································································· 9
LACP MAD ····························································································································································· 10
BFD MAD ······························································································································································· 11
Configuring IRF ··························································································································································· 13
General restrictions and configuration guidelines ······································································································ 13
Software requirements ·········································································································································· 13
IRF size and member ID restrictions ···················································································································· 13
MPU requirements ················································································································································· 13
IRF physical interface restrictions ························································································································· 13
Connecting IRF ports ············································································································································· 14
IRF link redundancy ··············································································································································· 14
Multichassis link aggregation ······························································································································ 14
Feature and IRF mode compatibility ···················································································································· 14
MAD and IRF domain restrictions ························································································································ 15
IRF merge restrictions ············································································································································ 15
Configuration backup ··········································································································································· 15
Setup and configuration task list ·································································································································· 15
Planning the IRF fabric setup ········································································································································· 16
Preconfiguring IRF member devices in standalone mode ·························································································· 16
Assigning a member ID to each IRF member device ························································································· 16
Specifying a priority for each member device ··································································································· 17
Binding physical interfaces to IRF ports ·············································································································· 17
Saving configuration to the next-startup configuration file ························································································ 18
Connecting IRF physical interfaces ······························································································································· 18
Setting the operating mode to IRF mode ····················································································································· 19
Accessing the IRF fabric ················································································································································ 20
Configuring IRF member devices in IRF mode ············································································································ 20
Assigning an IRF domain ID to the IRF fabric ····································································································· 20
Changing the member ID of a device ················································································································· 21
1
Changing the priority of a member device ········································································································ 21
Adding physical interfaces to an IRF port ··········································································································· 21
Enabling IRF auto-merge ······································································································································· 23
Configuring a member device description ········································································································· 24
Configuring IRF link load sharing mode ············································································································· 24
Configuring IRF bridge MAC persistence ··········································································································· 25
Enabling software auto-update for system software image synchronization ·················································· 26
Setting the IRF link down report delay ················································································································ 27
Configuring MAD ·················································································································································· 27
Displaying and maintaining an IRF fabric ··················································································································· 33
Configuration examples ················································································································································ 33
LACP MAD-enabled IRF configuration example ································································································· 33
BFD MAD-enabled IRF configuration example ··································································································· 36
Configuration example for restoring standalone mode ···················································································· 39
Support and other resources ····································································································································· 42
Contacting HP ································································································································································ 42
Subscription service ·············································································································································· 42
Related information ························································································································································ 42
Documents ······························································································································································ 42
Websites ································································································································································· 42
Conventions ···································································································································································· 43
Index ··········································································································································································· 45
2
IRF overview
The HP Intelligent Resilient Framework (IRF) technology creates a large IRF fabric from multiple devices to
provide data center class availability and scalability. IRF virtualization technology offers processing
power, interaction, unified management, and uninterrupted maintenance of multiple devices.
This book describes IRF concepts and guides you through the IRF setup procedure.
Hardware compatibility
An HP 12900 switch can form an IRF fabric only with devices of the same model.
IRF benefits
IRF provides the following benefits:
• Simplified topology and easy management—An IRF fabric appears as one node and is accessible
at a single IP address on the network. You can use this IP address to log in at any member device
to manage all the members of the IRF fabric. In addition, you do not need to run the spanning tree
feature among the IRF members.
• 1:N redundancy—In an IRF fabric, one member acts as the master to manage and control the entire
IRF fabric. All other members process services while backing up the master. When the master fails,
all the other member devices elect a new master from among them to take over without interrupting
services.
• IRF link aggregation—You can assign several physical links between neighboring members to their
IRF ports to create a load-balanced aggregate IRF connection with redundancy.
• Multiple-chassis link aggregation—You can use the Ethernet link aggregation feature to aggregate
the physical links between the IRF fabric and its upstream or downstream devices across the IRF
members.
• Network scalability and resiliency—Processing capacity of an IRF fabric equals the total
processing capacities of all the members. You can increase ports, network bandwidth, and
processing capacity of an IRF fabric simply by adding member devices without changing the
network topology.
Application scenario
Figure 1 shows an IRF fabric that has two devices, which appear as a single node to the upper-layer and
lower-layer devices.
3
Figure 1 IRF application scenario
Network topologies
The HP 12900 IRF fabric only supports the daisy-chain topology. For information about connecting IRF
member devices, see "Connecting IRF physical interfaces."
Basic concepts
This section uses Figure 2 to describe the basic concepts that you might encounter when you work with
IRF.
4
Figure 2 Two-chassis IRF fabric implementation schematic diagram
Device A
(Member ID=1)
Active MPU
Standby MPU
Network
interfaces
IRF physical
interfaces
IRF-port 2 IRF-port 1
IRF link
An IRF
fabric is
formed.
IRF
Master
(Member ID=1)
IRF’s master MPU
IRF’s standby MPU
Subordinate
(Member ID=2)
IRF’s standby MPU
IRF’s standby MPU
Device B
(Member ID=2)
Active MPU
Standby MPU
IRF physical
interfaces
Network
interfaces
In this figure, Device A and Device B form a two-chassis IRF fabric. The fabric has four MPUs (one active
and three standbys), and two times the number of interface cards that a single device provides. The IRF
fabric manages the physical and software resources of Device A and Device B in a centralized manner.
Operating mode
The device operates in one of the following modes:
• Standalone mode—The device cannot form an IRF fabric with other devices.
• IRF mode—The device can form an IRF fabric with other devices.
IRF member roles
IRF uses two member roles: master and standby (called subordinate throughout the documentation).
When devices form an IRF fabric, they elect a master to manage the IRF fabric, and all other devices back
up the master. When the master device fails, the other devices automatically elect a new master. For more
information about master election, see "Master election."
5
IRF member ID
An IRF fabric uses member IDs to uniquely identify and manage its members. If two devices have the
same IRF member ID, they cannot form an IRF fabric. If the IRF member ID of a device has been used in
an IRF fabric, the device cannot join the fabric.
Member ID information is included as the first part of interface numbers and file paths to uniquely identify
interfaces and files in an IRF fabric. For example, after you assign a device with member ID 2 to an IRF
fabric, the name of interface FortyGigE 3/0/1 changes to FortyGigE 2/3/0/1. The file path changes
from slot16#flash:/test.cfg to chassis1#slot16#flash:/test.cfg.
MPU roles
Each IRF member device has one or two MPUs. The following are MPU roles:
Role Description
Master MPU
Active MPU
Standby MPU
IRF port
An IRF port is a logical interface for the connection between IRF member devices. Every IRF-capable
device supports two IRF ports.
In standalone mode, the IRF ports are named IRF-port 1 and IRF-port 2.
In IRF mode, the IRF ports are named IRF-port n/1 and IRF-port n/2, where n is the member ID of the
device. The two IRF ports are referred to as IRF-port 1 and IRF-port 2 in this book.
Active MPU of the master device. It is also called the global active MPU. You
configure and manage the entire IRF fabric at the CLI of the global active MPU.
Active MPU on each member device. An active MPU performs the following
operations:
• Manages the local device, including synchronizing configuration with the
local standby MPU, processing protocol packets, and creating and
maintaining route entries.
• Handles IRF-related events, such as master election and topology collection.
For the master MPU, all other MPUs are standby MPUs, including active MPUs
on subordinate devices.
If a member device has two MPUs, the MPU backing up the local active MPU is
the local standby MPU from the perspective of the member device.
To use an IRF port, you must bind a minimum of one physical interface to it. The physical interfaces
assigned to an IRF port automatically form an aggregate IRF link. An IRF port goes down only if all its IRF
physical interfaces are down.
For two neighboring devices, their IRF physical links must be bound to IRF-port 1 on one device and to
IRF-port 2 on the other.
6
IRF physical interface
IRF physical interfaces connect IRF member devices and must be bound to an IRF port. They forward the
IRF protocol packets between IRF member devices and the data packets that must travel across IRF
member devices.
IRF domain ID
One IRF fabric forms one IRF domain. IRF uses IRF domain IDs to uniquely identify IRF fabrics and prevent
IRF fabrics from interfering with one another.
As shown in Figure 3, I
and Device D. Both fabrics use the LACP aggregate links between them for MAD. When a member
device receives an extended LACPDU for MAD, it checks the domain ID to see whether the packet is from
the local IRF fabric. Then, the device can handle the packet correctly.
Figure 3 A network that contains two IRF domains
Device A
Device C
RF fabric 1 contains Device A and Device B, and IRF fabric 2 contains Device C
Core network
IRF 1 (domain 10)
IRF link
IRF 2 (domain 20)
IRF link
Device B
Device D
IRF split
IRF split occurs when an IRF fabric breaks up into multiple IRF fabrics because of IRF link failures, as
shown in Figure 4. T
forwarding problems on the network. To quickly detect a multi-active collision, configure one of the MAD
mechanisms (see "IRF multi-active detection")
Access network
he split IRF fabrics operate with the same IP address. IRF split causes routing and
.
7
Figure 4 IRF split
IRF merge
IRF merge occurs when two split IRF fabrics reunite or when two independent IRF fabrics are united, as
shown in Figure 5.
Figure 5 IRF merge
Member priority
Member priority determines the possibility of a member device to be elected the master. A member with
higher priority is more likely to be elected the master.
Master election
Master election occurs each time the IRF fabric topology changes in the following situations:
• The IRF fabric is established.
• The master device fails or is removed.
• The IRF fabric splits.
• Independent IRF fabrics merge.
NOTE:
Master election does not occur when two split IRF fabrics merge.
Master election selects a master in descending order:
1. Current master, even if a new member has higher priority.
When an IRF fabric is being formed, all member devices consider themselves as the master. This
rule is skipped.
2. Member with higher priority.
3. Member with the longest system uptime.
8
Two members are considered to start up at the same time if their startup time difference is equal to
or less than 10 minutes. For these members, the next tiebreaker applies.
4. Member with the lowest member ID.
For a new IRF fabric, the subordinate devices must reboot to complete the setup after the master election.
For an IRF merge, devices must reboot if they are in the IRF fabric that fails the master election. The reboot
can be performed automatically or manually (see "Enabling IRF auto-merge")
After a master election, all subordinate devices reboot with the configuration on the master. The
configuration files of the subordinate members are retained, but the files do not take effect in the IRF
fabric. A subordinate member uses its own startup configuration file only after it is removed from the IRF
fabric.
IRF connection error notification
The device generates error messages when its IRF physical interfaces are connected to non-IRF physical
interfaces. The error messages use the form of "The port port can't receive irf pkt and has been changed
to inactive status, please check." The port argument represents the interface name of an IRF physical
interface that connects to a non-IRF physical interface.
The messages help you identify incorrect IRF connections to avoid issues including cross-chassis packet
loss and IRF split.
.
The error messages might be falsely generated when the IRF fabric is unstable. For example, the
messages might occur during an IRF setup, reboot, or IRF port binding modification process. If the IRF
connections are correct, the messages will not occur after the IRF fabric completes the process.
IRF multi-active detection
An IRF link failure causes an IRF fabric to split in two IRF fabrics operating with the same Layer 3
configurations, including the same IP address. To avoid IP address collision and network problems, IRF
uses multi-active detection (MAD) mechanisms to detect the presence of multiple identical IRF fabrics,
handle collisions, and recover from faults.
Multi-active handling procedure
The multi-active handling procedure includes detection, collision handling, and failure recovery.
Detection
The MAD implementation of this device detects active IRF fabrics with the same Layer 3 global
configuration by extending the LACP or BFD protocol.
These MAD mechanisms identify each IRF fabric with a domain ID and an active ID (the member ID of
the master). If multiple active IDs are detected in a domain, MAD determines that an IRF collision or split
has occurred.
IMPORTANT:
LACP MAD handles collisions differently than BFD MAD. To avoid conflicts, do not enable LACP MAD
together with BFD MAD.
9
For a comparison of the MAD mechanisms, see "Configuring MAD."
Collision handling
When MAD detects a multi-active collision, it allows one IRF fabric to forward traffic and sets all the other
IRF fabrics to the Recovery state. The Recovery-state IRF fabrics are inactive and cannot forward traffic.
LACP MAD uses the following process to handle a multi-active collision:
1. Compares the number of members in each fabric.
2. Allows the fabric that has the most members to forward traffic, and sets all other fabrics to the
Recovery state.
3. Compares the member IDs of their masters if all IRF fabrics have the same number of members.
4. Allows the IRF fabric that has the lowest numbered master to forward traffic, and sets all other
fabrics to the Recovery (inactive) state.
5. Shuts down all physical network ports in the Recovery-state fabrics except for the following ports:
{ IRF physical interfaces.
{ Ports you have specified with the mad exclude interface command.
In contrast, BFD MAD does not compare the number of members in fabrics. BFD MAD uses the following
process to handle a multi-active collision:
1. Allows the IRF fabric that has the lowest numbered master to forward traffic.
2. Sets all other fabrics to the Recovery state.
3. Takes the same action on the network ports in Recovery-state fabrics as LACP MAD.
Failure recovery
To merge two split IRF fabrics, first repair the failed IRF link and remove the IRF link failure.
• If the IRF fabric in Recovery state fails before the failure is recovered, repair the failed IRF fabric and
the failed IRF link.
• If the active IRF fabric fails before the failure is recovered, enable the inactive IRF fabric to take over
the active IRF fabric. Then, recover the MAD failure.
LACP MAD
As shown in Figure 6, LACP MAD has the following requirements:
• Every IRF member must have a link with an intermediate device.
• All the links form a dynamic link aggregation group.
• The intermediate device must be an HP device that supports extended LACP for MAD.
The IRF member devices send extended LACPDUs with a domain ID and an active ID. The intermediate
device transparently forwards the extended LACPDUs received from one member device to all the other
member devices.
• If the domain IDs and the active IDs in the extended LACPDUs sent by all the member devices are
the same, the IRF fabric is integrated.
• If the extended LACPDUs convey the same domain ID but different active IDs, a split has occurred.
LACP MAD handles this situation as described in "Collision handling."
10
Figure 6 LACP MAD scenario
Customer
premise
network
Intermediate device
LACP-enabled dynamic
link aggregation
IRF
LACP-enabled dynamic
link aggregation
IRF link
Master
Subordinate
BFD MAD
BFD MAD can work with or without intermediate devices. Figure 7 shows a typical BFD MAD application
scenario.
To use BFD MAD:
• Set up dedicated BFD MAD link between each pair of IRF members or between each IRF member
and the intermediate device. Do not use the BFD MAD links for any other purpose.
• Assign the ports connected by BFD MAD links to the same VLAN.
• Create a VLAN interface for the VLAN, and assign a MAD IP address to each member on the VLAN
interface.
NOTE:
The MAD IP addresses identify the member devices and must belong to the same subnet.
Internet
Common traffic path
LACP MAD traffic path
With BFD MAD, the master tries to establish BFD sessions with the other member devices by using its
MAD IP address as the source IP address.
• If the IRF fabric is integrated, only the MAD IP address of the master is effective, and the master
cannot establish a BFD session with any other member. If you execute the display bfd session
command, the state of the BFD sessions is Down.
11
• When the IRF fabric splits, the IP addresses of the masters in the split IRF fabrics take effect, and the
two masters can establish a BFD session. If you use the display bfd session command, the state of
the BFD session between the two devices is Up.
Figure 7 BFD MAD scenario
Customer
premise
network
Device
Link aggregation
IRF
VLAN 2
192.168.1.2/24
BFD MAD link
VLAN 2
192.168.1.3/24
Master
IRF link
Subordinate
Internet
12
Loading...