Reloading a VSF

Reloading a VSF cluster of Aruba switches, as in the firmware upgrade procedure discussed, is not obviously running straight forward. Since I tried to google a couple of times and really found no straight comment on what actually happens, here the summary of my findings.

Long story short. A warm boot with reload does not result in a predictable successfull manner. Never. Nowhere. That`s it!

The often cited vsf sequenced-reboot is only supported on the 5400 platform. So all the kind remarks for users with 2930F, 3810 or similar VSF enabled platforms are simply not helpful. Continue reading

How To: Firmware Upgrade on an VSF-Stack

Having created a VSF stack of Aruba 2930Fs, the immediate need of firmware maintenance is obviously raising the question of how!. Dealing with that, luckily a new software had been released and I was able to test.

Daring the result … it was shocking simple and runs as every other Aruba / Procurve firmware upgrade and you just have to cover the second vsf stack member.


vsf member 1
copy tftp flash 192.168.2.5 WC_16_07_0002.swi primary
vsf member 2
copy tftp flash 192.168.2.5 WC_16_07_0002.swi primary

Verify the upload with a show flash the firmware image something like, even you may Continue reading

How To: High Availability with Aruba 2930F – VSF

Considering recent posts on IRF, there was a need to get some availability with the more cost effective switches from the Aruba / ProCurve world. I did some research on that and luckily there are more than one option today with this platform – at least the 5400s (…) and in my case 2930s support this by default.

Considering redundancy you basically consider two types of high availability and these cover Layer 2 availability, traditionally suited with link aggregation which conventionally does not span several chassis, and Layer 3 availability for a redundant default gateway service.

In a traditional design, then with a couple of switches (at least four), you configure VRRP for L3 redundant default gateway service, LACP – link aggregation groups for L2 Continue reading

Musings on ProCurve Management Security

Im selben Atemzug noch die Bereinigung der Management Security. In diesen Überwachungsschweren- Zeiten ist das Thema Security ja ein bisschen mehr im Focus. Auch aktive Komponenten sind da nicht unbeteiligt und bevor man zur Hackerfahrschule verkommt wenigstens die grundlegende Absicherung der Netzwerk- Infrastruktur.

Im Falle HP networking ehemals ProCurve heisst das zunächst mal Keys und Zertifikat bauen:


crypto key generate ssh rsa
crypto key generate cert rsa 1024

crypto host-cert generate self-signed 05/01/2014 05/01/2018 192.168.11.12 ITINFRA MEINVEREIN SIMMERN RHINELANDPALATINATE DE

Continue reading

Musings on ProCurve timesync

Da waren sie wieder… meine drei Probleme. Was ich in früheren Installationen schon beobachtet habe ist, dass sich nicht alle Switches aus der HP ProCruve – ja die hat ihren Namen geändert – Familie absolut identisch benehmen. Passiert mir prompt gerade wieder. Eine Sammlung verschiedener Typen und teilweise divergenter Softwarestände und eindeutig nicht deterministisches Verhalten.

Ich mag das nicht. …

Continue reading

Configure VRRP on hp networking E5400-Family

Configuring redundant gateway services for hp ProCurve ProVision based switches is not a very big miracle. Basically its about switching it on. VRRP, saying virtual router redundancy protocol is similar to HSRP from  CISCO or CARP from Open BSD. VRRP itself as of today is standardized in RFC5798 by the IETF and follows hp’s habit of using industry standard protocols.

Why is it not redundant routing ? Well since the VRRP feature is enabled on an per VLAN basis and even more, it only defines a redundant IP interface within the according VLAN. The actual routing is covered independently from this. Assuming that the routing is configured properly the failing over IP interface ensures that the routing can happen. Itself provides only a redundant IP interface, which could be used as routing gateway, so we name the function redundant gateway services.

Different to other approaches by other vendors, VRRP only provides pairwise redundancy where the virtual IP interface is the same than the according VLAN IP on the owning routing switch. This address is failed over to the backup switch, who has a second IP interface configured in the VLAN. This is necessary to check the proper operation of the primary interface.

The partnering happens based on a so called virtual router ID, VRID which is defined within the VRRP configuration. This enables administrators to configure even different redundant IP gateways within one VLAN, if static routing requirements have this need.

So configuration on the Master works as follows. First configure the proper VLAN IP address. Naming VLANs is a clever approach and helps in the long run.

vlan 10
name "production east"
ip address 192.168.0.1 255.255.255.0

Then the VRRP feature is globally enabled:

router vrrp

Then the actual redundant IP interface is configured within the according VLAN context:

vlan 10
vrrp vrid 1
owner
virtual-ip-address 192.168.0.1 255.255.255.0
enable

Be aware that the VRID context is independently activated on a per VLAN basis and enabled within each VRID definition.

On the backup routing switch the VLAN IP configuration as wel as the VRRP activation look pretty much the same.


vlan 10
name "production east"
ip address 192.168.0.2 255.255.255.0

router vrrp

Within the VLAN based VRRP configuration here the backup role is defined:

vlan 10
vrrp vrid 1
backup
virtual-ip-address 192.168.0.1 255.255.255.0
enable

Voila, redundant gateway interfaces should be available.

Especially the strict creation of pairs is different to other implementations. Often sets of interfaces may be created. As well the assignment of the virtual IP as the identical IP that the VLAN IP on the owning router is not necessarily something other vendors do the same way. Very often the virtual IP is one and the local VLAN IPs are two different dedicated ones.