Question with EIGRP Timers on Interface

[Ryan Fisher]

I have a question about the "sh ip EIGRP interfaces detail" and what it shows.

When I do that command to show the interfaces hello/hold time configuration and stuff, it doesn't show me the physical interface that EIGRP is using.  The interface has a vlan assigned to it, and that vlan shows up in the detail command, but not the physical.  If I were to want to change the timers, would I then do that on the vlan interface, or on the physical interface?  I thought that I would do it on the physical, but if it's not showing up on the detail page then maybe not.

Here's the configs and output.  Thanks!

interface TenGigabitEthernet1/1/1
 description 2gb net
 switchport trunk allowed vlan 1,15,501,521,920,980
 switchport mode trunk

interface Vlan980
ip address 10.253.220.3 255.255.255.224

router eigrp 100
 network 10.0.0.0
 network 10.100.193.1 0.0.0.0
 passive-interface default
 no passive-interface Vlan980
 no passive-interface GigabitEthernet1/0/47
 no passive-interface GigabitEthernet1/0/48
 no passive-interface TenGigabitEthernet1/1/1
 no passive-interface GigabitEthernet1/0/45
 no passive-interface GigabitEthernet2/0/46

drcore01-9300stk#sh ip eigrp interfaces detail
EIGRP-IPv4 Interfaces for AS(100)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Vl980                    3        0/0       0/0          25       0/0           96           0
  Hello-interval is 5, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial <none>
  Packetized sent/expedited: 402/38
  Hello's sent/expedited: 2723923/152
  Un/reliable mcasts: 0/310  Un/reliable ucasts: 767/700
  Mcast exceptions: 50  CR packets: 49  ACKs suppressed: 26
  Retransmissions sent: 206  Out-of-sequence rcvd: 269
  Topology-ids on interface - 0
  Authentication mode is not set
  Topologies advertised on this interface:  base
  Topologies not advertised on this interface:

Gi1/0/45                 1        0/0       0/0           3       0/0           50           0
  Hello-interval is 5, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial <none>
  Packetized sent/expedited: 378/2
  Hello's sent/expedited: 2723806/2
  Un/reliable mcasts: 0/421  Un/reliable ucasts: 162/3
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 2  Out-of-sequence rcvd: 0
  Topology-ids on interface - 0
  Authentication mode is not set
  Topologies advertised on this interface:  base
  Topologies not advertised on this interface:

Gi1/0/47                 1        0/0       0/0           1       0/0           50           0
  Hello-interval is 5, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial <none>
  Packetized sent/expedited: 397/9
  Hello's sent/expedited: 2723805/2
  Un/reliable mcasts: 0/414  Un/reliable ucasts: 308/40
  Mcast exceptions: 2  CR packets: 2  ACKs suppressed: 13
  Retransmissions sent: 6  Out-of-sequence rcvd: 0
  Topology-ids on interface - 0
  Authentication mode is not set
  Topologies advertised on this interface:  base
  Topologies not advertised on this interface:

Gi2/0/46                 1        0/0       0/0          14       0/0           56           0
  Hello-interval is 5, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial <none>
  Packetized sent/expedited: 80/0
  Hello's sent/expedited: 718858/3
  Un/reliable mcasts: 0/98  Un/reliable ucasts: 82/15
  Mcast exceptions: 2  CR packets: 2  ACKs suppressed: 0
  Retransmissions sent: 5  Out-of-sequence rcvd: 0
  Topology-ids on interface - 0
  Authentication mode is not set
  Topologies advertised on this interface:  base
  Topologies not advertised on this interface:

[Martin L]

Yes, all settings and commands will go under SVI vlan interface, which is vlan 980 in your case.  To figure out How Eigrp packets got there, you could use show vlan to see what ports belong to that vlan.  it could be access or trunk port.

Regards, ML
**Please Rate All Helpful Responses **

[Joseph W. Doherty]

Actually, my understanding is, on the typical Cisco L3 switch, that command never shows a physical port, it shows the logical interface. However, the logical interface might be bound to just a single physical port and named the same.

For example, there's both a physical L2 port Gi1/0/47 and there's also a logical L3 interface, named, Gi1/0/47. Again, although named the same, they are not the same. What's makes this even more confusing, besides being named the same, both the physical port's, and logical interface's, parameters are defined under "interface Gi1/0/47".

When multiple physical ports might be bound to a logical interface, Cisco generally uses a separate logical interface declaration. So, for example, Vl980, which could have multiple access and/or trunk ports bound to it, has a SVI, "interface Vl980" defined for it. Likewise, if you had a port-channel defined, the logical interface would be Po#, and like for a SVI, you would have "interface Po#. Again, as either of these logical interfaces might have multiple physical ports bound to them, you'll need to use a separate set of commands to "see" what those ports are.

For EIGRP purposes, you would define L3 interface specific commands under the logical interface, i.e. where you'll find the IP address defined.

BTW, since Te1/1/1 is physically a trunk port, you don't need a "no passive Te1/1/1" under "router eigrp 100".

[Ryan Fisher]

Thanks for that good explanation.  I understand what you're saying.  So, if I were to set ip hello-interval eigrp 100 x and ip hold-time EIGRP 100 x settings, I would do that on the vlan980 interface and not the te1/1/1 interface, correct?

Also, I've had eigrp not work when I didn't have the physical interface defined with the no passive command.  I agree that shouldn't need to be there, but for whatever reason it wouldn't learn routes without having that physical interface in there.

Thanks for the help!

[Joseph W. Doherty]

Correct, or so I believe, although my expertise isn't with EIGRP. However, perhaps @Richard Burts will confirm.

Ditto (for Rick) on the question about passive on a trunk port.  Here too, again, I believe it should only be needed for the SVI.

[Richard Burts]

The original poster asks an interesting questions, and I appreciate my colleague @Joseph W. Doherty bringing me into the discussion. We might answer the question a bit differently if it were about a router (where physical interfaces are inherently layer 3 interfaces). But this question is about a layer 3 switch. So we approach the question a bit differently. One thing that we should keep in mind (and which will lead us to the right answer) is that EIGRP runs only on layer 3 interfaces with an IP address that is included into EIGRP. In this question Ten1/1/1 is configured as a trunk. So it is a layer 2 interface (related to that is the fact that there is no IP address associated with that interface). So in this case EIGRP can not run on the physical interface but will run on the vlan interface (the SVI).

So in both cases (the output of show ip eigrp interface, and the eigrp passive interface) it can only work on layer 3 interfaces with an IP address specified in EIGRP and not on any layer 2 physical interface.

[Ryan Fisher]

Thanks everyone for helping me understand this a lot better!

Just a bit of background, my network provider is telling me to increase the timeout because I’m getting periodic eigrp drops where I lose my network then it comes back up within a minute when eigrp sees it again. It’s a private layer 2 link that’s only between San Diego and Las Vegas, so there should really be no packet loss in my opinion. And with the hello/timer already at the defaults of 5/15, I don’t think I should have to make it much higher just because they seem to have some loss on their circuit.

But I was just looking in to what and how I would do it if I had to. Thanks again for your help!

[Joseph W. Doherty]

(Cow chips to your L2 provider's suggestion.)

Two of the more common, potential causes of lost EIGRP hello packets would be a physical drop, somewhere in the L2 link path (which bears correction by your vendor) or congestion along the L2 path which cause the packets to be dropped.

The latter can be caused by a L2 link with a guaranteed bandwidth less than your physical interface's bandwidth. If that's the case, a common solution is to shape traffic, at your egress interface, to not overrun the bandwidth guaranteed by the provider. If you see congestion with your shaper, you have the option to further manage it (although, I recall, EIGRP, implicitly guarantees itself, by default, 50% of your bandwidth).

When you use a shaper, and don't overrun you guaranteed bandwidth, a vendor might still drop your packets, but it you see that, you have a right to complain, and often have some monetary recourse too.

[Ryan Fisher]

Couldn't agree more.  I've been fighting with this for months now, and they keep saying that they don't see anything wrong with their circuit, but yet I continue to get eigrp drops periodically.  The line is used for data replication to a DR site, so there are times that it can get pretty well used, but there are times it's completely quiet, and I do get eigrp drops at those times also, so I think it is a problem with their line somewhere.

I don't think changing my eigrp timers to last longer is a good solution to this, because I'll still get packet loss, but then again I wouldn't get the route reconvergence either.  But in the end I think it's up to them to figure out why there's packet loss.

Thanks!

[Deepak Kumar]

Hi,

The question now tilled to packets drops and @Richard Burts has explained very well about the eigrp things. As EIGRP works on layer 3 interface so you can only found that settings under the layer 3 interfaces, in your case SVI. 

He also tried to explain the packet drop but seems this advice is not suitable on your network (as you said).  Let's do some more digging. First of all note down some basic details as Delayed, RTTO, Jitter, drops, etc on the link.

Add some of the monitoring tools such as PRTG,  Solerwind, etc in monitoring environment. Try to monitor with Netflow (at least exist point at your location) and ICMP as well. Also, add all middle devices (source and destination location) in the monitoring, and let's monitor for a few days. 

Analysis of both monitoring tools and eigrp up/down. I hope you will found out a clause such as high link utilization, drops, remote end device malfunctioning, etc. Also, this seems layer 3 switch so monitor the STP protocol as much you can.

[Joseph W. Doherty]

Well, assuming there is a problem with the "path", sometimes the only way to prove it is to use some kind of traffic generator that can compare sent vs. received. If received is less than sent, and the missing packets aren't at any of your interfaces, then, QED, they are lost somewhere in the provider's path.

I once spent a couple of months telling AT&T one of their links didn't seem to be quite right. They got so annoyed by my pestering, since they didn't see any problems, they went to my management (which fortunately supported me). Eventually, they found out-of-date firmware on one of their interface cards. Turns out, that firmware had a known bug, where it would start to lose packets, at a small percentage, when load approached 100%. They updated their firmware, and I no longer saw unexplained end-to-end packet loss.

What you might do, before pursuing this further, is double check what kind of bandwidth (and/or packet loss) is "guaranteed". Sometimes your contract is only for "best effort", so there really isn't any "problem" on their side.

BTW, rather than extending your timer's duration, what might work better is more hello packets during the same overall time duration. I.e. two or three times as many hellos during the same timeout period. That way, your link lost time shouldn't be any worst, for overall detection time, but with more hellos during the same interval, often it's more likely one will get to the other side. If this helps, this might be considered a temporary solution until you determine why packets are being lost, as not only EIGRP might be impacted by path packet loss.

[Richard Burts]

So the focus of the discussion has shifted from EIGRP behavior to drops on the connection between the 2 sites. @Joseph W. Doherty has made several very good points. I like his suggestion about check for mismatch in bandwidth between the device interfaces and the capacity provided on the connection by the provider. It might very well be that sometimes the interfaces are trying to push more than the circuit can carry.

Going back to the suggestion about changing the timers for EIGRP, I know that we would prefer to solve the problem of drops (or whatever is causing EIGRP to terminate the neighbor relationship) and most of us are reluctant to advocate for changing the timers. But I would like to play devils advocate here. Dropping some packets has some impact. Terminating the EIGRP neighbor relationship means that no traffic is routed between sites until the neighbor relationship is re-established. And I would think the impact of this would be greater than the impact of just dropped packets. If changing the timers would make EIGRP more stable and eliminate that additional impact would it be a good thing?

I had a similar experience with a customer who had a site to site connection. There were some packet drops on that connection and fixing the drops was not feasible. We were experiencing the symptom of EIGRP terminating the neighbor relationship and then re-establishing the neighbor relationship. We adjusted the EIGRP timers. EIGRP did become stable. We did still experience some packet drops but we no longer experienced instability because of neighbor flapping.

Changing the timers does not need to be a permanent change. Efforts can continue to solve the problem of drops (and I would suggest that eliminating network instability due to flapping neighbor might make it easier to identify and solve the drops). When the drop issue is solved then the EIGRP timers can return to their default values.

[Ryan Fisher]

Thanks for all the information. I’m traveling but will take some time soon to look over all these replies When i can. Appreciate all the information.