DEV Community: Abdulrazzaq Aminu

Automated CE(Customer Edge) Router and Switch Provisioning Using Ansible

Abdulrazzaq Aminu — Wed, 06 Aug 2025 09:20:25 +0000

I was tasked with building a scalable and repeatable provisioning system for a client which included CE routers and access switches across a central HQ and multiple branch offices. Each site supported local VLANs for departmental segmentation and required dynamic routing via BGP to the service provider MPLS core.

I developed a modular Ansible-based automation framework. I created a clean directory structure using role-based separation per site and per device type. This allowed for logical scoping of tasks, variables and made the system easy to scale as new sites were added.

The inventory was defined statically in hosts.yml, with clear grouping for HQ and branch devices. Using Ansible network_cli with cisco.ios modules, I automated:

Interface configuration using looped templates from structured YAML variables

BGP session setup with primary and secondary ISPs
VLAN route advertisement under each BGP process

Each device role included:

A tasks/main.yml file for interface and BGP configuration
A vars/main.yml file for block-style variables (interfaces, VLANs, neighbors)

The Ansible playbook playbook.yml targeted each device type by role and applied configurations using idempotent tasks with save_when: always to ensure persistence in NVRAM.

As a result:

CE routers and switches at HQ and branches were fully provisioned with consistent, reusable templates
BGP peering with PE routers were established successfully.
VLAN subnets were correctly advertised to the MPLS core.
The design allowed centralized control, automation at scale, and future expansion without manual rework.

This provisioning system brought clarity, structure, and maintainability to the entire deployment lifecycle.

iBGP Route Reflector Design for MPLS Layer 3 VPN Backbone

Abdulrazzaq Aminu — Wed, 06 Aug 2025 09:12:52 +0000

I was responsible for designing and implementing the Route Reflector (RR) control-plane architecture across our core backbone. The infrastructure consisted of a centralized MPLS core, multiple PE routers deployed across regional Points of Presence (PoPs), and CE routers at customer branches throughout Nigeria.

The primary challenge was iBGP scalability: a full mesh between all PE routers would require a rapidly growing number of neighborships (n(n–1)/2). To solve this, I designed a redundant and geographically distributed Route Reflector topology.

These locations were chosen to ensure geographic redundancy, faster convergence during regional outages, and control-plane resilience. Loopback interfaces were advertised via OSPF Area 0, and RRs maintained control-plane-only functionality and no VRF or CE configurations to preserve CPU resources and isolate fault domains.

On each RR, I configured iBGP VPNv4 peering using peer groups, enabling:

send-community extended for Route Target propagation.
route-reflector-client for efficient route distribution.

Each PE formed iBGP sessions with both RRs using loopback interfaces. I explicitly avoided peering the two RRs with each other, relying on BGP originator-ID and cluster-ID to prevent routing loops. Each RR reflected only routes from its direct clients, maintaining deterministic control-plane behavior.

To validate the deployment, I:

Verified VPNv4 route visibility on each PE.
Confirmed correct RT and RD propagation.
Ensured successful VRF route import/export.
Tested CE-to-CE reachability across VRFs.

The result was a highly scalable, loop-free, and resilient iBGP control-plane:

Reduced iBGP complexity from multiple neighborships to 2 per PE.
Ensured full VPNv4 route reachability across all customer sites.
Enabled clean control/data plane separation, improving stability and simplifying troubleshooting.
This RR design allowed the MPLS backbone to scale seamlessly as new PEs and customers were added across regions.

Enterprise-Wide VRF Segmentation with MP-BGP and Per-VRF OSPF Routing

Abdulrazzaq Aminu — Wed, 06 Aug 2025 09:00:26 +0000

I was part of a service provider deployment project where we were contracted to design and build a scalable, secure, and redundant enterprise network for a large client. The client required traffic isolation per department, centralized internet access, and resilient WAN connectivity with failover mechanisms. The network was designed using a multi-tier architecture consisting of a core, dual distribution switches, and multiple dual-homed access switches to ensure high availability.

My role was to architect and implement the VRF-based segmentation solution across the enterprise. This involved defining and enforcing routing boundaries between departments, enabling policy-based communication and integrating a scalable routing structure that could grow with the business. I chose VRFs with MP-BGP and per-VRF OSPF to achieve these goals.

To begin, I defined unique VRFs for each department assigning structured Route Distinguishers (RDs) and Route Targets (RTs) using a consistent pattern. This provided deterministic control over route distribution and simplified configuration templates across all devices.

Each access switch was dual-homed to both distribution switches and configured with VRF-aware interfaces, enabling both fault tolerance and faster convergence. Within each VRF, I configured separate OSPF processes for routing between access and distribution. This isolated the IGP per VRF and allowed granular redistribution into BGP, ensuring routing symmetry and ease of troubleshooting.

At the distribution layer, I implemented MP-BGP with the vpnv4 address family. Internal BGP peering was established between the distribution switches over loopbacks, and OSPF ensured reachability between them. I activated "send-community" to propagate RTs and controlled route leakage between departments by importing/exporting only the required RTs in each VRF.

Intelligent Internet Failover Using IP SLA and Conditional Default Route Injection

Abdulrazzaq Aminu — Wed, 06 Aug 2025 08:52:20 +0000

In a collapsed-core enterprise network architecture, I managed a high-performance Cisco Catalyst 9500‑24Q‑A switch functioning as the central Layer 3 gateway and aggregation point for all downstream access switches. This switch connected upstream to two redundant WAN edge routers: Edge1, connected to the primary ISP, and Edge2 connected to the secondary link.

The internal routing domain was built on OSPF Area 0, which included the core switch and both edge routers. Externally, the edge routers established BGP sessions with their respective ISPs and received default routes along with selected Internet prefixes.

An operational issue was discovered after a partial upstream failure on ISP1. Although BGP peering between Edge1 and ISP1 remained active and the default route was still installed in Edge1’s RIB, upstream Internet reachability was lost. OSPF, unaware of the failure, continued to propagate the default route from Edge1 to the core switch, resulting in blackholed traffic for all Internet-bound flows from the enterprise.

To address this, I deployed an IP SLA–based tracking mechanism to verify true Internet reachability. I configured ICMP echo probes on each edge router to periodically ping reliable external IP addresses (e.g., 8.8.8.8). These probes were linked to tracking objects, which were then referenced in route maps controlling conditional default route advertisement.

Using the "default-information originate" command in OSPF, I ensured that each edge router would only inject a default route into the OSPF domain when its corresponding IP SLA probe confirmed external reachability. Additionally, I configured OSPF priority and administrative distance settings to prefer Edge1 under normal conditions and fall back to Edge2 automatically when necessary.

The result was a highly resilient and intelligent Internet failover solution. It prevented recurrence of silent blackholing, ensured accurate default route advertisement based on actual upstream availability, and maintained uninterrupted access to business-critical services including VPNs, cloud platforms, and remote access systems.

Automated Router Backups with Python (Netmiko)

Abdulrazzaq Aminu — Wed, 06 Aug 2025 08:45:52 +0000

In a production environment managing dozens of routers across multiple sites, configuration consistency and versioning were critical. Previously, router backups were performed manually, which introduced delays and human error especially during configuration changes or policy updates.

To automate this process, I developed a Python-based solution using the Netmiko library. The script established SSH connections to each router, executed show running-config, and saved the output with clearly identifiable filenames (IP address and timestamp). I incorporated robust exception handling using NetMiko’s built-in classes to skip unreachable or misconfigured devices. Additionally, I integrated the schedule module to automate the script’s execution at defined intervals. This solution delivered reliable, consistent backups across 20+ routers with minimal administrative overhead.

OSPF Stub Area Optimization for External Route Propagation

Abdulrazzaq Aminu — Wed, 06 Aug 2025 08:40:46 +0000

I was troubleshooting a routing issue in a multi-area OSPF deployment for an enterprise spanning multiple locations. The design included Area 0 (core and internet edge), Area 1 (head office), and Area 2 (a branch office configured as a stub). The branch router in Area 2 was not receiving external BGP-learned routes, preventing access to certain services.

After confirming that the core router was redistributing BGP learned prefixes into OSPF as Type 5 LSAs and verified that Area 2's stub configuration was filtering them. I reconfigured Area 2 as a Not-So-Stubby Area (NSSA), enabling the ABR to translate Type 5 LSAs into Type 7 LSAs, which are permitted in NSSA areas. To improve route selection, I further changed the external metric type from N2 to N1, allowing internal cost to be considered during path calculations. The branch office regained full external route visibility with improved routing efficiency.

AS_PATH Prepending for Inbound Path Manipulation

Abdulrazzaq Aminu — Wed, 06 Aug 2025 08:37:18 +0000

While managing an enterprise edge router connected to both a transit provider and a local Internet Exchange Point (IXP), I observed that return traffic destined for IXP-advertised prefixes was instead arriving via the transit provider. This resulted in underutilization of the IXP link and unnecessary bandwidth consumption on the more expensive transit path.

To address this, I implemented AS_PATH prepending by appending our ASN three times to outbound route advertisements sent to the transit provider. This made our routes appear less preferred, thereby influencing external networks to return traffic via the IXP instead. This optimization ensured more efficient use of the IXP link and reduced load on the transit connection.