This topic is to discuss the following lesson:
Yesterday I did the same lab, hehe, same results.
R2#show ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(1) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.1.1 Fa1/0 167 00:17:51 81 486 0 17 R2# *Sep 11 19:02:43.279: EIGRP: Received QUERY on FastEthernet1/0 nbr 192.168.1.1 *Sep 11 19:02:43.279: AS 1, Flags 0x0:(NULL), Seq 18/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0 *Sep 11 19:02:43.283: EIGRP: Enqueueing ACK on FastEthernet1/0 nbr 192.168.1.1 tid 0 *Sep 11 19:02:43.283: Ack seq 18 iidbQ un/rely 0/0 peerQ un/rely 1/0 *Sep 11 19:02:43.287: Handling TLV: 242 43 for 0 route: 188.8.131.52/32 *Sep 11 19:02:43.295: EIGRP: Sending ACK on FastEthernet1/0 nbr 192.168.1.1 tid 0 *Sep 11 19:02:43.295: AS 1, Flags 0x0:(NULL), Seq 0/18 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0 *Sep 11 19:02:43.299: EIGRP: Enqueueing REPLY on FastEthernet1/0 R2# nbr 192.168.1.1 tid 0 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 13-13 *Sep 11 19:02:43.303: EIGRP: Requeued unicast on FastEthernet1/0 *Sep 11 19:02:43.315: EIGRP: Sending REPLY on FastEthernet1/0 nbr 192.168.1.1 tid 0 *Sep 11 19:02:43.319: AS 1, Flags 0x0:(NULL), Seq 18/18 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 13-13 *Sep 11 19:02:43.387: EIGRP: Received ACK on FastEthernet1/0 nbr 192.168.1.1 *Sep 11 19:02:43.387: AS 1, Flags 0x0:(NULL), Seq 0/18 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 R2#show ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(1) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.1.1 Fa1/0 171 00:18:03 78 468 0 18
Very good observation of you.
what is the default hello time ?
It’s 5 seconds for LAN interfaces and 60 seconds for slow (WAN) interfaces. The holddown timer is 3x the hello timer.
In case of hybrid FR hub and spoke configuration, all with serial interfaces ( R1 is the hub router - with 2 logical sub-interfaces, one point-to-point, and another one multipoint, R2 is a spoke router for the point-to-point connection, R3,R4,R5 are the spokes for the multipoint connection). In this case, R1 point-to-point subif has different timer values (Hello: 5s) than the multipoint subif (Hello: 60s) as the latter is considered to be slower link. However all this hub-and-spoke topology is configured in one EIGRP AS (AS:100). My question is do we need to tweak the Hello/Hold Timer on point-to-point subif and make it equal to the mulitpoint subif ? Configure (hello: 60s / hold timer: 180s) on the point-to-point subif?
Moreover I have also created loopback0 interface on each router, where Hello timer is again 5s. Do I need to change loopback0 timers as well to (60s/180s) for optimal configuration?
This is an excellent question and it reveals some of the nuances of EIGRP.
When using Ethernet as the layer 2 protocol, holdown and hello timers for EIGRP don’t have to be consistent over the whole AS. Each EIGRP neighbour relationship must have its timers configured correctly, but those can be different from relationship to relationship. However there is one case where timers must be configured the same, and this is the case you describe above.
This case is when you have multiple routers on a network that form adjacencies. All those routers must have matching hello/dead timers or the adjacencies will flap. This is a common problem with EIGRP in a frame-relay hub and spoke topology like the one you are describing where an NBMA PVC does not support broadcast. In this case, like you said, the point-to-point subinterface will use the hello/dead timers of 5/15 whereas the non-broadcast PVC will use 60/180. This will cause the hub to have adjacencies with neighbours with different timers on the same physical network thus causing flapping adjacencies.
Therefore you must tweak the hello/holdown timer to be the same on all links.
As for the loopback interfaces, no you don’t have to change the timers on those interfaces because as I mentioned before, you can have multiple interfaces with different timers in the same AS. Secondly, timers on the loopbacks will not affect the whole topology anyway because there are no other EIGRP routers connected to those to require timers.
I hope this has been helpful!
Your answer is really helpful and I appreciate your time to respond me.
Thank you for clarifying my concerns.