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

Connect. Secure. Manage.

Campus Gateway Architecture

Evaluate whether Cisco Campus Gateway suits your wireless design, separating its traffic-handling role from traditional wireless controller assumptions.

Cisco Partner since 2009 Projects & ongoing support

Illustrative Cisco and Meraki equipment in organised data-centre racks
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.

Campus Gateway architecture plans how cloud-managed wireless traffic reaches central campus services. We set out forwarding paths, recovery and admin ownership around your actual network and apps. The design explains how the Cisco gateway fits the rest of the site. Engineers can then build and test it against the agreed service needs.

01

Coverage and capacity

Design Wi-Fi around the spaces, devices and traffic that depend on it.

02

Secure access

Align authentication, segmentation and guest access with the wider network.

03

Measured performance

Validate roaming, interference and user experience instead of relying on signal bars.

Describe the intended service boundaries

We find the sites, client groups and wireless services within scope. Corporate users, visitors and specialist devices may need different security and addressing treatment. The design records where each service terminates and which team owns the next part of its path. This prevents a centralisation project from accidentally merging boundaries that were important in the previous architecture.

The assessment also explains why Campus Gateway is being considered. Requirements may concern mobility, the placement of client VLANs or consistency of campus forwarding. We compare those needs with the current model and identify any services that should remain locally switched. The architecture should justify the extra component and its support duties, not assume that centralisation is automatically an improvement for every part of the estate.

Illustrative Cisco and Meraki fibre network rack with structured cabling
01Fibre, switching and the physical path behind the service.
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

Separate management, tunnel and client traffic

The relevant management and traffic paths are documented individually. Access points need supported network access to Campus Gateway, while the gateway needs its own management relationship and upstream network integration. We review addressing, routing, firewall permissions and path-MTU considerations for the actual topology. Different paths may share infrastructure, but their purposes and failure consequences should remain clear.

Client traffic is mapped from the wireless service to its central termination and onward to the permitted destinations. DHCP, DNS and security inspection are included in that map. The design sets out where VLANs exist and where routed boundaries begin. This is more useful for rollout than a single line labelled wireless traffic, which can conceal several independent setup and ownership decisions.

Illustrative Cisco Meraki wireless access point in a modern office
02Cloud-managed wireless for modern workplaces.

A useful starting point

Not sure where to start?

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

Talk to a specialist

Size normal and degraded operation

Sizing covers access points, clients, app demand and the capabilities of the chosen appliance and software combination. We check current supported limits and avoid treating a headline maximum as the appropriate design target. The upstream switching setup must also accommodate the resulting forwarding and address-resolution load, with suitable uplink capacity and operational headroom.

Where resilience is required, the architecture considers the service remaining after a component fails. A design that has adequate aggregate capacity only while every member is available may not meet its stated continuity aim. We document the expected degraded condition and the apps that must continue. That allows the customer to make an informed decision about capacity and risk rather than relying on the presence of two appliances.

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

Define dashboard organisation and mobility scope

The management layout should reflect ownership and the intended wireless service. We review how networks, access points and gateway clusters are organised in dashboard. Where supported multi-network features are appropriate, their prerequisites and setup relationships are included clearly. We do not assume that identical network names alone create a common roaming or policy domain across otherwise separate dashboard networks.

The mobility design identifies the areas through which clients need to move, the relevant addressing continuity and the authentication dependencies. Radio planning remains essential. A central forwarding architecture cannot make an endpoint roam correctly through a coverage gap. The Campus Gateway roaming design service provides the detailed mobility assessment where that is a principal project aim.

Illustrative Cisco and Meraki network operations centre with monitoring displays
04Visibility, monitoring and operational control.

Specify integration and change responsibilities

The architecture includes interfaces with firewalls, identity systems, monitoring and any service-discovery needs. Supported features are checked for the chosen release and rollout mode. We identify assumptions that require a pilot rather than presenting every desired integration as already proven. Any dependency owned by a third party has a named approval and escalation route.

The design package separates mandatory prerequisites from rollout choices and future options. It includes a migration outline, acceptance criteria and the main rollback constraints. These documents help the delivery team recognise when a proposed change departs from the approved architecture. They also make it easier for the customer to compare a complete engineering scope with a quotation that covers only appliance installation.

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

Produce evidence that supports implementation

A useful architecture review ends with decisions, diagrams and an actionable dependency register. We record the supported target state, the reasons for the major choices and the risks that remain. Where current documentation is incomplete, the missing information is identified before the rollout is scheduled. Unresolved questions are not concealed inside a drawing that appears finished but cannot yet be delivered safely.

MCI can take the design into Campus Gateway deployment or hand it to your own engineering team. Provide the current topology, wireless platform and intended service outcomes. We will define the architecture scope and the evidence needed for approval, keeping the design tied to actual campus operation rather than assuming that all centralised wireless setups should be built in the same way.

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

Technical references

Illustrative Cisco Meraki wireless access point in a modern office
07Cloud-managed wireless for modern workplaces.

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.