Connect. Secure. Manage.
Cisco Route Redistribution
Control route exchange between Cisco routing domains, using explicit policy and testing to avoid loops, unexpected paths and excessive route propagation.
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 route redistribution allows prefixes learned by one routing protocol or source to become available in another routing domain. It is useful during migrations and at carefully controlled network boundaries, but it can also introduce routing loops, ambiguous path selection and widespread outages when applied too broadly. MCI Network Services helps organisations design, audit and troubleshoot redistribution policies on supported Cisco routers and switches.
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.
Identify the reason routes must cross domains
We begin by documenting the connected routing systems, such as OSPF, EIGRP, BGP and static routes. Each redistribution point should have a clear purpose: a migration boundary, a partner interconnect, a data-centre transition or a controlled exchange between operational domains.
Not every prefix needs to cross every boundary. We identify the applications and endpoints that require reachability, then define the smallest appropriate set of advertisements. This makes the policy easier to understand and reduces the potential impact of an incorrect route.
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
Establish prefix ownership and direction
A redistribution design should identify where each prefix originates and which domain is authoritative for it. Without this record, two routers may reintroduce the same destination into one another’s protocols and create route feedback. This can produce unstable routing even though every individual configuration command appears valid.
We document the permitted direction of route exchange and the conditions under which an advertisement should be withdrawn. Default routes deserve explicit treatment because they influence a broad range of destinations. A default route should not continue to be advertised when the service it represents has failed.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Design metrics and route preferences
Different routing protocols use different metrics and route-selection rules. A route redistributed from one protocol into another needs appropriate attributes so that its behaviour is predictable. We review seed metrics, administrative distance and any platform-specific settings relevant to the design.
A route with an unexpectedly attractive metric may draw traffic away from the intended path. Conversely, a route with an unsuitable metric may remain unused until a failure, when the backup path behaves differently from what the customer expects. We test normal and degraded states, not just the presence of the route in a table.
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 ↗Use filtering and route tags deliberately
Prefix lists, route maps and supported policy mechanisms can constrain what is redistributed. We prefer explicit allow lists for critical boundaries where practical, rather than importing all routes and trying to block exceptions later. The policy should be readable by another engineer during an incident.
Route tags can help identify where routes originated and prevent inappropriate reintroduction at another boundary. They are not a substitute for an overall routing design. We define how tags are assigned, preserved and interpreted across the protocols involved, and verify that the selected platforms support the required behaviour.
Consider high availability and multiple boundaries
A network with two redistribution routers can improve availability, but it also introduces the possibility of different policies and competing advertisements. We review what happens when one boundary fails, when it returns and when a prefix is reachable through only one side.
Asymmetric routing may affect stateful firewalls or applications that expect consistent paths. We therefore consider the complete forwarding route, including return traffic, rather than checking only the route-selection result on one router. Failure testing should include the interaction between redundancy and redistribution policy.
Plan migrations in stages
Redistribution is often introduced temporarily when moving from EIGRP to OSPF, replacing a WAN service or connecting a newly acquired network. Temporary policy can become permanent if the project lacks a removal plan. We define the intended end state before introducing the transition mechanism.
A staged migration may begin with a limited prefix set, monitoring and controlled application tests. We establish rollback criteria and identify which routes must remain available throughout the cutover. Once the new routing domain is stable, obsolete redistribution should be removed and the documentation updated.
Troubleshoot unexpected routes
When a destination appears through the wrong path, we trace its origin through each protocol boundary. We examine route attributes, redistribution policy, administrative distance and the actual forwarding state. Logs and recent configuration changes help explain when the behaviour began.
We avoid adjusting administrative distance or metrics at random until the route becomes reachable. Such changes can hide a feedback loop or shift traffic to an unintended path. The incident record should explain the underlying cause and the reason the final policy is safe.
Maintain policy over time
Every redistribution point should have an owner, an approved prefix policy and a review process for new networks. Monitoring should detect unexpected advertisements and route loss where practical. Configuration backups and change records help engineers compare the live state with the intended design.
MCI provides Cisco and Meraki network services throughout the UK, particularly London, Kent, Sussex, Essex and Berkshire. We can review existing redistribution, support a routing migration or help resolve unstable path selection with controlled changes and verifiable results.
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.