EIGRP Passive Interface

This topic is to discuss the following lesson:

https://networklessons.com/eigrp/eigrp-passive-interface/

Hi Rene,
Very Good Explanation!

Thanks,
SV

Hi Rene,

If we are connected different clients with a L3 Switch , we can used this command (Passive Interface) to stop hello packet to clients.

My question is , if make Passive Interface Defaults on all interface (directly connected to other router) should Adjacency will be there or will be stop ?

Thanks …

Regards

Adil Khan

Hi Adil,

The adjacency will be killed. If you use passive-interface on all interfaces then you need to use no passive-interface for the interfaces that require an EIGRP neighbor adjacency.

Rene

tnks rene bedant

Great and easy to understand lesson. I would only make one request on this for something to be added.
in my lab of this lesson everything went smoothly. Only thing I had some hiccups on that I had to search was the following.

I knew how to setup from the lesson the default command for passive interface. However, for some reason I was thinking “incorrectly” that I needed to setup the no passive-interface command under the interfaces… I tried a few times but it was not working for obvious reasons as that was the wrong place. Its small thing and I quickly did a search and found out what I was doing wrong. However, that would be nice to specify that went under the Eigrp router command.

(Just a note you do explain this fully under OSPF passive interface lesson so I should have known better but I tend to forget as much as I learn at times lol)

I know being able to think for ourselves and not having our hand held and figure out some small things on our own is good life experience but just figured I would mention it. Also I love posting on these forums in particular as this website is the best website to learn routing and switching I have came across in my lifetime. :stuck_out_tongue_winking_eye:

Hello Brian

In EIGRP just like in OSPF, it is possible to set the default state of an interface as passive with the passive-interface default command under the router eigrp configuration. This is explicitly explained in the OSPF passive interface lesson found below, but not in the EIGRP passive interface lesson.


I will inform Rene about your suggestion to add it explicitly in this lesson as well.

I’m very pleased that you find this forum useful for you in your studies and your endeavors to obtaining your CCNP and beyond. We’re glad that we can be of help!!

Laz

1 Like

In your introduction video to EIGRP and every other book that I read, it says that

EIGRP hello messages are sent using multicast address 224.0.0.10

but this debug says otherwise. Can you please clarify?

R1#debug eigrp packets hello
EIGRP Packets debugging is on
(HELLO)

EIGRP: Sending HELLO on FastEthernet0/0
  AS 12, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

EIGRP: Sending HELLO on FastEthernet0/1
  AS 12, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

Update: find out why

R1#debug ip packet
IP packet debugging is on
R1#
*Feb  3 18:31:23.715: IP: s=192.168.13.1 (local), d=224.0.0.10 (FastEthernet0/1), len 60, sending broad/multicast
*Feb  3 18:31:23.715: IP: s=192.168.13.1 (local), d=224.0.0.10 (FastEthernet0/1), len 60, sending full packet

image

1 Like

Hello sales2161

Great to see that you’ve solved the issue. Thanks very much for sharing your findings with everyone, it’s always helpful and adds to the richness of the forum.

Good job!!

Laz

1 Like

Hey ,
I still don’t get how can u advertise an interface without making it send hellos massages.
if perhaps as u said in the lesson I’ll put a passive interface on Fa0/1 how would R2 know how to get to 192.168.10.0 ?
thank you

Hello Takele

Let’s say you have a router R1 with the following configuration:

FastEthernet 0/1 has an IP address of 192.168.10.1/24
FastEthernet 0/2 has an IP address of 10.10.10.1/24
FastEthernet 0/3 has an IP address of 172.16.2.1/24

Here’s the topology:

Now let’s say that we’ve included all three subnets in the EIGRP process using the network command. This means that all updates R1 sends will contain all three subnets. Now by default, EIGRP will sent out hello and update packets out of all of its interfaces. But as you can see in the diagram, there’s no point i sending these updates out of Fe0/2 and Fe0/3 because there are no routers attached to these subnets. So, we can make these two interfaces passive.

Now this doesn’t exclude the networks on these interfaces from participating in EIGRP, but it just says that these physical interfaces will not send out EIGRP hello and update packets. From this you can easily see that R2 will still get an update that contains all three networks. So even networks on passive interfaces are advertised, just not via those interfaces themselves.

I hope this has been helpful!

Laz

2 Likes

Q- IF i want to Have neighbor over passive interface then i must configure the static neighbor …Right?.

Q-Once i will configure the passive interface with static neighbor , Still i will send the periodic Hello or any on demand hello like OSPF virtual link ?

Q-In IGP, if we want to have neighbor then we must have L2 and L3 multicast reach-ability …Right…But how exactly it works in case of GRE and IPSEC,DMVPN etc bcz these are Layer 3 tunnel and the Multicast MAC address does not get carried in the transit …How it encapsulate the Multicast MAC address over overlay L3 tunnel ??

Hello Narad

If you want to create a neighbor relationship on an EIGRP passive interface, then you must configure a static neighbor adjacency. This static adjacency must be configured on both EIGRP routers in order to achieve the adjacency. Note, however, that this is a highly unusual scenario, because the passive command eliminates hellos, while the static neighbor reintroduces them. This should be applied only in very specific scenarios, ones in which you want to suppress multicast hellos, and you want to have only unicast hellos.

Periodic hellos will be sent in unicast, only to the specified neighbor.

For links that don’t support multicast (such as IPSec VPNs for example), you must specify static neighbors in order for routing protocols to operate correctly. However, GRE and DMVPN which is based on GRE do support multicast, and thus can have EIGRP neighbor adjacencies automatically created.

I hope this has been helpful!

Laz

1 Like

"However, GRE and DMVPN which is based on GRE do support multicast, and thus can have EIGRP neighbor adjacencies automatically created."

Did not understand the logic, My question is L2 frame, when the l3 multicast packet will be encapsulated with L2 mAC , which MAc address will be used, it should be L2 mulicast MAc …Right…!..So how that L2 MAC will be routed over the internet …!..or the L2 multicast frame will be tunneled …!!

Hello Narad

GRE and DMVPN support multicast, but it is not implemented in the same way as in a simple network without tunneling. A multicast packet that is tunnelled within a GRE tunnel, will maintain a multicast destination IP address in its IP header, but this is then encapsulated into a second IP packet, which is the GRE packet encapsulation, in which a unicast IP address is placed in the destination field of the IP header.

So a multicast layer 3 packet is encapsulated (tunnelled) into a unicast layer 3 GRE packet. When multicast packets traverse such a tunnel, multicast MAC addresses play no role in the multicast process.

I hope this has been helpful!

Laz

1 Like

Well been like three years since my last post. This time I come back with production story.

I actually did a discovery process not too long ago for a bank and they used EIGRP on EOL switches/routers :X and I had to end up injecting a single static route via route-map in order for a site to site VPN connection from company to client to work as they did not configure EIGRP on the client side firewall of the VPN but instead only used a static routes. In addition, when the client routers that were configured with EIGRP saw this source IP coming from the VPN side they basically did not know how to get back to the source hence the reason for static route injected into EIGRP to be spread out amongst the client devices for return traffic. Not sure if it was the best solution but without a redesign it seemed to work well and solved the issues, we had in reaching the client devices from Bastions/Jump Boxes over secure site to site VPN.

While doing this process I noted on Nexus switch they had following command: “no ip passive-interface eigrp 1” on like 12 interfaces. Now while doing this I was pretty rusty on EIGRP, in fact I still am which is why I am redoing this CCNP ENARSI 300-410 lessons sequentially so I did not catch that these where basically not needed (not that I can see) and note I am not an expert at NXos. Because they would not need this unless they had under EIGRP enabled “passive-interface default command”. So to me it seems these no passive commands where not needed and could have been cleaned up or since production at the very least had a conversation about it. I realize its not a huge item but from design perspective it seems wasteful and in fact you might be able to optimize the entire EIGRP by using a “passive-interface default” command then going back through and on every interface that needed it then apply the “no ip passive-interface” command. This would actually help by removing traffic that was not needed helping to avoid unnecessary traffic.

Perhaps that was originally what happened and someone tried to use the default command but then was not careful and broke some EIGRP routing so removed the default command but then did not clean up the other commands; frankly don’t know but that’s only logical guess I could come up with.

So while what I was working with was Nexus it still is interesting as its very close to Cisco IOS and the lesson.

5k nexus does not show default command but even though not listed in documentation it existed because I logged into the 5k nexus to confirm.

7k nexus shows default command

Hello Brian

I tend to agree with your deductions. The no ip passive-interface command should only be used if the passive-interface default command is used. Otherwise, it is useless. An administrator seems to have made changes in the past, without removing these commands from the interfaces. There is no impact on performance however, it’s just a bit messy.

It’s interesting you note that there is no indication of the passive-interface default command on any NX-OS documentation for the 5000 series devices. I did a search for myself and to my surprise, that command is indeed left out of the command references for any 5000 series device for OSPF and EIGRP!! I only found it in reference to IS-IS here:

I did find it in the 3k, 7k, and 9k documentation for all routing protocols, however. I don’t have a 5k device on hand to test it out, but you say that the command is available, so it looks like Cisco has some deficiencies in their documentation.

You’ve already confirmed that the command exists in the 5k platform, so that’s useful information, thanks for that. I’ll add it to the NetworkLessons Notes as well.

Thanks for the info and for sharing your experiences!

Laz