Login
- Released At: 12-05-2025
- Page Views:
- Downloads:
- Table of Contents
- Related Documents
-
IRF 2.0 Technology White Paper
Copyright © 2025 New H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.
Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.
This document provides generic technical information, some of which might not be applicable to your products.
Contents
Generic logical software architecture
Simplified distributed multichassis system
Redundancy protection mechanisms of IRF member chassis devices
Flexible device connection options
Expanding system processing capability
Overview
Background
Communication devices are divided into two broad categories by form factors: fixed-port devices and modular devices.
· Fixed-port devices (also called centralized devices) are cost-effective, but are not highly reliable. They lack uninterrupted service protection and are typically not suitable for deployment at the core layer or distribution layer. Fixed-port devices are typically rigid. On a complicated network, administrators have to maintain many network devices and change the network topology whenever they add new devices.
· Modular devices (also called chassis or distributed devices) are highly reliable and provide high performance and high port density. They are typically deployed in important scenarios, such as the core layer and distribution layer. However, modular devices are typically expensive. They increase upfront investments of enterprises and have a higher cost per port than fixed-port devices.
H3C Intelligent Resilient Framework (IRF) technology combines the advantages of fixed-port devices and modular devices in costs and scalability. It virtualizes multiple physical devices at the same layer into one logical system called an IRF fabric, as shown in Figure 1. The IRF fabric appears as one node on the network. You can manage all the member devices in the IRF fabric from a single pane of management.
Since the inception of the virtualization concept, virtualization technology has been evolving and changing. Different vendors have implemented the technology in various ways, but the following common issues are generally present:
· Limited feature set—Most vendors have adopted entirely new system architectures in implementing virtualization technology. This means that technologies that are common and mature on other devices require separate support on virtual devices. The years of technological accumulation cannot be re-implemented in a short time. Therefore, virtual devices can only guarantee basic functionality support initially, and many value-added services might be missing.
· Differences in feature support compared to other products—Due to differences in basic architecture, many features are implemented differently on virtualization-supported products compared to any existing products. Customers must familiarize themselves with these differences before using such products. Moreover, when integrating these products with other products, it is necessary to understand the differences between each product, which makes management and maintenance difficult and increases maintenance costs.
· Immature technology leads to instability in operation—The immaturity mentioned here does not refer to the technology itself but to the application of the technology in a virtualization environment. For example, a characteristic of virtualization is that each member has independent control capabilities, and coordinating the control among members is a challenge. Furthermore, as members have equal status and each has the ability to interact with others, the number of interactions between members increases exponentially with the addition of more members, leading to the so-called N-squared problem. Virtualization must consider and address this issue effectively. In summary, these system-related issues require new technologies for various features. The immaturity of these new technologies can directly affect the performance and reliability of the product.
H3C IRF is constantly evolving. Developed on top of IRF 1.0, IRF 2.0 is more mature and offers more features. For the purposes of this document, the term "IRF" specifically refers to IRF 2.0. The subsequent sections will delve into the technical architecture and exemplar use cases of IRF 2.0.
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.
· Simplified network operation—Various control protocols running on different member devices as if they are running on one device. For example, routing protocols calculate the routes of the IRF fabric instead of calculating the routes of each member. This avoids a great number of protocol packet exchanges among the members, simplifies network operation, and shortens the convergence time during network flapping. In addition, this advantage of the IRF technology is not delivered by the common cluster technology, which only realizes the unified management of devices, and the devices in a cluster operate as independent nodes.
· Low costs—The IRF technology creates an IRF fabric from multiple low-end devices, and thus the IRF fabric has a higher port density and bandwidth and costs lower than using high-end devices.
· Powerful network scalability—By adding member devices, the number of IRF ports, network bandwidth, and processing capability of the IRF fabric can be easily expanded.
· Investment protection—Users only need to add new devices rather than replacing the original ones when upgrading a network because of the powerful network expansion capability of the IRF fabric.
· High reliability—IRF provides both link and node redundancy. An IRF fabric comprises multiple member devices that operate in 1:N redundancy. The master runs, manages and maintains the IRF fabric, whereas the subordinate devices process services as well as functioning as the backups. As soon as the master fails, the IRF fabric immediately elects a new master to prevent service interruption. In addition, you can aggregate both IRF links of members and the links between the IRF fabric and its upper or lower layer devices.
· High performance—You can increase the bandwidth and processing capability of an IRF fabric simply by adding member devices. Each member device has its own CPU and they independently process and forward protocol packets.
· Diversified features—IRF provides all features supported by a switch, including IPv4, IPv6, MPLS, security features, Open Application Architecture (OAA) modules, and high availability. Able to run these features efficiently and stably, an IRF fabric can be deployed in wider range of scenarios.
· Compatibility across H3C hardware platforms—IRF is a generic virtualization technology. It can virtualize hardware platforms in different form factors into an IRF fabric, including fixed-port devices and chassis devices.
Technology implementation
Basic concepts
IRF member roles
The devices that form an IRF fabric are called member devices. Each of them plays either of the following roles:
· Master—Manages the IRF fabric.
· Standby (or subordinate)—All members that operate as the backups of the master are called standby nodes or subordinates. When the master fails, the IRF fabric automatically elects a new master from one of the subordinates.
Master and subordinates are elected through the role election mechanism. An IRF fabric has only one master at a time. Other members are the subordinates.
IRF ports
An IRF port is a logical interface that connects IRF member devices. Every IRF-capable device has two IRF ports, called IRF-port 1 and IRF-port 2. To use an IRF port, you must bind a minimum of one physical interface to it.
IRF physical interfaces
Physical ports used for connecting members of an IRF fabric are called IRF physical interfaces. IRF physical interfaces can be dedicated ports, Ethernet copper ports, or Ethernet fiber ports, depending on the device model.
Common Ethernet fiber or copper ports forward packets to the network before they are bound to an IRF port. After they are bound to an IRF port, they forward traffic between IRF member devices, including IRF protocol packets and data packets that must travel between IRF member devices.
IRF merge
As shown in Figure 2, two IRF fabrics operate independently and steadily. IRF merge occurs when two split IRF fabrics reunite or when two independent IRF fabrics are united
IRF split
IRF split occurs when an IRF fabric breaks up into multiple IRF fabrics because of IRF link failures, as shown in Figure 3.
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. By default, the member priority of a device is 1. You can modify the priority value from the CLI.
Software architecture
The system architecture of an IRF fabric is as shown in Figure 4.
· IRF virtualization—This module automatically collects IRF topology, performs master election, and creates an IRF fabric from multiple member devices.
· Hardware—Hardware components.
· Device management—The management layer of the device. It enables management of device resources, including main processing units (MPUs) and different types of modules. The manageable devices include the abstracted forms of hardware and the logical devices discovered by the IRF virtualization component.
· System management and application modules—All management and control programs running on the device, including routing protocol modules and link layer protocol modules.
The IRF virtualization module creates an IRF fabric, and the device management module manages both the IRF fabric and physical devices and masks their differences. The application software does not have to take care of the differences on the physical layer and does not need to modify its internal mechanism or interfaces.
Figure 4 IRF software architecture
Establishing an IRF fabric
Physical connections
Selection of IRF physical interfaces
To establish an IRF fabric, physically connect the IRF physical interfaces of member devices. The connection medium depends on the IRF physical interfaces supported by the device.
· If you use IRF-dedicated ports as IRF physical interfaces, use IRF cables to connect them. This connection mode provides high reliability and performance for packet exchange between member devices.
· If you use Ethernet copper ports as IRF physical interfaces, use cross-over network cables to connect them. This connection mode improves resource use efficiency and saves costs. Ethernet copper ports can connect to the upstream or downstream devices to forward data traffic when they are not bound to IRF ports. After they are bound to IRF ports, they forward packets between IRF member devices. You do not need to purchase dedicated IRF connection cards or optical transceiver modules.
· If you use fiber ports as IRF physical interfaces, use fibers to connect them. This connection mode can connect distant physical devices, increasing flexibility.
IRF port connection requirements
When you connect two neighboring IRF members, follow these restrictions and guidelines:
· Connect the physical interfaces of IRF-port 1 on one member to the physical interfaces of IRF-port 2 on the other, as shown in Figure 5.
· Do not connect physical interfaces of both IRF ports on one member device to the physical interfaces of both IRF ports on the other device.
· For high availability, bind multiple physical interfaces to an IRF port.
Figure 5 Connecting IRF physical interfaces
IRF topology
An IRF fabric can use a daisy-chain or ring topology, as shown in Figure 6.
· Daisy chain topology is typically used to connect distant devices.
· Ring topology is more reliable than daisy chain topology. In a daisy chained IRF fabric, the failure of one link can cause the IRF fabric to split into two independent IRF fabrics. In ring topology, the failure of one IRF link does not cause the IRF fabric to split as in daisy-chain topology. Rather, the IRF fabric changes to a daisy-chain topology without interrupting network services.
Topology collection
Each member exchanges hello packets with the directly connected neighbors to collect topology of the IRF fabric. The hello packets carry the topology information, including IRF port connection states, member IDs, priorities, and bridge MAC addresses.
Each member records its known topology information locally. At startup, a member device records only its own topology information. When an IRF port of the member device comes up, the member device performs the following operations:
1. Periodically sends its known topology information out of the IRF port.
2. Upon receiving the topology information from the directly connected neighbor, it updates the local topology information.
After all members obtain the complete topology information (known as topology convergence), the IRF fabric moves to the master election stage.
Master election
An IRF fabric contains one master and multiple standby (or subordinate) devices.
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.
Master election selects a master in descending order, as follows:
1. The current master, even if a new member has a higher priority. (When an IRF fabric is being formed, all member devices consider themselves as the master, so this principle is skipped)
2. If all member devices are chassis devices, the following rules apply:
a. The local active MPU has higher priority than the local standby MPU.
b. The standby MPU of the original master device has higher priority than all MPUs on non-master devices.
3. The device with higher priority.
4. The device with the longest system uptime. (The system uptime of each member device is delivered in IRF hello packets.)
5. The member with the lowest bridge MAC address.
After a master is elected, an IRF fabric is established, with all other member devices as subordinates.
· An IRF fabric that comprises fixed-port devices operates like a chassis device, with the master acting as the active MPU of the IRF fabric, and the subordinates as the standby MPUs as well as interface cards, as shown in Figure 7.
Figure 7 
Fixed-port devices virtualization schematic diagram
· An IRF fabric that comprises chassis devices operates like a large chassis device, with more standby MPUs and interface cards than a single chassis device. The active MPU of the master is the active MPU of the IRF fabric. The standby MPU of the master, the active and standby MPUs of the subordinates are the standby MPUs of the IRF fabric, as shown in Figure 8.
Figure 8 Chassis devices virtualization schematic diagram
Managing an IRF fabric
Configuration synchronization
The configuration synchronization mechanism has two phases: bulk sync at startup and real-time sync during operation.
· Bulk synchronization
When multiple devices form an IRF fabric, a master is elected the first. The master uses its configuration file to start up. Then the master synchronizes its configuration to all the subordinates. When the subordinates are initialized, the IRF fabric is established. During the operation of the IRF fabric, when a new member joins the IRF fabric, the master also performs batch synchronization. The new member restarts and joins the IRF fabric as a subordinate. Then, the master synchronizes its configuration in bulk to the new member. The new member initializes with the synchronized configuration, without reading its local startup configuration file.
· Real-time synchronization
After all member devices initialize, the IRF fabric operates as a single device in the network. Users can log in on the console port or through telnet to any member device of the IRF fabric to manage and configure the IRF fabric. As the management core of the IRF fabric, the master responds to users’ login requests. Users perform configuration on the master, no matter through which member device, in what way do they log in to the IRF fabric. The master synchronizes users’ configurations to each subordinate, thus to make the configuration of each member device of the IRF fabric the same.
Member ID
An IRF fabric uses member IDs to uniquely identify and manage its members. For example, the interface number of an IRF fabric includes the member ID. Assume an interface on the device that operates in standalone mode was named GigabitEthernet 3/0/1. After the device joined an IRF fabric, it got a member ID of 2, and the name of the interface changes to GigabitEthernet 2/3/0/1. Member ID is also used in file management. For example, when the device operates in standalone mode, the path of a file was slot1#flash:/test.cfg. After the device joined an IRF fabric, the path changes to chassis1#slot1#flash:/test.cfg, which indicates that the file is saved on the board in slot 1 of member device 1. Therefore, member IDs must be unique.
If member IDs are not unique, an IRF fabric cannot be established. A device that has the same member ID as an existing member cannot join the IRF fabric. To ensure the uniqueness of member IDs, use the following two methods: Before establishing an IRF fabric, plan and configure member IDs for members. Adopt the member ID collision processing mechanism.
Maintaining an IRF fabric
IRF fabric maintenance involves monitoring the joining and leaving of the member devices, collecting new topology information, and maintaining the current topology.
Joining of a member device
During the IRF maintenance process, topology collection is performed. If a new member wants to join an IRF fabric, the IRF fabric may proceed according to the following situations:
· The newly added device did not belong to any other IRF fabric before it joins this IRF fabric. For example, you configure IRF on the device, power off the device, connect it to the IRF fabric with cables, and power it on. In this situation, the new member will be elected as a subordinate.
· The newly added device was in another IRF fabric before it joins this IRF fabric. For example, you configure IRF on the device, and connect it to another IRF fabric. Then, if you want to add the device to this IRF fabric, IRF merge may happen, which is not recommended. During the mergence, IRF election is held, and members of the loser side reboot and join the winner side as subordinates.
If a member joins an IRF fabric successfully, it is equal to adding a standby MPU and interfaces on the standby MPU for the IRF fabric.
A member device can be either manually added into an IRF fabric or automatically join an IRF fabric again when it recovers from a system failure or link failure.
Leaving of a member device
An IRF fabric can quickly determine whether a member device leaves in either of the following two ways:
· If neighbors are directly connected, when member device A is down or an IRF link is down, its direct neighbor Device B can be quickly aware of the leaving of Device A without waiting for IRF hello packet timeout. Then it broadcasts Device A’s leaving to all the other member devices of the IRF fabric.
· If neighbors are not directly connected (in other words, two member devices are connected by another device, and the device does not belong to the IRF fabric), when member device A is down or an IRF link is down, its direct neighbor Device B cannot be quickly aware of the leaving of Device A. However it can know Device A’s leaving through the IRF hello packet timeout mechanism. Then Device B broadcasts Device A’s leaving to all the other member devices of the IRF fabric.
The member device receiving the leave message determines whether it is the master or a subordinate that leaves according to the locally saved IRF topology information. If it is the master that leaves the IRF fabric, a role election will be held and the local topology is updated. If it is a subordinate that leaves the IRF fabric, the local IRF topology is updated directly to ensure fast convergence of the IRF topology.
|
|
NOTE: Member devices of an IRF fabric periodically (generally 200 ms a period) exchange hello packets to maintain neighbor relationship and send IRF running parameters. The IRF hello packet timeout mechanism is: if a member device does not receive IRF hello packets from its neighbor for several continuous periods (generally 10 periods), IRF considers the IRF hello packets timed out, and the member device has left the IRF fabric. Then IRF fabric will isolate the member device from the topology. |
A member device may leave an IRF fabric due to these reasons:
· Manual topology change to remove the member device
· Member device failure
· Link failure
Topology update
Topology change indicates that the topology changes from a daisy chain connection to a ring connection, or vice versa. For example, a ring connection may become a daisy-chain connection when a link fails; or, when adding new devices to an IRF fabric, you need to first change the ring connection to the daisy-chain connection, and then connect the new devices.
For this kind of topology update, the roles of the member devices do not change and only the forwarding path may be automatically changed when necessary, so the device functions are not affected.
Software auto upgrade
The IRF provides the auto loading function. When a new member is added to an IRF fabric, it does not need to have the same software version as the IRF fabric, but only needs a compatible version. When a device joins an IRF fabric, it compares its software version with that of the master. If the versions are not consistent, it automatically downloads the boot file from the master, reboots with the new boot file, and joins the IRF fabric again. If the device does not support this function, you need to manually update the software version to make the software versions of both the new member and the IRF fabric consistent and then the new member device can join the IRF fabric.
High reliability
Typically deployed at the access layer, distribution layer, and data center, an IRF fabric requires a high reliability. To shorten the down time caused by daily maintenance and burst system crash, IRF adopts a series of redundancy technologies to ensure reliability as follows:
· 1:N backup
· Protocol hot backup
· Up/down link backup
· IRF port backup
1:N backup
A common chassis device adopts 1:1 backup. It is installed with two MPUs. The active MPU processes services, and the standby MPU operates as the backup to keep synchronization with the active MPU. When the active MPU fails, the standby MPU immediately takes the responsibility of the active MPU.
An IRF fabric provides 1:N backup. The master processes services, and the subordinates operate as the backups of the master. When the master fails, one of the salves is selected as the master. During the running of the IRF fabric, strict configuration and data synchronization is performed. Therefore, the new master can take the responsibility of the original master to manage and run the IRF fabric, without affecting the original network functions and services. In addition, existing of multiple subordinates can improve the reliability of the system.
An IRF fabric that comprises chassis devices manages the active MPU and standby MPU of each member device as the main boards of the IRF fabric, increasing the reliability of the system.
Protocol hot backup
In a 1:N backup environment, protocol hot backup backs up the configuration data of a protocol and the data supporting the running of the protocol (for example, state machine or session table entries) to all the other member devices. Then the IRF fabric can operate as an independent device in the network.
Take routing protocols as an example. As shown in Figure 9, RIP and OSPF run on different networks. When the master receives the update packets sent from a neighboring router, it updates its routing table, and sends the updated routing table entries and protocol state information to all the other member devices. Upon receiving the entries and protocol state information, the member devices update their local routing tables and protocol states, thus to ensure consistency of the routing-related information of each physical device in the IRF fabric. When the subordinates receive the update packets sent from their neighbors, they send the packets to the master for processing.
As shown in Figure 10, when the master fails, the new master can take the responsibility of the old master seamlessly. Upon receiving the OSPF packets sent from a neighboring router, the master sends the updated routing table entries and protocol information to all the member devices, without affecting the running of the OSPF protocol. In this way, when a member device fails, the other member devices can operate normally and can quickly take the responsibility of the failed member device. In addition, the intra-domain routing protocol processing will not be interrupted, and Layer 2 and Layer 3 forwarding traffic and services will not be interrupted either, thus implementing fault protection and device switching without service interruption.
Figure 9 Protocol hot backup diagram (before a member device failure)
Figure 10 Protocol hot backup diagram (after a member device failure)
Uplink/downlink backup
IRF uses a distributed aggregation technology to implement uplink/downlink backup. The traditional aggregation technology aggregates multiple physical Ethernet ports (known as member ports) to implement link backup. However, it does not have a backup mechanism for a single-point failure. The new distributed aggregation technology supported by IRF adds the physical Ethernet ports on different devices to an aggregation port group. Even if the device where some ports reside fails, the aggregation link will not become invalid. Other member devices that work normally will manage and maintain the other aggregation ports. This is of great importance to the network environments with core switching systems and having high-quality service requirements. It not only solves the problem of single-point failure of aggregation devices, but also increases availability of the entire network. As shown in Figure 11, the traffic that goes to the core network is distributed evenly on the aggregation links. When an aggregation link fails, the distributed link aggregation technology can automatically distribute the traffic to other aggregation links to implement link backup and increase network reliability.
Figure 11 Uplink/downlink backup diagram
IRF port redundancy
IRF uses an aggregation technology to implement IRF port backup. As shown in Figure 12, multiple physical links can be aggregated to share load, which effectively increases bandwidth and performance. In addition, the physical links back up one another, ensuring that even if one link fails, the IRF function is not affected, thus increasing the device reliability.
For an IRF fabric that comprises chassis devices, the aggregated physical ports can be on the same interface card, or on different interface cards, which means cross-card aggregation of IRF ports is supported. When one interface card fails, the operation of the IRF fabric will not be affected.
Packet forwarding mechanism
IRF adopts a distributed resilient forwarding technology to implement Layer 2 and Layer 3 packet forwarding, making use of the processing capability of each member device to the maximum extent. Each member device of the IRF fabric has complete Layer 2 and Layer 3 forwarding capabilities. When a member device receives a Layer 2/3 packet to be forwarded, it finds the outbound interface (and the next hop) of the packet by searching its Layer 2/3 forwarding table, and then forwards the packet from the outbound interface. The outbound interface can be on the local device or on another member device. Forwarding packets from the local device to another member device is unknown to external networks. In other words, no matter how many member devices the Layer 3 packets traverse, the hop count is increased by one only.
As shown in Figure 13, the inbound and outbound interfaces of the packet to be forwarded are on the same device. When Subordinate 1 receives the packet, it searches its forwarding table, and finds that the outbound interface is on itself; then it will forwards the packet from the outbound interface.
Figure 13 Intra-device forwarding
As shown in Figure 14, the inbound and outbound interfaces of the packet to be forwarded are not on the same member device. When Subordinate 1 receives the packet, it searches its forwarding table, and finds that the outbound interface is on the master, and then it forwards the packet to the master over the optimal path, and the master forwards the packet to the end user through the outbound interface.
Figure 14 Cross-device forwarding
Figure 15 illustrates how IRF processes multicasts. Upon receiving a multicast, Subordinate 1 searches its multicast forwarding table, and finds that both Master and Subordinate 3 have connected multicast group members, and the optimal path from Subordinate 1 to Subordinate 3 is through Master. Therefore, Subordinate 1 forwards the multicast to Master, which makes three copies of the multicast, where two of them are forwarded to the multicast group members connected to Master, and the other is forwarded to Subordinate 3, which then forwards the multicast to other multicast group members. Each member device only needs to replicate the multicast as needed, ensuring that only one copy of the packet is transmitted among the devices, which saves system resources and increases processing speed of multicasts.
Figure 15 Multicast forwarding
Technical feature highlights
Generic logical software architecture
The biggest difference between IRF and other virtualization technologies is that it is not specific to a certain type of product, but is a generic logical software architecture. With this software architecture, devices of the same type can be connected to form a single logical device as needed. For example, IRF can combine fixed-port devices or chassis devices to ensure the consistency of the virtualization functions of different types of products.
In this software architecture, IRF is a relatively independent function. It affects part of the system, rather than the stability of the whole system.
Mature system architecture
Different from other virtualization technologies, IRF adopts a widely applied system architecture rather than a new architecture.
IRF adopts a generic distributed system architecture. At present, the distributed system architecture has been applied on multiple kinds of H3C devices. A mature architecture has many advantages over a brand-new architecture:
· Stable system: Defects of the system developed based on a mature system architecture have been solved, while a brand-new system architecture is bound to bring some problems specific for this architecture.
· Optimal performance to ensure stable, reliable and effective operation of an IRF fabric.
Simplified distributed multichassis system
Few techniques are available to virtualize chassis devices into a logical device. Even those that exist offer limited functionality for the virtual devices they create and support a minimal number of member devices, for example, allowing only two devices to be virtualized. This limitation stems from the traditional design approach where multichassis distribution adds an additional layer of management for the chassis, thus evolving into a two-tiered distribution system. The first tier manages the distribution among different chassis, while the second tier manages distribution among the cards within a chassis. Implementing a two-tiered distribution requires an enhancement of the current multilayer switching architecture by adding an extra layer, significantly increasing complexity over the existing models. These solutions are characterized by their high complexity, low performance, poor reliability, and impracticality.
IRF addresses this issue by combining multiple chassis devices to form a larger logical chassis device with one active MPU, multiple standby MPUs, and multiple interface cards. The difference between this system and existing chassis-based distributions lies merely in the number of backup and interface cards, with no architectural difference, thus maintaining the complexity at the same level as conventional chassis-based distributions. Consequently, the number of member devices is not limited by the system architecture but is only determined by the hardware's capacity.
Wide range of stable features
IRF supports IPv4, IPv6, MPLS, security features, Open Application Architecture (OAA) modules, and high availability techniques, and ensures that these functions are effective and stable.
Most virtualization techniques use new architectural approaches, which necessitates specialized support for functions that are standard and well-developed on traditional devices. For example, high-availability features common on chassis systems are often limited or absent in many virtualization platforms.
In contrast, IRF, built on a universal software architecture, enhances the original system for virtualization without changing its interfaces or mechanisms. This ensures that functionalities from the original system are seamlessly inherited by an IRF fabric, maintaining feature richness and continuity. Administrators do not need to separately investigate the compatibility or functionality of the features with an IRF fabric, making their life easier.
Efficient 1:N backup
While regular chassis devices provide 1:1 backup, an IRF fabric provides 1:N backup, with which multiple standby MPUs are available for higher system reliability.
Typically, 1:N backup is bandwidth intensive. The required bandwidth increases along with the value of N. Other virtualization techniques tackle this issue by either limiting high availability features to focus resources on critical tasks or implementing cold redundancy, which only backs up static data. This approach compromises functionality and performance for 1:N redundancy but doesn't effectively address the core issue.
IRF combines the high reliability of 1:N redundancy with the high performance of 1:1 redundancy without sacrificing either. It decreases the O(N) complexity in data backup to O(1) complexity by using a multicast group. Its unique O(1) algorithm ensures that the resource consumption by standby MPUs remains constant, irrespective of their number.
Redundancy protection mechanisms of IRF member chassis devices
While IRF delivers the 1:N redundancy, a chassis device also provides two MPUs operating in 1:1 redundancy. Some other virtualization techniques abandon the intrinsic redundancy mechanisms of chassis devices, relying solely on the redundancy mechanisms offered by virtualization. This approach introduces an issue: when a member device's MPU malfunctions, service interruption occurs on the service cards controlled by that MPU, although the entire virtual device can still continue to operate due to 1:N redundancy. In contrast, IRF retains both types of redundancy. When one MPU fails, the chassis device can continue to operate normally with another MPU. This further enhances system availability.
Flexible device connection options
Compared with common virtualization technologies, IRF provides more connection options. In addition to connecting devices with dedicated cables, you can use common copper or fiber Ethernet ports to connect IRF member devices. The requirements on IRF ports depend on the device model.
You can also build an IRF fabric of distant devices by connecting them with optical fibers. This is a unique IRF benefit that regular chassis device or common virtualized device cannot offer. This makes IRF applicable to more networking environments.
Application scenarios
Increasing port density
As shown in Figure 16, when the number of access users outgrows the ports of the switch, add a switch in the original IRF fabric to increase the number of ports.
Figure 16 Increasing port density with IRF
Expanding system processing capability
As shown in Figure 17, when user traffic outgrows the forwarding capability of the core switch, add a switch to build an IRF fabric with the original core switch. If the forwarding capability of one switch is 64 Mpps, a two-member IRF fabric will provide a forwarding capability of 128 Mpps in total.
Figure 17 Expanding system processing capability with IRF
Expanding bandwidth
As shown in Figure 18, you can increase the uplink bandwidth of the edge switch by adding another switch to build an IRF fabric with the edge switch. You can configure multiple physical links of the member devices as an aggregation group to increase bandwidth of the link to the core switch. To the core switch, the number of edge switches does not change. The original edge switch will back up the current configuration to the newly added switch in bulk, which minimizes the impact on the network planning and configuration.
Figure 18 Expanding bandwidth with IRF
Connecting distant devices
IRF connects devices located far from each other with optical fibers to form an IRF fabric. As shown in Figure 19, users on each floor are connected to the external network through a wiring-closet switch. You can connect the wiring-closet switches to form an IRF fabric. In this way, there is only one access device on each building, which simplifies the network structure. There are multiple links to the core network on each floor, which makes the network more robust and reliable. Configuration of the IRF fabric rather than multiple wiring-closet switches reduces management and maintenance costs.
Figure 19 Connecting distant devices with IRF
Simplifying network topology
Typical redundancy design uses MSTP and VRRP for link backup and gateway backup. This networking is applicable to many environments, and distribution and access layer networking is taken as an example.
With IRF enabled, multiple devices on the distribution layer form an IRF fabric, to which the accessing devices are connected. This network design removes complicated MSTP and VRRP, simplifying network configuration. In addition, with multichassis link aggregation, MSTP convergence and VRRP convergence are eliminated when a member device fails. This increases network reliability.
Figure 20 Simplifying network topology with IRF
