This topic is to discuss the following lesson:
How do I inject one or two specific static routes (originating from a remote s2s/l2l tunnel) into my EIGRP domain without advertising the static default route?
Example: Internet->ASA-> R1-> R2 -> R3-> R4
ip route 192.168.2.0 255.255.255.0
ip route 192.168.3.0 255.255.255.0 (needs to be routed via EIGRP all the way to R4)
ip route 192.168.4.0 255.255.255.0
ip route 192.168.5.0 255.255.255.0 (needs to be routed via EIGRP all the way to R4)
ip route 0.0.0.0 0.0.0.0 18.104.22.168
I want to propagate these two specific static routes all the way to R4 so network behind R4 can reach 192.168.3.x and 192.168.5.x through the ASA on the other side of the tunnel.
You mentioned these are static routes, and unless you say otherwise, I will assume they are on R1. Since they are static routes, we can assume they were not learned by EIGRP. Therefore, the easiest solution to your problem is advertise only those static routes in EIGRP like this (substitute the autonomous-system “1” below with whatever you are actually using for EIGRP):
R1(config)#router eigrp 1 R1(config-router)#network 192.168.3.0 0.0.0.255 R1(config-router)#network 192.168.5.0 0.0.0.255
The solution above assumes that you don’t want R2 or R3 to learn about any of the other static routes either.
Let’s suppose, however, you want R1, R2, and R3 to know about all the routes, but R4 should only know about the two routes. You would accomplish this by having R1 redistribute its static routes in EIGRP, then apply a Distribute-List on R3 to filter the routes so only the two you want will show up to R4. Here’s the config for this:
R1(config)#router eigrp 1 R1(config-router)#redistribute static metric 10000 10 255 1 1500
The command above takes all static routes on R1, injects them into the EIGRP autonomous-system using the specified metrics. Now, R2, R3, and R4 (assuming they are all running EIGRP) will see these. The last step is to filter out the routes, so R4 will only see what you want. This last step happens on R3.
R3(config)#ip access-list standard ACL_FILTER-FOR-R4 R3(config-std-nacl)#permit 192.168.3.0 0.0.0.255 R3(config-std-nacl)#permit 192.168.5.0 0.0.0.255 R3(config-std-nacl)#exit R3(config)#router eigrp 1 R3(config-router)#distribute-list ACL_FILTER-FOR-R4 out FastEthernet 0/1
Obviously, in the command above, substitute “FastEthernet 0/1” for whatever interface connects R3 to R4.
First off, Thank you for extending your help!
I want to accomplish this WITHOUT distributing or redistributing into EIGRP neighbors within the same AS. I actually tried your recommendation (below) last week in my lab, thinking it would work, but apparently it didn’t!
R1(config)#router eigrp 1 R1(config-router)#network 192.168.3.0 0.0.0.255 R1(config-router)#network 192.168.5.0 0.0.0.255
Here’s what R1 has in its RIB table as static:
ip route 192.168.2.0 255.255.255.0 192.168.24.4 ip route 192.168.3.0 255.255.255.0 192.168.24.4 (needs to be routed via EIGRP all the way to R4) ip route 192.168.4.0 255.255.255.0 192.168.24.4 ip route 192.168.5.0 255.255.255.0 192.168.24.4 (needs to be routed via EIGRP all the way to R4) ip route 0.0.0.0 0.0.0.0 22.214.171.124
Also, I tried the following lab on actual Cisco routers and created 4 static routes on Carl, advertised two out of 5 static routes from Carl by using “network 192.168.3.0 0.0.0.255” and “192.168.5.0 0.0.0.255” thinking they’d show up on Kingkong, Preston, and Ann. But no luck. I made up the default static route to see if I could advertise only two specific static routes.
Andrew, please let me know if you have any questions. Much Appreciated!
The solution I gave you should work, so something else must be going on. Would you mind tells us what configuration you used for the other routers for EIGRP, and what is in the RIB for each of those?
Also, when you tested this in your lab, did you confirm your EIGRP neighbor relationship? For example, if you haven’t statically configured R1 and R2 as being neighbors, you must include the network segment they share as part of the network statement under the EIGRP process.
You can verify your routers have neighbors by doing the following:
R2#sh ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(1) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 10.1.1.1 Fa0/0 13 00:00:06 1 3000 0 1
My lab is setup exactly as follows
Only difference is that I added 6 static routes on Carl and attempted to advertise 2 out of 6 from Carl so they would show up on other EIGRP routers. No LUCK! What am I missing?
However, it works with discard route (tested successfully), distribute-list / redistribution (as you suggested earlier). But it just wouldn’t work / propagate with a simple static and network cmd to other routers.
Please take a look at the attached file.
CARL: where I added 6 static routes and wanted to advertise 192.168.3.x/24 192.168.5.x/24
R4-Carl#sh ip route C 192.168.12.0/24 is directly connected, GigabitEthernet0/0 D 192.168.13.0/24 [90/30720] via 192.168.12.1, 00:01:07, GigabitEthernet0/0 C 192.168.24.0/24 is directly connected, GigabitEthernet0/1 S 192.168.4.0/24 [1/0] via 192.168.24.4 S 192.168.5.0/24 [1/0] via 192.168.24.4 D 192.168.34.0/24 [90/30720] via 192.168.24.4, 00:01:07, GigabitEthernet0/1 S 192.168.0.0/24 [1/0] via 192.168.24.4 S 192.168.1.0/24 [1/0] via 192.168.24.4 S 192.168.2.0/24 [1/0] via 192.168.24.4 S 192.168.3.0/24 [1/0] via 192.168.24.4 R4-Carl#sh ip protocols Routing Protocol is "eigrp 1" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Redistributing: eigrp 1 EIGRP NSF-aware route hold timer is 240s Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 192.168.3.0 192.168.5.0 192.168.12.0 192.168.24.0 Routing Information Sources: Gateway Distance Last Update Gateway Distance Last Update 192.168.12.1 90 00:02:02 192.168.24.4 90 00:02:02 Distance: internal 90 external 170 R4-Carl#sh ip eigrp nei IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.12.1 Gi0/0 12 00:03:18 1276 5000 0 73 1 192.168.24.4 Gi0/1 12 00:19:20 1 200 0 102 R4-Carl#sh ip route eigrp D 192.168.13.0/24 [90/30720] via 192.168.12.1, 00:03:31, GigabitEthernet0/0 D 192.168.34.0/24 [90/30720] via 192.168.24.4, 00:03:31, GigabitEthernet0/1
R2-KingKong#sh ip route eigrp Codes: L - local, 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, H - NHRP, l - LISP + - replicated route, % - next hop override Gateway of last resort is not set D 192.168.24.0/24 [90/30720] via 192.168.12.2, 00:02:32, FastEthernet0/0 D 192.168.34.0/24 [90/30720] via 192.168.13.3, 00:02:32, FastEthernet0/1 R2-KingKong#sh ip eigrp nei EIGRP-IPv4 Neighbors for AS(1) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.12.2 Fa0/0 12 00:11:22 3 200 0 64 1 192.168.13.3 Fa0/1 13 01:08:07 1 200 0 70
R3-Preston#sh ip eigrp nei IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.24.2 Fa0/1 10 00:29:48 1 200 0 62 1 192.168.34.3 Fa0/0 14 01:10:56 1 200 0 71 R3-Preston#sh ip route eigrp D 192.168.12.0/24 [90/30720] via 192.168.24.2, 00:13:57, FastEthernet0/1 D 192.168.13.0/24 [90/30720] via 192.168.34.3, 00:13:55, FastEthernet0/0
R1-ANN#sh ip eigrp nei EIGRP-IPv4 Neighbors for AS(1) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 1 192.168.13.1 Fa0/1 13 01:11:35 1 200 0 74 0 192.168.34.4 Fa0/0 13 01:12:00 1 200 0 103 R1-ANN# R1-ANN# R1-ANN#sh ip route eigrp Codes: L - local, 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, H - NHRP, l - LISP + - replicated route, % - next hop override Gateway of last resort is not set D 192.168.12.0/24 [90/30720] via 192.168.13.1, 00:15:02, FastEthernet0/1 D 192.168.24.0/24 [90/30720] via 192.168.34.4, 00:15:00, FastEthernet0/0 R1-ANN#
I have an answer for you. Your detailed information was very helpful, so thanks for that. EIGRP does NOT advertise static routes (except if you tell it to do redistribution), unless it considers the route to be connected to a local interface. To understand this, you should know that static routes can be defined two different ways:
- The route can point to a next hop address, as you have done: ip route 192.168.4.0 255.255.255.0 192.168.24.4
- The route can point to an interface such as: ip route 192.168.4.0 255.255.255.0 serial0/0/0
When you use an interface as the destination, the router assumes this is a point-to-point connect so there is only one possible destination (the router on the other side). In an multi-access environment, such as Ethernet, this will not work because there could be multiple devices on the other end of the connection.
Now, let’s tie this back to EIGRP. As odd as it may seem, EIGRP considers any static route with an interface as a destination to be “directly connected” and thus eligible for advertisement within EIGRP via a “Network” statement. You can test this by doing the following:
no ip route 192.168.4.0 255.255.255.0 192.168.24.4 ip route 192.168.4.0 255.255.255.0 null0
By changing the static route from using a next hop destination to an interface destination (null 0 counts as an interface), you should see this route being shared within EIGRP.
Now that you know this, you can solve your original problem where you had Internet->ASA-> R1-> R2 -> R3-> R4. You have to cheat a bit to do it, though. If you are determined not to use static route redistribution with a distribute-list for filtering, you can create a “fake” summary route on R1 that includes 192.168.2.0 - 192.168.5.0, route that to null0, and it will be advertised via EIGRP. Try this via R1:
R1(config)#ip route 192.168.0.0 255.255.252.0 null0 R1(config)#ip route 192.168.4.0 255.255.254.0 null0 R1(config)#router eigrp 1 R1(config-router)#network 192.168.0.0 0.0.7.255
When you do this, R4 will be able to route to 192.168.3.0/24 and 192.168.5.0/24 without a default route like you wanted, but there will be extra subnets in there as well. If you wanted precisely just the 3 and 5 network, you would have to use redistribution with a distribute-list filter.
Discard route (null0) works, I tested it successfully, in addition to route filtering tools like distribute-list and redistribution to propagate static routes to other EIGRP neighbors.
I’m really happy that you have reinforced my understanding on “network” cmd which is used to activate / enable IGP on INTERFACES that fall within the “network” range. To recap, IGP will not advertise it unless it’s pointed to either a physical or virtual interface. and if it’s not pointed to an interface then route filtering mechanism (distribute-list or redistribution) is the way to go. Am I correct?
The reason I wanted to make it work with “next hop IP” was because I thought whatever you have in your RIB table can be advertised using “network” cmd. Apparently not! IGP is interface / link based.
Andrew, I can’t THANK YOU enough for stepping in and helping me out on this very fundamental yet important concept.
You are correct in your understanding. The network statement tells EIGRP which interfaces should participate in the routing process, not which routes to advertise. Note: The Network command behavior in BGP is quite different. This will cause any matching route in the RIB to be advertised.
It is a subtle, but key distinction.
Using EIGRP static neighbor, is it possible to run EIGRP over plain IPSEC tunnel?
This is possible yes since all EIGRP packets will be unicast:
Keep in mind that your EIGRP neighbors do have to be in the same subnet.
I tried this config in Packet tracer and GNS3. Everything works until I add the eigrp. Then the adjacency never forms. Do we need to add the broadcast command to the frame relay?
When you add the EIGRP implementation, make sure you are configuring the static neighbour relationship correctly.
frame-relay map <em>protocol protocol_address</em> [broadcast] command forwards broadcasts to the specified address when multicast is not enabled. By using static neighbour relationships for EIGRP we are inherently using only unicast so this command would make no difference.
Check your config again and if you still have problems, copy and paste the relevant parts of your config so we can take a look.
I hope this was helpful!
Is there a way to use both eigrp unicast and multicast packets at the same interface ?
When you set up a static neighbour on an EIGRP enabled interface of a router, the interface changes to using unicast EIGRP updates to the specific neighbour. This DISABLES multicast updates. You cannot have both unicast and multicast functioning on the same interface. They are mutually exclusive.
I hope this has been helpful!
Qestion1: My Router simulator not support command
clock rate 200000 but it accept
clock rate threshold 200000
R1(config-if)#clock rate 200000 ^ % Invalid input detected at '^' marker. R1(config-if)#clock rate ? threshold Configure the threshold clockrate limit for DTE interfaces R1(config-if)#clock rate threshold 200000
Q2: Not sure why I’m not get the status active on below command ?
R1#sh frame-relay map Serial0/0 (up): ip 192.168.12.2 dlci 102(0x66,0x1860), static, CISCO, status deleted
In order to understand this, we need to understand the concept of Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE).
Serial connections are usually used for WAN connections using some point to point technology such as Frame Relay, or PPP. When a router connects with a serial cable, it usually connects to some box that the telco brings to the customer premises. In such a scenario, the DCE is the telco box, and the DTE is the router. The clock rate can only be configured on the DCE. The DCE sends the clock rate to the DTE, and this determines the speed of the link. The DTE can be configured with a clock rate threshold, which simply specifies the minimum clock rate that it will accept from the DCE.
Now when using real Cisco devices in a lab environment, if you want to connect them using serial connections, you need those DCEs in between them to provide the clock rate. However, in order to avoid having to connect additional equipment, it is possible to connect two Cisco devices back to back over their serial cable, using a special DTE/DCE cable.
In this case, one of the two routers must play the role of the DCE and provide the clock rate. Notice how the cable is labelled DCE, and DTE? The router on the DCE side must configure the clock rate, while the one on the DTE side must receive the clock rate. If you are on the DTE side, then the router will not have the
clock rate 200000command available, but will have the
clock rate thresholdcommand available.
Note that this behaviour is observed only for physical equipment. If you are using GNS3, then both DTE and DCE don’t have any effect. You should be able to configure both ends of the connection with a clock rate. Even in the lesson, Rene configures both ends in this manner. Even if you don’t set up a clock rate, the link should still function.
Can you share with us what simulator you are using? It may be that the behaviour has changed as updates to simulators are being made.
This could be due to many things. It may be the simulator it may be a configuration issue. Take a look at this Cisco Community Thread which includes some solutions that various users have shared.
You’ll have to do a bit of troubleshooting on this one as you may need to reconfigure from scratch. Let us know how it goes!
I hope this has been helpful!