Fundamentals, RTP & Neighbor Adjacency

Complete operational master field notes covering EIGRP advanced distance-vector operations, protocol #88 encapsulation, multicast 224.0.0.10, administrative distance hierarchy, Reliable Transport Protocol (RTP) retransmission throttling, SRTT/RTO timers, null update bidirectionality, and static vs. dynamic neighborship configuration.

👤 Author: Hrishi Pradhan

🎯 Level: Basic to Advanced

📘 Sections: 4 Theory Sections

📊 Diagrams: 4 Mermaid

1. EIGRP Protocol Mechanics, Encapsulation & Multicast

How EIGRP rides directly on IP using Protocol 88

Section 1

📌 What, Where, How & Why

EIGRP is a Cisco routing protocol that encapsulates directly inside IP (Protocol 88). It uses multicast 224.0.0.10 for neighbor discovery. Use it in enterprise networks for fast convergence, scalable designs, and unequal-cost load balancing. It solves the problem of slow periodic updates found in older protocols like RIP.

%%{init: { 'theme': 'base', 'themeVariables': { 'fontSize': '12px' }}}%% flowchart TD subgraph EIGRP["EIGRP Packet Encapsulation"] direction LR L7["Layer 7
EIGRP Control
(Hello, Update, Query, Reply)"] L4["Layer 4
RTP (Reliable Transport)
SRTT, RTO, Q-Count"] L3["Layer 3
IP Header
Protocol Number 88"] L2["Layer 2
Ethernet / Frame Relay / etc."] end L7 --> L4 --> L3 --> L2 style L7 fill:#7C3AED,color:#FFF style L4 fill:#0EA5E9,color:#FFF style L3 fill:#10B981,color:#FFF style L2 fill:#F59E0B,color:#FFF

Protocol Number 88: EIGRP messages ride directly on top of IP without TCP or UDP wrappers.
Administrative Distance (AD) Hierarchy: Internal EIGRP = 90, External EIGRP = 170, Summary = 5.
Multicast 224.0.0.10: Used for hello packets, queries, and other control traffic.
Protocol Number 88: Distinct from OSPF's 89 and RIP's UDP 520.

2. Adjacency Formation & Null Update Mechanics

Neighborship vs. full adjacency — the two-way handshake

Section 2

📌 What, Where, How & Why

Adjacency is the full bidirectional relationship between EIGRP routers. It starts with Hellos, then a Null Update verifies both sides can exchange packets reliably. Use this on all EIGRP-enabled links to ensure stable routing. It solves the problem of one-way communication causing blackholes.

%%{init: { 'theme': 'base', 'themeVariables': { 'fontSize': '12px' }}}%% sequenceDiagram participant R1 as Router A participant R2 as Router B Note over R1,R2: Step 1: Neighbor Discovery R1->>R2: Hello (224.0.0.10) R2-->>R1: Hello Reply Note over R1,R2: Step 2: Bidirectional Verification R1->>R2: Null Update (Init=1, Seq=1) R2-->>R1: ACK (Acknowledgment) Note over R1,R2: Step 3: Full Database Exchange R1->>R2: Full Update Exchange R2-->>R1: Full Update Exchange Note over R1,R2: ✅ ADJACENCY ESTABLISHED

Neighborship ≠ Adjacency: Hello discovery is only the first step.
Null Update: A blank update (Init=1, Seq=1) verifies bidirectional reachability.
ACK Required: The receiving router must acknowledge the null update to confirm both sides are reachable.
Full Adjacency: Only after successful null update exchange can full routing updates be exchanged.

3. Reliable Transport Protocol (RTP) & Timer Engineering

SRTT, RTO, Q-Count, and the retransmission logic

Section 3

📌 What, Where, How & Why

RTP is EIGRP's reliable delivery mechanism. It tracks acknowledgments, retries failed packets up to 16 times, and uses SRTT/RTO timers to manage retransmissions. Use it on all EIGRP links to guarantee critical updates are delivered. It solves the problem of lost routing updates causing network instability.

%%{init: { 'theme': 'base', 'themeVariables': { 'fontSize': '12px' }}}%% flowchart TD subgraph RTP["RTP (Reliable Transport Protocol)"] direction LR Unreliable["Unreliable Messages
Hello, ACK"] Reliable["Reliable Messages
Update, Query, Reply"] end Reliable --> Retry{"ACK Received?"} Retry -->|Yes| Done["✅ Delivery Complete"] Retry -->|No| Unicast["Retransmit via Unicast
(Up to 16 attempts)"] Unicast --> Timeout{"Timeout?"} Timeout -->|Yes| Flap["❌ Neighborship Flaps"] Timeout -->|No| Retry style Unreliable fill:#F59E0B,color:#FFF style Reliable fill:#0EA5E9,color:#FFF style Done fill:#10B981,color:#FFF style Flap fill:#EF4444,color:#FFF

SRTT: Smooth Round Trip Time – average time between sending and receiving ACK.
RTO: Retransmission Timeout – max time before retry (up to 5000ms).
Q-Count: Pending unacknowledged packets. High Q-Count = congestion or packet loss.
16 Retries: EIGRP retries up to 16 times via unicast; after that, neighborship flaps.
Default Timers: Hello = 5s, Hold = 15s (3× Hello).

4. Static vs. Dynamic Neighborship Engineering

When to use multicast discovery vs unicast peering

Section 4

📌 What, Where, How & Why

Dynamic neighborship uses multicast 224.0.0.10 for automatic discovery. Static neighborship uses unicast to a specific IP. Use dynamic on broadcast segments with multiple routers. Use static on point-to-point links or for security where you want to control exactly who peers with whom.

%%{init: { 'theme': 'base', 'themeVariables': { 'fontSize': '12px' }}}%% flowchart LR subgraph Dynamic["Dynamic Neighborship"] direction TB D1["Router A"] -->|"224.0.0.10"| D2["Router B"] D1 -->|"224.0.0.10"| D3["Router C"] D1 -->|"224.0.0.10"| D4["Router D"] end subgraph Static["Static Neighborship"] direction TB S1["Router A"] -->|"Unicast to 192.168.1.2"| S2["Router B"] end style Dynamic fill:#F8FAFC,color:#1E293B,stroke:#0EA5E9,stroke-width:2px style Static fill:#F8FAFC,color:#1E293B,stroke:#7C3AED,stroke-width:2px style D1 fill:#0EA5E9,color:#FFF style D2 fill:#10B981,color:#FFF style D3 fill:#10B981,color:#FFF style D4 fill:#10B981,color:#FFF style S1 fill:#7C3AED,color:#FFF style S2 fill:#F59E0B,color:#FFF

Dynamic (Default): Uses multicast 224.0.0.10. Scalable for broadcast segments.
Static: Uses unicast hello packets to a specific neighbor. Requires config on both sides.
Incompatibility: Static and dynamic types cannot interoperate. Both sides must match.
Use Case: Security-conscious environments or point-to-point WAN links where multicast isn't desired.