First of all a clarification. There’s a difference between “static routes” and “statically configured EIGRP neighbors”. I assume that in your post, where you mention the former, you actually mean the latter.
So can EIGRP static neighbors be configured over regular Ethernet links instead of over Frame Relay? Yes, you can. However, there’s no reason to do so. The feature is useful for technologies, such as Frame Relay, that don’t support multicast. Unless there’s some obscure configuration scenario that needs it, since Ethernet supports multicast, there’s no reason to do so.
As for the method of configuration, Nexus devices use the ip router eigrp command on the interface to indicate which interfaces and their corresponding subnets, will participate in EIGRP. In addition, things like summary addresses are also applied to interfaces rather than the EIGRP router mode configuration. This simply has to do with the syntax of configuration, and not so much on the actual operation of EIGRP.
EIGRP is also configured differently when IPv6 is used, or when EIGRP named mode is used. To familiarize yourself with these and the method and syntax of implementation it will simply take practice.
Unfortunately, I was unable to get the GNS3 files to function. Can you share your configs for the neighboring routers? In the link I shared in my previous post, the NetworkLessons Note on IPv6 EIGRP static neighbors, the important aspects were that you must use the link local address to create the static neighbor adjacency. Take a look, share your config, and we’ll revisit the issue shortly!
Thanks for sending those files. I was able to recreate your EIGRP IPv6 neighbor adjacencies. I started off by creating the dynamic adjacencies as shown in your configs. Adjacencies were created as expected. I then went on to apply the static adjacency like so:
(Note that in my topology I’m using Gi0/1 instead of Gi0/0, but all the rest is the same).
R-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R-1(config)#ipv6 router eigrp 6
R-1(config-rtr)#neighbor FE80:12::2 gig 0/1
R-1(config-rtr)#
*Mar 15 07:01:10.728: %DUAL-5-NBRCHANGE: EIGRP-IPv6 6: Neighbor FE80:12::2 (GigabitEthernet0/1) is down: Static peer replaces multicast
R-1(config-rtr)#
Once applied to R-1, the SYSLOG message reports the appropriate result. Take a look at what happens to R-2:
*Mar 15 07:01:11.400: %DUAL-5-NBRCHANGE: EIGRP-IPv6 6: Neighbor FE80:12::1 (GigabitEthernet0/1) is down: Interface PEER-TERMINATION received
A peer termination is received, and the adjacency is currently down. Configuring the static neighbor on R-2 results in the following:
R-2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R-2(config)#ipv6 router eigrp 6
R-2(config-rtr)#neighbor FE80:12::1 gigabitEthernet 0/1
R-2(config-rtr)#
*Mar 15 07:01:56.271: %DUAL-5-NBRCHANGE: EIGRP-IPv6 6: Neighbor FE80:12::1 (GigabitEthernet0/1) is up: new adjacency
R-2(config-rtr)#
A new adjacency successfully forms. Looking again at R-1, we see:
*Mar 15 07:01:55.597: %DUAL-5-NBRCHANGE: EIGRP-IPv6 6: Neighbor FE80:12::2 (GigabitEthernet0/1) is up: new adjacency
So I was able to create the static neighbors using IPv6 EIGRP. Let us know what results you are getting so that we can help you further your troubleshooting process.
Yes, a static neighborship can form after a dynamic neighborship has already been formed.
However, I’m unable to create a static neighborship without first having the dynamic neighborship.
And you?
FYI:
R-1
en
Conf t
ipv6 router eigrp 6
eigrp router-id 1.1.1.1
neighbor FE80:12::2 g0/0
! Must use LLA
end
R-2
en
Conf t
ipv6 router eigrp 6
eigrp router-id 2.2.2.2
neighbor FE80:12::1 g0/0
end
Assigned the interfaces an IPv6 link-local address, and a global unicast address. Check to see that connectivity is established by pinging.
Created the EIGRP instance in each router with AS1. Issued the no shutdown command to enable it.
Configured the static IPv6 neighbors using the neighbor FE80:12::1 interface gigabitethernet0/1 command on both routers, (using the appropriate link-local address in each case).
Applied the ipv6 eigrp 1 command to the interfaces on both routers to enable EIGRP on those interfaces.
As soon as step 4 was completed on both routers, the neighbor adjacency came up as a statically assigned adjacency. No previous dynamic adjacency was established.
I’ve duplicated this config in my eve-ng topology, but I continue to see a “status deleted” notification when viewing the output of show frame-relay map. Any recommendations or insight would be of great help. I’ve verified all configs on both R1 and R2 are identical to that which Rene posted (see below). Thanks for your input.
R1#sh run int s1/0
Building configuration...
Current configuration : 178 bytes
!
interface Serial1/0
ip address 192.168.12.1 255.255.255.0
encapsulation frame-relay
clock rate 2016000
frame-relay map ip 192.168.12.2 102
no frame-relay inverse-arp
end
R2#sh run int s1/0
Building configuration...
Current configuration : 178 bytes
!
interface Serial1/0
ip address 192.168.12.2 255.255.255.0
encapsulation frame-relay
clock rate 2016000
frame-relay map ip 192.168.12.1 201
no frame-relay inverse-arp
end
R1#sh frame map
Serial1/0 (up): ip 192.168.12.2 dlci 102(0x66,0x1860), static,
CISCO, status deleted
R2#sh frame-relay map
Serial1/0 (up): ip 192.168.12.1 dlci 201(0xC9,0x3090), static,
CISCO, status deleted
I believe that the issue you are facing has to do with a typo that is in the configuration. When you create a frame relay topology, and you are using a direct serial link between two routers, one router must operate as the DCE while the other operates as the DTE. More info about this can be found here:
What this means for your configuration is that the clock rate should be set only on one side of the link (i.e. the DCE side). You should remove the clock rate from the DTE side to make your link come up.
If you still have a problem, you may also need to disable LMI messages. Since there is no Frame Relay switch, the LMI messages are not needed and should be disabled. This can be done by using the no keepalive command on the serial interfaces. This may be needed in your setup depending upon the default behavior of the EVE-NG images.
You can also use the show interface command for these particular interfaces to see the status (it should e up) and any error counters as well. Check these out, and I’ll let Rene know about the typo to make the appropriate changes.
Thank you for the detailed response! I played around with my configs and it looks like adding no keepalive to both sides was all that was needed for the link to come up. I will keep this in mind in the future when working with serial interfaces.
I am running into another issue with this lessons configuration, however. As detailed in the lesson, due to the static mapping, no broadcast or unicast traffic is able to be sent across the PVC.
Within the EIGRP config, a neighbor interface is thus specified to build the relationship. Yet, a relationship is unable to be formed. See below:
According to the lesson “You only have to use the neighbor command to specify the remote neighbor and the interface to reach it. After a few seconds the neighbor adjacency will appear”. When I make the dlci the same on both sides, the neighborship forms without issue as would be expected.
I’m glad to hear that the solution worked for you! The no keepalive command can indeed be a quick fix for certain issues with serial interfaces. However, please remember that disabling keepalives can sometimes mask underlying issues. Ideally, the DCE side of the link should have the clock rate set (without the no keepalive command) and the DTE side should not have the clock rate set, but should have the no keepalive command.
Looking at your configs I don’t see an issue. Things should be working. However, the fact that the EIGRP neighborship forms when the DLCI is the same on both sides indicates that the issue likely lies with how the DLCIs are mapped and possibly with the Frame Relay configuration itself. In a Frame Relay environment, the DLCI values are local identifiers and do not need to match on both sides. However, they need to be correctly mapped.
When you use different DLCIs and your EIGRP neighborship is not being established, have you tried pinging from one device to the other to see if you have IP connectivity? If there is no response, the issue is with the network and likely with the frame relay configuration. If you can ping but the neighborship is not being established, the issue has to do with the EIGRP setup.
Approach your troubleshooting in this manner and see if you’re able to resolve the issue. If you do resolveit let us know here. If not, again, let us know so that we can help you further.
In this lesson, What if connection between R1 and R2 would be ethernet connection , not serial , but if we configure static neighbors on r1 and r2 , will there be only unicast eigrp traffic?
Yes, you are correct. If you configure static neighbors on R1 and R2, there will only be unicast EIGRP traffic between them, regardless of the connection type (Ethernet or Serial).
I have question regarding the example mentioned in this thread. Can you please advise?
This question is directed at the statement highlighted above. I believe the extra subnet motioned are 192.168.6.0/24 and 192.168.7.0/24 which came as part of route summarization. Instead of summarizing the route to 192.168.0.0 0.0.7.255 , can I enter each network one at a time to avoid the extra network 192.168.6.0/24 and 192.168.7.0/24.
As below:
Router EIGRP 1
no auto summary
Network 192.168.2.0
Network 192.168.3.0
Network 192.168.4.0
Network 192.168.5.0
The post that Andrew is responding to has very specific requirements. The user wants to propagate a statically configured route (not on an interface) via the network command.
Yes, that is correct, but it also includes the 192.168.4.0/24 network as well, which is also unneeded.
Yes you could, but you would need to create null0 route for each one. However, if you did that you would blackhole your traffic to those routes, so that would defeat the purpose. Does that make sense?
