Connect. Secure. Manage.
BGP RPKI Validation
Assess and deploy BGP origin validation on supported Cisco platforms, with validator resilience, policy choices and tests for invalid route 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.
BGP RPKI validation checks whether a network is allowed to announce an IP prefix. It helps you decide which routes to accept. It does not make that decision for you. We plan route-origin checks on supported Cisco devices, including the source of the validation data, who keeps it current and what to do when it cannot be reached.
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.
Separate publishing authorisations from checking routes
A Route Origin Authorisation, or ROA, is created by the relevant resource holder through its RPKI arrangements. A router’s validation process checks received route origins against checked authorisation data. Publishing your own ROAs and checking routes received from others are related activities, but doing one does not on its own complete the other.
We establish who controls the customer’s address resources, who may maintain authorisations and which routers will consume validation data. Provider-assigned space needs particular care because the customer may not control the relevant resource certificate. These ownership questions are resolved with the appropriate party before routing policy is changed.
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
Understand valid, invalid and not-found results
Origin validation produces a result that the routing policy must interpret. A valid result means the announcement is covered by suitable authorisation. An invalid result can arise from an origin or permitted-prefix-length mismatch. Not found shows that no covering authorisation establishes a validation result for that route.
Those states are not equivalent to good, malicious and safe. An invalid route can be an admin mistake, and a valid origin does not prove that every part of the AS path is legitimate. We explain these limits and avoid describing RPKI as complete route-hijack or route-leak prevention. Peer-specific route filtering remains necessary.
A useful starting point
Tell us what is happening.
A short description of the problem is enough for an initial discussion.
Review your own advertisements first
Before enforcing a receiving policy, we review the customer’s published prefixes, originating AS numbers and expected more-specific advertisements. The ROA’s permitted maximum length should match the real routing design rather than being unnecessarily broad. A planned traffic-engineering change can otherwise make a legitimate announcement invalid to networks that enforce validation.
We include backup providers, migration arrangements and disaster-recovery advertisements in that review. The normal route may be valid while a rarely used failover route is not. Changes to resource ownership or origin AS need a coordinated sequence, with enough time to check that new authorisation data is visible before the advertisement changes.
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 ↗Design validator availability and router behaviour
Routers normally get checked prefix-origin information from an appropriate validation service rather than performing every repository-validation task themselves. We assess the supported router-to-validator arrangement, transport protection, reachability and monitoring. Validator infrastructure is a service dependency and should have an owner and recovery procedure.
Failure behaviour matters as much as normal operation. We test or document what the chosen rollout does when a validator becomes unreachable, data becomes stale or a session is restored. We do not assume that every Cisco platform or software release treats these events identically. The customer should understand whether routes remain usable and how the condition is reported.
Move from observation to enforcement deliberately
A staged rollout can begin by observing validation results without immediately changing forwarding policy. We compare unexpected invalids with resource records and provider information, then agree how enforcement will be introduced. This gives the operations team evidence and a chance to correct its own authorisations before a policy change affects critical services.
Any exception needs a narrow scope, a business reason and an expiry or review date. A permanent blanket bypass would defeat much of the purpose of validation. We also ensure the chosen policy applies to the intended address families and peers, rather than assuming an IPv4 setup protects IPv6 advertisements as well.
Test the result beyond the configuration screen
Acceptance includes validator network access, received validation data, route-state classification and the actual import decision. Controlled test cases should show the treatment of valid, invalid and not-found routes without announcing unauthorised production prefixes. The test method is agreed to avoid creating an incident while trying to prove a safeguard.
We record baseline route counts and representative app paths, then observe changes after enforcement. A sudden loss of routes needs to be distinguished from an unrelated provider event. The rollback plan restores the previous acceptance policy while retaining evidence for investigation. It should not require an improvised reset of every BGP session.
Make authorisation maintenance part of change control
MCI’s handover identifies resource administrators, validator owners, router policy and escalation contacts. Prefix additions, AS changes and more-specific announcements become triggers for an RPKI review. Monitoring covers stale validation data and session loss. Discuss your current BGP routing setup with us to establish a rollout scope that improves origin assurance without hiding its limitations.
Talk to a specialist
Need a specialist view?
Tell us what is affected, what changed and what your team has already checked. A short outline is enough to start.
+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.