Connect. Secure. Manage.
Cisco ACI Policy Design
Translate application requirements into ACI tenants, endpoint groups and contracts, documenting permitted communication and policy ownership.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Cisco ACI policy design sets the rules for which apps can talk to each other. We map those needs to tenants, endpoint groups and contracts with clear owners. The aim is a set of rules your engineers can understand and change. It should allow required traffic without opening access that the business does not need.
Workload-led design
Start with application, compute and storage dependencies rather than the switch model.
Clear failure domains
Understand which links, devices and sites can fail together.
Operational clarity
Make fabrics, external routing and management responsibilities supportable.
Start with application relationships
We gather the flows that an app genuinely needs, including direction, service ports and supporting dependencies. DNS, identity, monitoring and backup can be as important as the main transaction. The app owner checks the need rather than asking the network team to infer it entirely from current traffic, which may include obsolete or unintended communication.
Observed traffic can help build the picture. But it is not automatically an approved access list. We distinguish required behaviour from historical access that no one has reviewed. Where the information is incomplete, the project can begin with discovery and a controlled policy-development stage. That uncertainty is visible in the scope instead of being hidden behind an overly permissive initial contract.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Give policy objects consistent meaning
Tenants, routing contexts, bridge domains and endpoint groups should align with the customer’s admin and app boundaries. We set out naming, ownership and allocation principles before creating large numbers of objects. The structure should make it possible to understand why a workload belongs to a group and who approves changes affecting it.
A policy model does not have to mirror the organisation chart or preserve every legacy VLAN boundary. We compare suitable approaches against scale, operational effort and the required security outcomes. Existing dependencies may justify a phased transition. The design records those decisions so that later engineers do not mistake a temporary migration arrangement for the permanent policy standard.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Define contracts and exceptions deliberately
We review provider and consumer relationships, filters and the effect of policy options supported by the chosen release. The aim is to allow the approved service without unintentionally broadening access. A contract name alone does not show what traffic is permitted. The actual filters, scope and endpoint classification must be examined together.
Exceptions such as shared groups, unrestricted contexts or broad external classifications receive clear review. They may be justified in a particular design. But they should not be enabled simply to remove an initial network access problem. We document why an exception exists, which systems it affects and how it will be revisited. This keeps the policy auditable without claiming that ACI setup alone establishes regulatory compliance.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Treat shared and external services as distinct cases
Applications often need common services in another routing context or beyond the fabric. We set out the required route availability and the separate security permission. L3Out policy, external endpoint classification and route-control settings are reviewed with the routing design. A learned external prefix does not on its own mean that the intended app traffic is permitted.
Stateful firewalls and other service devices can introduce extra constraints. We examine the traffic path in both directions and agree how policy and inspection duties are divided. The design should not accidentally bypass a required control when a route changes. Integration with the security team is therefore part of policy design, not a check postponed until rollout is complete.
Validate both access and isolation
The test plan includes representative permitted flows and deliberate checks of paths that should remain unavailable. Tests are authorised and targeted to the customer’s setup. We use endpoint, contract and forwarding evidence to explain the result rather than relying only on a successful ping or a dashboard health score.
Policy changes are introduced in manageable stages with a rollback plan. Application owners confirm the service outcome, and the network team records any exceptions needed during transition. A rule that restores access but grants a wider path than approved is not accepted silently. The customer receives a clear account of the difference between the target policy and any temporary operating state.
Make policy ownership sustainable
The handover links apps to their groups, contracts, shared services and approval owners. It defines a repeatable process for adding or retiring a service and checking for obsolete access. Configuration automation can help enforce standards. But the desired policy still needs human ownership and review. We avoid building a system that only the original consultant can interpret.
MCI can design policy for a new fabric or simplify an inherited ACI setup. Related work includes ACI external routing and ACI troubleshooting. For a scoped review, provide the current object model and app needs through an agreed secure channel. The deliverable will identify usable standards, justified exceptions and the tests needed to show the intended separation.
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 6566Choose option 1
sales@proxar.co.ukUK-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.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.