How To Configure IRF on HPE FF5700

Approaching a certain quality level of switching and routing, high availability evolves to be an obligation. In these terms, according to the different OSI service layers, there are many high availability protocols, securing the according network services. The Spanning Tree family as STP, RSTP, MSTP, PVST, protocols for link aggregation as LACP and layer three routing redundancy services like VRRP.

These protocols have the advantage, being vendor independent standards and presume to be interoperable. But either design gets complex, interoperability keeps its caveats or ressources are simply disabled and take over in failiure. Thats not exactly performance driving.

So vendors created stacks – which failed otherwise, or they started to create systems of higher complexity which proprietary created load sharing high availability clusters in the Continue reading

How-To: HPE FF5700 10G and Adapter Teaming to Windows 2012 R2

Vor einigen Wochen sind wir mit HPEs recht neuen 40G FlexFabric Switches aus der 5700er Familie gestartet.

Dem Duty Manager – bei HPE Service nach braucht man ja ein Installation Carepack um eine gescheite Firmware Version zu kriegen – dreimal darf der geneigte Leser raten was ich davon halte. Eine Aussage für die eben jene Hotline immerhin auch 144 Stunden während einer kritischen Inbetriebnahme gebraucht hat. Aber glücklicherweise ist dem nicht so und nach zehn ziemlich spannenden Tagen sind die Dinger jetzt tatsächlich im ruhigen Fahrwasser angekommen.

Zeit erste Konfigurationen aus dem Tagesgeschäft vor zu nehmen. Da wir eine IRF Konfiguration haben um einen komfortablen redundanten Netzwerk Core zu erhalten, bietet sich an auch Server per LACP an zu binden. Im IRF kann man ebendas Chassis- übergreifend auch Link Aggregation Groups anlegen. Dabei geht IRF über klassisches Continue reading

Musings on Software Defined Networking – SDN

Mal wieder etwas technisches: SDN – Softare Defined Networking mausert sich ja zum nächsten Hype – mit welchem Recht auch immer – und wie bei jedem Hype Thema springen die üblichen Verdächtigen zügig auf. Die Sprungrate hat dabei 2013 drastisch zugenommen – ob begründet oder unbegründet sei mal dahin gestellt.

Aufspringen bedeutet dabei ja gerne, dass man die Technologie, die man ohnehin schon im Haus hat etwas erweitert und dann seine eigene Deutung definiert, die einen natürlich zum gefragtesten Anbieter in dem Segment macht.

Nachdem VMWare als der Marktführer im Bereich Virtualisierung hier mit der Nicira Aquise hier früh 2012 den Reigen eröffnet hat lohnt sich ein genauerer Blick auf die Szenarien und Aufgabenstellungen, sowie den Status-Quo:

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.