DVMRP Neighbor Discovery

DVMRP Neighbor Discovery

When DVMRP is initially enabled on a router, the DVMRP process determines if the router has any DVMRP neighboring routers. The purpose of neighbor discovery is to locate other DVMRP routers that are directly connected in order to determine the capabilities of neighbor routers and to enable a keep-alive function.

Neighbor probes are sent on all DVMRP-enabled interfaces every 10 seconds. If a previously discovered neighbor does not respond with its own keep-alive (neighbor probe) message within 35 seconds, then the neighbor is declared down. Routers that have tagged a neighbor as down are required to follow the actions listed in the following steps.

1.   Any routes that have been learned from the dead neighbor are placed in the hold-down state.

2.   If traffic was being forwarded to this router (it was a down-stream router), then this dependency should be removed.

3.   If the dead neighbor was the designated forwarder on a multi-access network, then a new designated forwarder needs to be elected.

4.   If the dead neighbor was an upstream router, then forwarding entries must be flushed.

5.   If Grafts from this neighbor need to be acknowledged, then they can be canceled.

6.   If the neighbor is the last downstream router on the interface and no other receivers are on the network, then the interface should be pruned.

Neighbors are discovered using IGMP packets with the format shown in Figure 5-13. The type code of 0x13 indicates that this a DVMRP message. Neighbor discovery packets are identified by setting the code field to 1. The checksum field in all DVMRP packets is the standard 16-bit ones compliment of the ones compliment sum of the packet.

Figure 5-13: DVMRP neighbor discovery packet format

The Generation ID field is used to determine if a neighbor router has been rebooted. When a router discovers that the generation ID field has changed, the router can assume that the neighbor has been restarted. When this occurs, the router that detected the change in neighbor generation ID flushes any prune information that it has from the neighbor and then sends a unicast copy of the routing table to the neighbor. The network in Figure 5-14 illustrates the neighbor discovery process.

Figure 5-14: Network used to illustrate the DVMRP neighbor discovery process

When DVMRP is enabled on the ethernet interface on router A, a DVMRP probe packet is sent out from that interface. Router A has not discovered any DVMRP neighbors at this point, so the neighbor list in the probe packet is empty (see Figure 5-15).

Figure 5-15: DVMRP neighbor discovery packet format, initial contents

The neighbor probe interval is 10 seconds. Router A will continue to send neighbor probe packets with an empty neighbor list until DVMRP is enabled on the ethernet interface of router B. Assume DVMRP is enabled on router B, which receives a neighbor probe from router A before it sends its initial probe. Router B will place the IP address of router A into the neighbor list of the probe packet and then transmit the probe having the format of Figure 5-16.

Figure 5-16: Neighbor probe packet sent by router B.

When router A receives the probe from router B and detects its IP address, then router A has established a two-way adjacency with router B. When router A sends the next probe, the packet will now contain the IP address of router B, which will form a two-way adjacency with router A. Once the two-way adjacency has been formed, the routers can exchange their routing information.

The neighbor discovery process also determines if any DVMRP enabled routers are directly attached to any of the router’s interfaces. If no neighbors are discovered, then the network is a leaf network, meaning that no other DVMRP routers are on the network that will forward the multicast traffic. On leaf networks, the router only needs to consult the IGMP tables to determine if any receivers for a particular multicast group are on the network. For non-leaf networks, networks on which there is a DVMRP neighbor, other techniques are required to determine if multicast traffic needs to be forwarded.