EIGRP can route more than one network-layer protocol at once, and the mechanism that makes this possible is the Protocol-Dependent Module (PDM). Each PDM handles everything specific to one particular routed protocol — building its own neighbor table, its own topology table, and interfacing with the shared DUAL algorithm — while DUAL itself remains protocol-agnostic. This guide covers exactly what a PDM does, its full list of responsibilities, how the architecture has changed since EIGRP’s early multi-protocol days, and how to verify PDM-specific tables directly on a router.
What a PDM Actually Does
EIGRP currently supports IPv4 and IPv6 through separate PDMs. Each PDM handles every task specific to its own protocol: building and parsing EIGRP packets in that protocol’s format, tracking neighbors reachable via that protocol, and feeding routing information to DUAL in a protocol-neutral form DUAL can act on regardless of which PDM it came from. This modular design is deliberate — it means adding support for an entirely new network-layer protocol to EIGRP, at least in principle, only requires writing a new PDM rather than modifying DUAL’s core loop-free path-selection logic at all.
For example, the IPv4 PDM is responsible for sending and receiving EIGRP packets encapsulated in IPv4, analyzing those packets, and informing DUAL about any new routing information they contain. DUAL then makes its routing decision — selecting the successor and any feasible successors — based on that information, and the result gets installed into the IPv4 routing table by the same PDM.
Normally, information flows from the topology table toward the routing table: DUAL evaluates the topology table’s candidate routes and installs the winning ones into the routing table. But the PDM can also carry information in the reverse direction — from the routing table into the topology table — specifically when routes are being redistributed into EIGRP from another routing protocol. In that case, the externally learned route enters through the routing table side rather than through a normal EIGRP neighbor update, and the PDM is what carries it back into the topology table so DUAL can treat it consistently with natively learned EIGRP routes, ensuring redistributed routes participate correctly in DUAL’s loop-prevention logic rather than bypassing it entirely.
The Eight Core Responsibilities of a PDM
Based on Cisco’s own EIGRP documentation, a protocol-dependent module handles the following, drawn directly from Cisco’s official EIGRP FAQ material and confirmed consistent across multiple independent technical references:
- Maintaining the neighbor table and topology table for EIGRP-enabled routers belonging to that specific protocol suite.
- Building and translating protocol-specific packets for DUAL — both constructing outgoing EIGRP packets and parsing incoming ones.
- Interfacing DUAL to the protocol-specific routing table — this is the connection point where DUAL’s computed best paths actually become installed routes.
- Computing the metric and passing that value to DUAL, since metric calculation details can vary slightly by protocol context even though the underlying composite-metric formula is shared.
- Implementing filtering and access lists specific to that protocol.
- Carrying out redistribution to and from other routing protocols.
- Redistributing routes learned by other routing protocols into EIGRP for that specific protocol suite.
- Sending and receiving EIGRP packets that carry that protocol’s data.
Separate Tables Per Protocol
A router running EIGRP for both IPv4 and IPv6 maintains entirely separate neighbor tables and topology tables for each protocol — an IPv4 neighbor table and topology table, and a completely independent IPv6 neighbor table and topology table. This separation exists because the two protocols have fundamentally different addressing, and it lets each PDM operate independently: a neighbor relationship or topology change on the IPv4 side has no direct effect on the IPv6 side’s tables, even between the same two physical routers, and even when both EIGRP processes are running on identical hardware with the identical set of physical interfaces.
When a router discovers a new EIGRP neighbor, it records that neighbor’s address and the receiving interface as an entry in the neighbor table — specifically, the neighbor table belonging to whichever PDM matches the protocol the Hello packet arrived in. The topology table, in turn, holds every destination advertised by neighboring routers for that protocol, which DUAL uses as the raw material for computing successors and feasible successors.
A Note on Legacy Protocol Support
EIGRP’s PDM architecture was originally designed with more than just IP in mind — historically, EIGRP also supported Novell’s IPX and Apple Computer’s AppleTalk network-layer protocols through their own dedicated PDMs, each maintaining independent neighbor and topology tables just like the IPv4 and IPv6 PDMs do today.
This is now purely historical. Cisco permanently removed AppleTalk and IPX/Novell support from Cisco IOS starting around IOS 12.2(13)T and completing with 15.0(1)M, as the networking industry moved almost entirely to IP-only infrastructure. No currently supported Cisco IOS release includes an AppleTalk or IPX PDM. The architectural concept remains genuinely useful today — it’s exactly what allowed EIGRP to add IPv6 support without redesigning DUAL — but IPv4 and IPv6 are the only PDMs you’ll actually encounter in a modern deployment, and any documentation referencing configuration commands for the older protocols should be understood as historical reference material rather than something applicable to current hardware.
Why This Architecture Matters
The PDM design is what let EIGRP add IPv6 support relatively cleanly, long after the protocol’s original 1992 design: rather than rewriting DUAL to understand a new addressing scheme, Cisco simply added a new PDM that handles IPv6-specific packet formats and table structures, while DUAL continues operating exactly as it always has, agnostic to which specific protocol the routing information originally came from. This is also why a router can run EIGRP for IPv4 and IPv6 simultaneously without either one interfering with the other’s neighbor relationships, timers, or topology — they’re handled by entirely separate PDMs feeding into the same underlying DUAL process, but never intermixing their protocol-specific data structures.
Verifying PDM-Specific Tables
Because each PDM maintains its own independent tables, verification commands are protocol-specific rather than universal. On Cisco IOS, the neighbor and topology tables for each protocol are checked separately:
Router# show ip eigrp neighbors
Router# show ip eigrp topologyThese two commands show the IPv4 PDM’s tables. The IPv6 equivalents follow the same ipv6 substitution pattern seen throughout EIGRP and OSPF verification:
Router# show ipv6 eigrp neighbors
Router# show ipv6 eigrp topologyRunning both sets side by side on a dual-stack router is a useful habit — a healthy IPv4 EIGRP topology doesn’t guarantee the IPv6 side is equally healthy, since the two PDMs operate as fully independent processes with their own neighbor relationships and their own potential failure points, meaning a problem specific to IPv6 addressing or configuration could go completely unnoticed if only the IPv4 tables are ever checked.
How This Compares to OSPF’s Approach
It’s worth briefly contrasting EIGRP’s PDM model with how OSPF handles the same underlying problem — supporting both IPv4 and IPv6. OSPF took a different architectural path: rather than a modular per-protocol design bolted onto a shared algorithm, IPv4 and IPv6 are handled by entirely separate OSPF versions — OSPFv2 for IPv4 and OSPFv3 for IPv6 — each running as its own independent process with its own configuration syntax, as covered throughout this site’s OSPF series.
EIGRP’s PDM approach and OSPF’s separate-version approach both achieve the same practical outcome — independent, non-interfering support for multiple network-layer protocols — but arrive at it differently. EIGRP’s DUAL algorithm and general mechanics stay identical across every PDM, with only the protocol-specific pieces (packet format, tables, metric details) varying. OSPF instead maintains two largely parallel implementations that share core concepts (areas, LSAs, SPF) but differ enough in specifics that OSPFv2 and OSPFv3 are often discussed as related-but-distinct protocols rather than a single protocol with pluggable modules.
Common Misunderstandings
Assuming EIGRP has one single topology table. Every PDM maintains its own — a router running EIGRP for IPv4 and IPv6 genuinely has two separate topology tables, not one shared table serving both protocols, and confusing this can lead to looking in the wrong place entirely when troubleshooting a protocol-specific routing issue.
Assuming AppleTalk or IPX EIGRP still exists somewhere. As covered above, both were fully removed from Cisco IOS years ago. Any reference to configuring appletalk eigrp or an IPX EIGRP process refers to hardware and software that predates any currently supported IOS release, and shouldn’t be treated as applicable guidance for a network being built or maintained today.
Confusing the PDM with DUAL itself. The PDM handles protocol-specific packet formats, tables, and metric computation; DUAL is the shared, protocol-agnostic algorithm that actually selects best paths and backup paths once the PDM has fed it the necessary information. They’re separate, cooperating components, not the same thing under different names, and conflating them makes it harder to reason correctly about where a given EIGRP problem actually originates during troubleshooting.
Frequently Asked Questions
Does EIGRP still support IPX or AppleTalk today?
No. Both were permanently removed from Cisco IOS years ago (starting around 12.2(13)T, completed by 15.0(1)M). Only the IPv4 and IPv6 PDMs remain in any currently supported IOS release.
Why does EIGRP need separate neighbor tables for IPv4 and IPv6 on the same router?
Because IPv4 and IPv6 are fundamentally different addressing schemes with independent adjacency and topology information. Keeping the tables fully separate per PDM means a change or problem in one protocol’s EIGRP process has no direct effect on the other.
What’s the difference between the topology table and the routing table in EIGRP?
The topology table holds every route a neighbor has advertised for a destination, evaluated by DUAL to select the best path (successor) and any qualified backups (feasible successors). The routing table holds only the winning routes DUAL has actually selected for active use — it’s the practical output of what the topology table and DUAL calculated.
Can information flow from the routing table back into the topology table?
Yes, in one specific case: when routes are redistributed into EIGRP from another routing protocol, they enter through the routing table side, and the PDM carries that information back into the topology table so DUAL can treat those redistributed routes consistently alongside natively learned EIGRP routes.
Why does EIGRP’s PDM architecture matter for understanding IPv6 support?
It explains how EIGRP added IPv6 support without a fundamental redesign — a new PDM was added to handle IPv6-specific packet formats and tables, while DUAL itself remained unchanged and protocol-agnostic, exactly the design flexibility PDMs were built to provide.
Does OSPF use a similar module-based system for supporting IPv4 and IPv6?
No, OSPF takes a different approach entirely — it uses two separate protocol versions, OSPFv2 for IPv4 and OSPFv3 for IPv6, each running as its own distinct process rather than sharing one algorithm through pluggable protocol modules the way EIGRP’s PDM architecture does. Both approaches solve the same basic problem, but the underlying design philosophy differs meaningfully between the two protocols.
Conclusion
A Protocol-Dependent Module is what lets EIGRP handle more than one network-layer protocol using the same underlying DUAL algorithm — each PDM manages its own protocol-specific neighbor table, topology table, packet formats, and metric calculation, while DUAL stays focused purely on selecting loop-free best paths regardless of which protocol the information originated from. IPv4 and IPv6 are the two PDMs in active use today; the historical IPX and AppleTalk PDMs are long gone from any supported IOS release, but the architectural pattern they helped establish is exactly what made adding IPv6 support to EIGRP possible without reworking its core algorithm — a meaningfully different design philosophy than OSPF’s approach of maintaining two largely separate protocol versions for the same purpose.
