Resilience measures with HP IRF: ISSU, GR and MAD (Part I)

In an effort to come down to earth and cover a topic which can be useful for the majority of now-a-days Enterprises that have HP gear, I will cover resilience features one can/should use in a HP Networking environment along with IRF.

Though I don’t argue that this is a Best Practice for all cases, clustering HP (former 3Com) switches with IRF can be a great solution to a lot of problems. How? Basically using a simple and thus effective ingredient that speaks by itself: drastic topology complexity reduction. Aggregation of devices to function as one can be an early Christmas for many cases: You get to do so many more LAGs (MLAGs preferably), your Spanning Tree is much simpler (I’m not that big of a fan of the HPN marketing papers issuing STPs death certificate by IRF, you gotta admit human mistake!), your linkstate DB gets much simpler, and you have less devices to config and manage (after you get centralized control & management planes).

Creating a Non-stop network environment
I’m not going to focus on HP’s claim on convergence time above HPs claim. That should be left for a demo by HP guys. What I want to focus on are the Software features that can be used to create an even more resilient network along with IRF, and which require human config.
These features are In-Service-Software-Upgrade (ISSU) – so yes, you get this bonus feature on standalone switches (where this feature is not natively present) when you setup an IRF cluster – Graceful Restart, and Multi-Active detection – commonly know as split brain detection.

ISSU
First you have to take into consideration that the way IRF works when you do virtual clustering with standalone switches, is exactly the way chassis-based switches work: Master MPU controls Management & Control planes, synchronizes real time with standby MPU, and forwarding plane is active on all LPUs. The difference being that in standalone switches one of the switch acts as a Master and the all the rest of the nodes as standby “MPUs”.
So when your start a Software upgrade on a IRF stack, the first members to be upgraded are the standby nodes. After this job is completed, one of the standby nodes gets elected as the new master, and failover occurs. While the new elected node acts as Master, the former Master is upgraded. After this job is done, preemption-alike behavior occurs, and the former master gets reelected to the master role.
Note that the virtual cluster runs with a virtual Bridge MAC address, so L2 destination remains remains the same, and the only changes that might occur are on the link forwarding inside MLAGs. This should be neglectable if you have a solid config. Note also that the routing process (if any) running on the master will not be restarted during the service upgrade.

 

Comment Relative To former post “HP MSM Controllers Initial Setup Considerations”

This post is an answer to a comment relative to this former post “HP MSM Controllers Initial Setup Considerations“. (I wanted to add some drawings to the answer to make it clearer, so ended up using another post.) Thank you for your comment. Please let me know if I understood your comment well, or got it all wrong.

George P Isaac’s comment was:

Hi,
As per my understanding..In option 2 we have to do following config.

1.We should tag particular VLAN in either internet port or access port
2.we should assign IP address to particular VLAN and gateway..
3.Nothing is required in VSC mapping in AP group.

then Where will I specify VLAN mapping..??

“extending the ingress interface to the egress interface “– is this option used when internet port and tunneled network in same VLAN??

OK to be fair my post could have been clearer (probably related to the fact that I’m not an expert on HP’s MSM solution). I took the next figure from a MSM Controller Config manual (section 4-30), which summarizes pretty well in my opinion what the options are for Access-Controlled traffic.

Access-controlled Flow of traffic

So let me recap: “Option 2” should actually have been Option 2 A) and B). Essentially these options are:

2. A) Having Access-Controlled Clients doing Web Auth on the HP MSM Controller, and then being ejected straight to the a default Gateway of a different interface that bypasses the Corporate Network. So in summary what the Egress VLAN is doing is defining a new default Gateway – for instance the routing device connected to the Internet – for the controller to use specifically for the clients assigned to that VLAN. The reasoning for this option might be that the Network Admin is worried that it may allow clients to access corporate resources, the Controller’s default Gateway might not have the adjusted ACLs for handling the Client traffic, or you might prefer to simply save that router CPU. In any case – the main goal is to bypass the Corporate Network.

In this option Clients still have an IP address in a different subnet from the egress VLAN subnet. This is the reason why you should enable NAT on that interface (to simplify): because clients will be placed on a subnet to which the gateway has no route to. Alternatively you can also configure a Route on that gateway to that subnet.

2. B) Having Access-Controlled Clients doing Web Auth on the HP MSM Controller, and then being ejected to a restricted VLAN, and receiving IP addresses on the egress VLAN. Hence the term extending the Egress VLAN to clients. Sort of like in non-access-controlled scenarios, but in this case the controller is actually routing on the background, though clients can’t notice it.

Please note that Option 2 A) and B) have essentially one thing in common: clients bypass Corporate resources. However in example B, clients actually receive an IP address in the VLAN where they are ejected either given by a DHCP Server resident on that VLAN, or by the Egress VLAN’s Gateway, which is implementing DHCP Relay.

then Where will I specify VLAN mapping..??” 

So in both cases, you have to alternatives to specify the VLAN Mapping: VSC level or user-based level. In VSC level you simply grab all authenticated users and forward them on the same VLAN. In user-based Egress VLANs you get more granularity by specifying customized VLAN IDs to user account profiles. Or you can implement both altogether, where user-based specifics override VSC level Egress VLAN definitions.

However in option B – where you extend the Egress VLAN IP addressing to the clients – you have some additional settings to configure, which I specified in the previous post:

  • In the global DHCP relay settings, select the checkbox for extending the ingress interface to the egress interface. After this is enabled, you will no longer be able to specify the IP address and subnet mask settings on VSCs.
  • Disable NAT on the egress VLAN IP interface.
  • Set the MSM controller’s IP address for the default gateway and DNS server (it will forward them to the correct ones).

“extending the ingress interface to the egress interface “– is this option used when internet port and tunneled network in same VLAN??

Well the Egress VLAN (whether extended or not to the client) might be implemented in either port (LAN or Internet). I would rather say that this option might make sense being used when you prefer having the “Bypassing main Corporate Network feature” + “the non-access-controlled alike behavior” all together. This solution might greatly simplify your manual setup, when you want certain clients to access some corporate resources, for instance. Having the same Subnet as those corporate resources might be advantageous for your setup.

Hope this helps. Cheers!

Cota – Wireless Power baby!

I haven’t had the opportunity to return to blogging activity as much as I wanted, but no matter what your tech inclination inside the DC might be, whether you’re Cisco/Dell/IBM/HP/VMware/… oriented, I still think you’ll find this technology a cool one. Yes, I can’t resist to jump out of the Datacenter to share an exciting Startup company: Cota.

These guys want to bring to the market a Power Charger that works via… Wi-Fi. Yes, you read it right. We’re talking about using similar spectrum from current Wi-Fi (2.4GHz or 5GHz) to charge your mobile devices. And yes, no line-of-sight is needed, just like Wi-Fi signal can cross walls; though not without suffering likewise from interference on your charging power.

Can’t help to wonder if Peeble got 10M on Kickstarter, how much would this get? (And I do buy into the whole tech wearables concept!)

 

Cheers