Describe RIPng & EIGRP packet types

The RIP is the IP route exchange protocol, which uses the distance vector to measure the cost of the provided route. The RIP uses the hop count as its metric or cost. The IPv6 RIP is known as the routing information protocol next generation (RIPng) functions similarly to the IPv4 RIP version 2. This RIPng supports the IPv6 prefixes and addresses as well as introduced few new commands which are specific to the RIPng. In this section, the RIPng is described well.

3.17 RIPng

The RIPng will maintain the routing information database, which is the local route table. This local RIB comprises the lowest cost internet protocol version 6 routes learned from the other RIP routes. On the other hand, the RIPng attempt to add routes from the local RIB into a main IPv6 route table.

Even though the RIPng is the new protocol, a particular efforts were made to make the RIPng like its predecessors. The basic operation of the RIPng is nearly same and uses the similar overall operation and algorithms. The RIPng will not introduce any of the specific new features when compared to the RIP2, except those required to implement the Rip on IPv6.

The RIPng also maintains most of the enhancements which is introduced in the RIP2 and a few are implemented as it is in RIPv2, when others appear in the modified form. Given below are how the 5 extensions in the RIPv2 are implemented in the RIPng.

The next hop specification feature is maintained in the RIPng, which is implemented differently. Because of the larger size of the IPv6 addresses such as a next hop field in the RIPng Rtes format would almost as double the size of each entry. Though the next hop is the optional feature, it would be wasteful, rather when the next hop is required, that is specified in the separate routing entry.

Subnet mask specification and classless addressing support: in the IPv6 all the addresses are classless and also specified by the address as well as prefix lengths rather than the subnet mask. Hence, the field for a prefix length is offered for the each entry rather than the subnet mask field.

Authentication: The RIPng will not include own authentication mechanism. In this, it assumed that suppose the authentication or/and encryption are required, it will be offered with the help of the IPsec standard features defined for the IPv6 at the layer of the internet protocol. It is very efficient than the individual protocols, including RIPng perform authentication.

Use of multicasting: The RIPng uses the multicasts for the transmissions by using the reserved internet protocol version 6 multicast address FF02::9.

The route tag: It is the field which implements the same method as it is in the RIP2.

RIPng Messaging

There are 2 basic message types in the RIPng such as RIP response and RIP request. It is exchanged by using the UDP- user datagram protocol as with the RIP 2 and RIP 1. Though RIPng is the new protocol, it will not use the same user datagram protocol reserved port number as 520 used for the Rip or RIP 1. Rather RIPng using the well known port number- 521, semantics use is same for the port 520 in the RIP 2 and RIP 1. For convenience, some rules are listed below:

The RIP response message sent in the reply to the Rip request are sent to the source port of 521 and the destination port is equal to whatever source port that the RIP request used. The RIP request message is sent to the UDP destination port of 521. It may have the source port 521 or can use the ephemeral port number. The unsolicited RIP response message is sent with both the destination and source ports set to the 521.

To configure the RIPng, it is essential to enable the RIPng globally on individual router interfaces and on foundry device. Below are the optional configuration tasks:

1. Configure the poison reverse parameters
2. Configure default settings of the RIPng timers
3. Configure how advertises routes and foundry device learns
4. Configure which route is redistributed into the RIPng from the other sources.

RIPng packets

The RIPng packet header contains the following fields:

Version number: it specifies the version of the RIPng in which the originating router is running. It is currently set to the version 1.

Command: it indicates whether a packet is the response message or request message. The request message seeks the information for routing table of the router. The response message is sent when the request messages are received or periodically. The periodic response message is called the update message. The update message comprises the version field and command as well as the set of metrics and destinations.

The rest of a RIPng packet comprises the routing table entry list in the following fields: Route tag: it is the route attribute which should be redistributed and advertised with a route. The route tag will distinguish the external RIPng routes from the internal RIPng routes when the routes have to be redistributed over the EGP. Metric: value of a metric advertised for an address. Prefix length: it is the number of significant bits in a prefix. Destination prefix: it is the 128 bit IPv6 for a destination.

The RIPng will only use the fixed metric to choose the route. Then other IGP will use the additional parameters, including measured reliability, load and delay. The RIPng is the prone to a routing loop while the routing table is reconstructed. Specifically, when the RIPng is implemented in the larger networks which consist of many hundred routers, then the RIPng will take longer time to solve the routing loops.

The RIPng is proposed to permit routers to exchange the information to compute routes in the IPv6 enabled networks. The RIPng relies on the specific information about every network, mainly metric. The RIPng is the value between the 15 and 1, inclusive. Then the maximum path limit is the 15, which the network is considered as unreachable. The RIPng supports the multiple IPv6 addresses on every interface. This RIPng is widely deployed in the modest size network in the commercial, banking, military and much more.

3.18 EIGRP packet types

The EIGRP is the enhanced version of the IGRP. The EIGRP will use 6 different packet types, while communicating with the neighbor EIGRP routers. The EIGRP uses the reliable transport protocol to handle the reliable delivery and guaranteed of the EIGRP packets to the neighbors. This reliable and guaranteed will sounds a lot like the TCP, but the 2 is quite different in how it operates. Not the entire EIGRP packets will send reliably.

Hello packets

The hello packet is sent between the EIGRP neighbors for the recovery and neighbor discovery. It helps to keep the existing neighboring relationship alive. The EIGRP hello packet is the multicast to 224.0.0.10. It does not require acknowledgement. The EIGRP neighbor ship is maintained and discovered by the hello packets. If a router fails to get the hello packet within a hold timer, then the corresponding router can be declared as dead.

In the above example, all the 4 routers running EIGRP. The hello packet is sent between the routers to form the adjacencies. You can easily get from the above figure, that the Lizzy router is sending the 3 hello packets meant for the James, John and Jack. You can ask, that it is really useful to send 3 various hello packets on the single and is it essential that the hello packet receives the anything return. Sending three packets on the same links are not useful so rather of doing that EIGRP can send the hello packet using the multicast on the multicast access network like the Ethernet.

The hello packets no need to acknowledge since the EIGRP uses the holdown time. If the routers do not get the hello packets in the X period of time it can drop the neighbor adjacency.

As soon as you send the hello packets and get them in the EIGRP routers can try to form a neighbor adjacency. It need not require acknowledgement for confirmation that it was received. Because it need no explicit acknowledgment, the hello packets are again classified as the unreliable EIGRP packets. The EIGRP hello packets have the OP code of 5.

Update packets

The update packets are used to convey the reachability of destination. When the new neighbor is discovered, then the update packet is sent so a neighbor can build up their accurate routing as well as topology table. In that case, the update packet is unicast. In some other cases, like the link cost change, then the update is multicast. The updates are mostly transmitted reliably. So the update packets can be sent to single neighbor as well as a group of neighbors too. This packet has the routing information to whatever router that needs this information. The update packet is assigned an OP code of 1.

Query packet

The query packet is used when the EIGRP router lost its information about the specific network and it does not have any backup routes. This query packets are always multicast unless it is sent in response to the received query. In that case, it is the unicast back to a successor which originated the query. The EIGRP packets are used to reliable request the routing information. The packets are sent to the neighbors when the route is lost as mentioned above or not at all available as well as the router requires to ask about the route status for the faster convergence. If a router which sends out the does not get the response from any neighbor, then it will resend the query as the unicast packet to a non responsive neighbor. If there is no response in 16 attempts, then the EIGRP neighbor relationships are reset. The EIGRP query packet is assigned an OP code of 3.

Reply packets

The EIGRP rely packet is sent in response to the query packets. Then the reply packet is used to reliably respond to the query packet. The EIGRP reply packet is assigned an OP code of 4. The replies are unicast to the originator of the query. The replay packet indicates that the new route to a destination has been found.

Request packets

The request packet is sent in response to the query packets. Then the reply packet is used to reliably respond to the query packet. The packets are unicast to the query originator. The EIGRP reply packet is assigned an OP code of 4. This request packet is used to receive certain information from 1 or more neighbors and is used in the route server application. This type of packet can also be sent through multicast or unicast, but are transmitted unreliably.

Acknowledgment packet

The acknowledgement packets are themselves simply the hello packets which have no data. Neither hello and nor ack packets use the RTP and hence it is considered as the unreliable. The packets use to know the status of the transmission. If the hello packets are sent without any data which is recognized as an acknowledgment. The unicast address with the non zero acknowledgement number is always sent by the Acknowledgement packets. This packet will acknowledge as a receipt of update, query, and replay packets. The ACk uses the OP code as same as hello packets because, it is just a hello which contains no information, so that the OP code is 5. It packets cannot be sent through multicast.

The RIP next generation is an IGP that uses the distance vector algorithm to determine the best path to the destination, using the hop count as a metric. It is based on the routing information protocol and inherits the constraints and limitations that are in the RIP. In the above section, the RIPng features, formats, messages and configuration are explained in detail. It is important to learn about the EIGRP packet types in the network field. So that the types like query, update, acknowledgement, hello, reply and request packets will give you great knowledge about the EIGRP packets.