The EIGRP Packet Header

Believe me or not, aside from passing an exam there is another important reason why you should know what is inside the EIGRP packet header. Any hypothesis?

The Job Interview

You thought you know everything when you got the Cisco professional level certification but what happens when the interviewer asked you about what is inside the EIGRP packet header? You memorized all the configurations commands. You know what is BGP route reflector. You know how to do unequal load balancing in EIGRP. You even know how to configure fabric path, ASA firewalls, and do site-to-site VPN. You know everything you did in your laboratory but you forgot what is inside the EIGRP packet header.

“Who is going to ask me this stupid question?”

I guess an interviewer who has a doubt about your skills most especially if you put all your certifications on your resume. Funny, but it is pretty quite true.

“Is the interviewer going to judge me if I forgot what EIGRP packet header contains?”

Uhm, maybe. Depends on many reasons. We can say, the interviewer is using a bottom-up approach. In this way, it saves time and may not continue asking you further questions if you did not know the basic. Or, it can be a warm-up for more heart-pounding questions.

“What if you just forgot and neglect it during the academy session?”

I don’t think the interviewer will be interested in that kind of reason. So, if you were not able to answer, you better pray that the interview will not stop there.

I don’t want to scare you because this is just a legend. It is a traditional story popularly regarded as historical but nobody wants to confirm the truth. Anyhow, it is just my way to open up our “EIGRP Packet Header” discussion.

1. Version – This is the EIGRP header version with the current version of 2. This is a 4-bit field and it is not the same as the TLV version field.
2. Opcode – Remember the EIGRP packet types? This is how EIGRP neighbors know what kind of packet type it is. It is a 4-bit field as well like the version field and below is the equivalent values of message types:
   EIGRP Message TypeOpcode ValueUpdate1Request2Query3Reply4Hello5Reserved6-9SIA Query10SIA Reply11
3. Checksum – this is 24-bit field standard IP checksum. If the packet fails the checksum, the it is discarded.
4. Flags – This is a 32-field that defines special handling of the packet. There are 4 flag bits: INIT flag (0x01), Conditionally Received (CR) flag (0x02), Restart (RS) flag (0x04), and End-of-Table (EOT) flag (0x08). For newly discovered neighbors, the bit is set in the initial UPDATE. The INIT flag instructs the neighbor to advertise its full set of routes. CR flag is that receivers should only accept the packet if they are in Conditionally Received mode. RS flag is set in the HELLO and UPDATE packet. It is an indication that the neighbor is doing a soft restart. This In this way, adjacency is maintained. When EOT flag is set, it indicates that the neighbor has completed sending all updates. This indicates the neighbor can flush all stale routes prior to restart event.
5. Sequence – Every packet sent to the neighbor will have a 32-bit sequence number that is unique to the sender. When the value is set to 0 that means it doesn’t require any acknowledgement. 
6. Acknowledgement – this is another 32-bit field sequence number that is unique to the receiver.
7. Virtual Router ID – This is a 16-bit number that distinguishes the virtual router a packet is associated with. Any value other than listed below, will be discarded:
   
8. Autonomous System – This is the most important part in the EIGRP packet header. This is a 16-bit number which value ranges from 1 – 65535. AS should match on all EIGRP neighbors or else packet will be ignored and there will be no adjacency.