6 Replies Latest reply: May 8, 2016 9:40 PM by Kamlesh RSS

    Protocol-Dependent Modules in EIGRP

    Sarah

      Hello my friends,


      I found the following text which seems to explain the concept of Protocol-Dependent Modules clearly, but there's still some misunderstanding for me here. OSPF also supports IPv6, for example, but why there's no mention of PDMs there as opposed to EIGRP which always mentions it everywhere.

       

      "EIGRP supports different Network Layer Protocols, i.e IPv4, IPv6, IPX and AppleTalk (Though, the last two are useless now). To support all of the protocols EIGRP uses PDM for each of the protocols separately.


      The PDMs are responsible for network layer protocol-specific tasks. An example is the EIGRP module, which is responsible for sending and receiving EIGRP packets that are encapsulated in IPv4.


      The EIGRP module is also responsible for parsing EIGRP packets and informing DUAL of the new information that is received. EIGRP asks DUAL to make routing decisions, but the results are stored in the IPv4 routing table.


      Also, EIGRP PDMs are responsible for redistributing routes that are learned by other routing protocols.


      PDMs are responsible for the specific routing tasks for each network layer protocol, including:

      • Maintaining the neighbor and topology tables of EIGRP routers that belong to that protocol suite
      • Building and translating protocol-specific packets for DUAL
      • Interfacing DUAL to the protocol-specific routing table
      • Computing the metric and passing this information to DUAL
      • Implement filtering and access lists
      • Perform redistribution functions to and from other routing protocols


      When a router discovers a new neighbor, it records the neighbor’s address and interface as an entry in the neighbor table. One neighbor table exists for each protocol-dependent module, such as IPv4.


      EIGRP also maintains a topology table. The topology table contains all destinations that are advertised by neighboring routers. There is also a separate topology table for each PDM"

       

      Thanks,

      Sara

        • 1. Re: Protocol-Dependent Modules in EIGRP
          Armand wang(CCNP)

          hi,buddy:

           

          Differ dynamic routing protocol has differ mechnism.

           

          best regards

          • 2. Re: Protocol-Dependent Modules in EIGRP
            Sarah

            A little more clarification would be helpful.

             

            What mechanism do RIP, OSPF etc use for such purposes?

            • 3. Re: Protocol-Dependent Modules in EIGRP
              KhizerSaleem1992

              Hey !

               

              RIP select best path on the basis of shortest path, while OSPF select best path on the basis of High Bandwidth.

              But today's RIP is no more use cx of certain limitations, OSPF is widely use now a days.

              Some limitations of RIP are:

              Maximum Hop count is 15 only, 16th router will consider unreachable, also it consumes lot of bandwidth cx it share its whole routing table with its neighbour every 30 seconds, no subnetting and much more while OSPF have all this.

               

              Regards!

              • 4. Re: Protocol-Dependent Modules in EIGRP
                Mark Holm - 3xCCIE #34763/CCDE #2016::20

                RIP uses an updated version of the protocol for IPv6, known as RIPng. It doesn't support IPv4, so there are no need to include PDM's (or similar concepts) in the protocol. If you need both IPv4 and IPv6 with RIP, you run RIPv2 for IPv4, and RIPng for IPv6 (two separate routing instances).

                 

                Originally, the same was true for OSPF. Instead of incorporating IPv6 into OSPFv2, it was decided to develop a new OSPF version, namely OSPFv3. Originally, you were required to run one OSPFv2 instance for IPv4 and one OSPFv3 instance for IPv6. Again, they are completely separated and do not share information of any kind with each other. However, subsequent RFC's have expanded OSPFv3 to allow address-families and thus allowing it to carry IPv4 information alongside with IPv6 information. The LSA's can simply contain both IPv4 or IPv6 information. This allows you to run only one instance of OSPFv3 to support both IPv4 and IPv6. OSPFv3 always runs over native IPv6 - even when carrying IPv4 information. OSPFv3 also has some significant changes in the way that it actually do not use IP addressing information to builds its SPF, which reduces flooding in some cases. However, separate SPF calculations are run for IPv4 and IPv6, so they are essentially still separated, just under the control of the same OSPFv3 instance.

                Under the hood, IPv4 and IPv6 address families are handled through use of OSPFv3's ability to have several instances per link. The instance is referenced by a numerical value, so by using one of the values assigned by the multi-AF OSPFv3 RFC, the router can indicate which protocol (and possibly topology) the associated LSA is related to. The instance ID's are assigned in groups:

                   

                Instance IDDescription
                0IPv6 unicast (base)
                1-31IPv6 unicast
                32IPv6 multicast (base)
                33-63IPv6 multicast
                64IPv4 unicast (base)
                65-95IPv4 unicast
                96IPv4 multicast (base)
                97-127IPv4 multicast
                128-255Unassigned

                 

                If you don't specify it in your configuration, the OSPF process will use instance ID 0 for IPv6 and instance ID 64 for IPv4, as you can see here:

                 

                R1#sh ospfv3 interface gigabitEthernet 0/1.500

                GigabitEthernet0/1.500 is up, line protocol is up

                  Link Local Address FE80::F816:3EFF:FE8D:F858, Interface ID 9

                  Internet Address 10.12.1.1/24

                  Area 0, Process ID 1, Instance ID 64, Router ID 1.1.1.1

                  Network Type POINT_TO_POINT, Cost: 100

                  Prefix-suppression is enabled

                  Transmit Delay is 1 sec, State POINT_TO_POINT

                  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

                    Hello due in 00:00:03

                  Graceful restart helper support enabled

                  Index 1/2/2, flood queue length 0

                  Next 0x0(0)/0x0(0)/0x0(0)

                  Last flood scan length is 0, maximum is 0

                  Last flood scan time is 0 msec, maximum is 0 msec

                  Neighbor Count is 0, Adjacent neighbor count is 0

                  Suppress hello for 0 neighbor(s)

                GigabitEthernet0/1.500 is up, line protocol is up

                  Link Local Address FE80::F816:3EFF:FE8D:F858, Interface ID 9

                  Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1

                  Network Type POINT_TO_POINT, Cost: 100

                  Prefix-suppression is enabled

                  Transmit Delay is 1 sec, State POINT_TO_POINT

                  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

                    Hello due in 00:00:04

                  Graceful restart helper support enabled

                  Index 1/2/2, flood queue length 0

                  Next 0x0(0)/0x0(0)/0x0(0)

                  Last flood scan length is 0, maximum is 0

                  Last flood scan time is 0 msec, maximum is 0 msec

                  Neighbor Count is 0, Adjacent neighbor count is 0

                  Suppress hello for 0 neighbor(s)

                 

                For ISIS, a new set of TLV's describing IPv6 reachability were simply added to the protocol. WIth ISIS, the topology is built using IS reachability - IPv4 and IPv6 reachability is just attached to the IS itself. This allows ISIS to schedule a single SPF run to cover both IPv4 and IPv6 (assuming it is configured in single-topology mode), possibly resulting in a lower CPU utilization compared to OSPFv3 (for identical topologies).

                • 5. Re: Protocol-Dependent Modules in EIGRP
                  Sarah

                  It is a great reply, as always   Thanks!

                  • 6. Re: Protocol-Dependent Modules in EIGRP
                    Kamlesh

                    very informative indeed, such posts are not encountered very often..thankyou Sara for getting this query in the forum and Super Like to Mark for the response

                     

                    @Sara, is this part of some deeper conceptual knowledge or you trying to write a thesis

                    just wondering where this question came from...