Static neighbor discussion, configuration, and why you may not want to deploy this
Static neighbors have been used in every one of my OSPF labs that include the NBMA, for the same reason you might use configure static EIGRP neighbors, and that’s because the Layer 2 Media doesn’t allow the Adjacencies to form without the statements. However, EIGRP and my NBMA seem to play nice together, it hasn’t been needed but it segways into the discussion of configuring static EIGRP neighbors.
You may want to configure static neighbors if you have some Layer 2 Media type that is not Broadcast or Multicast tolerant, or perhaps as a safety feature to make sure you are only neighbors with routers you define specifically.
I had to perform this recently on the job to piggy back off the non-Broadcast / Multicast tolerant media, configuring static neighbor relationships instead of Multicast discovery, to prove whether the ISP was dropping Multicast traffic because the neighbor command forces EIGRP to use Unicast transmissions between the neighbors when both configured this way.
On the flip side for the security portion, this protects from unknown or possibly malicious devices intercepting the multicast EIGRP packets from your network.
So I configured this over my NBMA, and found it DOES require you to specify an interface as well, which I thought wasn’t going to play nice going out my hub to two different source, but here it is:
R1(config-router)#neighbor 172.12.123.2 s0/0/0 ?
<cr>
R1(config-router)#neighbor 172.12.123.2 s0/0/0
R1(config-router)#
*May 12 04:15:43.735: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is down: Static peer configured
*May 12 04:15:43.735: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is down: Static peer configured
R1(config-router)#neighbor 172.12.123.3 s0/0/0
R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]
Uh oh, better get to R2 to send a R1 an EIGRP love letter back their way:
*Mar 31 00:06:11.100: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/0) is down: Interface Goodbye received
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router eigrp 100
R2(config-router)#neighbor 172.12.123.1 s0/0
R2(config-router)#
*Mar 31 00:07:03.446: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/0) is up: new adjacency
R2(config-router)#
ASR#3
[Resuming connection 3 to r3 … ]
And finally the same for R3:
*Mar 31 21:02:48.793: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/2) is down: Interface Goodbye received
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router eigrp 100
R3(config-router)#neighbor 172.12.123.1 s0/2
R3(config-router)#
*Mar 31 21:04:24.386: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/2) is up: new adjacency
R3(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]
Now to check R1 to see if we are all good:
*May 12 04:16:36.111: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is up: new adjacency
R1(config-router)#
*May 12 04:17:19.363: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is up: new adjacency
R1(config-router)#do sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.12.123.3 Se0/0/0 167 00:00:14 39 234 0 8
0 172.12.123.2 Se0/0/0 178 00:00:58 63 378 0 7
R1(config-router)#
It appears not to be having any issues so far, I ran a debug and we are still getting Hello’s, however instead of them being Multi-cast to 224.0.0.10 they are Unicast between Neighbors.
The down side as you can see, is that BOTH neighbors have to be configured with this, whereas with OSPF only the DR can be configured with static neighbor statements to its minion routers (DROthers) without them having a say in it.
It will also drop the Adjacencies as seen until both sides are configured, and now an even bigger issue is that all neighbors off of the specified interface will need to be configured with a neighbor statement as well and to prove this I will bring in R4 which is connected to R3 via FastEthernet:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router eigrp 100
R4(config-router)#no auto
R4(config-router)#network 172.12.34.0 0.0.0.255
R4(config-router)#do sh ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
FastEthernet0/1 172.12.34.4 YES NVRAM up down
Loopback4 4.4.4.4 YES NVRAM up up
R4(config-router)#
ASR#3
[Resuming connection 3 to r3 … ]
R3(config-router)#int fa0/1
R3(config-if)#no shut
R3(config-if)#
*Mar 31 21:19:52.171: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Mar 31 21:19:52.171: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
*Mar 31 21:19:52.183: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.23.2 (FastEthernet0/0) is down: interface down
R3(config-if)#
ASR#4
[Resuming connection 4 to r4 … ]
*May 12 03:24:19.811: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
R4(config-router)#do sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(100)
R4(config-router)#
As you can see, I had a cable missing issue, but as soon as I popped that sucker into the lab the Adjacency immediately went splat and over on R4 it shows it is not seeing a thing from the rest of our AS 100 so lets give it a neighbor statement and see if R1 will befriend it as well here:
R4(config-router)#neighbor 172.12.123.1 fa0/1
R4(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router eigrp 100
R1(config-router)#neighbor 172.12.34.4 s0/0/0
R1(config-router)#
Interesting, I stuck around to see if the Adjacency was taking some extra time, but no dice. I am guessing I need to form the relationship not through neighbors but to the next hop neighbor, so lets try that again here on R4, leaving the statement on R1 also:
Oooooooh I got it, I’ll spare you the output, I forgot to add 172.12.34.0/24 in EIGRP on R3 because it wasn’t in use in the last labs, after throwing it on there without altering any of what was configured above:
R3(config-router)#network 172.12.34.0 0.0.0.255
R3(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]
R1(config-router)#do sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.12.123.3 Se0/0/0 155 00:25:36 46 276 0 10
0 172.12.123.2 Se0/0/0 143 00:26:19 58 348 0 8
R1(config-router)#
You ungrateful routing protocol! So first I tried simply removing all statements to and from R4 thinking that it’s Fa0/1 link to R3 has not been comprised by this setup, but guess again – No Adjacency is forming.
Ok lets put some neighbor statements on the Fa0/1 interfaces between R3 and R4 to see if that is what is needed, as you can see this is beginning to look like a LOT of administrative overhead:
R1(config-router)# neighbor 172.12.34.4 s0/0/0
R1(config-router)#
ASR#3
[Resuming connection 3 to r3 … ]
R3(config-router)#nei 172.12.34.4 fa0/1
EIGRP: Static nbr 172.12.34.4 already in AS 100 FastEthernet0/1
R3(config-router)#
ASR#4
[Resuming connection 4 to r4 … ]
R4(config-router)#nei 172.12.34.3 fa0/1
R4(config-router)#
*May 12 03:39:06.795: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.34.3 (FastEthernet0/1) is up: new adjacency
R4(config-router)#
I highlighted one line in red, because it gave me this error when trying to remove the neighbor statement from R3, which is how I caught it wasn’t entered in the EIGRP config in the first place:
R3(config-router)#no neighbor 172.12.34.4 fa0/1
EIGRP: AS 100 not running on FastEthernet0/1, can’t delete static nbr
So it apparently held onto that configuration, even though it the interface was not EIGRP enabled, and the show run to confirm there was no config:
router eigrp 100
network 3.3.3.3 0.0.0.0
network 172.12.23.0 0.0.0.255
network 172.12.123.0 0.0.0.255
no auto-summary
neighbor 172.12.123.1 Serial0/2
So that is just kind of odd.
Anyways, so I took a look at R2 just to confirm this overhead, and sure enough he doesn’t know about R4 either because now this router is missing a static neighbor command, and its just turning into a mess.
So this was a good learning experience, but I am removing all this static neighbor stuff from my routers, as this is good if necessary and for security but not something you want to deploy across a large number of routers as that leaves a lot of room for misconfiguration then finding the source – No thanks.
However, between maybe a couple of neighbors between sites, that don’t attach to a lot of other neighbors it can be useful to statically point between your couple of EIGRP routers.
One more point to touch on, to verify static neighbor relationships, “sh ip eigrp nei” doesn’t show static neighbor information, you need to use “sh ip eigrp nei det”, however I already removed the configs just remember that (along with everything else, of course).
The EIGRP RID
The EIGRP Router ID comes up with it’s RID exactly how OSPF does, first it looks for the highest logical (loopback) interface, and if none, it will use the highest physical interface IP address in IPv4 format.
There are a few points here about EIGRP RID and External points that I’ll bullet point style this one and explain further down:
- EIGRP RID used to prevent External routing loops
- Routers injecting external EIGRP routes also knows it’s RID as the “Originator”
- If two neighbors have the same RID they can still form neighbor relationships
- Routers will not accept External updates that have the same RID
That is a lot of External talk, so let us explain here, and actually lets lab this one up. I’ll configure R2 and R3 with the same RID manually, and see first what happens on R1:
R2(config-router)#eigrp router-id 23.23.23.23
R2(config-router)#
ASR#3
[Resuming connection 3 to r3 … ]
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router eigrp 100
R3(config-router)#eigrp
*Mar 31 22:12:23.208: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.23.2 (FastEthernet0/0) is down: Interface Goodbye received
R3(config-router)#eigrp routeri
*Mar 31 22:12:26.462: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.23.2 (FastEthernet0/0) is up: new adjacency
R3(config-router)#eigrp router-id 23.23.23.23
R3(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]
*May 12 05:25:18.799: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is down: Interface PEER-TERMINATION received
R1#
*May 12 05:25:40.599: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is down: Interface PEER-TERMINATION received
R1#
*May 12 05:26:02.835: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is up: new adjacency
*May 12 05:26:02.843: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is up: new adjacency
R1#
I feel like I am running through an exploding building configuring the RID’s, however all adjacencies came back up and everything looks good thus far:
R1#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.12.123.3 Se0/0/0 130 00:01:44 1279 5000 0 39
0 172.12.123.2 Se0/0/0 128 00:01:44 1049 5000 0 22
R1#sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 172.12.34.0/24, 1 successors, FD is 2172416
via 172.12.123.3 (2172416/28160), Serial0/0/0
via 172.12.123.2 (2174976/30720), Serial0/0/0
P 172.12.123.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0/0
P 172.12.23.0/24, 2 successors, FD is 2173416
via 172.12.123.2 (2173416/29160), Serial0/0/0
via 172.12.123.3 (2173416/29160), Serial0/0/0
P 2.2.2.2/32, 1 successors, FD is 2297856
via 172.12.123.2 (2297856/128256), Serial0/0/0
via 172.12.123.3 (2300416/156160), Serial0/0/0
P 3.3.3.3/32, 1 successors, FD is 2297856
via 172.12.123.3 (2297856/128256), Serial0/0/0
via 172.12.123.2 (2300416/156160), Serial0/0/0
So on R1 everything seems good to go, but what about R2 and R3:
R2#sh ip eigrp nei
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.12.123.1 Se0/0 159 00:03:10 120 720 0 32
0 172.12.23.3 Fa0/0 14 00:03:27 5 300 0 36
R2#sh ip eigrp top
IP-EIGRP Topology Table for AS(100)/ID(23.23.23.23)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 3.3.3.3/32, 1 successors, FD is 156160
via 172.12.23.3 (156160/128256), FastEthernet0/0
P 2.2.2.2/32, 1 successors, FD is 128256
via Connected, Loopback2
P 172.12.34.0/24, 1 successors, FD is 30720
via 172.12.23.3 (30720/28160), FastEthernet0/0
P 172.12.23.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 172.12.123.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0
R2#
So to get something going here, I will add a loopback to R3, and redistribute it into EIGRP, and see if R2 is able to see it:
R3(config-router)#redistribute connected metric 1544 10 255 1 1500
R3(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]
R1#sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 172.12.34.0/24, 1 successors, FD is 2172416
via 172.12.123.3 (2172416/28160), Serial0/0/0
via 172.12.123.2 (2174976/30720), Serial0/0/0
P 33.33.33.33/32, 1 successors, FD is 2172416
via 172.12.123.3 (2172416/1660416), Serial0/0/0
P 172.12.123.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0/0
P 172.12.23.0/24, 2 successors, FD is 2173416
via 172.12.123.2 (2173416/29160), Serial0/0/0
via 172.12.123.3 (2173416/29160), Serial0/0/0
P 2.2.2.2/32, 1 successors, FD is 2297856
via 172.12.123.2 (2297856/128256), Serial0/0/0
via 172.12.123.3 (2300416/156160), Serial0/0/0
P 3.3.3.3/32, 1 successors, FD is 2297856
via 172.12.123.3 (2297856/128256), Serial0/0/0
via 172.12.123.2 (2300416/156160), Serial0/0/0
R1#
ASR#2
[Resuming connection 2 to r2 … ]
R2#sh ip eigrp top
IP-EIGRP Topology Table for AS(100)/ID(23.23.23.23)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 3.3.3.3/32, 1 successors, FD is 156160
via 172.12.23.3 (156160/128256), FastEthernet0/0
P 2.2.2.2/32, 1 successors, FD is 128256
via Connected, Loopback2
P 172.12.34.0/24, 1 successors, FD is 30720
via 172.12.23.3 (30720/28160), FastEthernet0/0
P 172.12.23.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 172.12.123.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0
R2#
There is the proof in the pudding, R1 will accept the external route, but R2 with a matching RID will not as routing loop mechanism for External routes.
On a side note that I don’t really care to perform as I am hitting my burnout point, if two routers are directly connected, they will actually discard both Internal and External routes from each other if they have the same RID, however if you stick a router between the two then they are back to dropping only external routes.
That is it for this post on the RID and Static neighbors, it seems to have a lot less use in EIGRP as honestly I am still not quite clear on how it prevents routing loops via the RID.
However, I will take the knowledge that if two routers have the same RID, they will drop External routes as a route loop prevention mechanism, and if directly connected they may drop internal routes as well.
Until next time!
The DEVNET GRIND! 