Dynamic Routing
Distance-vector-type routing protocols are principally founded on the exchange of distance vectors; that is, arrays of distances to known networks. A router learns about the existence of a network by receiving a message from its neighboring router that advertises the network. This neighbor then becomes the next hop toward this network. After a router learns about a network from one or more of its neighbors, chooses a next hop, and installs the route into its routing table, it advertises the route itself, announcing its own distance from the destination. A sanity check is performed by all distance-vector routing protocols on Cisco routers: A route learned by a routing protocol will be further advertised only if it is also placed into the router’s routing table; a router advertises only those routes used by itself. In distance-vector routing protocols, routers by definition exchange only lists of known networks and their distances. They do not exchange information about the network’s topology.An extension of the distance-vector principle is the path-vector routing protocol. Routers exchange messages about known networks and their distances, but in addition, each network is also accompanied by a list of path elements describing the path toward the network. These path elements can be theoretically anything router IDs of individual routers, area numbers, and so on.
A link-state routing protocol exchanges information about individual objects in the topology and their mutual interconnection. These objects include routers, multiaccess networks, routers on borders of areas or entire autonomous systems, and networks from other areas or from outside the autonomous system. After a router has generated a message in which it describes itself and its links to immediately neighboring objects, this message is flooded without any modification to every other router in an area. As a result, every router has exact information about the entire area’s topology:
Link state routing protocol downside—is their inability to perform route summarization, filtering, or applying offset-lists in arbitrary places in network. This is because the topological information can only be modified by its originating router, and must not be otherwise altered or filtered by any other router. Within an area, therefore, none of these operations is available. If route summarization or filtering is required, it can be accomplished only on area border routers, as these routers are in charge of carrying (that is, re-originating) information in a distance-vector fashion from one area to another.
RIPv2 Basics
RIPv2 exchanges routes by sending RIPv2 updates on each RIPv2-enabled interface based on the Update timer(update interval). A RIPv2 router advertises its connected routes, as well as other RIPv2-learned routes that are in the router’s IP routing table. RIPv2 routers do not form neighbor relationships, nor do they use a Hello protocol. Each router simply sends updates, with destination address 224.0.0.9.
A Request message is used to ask a neighbor to send a partial or a full RIP update immediately, rather than waiting for the Update timer to expire, speeding the convergence.
On Cisco routers, Request messages for full updates are sent when the RIP process is being started, a RIP-enabled interface comes up,or when the clear ip route * command is used to clear the routing table. Partial requests do not appear to be used.
RIPv2 increments the metric when sending updates; RIPng and EIGRP increment metrics when receiving updates. When Cisco RIPv2 routers learn multiple routes to the same subnet, the lowest-metric route is chosen, of course. If multiple equal-hop routes exist, the router (by default) installs up to 4 such routes in its routing table by default.
RIPv2 Convergence and Loop Prevention
Counting to Infinity - If, for some reason (usually caused by deactivated Split Horizon and race conditions in timing), two neighboring routers start mutually considering themselves as next hops toward the same destination network, each of them will derive its own metric from the metric of its neighbor.The Split Horizon is a well-known principle, stating that a network should never be advertised back over the interface that is used to reach that network, because that interface leads back to the next hop toward that route and we do not want to risk a situation where the next hop suddenly loses the route while we inadvertently trick it into believing we are providing a backup path. In the Cisco RIPv2 implementation, Split Horizon is by default activated on most interfaces, notable exceptions being physical Frame Relay and ATM interfaces.
Poisoned Reverse - a network should always be explicitly advertised as unreachable over the interface that is used to reach that network.
Route Poisoning is a mechanism used to rapidly flush a route that has become unreachable. Doing this is accomplished by advertising his route with the metric set to infinity. A router that receives an update about a network from its next hop with an infinite metric will immediately remove the route to the network through that particular next hop from its routing table.
Poisoned Reverse is an extension to the Split Horizon principle. Route Poisoning advertises a truly unreachable route to quickly flush it from routing tables.
Even though a route is removed from the routing table during a Route Poisoning procedure, RIP will still keep the route in its internal database (see the show ip rip database. The unreachable route will be flushed from the RIP internal database after Flushed after – Invalid after seconds.
Triggered updates are updates in RIPv2 that are sent in the moment of detecting a change in reachability of a network, rather than waiting for the full Update interval to expire. This update commonly carries only the changed network, without listing all other known networks.
The Holddown mechanism is to delay processing updates about a network whose reachability has become questionable, as the received updates might not yet contain up-to-date information. The router that has detected a sudden loss of reachability information for a network must not immediately accept the updates from its neighbors; rather, it must give them certain time to learn about the outage and converge to a different path.
The Invalid after timer is reset every time an update about a network from its next hop arrives, and is incremented each second. The default upper limit for the Invalid after timer is 180 seconds. After the Invalid after timer has reached the upper limit and an update about this network has not been received, the network is considered invalid, In such case, the following happens:
-Router declares the network invalid
-Router starts the Holddown timer for this network. While the timer runs (180 sec-onds by default), the router itself advertises the network with infinite metric (Route Poisoning) to force its neighbors to find an alternative route if possible. Additionally, the router locks the routing entry in its routing table, still pointing toward the former next hop. Absolutely no updates whatsoever are accepted until the Holddown timer expires.
-After the Holddown timer expires, the router unlocks the routing entry in its routing table and converges through a neighbor that offers the lowest metric route to the network.
This procedure is invoked after the reachability of a network can be neither confirmed nor refuted for a period of time. In summary, after a router puts a route into the invalid state, it advertises that route as unreachable itself. A router never updates an invalid route while the Holddown timer runs. After the Holddown timer expires and the routing entry is unlocked. However, the failed route might have been the only path to the destination.
That would cause that no-longer-invalid routing entry to linger in the routing table indefinitely, still pointing toward the previous next hop. To solve that, the Flushed after timer is used. Flushed after timer is reset every time an update about a network from its next hop arrives, and is incremented each second. If the Flushed after timer reaches its upper limit, the route is immediately flushed from the routing table. When the route is flushed (removed), any associated timers are also removed, including the Holddown timer.
Either the Flushed after timer or the Holddown timer must expire before new routing information would be used.
The default setting of RIPv2 timers on Cisco routers is 30 seconds for Update , 180 seconds for Invalid after and Holddown, and 240 seconds for Flushed after.
show ip protocols
show ip rip database // lists all RIP learned routes and all connected routes that RIP is advertising
Note in debug, the triggered update is referred as a flash update
debug ip RIPv2 //show messages that show every route in the sent and received updates
debug ip ripv2 event //displays messages when updates are sent and received, but does not display the contents of the updates.
Convergence Extras
The RIPv2 timers can be tuned with the timers basic update invalid hold-down flush subcommand under router rip. The timers should be consistent across routers, and smaller values increase the chance of transient routing loops being formed during convergence. The clear ip route * command also speeds convergence by removing all routes (not just RIP-learned) from the routing table, along with any per-route timers. Because the clear command bypasses loop-prevention features by deleting the route and timers, it can be risky, but it certainly speeds convergence. The router immediately issue RIPv2 request packets, which cause the neighboring routers to send full routing updates to the router, instead of waiting on their next update time.RIPv2 Configuration
The network command always recomputesthe network address into a classful representation. Even if a subnetwork address is entered as the network command’s parameter, the router will automatically compute the corresponding classful network’s address and store it in the configuration.To advertise the subnets of network 10.0.0.0, use no auto-summary command under router rip. Disabling the automatic summarization should be considered a mandatory part of any RIPv2 configuration. Note that RIPv2 allows for discontiguous networks, but autosummarization must be disabled for a design using discontiguous networks to work.
Cisco IOS enables the RIPv2 (and EIGRP) authentication process on a per-interface basis, referring to the key chain that holds the keys with the ip rip authentication key-chain name interface subcommand. If multiple keys are valid for signing outgoing RIPv2 packets, the key with the lowest sequence number will be used. With RIPv2, the type of authentication (clear-text password or MD5 digest) is chosen per interface as well, using the ip rip authentication mode { text | md5 }
When authentication is enabled, the maximum number of prefixes that can be advertised in a RIPv2 message is reduced by 1 to a value of 24.
RIPv2 Next-Hop Feature and Split Horizon
Cisco IOS controls the split horizon setting per interface. Split Horizon is on by default, except for Frame Relay or ATM.
The RIPv2 next-hop feature allows a RIPv2 router to advertise a different next-hop router than the advertising router. On Cisco routers, this feature is not configurable, though, and is almost unused.
RIPv2 offset lists allow RIPv2 to add to a route’s metric, either before sending an update, or for routes received in an update. The offset list also specifies which routing updates to examine by referring to a direction (in or out) and, optionally, an interface.
Route Filtering with Distribute Lists and Prefix Lists
Outbound and inbound RIPv2 updates can be filtered at any interface, or for the entire RIPv2 process. The distribution list filtering can be performed for either direction of flow(in or out) and, optionally, for a particular interface.
A RIPv2 distribute list might refer to a prefix list instead of an ACL to match routes. Prefix lists are designed to match a range of subnets, as well as a range of subnet masks associated with the subnets.
RIPng for IPv6
IPv6 version of RIP is called RIP next generation(RIPng). RIPng remains a plain distance-vector protocol utilizing User Datagram Protocol (UDP) as its transport protocol, using port 521 instead of 520 to avoid clashes with existing RIPv1/RIPv2 implementations. The destination Ipv6 address for multicasted RIPng messages is FF02::9 while for the hop count, 15 being the maximum usable metric and 16 representing infinity. The metric is incremented by the receiver of a RIPng advertisement, not by the advertisement sender anymore as in RIPv2.
The number of route entries in a RIPng message is limited only by the IPv6 MTU on the link, and the protocol itself poses no limitations.
Authentication is not handled by RIPng anymore and it lacks several features supported by RIPv2:
-Authentication or encryption by IPsec is not supported.
-Split Horizon can be activated or deactivated only on a per-process basis, not on individual interfaces.
-Passive interfaces are not supported.
-Static (manual) neighbors cannot be configured (no neighbor command).
-Per-process offset lists are not supported.
Management improvements over RIPv2
-Multiple RIPng processes can be run on a router. Individual processes are distinguished by an alphanumeric name that is local to the router and does not need to match between different routers.
-Route Poisoning, as an enhancement of the Split Horizon mechanism, can be activated on a per-process basis.
-Interfaces can be configured with a metric-offset value that is added to the metric in all received advertisements over that interface.
-The default route can be originated on a per-interface basis, including an option of suppressing all other updates over that interface.
Configuration
ipv6 unicast-routing
ipv6 cef
R1(config-if)#ipv6 rip 1 enable
R1(config)#ipv6 router rip 1
R1(config-rtr)#poison-reverse
No comments:
Post a Comment