Hands-On Lab: Configuring EIGRP Routing Using Wildcard Masks

This hands-on lab configures EIGRP using precise wildcard masks in the network command to advertise only specific subnets rather than entire classful networks, giving finer control over exactly which interfaces participate in EIGRP.

EIGRP Wildcard MaskPrecise Network AdvertisementEIGRP Interface Selection

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Reconfigure EIGRP on a router with multiple interfaces using precise wildcard masks in the network command, verifying only the intended interfaces participate in EIGRP rather than every interface within the same classful network.

Lab Purpose

The basic EIGRP configuration in the previous lab used the classful major network address alone, which enables EIGRP on every interface falling within that broad range. A precise wildcard mask, discussed earlier in this series regarding ACLs, narrows this to exactly the intended subnet, avoiding accidentally enabling EIGRP on an interface that should remain excluded.

Lab Topology

R1 with three interfaces, all within the
10.0.0.0/8 classful range:

Gi0/0: 10.1.1.1/24 (should participate in EIGRP)
Gi0/1: 10.1.2.1/24 (should participate in EIGRP)
Gi0/2: 10.99.99.1/24 (management-only, should
                       NOT participate in EIGRP)

Task 1: Configure the Three Interfaces

Configure all three interfaces with the addresses shown.

Task 2: Enable EIGRP Using a Broad Network Statement (Demonstrating the Problem)

Configure EIGRP using only network 10.0.0.0 with no wildcard mask, and observe that all three interfaces become EIGRP-enabled, including the unintended management interface.

Task 3: Remove the Broad Statement and Use Precise Wildcard Masks

Remove the broad network statement, then add two precise network statements using wildcard masks that match only Gi0/0 and Gi0/1's specific subnets.

Task 4: Verify Only the Intended Interfaces Participate

Confirm EIGRP is now active only on Gi0/0 and Gi0/1, and Gi0/2 no longer participates.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 10.1.1.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 10.1.2.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/2
R1(config-if)# ip address 10.99.99.1 255.255.255.0
R1(config-if)# no shutdown

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

R1# show ip eigrp interfaces

Interface       Peers    Xmit Queue
Gi0/0            0        0/0
Gi0/1            0        0/0
Gi0/2            0        0/0
-- All three interfaces are EIGRP-enabled,
-- including Gi0/2, which was never intended
-- to run a routing protocol at all

R1(config)# router eigrp 100
R1(config-router)# no network 10.0.0.0
R1(config-router)# network 10.1.1.0 0.0.0.255
R1(config-router)# network 10.1.2.0 0.0.0.255

R1# show ip eigrp interfaces

Interface       Peers    Xmit Queue
Gi0/0            0        0/0
Gi0/1            0        0/0
-- Gi0/2 no longer appears -- EIGRP is now
-- precisely scoped to only the intended
-- subnets

Key Takeaway

A wildcard mask in the EIGRP network command narrows participation to exactly the specified subnet, rather than the entire classful network the address belongs to — this precision matters specifically on routers with a mix of interfaces that should and should not run the routing protocol, such as a dedicated management interface that must never form neighbor relationships.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه