Advanced OSPF Route Redistribution with Prefix Control

November 2009    |   Reading time: 9 min

In complex enterprise networks, route redistribution becomes necessary when multiple routing protocols coexist. OSPF, being a link-state protocol, offers flexible methods to manage redistributed routes and control which prefixes enter the OSPF domain.

Scenario Overview

Imagine a network running OSPF internally but connected to an external EIGRP domain. The design goal is to redistribute EIGRP routes into OSPF, but only allow specific prefixes that match internal policy guidelines.

Configuration Walkthrough

router ospf 1
 redistribute eigrp 100 subnets route-map EIGRP_TO_OSPF
!
route-map EIGRP_TO_OSPF permit 10
 match ip address prefix-list ALLOWED_ROUTES
!
ip prefix-list ALLOWED_ROUTES seq 5 permit 10.10.0.0/16 le 24
  

Explanation and Rationale

The route-map EIGRP_TO_OSPF applies a prefix-list filter that only allows 10.10.x.x/24 subnets to be redistributed. This limits route noise and prevents unintended prefixes from being advertised into OSPF. The use of le 24 enables inclusion of subnets within the permitted /16 range up to /24 granularity.

Verification and Testing

After implementing the configuration, validate the results using:

show ip ospf database external
show ip route ospf
  

You should see only the allowed prefixes from EIGRP appearing in the OSPF routing table as type 5 LSAs.

Conclusion

Prefix-based filtering during route redistribution provides control and minimizes routing instability. Using route-maps and prefix-lists together enables fine-tuned policies that align with design intents, reduce administrative overhead, and improve routing convergence stability in mixed-protocol networks.

Eduardo Wnorowski is a network infrastructure consultant and technologist.
With over 14 years of experience in IT and consulting, he brings deep expertise in networking, security, infrastructure, and transformation.
Linkedin Profile

Mastering OSPF Redistribution Between Areas and Protocols

September 2009 · 7 min read

Open Shortest Path First (OSPF) remains a cornerstone of dynamic routing in enterprise networks. As businesses grow and segments become logically separated, engineers often face the challenge of redistributing routes between OSPF areas or into other protocols like EIGRP or RIP. While redistribution provides flexibility, incorrect configuration can lead to routing loops or suboptimal path selection.

Understanding OSPF Redistribution

Redistribution in OSPF is the process of injecting routes learned via other routing protocols—or from another OSPF process—into the current OSPF process. This is common when transitioning between routing domains, integrating legacy areas, or during mergers and acquisitions where different routing protocols are in use.

There are typically two scenarios:

1. Inter-protocol Redistribution: Between OSPF and another routing protocol (e.g., EIGRP, RIP, BGP).
2. Intra-protocol Redistribution: Between two OSPF processes or areas on the same router.

Walkthrough: Redistributing OSPF into EIGRP

Let’s take a common use case—redistributing OSPF into EIGRP in a Cisco IOS environment.

R1(config)# router ospf 1
R1(config-router)# network 10.10.0.0 0.0.255.255 area 0

R1(config)# router eigrp 100
R1(config-router)# network 192.168.0.0 0.0.255.255

R1(config)# router eigrp 100
R1(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500

In this configuration:

• OSPF is running in Area 0 for 10.10.0.0/16
• EIGRP is configured for 192.168.0.0/16
• The redistribute command includes a required metric for EIGRP to accept OSPF routes.

Controlling Redistribution with Route Maps

To prevent importing unnecessary routes, always filter redistributed routes using a route map:

R1(config)# access-list 10 permit 10.10.1.0 0.0.0.255
R1(config)# route-map OSPF_TO_EIGRP permit 10
R1(config-route-map)# match ip address 10
R1(config-route-map)# set metric 10000 100 255 1 1500

R1(config)# router eigrp 100
R1(config-router)# redistribute ospf 1 route-map OSPF_TO_EIGRP

This ensures only 10.10.1.0/24 is injected into EIGRP with a valid metric.

Verifying Redistribution

R1# show ip route eigrp
R1# show ip protocols

Always verify the redistribution path and ensure no default routes or undesired prefixes leak between routing domains.

Common Pitfalls

• Missing metric: EIGRP requires a full metric; OSPF does not.
• Route feedback loops: When both protocols redistribute each other's routes.
• Redistribution without filtering: Brings unnecessary routes and complexity.

When to Use Multiple OSPF Areas vs Redistribution

Prefer areas when staying within OSPF. Use redistribution only when bridging OSPF to non-OSPF routing domains.

Conclusion

OSPF redistribution, when used correctly, bridges protocols and areas cleanly. Misuse, however, leads to major routing issues. Be conservative, filter intelligently, and test thoroughly.

Eduardo Wnorowski is a network infrastructure consultant and Director. With over 14 years of experience in IT and consulting, he delivers practical networking designs and configuration strategies to solve enterprise connectivity challenges.

Configuring EIGRP in Multi-Area Network Topologies

July 2009  |  ⏱️ 7 min read

Enhanced Interior Gateway Routing Protocol (EIGRP) has established itself as a robust and scalable routing protocol for many enterprise environments. Introduced by Cisco as a hybrid distance-vector protocol, EIGRP offers fast convergence, loop-free operation, and support for VLSM and CIDR.

In this post, we walk through a multi-area topology configuration using EIGRP, focusing on summarization, route filtering, and metrics tuning. This setup helps network engineers design resilient and optimized routing domains.

Network Design Overview

Let’s consider a scenario with three routing domains: Core, Distribution, and Access. Each domain consists of multiple routers, and we aim to build EIGRP neighbor relationships across them while keeping the topology scalable and manageable.

Core          Distribution         Access
[R1]────[R2]────[R3]────[R4]────[R5]

Each router represents a different area in our logical hierarchy, though EIGRP does not support traditional areas like OSPF. Instead, we will use route summarization and stub routing to emulate area-like behavior and keep routing tables concise.

Step-by-Step EIGRP Configuration

1. Enable EIGRP on All Interfaces

    R1(config)# router eigrp 100
    R1(config-router)# network 10.0.0.0 0.255.255.255

Ensure all participating routers use the same autonomous system number (AS). This allows neighbor adjacencies to form.

2. Use Wildcard Masks for Precision

    R2(config)# router eigrp 100
    R2(config-router)# network 10.1.1.0 0.0.0.255
    R2(config-router)# network 10.1.2.0 0.0.0.255

Applying more specific wildcard masks helps control which interfaces participate in EIGRP.

3. Configure Passive Interfaces Where Needed

    R3(config-router)# passive-interface default
    R3(config-router)# no passive-interface FastEthernet0/0

We prevent EIGRP updates from being sent on interfaces that don’t need to form adjacencies, enhancing security and efficiency.

4. Implement Route Summarization

    R4(config-router)# interface FastEthernet0/1
    R4(config-if)# ip summary-address eigrp 100 10.1.0.0 255.255.0.0

Route summarization reduces the size of routing tables and suppresses unnecessary route flaps.

5. Configure Stub Routing at the Edge

    R5(config-router)# eigrp stub connected summary

Stub routers prevent transit traffic and keep routing protocol overhead minimal on access routers.

Tuning Metrics and Convergence

Adjusting delay and bandwidth parameters on interfaces helps influence EIGRP path selection.

    R2(config-if)# interface FastEthernet0/0
    R2(config-if)# bandwidth 1000
    R2(config-if)# delay 10

Remember: EIGRP uses bandwidth, delay, reliability, and load to calculate its composite metric (K values default: K1=1, K3=1).

Verifying the Configuration

R3# show ip eigrp neighbors
R3# show ip route eigrp
R3# show ip protocols

Use these commands to check neighbor relationships, routing table entries, and protocol timers.

Conclusion

Deploying EIGRP in a segmented network demands careful attention to summarization, filtering, and interface tuning. By adopting stub routers and thoughtful route advertisement policies, engineers can maintain fast convergence and efficient routing in medium to large topologies.

Eduardo Wnorowski
With over 14 years of experience in IT and consulting, Eduardo specializes in networking, security, and infrastructure design for enterprise environments. He simplifies complex routing designs and makes networks work smarter.
LinkedIn Profile

Hypervisor Decision Factors: Making the Right Choice in 2009

May 2009 | Reading time: 6 min

In 2009, virtualization is no longer just an emerging trend — it is a critical component of modern IT infrastructure strategies. As adoption increases, organizations face a key decision: which hypervisor platform best fits their environment? While VMware remains the dominant player, Microsoft’s Hyper-V and Citrix XenServer are gaining traction, each offering distinct advantages.

Understanding the Core Players

VMware ESX/ESXi offers mature capabilities, robust management through vCenter, and strong third-party ecosystem support. Enterprises with demanding workloads or specific needs around HA, DRS, or VMotion tend to favour VMware despite higher licensing costs.

Microsoft Hyper-V, bundled with Windows Server 2008, is making significant strides. For organizations heavily invested in Microsoft infrastructure, Hyper-V offers tight integration with Active Directory, SCVMM, and future System Center tools.

Citrix XenServer presents a cost-effective option with open-source roots, good performance, and integration with Citrix's desktop virtualization stack. It also supports live migration and basic clustering at no cost.

Evaluation Criteria in 2009

• Performance: ESX leads in benchmarks, but Hyper-V is catching up quickly, especially with 64-bit guest support and synthetic device drivers.
• Licensing: XenServer and Hyper-V are included with their respective ecosystems, while VMware requires separate licensing even for basic features.
• Management Tools: vCenter is unmatched, but SCVMM is improving. XenCenter is lightweight and functional but lacks advanced orchestration.
• Hardware Compatibility: VMware supports a wider range of CPUs and memory configurations, while Hyper-V requires Intel VT or AMD-V support explicitly enabled in BIOS.

Integration with Existing Infrastructure

One of the most overlooked decision points is ecosystem compatibility. If your datacenter already runs Exchange, SQL Server, and Active Directory, then Hyper-V can integrate seamlessly. Similarly, Citrix shops running Presentation Server or experimenting with XenDesktop may prefer XenServer’s tighter integration and cost alignment.

Support and Training Availability

VMware has a well-established training and certification ecosystem (VCP, VCDX), which can be appealing for teams seeking standardization. Microsoft and Citrix are catching up with official curricula, but community-driven support remains stronger for VMware at this stage.

Choosing the Right Fit

Rather than seeking a one-size-fits-all answer, IT leaders should assess their operational maturity, licensing appetite, and future roadmap. For greenfield deployments where budget is tight and Microsoft infrastructure is dominant, Hyper-V makes a strong case. For mission-critical environments or those requiring deep integration with enterprise tools, VMware retains its edge.

As 2009 progresses, we expect to see further innovation, especially from Microsoft’s Hyper-V R2 release, which promises improved live migration. Until then, the decision still leans on feature parity, operational ease, and long-term flexibility.

Eduardo Wnorowski is a technology consultant focused on network and infrastructure. He shares practical insights from the field for engineers and architects.

Building Resilient Data Centers: March 2009 Strategies

March 2009 • Reading time: 6 min

In March 2009, data center discussions increasingly revolve around how to deliver continuous uptime while keeping capital and operational expenditures in check. IT leaders start to look beyond simple N+1 redundancy and begin integrating smarter, virtualized architectures that can failover seamlessly...

Power distribution is one of the most scrutinized aspects in 2009 planning cycles. Companies begin to adopt modular UPS designs and dual-feed PDUs, which allow data centers to scale capacity without downtime. Virtualization also enables infrastructure managers to spin up backup workloads in geographically redundant locations. ESX 3.5 remains the virtualization platform of choice, providing reliable HA clustering for VM failover.

Thermal zoning and hot aisle/cold aisle containment continue to mature. CFD (computational fluid dynamics) modeling tools help simulate airflow and identify hotspots before equipment is deployed. This preemptive thermal design dramatically improves reliability, especially as blade server densities push rack power envelopes above 10kW.

Storage and SAN configurations also see architectural updates. Active-active multi-controller SAN arrays are increasingly deployed to ensure no single point of failure. The 2009 environment sees many shops standardizing on Fibre Channel over Ethernet (FCoE) pilots as Cisco, Brocade, and HP expand support for converged infrastructure.

Physical security does not take a backseat. Biometrics, mantraps, and logging controls are common in Tier 3+ designs. However, the trend now is toward better integration with logical access control, enabling a seamless audit trail from user ID to rack access.

From a cabling and switching standpoint, organizations adopt more structured approaches. Color-coded, labelled patch panels and top-of-rack (ToR) switches enable easier tracing and faster troubleshooting. This is crucial in high-density environments.

Environmental monitoring with SNMP-enabled sensors becomes common across DC floors, integrating into monitoring platforms such as Nagios or HP OpenView. Alerts for humidity, temp, and airflow are used proactively to schedule maintenance, avoiding reactive outages.

As cloud computing begins its ascent, many mid-size IT departments still opt to run private virtual clusters. These clusters leverage existing real estate while allowing for elastic VM provisioning. It’s a hybrid approach—a stepping stone for future cloud migrations.

Ultimately, the 2009 push toward resilient infrastructure is not just about uptime—it’s about business continuity. When an outage occurs, the question is no longer "when will services be restored" but "why weren’t we already running from somewhere else?"

Eduardo Wnorowski is a technology consultant focused on network and infrastructure. He shares practical insights from the field for engineers and architects.