Posted by: Richard @ | February 4, 2008

Day 6 of Week 4 and the end of Week 4

Week 4 has come to an end and it looks like I’m hitting the deadlines I have set for myself J

Day 6 was two and half hours aimed exclusively at EIGRP, and I found one or two little gems; One of the tasks I often work through when studying is to read the command summary of a given protocol/technology to check that I know exactly what every command does.  EIGRP has a relatively short list of protocol dependant commands (hyperlink) but one stood out above the rest to me – I asked myself when would I actually need to use the ‘neighbor’ command option?  Well it turns out that it can be a bit of a ‘gotcha’:

Q. What does the neighbour statement in the EIGRP configuration section do?

A. The neighbor command is used in EIGRP in order to define a neighboring router with which to exchange routing information. Due to the current behavior of this command, EIGRP exchanges routing information with the neighbors in the form of unicast packets whenever the neighbor command is configured for an interface. EIGRP stops processing all multicast packets that come inbound on that interface.
Also, EIGRP stops sending multicast packets on that interface.
The ideal behavior of this command is for EIGRP to start sending EIGRP packets as unicast packets to the specified neighbor, but not stop sending and receiving multicast packets on that interface. Since the command does not behave as intended, the neighbor command should be used carefully, understanding the impact of the command on the network.   Hyperlink

The key point within the answer above is that as soon as you configure an EIGRP ‘neighbor’ entry you are also turning off EIGRP multicast messaging on that interface and therefore it is possible to lose other neighbour adjacencies as soon as it is used.
I decided to test the theory out…..


The first thing I did was check that R1 could see its adjacencies with R2 & R3:

R1#sho ip eigrp neighbors
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq                                            (sec)         (ms)       Cnt Num
1              Fa0/0             10 00:00:23  252  1512  0  4
0              Fa0/0             10 00:01:09   48   288  0  5

OK, EIGRP had the adjacencies in place….
Then I configured R2 as a neighbour using the ‘neighbor’ EIGRP command thus disabling multicast messaging and enabling the use of unicast messaging only:

R1#conf t
R1(config)#router eigrp 1
R1(config-router)#neighbor fastEthernet 0/0

Multicast hellos had been disabled on R1’s FastEthernet0/0 but then I witnessed R3’s AND R2’s hold-times expire:

R1#sho ip eigrp neighbors
IP-EIGRP neighbors for process 1

That confirmed Cisco’s answer but the lack of R2 as a neighbour told me that I needed to configure a mirror of the command on the neighbouring router, in this case R2:

R2#conf t
R2(config)#router eigrp 1
R2(config-router)#neighbor fastEthernet 0/0

The default behaviour of a non-unicast neighbour is to ignore any unicast hellos and to continue to send multicast hellos every ‘hello-interval’ unless the configuration above is done, I then witnessed a new adjacency:

R1#sho ip eigrp neighbors
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq                                         (sec)         (ms)       Cnt Num
0              Fa0/0             14 00:00:19  880  5000  0  9

This confirmed that the EIGRP ‘neighbor’ command needs to flag a  Hazard in my head, here is what happened to R3 straight after configuring R2:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor (FastEthernet0/0) is down: Interface Goodbye received

Please note.  EIGRP will not bring up adjacencies on a ‘passive-interface’ regardless of whether the ‘neighbor’ command is configured (unlike RIP logic).  No hellos are sent in any circumstances.

In my last post I published this:

I should take this opportunity to mention something I didn’t include in my blog post last night; the EIGRP chapter within RSCG2 has an error in the first few pages that subsequent pages are based on – the error being the formula used for the default EIGRP composite metric calculation – I advise that any readers studying for CCNA/CCNP/CCIE seek an alternative source for EIGRP metric information!

I owe the author(s) of RSCG2 an apology, the formula used in RSCG2 for EIGRP composite metric calculation is indeed correct!  The formula is simply expressed in a different way (although I think ‘delay’ should be displayed with a ‘/10’), and that is where the confusion stemmed from after my colleague had pointed out the ‘mistake’ to me previously (see how I have just managed point the finger at someone else! J)

I also mentioned this:

Here’s something interesting that my colleague mentioned to me today; he told me that he has witnessed a router’s IOS version being carried in EIGRP messages, I ‘googled it’ but without any luck (however I did find-out about EIGRP TLV’s), I have also searched the EIGRP header format and all of the TLV’s I can find without unearthing anything.

I now have the answer, the major IOS version (not sub-version) is carried within EIGRP messages:

I had some correspondence with one of the better known CCIE wannabes within the CCIE blogosphere over the last week, he kindly gave me a few tips about this blog and therefore you will be seeing a lot more in my posts from now on, I have previously skipped over publishing certain technical details because of nuances that I didn’t believe I had time to do the necessary digging around for.  I am now going to explore the nuances whenever they appear regardless of whether they hold me up or not, I and you should be the better for it.  For all non-technical readers I will try and keep the personal side of things in a consistent/obvious place.

Lastly, here is week four’s breakdown:

Study time:
Study Hours = 17  inc.
Lab Hours = 3

Total study time so far:
Total Study Hours = 57.5  inc.
Total Lab Hours = 9.5

What I have studied this week:

Recent test scores:
EIGRP = 9/9  (an order for Boson ExSim needs to be brought forward!)
+ Use of command memorizer



  1. Dear Richard

    Thanks for a decent explanation of the use of the neighbor command in EIGRP. I have managed to put this to a practical application and it has solved an issue for me. By controlling which neighbour relationships are formed on an ethernet segment, I have stopped a routing loop.

    Kind Regards


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: