More notes on EIGRP

By | March 27, 2015

In continuation of my last post, here I will write down about EIGRP operation a little mote.

Packets

On the wire, EIGRP is present with five types of packets:

  1. Hello and Acknowledgements (ACKs are just Hellos with the relevant bit set). They are the only EIGRP packets sent unreliably – that is, without acknowledgement. Any other packet must be acknowledged before the next one is sent
    EIGRP HELLO

    Thanks to Wireshark.org collection of captures!

  2. Updates – used to disseminate routing information. The last one in series contains the End Of Table bit set
    EIGRP Update
  3. Query / Reply packets – used in case of loss of a route to destination
    EIGRP Query

    This one is from the packetlife.net captures collection

  4. SIA-Query / SIA-Reply – used to solve SIA problems (see previous post on EIGRP)

There are several rules to the packets in general:

  • All communications start with Multicast (neighbour discovery) and then use Unicast for normal operations
  • No updates are sent until proper exchange of the Hellos (the tree-way handshake)
  • The first Update is sent empty, with the INIT bit set to 1
    EIGRP Update
  • For each route received, a poison reverse is sent to prevent any possibility of loops

In the Updates, the parameters of routes are sent in Type-Length-Value format. This provides for extensibility of the protocol. Instead of full-blown netmasks, the Updates contain Bit Counts for each route. The helps to conserve some memory the bit counts are compressed this way:

BC_c = 1 + ((BC - 1) / 8)

Route loss is reported to neighbours using Update packets. For that purpose, the DELAY of the route is set to infinity (represented by -1). Interestingly, a loss of a neighbour is simulated (in the computations) by “receiving” an Update from that neighbour with the DELAYs of all routes received from that neighbour set to infinity. That means that all these routes are effectively removed from EIGRP topology database and from routing table/routing information base. Connectivity is lost.

Notably, this might affect, by way of Fate Sharing, other [routing] protocols in the network, causing total chaos and utter destruction of someone’s weekend.

Stuck-in-active troubleshooting

Why would SIA happen? Well, I’ve already mentioned the case of lossy links last time, but it doesn’t cut it, as there are several other possibilities:

  • Links with high load – it’s a special case of lossy links, actually, as on an interface with too much load, there is a high probability of packet drop (due to buffer constraints)
  • Configuration of the Bandwidth parameter of the interface – as EIGRP would always use only a certain percentage of the configured interface Bandwidth, it might prevent it from sending Replies (or Acks) on time (read: special case of lossy link as well). This is the reason why one should manipulate Delay of the link to tweak EIGRP, not the Bandwidth.
  • Adjacency was cleared between neighbours for some reason (see next paragraph)
  • (pet peeve in the recent days) Flapping interface – each flap causes the Queries to be sent and the computation to start. There may come a situation, when there would be too much Active Queries, and the SIA timer will expire before the replies would have a chance to reach the router.
  • Any combination of those, actually.

So, of all those reasons, why would Neighbour Adjacency be cleared? A number of possible causes were given by Zaheer Aziz, Johnson Lui, Abe Martey, Faraz Shamim in the Troubleshooting IP Routing Protocols book (Cisco Press, 2002). Among them:

  • L1 and L2 problems, like Unidirectional link – the relationship won’t be formed in the first place per three-way-handshake procedure
  • Addressing mismatch, including differences in subnets, primary and secondary address and/or netmask on the interface – again, the relationship won’t form
  • Other configuration mismatches (K values, EIGRP AS number)
  • Stuck In Active. Yes. One stuck-in-active can cause neighbour relationship to be torn down, consequently causing another SIA and so on – until all network melts down and starts to slowly repair itself. The SIA Rewrite was [supposedly] created to cure this problem.
  • Something, like an ACL, blocking EIGRP packets (or even the whole of Multicast)
  • Administrator’s actions: changing metrics, adding a route filter or summarisation

    This is it for EIGRP for now, but I will return to it sometime later.

One may notice, that my posts lack configuration snippets or command outputs. Well, configurations change quickly – look at NAT configuration in ASA between versions 8.0 – 9.x or at the differences in routing configuration between versions and flavours of IOS. In the meantime, basic principles change less often or at least less dramatically. Thus, in my understanding, these general observations and notes on how thing work (or don’t) are more useful in the long run.

Denis Borchev
Follow me

Denis Borchev

Engineer at Netcube LLC
I am a networking engineer, a geek and a generally nice person=)
Computer Networking Engineer with some experience; MSc Applied CS, CCIE #53271
Denis Borchev
Follow me

Latest posts by Denis Borchev (see all)

2 thoughts on “More notes on EIGRP

  1. Pingback: More notes on EIGRP | Askbow

  2. Pingback: Some notes on EIGRP history and metrics - Askbow

Comments are closed.