Evaluating Switches
2018-07-15
Sometime in May I got a HPE/Aruba 2530-8G-Poe Switch on my desk to evaluate as a new model for L2 Switching with poe. Since we have quite a few ProCurve switches in the network already, and a few of them are 2520-8G-POE, it was a bit boring until I discovered the new REST-API. Even better, I found out that several of our deployed 2620-48 Switches also support this API, although at a lower version.
The API is relatively simple, and requires the web-management to be enabled (preferably via tls). There is also some documentation available from Aruba, but it does not always explain the data schemes needed to send data via POST/PUT. There is also a nifty little exxample python project on github:
arubaos-switch-python
funny enough, it has some example functions exporting port statistics to excel (who t.f. does monitoring via excel?).
While it was relatively easy to get up and running with it, I did find one gripe: It does not support any IPv6 Addresses in the native API functions, although it has a data type distinguisher for IP Version 4 on all IP Addresses. The current only workaround is to use the anycli call to execute a cli command and parse the text-output. While this is still much better than ssh screen-scraping an interactive cli, it is a very annoying downside of the api. This is 2018, and IPv6 is the current internet standard. Tech Support does not see this as broken, so the only way to get it fixed is to put pressure on the sales channels.
More evaluations
Due to the discovery of the REST-API, HPE/Aruba Switches became interesting again for the next generation of dormitory switching routers.
So I ordered a demo of some 2540, 2930f and a 3810M Switches to test.
After arrival, I connected them up, and ran the test IPv6-only due to the simlicity:
- Enable ospf3 on the interfaces connecting the 2930f to the next router on the exisiting network (EX4600 in this case)
- Enable ospf3 and ipv6-unicast routing on the 2930f
- Add an unused prefix to a vlan on the 2930f.
A connected client to that routed vlan was quickly online. Then the fun started:
All pings to ipv6 addresses, contacting a sntp server, outgoing syslog and snmp failed. Some puzzled looks and cli-poking later I found the issue to be the outgoing source-address of traffic originating from the switch. The are options to set the preferred-source to loopback, but those options are only working for legacy-IP. The only way to get outgoing traffic working was to add a global prefix to the transfer net, giving up the nice and simple unnumbered setup. Additionally, snmp always responds using the outgoing interface, not the dst-ip of the incoming request, making it impossible to use the loopback IP for monitoring.
What about the competion?
The same setup on a Juniper EX2300C worked fine.
Cisco with legacy-IOS Switches is not an option, and they are going into a more expensive direction. So No.
Arista would be nice, but too expensive, and no poe.
Why bother with HPE/ArubaOS-Switch anyways?
Assigning a vlan to a port is very easy on ArubaOS-Switch, as well as changing the vlan. On Juniper, you need to delete the old vlan from the port, set the new one and commit. To change an access-port from vlan 2 to vlan 3, you would execute these commands on both platforms:
Junos:
delete interface ge-0/0/0.0 family ethernet-switching vlan memebers 2 set interface ge-0/0/0.0 family ethernet-switching vlan members 3 commit
ArubaOS-Switch:
interface 1 untagged vlan 3 ## OR ## vlan 3 untagged 1
While I'm pretty used to the Junos Syntax by now, I'm not the only teammember, and others do prefer the ArubaOS way. And they are quite affordable.