It's nice when you boot an appliance and the web user interface doesn't look like it was designed by a guy who thought Jurassic Park and The Net were the pinnacle of UI design. The A10 Advanced Core OS (ACOS) has an incredibly polished look to the WebUI. Frankly, its beautiful. All chrome and glass so to speak…

 

Overall, the Web UI is very easy to navigate and options are not buried more than 2 clicks deep. However, there are two areas where the ACOS Web UI is absolutely a pain in the rear:

  • Grid-metaphor editing.
  • Heinous layout for the relationship between physical interfaces, VLANs and virtual interfaces.

Grid Editing 

One of the most common day-to-day tasks we end up doing with a load balancer is enabling/disabling a batch of real servers for upgrade. Generally, we want to:

  1. Disable real servers A, C, and E. (Leaving B & D enabled).
  2. Upgrade A, C, and E.
  3. Swap A, C, and E back into battery and take B & D out.
  4. Upgrade B & D.
  5. Put B & D back in.

This is a perfect application where you want to be able to pull up the settings for multiple entries in one edit table. With the settings for real servers A,B,C,D, and E up on the same page, you can change all of the applicable settings all at the same time, verify each server is correct, then bam!…slam the new settings into place all at once. Unfortunately, this is not possible with the ACOS Web UI. The only thing you can do to multiple entries at once is delete them:

 

But simple maintenance of real server status is not the only place with the table editing metaphor is helpful. It is indispensable when trying to balance which VLANs are on which physical ports. Having to drill into an entry, make the change, and then re-examine the grid view to see how it looks is very tedious. It's much easier to pull up all the necessary interface/VLAN assignments on one view, edit them in-place and then apply them with a single-click once they look right. It seems that the goal of any good Web UI should be  to minimize round trips and enable batch application as much as possible. This was an area where the Nauticus/Sun Web UI was phenomenal. Any grid view could be turned into an edit table. On the other hand, if you only selected one entry to edit, the Nauticus Web UI was smart enough to reformat the one entry into a single column of editable values (so it fit horizontally without scrolling). Quickly swapping batches of real servers in and out of service is not a task we're looking forward to with the AX2200.

Network Relationships & Just Being Friendly 

This is not an uncommon metaphor for dealing with VLANs and the IP interfaces that sit on them:

  • VLANs entries belong to physical interfaces.
  • Virtual IP interfaces are created and belong to specific VLANs entries.

To A10s credit, it's a familiar metaphor that is instantly accessible, and they even kept the ve0, ve1 virtual interface naming convention that's common to Cisco and Foundry equipment. Where they went wrong is not making it easy to tag a friendly name onto the VLAN and virtual interface entries.

What's the purpose of VLAN 1234? Well it's attached virtual interface ve0…that's helpful. What on God's Green Earth does ve0 serve? You can't tell easily from the VLAN page. You either have to dig out your documentation, or open the virtual interface list in a separate window:

 

The simple solution on Foundry and Nauticus/Sun gear was what you could call “friendly names”: A simple user description for each VLAN, interface and virtual interface. Can't remember what VLAN 1234 does…no problem…it's friendly name says “tier1_realservers”. Oh! That's right, VLAN 1234 contains the application servers for tier 1 of our application and ve0 is the virtual interface that serves that subnet. Toggling back and forth between tabs in Firefox for VLANs and virtual interfaces while setting up the test AX2200 has been a barrel of monkeys. Frankly, “friendly” or “vanity” names should be able to be attached to any type of entry whether it's a real server, a physical interface, or an SSL certificate.

Other nits so far: 

  • Appliance will not boot if hard drives are not in exactly the same slots as shipped (not expected for a RAID-1 setup).
  • Can't find a mechanism in the Web UI to generate a CSR.
  • Can't find a way to import a PEM file (Must import certificate and key file separately.)
  • There doesn't appear to be a way to load certificates and keys by pasting them into a text box.
  • Host name is not notated at the top of the GUI and in the page title at all times to help identify which box you're in.
  • Virtual interfaces that are already in use still show up in the VLAN creation screen as assignable. Only when “Apply” is clicked does a JavaScript alert box tell you there's an issue.
  • Physical front panel status light only blinks when there's a problem. Does not turn amber or red. Very unnoticeable if you don't already know there's an issue.
  • Showing system interfaces via the CLI is “sh int” instead of “sh sys int” on Foundry gear.

The last one is not something normally you'd complain about. All networking vendors seem to do it differently. However, given the fact that A10 is staffed with so many ex-Foundry Networks folks, and the fact that the ACOS CLI is identical to Ironware in so many areas, it's an unwelcome surprise when “sh sys int” errors out while you're in the CLI.

Needless to say, we're still talking about the AX2200, so we're fairly happy with what we've seen so far. However, “friendly naming” and table editing  really need to be fixed in an upcoming version of ACOS. The current way of doing things is probably only acceptable in very small environments where the boxes don't get touched very much. This weekend is dedicated to SLB testing…so hopefully more advanced configuration is where the Web UI really comes together.

That's all that's fit to print as they say.

Technorati Tags: , , , ,