Implementing VLAN Trunking Protocol (VTP): Practical Insights and Gotchas

February 2016    10 min read

VLAN Trunking Protocol (VTP) has been a staple in Cisco Layer 2 designs since the early 2000s, enabling centralized VLAN administration across switches in the same domain. But for many engineers, VTP is a double-edged sword—capable of streamlining operations or wiping out entire VLAN databases with a single misstep. In this post, we dissect how VTP works, how it’s evolved through VTPv3, and how to safely implement or avoid it in enterprise networks.

What VTP Actually Does

VTP propagates VLAN information across trunk links between switches that share the same domain. Changes made on a VTP server (like creating a new VLAN) are advertised to all clients in the same domain, ensuring consistent VLAN databases across the topology.

Each update carries a revision number, and switches accept updates only if the revision number is higher than what they currently store. This mechanism helps maintain sync—but also opens the door for catastrophic overwrites if not managed carefully.

VTP Modes Explained

There are four operational modes in VTPv3:

• Server: Can create, modify, and delete VLANs. Propagates changes.
• Client: Cannot modify VLANs but accepts and applies advertisements.
• Transparent: Forwards VTP messages but does not modify local VLAN configuration.
• Off: Ignores and does not forward VTP messages.

Server mode seems convenient until an untrusted switch with a high revision number connects and wipes out the VLANs of all downstream clients. This is the notorious “VTP bomb.”

Best Practices for Avoiding Disaster

• Use VTP Transparent mode by default across all switches unless you explicitly need VTP.
• Always reset the revision number when adding switches to an existing VTP domain.
• Configure the domain name and password explicitly on every switch—don’t rely on defaults.
• Consider managing VLANs manually or using automation tools (e.g., Ansible) instead of VTP.

VTPv3 Enhancements

Released to address many shortcomings of earlier versions, VTPv3 introduces several key improvements:

• Support for extended VLANs (1006–4094)
• Per-database protection for VLANs, MST, and private VLANs
• Configurable primary server election
• Capability to disable VTP entirely with the off mode
• Authentication enhancements including MD5 digest with hidden passwords

While these upgrades help mitigate the risks of legacy behavior, VTP still requires careful planning and restricted administrative access.

Sample Configuration

    vtp version 3
    vtp domain secure-domain
    vtp mode transparent
    vtp password strongPass123
  

With this setup, the switch will forward VTP messages but not apply or generate changes. This gives you the benefit of visibility without the risk of automatic database synchronization.

Lessons from Production Networks

We've seen production outages caused by switches pulled from test labs and plugged into production trunks without clearing their VTP state. In one case, a lab switch with a blank VLAN database and a higher revision number was introduced and erased 50+ production VLANs from all access switches.

In another instance, a VTP password mismatch prevented critical VLAN propagation—resulting in partial outages during maintenance windows.

The takeaway? If you must use VTP, treat it like a configuration management system, with strict controls and clear change processes.

Should You Use VTP Today?

In 2016, many network architects are opting out of VTP entirely. With the rise of controller-based fabrics, automation, and programmable overlays, centralized VLAN management via VTP feels increasingly outdated.

Still, in small or static environments with experienced admins, VTPv3 can provide convenience—so long as you document everything and treat it with respect.

Conclusion

VTP is not evil—but it is powerful, and power requires responsibility. Whether you use it, disable it, or replace it with automation, make sure your Layer 2 strategy is predictable, documented, and resilient to operator error.

Eduardo Wnorowski is a network infrastructure consultant and Director.
With over 21 years of experience in IT and consulting, he helps organizations build resilient Layer 2 environments with clarity and operational control.
Connect on Linkedin

Fine-Tuning EIGRP Metrics: Understanding Bandwidth, Delay, and K Values

April 2015   |   Reading Time: 10 min read

Introduction

Enhanced Interior Gateway Routing Protocol (EIGRP) remains a preferred choice in many enterprise environments for its balance of performance and simplicity. While often praised for its ease of deployment, EIGRP’s true power lies in its customizable metric system. Engineers who understand how bandwidth, delay, and K values interact can influence path selection with surgical precision. This post explores how to fine-tune EIGRP metrics effectively.

EIGRP Metric Formula

EIGRP uses a composite metric that includes bandwidth, delay, reliability, load, and MTU. The default metric calculation uses only bandwidth and delay, and the simplified formula looks like this:

metric = 256 * (K1 * bandwidth + K3 * delay)

By default, K1 and K3 are set to 1, and all other K values (K2, K4, K5) are set to 0. This means that only bandwidth and delay impact the routing decision.

Understanding Bandwidth in EIGRP

EIGRP treats bandwidth as the minimum bandwidth along the path. Lower bandwidth increases the metric and makes a path less preferred.

interface FastEthernet0/1
 bandwidth 10000

Note: This does not limit actual throughput. It's only used for metric calculations and QoS shaping.

Understanding Delay in EIGRP

Delay is cumulative and expressed in tens of microseconds. EIGRP adds the delay of each interface along the path. Lower delay means a better metric.

interface Serial0/0
 delay 2000

Be cautious when manually adjusting delay to influence routing—it impacts convergence and route selection.

Customizing K Values

You can modify which factors EIGRP uses by changing the K values, but this must be consistent across the entire EIGRP domain.

router eigrp 100
 metric weights 0 1 0 1 0 0

This configuration activates bandwidth (K1) and reliability (K4), which is uncommon and can introduce instability if not coordinated.

Why Not Use Reliability or Load?

• Reliability and load are dynamic and can fluctuate rapidly.
• Instability in these metrics can cause frequent route recalculations.
• Best practice is to avoid using K2, K4, and K5 in production unless explicitly required and monitored.

Influencing Routing Decisions

Adjusting interface delay is the safest and most predictable method to influence EIGRP metrics. Use it when you want to prioritize certain links over others without changing topology.

interface Serial0/1
 delay 1500

Metric Calculation Example

Assume a path with two interfaces: one with bandwidth of 100 Mbps and delay of 1000, the other with bandwidth of 10 Mbps and delay of 2000.

metric = 256 * (10^7 / min_bw + sum_delay)

metric = 256 * (10^7 / 10000 + 3000) = 256 * (1000 + 3000) = 1,024,000

Verification and Troubleshooting

• Use show ip protocols to verify active K values.
• Use show ip route eigrp to confirm path selections.
• Use show interfaces to check bandwidth and delay settings.
• Use debug eigrp fsm for deeper convergence analysis (use cautiously).

Best Practices

• Stick to default K values unless you have a clear use case.
• Adjust delay rather than bandwidth to influence metrics.
• Document any metric manipulations for audit and troubleshooting.
• Test changes in a lab environment before deploying to production.

Conclusion

Understanding how EIGRP calculates its composite metric gives network engineers a significant degree of control. Whether you're influencing primary paths or preparing for convergence scenarios, knowing when and how to tune bandwidth, delay, and K values can elevate your routing strategy. With great power comes great responsibility—so adjust carefully, document thoroughly, and always test before rollout.

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

BGP Communities Demystified: Tagging Routes with Meaning

January 2015   |   Reading Time: 9 min read

Introduction

Border Gateway Protocol (BGP) is the cornerstone of the Internet’s routing architecture. While most engineers are familiar with BGP attributes like AS_PATH and NEXT_HOP, BGP communities remain an underutilized yet powerful tool for applying policy and enabling route tagging.

What Are BGP Communities?

BGP communities are optional transitive attributes that allow routers to tag prefixes with metadata. These tags, in turn, can be used to apply policies across autonomous systems (ASes) or within large ISPs. Each community is a 32-bit value, typically represented as two 16-bit integers: <AS>:<value>.

For example, a route tagged with 65000:100 might mean "do not advertise to peers" in a particular provider’s policy.

Standard vs Extended Communities

Standard communities are the most commonly used and are typically sufficient for intra-domain or provider-edge policies. Extended communities provide more granularity, such as VPN-related identifiers in MPLS VPN environments.

Use Cases for BGP Communities

• Traffic engineering (e.g., prepending AS_PATH based on tags)
• Regional route control (e.g., advertise routes only in Asia)
• Customer-specific policies (e.g., blackholing using a special tag)
• Simplifying prefix-list/filter complexity

Sample Configuration

    router bgp 65000
     bgp log-neighbor-changes
     neighbor 192.0.2.2 remote-as 65001
     neighbor 192.0.2.2 send-community
    !
    ip community-list 10 permit 65000:100
    !
    route-map TAG-IN permit 10
     match ip address prefix-list FROM-CUSTOMER
     set community 65000:100 additive
    !
    route-map TAG-OUT permit 10
     match community 10
     set local-preference 200
    !
    router bgp 65000
     neighbor 192.0.2.2 route-map TAG-IN in
     neighbor 192.0.2.2 route-map TAG-OUT out

Best Practices

• Always document what each community means.
• Use a well-defined registry if you’re a service provider.
• Avoid overlapping or conflicting community policies.
• Enable 'send-community' to propagate community values between neighbors.

Common Pitfalls

A common mistake is assuming that communities are automatically propagated. Without 'send-community' enabled, no tags are transmitted. Another pitfall is not filtering inbound communities from customers, which may result in unintended policy triggers.

Testing and Validation

Use commands like show ip bgp, show ip bgp community, and debug ip bgp to validate policies. Tools like route views or looking glasses can help confirm community visibility across provider boundaries.

Future Outlook

With the rise of route automation and SDN, BGP communities will continue to serve as a programmable interface for real-time routing adjustments. Standardization efforts (e.g., Large BGP Communities - RFC 8092) aim to expand their capabilities.

Conclusion

BGP communities provide engineers with a scalable and flexible method of applying policy without touching complex ACLs or route-maps. Mastering communities is essential for anyone managing BGP in modern enterprise or service provider environments.

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

Implementing AAA Services on IOS Devices with RADIUS and TACACS

December 2013 • 7 min read

In modern enterprise networks, robust user authentication and access control mechanisms are critical to maintaining a secure infrastructure. Cisco IOS devices offer support for Authentication, Authorization, and Accounting (AAA) services, which enable administrators to enforce consistent access policies and monitor network usage. Two widely adopted AAA protocols in IOS environments are RADIUS and TACACS+.

Understanding AAA

AAA stands for Authentication, Authorization, and Accounting:

• Authentication verifies a user's identity before granting access to network resources.
• Authorization determines what an authenticated user is allowed to do.
• Accounting tracks what users do on the network, including commands entered and sessions initiated.

RADIUS vs TACACS+

Both protocols are used to implement AAA, but they differ in how they handle communication and capabilities:

• RADIUS (Remote Authentication Dial-In User Service) combines authentication and authorization in a single process. It uses UDP and is widely used for network access authentication (e.g., VPN, Wi-Fi).
• TACACS+ (Terminal Access Controller Access-Control System Plus) separates all three functions (authentication, authorization, accounting), uses TCP, and provides more granular command-level control. It is typically preferred for administrative access control on IOS devices.

Configuring AAA on Cisco IOS

To begin using AAA services, you must first enable AAA on the device:

Router(config)# aaa new-model
  

Configuring RADIUS

Add a RADIUS server and define its shared secret:

Router(config)# radius-server host 192.168.1.10 key radiusSecret
Router(config)# aaa authentication login default group radius local
  

Configuring TACACS+

For TACACS+, define the server and set up the AAA method:

Router(config)# tacacs-server host 192.168.1.20
Router(config)# tacacs-server key tacacsSecret
Router(config)# aaa authentication login default group tacacs+ local
  

Fallback Authentication

In both cases, using local as a fallback ensures access if the external server is unavailable.

Authorization and Accounting Examples

To authorize exec shell access and account for user commands:

Router(config)# aaa authorization exec default group tacacs+ local
Router(config)# aaa accounting exec default start-stop group tacacs+
  

Use Cases and Deployment Considerations

RADIUS is ideal for end-user authentication, such as wireless access or VPN logins. TACACS+ is preferred for network device management due to its superior command control and logging granularity. Enterprises often deploy both simultaneously, using RADIUS for end-user access and TACACS+ for admin access.

Best Practices

• Use encrypted transport and strong shared secrets.
• Segment AAA traffic on a dedicated management network.
• Regularly audit AAA logs to detect anomalies.
• Ensure backup user access methods are available.

 

✅ Want to improve your network security posture?
Try implementing AAA services in your test environment to gain better visibility and control.

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

Multicast Routing with PIM: Understanding Dense and Sparse Modes

August 2012 - Estimated reading time: 9 min

Multicast routing is a critical feature in modern IP networks, allowing the efficient delivery of data streams to multiple receivers. Protocol Independent Multicast (PIM) is the de facto standard used for multicast forwarding in enterprise and service provider environments. This post takes a deep dive into how PIM operates, focusing on Dense Mode (PIM-DM) and Sparse Mode (PIM-SM), and the network scenarios best suited to each.

Understanding Multicast Basics

Unlike unicast or broadcast, multicast enables the delivery of a single stream of traffic to multiple interested receivers without flooding the network. The use of multicast groups (224.0.0.0/4) enables this selective delivery. Routers must build multicast distribution trees that ensure efficient delivery paths to all group members.

PIM Overview

PIM operates independently of the underlying unicast routing protocol (thus the name). It uses existing unicast routing tables to determine reverse paths for multicast forwarding. PIM is not a routing protocol in itself — it doesn’t discover routes but leverages others (e.g., OSPF, EIGRP, BGP).

PIM Dense Mode (PIM-DM)

PIM-DM assumes that all routers want multicast traffic. When a source starts transmitting, multicast packets are flooded throughout the network. Routers that don't have interested receivers will prune the branches of the multicast tree. After a while, the forwarding state stabilizes based on actual interest.

Key Characteristics of PIM-DM:

• Flood-and-prune mechanism
• Periodic state refresh (every 3 minutes by default)
• Suitable for small networks with many multicast receivers

This approach results in unnecessary traffic in large or sparsely populated networks. As such, PIM-DM is falling out of favor for most production networks but can still be useful in tightly controlled LAN environments or labs.

PIM Sparse Mode (PIM-SM)

In contrast, PIM-SM assumes that multicast receivers are sparse. No traffic is forwarded unless a router explicitly requests it via a join message. The protocol builds a shared tree rooted at a Rendezvous Point (RP), and can later switch to a source-specific shortest path tree (SPT).

Key Characteristics of PIM-SM:

• Join-driven approach — only routers with receivers join the multicast tree
• Uses Rendezvous Points (RP) for shared trees
• Can switch to shortest-path trees for optimization
• More scalable and efficient than Dense Mode

Dense vs Sparse: Choosing the Right Mode

The choice between PIM-DM and PIM-SM hinges on network topology and multicast group density. PIM-DM is easier to configure but less efficient. PIM-SM is more scalable and controllable, with RP redundancy and policy mechanisms like Auto-RP and BSR improving availability and automation.

Hybrid Networks and Bidirectional PIM

Many modern networks operate in a hybrid mode, using PIM-SM for general multicast traffic and PIM-Bidir for very dense applications (like financial trading floors). Bidirectional PIM enables many-to-many communication without requiring source registration to the RP, improving performance in specific cases.

Verification and Troubleshooting

Useful IOS commands for PIM include:

• show ip mroute — Displays multicast routing table entries
• show ip pim neighbor — Verifies neighbor relationships
• debug ip pim — Diagnoses protocol behavior in real time

Always ensure that unicast routing to the RP is functional, as PIM relies on reverse-path forwarding checks to prevent loops.

Conclusion

PIM continues to be an essential building block for multicast deployments. Dense Mode offers simplicity for small, tightly knit networks, while Sparse Mode provides control and efficiency at scale. With proper configuration and RP redundancy, PIM-SM can reliably serve even the most demanding multicast applications.

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

Understanding Route Maps in Cisco IOS: Policy Control in Action

June 2012   |   9 min read

In Cisco IOS, route maps serve as a highly flexible tool for defining conditional routing and policy enforcement. They are widely used in policy-based routing (PBR), redistribution, filtering, and advanced BGP/OSPF manipulations. This post dives into their syntax, structure, and best practices.

What is a Route Map?

A route map is essentially a conditional if-then construct for modifying or filtering routes. Each route map comprises multiple numbered entries called clauses. These are evaluated sequentially until a match occurs, making the order of entries critical.

Route Map Use Cases

• Policy-Based Routing (PBR): Forwarding decisions based on source IP or packet attributes, not just destination.
• Redistribution Control: Manipulating which routes are injected between protocols (e.g., OSPF to BGP).
• Prefix Filtering: Allow or deny based on prefix-lists or access-lists.
• Attribute Manipulation: Changing BGP metrics (MED, weight, local preference).

Route Map Syntax Overview

route-map <name> permit|deny <sequence>
  match ...
  set ...
  

Each clause contains match statements (criteria) and set statements (actions). If no match is made, the next clause is evaluated. If no clauses match, the route is denied by default.

Policy-Based Routing Example

access-list 101 permit ip 192.168.10.0 0.0.0.255 any

route-map PBR permit 10
  match ip address 101
  set ip next-hop 10.1.1.1

interface FastEthernet0/0
  ip policy route-map PBR
  

This configuration routes traffic from 192.168.10.0/24 to next-hop 10.1.1.1 regardless of the routing table.

Controlling Redistribution

Let’s look at filtering route redistribution into OSPF:

route-map REDIST deny 10
  match ip address 10

route-map REDIST permit 20

router ospf 1
  redistribute eigrp 100 route-map REDIST
  

This example denies redistribution of certain prefixes while allowing all others.

Match and Set Commands

Some of the most common match commands:

• match ip address
• match interface
• match metric
• match route-type

Useful set commands include:

• set ip next-hop
• set metric
• set local-preference
• set weight

Best Practices

• Use sequence numbers in increments (e.g., 10, 20, 30) for flexibility.
• Test route-map logic with show route-map and debug ip policy.
• Document the logic inside config with comments.
• Combine with prefix-lists for efficient and readable filtering.

Verifying Route Maps

Verification tools:

• show route-map
• show ip policy
• show ip bgp or ospf database
• debug ip policy (use with care)

Conclusion

Route maps are foundational tools in Cisco IOS. Whether directing traffic with PBR or shaping protocol behavior, mastering route-map logic will elevate your capabilities in enterprise network design and troubleshooting.

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

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.

Cisco IOS NAT & Firewall Basics

October 2007 · Reading time: 7 minutes

By 2007, securing perimeter access using Cisco IOS software had become an increasingly popular method for small and medium-sized networks to implement cost-effective security. At the center of this approach lies Network Address Translation (NAT) and firewall capabilities baked directly into Cisco routers.

NAT offers address conservation and a layer of abstraction between public and internal IPs. Dynamic NAT, static NAT, and PAT (Port Address Translation) are all available in IOS, each with configuration nuances. For example, when configuring PAT:

    interface FastEthernet0/0
     ip address 192.0.2.1 255.255.255.0
     ip nat outside
    !
    interface FastEthernet0/1
     ip address 10.0.0.1 255.255.255.0
     ip nat inside
    !
    ip nat inside source list 1 interface FastEthernet0/0 overload
    access-list 1 permit 10.0.0.0 0.0.0.255

This configuration sets up PAT to translate internal addresses into the router's outside interface IP. The overload keyword enables multiple devices to share the public IP using different ports.

IOS Firewall Capabilities

While not a full-featured firewall like a PIX or ASA, Cisco IOS offers Context-Based Access Control (CBAC), allowing inspection of traffic at the application layer. CBAC dynamically opens return paths for inspected protocols, greatly enhancing security posture without the complexity of ACL micromanagement.

For instance, when enabling CBAC for TCP traffic, the IOS router inspects outgoing connections and dynamically creates temporary ACL entries for corresponding return traffic. This can be done using:

    ip inspect name myfw tcp
    ip inspect name myfw udp
    ip inspect name myfw icmp
    interface FastEthernet0/0
     ip inspect myfw out

This level of inspection is sufficient for many branch deployments or networks with limited security budgets. Additionally, logging and alerting features via SNMP or syslog provide visibility.

Limitations and Best Practices

Despite its benefits, IOS firewalling has limitations. It lacks deep inspection for modern web applications or encrypted traffic. There's also limited protection against sophisticated attacks or malware. Nonetheless, when paired with disciplined ACLs, monitoring, and updates, it can form a reliable first layer of defense.

Key best practices include:

• Use ACLs to restrict exposed services
• Regularly update IOS firmware for security patches
• Log and monitor traffic patterns for anomalies
• Deploy additional layers for sensitive networks (e.g., IDS/IPS, endpoint protection)

Cisco IOS-based NAT and firewall features remain relevant in environments where simplicity, cost, and reliability matter. Understanding these features enables engineers to design secure networks without requiring high-end firewalls at every edge.

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

Refining Routing Decisions: Administrative Distance and Route Selection

July 2005 | Reading time: 6 minutes

In the realm of routing decisions within Cisco IOS, understanding how administrative distance influences route selection is fundamental. This internal metric helps routers determine the most trustworthy route when multiple sources provide paths to the same destination.

Administrative distance (AD) is essentially a ranking system. Routes learned via directly connected interfaces have the lowest AD (0), followed by static routes (1), and then dynamic routing protocols like EIGRP, OSPF, and RIP with increasing values.

Consider a scenario where a router learns about network 10.0.0.0/8 via both EIGRP (AD 90) and RIP (AD 120). The router installs the EIGRP-learned route because it has a lower administrative distance. This mechanism ensures that more reliable routing information takes precedence.

However, administrators can manipulate administrative distances to control route preference. For example, adjusting the AD of a static route to 250 makes it less likely to be selected over dynamic routes, useful in backup scenarios or routing policy enforcement.

Understanding these values and how they interact with the routing table allows network engineers to shape behavior more precisely, especially in complex enterprise environments with multiple routing protocols coexisting.

From a troubleshooting standpoint, verifying AD values is a go-to step when expected routes are missing or incorrect routes appear in the table. Tools like show ip route and show ip protocols can provide immediate insight.

As networks become increasingly hybrid, understanding administrative distance is vital for maintaining routing consistency and minimizing failover surprises. Whether deploying policy-based routing or preparing for future migrations, AD plays a quiet but critical role in route control.

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

Cisco IOS Switching Paths: Process, Fast, and CEF

April 2005 · 6 min read

When packets arrive at a Cisco router, the decision about how to forward them depends on the switching path in use. Early in IOS development, routers relied primarily on process switching, where each packet was handled directly by the main CPU. This method was flexible but slow, limiting throughput.

Fast switching was introduced to address performance concerns. The first packet of a flow is process-switched, but the forwarding information is cached. Subsequent packets are switched using this cache, significantly reducing CPU load and improving speed.

As networks evolved, Cisco introduced Cisco Express Forwarding (CEF), which became the default switching method. CEF pre-populates the FIB (Forwarding Information Base) and adjacency tables, allowing for near-instant lookup and forwarding. This approach not only improves performance but also scales better in modern networks.

Understanding when and how these switching paths are applied is vital for troubleshooting high CPU usage or asymmetric routing behavior. It's common to disable CEF on interfaces for testing or troubleshooting, but in production environments, it should remain enabled for consistency and performance.

To inspect switching statistics, use show interfaces switching or show ip cef on Cisco devices. These commands provide insight into how traffic is handled and help validate network design decisions.

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