Connect. Secure. Manage.
Cisco IS-IS Services
Design or troubleshoot Cisco IS-IS routing for an agreed platform and scale, covering adjacency formation, topology structure and operational visibility.
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 IS-IS services cover the design and care of networks that use IS-IS to share routes. The work includes device roles, links between neighbours and how other routing protocols connect to it. We help you plan, install or troubleshoot a supported Cisco setup. Tests check what the network does during normal use and faults.
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.
Confirm the use case and supported platforms
We begin by identifying why IS-IS is used or proposed. It may form the underlay for a network fabric, support a routed backbone or reflect an established operational standard. We document the physical topology, expected prefixes, device roles and routing domains that connect to the IS-IS setup.
Platform and software support must be checked before choosing the design. Features such as particular address families, authentication methods or fast-convergence mechanisms may differ between Cisco operating systems and releases. We check the actual hardware and licensing rather than assuming all Cisco devices implement the same IS-IS capabilities.
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
Design the level hierarchy
IS-IS uses Level 1 and Level 2 routing, with devices operating in supported roles according to the topology. We assess whether a single Level 2 domain is enough or whether separate Level 1 areas offer a meaningful operational benefit. Introducing hierarchy without a need can make troubleshooting harder.
Area boundaries should correspond to clear routing and admin aims. We document how destinations outside an area are reached, where route leaking or summarisation may be appropriate and how the design responds when a boundary device fails. The aim is predictable reachability, not merely a tidy-looking diagram.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Plan addressing and system identifiers
IS-IS uses network entity titles and system identifiers that need a consistent allocation scheme. Poor identifier management can cause adjacency or operational problems, particularly during hardware replacement or site expansion. We set out a naming and addressing convention that engineers can maintain over time.
The IP addressing plan is a separate but related concern. We document the interface networks, loopbacks and the prefixes carried in the relevant address families. For fabric underlays, loopback reachability may be essential to overlay control-plane functions. So it needs clear verification rather than a generic routing test.
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 ↗Establish and protect adjacencies
Neighbour formation depends on compatible setup and the underlying link state. We review expected adjacency types, relevant timers, authentication, interface MTU considerations and the permitted interfaces. Control-plane traffic should be accepted only where a routing relationship is intended.
An unexpected neighbour reset can be caused by a physical fault, parameter mismatch or device resource pressure. We use protocol state, logs and interface evidence to identify the cause. Increasing timers or disabling authentication as a quick workaround can obscure the problem and weaken the intended design.
Control route propagation and path selection
We assess metrics, equal-cost paths and any route-policy boundaries that influence forwarding. The lowest metric path may not always align with business needs, particularly when circuits have different capacity or service characteristics. The design should explain how traffic is expected to use primary and backup paths.
Where IS-IS exchanges routes with BGP, OSPF or static domains, redistribution needs clear filtering and ownership. We avoid uncontrolled import of internal or external prefixes. Default-route handling is particularly sensitive because a mistaken advertisement can affect a large part of the network.
Test convergence and resilience
Link-state protocols can respond quickly to changes, but actual recovery includes failure detection, topology processing, route installation and forwarding updates. We review whether the supported platform can meet the required convergence aims and whether extra mechanisms are justified.
Acceptance testing should include representative path failures, neighbour loss and restoration where safe. We compare observed routing state with app reachability, especially for services sensitive to short interruptions. We document which scenarios were tested and which rely on vendor-supported behaviour rather than direct production evidence.
Troubleshoot with a topology-first approach
When routes disappear or traffic takes an unexpected path, we compare the link-state database, neighbour state and forwarding information with the intended topology. We check the relevant level, area and address family rather than treating every missing prefix as the same kind of incident.
We also review recent changes, including interface setup, software upgrades and route policy. A controlled investigation should isolate one hypothesis at a time. Broad protocol restarts are rarely an appropriate first response on a network carrying critical traffic.
Maintain an understandable IS-IS estate
A supportable rollout needs diagrams, identifier allocations, adjacency maps, route-policy records and monitoring for unexpected topology changes. Engineers should know which team owns the underlay, which team owns any overlay and how incidents cross that boundary.
MCI delivers Cisco and Meraki network services across the UK, with particular focus on London, Kent, Sussex, Essex and Berkshire. We can review a current IS-IS backbone, prepare a new supported design or investigate persistent routing instability with a clear evidence trail.
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.