Labs on ROUTE: EIGRP - Solution
EIGRP Lab | EIGRP Lab - Answers
We continue the study lab for the ROUTE exam of the course CCNP.
I thought to combine the answers to the tasks of the past labs with the lab on OSPF, but this topic is already so large that, I'm afraid, as if everyone read it to the end. There will be a lot of configs, screenshots from Wireshark and the wilds of technology, but all this is just to better illustrate the internal logic of EIGRP, without understanding which this exam is impossible to pass.
')
Future, former and present CCNP, welcome under kat!
I suggest, going through the points of the labs, to consider all possible options and reasons, and not to go purposefully to the well-known conclusion. The same problem can cause several things, and, anyway, you need to know everything - after all, there is still a TSHOOT exam.
For convenience, I will repeat here the topology of the labs from the last post:
1. Why can't the Hub router establish an EIGRP neighborhood with Spoke 2? Fix it.
Indeed, the show ip eigrp neighbors command shows that a neighborhood with four routers has been established, but among them there is no Spoke 2 with the address 192.168.100.3:
Does the traffic go between two routers?
Walks There is a connection, the EIGRP neighborhood does not. Need to watch interfaces.
According to the Frame Relay Switch data, the DLCI 203 leads to Spoke 2 from the Hub. We also see that all Frame Relay connections use the subinterfaces of the Serial 0/0 port. Check which DLCIs are assigned to which of the subinterfaces.
Yeah, we see that the Serial0 / 0.202 subinterface leads to Spoke 2, this subinterface is multipoint, and the connection to Spoke 1 also hangs on it. There are no filters on the interfaces. Let's look at the EIGRP settings.
We see that Spoke1 is specified as a static neybor on the Serial0 / 0.202 interface. Why then is Spoke2 not dynamically located?
It's all about the features of the work of EIGRP with static neyborami. By default, EIGRP sends Hello multicast packets, directing them to all routers that work with EIGRP. But when a neybor is specified statically, the router starts sending unicast EIGRP packets, directing them only to those devices that are configured as neybor. Multicast packets on this port are no longer sent.
This is the reason why it is impossible to establish a neighborhood with Spoke2. Sending a unicast Spoke1 packet, the Hub router does not send a multicast from the Serial0 / 0.202 interface and does not accept it. The second neybor remains without communication.
To fix this, you can either configure the second nibor statically, or remove the first. I suggest to go first option:
Neighborhood set, everything is in order.
2. How to view the Hello timer on the Serial0 / 0.202 interface of the MainOfficeHub router? Which team see the Hold Timer value?
The standard show ip eigrp interfaces command does not help here:
To it you need to add the keyword details.
Here you can see that multicasts are disabled on this interface and unicast packages are used to “communicate” with neyborami.
But I don’t know how to look at the Hold timer :-) The only option: often and often enter the show ip eigrp neighbors command and, by changing the Hold value of the timer, knowing the Hello value, guess the Hold value. So if someone tells me the correct way to find out this information, I will be very grateful.
3. Will EIGRP lose its Spoke router neighborhood if I change the Hello value of the timer on the Hub router for 5 seconds? And if in 120 seconds? What will be the value of the Hold timer in Hub Router, if you put Hello an interval of 5 seconds? How to check it?
For EIGRP, it is not necessary that the neybor timers match; it is enough that Hello packets arrive before the Hold timer expires. Hello, the default interval depends on the type of interface and encapsulation, so for serial interfaces with bandwidth T1 or lower, Hello is 60 seconds.
Therefore, if you put Hello an interval of 5 seconds on the Serial 0 / 0.202 interface, for example, the neighborhood will remain. And if 120 is not.
An interesting nuance: Hold timer for our new Hello value, you need to look at the router-nEbor. By default, the value of the Hold timer is three times the value of the default Hello, and the Hold value is announced by the router to its neighbor. As if telling him: if Hello does not come from me during this period of time, consider me dead. But while changing the Hello timer, the Hold value does not automatically change:
Because the value of the Hold timer on Spoke 1, for example, never drops below 170:
In such a situation, however, confirmation of the death of the Hub of the Spoke 1 router will have to wait too long. Therefore, it makes sense to reduce this waiting time:
This exercise illustrates the feature of setting up EIGRP timers: when you specify Hello interval on an interface, you really specify how often EIGRP Hello packets are sent through this interface. But when you configure the Hold timer, it does not mean that you change the time your router will expect Hello packets from neybor from this interface. This means that you change the time that the neybor from this interface will wait for Hello packages from you.
4. Now the Spoke3 interface of the router and the router's Hub subinterface are located on the network 192.168.101.0/29 and have the addresses .1 and .2, respectively. If I change the address mask of the Spoke interface of the router to / 30, will the EIGRP neighborhood remain?
Another interesting nuance: to establish an EIGRP neighborhood, the neybor interfaces do not necessarily have to be on the same network. It is enough that each of them considers that the address of the dialer is in its network. Therefore, with this change, the neighborhood will continue:
5. 10.10.10.10 and 20.20.20.20 - the loopback addresses of the interfaces of the routers Spoke 1 and Spoke 2, respectively. Both networks are visible on the Hub router, but Spoke 1 does not see the network 20.20.20.20, and Spoke 2 does not see 10.10.10.10. At the same time, they see the other networks (for example, the 30.30.30.30 network of the Spoke 3 router) normally. Why is this and how to fix this situation?
Indeed, the Spoke 1 router sees all networks except the networks of the Spoke 2 router, and the Spoke 2 router sees all the networks except the networks of the Spoke 1 router. Because of what could happen?
The first assumption: filtering routes. We look:
No filtering. Look further: all the information about the routes both of these Spoke routers receive from a single Hub router. But there is no filtering there - we already looked at its router eigrp 100 section. What else could be the reason that routes are announced so selectively?
The reason for this is that EIGRP is a distance vector protocol. He does not know the whole topology, he knows only some kind of metric and direction to the network (next hop router). In these circumstances, distance vector protocols are much easier to obtain a routing loop, and they all use three mechanisms to prevent such loops: Route Poisoning, Holddown Timer, and Split Horizon. Remember how Split Horizon works? The router does not announce the network through the interfaces through which he learned about them.
Now look at our topology. Spoke 1 and Spoke 2 routers are connected to the Hub via a single multipoint subinterface: Serial0 / 0.202. According to the rule of Route Poisoning, the Hub router does not announce through it those networks that he learned about from him. Therefore, the Hub router will not announce Spoke 1 network 20.20.20.20 - he learned about it through the same interface, albeit from another nibor.
Therefore, in order to fix this glitch, you need to turn off Split Horizon on the Serial 0 / 0.202 interface of the router Hub. At the same time, in order to minimize damage, it can be turned off for a specific instance (AS Number) of a specific protocol:
6. Spoke 1 and Spoke 2 routers are configured as eigrp stub, but the networks of their loopback interfaces are still announced by the hub router. Why does this happen and how can they not announce anything?
Spoke 1 and Spoke 2 routers, as Spoke routers rely on in the Hub & Spoke topology, are configured as stub routers with the eigrp stub command. However, notice that in the config it is displayed as eigrp stub connected summary. By default, despite the fact that you do not select these options, the router selects the stub mode, in which it does not announce anything other than connected networks and summary networks. In order for the router not to announce anything, you need to enter the command eigrp stub receive-only.
7. If the hub router loses the link to the network on 10.10.10.10, where will it send the EIGRP Query and why?
As you know, when an EIGRP router loses a path to some network, it transfers it to the Active state and starts sending EIGRP Query messages to neighbors with the words: do you know, by chance, the path to this network, because I just lost it ?
Let's see live where he will send them to Hub router if he loses the path to the network 10.10.10.10.
These are the EIGRP Query packages that the Hub router sent from the FastEthernet 0/0 and FastEthernet 0/1 interfaces, but it did not send them from the Serial 0 / 0.202 and Serial 0 / 0.204 interfaces, although they also had neybor. What is the reason for this?
The hub router does this because all the neybor on the Serial 0 / 0.202 and Serial 0 / 0.204 interfaces are configured as stub routers. Being configured as a stub, the router informs all the neybor about this, including this information in its Hello packages:
Stub routers do not make sense to send EUGRP Query, and this is logical, because they do not relay other people's networks via EIGRP, therefore, they can not provide an alternative route for the lost prefix. Because Hub router and does not send Query to all three Spoke routers.
8. How much bandwidth to a Spoke 3 bandwidth can EIGRP packets take?
One of the EIGRP features is bandwidth control. It was invented to prevent cases where a slow WAN link can be completely clogged with EIGRP messages (in the case, for example, when a new EIGRP network appears on this link or there is some big change in the network). Therefore, by default, EIGRP can occupy a maximum of half the interface bandwidth. But in the case of subinterfaces and Frame Relay, this calculation is not obvious.
Each subinterface receives as a reference bandwidth of the interface on which it is configured. So both interfaces on the Hub router: Serial 0 / 0.202 and Serial 0 / 0.204 will have a bandwidth of 1544 kbit / s. One subinterface leads to Spoke 3: Serial 0 / 0.204, and EIGRP in a data stream can occupy a maximum of half the bandwidth: 772 kbps.
For multipoint subinterfaces, EIGRP limits not only the transfer of updates through a single interface, but also the maximum load of these updates on a single DLCI. Thus, the total bandwidth of the interface is divided by the amount of DLCI in it, and from the result obtained for each DLCI, half the bandwidth is allocated for EIGRP. So for the Serial 0 / 0.202 subinterface, the maximum bandwidth of 386 kbit / s will be available for each DLCI for EIGRP.
9. EIGRP authentication is configured between the Hub router and R5, but routers cannot establish a neighborhood. In this case, on the Hub router, the neighborhood with R5 is then installed, then lost. What is the reason for this and how to eliminate it?
And indeed, a rather strange activity occurs on the Hub router, the neighborhood with 192.168.201.2 (R5) is either set or disappears:
At the same time, nothing like this happens on the R5 itself, the router does not even think of establishing a neighborhood with Hub:
What could be the reason?
On the FastEthernet0 / 1 interface of the Hub router, authentication for EIGRP neybor is configured:
The same is configured for R5:
The names of the key chain on the routers do not match, but they should not - the neighborhood is not a hindrance. The reason for the strange behavior in the lifetime on R5. This router constantly “signs” its messages with a password that is valid for the Hub of the router, but Hello will start to be signed only with April 1, 2012.
It turns out that the Hub router receives a Hello packet with the correct password, identifies R5 as a neybora (displays a line to the terminal), and tries to exchange routes with it. But R5 does not respond to such a request, because, although it sends this password, it does not accept it as a correct one. The hub router waits for a response for a while, after which it identifies R5 as a dead person (it displays a line to the terminal) and the circle closes.
In order to interrupt it, you need to remove the temporary restriction on the password on R5:
Neighborhood established.
10. ASBR has an Internet connection through the loopback 4 interface with the address 50.0.0.1/24. It is necessary to announce on EIGRP default route to this network.
(Here I complicated the task a bit: I changed the network address from 150.0.0.1/24 to 50.0.0.1/24)
To announce a default route, EIGRP supports the concept of a default network — a full-class network can be announced via EIGRP as a default gateway. West traffic for which no route is found will be routed to a router connected to this network.
But - such a network should be full-class. We have our way to the provider has the address: 50.0.0.1/24. How to be in this case?
To announce via EIGRP, we need a full-class network - you can’t get out. As a result, all traffic will be delivered to us. But then we are already free to do with him what we want, right? It is not necessary to push it into this very full-class network, we can send it with a static route, wherever we want.
Therefore - we will create another loopback interface, say, loopback 10 with a full class address: 160.0.0.1/24.
Next, create a static route on the ASBR for the default route - to the network 50.0.0.1/24 through the loopback interface 4.
(Yes, I know that is so incorrect, but what can you do - Lupbek. Consider that I indicated hext hop IP address here)
Now we define the network 160.0.0.1/24 as the default-network and announce it by EIGRP.
As a result, we get on all routers of our network, except ASBR, the default route - to the network 160.0.0.0:
And the ASBR is a static route that redirects traffic from loopback 10 (which represents the default network) to a real provider to a classless network.
11. On the Hub router, the summary route for the 192.168.100.0/22 ​​network is configured. Why is its metric set to 2169856?
In order to figure this out, we need to look at the EIGRP topology table on the Hub router.
As can be seen from the topology table, summary route 192.168.100.0/22 ​​combines routes to networks 192.168.100.0/29 and P 192.168.101.0/29. 2169856 - the smallest metric of them. For the summary route, EIGRP sets the minimum metric of all aggregated routes as a metric.
12. In connection with the automatic summation of routes, the network of the Loopback 1 interface of the Spoke 1 router and the Loopback network of the 0–3 ASBR routers are advertised as the same 172.16.0.0/16 networks. Where do you need to remove the automatic summation, so that all the network routers see them as different networks?
EIGRP connected , EIGRP auto-summary ( , ). 172.16.10.1/24 172.16.0.1/24, 172.16.1.1/24, 172.16.2.1/24 Spoke 1 ASBR , summary. , , . , auto-summary .
13. Hub . variance 2. EIGRP ( ), 15000 16000, . ?
– , , EIGRP. . , EIGRP – - , .
EIGRP , , (next hop) . DUAL, EIGRP, loop-free successor/feasible successor . loop-free, .
DUAL feasible successor . next hop, . successor/feasible successor!
EIGRP, -, . . , , , , loop-free . , , , , loop-free , , - . feasible successor.
, . , EIGRP Query . .
Hub ASBR:
, 172.16.0.0/24 , FD , AD Hub . .
, , . , , .
PS - , , , – , , .
We continue the study lab for the ROUTE exam of the course CCNP.I thought to combine the answers to the tasks of the past labs with the lab on OSPF, but this topic is already so large that, I'm afraid, as if everyone read it to the end. There will be a lot of configs, screenshots from Wireshark and the wilds of technology, but all this is just to better illustrate the internal logic of EIGRP, without understanding which this exam is impossible to pass.
')
Future, former and present CCNP, welcome under kat!
I suggest, going through the points of the labs, to consider all possible options and reasons, and not to go purposefully to the well-known conclusion. The same problem can cause several things, and, anyway, you need to know everything - after all, there is still a TSHOOT exam.
For convenience, I will repeat here the topology of the labs from the last post:
Problem solving
1. Why can't the Hub router establish an EIGRP neighborhood with Spoke 2? Fix it.
Indeed, the show ip eigrp neighbors command shows that a neighborhood with four routers has been established, but among them there is no Spoke 2 with the address 192.168.100.3:
MainOfficeHub#show ip eigrp neighbors IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 1 192.168.201.2 Fa0/1 11 00:00:03 1 3000 2 0 3 192.168.101.2 Se0/0.204 159 00:00:27 1306 5000 0 5 2 192.168.100.2 Se0/0.202 171 00:01:08 451 2706 0 3 0 192.168.200.2 Fa0/0 12 00:02:49 427 2562 0 19 Does the traffic go between two routers?
MainOfficeHub#ping 192.168.100.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/112/296 ms Walks There is a connection, the EIGRP neighborhood does not. Need to watch interfaces.
According to the Frame Relay Switch data, the DLCI 203 leads to Spoke 2 from the Hub. We also see that all Frame Relay connections use the subinterfaces of the Serial 0/0 port. Check which DLCIs are assigned to which of the subinterfaces.
MainOfficeHub#show running-config interface serial 0/0.202 Building configuration... Current configuration : 148 bytes ! interface Serial0/0.202 multipoint ip address 192.168.100.1 255.255.255.248 frame-relay interface-dlci 202 frame-relay interface-dlci 203 end MainOfficeHub#show running-config interface serial 0/0.204 Building configuration... Current configuration : 138 bytes ! interface Serial0/0.204 point-to-point bandwidth 100 ip address 192.168.101.1 255.255.255.248 frame-relay interface-dlci 204 end Yeah, we see that the Serial0 / 0.202 subinterface leads to Spoke 2, this subinterface is multipoint, and the connection to Spoke 1 also hangs on it. There are no filters on the interfaces. Let's look at the EIGRP settings.
MainOfficeHub#show running-config | section router eigrp 100 router eigrp 100 variance 5 network 192.168.0.0 0.0.255.255 auto-summary neighbor 192.168.100.2 Serial0/0.202 We see that Spoke1 is specified as a static neybor on the Serial0 / 0.202 interface. Why then is Spoke2 not dynamically located?
It's all about the features of the work of EIGRP with static neyborami. By default, EIGRP sends Hello multicast packets, directing them to all routers that work with EIGRP. But when a neybor is specified statically, the router starts sending unicast EIGRP packets, directing them only to those devices that are configured as neybor. Multicast packets on this port are no longer sent.
This is the reason why it is impossible to establish a neighborhood with Spoke2. Sending a unicast Spoke1 packet, the Hub router does not send a multicast from the Serial0 / 0.202 interface and does not accept it. The second neybor remains without communication.
To fix this, you can either configure the second nibor statically, or remove the first. I suggest to go first option:
BranchOfficeSpoke2(config-router)#neighbor 192.168.100.1 serial 0/0 MainOfficeHub(config-router)#neighbor 192.168.100.3 serial 0/0.202 MainOfficeHub#show ip eigrp neighbors IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 4 192.168.100.3 Se0/0.202 162 00:00:18 161 1449 0 3 1 192.168.201.2 Fa0/1 11 00:00:44 1 5000 2 0 3 192.168.101.2 Se0/0.204 162 00:16:11 1199 5000 0 5 2 192.168.100.2 Se0/0.202 163 00:16:52 511 3066 0 3 0 192.168.200.2 Fa0/0 14 00:18:33 345 2070 0 22 Neighborhood set, everything is in order.
2. How to view the Hello timer on the Serial0 / 0.202 interface of the MainOfficeHub router? Which team see the Hold Timer value?
The standard show ip eigrp interfaces command does not help here:
MainOfficeHub#show ip eigrp interfaces serial 0/0.202 IP-EIGRP interfaces for process 100 Xmit Queue Mean Pacing Time Multicast Pending Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0/0.202 2 0/0 336 0/15 1326 0 To it you need to add the keyword details.
MainOfficeHub#show ip eigrp interfaces detail serial 0/0.202 IP-EIGRP interfaces for process 100 Xmit Queue Mean Pacing Time Multicast Pending Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0/0.202 2 0/0 336 0/15 1326 0 Hello interval is 60 sec Next xmit serial <none> Un/reliable mcasts: 0/0 Un/reliable ucasts: 0/11 Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 5 Retransmissions sent: 2 Out-of-sequence rcvd: 0 Interface has all stub peers Authentication mode is not set Use unicast Here you can see that multicasts are disabled on this interface and unicast packages are used to “communicate” with neyborami.
But I don’t know how to look at the Hold timer :-) The only option: often and often enter the show ip eigrp neighbors command and, by changing the Hold value of the timer, knowing the Hello value, guess the Hold value. So if someone tells me the correct way to find out this information, I will be very grateful.
3. Will EIGRP lose its Spoke router neighborhood if I change the Hello value of the timer on the Hub router for 5 seconds? And if in 120 seconds? What will be the value of the Hold timer in Hub Router, if you put Hello an interval of 5 seconds? How to check it?
For EIGRP, it is not necessary that the neybor timers match; it is enough that Hello packets arrive before the Hold timer expires. Hello, the default interval depends on the type of interface and encapsulation, so for serial interfaces with bandwidth T1 or lower, Hello is 60 seconds.
Therefore, if you put Hello an interval of 5 seconds on the Serial 0 / 0.202 interface, for example, the neighborhood will remain. And if 120 is not.
An interesting nuance: Hold timer for our new Hello value, you need to look at the router-nEbor. By default, the value of the Hold timer is three times the value of the default Hello, and the Hold value is announced by the router to its neighbor. As if telling him: if Hello does not come from me during this period of time, consider me dead. But while changing the Hello timer, the Hold value does not automatically change:
Because the value of the Hold timer on Spoke 1, for example, never drops below 170:
BranchOfficeSpoke1#show ip eigrp neighbors IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.100.1 Se0/0 171 00:27:32 323 1938 0 20 BranchOfficeSpoke1#show ip eigrp neighbors IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.100.1 Se0/0 179 00:27:32 323 1938 0 20 In such a situation, however, confirmation of the death of the Hub of the Spoke 1 router will have to wait too long. Therefore, it makes sense to reduce this waiting time:
MainOfficeHub(config-subif)#ip hold-time eigrp 100 30 BranchOfficeSpoke1#show ip eigrp neighbors IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.100.1 Se0/0 25 00:30:42 323 1938 0 20 This exercise illustrates the feature of setting up EIGRP timers: when you specify Hello interval on an interface, you really specify how often EIGRP Hello packets are sent through this interface. But when you configure the Hold timer, it does not mean that you change the time your router will expect Hello packets from neybor from this interface. This means that you change the time that the neybor from this interface will wait for Hello packages from you.
4. Now the Spoke3 interface of the router and the router's Hub subinterface are located on the network 192.168.101.0/29 and have the addresses .1 and .2, respectively. If I change the address mask of the Spoke interface of the router to / 30, will the EIGRP neighborhood remain?
Another interesting nuance: to establish an EIGRP neighborhood, the neybor interfaces do not necessarily have to be on the same network. It is enough that each of them considers that the address of the dialer is in its network. Therefore, with this change, the neighborhood will continue:
BranchOfficeSpoke3#show run interface serial 0/0 Building configuration... Current configuration : 128 bytes ! interface Serial0/0 ip address 192.168.101.2 255.255.255.248 encapsulation frame-relay frame-relay interface-dlci 103 end BranchOfficeSpoke3#show ip eigrp neighbors IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.101.1 Se0/0 5 00:00:26 460 2760 0 22 BranchOfficeSpoke3#conf t Enter configuration commands, one per line. End with CNTL/Z. BranchOfficeSpoke3(config)#int s0/0 BranchOfficeSpoke3(config-if)#ip address 192.168.101.2 255.255.255.252 BranchOfficeSpoke3(config-if)# *Mar 1 00:02:39.537: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.101.1 (Serial0/0) is down: address changed BranchOfficeSpoke3(config-if)# *Mar 1 00:02:45.923: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.101.1 (Serial0/0) is up: new adjacency BranchOfficeSpoke3(config-if)#^Z BranchOfficeSpoke3#sh *Mar 1 00:02:50.487: %SYS-5-CONFIG_I: Configured from console by console BranchOfficeSpoke3#show ip eigrp neighbors IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.101.1 Se0/0 5 00:00:09 1 4500 2 0 5. 10.10.10.10 and 20.20.20.20 - the loopback addresses of the interfaces of the routers Spoke 1 and Spoke 2, respectively. Both networks are visible on the Hub router, but Spoke 1 does not see the network 20.20.20.20, and Spoke 2 does not see 10.10.10.10. At the same time, they see the other networks (for example, the 30.30.30.30 network of the Spoke 3 router) normally. Why is this and how to fix this situation?
Indeed, the Spoke 1 router sees all networks except the networks of the Spoke 2 router, and the Spoke 2 router sees all the networks except the networks of the Spoke 1 router. Because of what could happen?
The first assumption: filtering routes. We look:
BranchOfficeSpoke1#show running-config | section router eigrp 100 router eigrp 100 network 10.0.0.0 network 172.16.0.0 network 192.168.0.0 0.0.255.255 auto-summary eigrp stub connected summary neighbor 192.168.100.1 Serial0/0 BranchOfficeSpoke2#show running-config | section router eigrp 100 router eigrp 100 network 20.0.0.0 network 192.168.0.0 0.0.255.255 auto-summary eigrp stub connected summary No filtering. Look further: all the information about the routes both of these Spoke routers receive from a single Hub router. But there is no filtering there - we already looked at its router eigrp 100 section. What else could be the reason that routes are announced so selectively?
The reason for this is that EIGRP is a distance vector protocol. He does not know the whole topology, he knows only some kind of metric and direction to the network (next hop router). In these circumstances, distance vector protocols are much easier to obtain a routing loop, and they all use three mechanisms to prevent such loops: Route Poisoning, Holddown Timer, and Split Horizon. Remember how Split Horizon works? The router does not announce the network through the interfaces through which he learned about them.
Now look at our topology. Spoke 1 and Spoke 2 routers are connected to the Hub via a single multipoint subinterface: Serial0 / 0.202. According to the rule of Route Poisoning, the Hub router does not announce through it those networks that he learned about from him. Therefore, the Hub router will not announce Spoke 1 network 20.20.20.20 - he learned about it through the same interface, albeit from another nibor.
Therefore, in order to fix this glitch, you need to turn off Split Horizon on the Serial 0 / 0.202 interface of the router Hub. At the same time, in order to minimize damage, it can be turned off for a specific instance (AS Number) of a specific protocol:
MainOfficeHub(config-subif)#no ip split-horizon eigrp 100 BranchOfficeSpoke1#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 D 20.0.0.0/8 [90/2809856] via 192.168.100.1, 00:02:19, Serial0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks ! Output omitted 6. Spoke 1 and Spoke 2 routers are configured as eigrp stub, but the networks of their loopback interfaces are still announced by the hub router. Why does this happen and how can they not announce anything?
Spoke 1 and Spoke 2 routers, as Spoke routers rely on in the Hub & Spoke topology, are configured as stub routers with the eigrp stub command. However, notice that in the config it is displayed as eigrp stub connected summary. By default, despite the fact that you do not select these options, the router selects the stub mode, in which it does not announce anything other than connected networks and summary networks. In order for the router not to announce anything, you need to enter the command eigrp stub receive-only.
7. If the hub router loses the link to the network on 10.10.10.10, where will it send the EIGRP Query and why?
As you know, when an EIGRP router loses a path to some network, it transfers it to the Active state and starts sending EIGRP Query messages to neighbors with the words: do you know, by chance, the path to this network, because I just lost it ?
Let's see live where he will send them to Hub router if he loses the path to the network 10.10.10.10.
These are the EIGRP Query packages that the Hub router sent from the FastEthernet 0/0 and FastEthernet 0/1 interfaces, but it did not send them from the Serial 0 / 0.202 and Serial 0 / 0.204 interfaces, although they also had neybor. What is the reason for this?
The hub router does this because all the neybor on the Serial 0 / 0.202 and Serial 0 / 0.204 interfaces are configured as stub routers. Being configured as a stub, the router informs all the neybor about this, including this information in its Hello packages:
Stub routers do not make sense to send EUGRP Query, and this is logical, because they do not relay other people's networks via EIGRP, therefore, they can not provide an alternative route for the lost prefix. Because Hub router and does not send Query to all three Spoke routers.
8. How much bandwidth to a Spoke 3 bandwidth can EIGRP packets take?
One of the EIGRP features is bandwidth control. It was invented to prevent cases where a slow WAN link can be completely clogged with EIGRP messages (in the case, for example, when a new EIGRP network appears on this link or there is some big change in the network). Therefore, by default, EIGRP can occupy a maximum of half the interface bandwidth. But in the case of subinterfaces and Frame Relay, this calculation is not obvious.
Each subinterface receives as a reference bandwidth of the interface on which it is configured. So both interfaces on the Hub router: Serial 0 / 0.202 and Serial 0 / 0.204 will have a bandwidth of 1544 kbit / s. One subinterface leads to Spoke 3: Serial 0 / 0.204, and EIGRP in a data stream can occupy a maximum of half the bandwidth: 772 kbps.
For multipoint subinterfaces, EIGRP limits not only the transfer of updates through a single interface, but also the maximum load of these updates on a single DLCI. Thus, the total bandwidth of the interface is divided by the amount of DLCI in it, and from the result obtained for each DLCI, half the bandwidth is allocated for EIGRP. So for the Serial 0 / 0.202 subinterface, the maximum bandwidth of 386 kbit / s will be available for each DLCI for EIGRP.
9. EIGRP authentication is configured between the Hub router and R5, but routers cannot establish a neighborhood. In this case, on the Hub router, the neighborhood with R5 is then installed, then lost. What is the reason for this and how to eliminate it?
And indeed, a rather strange activity occurs on the Hub router, the neighborhood with 192.168.201.2 (R5) is either set or disappears:
MainOfficeHub# *Mar 1 01:03:20.658: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.2 (FastEthernet0/1) is down: retry limit exceeded MainOfficeHub# *Mar 1 01:03:22.974: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.2 (FastEthernet0/1) is up: new adjacency MainOfficeHub# *Mar 1 01:04:42.500: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.2 (FastEthernet0/1) is down: retry limit exceeded MainOfficeHub# *Mar 1 01:04:46.006: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.2 (FastEthernet0/1) is up: new adjacency At the same time, nothing like this happens on the R5 itself, the router does not even think of establishing a neighborhood with Hub:
IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.203.2 Fa0/0 10 01:06:39 281 2529 0 71 What could be the reason?
On the FastEthernet0 / 1 interface of the Hub router, authentication for EIGRP neybor is configured:
MainOfficeHub#show running-config interface fastEthernet 0/1 Building configuration... Current configuration : 188 bytes ! interface FastEthernet0/1 ip address 192.168.201.1 255.255.255.252 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 main-chain duplex auto speed auto end MainOfficeHub#show key chain main-chain Key-chain main-chain: key 1 -- text "qwerty" accept lifetime (always valid) - (always valid) [valid now] send lifetime (always valid) - (always valid) [valid now] The same is configured for R5:
R5#show running-config interface fa0/1 Building configuration... Current configuration : 185 bytes ! interface FastEthernet0/1 ip address 192.168.201.2 255.255.255.252 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 mychain duplex auto speed auto end R5#show key chain mychain Key-chain mychain: key 1 -- text "qwerty" accept lifetime (12:00:00 UTC Apr 1 2012) - (infinite) send lifetime (always valid) - (always valid) [valid now] The names of the key chain on the routers do not match, but they should not - the neighborhood is not a hindrance. The reason for the strange behavior in the lifetime on R5. This router constantly “signs” its messages with a password that is valid for the Hub of the router, but Hello will start to be signed only with April 1, 2012.
It turns out that the Hub router receives a Hello packet with the correct password, identifies R5 as a neybora (displays a line to the terminal), and tries to exchange routes with it. But R5 does not respond to such a request, because, although it sends this password, it does not accept it as a correct one. The hub router waits for a response for a while, after which it identifies R5 as a dead person (it displays a line to the terminal) and the circle closes.
In order to interrupt it, you need to remove the temporary restriction on the password on R5:
R5(config)#key chain mychain R5(config-keychain)#key 1 R5(config-keychain-key)#no accept-lifetime 12:00:00 Apr 1 2012 infinite R5(config-keychain-key)# *Mar 1 01:14:01.048: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.1 (FastEthernet0/1) is up: new adjacency Neighborhood established.
10. ASBR has an Internet connection through the loopback 4 interface with the address 50.0.0.1/24. It is necessary to announce on EIGRP default route to this network.
(Here I complicated the task a bit: I changed the network address from 150.0.0.1/24 to 50.0.0.1/24)
To announce a default route, EIGRP supports the concept of a default network — a full-class network can be announced via EIGRP as a default gateway. West traffic for which no route is found will be routed to a router connected to this network.
But - such a network should be full-class. We have our way to the provider has the address: 50.0.0.1/24. How to be in this case?
To announce via EIGRP, we need a full-class network - you can’t get out. As a result, all traffic will be delivered to us. But then we are already free to do with him what we want, right? It is not necessary to push it into this very full-class network, we can send it with a static route, wherever we want.
Therefore - we will create another loopback interface, say, loopback 10 with a full class address: 160.0.0.1/24.
ASBR(config)#int loopback 10 *Mar 1 01:42:07.148: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10, changed state to up ASBR(config-if)#ip address 160.0.0.1 255.255.255.0 Next, create a static route on the ASBR for the default route - to the network 50.0.0.1/24 through the loopback interface 4.
ASBR(config)#ip route 0.0.0.0 0.0.0.0 loopback 4 (Yes, I know that is so incorrect, but what can you do - Lupbek. Consider that I indicated hext hop IP address here)
Now we define the network 160.0.0.1/24 as the default-network and announce it by EIGRP.
ASBR(config)#ip default-network 160.0.0.0 ASBR(config)#router eigrp 100 ASBR(config-router)#network 160.0.0.0 As a result, we get on all routers of our network, except ASBR, the default route - to the network 160.0.0.0:
MainOfficeHub#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 192.168.200.2 to network 160.0.0.0 ! Output omitted D* 160.0.0.0/16 [90/158720] via 192.168.200.2, 00:01:19, FastEthernet0/0 MainOfficeHub#ping 50.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 50.0.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/149/465 ms And the ASBR is a static route that redirects traffic from loopback 10 (which represents the default network) to a real provider to a classless network.
11. On the Hub router, the summary route for the 192.168.100.0/22 ​​network is configured. Why is its metric set to 2169856?
In order to figure this out, we need to look at the EIGRP topology table on the Hub router.
MainOfficeHub#show ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(192.168.200.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 30.30.30.30/32, 1 successors, FD is 2297856 via 192.168.101.2 (2297856/128256), Serial0/0.204 P 10.0.0.0/8, 1 successors, FD is 2297856 via 192.168.100.2 (2297856/128256), Serial0/0.202 P 192.168.100.0/22, 1 successors, FD is 2169856 via Summary (2169856/0), Null0 P 192.168.100.0/24, 1 successors, FD is 2169856 via Summary (2169856/0), Null0 P 192.168.100.0/29, 1 successors, FD is 2169856 via Connected, Serial0/0.202 P 192.168.101.0/24, 1 successors, FD is 4168960 via Summary (4168960/0), Null0 P 192.168.101.0/29, 1 successors, FD is 4168960 via Connected, Serial0/0.204 P 20.0.0.0/8, 1 successors, FD is 2297856 via 192.168.100.3 (2297856/128256), Serial0/0.202 P 160.0.0.0/16, 1 successors, FD is 158720 via 192.168.200.2 (158720/156160), FastEthernet0/0 P 192.168.200.0/24, 1 successors, FD is 28160 via Summary (28160/0), Null0 P 192.168.200.0/30, 1 successors, FD is 28160 via Connected, FastEthernet0/0 P 192.168.201.0/24, 1 successors, FD is 28160 via Summary (28160/0), Null0 P 192.168.201.0/30, 1 successors, FD is 28160 via Connected, FastEthernet0/1 P 192.168.202.0/24, 1 successors, FD is 30720 via 192.168.200.2 (30720/28160), FastEthernet0/0 P 192.168.203.0/24, 1 successors, FD is 33536 via 192.168.201.2 (33536/30976), FastEthernet0/1 P 172.16.0.0/16, 1 successors, FD is 158720 via 192.168.200.2 (158720/156160), FastEthernet0/0 via 192.168.100.2 (2297856/128256), Serial0/0.202 As can be seen from the topology table, summary route 192.168.100.0/22 ​​combines routes to networks 192.168.100.0/29 and P 192.168.101.0/29. 2169856 - the smallest metric of them. For the summary route, EIGRP sets the minimum metric of all aggregated routes as a metric.
12. In connection with the automatic summation of routes, the network of the Loopback 1 interface of the Spoke 1 router and the Loopback network of the 0–3 ASBR routers are advertised as the same 172.16.0.0/16 networks. Where do you need to remove the automatic summation, so that all the network routers see them as different networks?
EIGRP connected , EIGRP auto-summary ( , ). 172.16.10.1/24 172.16.0.1/24, 172.16.1.1/24, 172.16.2.1/24 Spoke 1 ASBR , summary. , , . , auto-summary .
MainOfficeHub#show running-config | section eigrp 100 router eigrp 100 variance 5 network 192.168.0.0 0.0.255.255 auto-summary neighbor 192.168.100.3 Serial0/0.202 neighbor 192.168.100.2 Serial0/0.202 MainOfficeHub#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 192.168.200.2 to network 160.0.0.0 172.16.0.0/24 is subnetted, 4 subnets D 172.16.10.0 [90/2297856] via 192.168.100.2, 00:05:57, Serial0/0.202 D 172.16.0.0 [90/158720] via 192.168.200.2, 00:05:53, FastEthernet0/0 D 172.16.1.0 [90/158720] via 192.168.200.2, 00:05:53, FastEthernet0/0 D 172.16.2.0 [90/158720] via 192.168.200.2, 00:05:53, FastEthernet0/0 ! Output omitted 13. Hub . variance 2. EIGRP ( ), 15000 16000, . ?
– , , EIGRP. . , EIGRP – - , .
EIGRP , , (next hop) . DUAL, EIGRP, loop-free successor/feasible successor . loop-free, .
DUAL feasible successor . next hop, . successor/feasible successor!
EIGRP, -, . . , , , , loop-free . , , , , loop-free , , - . feasible successor.
, . , EIGRP Query . .
Hub ASBR:
MainOfficeHub#show ip eigrp topology all-links IP-EIGRP Topology Table for AS(100)/ID(192.168.200.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status ! Output omitted P 172.16.0.0/24, 1 successors, FD is 158720, serno 40 via 192.168.200.2 (158720/156160), FastEthernet0/0 via 192.168.201.2 (161536/158976), FastEthernet0/1 P 172.16.1.0/24, 1 successors, FD is 158720, serno 41 via 192.168.200.2 (158720/156160), FastEthernet0/0 via 192.168.201.2 (161536/158976), FastEthernet0/1 P 172.16.2.0/24, 1 successors, FD is 158720, serno 42 via 192.168.200.2 (158720/156160), FastEthernet0/0 via 192.168.201.2 (161536/158976), FastEthernet0/1 , 172.16.0.0/24 , FD , AD Hub . .
Conclusion
, , . , , .
PS - , , , – , , .
Source: https://habr.com/ru/post/126450/
All Articles