Ripng Ospfv3 And Eigrpv6 In Ipv6 Information Technology Essay

Ripng Ospfv3 And Eigrpv6 In Ipv6 Information Technology Essay A working model of the purpose is implemented in Packet Tracer and it illustrates how routing can be achieved between to dissimilar routing domains. It highlights both positive and negative aspects like full visibility and potential routing loops consequently. Findings Access lists can be used to avoid routing loops. More study is needed when OFPF is redistributed into RIP-EIGRP combination. Originality/value this paper addresses how different routing protocol domains can be interconnected and enjoy the full visibility of routers that belongs to different routing protocols Keywords EIGRPv6, RIPng, OSPFv3, redistribution, Administrative Distance, Access list, routing loops Introduction Though IPv4 is proved as one of the dominant network layer protocol which has been in use for last 3 decades since its development in 1981 (RFC 791), people still find a need for an enhanced and better protocol due to the ever growing networks. When IPv4 address scheme was made, developers did not give a thought that internet would explode and expand too rapidly as we see the current picture of networks today. To slow down the depletion of address space, IPv4 protocol was further updated in 1993 and started using as classless (CIDR) (RFC 1519) which was failed to be adequate enough as a long term solution for conserving IP addresses. As the architecture of IPv4 has been subjected to changes, so the underneath routing protocols like RIP, OSPF, IGRP, EIGRP, BGP, IS-IS etc. are also been updated or reformed in order to have better routing and converged networks. In 1994, NAT was came up with public address and private address concept and succeeded to a great extent in conserving the IPv 4 addresses (RFC 1631). A report generated by IANA predicted that IPv4 would completely run out of available addresses by 2011 (Potaroo, 2011). In 1998 December, a new internet protocol, IPv6, is proposed with Expanded Address Capabilities, support for hierarchy in addressing, simplified header format and support for real-time services like IPTV (RFC 2460). Just like in IPv4, IPv6 (routed protocol) is also dependent on routing protocols to route the packets. Since 1997, networking groups started developing routing protocols to support IPv6 and they successfully standardized RIPng, OSPFv3, EIGRPv6, BGPv6 and IS-ISv6 in the subsequent years. These protocols are developed for 128 bit address and better security, without having much difference to their counterparts in IPv4. We cannot expect entire network to be operated by a single type of dynamic routing protocol. Depending upon size of network and requirements, administrator may choose relevant routing protocol still maintaining full connectivity among the nodes in network. The possible solutions are using static routes or deploying mutual redistribution among different protoc ol domains. As IPv4 routing protocols, RIPv2, OSPFv2 and EIGRP are well established, there are minimal redistribution issues among them. Whereas in case of IPv6 there is good amount of scope to understand and research on practical issues that arise when mutual redistribution is applied among them. Following sections of document deals with review of RIPng, OSPFv3 and EIGRPv6 individually and a practical implementation in packet tracer is shown. Later sections demonstrate how Administrative Distance (AD) of a dynamic routing protocol create loops or route to infinity and how access-list can be applied in order to avoid them. RIPng RIPng is developed in 1997 and it uses Ford-Fulkerson algorithms. And nevertheless to mention, RIPng is a distance vector protocol which depends on route on rumor, just like its earlier versions. RIPng is best suited for smaller size networks having hop count limited to 15. Beyond 15, any router would be considered as unreachable (RFC 2080). For every 30 seconds, entire Database of routing information is being exchanged and this could be keep networks always processing data. It uses hold down timer prevent route loops when a router or a particular interface of a router, or a network goes down. Split horizon is another concept which is enabled by default in cisco routers help preventing routing loops. Trigger updates are generated when there is a change in the topology to have better convergence. One of the reasons for slower convergence when compared to link-state routing protocols is when an update is being multicasted to the neighbors, first they sniff the packet, analyze and then make changes to TTL field, metric and then forward the packet to next hop. Because of this update packet spends notable amount of time at every node and hence convergence is slower as shown below. Fig: forwarding process in RIPng The main drawbacks of this protocols is higher convergence time, limited number of router in routing domain and high amount of traffic for administration and maintenance. Below is another screenshot from the working model which depicts the RIPng routing domain. OSPFv3: RFC2740 is proposed and standardized for OSPF that supports IPv6 networks in 1999. As its previous versions, OSPFv3 came up with many of its fundamental concepts like support for areas, flooding, and algorithm (Dijkstra) for calculating shortest path first (SPF), Designated and Backup Designated router selection intact. Changes are done to accommodate new IP address format which is 128 bit one. OSPF in IPv6 networks run on per-link basis where as it is per-IP-subnet based in IPv4. And the main difference is authentication is removed from OSPF protocol itself as IPv6 got its own Authentication Header and Encapsulating Security Payload (RFC 2740). OSPF form adjacency with attached routers and work in areas. A router can have many instances of OSPF process and hence inter connecting more nodes which belongs to more than one area as shown in the below screenshot from the working model of packet tracer. Fig3: OSPFv3 and Inter-Area connections OSPF uses hello packets and to make sure of adjacency. For every 10 seconds, OSPF enabled router sends hello packets to neighbors and in case if does not get reply for hello in four times the hello interval that particular adjacent node is announced as dead and accordingly updates will be sent to the affected nodes only. OSPF does not process the update packet before forwarding. Hence convergence time is very low even in a big network. Even though SPF algorithm looks simple, it involves complex calculation and hence it requires large amount of resources i.e CPU memory and time. OSPF is best suited to deploy in larger networks. EIGRPv6: EIGRP is ciscos proprietary protocol and works only in cisco routers. EIGRPv6, like its previous version, uses Diffusion Algorithm (DUAL) to make network really loop-free. Though EIGRP is categorized as distance vector protocol, it carries features from link-state model and hence EIGRP deals with neighbor and topology databases. Like RIP, EIGRPv6 does not send its entire database to the adjacencies which would create lot of administrative traffic. EIGRPv6 maintains installs both successor and feasible successor routes in the topology table. Whenever the successor route goes down, within no time, it installs feasible successor into the routing table and hence convergence is very fast in EIGRPv6. It generates triggers whenever there is a change in the topology. Just like OSPF, EIGRP can run multiple instances of the process and hence work in multiple process domains. EIGRPv6 uses bandwidth and delay for calculating metric as default parameters and user can change this metric by includi ng reliability and load. Below is the screenshot of EIGRPv6 routing domain with backup routes (Netacad, 2011). Fig4: EIGRPv6 domain Redistribution: Using a routing protocol to advertise routes that are learned by some other means, such as by another routing protocol, static routes, or directly connected routes, is called redistribution (Cisco, 2011). Though it is recommended to use single routing protocol throughout the network, in some scenarios it may be required to advertise routes of a particular routing protocol domain to a different routing protocol domain, especially when organizations merge, or multiple departments merge. Every routing protocol has its own way of calculating and using metric for routing packets. RIPng uses hop count as metric, OSPF is based on Bandwidth and EIGRP use Bandwidth, delay, reliability, load and MTU to calculate metric. As metric plays key role in redistribution, it needs to be set along with CLI commands of redistribution. Care must be taken to advertise correct metric while redistributing. Following is the screenshot from working model. For illustration purpose let us focus on redistribution between EIGRP and RIP routing protocol domains. Fig: Mutual redistribution between EIGRPv6 and RIPng Routers in the EIGRP domain neither reach nor have the visibility of routers deployed in RIP domain. The common point between these routing domains is called edge router and this router run both RIPng and EIGRPv6. We need to enable mutual redistribution on these edge routers. When we configure the edge router with following configuration, routes of RIP protocol domain will be learned by routers in the EIGRP protocol domain with the specified metric. In the same way when we issue the following configuration on the edge router, routes of EIGRP will be distributed into RIP protocol domain and RIP speaking routers learns about EIGRP routes with specified metric. We can find if redistribution successfully imported routes into adjacent routing domain by observing the route entries of IPv6. All native routes are either marked as C or D representing directly connected and EIGRP routes respectively. Whereas distributed routes are marked as EX exterior EIGRP routes with administrative distance of 170 and calculated metric to the respective network. The same can be observed in the following screenshot. Each and every router in both the domains has full visibility to any other router and the same can be checked in the working model of packet tracer using ping command. In the same way multi-area OSPF protocol domain is configured with the below shown configuration having Area0 as backbone area and Area1 and Area2 are connected to backbone area on both the sides. Now configure mutual redistribution between OSPF into RIP. Routes should be updated accordingly and full connectivity must be established between any two nodes in the packet tracer. When OSPF routes are redistributed into a system having RIP and EIGRP, all the routers are not converged and formations of routing loops are suspected. This will be discussed in the following sections. Note: After launching the packet tracer, it is recommended to wait for 1-2 minutes before pinging any node as it takes some time for converging. Administrative Distance contributing to routing loops: As each dynamic routing protocol has its own way of calculating metric, they cannot be used to compare routes. This can be taken care by Administrative Distance as it represents the degree of reliability of a route. Most preferable routes are chosen based on the AD. Lower the AD, better the reliability and precedence will be given to that route. Static routes got preference over any other route as AD for static route is 0. In the same way Interior EIGRP got AD of 90, OSPF is of 110, RIP is of 120 and finally Exterior EIGRP is of 170. A close observation of EIGRP domain says that it got redundant paths introducing possibility for routing loops. R2 and R4 learn about network 2006::0/64 (which is highlighted in red) through RIPng and advertise this information into EIGRP domain when redistribution is applied. Using EIGRPv6, R2 learns about network 2006::0/64 from R1 or R4 and R4 learns the same network from R1, R5 or R2. As EIGRP has less Administrative Distance (90) than RIP (120), the EIGRP route is the one used in the routing table causing routing loop. Even techniques like split horizon is used, still these networks suffer from convergence problem. When EIGRP is redistributed into RIP this problem gets more worsen as R3 learns about 2006::0/64, which is a directly connected network, from other routers. Solution to this problem is using access lists to deny routing updates of 2006::0/64 into its own routing domain i.e RIP. Following shown configuration applied on both R2 and R4 describes how to set access-list. After access lists are applied on edge routers, both domains become fully converged with full reachability. Insufficient route updates will happen when redistribution is applied between RIP and OSPF domains. Potential reasons for this problem are yet to be known and further study is required. Packet tracer 5.3 does not support tracert for IPv6 networks and sometimes it causing the application to crash. CONCLUSION: In the stand still mode, each routing domain is fully converged and any node can ping any other node inside the routing domain. When RIP and EIGRP are mutually redistributed into each other, potential route loops and insufficient route tables are observed because of Administrative Distance. These problems are attended by using access list with permit and deny commands. After applying access lists on edge routers, EIGRP and RIP are fully converged and full connectivity is established. Insufficient route tables are observed with OSPF redistribution into RIP and the causes of this problem are yet to be studied. Simulation tool, Packet tracer 5.3, needs to be updated as when IPv6 networks are simulated two things are observed. One, application is getting crashed frequently without any reason and the second is tracert is not supported for IPv6 networks. This model could be further used to analyze QoS and path vector protocols like BGP and IS-IS and to examine how networks behave in Autono mous Systems (AS). [1]RFC 791, http://www.rfc-editor.org/rfc/rfc791.txt, Last accessed 14-01-2011 [2] RFC 1519, ftp://ftp.rfc-editor.org/in-notes/rfc1519.txt, Last accessed 14-01-2011 [3] RFC 1631, ftp://ftp.rfc-editor.org/in-notes/rfc1631.txt, Last accessed 14-01-2011 [4] Potaroo 2010, IPv4 Address report, http://www.potaroo.net/tools/ipv4/, Last accessed 14-01-2011 [5] RFC 2460, ftp://ftp.rfc-editor.org/in-notes/rfc2460.txt, Last accessed 14-01-2011 [6] RFC 2080, ftp://ftp.rfc-editor.org/in-notes/rfc2080.txt, Last accessed 14-01-2011 [7] RFC 2740, ftp://ftp.rfc-editor.org/in-notes/rfc2740.txt, Last accessed 14-01-2011 [8] Netacad 2011, https://auth.netacad.net/idp/Authn/NetacadLogin, Last accessed 14-01-2011 [9]Cisco 2011, http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009487e.shtml, Last accessed 14-01-2011