Cisco & Meraki specialists. Across the UK.
+44 203 196 6566 · option 1sales@proxar.co.uk

Connect. Secure. Manage.

Catalyst StackWise Virtual

Design and implement StackWise Virtual on supported Cisco platforms, validating dual-active detection, link resilience and planned maintenance behaviour.

Cisco Partner since 2009 Projects & ongoing support

Illustrative Cisco and Meraki fibre network rack with structured cabling
Your network. Properly considered.Design · Implementation · Support
1,000+

Devices supported
across the UK

20+

Client locations
supported

Nearly 8 Tbps

Traffic handled
at peak time

3 min

Average
response time

Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.

Catalyst StackWise Virtual lets two supported Cisco switches work as one logical system. It differs from a standard switch stack. We check the links between the two units, their shared control functions and the devices attached to them. The design must fit both your failure plan and the way you will carry out maintenance.

01

Cisco-focused engineering

Design around the platform, traffic and failure behaviour you actually operate.

02

Change with evidence

Use pre-checks, acceptance criteria and a documented route back.

03

Operational handover

Keep the configuration, diagrams and responsibilities understandable after delivery.

Establish whether StackWise Virtual is appropriate

The main reason to consider StackWise Virtual is usually to simplify the logical topology while connecting critical access, distribution or core services to two physical switches. It can support multi-chassis link aggregation on eligible platforms. But it does not make the whole network immune to failures. The effect of a software defect, setup error or upstream incident must still be assessed.

We start by identifying the business apps and the network functions hosted on the proposed pair. These may include Layer 3 gateways, aggregation links, routing adjacencies and connections to security appliances. A design that is suitable for an office distribution layer may not suit a data-centre setup with different convergence or change-isolation needs.

Illustrative Cisco and Meraki equipment in organised data-centre racks
01Data-centre connectivity with clear physical and logical boundaries.
Cisco PartnerCisco Partner
Cisco MerakiCisco Meraki
ISO 9001Quality management
ISO 27001Information security
Cyber EssentialsCyber Essentials
Cyber Essentials PlusCyber Essentials Plus

MCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information

Confirm platform and feature support

StackWise Virtual support is platform- and release-dependent. We check the exact Catalyst hardware, supervisor setup where relevant, software version, interface needs and supported feature combinations against current Cisco documentation. We do not assume that a capability available on one Catalyst family applies to another.

Licensing, optics and the available high-speed ports also need attention. The inter-switch link consumes physical capacity that may otherwise have been allocated to network services. We review how many ports are required, their placement, the permitted link combinations and the operational consequences of losing one or more of those links.

Illustrative Cisco and Meraki industrial network equipment in a plant environment
02Network engineering for operational and industrial environments.

A useful starting point

Not sure where to start?

Bring the requirement. We will help you define the engineering work.

Talk to a specialist

Design the virtual link and dual-active detection

The StackWise Virtual Link carries essential communication between the two chassis. Its design should consider bandwidth, physical separation, cable paths and the supported redundancy arrangement. We document what happens if one link fails and what conditions could isolate the members.

Dual-active detection is a particularly important part of the design. If the switches lose the ability to coordinate, both must not continue forwarding in a way that creates conflicting active roles. We choose and check the supported detection mechanism for the specific platform and topology. A diagram that shows two switches and a connecting cable is not enough evidence of a safe high-availability design.

Illustrative Cisco and Meraki data-centre network infrastructure
03Network infrastructure designed around the workloads it carries.

Review downstream and upstream connectivity

Multi-chassis EtherChannel can simplify connections to compatible downstream devices, but its behaviour must be considered alongside spanning tree, routing and app traffic. We check the proposed port-channel membership, physical diversity and what a connected device does when one chassis becomes unavailable.

Upstream connections may use routed interfaces or other supported arrangements. We review routing adjacencies, gateway placement and the convergence behaviour expected during failover. Firewall clustering and internet-edge routing can introduce their own state and timing dependencies. The complete traffic path needs validation rather than assuming a switching failover guarantees app continuity.

Illustrative Cisco and Meraki network rack in a modern office
04The office network: switching, uplinks and structured cabling.

Plan changes and software upgrades

A pair of physical switches operating as one logical system has a different maintenance model from two independent routed devices. Software upgrades, reloads and changes to the settings must follow the supported process for the platform and release. We review the maintenance window, expected traffic impact, backup needs and rollback limitations before making changes.

Where an in-service or reduced-impact upgrade method is supported, we still check the exact prerequisites. We avoid promising zero downtime simply because a feature is described as high availability. Applications with strict latency or session needs may notice even short forwarding changes, and customers should know what will be tested and what remains outside the scope.

Illustrative enterprise Cisco network rack in a modern office environment
05Enterprise switching and routing, built to be operated.

Validate resilience with controlled tests

Acceptance tests should show the intended behaviour under agreed fault scenarios. These may include a failed uplink, a failed virtual-link member, loss of a chassis or an approved role-transition test. We record the observations, including routing reconvergence and app reachability where practical.

Not every failure test is appropriate on a production system. We agree which tests can be performed safely, which require a maintenance window and which risks need to be accepted based on lab evidence or vendor documentation. The resulting handover should state what has actually been checked, rather than presenting theoretical resilience as a proven result.

Illustrative Cisco and Meraki fibre network rack with structured cabling
06Fibre, switching and the physical path behind the service.

Operate and troubleshoot the system

Ongoing management should monitor the virtual system’s health, inter-switch links, role state and connected port channels. The operations team needs current diagrams, supported software records, backups of the settings and clear escalation steps. An incident involving split control-plane communication demands a different response from an ordinary failed access port.

MCI supports Cisco and Meraki networks across the UK, with a strong engineering presence in Kent and services covering London, Sussex, Essex, Berkshire and beyond. If you are assessing StackWise Virtual or troubleshooting a current rollout, we can review the topology, compatibility, risk to the live services and evidence needed for a controlled rollout.

Illustrative Cisco and Meraki equipment in organised data-centre racks
07Data-centre connectivity with clear physical and logical boundaries.

Talk to a specialist

What does your network need next?

Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.

+44 203 196 6566

Choose option 1

sales@proxar.co.uk

UK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.

Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.

Tell us what you need.

A short outline is enough. Please do not include passwords or sensitive network details.

Thank you. Your enquiry has been submitted.

We’ll use these details to respond to your enquiry. Please leave out passwords and sensitive network information. Read our privacy notice.