Alcatel-Lucent Enterprise is not the first name that comes up in a UK switching conversation. Cisco, Aruba, and Arista dominate the marketing. But in practice, OmniSwitch platforms are deployed across a significant slice of the UK estate — education, healthcare, hospitality, and multi-site enterprise. If you've inherited an ALE environment, or if you're evaluating OmniSwitch as a cost-competitive alternative to more prominent brands, this post covers what you need to know to deploy it well.

The OmniSwitch range — 6360, 6560, 6860, and 6900 — runs AOS (Alcatel-Lucent OmniSwitch Operating System), a mature platform with a consistent CLI across models. The learning curve is real if you're coming from Cisco IOS, but AOS is well-documented and the configuration model is logical once you understand it. Where organisations run into trouble isn't the CLI — it's the deployment decisions that happen before anyone touches a console cable.

WHY ALE OMNISWITCH?

The honest answer to "why would an organisation choose OmniSwitch?" is usually one of three things: they already have it (legacy estate or inherited infrastructure), price (OmniSwitch is meaningfully cost-competitive on PoE-dense access switching), or the Virtual Chassis capability, which is genuinely strong for organisations that need a resilient core without the cost of chassis-based systems.

PoE budget is a real differentiator. The OmniSwitch 6560 and 6360 deliver high aggregate PoE output at a price point that undercuts comparable Cisco Catalyst or Aruba CX configurations — relevant for healthcare wards, lecture theatres, and hotel floors where PoE device density is high. The 6860 and 6900 series extend into aggregation and campus core, with 10G and 40G uplinks, and both support ISSU (In-Service Software Upgrade) when configured as Virtual Chassis. For more detail on ISSU and why it matters at the design stage, see our ISSU article.

AOS has been in continuous development for over 20 years. It is not a cutting-edge NOS in the way Arista EOS or Juniper Junos are, but it is stable, predictable, and supported. If the network team knows AOS, an OmniSwitch estate is low operational overhead.

VIRTUAL CHASSIS AND STACKING

Virtual Chassis (VC) is ALE's implementation of multi-chassis logical stacking — two or more OmniSwitch units managed as a single device: one IP address, one configuration, one CLI. This is the same concept as Cisco StackWise, Juniper Virtual Chassis, or Aruba VSF, and the deployment considerations are similar.

The physical link connecting Virtual Chassis members is the VFL — the Virtual Fabric Link. This is not a standard Ethernet uplink. VFL ports are dedicated SFP+ or QSFP+ ports (depending on model) and must be connected with appropriate DAC cables or short-reach fibre. Using the wrong transceiver or cable type is one of the most common sources of VC instability — check the ALE compatibility matrix before ordering cabling.

Chassis ID assignment is the step that most commonly causes problems in initial deployments. Each switch in the Virtual Chassis must have a unique chassis ID (1, 2, 3, etc.), and these must be set before you connect the VFL links and allow the VC to form. If you connect VFL cables before setting chassis IDs, the switches will negotiate automatically — and the result is often both units trying to elect themselves as chassis 1, triggering a conflict that requires a factory reset to resolve. The correct sequence is: configure chassis ID on each unit independently, then connect VFL cables, then power cycle.

Role election (primary/standby) is determined by a combination of chassis ID and uptime. The primary handles the control plane; the standby maintains a synchronised state and takes over if the primary fails. For planned maintenance, you can force a switchover from the CLI — useful for testing VC failover before you rely on it in production.

VLAN AND IP DESIGN

AOS VLAN configuration is port-based by default. You assign a default VLAN to each port, configure tagged (trunk) ports explicitly, and create IP interfaces per VLAN for inter-VLAN routing. The syntax differs from Cisco IOS, but the conceptual model is the same. For SMB-scale deployments, standard VLAN assignment is the right approach — keep the design flat and well-documented.

For larger campus or multi-building deployments, ALE supports SPB — Shortest Path Bridging (IEEE 802.1aq). SPB is a data centre and campus fabric technology that replaces traditional Spanning Tree with a loop-free, equal-cost multipath forwarding model. On OmniSwitch 6860 and 6900, SPB enables you to extend VLANs across a multi-node fabric without STP convergence delays or the operational complexity of MSTP. If you are designing a multi-building OmniSwitch campus, SPB is worth evaluating — but it requires consistent platform support across the fabric and careful planning of the IS-IS control plane that underpins it.

For most SMB and mid-market deployments, SPB is overkill. Use standard VLANs, IP interfaces per VLAN, and DHCP relay pointing to a central Windows Server or router-based DHCP service. If the environment includes 802.1X-based dynamic VLAN assignment (common in healthcare and education), AOS supports RADIUS-based dynamic VLAN assignment natively — test this with your RADIUS server before go-live, as the attribute mapping varies between RADIUS vendors.

COMMON CONFIGURATION PITFALLS

These are the issues that come up repeatedly on OmniSwitch deployments, particularly on inherited estates or first-time ALE installations:

  • Firmware mismatch between VC members — In a Virtual Chassis, all members must run identical AOS firmware. If you add a new switch to an existing VC or replace a failed unit with a switch on different firmware, the VC will refuse to form or will drop into a degraded state. Pre-stage firmware on all units before connecting VFL links.
  • Default credentials not changed — AOS ships with a default admin account. The password must be changed before the switch is placed on a production network. Obvious, but still found in the wild — especially on inherited estates that were "temporarily" left as-is.
  • Telnet left enabled — AOS enables Telnet by default. Disable it and enforce SSH-only management access before deployment. Configure an ACL on the management interface to restrict SSH access to your management VLAN or jump host.
  • NTP not configured — Without NTP, log timestamps are based on the switch's local clock, which drifts over time and often defaults to epoch zero after a power cycle. This makes log correlation useless for incident investigation. Configure NTP to a reliable UK stratum-2 source at deployment.
  • SNMP community strings left as defaults — AOS ships with default SNMP community strings. Change them, or better, migrate to SNMPv3 with authentication and encryption. A monitoring platform querying your switches with default community strings is a security gap.
  • PoE budget exceeded without planning — OmniSwitch platforms advertise a total PoE budget per switch or per chassis. In dense deployments (IP phones, APs, cameras, PoE lighting), it is easy to exceed the budget if devices are added incrementally without tracking. Use the PoE monitoring CLI to check consumption before adding devices, and size the power supply appropriately at design stage.

GETTING THE DEPLOYMENT RIGHT

A reliable OmniSwitch deployment follows a consistent sequence regardless of scale:

  • Pre-stage firmware — verify all switches are on the target AOS version before connecting VFL links or placing them in-rack
  • Set chassis IDs first — configure chassis IDs on each unit independently, then connect VFL cabling
  • Configure management access — SSH only, SNMPv3, restrict management VLAN access with an ACL, change default credentials
  • Verify VFL links — confirm VFL ports are up and the VC has formed correctly before proceeding with the rest of the config
  • Test Virtual Chassis failover — force a primary/standby switchover from the CLI and confirm that downstream connections remain stable
  • Configure NTP — time synchronisation on every device; verify with show ntp status
  • Document the IP scheme — VLAN IDs, IP interfaces, management IPs, DHCP relay targets, all in a format that can be handed to the next engineer
  • Back up the running config — push a copy to a TFTP server or repository before handing over to the client

An OmniSwitch estate that is deployed carefully and documented properly is low-maintenance and reliable. The platform is mature, the CLI is consistent, and ALE's support is responsive for customers on active service contracts.

NEED ALE SPECIALIST SUPPORT?

We deploy and support Alcatel-Lucent OmniSwitch infrastructure across the UK — from single-stack deployments to multi-site Virtual Chassis designs. Whether you're planning a new installation, refreshing an inherited estate, or troubleshooting an existing ALE network, we work with AOS day-to-day and bring the depth to get it right. See our Alcatel-Lucent services or get in touch to discuss your requirements.