We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 581 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

295 New Members signed up the last 30 days!

satisfaction-guaranteed

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!


Forum Replies

  1. system says:

    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: 1.1.1.1/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.
    Thanks again. :slight_smile:

  2. It's 5 seconds for LAN interfaces and 60 seconds for slow (WAN) interfaces. The holddown timer is 3x the hello timer.

  3. Hi Rene,

    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?

    Thanks,
    Kostas

  4. Hello Kostas

    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!

    Laz

  5. Hello Laz,

    Your answer is really helpful and I appreciate your time to respond me.
    Thank you for clarifying my concerns. :slight_smile:

    Kostas

1 more reply! Ask a question or join the discussion by visiting our Community Forum