HP Comware switches have had IRF (Intelligent Resilient Framework) for years, and it was the basis of more simplified network topologies. Now it seems HP is preparing a next-generation of IRF !
The current IRF implementation (known as IRF2) supports grouping 2 up to 9 devices in 1 virtual system (the actual number varies per model).
IRF2: Distributed forwarding and the resulting requirement
One of the key features I like about IRF is the distributed forwarding nature of the technology. There is indeed 1 Master control/management plane and all other devices act as Slave control/management planes (hot standby/sync of control plane tables), but all members are active/active with regards to the data plane.
This required however that all devices in the IRF system would have equal ASIC forwarding capabilities (in order to perform the local member data forwarding in a consistent way), so hence the requirement for the same models inside the IRF system.
So an IRF system can be made with 4x5120EI, another one with 2×5900, etc. but it was not possible to combine a 5120 with a 5500 in a single IRF system.
I never found this a limitation. Vendors that do support this mixing, will need to admit that traffic entering a “dumb” stack member, will need to be sent inside the stack over the stacking links to the “smart” stack member, which will perform the actual forwarding decision process. Then the packet may need to be sent internally to the original “dumb” member, and finally it goes out to the actual network. This adds additional latency to the process (since the packet is physically processed by 2 or 3 devices).
Getting ready for next-generation IRF
Now it seems HP is getting ready to release a major new generation of IRF, which will support combining multiple models into 1 logical system.
On this public HP link I found some initial information :
Click to access 4AA5-3379ENW.pdf
UPDATE 8/7/14: link is currently broken
UPDATE 3/9/14: link is working again
The goal does not seem to group multiple models as “peers” on the same layer of the network, but to be able to combine e.g. the aggregation and access Layers (or Core and Access Layers) into 1 logical device.
The end result is a single, massive logical device, which can be managed as a single entity.
CB: Controlling Bridges
The top layer devices (which would operate in normal IRF) are known as the Controlling Bridges. These switches must be of the same model (classic IRF rules would apply).
Current document describes 12900/11900/5900 as candidates for the CB role.
The other model switches will be visible as line-cards for the the CB.
Current document describes 5700/5900/6125XLG as candidates for the PE role.
This seems to indicate that there is no special switch model which can only be used as PE ! These are all “normal” switches, which can either operate in stand-alone mode, in IRF mode (with other switches of the same model) or in PE mode (controlled by the CB).
All mentioned models are Comware7 based devices.
Mixing PE models
The new model supports mixing multiple switch models as PE devices. So a new IRF network could have:
* 11900 as CB with 40G and 10G line cards
* 5900AF-48XG-4QSFP+ as PE (10G for server access, available as Fiber/Copper models) using 40G links to the 11900 CB
* 5900af-48g-4xg-2qsfp+ as PE (classic 1G access for lower requirement devices) and using 10G links to the 11900 CB
Current document mentions 2 CB devices and 30 PE devices, but these number would be enhanced in the future.
The document does not mention any schedule, so we will need some patience to see when this will be released.
Interesting times ahead !
UPDATE 8/7/2014: The document seems to have moved on the HP site so the link is currently broken.
UPDATE 3/9/2014: The document link is working again
404 on the HP pdf link
Hi, yes, the doc seems to have moved, the link worked when I made the post. I’ll update the post. Thanks for the notification !
Great article peter!!!
Is there stacking between the 5900 anymore or is this no longer required due to the nature of EIRF? Also I’m assuming BAGGs can still be utilized to provide active/active forwarding off of servers?