Sometimes, we might want a router interface to participate in an EIGRP routing process (in order to advertise that interface's network) without that interface sending out EIGRP Hello messages. That's what we'll cover in this blog post.

By the way, this is the fourth posting in a series on Understanding EIGRP. If you missed any of the earlier postings, you can check them out here:

• Understanding EIGRP - Part 1 (Overview, Basic Configuration, and Verification)
• Understanding EIGRP - Part 2 (Neighborships and Metrics)
• Understanding EIGRP - Part 3 (EIGRP Timers)

Previously, we talked about the network net-id wildcard-mask command issued in EIGRP router configuration mode. This command causes two primary actions:

1. Sends EIGRP Hello multicast messages out any interface whose IP address falls within the network address space specified by the network command.
2. Advertises the subnet of any interface whose IP address falls within the network address space specified by the network command.

However, in some instances, we might not want the network command to perform the first action. For example, if an interface connects out to hosts on an LAN and not to other EIGRP-speaking routers, there’s really not a reason to send Hello messages out of that interface. Fortunately, we can selectively suppress the sending of Hellos out of an interface, while still advertising that interface’s subnet to our EIGRP neighbors. This is made possible with the passive interface feature.

Consider the topology below:

Notice that each router has an interface pointing out to a LAN segment (that is, the interface connected to a switch). We do want those interfaces’ subnets to be advertised via EIGRP, but we don’t need to send Hello messages out of those interface (since they’re not connecting to any other EIGRP-speaking routers). That makes these interfaces (that is, interface Gig 0/3 on routers R1, R2, and R3) great candidates to be passive interfaces. The following example shows us how to use the passive-interface interface_id command to make that happen.

In the above example, the passive-interface gig 0/3 command was issued on routers R1 and R2 to say that these routers should suppress the sending of Hello messages out of their Gig 0/3 interfaces (that is, the interfaces connecting to LAN segments). However, the configuration on router R3 takes a slightly different approach. Instead of specifying interfaces that should be passive, the passive-interface default command is given which makes all interfaces passive. Then, the no passive-interface gig 0/1 and no passive-interface gig 0/2 commands were given to selectively say those interfaces should not be passive (since those interfaces to connect to EIGRP neighbors). This type of approach might be useful on routers with multiple LAN interfaces and only a few interfaces connecting to EIGRP neighbors.

Once we issue the passive-interface interface_id command for a specific interface, that interface no longer appears in the output of the show ip eigrp interfaces command, as seen in the example below. Notice how interface Gig 0/3, which was configured to be a passive interface, is not listed. However, EIGRP is still advertising the subnet to which interface Gig 0/3 belongs.

Fortunately, we can determine which, if any, interfaces on a router are acting as passive interfaces by issuing the show ip protocols command. In the output of this command, as seen in the example below, notice that interface Gig 0/3 on router R2 is a passive interface, while its subnet (198.51.100.0 /24) is being advertised by EIGRP.

If you want to watch me teach EIGRP in-depth, please check out either of the following complete video courses I've created for Cisco Press:

Click HERE to learn more about the CCNA R/S 200-125 Complete Video Course.

Click HERE to learn more about the ROUTE 300-101 Complete Video Course.

That's going to wrap it up for this installment of Understanding EIGRP. In the next post in this series, you'll learn how to configure an EIGRP-speaking router with static neighbors. Beyond configuration and verification of static neighbors, you'll also learn the benefit and potential danger of statically configured neighbors.

Enjoy your studies!

Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945