Connect. Secure. Manage.
DDoS Provider Integration
Coordinate Cisco network routing and operational procedures with a customer's DDoS protection provider, defining activation, escalation and recovery steps.
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.
DDoS provider integration prepares your network to use an agreed carrier or specialist mitigation service. We support the client-side Cisco routes, addresses and response process, working with the provider. The design depends on the traffic and protection method in scope. Neither a local firewall nor an upstream contract can guarantee that every attack will be stopped.
The whole path
Understand how sites, providers, cloud networks and security controls fit together.
Resilience that can be tested
Separate a second circuit from genuine end-to-end service resilience.
Provider coordination
Keep addressing, routing and escalation ownership clear across organisations.
Identify the services and attack surface in scope
We establish whether the need concerns internet bandwidth, public app endpoints, network infrastructure or a combination. Network-layer traffic floods and application-layer abuse may require different controls and providers. A service protecting a website through a proxy does not on its own cover every public address or non-web protocol used by the organisation.
The inventory identifies public prefixes, published services, DNS dependencies and the parties responsible for them. We also record the impact of losing a particular service so activation and escalation decisions can be prioritised. The provider's scope is compared with the actual exposure rather than inferred from a broad product label.
Standards & partnerships
Confidence in the team behind your network.
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
Verify the provider's integration method
The provider’s service may use route changes, tunnels, traffic diversion or an app-specific front end. We check its technical specification and the customer’s entitlement before designing the edge changes. The method must fit both. We do not assume that one approach works with every provider or every public address range.
The design records whether mitigation is always in the traffic path or activated under defined conditions. That distinction affects normal routing, testing, cost and incident response. The customer needs to know what happens before activation and during mitigation, including the conditions under which the service may not be able to protect a particular destination.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Coordinate routing and prefix authority
Where route diversion is involved, authorised prefix use and advertisement policy must be clear. We establish which party originates the route, what the customer advertises and how traffic returns from the mitigation service. Prefix filters and any relevant route-origin records are reviewed with the provider before production changes are made.
The return path can involve tunnels or other supported arrangements with capacity, MTU and reachability needs. We check those dependencies and identify any asymmetry affecting stateful devices. A diversion that removes unwanted traffic is not operationally complete if legitimate app responses then follow an unusable route.
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 ↗Preserve legitimate application traffic
The provider needs to understand the services it will protect. Protocols, normal traffic levels and important outside connections help it distinguish valid use from unwanted traffic. We prepare the network details it needs. Sensitive app and customer data is limited to what is needed for that work.
Application owners participate in acceptance tests because a network path can appear healthy while a service is incorrectly restricted. Changes to public source or destination behaviour may also affect external permissions and monitoring. The integration plan records those dependencies instead of assuming all apps behave like a simple public website.
Define activation and escalation responsibilities
The incident process identifies who can request mitigation, who authorises routing changes and which contacts remain available during a network access problem. Access to the provider portal or support channel must not depend solely on the affected network. We agree how the customer communicates internally while technical teams investigate.
Automatic activation, where provided, still needs service ownership. The team must understand alerts, thresholds and the process for reviewing false positives or unexpected diversion. A contract promising a capability is not the same as an organisation having tested the steps needed to use it effectively.
Exercise the integration safely
Tests are coordinated with the provider and limited to authorised methods. We do not generate uncontrolled attack traffic against production services as an informal validation exercise. Routing, tunnel and app checks can show important parts of the integration, while any provider-run simulation follows its agreed safety and permission needs.
The test record includes activation, operation and return to normal routing. Restoration can affect sessions and route preferences. So it deserves clear validation. The evidence also states what was not tested. A successful diversion test is not a claim that every possible attack volume or technique has been reproduced.
Maintain readiness as the edge changes
New prefixes, providers, apps and contact changes can invalidate an earlier integration. We connect those changes to the customer's review process and keep the technical and escalation records current. Periodic exercises help ensure the service remains usable rather than current only as an old procurement document.
MCI can support integration within a Cisco internet edge design or review a current arrangement with a mitigation provider. Our scope is defined client-side engineering and coordination; attack detection, scrubbing capacity and provider repair obligations remain with the contracted parties. Share the protected services and proposed provider specification so the duties and limitations can be made clear before an incident.
Technical references
- Cisco provider-network DDoS integration overview — Cisco / Cisco Meraki
- Cloudflare Magic Transit reference architecture — Cloudflare
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.