IS-IS in Service Provider Networks: Design and Operations Guide

IS-IS in Service Provider Networks is still one of the most reliable choices for carrying loopbacks, infrastructure links, MPLS reachability, and Segment Routing information across large backbones. It is quiet, scalable, and protocol-flexible, but it also has a few operational details that can surprise engineers who mostly learned OSPF first.

This guide focuses on practical IS-IS design and operations for provider-style networks: levels, addressing, metrics, authentication, Segment Routing, and the troubleshooting checks that quickly separate a simple adjacency issue from a real control-plane problem.

Why Service Providers Still Use IS-IS

IS-IS was not originally built as an IP-only routing protocol. It runs directly over Layer 2 using CLNS PDUs instead of IP packets, and it carries reachability information through TLVs. That design is one reason operators like it: new capabilities can often be added as new TLVs without changing the base protocol behavior.

In a Service Provider backbone, IS-IS is commonly used as the interior gateway protocol for:

• Router loopback reachability for BGP, LDP, RSVP-TE, or Segment Routing.
• Infrastructure link prefixes used for management and troubleshooting.
• MPLS Traffic Engineering attributes such as link bandwidth and administrative groups.
• Segment Routing Prefix-SIDs and Adjacency-SIDs.
• IPv4 and IPv6 reachability in a single protocol instance.

The operational goal is simple: keep the IGP stable, fast enough to converge, and small enough that a failure in one part of the backbone does not create unnecessary churn everywhere else.

Core Design: Level-1, Level-2, or Both?

IS-IS has two hierarchy levels. Level-1 is similar to an intra-area routing domain, while Level-2 is the backbone between areas. A router can run L1, L2, or L1/L2. Many modern provider networks choose a single Level-2 domain for the core because it is simple and avoids route leaking complexity. That works well when the topology is not excessively large and the control-plane can handle the link-state database.

A hierarchical design becomes useful when the network has many aggregation regions, metro domains, or operational boundaries. A common model is:

• L2-only core routers: P routers and route reflectors in the backbone.
• L1/L2 border routers: PE or aggregation routers connecting regional L1 domains to the core.
• L1-only access or metro routers: devices that should not need the full backbone database.

The trade-off is visibility. A flat L2 design gives every router the same topology view. A hierarchical design reduces the database size but requires careful route leaking and default route behavior. In Service Provider operations, simplicity often wins unless scale forces hierarchy.

NET Addressing and System IDs

Every IS-IS router needs a Network Entity Title, usually called the NET. The most operationally important part is the six-byte System ID. Many providers derive it from the router loopback address because it is easy to read during troubleshooting. For example, loopback 10.0.12.34 may become System ID 0100.0012.0034.

Example NET format:
49.0001.0100.0012.0034.00

49.0001  = private area ID
0100.0012.0034 = system ID derived from loopback
00       = NSEL

Keep NET addressing boring. Use a documented area scheme, avoid duplicate System IDs, and make sure the value is stable for the lifetime of the router. A duplicate System ID is one of the fastest ways to create confusing SPF behavior and intermittent reachability.

Metric Strategy: Keep It Predictable

IS-IS wide metrics are the normal choice today. They allow a much larger metric range than old-style narrow metrics and are required for many modern traffic engineering designs. The metric strategy should reflect the physical topology and operational intent.

A practical approach is to set lower metrics on high-capacity, low-latency backbone links and higher metrics on backup, satellite, or long-haul paths. Avoid making every interface metric 10 in a real provider network unless equal-cost forwarding everywhere is actually intended.

Example metric policy:

• 400G core links: metric 10
• 100G regional links: metric 20
• 10G backup links: metric 100
• Out-of-region disaster path: metric 500 or higher

Document this policy. During an outage, the difference between a deliberate backup path and an accidental hot potato path should be obvious from the metrics.

IS-IS and Segment Routing

Segment Routing has made IS-IS even more relevant in many backbones. With SR-MPLS, IS-IS advertises Segment Routing capabilities and Prefix-SIDs for loopbacks. The IGP becomes the distribution mechanism for the labels that represent shortest-path forwarding to each node.

A small operational checklist for IS-IS with Segment Routing:

• Enable wide metrics before deploying SR.
• Use stable loopbacks for Prefix-SIDs.
• Keep the SRGB consistent unless the vendor design intentionally supports variation.
• Protect the IGP with authentication before it carries label-signaling information.
• Monitor SID conflicts and missing Prefix-SID advertisements.

If a router has normal IP reachability but SR traffic fails, check whether the Prefix-SID is advertised, whether the receiving router installed the label, and whether PHP or explicit-null behavior matches the service design.

Security and Stability Basics

Because IS-IS runs directly over Layer 2, it is not exposed in the same way as a TCP-based control-plane protocol. That does not mean it should be left unprotected. Provider networks should use authentication on core-facing adjacencies and keep IS-IS disabled on interfaces where it is not required.

Useful stability practices include:

• Use point-to-point network type on point-to-point links.
• Enable BFD only where faster failure detection is needed and tested.
• Apply LSP generation and SPF timers that converge quickly without reacting to every micro-flap.
• Limit passive interfaces to loopbacks and management-only prefixes.
• Alert on adjacency flaps, LSP database overload, and authentication failures.

The best IS-IS network is almost boring: adjacencies stay up for months, LSP changes are explainable, and metric changes happen through controlled maintenance.

Troubleshooting Common IS-IS Problems

When IS-IS breaks, start with the adjacency. A missing route is often only a symptom of a neighbor that never reached the correct state.

1. Adjacency does not come up

• Check that both sides run IS-IS on the interface.
• Verify matching Level-1 or Level-2 capability.
• Confirm MTU compatibility; padded hellos can expose mismatches.
• Check authentication key, key chain, and algorithm.
• Verify point-to-point versus broadcast behavior.

2. Neighbor is up, but routes are missing

• Inspect the link-state database for the missing prefix TLV.
• Check route leaking policy between L1 and L2.
• Confirm the interface or loopback is not passive in the wrong way.
• Look for overload bit, maximum-prefix behavior, or administrative filtering.

3. Traffic takes the wrong path

• Compare IS-IS metrics in both directions.
• Check ECMP width and platform limits.
• Verify whether MPLS, SR policy, or BGP next-hop resolution changes the forwarding path.
• Use traceroute, MPLS traceroute, or vendor-specific forwarding-table checks instead of relying only on the RIB.

A useful rule: troubleshoot the control-plane database first, then the routing table, then the forwarding table. Skipping directly to packet captures often wastes time unless you already know the adjacency is failing.

Short Lab Idea

Build a four-router lab with two core routers and two PE routers. Run IS-IS Level-2 only, advertise loopbacks, and enable MPLS or Segment Routing if your platform supports it. Then practice three failures:

1. Change the IS-IS metric on one core link and observe SPF and traffic path changes.
2. Break authentication on one side and identify the log messages and neighbor state.
3. Advertise a Prefix-SID on one PE and confirm that the remote PE installs the expected label.

This small topology is enough to practice the operational workflow used in much larger provider networks.

Summary

IS-IS is not popular in Service Provider networks by accident. It scales well, supports IPv4 and IPv6 cleanly, carries traffic engineering and Segment Routing information, and gives operators a stable link-state foundation for BGP and MPLS services. The key is disciplined design: predictable hierarchy, stable System IDs, documented metrics, authentication, and monitoring that catches database or adjacency changes before customers notice.

Related reading

• Start Here: Networking Topics
• Routing articles on Network freak
• Service Provider networking articles
• BGP Communities: The Small Routing Tag That Powers Large Service Provider Networks

EVPN VXLAN Troubleshooting: Common Problems and Fixes

EVPN VXLAN troubleshooting is easier when you stop treating the fabric as one mysterious overlay and start checking it in layers: underlay reachability, BGP EVPN control plane, VXLAN data plane, and tenant routing. Most outages in a data center fabric are not caused by an exotic protocol bug. They are usually caused by a missing route, a mismatched VNI, an anycast gateway inconsistency, an MTU problem, or a route target that does not match the intended tenant.

This guide gives a practical workflow for network engineers operating EVPN/VXLAN fabrics. The commands differ between Cisco, Juniper, Arista, Nokia, FRRouting, and SONiC, but the logic is portable. If you can prove each layer independently, you can isolate most problems quickly without guessing.

1. Start with a Simple Mental Model

In a typical EVPN/VXLAN design, leaf switches act as VTEPs. The underlay provides IP reachability between VTEP loopbacks, usually with OSPF, IS-IS, or eBGP. The overlay uses BGP EVPN to advertise MAC addresses, IP addresses, prefixes, Ethernet segments, and VTEP next hops. VXLAN encapsulates tenant traffic between VTEPs using a VNI.

When something breaks, map the symptom to the layer:

• No VTEP reachability: suspect the underlay, loopback advertisement, ECMP, MTU, or ACL/filtering.
• MAC or ARP entries missing: suspect BGP EVPN route exchange, route targets, VLAN-to-VNI mapping, or host attachment.
• Same subnet works locally but not remotely: suspect Layer 2 VNI, type-2 routes, VXLAN UDP reachability, or MTU.
• Inter-subnet routing fails: suspect Layer 3 VNI, anycast gateway, VRF route targets, or symmetric IRB configuration.

2. Verify the Underlay Before Looking at EVPN

EVPN cannot repair a broken underlay. Before checking MAC routes or VNIs, prove that every VTEP loopback can reach every other VTEP loopback with the expected source address. This matters because VXLAN packets are sourced from the local VTEP IP and destined to the remote VTEP IP.

# Generic checks to adapt to your NOS
ping <remote-vtep-loopback> source <local-vtep-loopback>
traceroute <remote-vtep-loopback> source <local-vtep-loopback>
show ip route <remote-vtep-loopback>
show isis route / show ospf route / show bgp ipv4 unicast

Look for asymmetric reachability, unexpected next hops, missing loopbacks, or a single failed spine path causing ECMP imbalance. If your fabric uses jumbo frames, test with a payload that represents VXLAN overhead. A classic Ethernet frame plus VXLAN, UDP, IP, and outer Ethernet headers needs additional headroom. If the underlay MTU is too small, small pings may pass while real tenant traffic is dropped or fragmented.

3. Check BGP EVPN Adjacencies and Address Families

Once the underlay is stable, confirm that BGP EVPN sessions are established and that the EVPN address family is active. In many fabrics, IPv4 unicast BGP can be up while EVPN is not activated for a neighbor. That creates a deceptive state: the underlay looks healthy, but no MAC/IP routes are exchanged.

show bgp l2vpn evpn summary
show bgp evpn summary
show bgp neighbors <peer> advertised-routes
show bgp neighbors <peer> received-routes

Focus on three details: session state, route count, and next-hop handling. EVPN routes should carry a VTEP next hop that other leaf switches can resolve through the underlay. If route reflectors are used, make sure they preserve the next hop as required by the design and that clients are exchanging the correct EVPN address family.

4. Understand EVPN Route Types During Troubleshooting

You do not need to memorize every EVPN route type to troubleshoot effectively, but you should recognize the routes tied to common symptoms:

• Type 2: MAC/IP advertisement. Used for endpoint learning and ARP/ND suppression.
• Type 3: Inclusive multicast Ethernet tag route. Used for BUM traffic discovery in many designs.
• Type 5: IP prefix route. Used for advertising routed prefixes between VRFs in EVPN fabrics.

If a remote host is unreachable in the same subnet, search for its MAC and IP in the EVPN table. If the route is absent everywhere, the local leaf may not be learning the endpoint or advertising the VNI. If the route is present on the advertising leaf but absent on the receiving leaf, suspect route targets, import policy, route reflection, or EVPN address-family configuration.

5. Validate VLAN, VNI, and Route Target Mapping

One of the most common EVPN/VXLAN failures is a simple mapping error. A VLAN may be mapped to VNI 10100 on one leaf and VNI 10010 on another. A VRF may import the wrong route target. A tenant may have the correct Layer 2 VNI but the wrong Layer 3 VNI. These issues often look like random host reachability problems because local switching continues to work.

Build a small source-of-truth table for each tenant:

• Tenant or VRF name
• VLAN ID and subnet
• Layer 2 VNI
• Layer 3 VNI
• Route distinguisher and route targets
• Anycast gateway IP and MAC

Then compare the live device configuration against that table. This is where automation helps: even a short Python script or Ansible playbook that audits VLAN-to-VNI consistency can catch outages before users do.

6. Troubleshoot Anycast Gateway and IRB Problems

In modern EVPN/VXLAN fabrics, hosts often use an anycast gateway configured identically on every leaf. The gateway IP and virtual MAC must be consistent. If one leaf uses a different virtual MAC, endpoints may ARP successfully but traffic can fail after moving between racks. If one leaf misses the SVI or IRB interface, local hosts may have no default gateway even though remote EVPN routes are present.

For symmetric IRB designs, verify both the Layer 2 VNI and the Layer 3 VNI. The ingress leaf routes traffic from the source VLAN into the tenant VRF, sends it across the fabric with the L3 VNI, and the egress leaf routes it toward the destination VLAN. A missing L3 VNI or VRF route target can break inter-subnet traffic while same-subnet bridging still works.

7. Data Plane Checks: VXLAN UDP and MTU

BGP EVPN can look perfect while encapsulated packets are being dropped. VXLAN normally uses UDP port 4789. Check whether firewalls, underlay ACLs, CoPP policies, or fabric security filters permit VTEP-to-VTEP VXLAN traffic. In a tightly controlled data center, an underlay filter that permits BGP and ICMP but blocks UDP 4789 will produce exactly this failure pattern: control plane up, data plane down.

MTU is the second frequent data plane issue. Use a large ping with the do-not-fragment bit where supported, sourced from the VTEP loopback or routed interface used for encapsulation. Also inspect interface counters for drops, giants, MTU errors, and discards. A single undersized link in an ECMP path can create intermittent application issues that are hard to reproduce.

8. A Practical Troubleshooting Sequence

1. Identify one failing source, destination, VLAN, VRF, and leaf pair.
2. Verify local host learning on the ingress leaf: MAC table, ARP/ND table, and interface state.
3. Confirm the local VLAN-to-VNI and VRF-to-L3-VNI mapping.
4. Check whether the destination MAC/IP or prefix exists in the EVPN table.
5. Verify that the EVPN next hop is the expected remote VTEP and is reachable in the underlay.
6. Test VXLAN data plane reachability and MTU between VTEPs.
7. Review route targets and import/export policies for the tenant VRF.
8. Check counters on access, fabric-facing, and loopback-related paths.

This sequence prevents a common mistake: jumping straight into BGP policy while the real issue is a disconnected server port, or chasing interface counters while the remote MAC route was never imported.

Lab Practice Idea

Build a three-leaf, two-spine EVPN/VXLAN lab in containerlab, EVE-NG, CML, or your preferred virtual NOS environment. Create two tenants, two Layer 2 VNIs, and one Layer 3 VNI. After the baseline works, intentionally break one thing at a time: change a VNI on one leaf, remove a route target import, lower the MTU on one underlay link, and disable EVPN activation for one neighbor. For each fault, write down the symptom, the command that exposed it, and the fix.

Summary

Good EVPN VXLAN troubleshooting is a layered process. Prove the underlay first, then validate BGP EVPN route exchange, then inspect VLAN/VNI/VRF mappings, and finally test the VXLAN data plane. Most incidents become much smaller when you reduce them to one failing endpoint pair and one tenant. The goal is not to run every command on every switch; the goal is to prove where the packet stops being forwarded correctly.

Related reading

• Start Here: Networking Topics
• Data Center articles
• Routing articles
• Network Security articles

BGP Communities: The Small Routing Tag That Powers Large Service Provider Networks

When people learn BGP, they usually focus on prefixes, AS_PATH, Local Preference, MED, route-maps, and filtering. These are all important topics, but there is one BGP feature that often looks simple at first and later turns out to be one of the most powerful tools in real-world networks.

That feature is BGP Communities.

BGP Communities are used heavily in Service Provider networks, Internet exchanges, large enterprise WANs, Data Center fabrics, MPLS VPN environments, and DDoS mitigation systems. They allow network engineers to attach additional information to BGP routes and then use that information to make routing decisions.

In simple words: a BGP Community is a tag attached to a route. But in production networks, that small tag can control traffic engineering, route propagation, blackholing, customer policies, and inter-domain routing behavior.

What Is a BGP Community?

A BGP Community is an optional transitive BGP attribute. It allows a router to mark a route with one or more values. Other routers can then match those values and apply routing policy.

The classic format looks like this:

ASN:VALUE

For example:

64500:100
64500:200
64500:300
64500:666

The first part usually represents the Autonomous System Number, and the second part represents a specific policy defined by that network.

For example, a Service Provider could define the following policy:

64500:100  - advertise to all upstreams
64500:200  - advertise only to customers
64500:300  - prepend AS_PATH three times
64500:666  - blackhole this prefix

The important thing to understand is that most communities do not have a universal meaning. Their meaning depends on the network that defines and processes them.

Why Are BGP Communities Useful?

In a small lab, it may be easy to configure routing policy manually on every router. In a real Service Provider network, that approach does not scale.

Imagine a provider with hundreds of routers, multiple upstream providers, Internet Exchange connections, enterprise customers, MPLS VPN customers, DDoS protection services, and different routing policies per region.

Without communities, every routing change would require manual changes in many places. With communities, the workflow becomes much cleaner:

1. A route is received from a customer or another router.
2. The route carries a specific community.
3. The provider edge router matches that community.
4. A route policy automatically performs the correct action.

This allows the network to become more programmable and policy-driven.

Example: BGP Blackholing for DDoS Mitigation

One of the most common real-world uses of BGP Communities is Remote Triggered Black Hole, often called RTBH.

Let’s say a customer is under a DDoS attack targeting a single IP address. Instead of allowing the attack traffic to saturate the customer’s link, the customer can announce a more specific route, usually a /32 for IPv4, with a special blackhole community.

Prefix: 203.0.113.55/32
Community: 64500:666

The Service Provider has a routing policy that says:

If a route has community 64500:666,
set next-hop to discard/null,
and propagate it to edge routers.

The result is that traffic to the attacked IP address is dropped inside the provider network, closer to the edge, before it reaches the customer circuit.

This is not a perfect solution because the attacked IP becomes unreachable, but it can protect the rest of the customer’s network and services. In many DDoS situations, sacrificing one IP address is better than losing the entire connection.

Well-Known BGP Communities

Some BGP Communities have standard meanings. These are called well-known communities.

The most common ones are:

no-export

A route with this community should not be advertised outside the local AS or confederation.

no-advertise

A route with this community should not be advertised to any BGP neighbor.

local-AS

A route with this community should not be advertised outside the local AS in confederation scenarios.

Standard Communities vs Extended Communities vs Large Communities

Standard Communities

Standard communities use a 32-bit value and are commonly written as:

ASN:VALUE

They are simple and widely supported, but they have limitations, especially when working with 32-bit ASNs.

Extended Communities

Extended Communities provide more space and structure. They are heavily used in MPLS VPNs and EVPN.

Common use cases include Route Targets, Route Origin, MPLS Layer 3 VPN import/export policy, EVPN tenant separation, and VPN route control.

route-target:64500:100

In MPLS L3VPN and EVPN networks, Route Targets are used to decide which VRFs should import specific routes.

Large Communities

Large Communities were introduced to solve limitations of standard communities, especially for networks using 32-bit ASNs.

GLOBAL_ADMIN:LOCAL_DATA_1:LOCAL_DATA_2

Example:

64500:10:200

Large Communities are easier to document and scale in modern networks.

Example Service Provider Policy

Let’s imagine a Service Provider with AS64500. The provider wants to let customers influence how their prefixes are advertised.

64500:100 - advertise to all upstreams and peers
64500:110 - do not advertise to upstream A
64500:120 - do not advertise to upstream B
64500:200 - advertise only to local peers
64500:300 - prepend three times to upstream A
64500:666 - blackhole

Now the customer can control routing behavior by attaching the correct community.

Prefix: 198.51.100.0/24
Community: 64500:300

When the provider advertises this route to upstream A, it applies AS_PATH prepending:

AS_PATH: 64500 64500 64500

This makes the route less preferred through that upstream. The customer does not need to open a ticket or ask the provider to manually change routing policy. The policy is already automated.

Cisco IOS-Like Configuration Example

ip community-list standard BLACKHOLE permit 64500:666

route-map CUSTOMER-IN permit 10
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
 set community no-export additive

route-map CUSTOMER-IN permit 20
 set local-preference 100

Then the route-map is applied to a BGP neighbor:

router bgp 64500
 neighbor 198.51.100.2 remote-as 64510
 neighbor 198.51.100.2 route-map CUSTOMER-IN in
 neighbor 198.51.100.2 send-community

The line below is extremely important:

send-community

Without it, the router may not send community attributes to the BGP neighbor. This is one of the most common troubleshooting mistakes with BGP Communities.

Common Troubleshooting Issues

1. Missing send-community

A router sets a community locally, but the neighbor never receives it because send-community is missing. Always verify received routes on the neighbor.

2. Replacing Communities Instead of Adding Them

Some platforms replace existing communities unless you explicitly tell them to add a new one.

set community 64500:100 additive

Without additive, you may accidentally remove communities that were already attached to the route.

3. No Community Documentation

A community without documentation is just a magic number. Good providers usually maintain a public or internal table explaining every community value.

4. Vendor Syntax Differences

The concept of BGP Communities is standard, but the configuration syntax differs between vendors. Cisco, Juniper, Arista, Nokia, Huawei, and FRRouting all support communities, but the route policy syntax can look very different.

Why BGP Communities Matter in Data Center Networks

BGP Communities are not only useful in Service Provider networks. They are also important in modern Data Center designs.

Many Data Centers use BGP as the main control-plane protocol, especially in leaf-spine architectures and EVPN VXLAN fabrics.

In Data Centers, communities can help with tenant separation, VRF import/export policy, route leaking, firewall service insertion, EVPN route control, traffic engineering, automation, and operational visibility.

Extended Communities are especially important in EVPN because Route Targets define which VRFs import specific EVPN routes.

Best Practices

1. Document every community. If nobody knows what a community means, it becomes technical debt.
2. Use a consistent numbering scheme. For example: 100–199 for export control, 200–299 for local preference, 300–399 for AS_PATH prepending, and 666 for blackholing.
3. Always check send-community. If communities are not propagated, your policy will not work.
4. Use additive when needed. Avoid accidentally overwriting existing communities.
5. Test policies in a lab. Tools like FRRouting, containerlab, EVE-NG, or Cisco CML are great for learning.
6. Keep customer-facing community guides simple. If customers are expected to use communities, the documentation must be clear.

Lab Idea

You can build a simple BGP lab with three routers:

R1 - Customer
R2 - Service Provider
R3 - Upstream

Goal:

1. R1 advertises a prefix to R2.
2. R1 attaches community 64500:300.
3. R2 matches the community.
4. R2 prepends AS_PATH when advertising the route to R3.
5. R3 receives the route with a longer AS_PATH.

Then extend the lab: add blackhole community 64500:666, verify communities with show bgp, remove send-community and observe what breaks, and test standard vs large communities.

Summary

BGP Communities are simple in concept but extremely powerful in practice.

They allow network engineers to tag routes and build flexible routing policies. In Service Provider networks, they are used for traffic engineering, blackholing, route filtering, customer policy control, and upstream selection. In Data Center networks, they are important for EVPN, VRFs, tenant separation, and route control.

If you work with BGP, you should understand communities well.

A small tag attached to a route can completely change how traffic flows across a network.

Data Center Trends: Automation, AI-ready Infrastructure and ACI

Data Center Trends – Automation, AI-ready Infrastructure and ACI

Digital transformation and generative AI have triggered a revolution in data centers. Below I summarize the most important trends from the last 12‑18 months.

AI‑ready infrastructure and new switches

– In February 2025 Cisco unveiled new 9300 switches with built‑in Data Processing Units (DPUs). These provide 800 Gbps throughput and 128 GB memory and can run security services such as Layer†4 stateful firewalling, NAT, IPSec, telemetry and DDoS protection directly on the switch. This architecture reduces latency and simplifies network design because security functions are moved into the network infrastructure.

– Solutions for intensive AI workloads are becoming more flexible. Drut, a software company, released in 2024 the DX3.0 system, which creates virtual "vPODs" made of CPU, GPU and memory slices from multiple servers. This allows dynamic allocation of expensive GPU resources and increases utilization — even 6 of 8 GPU cards in a single server can be assigned to other tasks. It’s an example of how data centers are becoming more modular and AI‑ready.

State of network automation and orchestration

 

 

 

 

 

 

– The NetBox Labs report (based on EMA research) from April 2024 shows that only 27 % of network teams report full success in managing complex infrastructure. 80 % of successful automation projects were fully funded, whereas only 57 % of partially successful projects enjoyed full funding. At the same time, 76 % of organizations expect their network automation budgets to grow within the next two years. This underscores growing interest in automation. 

 

 

 

 

 

 

 

 

 

– Results from the "State of Network Automation Survey 2024" (Packet Pushers) show that among 106 respondents, 58 have automated up to 50 % of their networks while 48 have automated more than 50 %. The most commonly automated tasks include backups, device deployment, firmware upgrades, service provisioning and firewall rules. However, 81 % of respondents rely on their own scripts rather than commercial tools.

Orchestration with ACI

 

– Cisco’s Application Centric Infrastructure (ACI) combines network automation, policy orchestration and monitoring in a single ecosystem. According to Techniche data from 2023, ACI already has more than 6 000 production customers. Cisco has numerous case studies across industries and continues to expand ACI with multi‑cloud support – for example, Amazon Web Services and Microsoft Azure.

– Growing interest in automation suggests that more enterprises are considering migration to ACI and similar platforms. Although there are no official statistics, the NetBox Labs report indicates that 76 % of organizations want to increase their automation budgets and that fully funded projects dramatically increase the chance of success. These figures suggest that many companies plan to adopt centralized solutions like ACI.

Summary

New technologies — such as switches with DPUs and virtual compute pools — are designed to handle rising AI workloads. At the same time, the challenges of managing networks are pushing companies toward automation and platforms like ACI. More than six thousand organizations have already implemented ACI, and rising automation budgets indicate that this number is likely to increase. In the coming years, success in automation will depend on well‑funded projects and the adoption of proven orchestration platforms.

Weekly Networking News: Cisco, Juniper & Nokia (Aug 3, 2025)

This week’s networking news round‑up explores how the industry’s biggest vendors are pushing the boundaries of AI‑ready networks, data centre fabrics and service provider solutions.

Cisco – AI‑ready networks and data centres

At Cisco Live 2025, Cisco’s leadership highlighted a bold pivot: the company is positioning itself as an AI‑driven firm with networking at its core. The focus is on building AI‑ready networks that can support the massive data flows generated by training and inference workloads. Cisco announced new high‑capacity switches based on its Silicon One chips, an AI Canvas to accelerate AI development, and integrated security and observability tools such as Hypershield. This shift from simply delivering network hardware to providing a unified platform underscores how important data centre networking has become in the age of agentic AI.

 

 

Juniper – AI‑nati vedata centre and routing

Juniper’s AI‑Native Networking Platform, now part of HPE, integrates Mist AI, the Marvis virtual assistant and Apstra automation to simplify operations across campus, data centre and WAN. Juniper says its AI data centre solution provides a quick way to deploy high‑performance AI training and inference networks while remaining flexible and easy to manage. On the WAN side, the company’s AI‑native routing family delivers robust 400 GbE and 800 GbE capabilities for high performance, reliability and sustainability. This combination of automation and high‑speed hardware earned Juniper recognition as a leader in the 2025 Magic Quadrant for enterprise wired and wireless LAN infrastructure.

Nokia – Visionary in data centre switching

Nokia was named a Visionary in the 2025 Gartner Magic Quadrant for data centre switching. The company’s portfolio includes the 7220 and 7250 IXR platforms, SR Linux operating system and Event‑Driven Automation framework, with options to run community SONiC software. These switches support 400 GbE and 800 GbE speeds and emphasise automation and reliability, reflecting Nokia’s vision for AI‑native data centres and service provider networks. The recognition underscores both the completeness of Nokia’s vision and its ability to execute in the data centre market.

Summary

Across the board, networking vendors are rapidly adapting to AI’s demands. Cisco is refocusing its strategy around AI‑ready data centre networks; Juniper, under HPE, is promoting AI‑native platforms that combine high‑speed hardware with automation; and Nokia is expanding its vision with next‑generation switching fabrics. We’ll continue monitoring these developments every Monday, Wednesday and Friday to keep you informed of the latest trends.

OSPF Neighbor States: Step‑by‑Step

Understanding OSPF Neighbor States and Adjacency Formation

Open Shortest Path First (OSPF) is a link-state IGP (Interior Gateway Protocol) designed for efficient, scalable, and fast convergence in enterprise and service provider networks. Before routers can exchange routing information, they must become neighbors and go through a well-defined finite-state machine to synchronize their Link-State Databases (LSDBs). A deep understanding of each OSPF neighbor state and the LSA exchange process is critical for troubleshooting and optimizing OSPF behavior in complex topologies.

 

OSPF Neighbor State

OSPF adjacency formation progresses through a series of states, each representing a specific phase in the neighbor relationship:

1. Down 

• This is the initial state.

• No Hello packets have been received from the neighbor.

• The router may still be sending Hello packets.

2. Attempt (only for NBMA networks)

• The router actively sends unicast Hello packets to a configured neighbor.

• No Hello has been received yet from that neighbor.

3. Init 

• A Hello packet has been received from the neighbor.

• However, the router's own Router ID is not yet seen in the neighbor's Hello packet.

• Communication is unidirectional.

4. 2-Way 

• Bi-directional communication is established.

• The router sees its own Router ID in the neighbor's Hello packet.

• DR and BDR election occurs on broadcast and NBMA networks.

• On point-to-point networks, routers may move directly to the next state.

5. ExStart 

• Routers negotiate master-slave roles.

• They select initial sequence numbers for Database Description (DBD) packets.

• This phase prevents simultaneous DBD packet exchange and ensures order.

6. Exchange 

• Routers exchange DBD packets summarizing their LSAs.

• Each LSA summary includes type, ID, advertising router, and sequence number.

• Routers build a list of LSAs they need from their neighbor.

7. Loading 

• The router sends Link State Request (LSR) packets for missing or outdated LSAs.

• The neighbor responds with Link State Update (LSU) packets containing the full LSA.

• Routers install received LSAs in the LSDB.

8. Full 

• LSDBs are fully synchronized.

• The routers are fully adjacent.

• On broadcast and NBMA networks, only DR and BDR form Full adjacencies with other routers

---

AI‑Native Networking: How Juniper’s HPE Acquisition and Cisco Live 2025 Signal a New Era for Data Centers

 The networking industry is at an inflection point, where artificial intelligence workloads and the demands of modern data centers are forcing vendors to rethink their architectures. In July 2025, Hewlett Packard Enterprise completed its US$14 billion acquisition of Juniper Networks, creating a combined HPE Networking business that doubles HPE’s networking revenue and positions it as a direct competitor to Cisco. A month earlier, Cisco used its Cisco Live 2025 conference to unveil an AI‑first vision for networking.

## HPE–Juniper: building an AI‑native competitor to Cisco

HPE’s acquisition brings Juniper’s data‑center and service‑provider expertise — think EVPN‑VXLAN fabrics, high‑performance routing and Mist AI — under the same roof as HPE’s Aruba campus networking and GreenLake cloud platform. Juniper’s former CEO, Rami Rahim, now leads the combined organization. The integration aims to give customers a unified network architecture spanning enterprise, data center and service‑provider segments, with consistent management across on‑premises and cloud deployments. For network architects, this promises simplified hybrid‑cloud implementations and new competition to Cisco’s dominant market position.

## Cisco Live 2025: agentic AI and AI‑ready networks

At Cisco Live 2025, Cisco’s president and chief product officer Jeetu Patel announced a cascade of AI‑driven solutions designed to modernize infrastructure and revolutionize IT operations. Key highlights include:

• AgenticOps and the Deep Network Model – a domain‑specific large language model trained on decades of Cisco expertise that diagnoses network issues and troubleshoots automatically.

• AI Canvas and Intelligent Workspace – a generative AI interface for NetOps, SecOps and DevOps teams, scheduled for general availability in October 2025.

• Secure and scalable AI‑ready networks – a unified management platform for Catalyst, Meraki and industrial devices; ThousandEyes assurance integrated with Splunk monitoring; and a quantum‑resistant security model.

• Hardware refresh – routers offering up to three times the throughput of prior models and Catalyst switches delivering up to 1.6 terabits per second of stacked bandwidth.

Cisco is also partnering with OpenAI to develop compute clusters tailored for large language models. The message is clear: AI will be deeply embedded in network operations, and networks must be designed to support AI workloads.

## Why AI needs data‑center networking innovation

Training large language models requires moving terabytes of data between hundreds of GPUs, creating east–west traffic patterns that overwhelm legacy data‑center networks. Modern fabrics use technologies such as EVPN‑VXLAN, segment routing and RDMA over Converged Ethernet to deliver high bandwidth and low latency. Both HPE‑Juniper and Cisco are investing heavily to ensure their platforms meet these requirements. For network engineers, this convergence of AI and networking marks a new chapter: understanding protocols like EVPN, segment routing and BGP EVPN will be essential for designing AI‑ready data centers.

## Conclusion

The convergence of networking and AI is transforming how data centers are built and operated. HPE’s integration of Juniper brings Mist AI and EVPN fabrics into a larger portfolio, while Cisco’s agentic AI and AI‑ready architecture offer a unified platform and refreshed hardware. Staying ahead means keeping pace with these developments and mastering the underlying technologies. Stay tuned for upcoming posts where we’ll dive deeper into protocols like OSPF, IS‑IS and segment routing — and explore how they support the AI‑native networks of tomorrow.

 Lately I've been spending a lot of time on projects related to migrating traditional MPLS (based on LDP) to a new solution based on MPLS Segment Routing. Migrations can be challenging and very interesting, so I’ll try to illustrate, using the example of several clients – of course, the data will be anonymized – what the migration process looks like and what its main advantages are. I'm returning to running this blog because it gives me the motivation for further activities and learning. I hope there will be readers for what I share here and that it will be useful to someone.

Reflecting on the value of CCIE and how it opened opportunities

 

Just wanted to come back to write this blog. I have been a CCIE for a few years now and wanted to share with you how many doors and opportunities it has opened for me. I am currently trying to motivate myself to study for the CCDE and focus on the world of AI, which is increasingly fascinating to me.

First, I asked AI for its current opinion on CCIE and CCDE. It seems that it's still worth going on this journey and focusing on learning.

That's why I will be posting various summaries from the world of Networking and AI here.

 

The CCIE (Cisco Certified Internetwork Expert) and CCDE (Cisco Certified Design Expert) certifications are among the most prestigious credentials in the IT industry, offering a wide range of technical and career opportunities. Here’s a deeper look at what they bring to the table:

CCIE (Cisco Certified Internetwork Expert):

1. Advanced Technical Expertise:

   • The CCIE certification validates your ability to design, implement, and troubleshoot complex network infrastructures.

   • It covers advanced topics such as routing and switching (CCIE Enterprise), data center technologies, security, service provider, and wireless networks.

   • You’ll gain hands-on experience with cutting-edge Cisco technologies, including SD-WAN, automation, and network programmability.

2. Career Growth:

   • Opens doors to high-level roles such as Senior Network Engineer, Network Architect, or Technical Consultant.

   • Employers value CCIE-certified professionals for their ability to solve complex network challenges and optimize performance.

3. Global Recognition:

   • CCIE is globally recognized as a gold standard in networking expertise, giving you credibility and respect in the industry.

4. Salary Potential:

   • CCIE-certified professionals often command higher salaries due to their specialized skills and ability to handle mission-critical networks.

5. Personal Satisfaction:

   • Achieving CCIE is a challenging but rewarding journey that brings a deep sense of accomplishment and confidence in your technical abilities.

---

CCDE (Cisco Certified Design Expert):

1. Network Design Mastery:

   • The CCDE certification focuses on advanced network design principles, enabling you to create scalable, secure, and efficient network architectures.

   • It emphasizes strategic thinking, including business requirements, technical constraints, and risk management.

   • You’ll learn to design solutions for large-scale networks, integrating technologies like MPLS, QoS, and cloud connectivity.

2. Strategic Roles:

   • Prepares you for roles such as Network Design Architect, Solutions Architect, or Technical Lead.

   • You’ll be responsible for designing networks that align with business goals and future-proof organizations.

3. Global Impact:

   • CCDE is recognized worldwide as a mark of excellence in network design, making you a sought-after expert for global projects.

4. Salary Potential:

   • CCDE-certified professionals often earn top-tier salaries due to their ability to design innovative and cost-effective solutions.

5. Personal Satisfaction:

   • Earning the CCDE certification is a testament to your ability to think strategically and solve complex design challenges, bringing immense professional pride.

---

Why Pursue CCIE or CCDE?

• Technical Mastery: Both certifications push you to the forefront of networking technology, giving you the skills to work with the latest tools and methodologies.

• Career Advancement: They open doors to leadership roles, consulting opportunities, and high-impact projects.

• Global Opportunities: With these certifications, you can work anywhere in the world, as they are recognized and respected across industries.

• Personal Growth: The rigorous preparation process is intellectually stimulating and builds resilience, problem-solving skills, and confidence.

• Community and Recognition: Joining the elite group of CCIE and CCDE holders connects you with a global network of experts and thought leaders.

---

Conclusion:

Pursuing CCIE or CCDE is not just about earning a certification—it’s about transforming your career and becoming a leader in the networking field. The journey is demanding, but the rewards are immense: technical mastery, career growth, global recognition, and personal satisfaction. If you’re passionate about networking and ready to take your skills to the next level, CCIE and CCDE are the ultimate goals to strive for. They don’t just validate your expertise—they redefine what you’re capable of achieving.

Why Migrate from MPLS to Segment Routing?

 

Why Migrate from MPLS to Segment Routing? A Comprehensive Guide

In today’s rapidly evolving networking landscape, enterprises face the constant challenge of optimizing their network infrastructure to meet growing demands for performance, scalability, and flexibility. One of the key trends in recent years is the migration from traditional MPLS (Multiprotocol Label Switching) to modern technologies like Segment Routing (SR). In this article, we will explore why migrating from MPLS to Segment Routing is a strategic move, the benefits it offers, and a detailed overview of the migration process from LDP (Label Distribution Protocol) to SR.

 

Why Migrate from MPLS to Segment Routing?

1. Simplified Network Architecture

MPLS, while effective, requires complex configuration and management, especially in large-scale networks. Segment Routing simplifies network architecture by eliminating the need for additional protocols like LDP or RSVP-TE (Resource Reservation Protocol - Traffic Engineering). In SR, path information is encoded directly in packet headers, reducing the number of protocols and management mechanisms.

2. Improved Scalability

Segment Routing offers better scalability compared to MPLS. In traditional MPLS networks, each router must maintain the state of every label for every path, which can lead to significant memory and CPU overhead in large networks. SR stores path information more efficiently, enabling easier network scaling without requiring additional hardware resources.

3. Enhanced Traffic Control and Flexibility

SR provides greater flexibility in traffic engineering. By allowing administrators to define application-specific paths (segments), SR enables precise control over how traffic flows through the network. This is particularly useful for applications requiring high availability, such as cloud services or business-critical applications.

4. Seamless Integration with SDN (Software-Defined Networking)

Segment Routing is inherently compatible with SDN architectures, enabling greater automation and optimization. By integrating with SDN controllers, SR allows for dynamic traffic management, automatic fault detection, and fast rerouting, resulting in higher network availability and reliability.

5. Cost Reduction

Migrating to Segment Routing can lead to significant cost savings. The simplified architecture and reduced management requirements mean IT teams can operate more efficiently, and the costs associated with network maintenance can be significantly reduced. Additionally, SR can operate on existing MPLS infrastructure, allowing for a gradual migration without the need for immediate hardware upgrades.

6. Support for Modern Applications

In the era of digital transformation, enterprises are increasingly deploying modern applications such as IoT (Internet of Things), AI (Artificial Intelligence), and cloud-based services. Segment Routing is better suited to meet the demands of these applications, offering lower latency, higher throughput, and improved traffic control.

7. Easier Inter-Domain Traffic Management

For wide-area networks (WANs) or service provider networks, SR simplifies inter-domain traffic management. By enabling end-to-end path definition, SR allows for more efficient traffic management across different network domains, which is particularly important for large enterprises and telecom operators.

8. Future-Proofing with IPv6 Support

Segment Routing is designed with the future in mind, including full support for IPv6. As more organizations transition to IPv6, SR ensures a smooth migration and integration with new networking standards.

---

The Migration Process: From LDP to Segment Routing

Migrating from LDP-based MPLS to Segment Routing requires careful planning and execution. Below is a step-by-step guide to ensure a smooth transition:

1. Assess Your Current Network

• Inventory Your Network: Document all devices, links, and configurations in your MPLS network.

• Identify Dependencies: Determine which applications and services rely on LDP and MPLS.

• Evaluate Hardware and Software Compatibility: Ensure your network devices support Segment Routing. Most modern routers and switches support SR, but older hardware may require upgrades.

2. Design the Segment Routing Architecture

• Define Segment Routing Domains: Decide where SR will be implemented (e.g., core, edge, or entire network).

• Plan Segment Identifiers (SIDs): Allocate Node SIDs, Adjacency SIDs, and any other required SIDs.

• Design Traffic Engineering Policies: Define how traffic will be steered using SR policies, especially for critical applications.

3. Configure Segment Routing

• Enable SR on Devices: Configure SR on routers and switches, ensuring compatibility with existing MPLS infrastructure.

• Configure IGP (Interior Gateway Protocol): Use protocols like OSPF or IS-IS to distribute SIDs and SR information.

• Implement SR Policies: Define and deploy SR policies for traffic engineering and path optimization.

4. Test the SR Configuration

• Conduct Lab Testing: Test the SR configuration in a lab environment to validate functionality and performance.

• Simulate Failures: Test fault tolerance and rerouting capabilities to ensure network resilience.

• Verify Interoperability: Ensure SR works seamlessly with existing MPLS and LDP configurations.

5. Gradually Migrate Traffic

• Start with Non-Critical Traffic: Begin by migrating less critical traffic to SR to minimize risk.

• Monitor Performance: Use network monitoring tools to track performance and identify any issues.

• Migrate Critical Traffic: Once the SR network is stable, migrate critical applications and services.

6. Decommission LDP

• Disable LDP on Devices: Once all traffic has been migrated to SR, disable LDP on routers and switches.

• Remove LDP Configurations: Clean up any remaining LDP configurations to simplify the network.

7. Optimize and Maintain

• Fine-Tune SR Policies: Continuously optimize SR policies based on network performance and traffic patterns.

• Monitor and Troubleshoot: Use monitoring tools to proactively identify and resolve issues.

• Train Your Team: Ensure your network team is trained on Segment Routing concepts and management.

---

Key Considerations During Migration

• Phased Approach: A gradual migration reduces risk and allows for thorough testing at each stage.

• Backup and Rollback Plans: Always have a rollback plan in case of unexpected issues during migration.

• Vendor Support: Work closely with your hardware and software vendors to ensure compatibility and resolve any issues.

• Documentation: Keep detailed documentation of the migration process, configurations, and changes for future reference.

---

Conclusion

Migrating from MPLS to Segment Routing is a strategic decision that can bring significant benefits to your organization, including simplified architecture, improved scalability, enhanced traffic control, and cost savings. The migration process, particularly from LDP to SR, requires careful planning, testing, and execution, but the long-term advantages far outweigh the initial effort.

By adopting Segment Routing, your organization can build a more efficient, flexible, and future-proof network capable of meeting the demands of modern applications and digital transformation. If you’re considering this migration, consult with networking experts to develop a tailored strategy that ensures a smooth and successful transition.