Configuring EIGRP Static Neighbors

There may be times where you need to configure static neighbors for EIGRP such as NBMA networks or for security reasons. This lab will discuss and demonstrate the configuration and verification of static EIGRP Neighbors.

Real World Application & Core Knowledge

If you’ve completed the previous Lab 8-1 – Configuring Basic EIGRP, you’ll notice that EIGRP did not form a neighbor relationship between R1 and R4. This is due to broadcast now being permitted on the frame-map between the two devices. As a restriction the ISP prohibits broadcast on that specific PVC. With that being said, keep in mind that multicast is treated like broadcast on frame relay networks.

As a fix to this issue you can define a static neighbor in the EIGRP routing process which will force EIGRP to communicate to that neighbor via unicast similar to RIP; even the commands are the same which is neighbor x.x.x.x interface#/# where x.x.x.x equals the IP address of the interface and the interface#/# is the interface of which the neighboring relationship will peer over.

When configuring an EIGRP static neighbor, the neighbor statement is required on both ends of the neighbor relationship in the EIGRP routing process that operate in the same autonomous system. Also keep in mind when you specify a static neighbor relationship over a particular interface, EIGRP will disable the processing of multicast EIGRP packets on the specified interface so with that being said EIGRP will not send nor process received multicast EIGRP traffic on an interface which has a static neighbor defined under the EIGRP routing process.

In this lab you will configure a static neighbor relationships on the hub and spokes of the frame-relay network. (R1 to R2, R1 to R3 and R1 to R4)

This lab will continue to build upon the topology used in Lab 8-1 and other labs that are in Section 8.

Familiarize yourself with the following new command(s);

Command Description
neighbor x.x.x.x interface#/# This command is executed in router configuration mode to specify a static neighbor in EIGRP, commonly used in NBMA networks where multicast is not permitted. This command will disable the transmission or processing of received eigrp multicast traffic.
show ip eigrp neighbor This command is executed in privileged mode to show all current neighbor relationships on a particular EIGRP enabled device.

Lab Prerequisites

  • If you are using GNS3 than load the Free CCNA Workbook GNS3 topology than start devices; R1, R2, R3 R4 and R5.
  • Establish a console session with devices R1, R2, R3 R4 and R5 than load the initial configurations provided below by copying the config from the textbox and pasting it into the respected routers console.

 

Lab Objectives

  • Configure static neighbor relationships on the frame-relay hub and spoke network between R1 and R4, R1 and R3, R1 and R2.
  • Verify on R1 that the neighbor relationships have been established.
  • Verify that the routes are being propagated between the spokes to the hub and between spoke to spoke.

Lab Instruction

Objective 1. – Configure static neighbor relationships on the frame-relay hub and spoke network between R1 and R4, R1 and R3, R1 and R2.

R1>enable
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router eigrp 10
R1(config-router)#neighbor 10.80.234.2 Serial0/0
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.80.234.2 (Serial0/0) is down: Static peer configured
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.80.234.3 (Serial0/0) is down: Static peer configured
R1(config-router)#neighbor 10.80.234.3 Serial0/0
R1(config-router)#neighbor 10.80.234.4 Serial0/0
R1(config-router)#end
R1#

R2>enable
R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp 10
R2(config-router)#neighbor 10.80.234.1 Serial0/0.221
R2(config-router)#end
R2#
%SYS-5-CONFIG_I: Configured from console by console
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.80.234.1 (Serial0/0.221) is up: new adjacency
R2#


R3>enable
R3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router eigrp 10
R3(config-router)#neighbor 10.80.234.1 Serial0/0.321
R3(config-router)#end
R3#
%SYS-5-CONFIG_I: Configured from console by console
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.80.234.1 (Serial0/0.321) is up: new adjacency
R3#

R4>enable
R4#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router eigrp 10
R4(config-router)#neighbor 10.80.234.1 Serial0/0
R4(config-router)#end
R4#
%SYS-5-CONFIG_I: Configured from console by console
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.80.234.1 (Serial0/0) is up: new adjacency
R4#

Objective 2. – Verify on R1 that the neighbor relationships have been established.

To view the current neighbor relationships you’ll use the show ip eigrp neighbors command in privileged mode as shown below;

R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
2   10.80.234.4              Se0/0            154 00:02:16   83   498  0  24
1   10.80.234.3              Se0/0             13 00:12:12  788  4728  0  33
0   10.80.234.2              Se0/0             14 00:14:13   88   528  0  29
R1#

Objective 3. – Verify that the routes are being propagated between the spokes to the hub and between spoke to spoke.

As shown below all routes are being advertised to the hub router in the frame-relay network (R1);

R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.80.0.0/8 is variably subnetted, 11 subnets, 4 masks
D       10.80.50.0/24 [90/2809856] via 10.80.234.4, 00:01:35, Serial0/0
D       10.80.40.0/24 [90/2297856] via 10.80.234.4, 00:01:35, Serial0/0
D       10.80.23.1/32 [90/2681856] via 10.80.234.3, 00:11:32, Serial0/0
D       10.80.23.0/30 [90/2681856] via 10.80.234.3, 00:11:32, Serial0/0
                     [90/2681856] via 10.80.234.2, 00:11:32, Serial0/0
D       10.80.23.2/32 [90/2681856] via 10.80.234.2, 00:13:33, Serial0/0
D       10.80.30.0/24 [90/2297856] via 10.80.234.3, 00:07:36, Serial0/0
D       10.80.45.2/32 [90/2681856] via 10.80.234.4, 00:01:36, Serial0/0
D       10.80.45.0/30 [90/2681856] via 10.80.234.4, 00:01:36, Serial0/0
D       10.80.20.0/24 [90/2297856] via 10.80.234.2, 00:07:36, Serial0/0
C       10.80.10.0/24 is directly connected, Loopback0
C       10.80.234.0/29 is directly connected, Serial0/0
R1#

Now verify that the routes from the spoke routers R2 and R3 are in the R4’s routing table as shown below;

R4#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.80.0.0/8 is variably subnetted, 6 subnets, 4 masks
D       10.80.50.0/24 [90/2297856] via 10.80.45.2, 00:10:07, Serial0/1
C       10.80.40.0/24 is directly connected, Loopback0
C       10.80.45.2/32 is directly connected, Serial0/1
C       10.80.45.0/30 is directly connected, Serial0/1
D       10.80.10.0/24 [90/2297856] via 10.80.234.1, 00:04:42, Serial0/0
C       10.80.234.0/29 is directly connected, Serial0/0
R4#

As you can see from above you can tell that routes on R2 and R3 are not getting to R4 thus not being advertised to R5 as well. What causes this problem and how do you fix it?

This type of behavior is caused by EIGRP ip split-horizon which states that routes will not be advertised back out an interface which they were received on. This is a loop-prevention method and in some cases must be disabled such as the hub-and-spoke topology. You will learn more about split-horizon in Lab 8-3 – Configuring EIGRP No Split-Horizon

◄ Previous Lab
Next Lab ►