Connect. Secure. Manage.
Cisco Policy-Based Routing
Apply Cisco policy-based routing where normal route selection does not meet application needs, with tracking, fallback and exception handling.
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 policy-based routing, often called PBR, can direct selected traffic along a path that differs from the route normally chosen by the routing table. It is useful for specific WAN, migration or service-insertion requirements, but it introduces policy dependencies that must be documented and tested. MCI Network Services helps customers evaluate, deploy and troubleshoot PBR on supported Cisco platforms without turning the network into an unmanageable collection of exceptions.
Cisco-focused engineering
Design around the platform, traffic and failure behaviour you actually operate.
Change with evidence
Use pre-checks, acceptance criteria and a documented route back.
Operational handover
Keep the configuration, diagrams and responsibilities understandable after delivery.
Establish why normal routing is insufficient
A request for PBR usually begins with a particular application or source network that needs a different path. Examples include sending selected traffic through a security service, steering a migration subnet toward a temporary gateway or using a dedicated circuit for an approved business flow.
We first ask whether the requirement could be met more cleanly through routing design, segmentation or SD-WAN policy. PBR is not automatically the best solution simply because it can match a packet and change its next hop. The chosen approach should be understandable to engineers who will support it later.
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
Define the traffic match precisely
A policy may classify traffic using supported criteria such as source addresses or other packet attributes. We document the intended endpoints, applications and exclusions. A broad match can capture traffic that was never meant to use the alternate path.
We also check the platform’s forwarding capabilities. Feature support, hardware acceleration and interaction with other services can vary between Cisco operating systems and releases. A configuration accepted by the command-line interface is not sufficient proof that the intended traffic will be handled efficiently.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Consider return paths and stateful services
Changing the forward path does not necessarily change the return path. This matters when traffic crosses a stateful firewall, VPN tunnel or network address translation boundary. A service can fail even though packets leave through the intended interface if the return traffic follows a different route.
We trace both directions and identify the systems responsible for security inspection and address translation. The design should describe expected behaviour during normal operation and after a link failure. Where symmetrical routing is essential, the policy must account for it explicitly.
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 ↗Understand next-hop availability
A policy that forwards traffic toward an unavailable next hop can create an outage even while the ordinary routing table contains a working alternative. We review supported next-hop tracking or verification mechanisms and determine what should happen when the preferred path is lost.
Failover testing needs to include the recovery path as well as the initial failure. A policy may resume using a preferred circuit before the connected application is genuinely ready. We test representative traffic and document any limitations of the selected detection method.
Control policy complexity
A few carefully scoped PBR rules can solve a legitimate requirement. Dozens of overlapping exceptions can make troubleshooting difficult and create unexpected dependencies between teams. We use clear naming, match order and change records, with an owner for each policy.
Temporary migration policies should include a removal condition. Otherwise, a route exception introduced for a short cutover can remain in place for years and surprise engineers during a later network refresh. We review existing policies for obsolete source networks and unsupported next hops.
Deploy with a rollback plan
Before applying PBR to production interfaces, we capture the routing and forwarding state, confirm the match criteria and identify the affected applications. We prepare the exact changes and a rollback method that does not depend on the path being modified.
After implementation we verify that matching traffic takes the intended path and non-matching traffic continues to use ordinary routing. We inspect counters, supported platform diagnostics and end-to-end application behaviour. We also test approved failure scenarios, including loss of the preferred next hop.
Troubleshoot from the packet path
When a service becomes unreachable, we check whether the traffic matches the policy, which action is applied and whether the selected next hop is reachable. We compare that result with the normal routing table and the return path.
A common mistake is to investigate only the dynamic routing protocol while overlooking an interface policy that overrides the normal decision. We use configuration evidence and controlled tests to isolate the cause before making changes. Removing every policy during an incident can disrupt unrelated applications.
Maintain the service over time
PBR requires periodic review as circuits, applications and addressing change. Monitoring should detect the loss of a preferred path and provide enough context for engineers to understand the resulting traffic shift. Documentation should identify who may approve changes and which services depend on each exception.
MCI supports Cisco and Meraki networking throughout the UK, with particular emphasis on London, Kent, Sussex, Essex and Berkshire. We can review existing policy-based routing, determine whether a simpler design is possible and implement a controlled solution with measurable acceptance criteria.
Decide when to retire PBR
Policy-based routing can remain useful for long-lived service requirements, but it should not survive solely because nobody knows why it was introduced. During a network review we compare each rule with the current circuit inventory, application dependencies and security architecture.
If a policy is no longer required, we plan its removal as a controlled change. We verify the normal routing path before removing the exception, check both directions of application traffic and retain a rollback option. This reduces complexity without making assumptions about undocumented services that may still depend on the rule.
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.