Friday 27 February 2015

Basic EIGRP configuration

Configuring EIGRP

This section explains how to enable and restart the EIGRP process on your system. After enabling see the section, to learn how to customize the EIGRP process on your system.
Enabling EIGRP
Enabling EIGRP Stub Routing
Restarting the EIGRP Process

Enabling EIGRP

You can only enable one EIGRP routing process on the ASA. To enable EIGRP, perform the following detailed steps.

Detailed Steps


Command

Purpose

Step 1 


router eigrp as-num




Example:


hostname(config)# router eigrp 2

This creates an EIGRP routing process, and the user enters router configuration mode for this EIGRP process.

The as-num argument is the autonomous system number of the EIGRP routing process.

Step 2 


network ip-addr [mask]




Example:


hostname(config)# router eigrp 2


hostname(config-router)# network 10.0.0.0 
255.0.0.0

This step configure the interfaces and networks that participate in EIGRP routing. You can configure one or morenetwork statements with this command.

Directly-connected and static networks that fall within the defined network are advertised by the ASA. Additionally, only interfaces with an IP address that fall within the defined network participate in the EIGRP routing process.

If you have an interface that you do not want to participate in EIGRP routing, but that is attached to a network that you want advertised, see the section Configuring Interfaces in EIGRP.

Enabling EIGRP Stub Routing

You can enable, and configure the ASA as an EIGRP stub router. Stub routing decreases memory and processing requirements on the ASA. As a stub router, the ASA does not need to maintain a complete EIGRP routing table because it forwards all nonlocal traffic to a distribution router. Generally, the distribution router need not send anything more than a default route to the stub router.
Only specified routes are propagated from the stub router to the distribution router. As a stub router, the ASA responds to all queries for summaries, connected routes, redistributed static routes, external routes, and internal routes with the message "inaccessible." When the ASA is configured as a stub, it sends a special peer information packet to all neighboring routers to report its status as a stub router. Any neighbor that receives a packet informing it of the stub status will not query the stub router for any routes, and a router that has a stub peer will not query that peer. The stub router depends on the distribution router to send the proper updates to all peers.
To enable the ASA as an EIGRP stub routing process, perform the following steps:

Detailed Steps


Command

Purpose

Step 1 


router eigrp as-num




Example:


hostname(config)# router eigrp 2

This creates an EIGRP routing process, and the user enters router configuration mode for this EIGRP process.

The as-num argument is the autonomous system number of the EIGRP routing process.

Step 2 


network ip-addr [mask]




Example:


hostname(config)# router eigrp 2


hostname(config-router)# network 10.0.0.0 
255.0.0.0

This step configure the interfaces and networks that participate in EIGRP routing. You can configure one or morenetwork statements with this command.

Directly-connected and static networks that fall within the defined network are advertised by the ASA. Additionally, only interfaces with an IP address that fall within the defined network participate in the EIGRP routing process.

If you have an interface that you do not want to participate in EIGRP routing, but that is attached to a network that you want advertised, see the section Configuring Interfaces for EIGRP.

Step 3 


eigrp stub {receive-only | [connected] 
[redistributed] [static] [summary]}




Example:


hostname(config)# router eigrp 2


hostname(config-router)# network 10.0.0.0 
255.0.0.0


hostname(config-router)# eigrp stub 
{receive-only | [connected] 
[redistributed] [static] [summary]}


This step configure the stub routing process. You must specify which networks are advertised by the stub routing process to the distribution router. Static and connected networks are not automatically redistributed into the stub routing process.

Restarting the EIGRP Process

To restart an EIGRP process, clear redistribution, or counters, enter the following command:
hostname(config)# clear eigrp pid {<1-65535> | neighbors | topology | events)}

Customizing EIGRP

This section describes how to customize the EIGRP routing, and includes the following topics:
Configuring Interfaces for EIGRP
Configuring the Summary Aggregate Addresses on Interfaces
Changing the Interface Delay Value
Enabling EIGRP Authentication on an Interface
Defining an EIGRP Neighbor
Redistributing Routes Into EIGRP
Filtering Networks in EIGRP
Customizing the EIGRP Hello Interval and Hold Time
Disabling Automatic Route Summarization
Disabling EIGRP Split Horizon

Configuring Interfaces for EIGRP

If you have an interface that you do not want to participate in EIGRP routing, but that is attached to a network that you want advertised, you can configure anetwork command that covers the network the interface is attached to, and use the passive-interface command to prevent that interface from sending or receiving EIGRP updates.

Detailed Steps


Command

Purpose

Step 1 


router eigrp as-num




Example:


hostname(config)# router eigrp 2

This creates an EIGRP routing process, and the user enters router configuration mode for this EIGRP process.

The as-num argument is the autonomous system number of the EIGRP routing process.

Step 2 


hostname(config-router)# network ip-addr [mask]




Example:


hostname(config)# router eigrp 2


hostname(config-router)# network 10.0.0.0 
255.0.0.0

This step configure the interfaces and networks that participate in EIGRP routing. You can configure one or more network statements with this command.

Directly-connected and static networks that fall within the defined network are advertised by the ASA. Additionally, only interfaces with an IP address that fall within the defined network participate in the EIGRP routing process.

If you have an interface that you do not want to participate in EIGRP routing, but that is attached to a network that you want advertised, see the sectionConfiguring Interfaces for EIGRP.

Step 3 

Do one of the following to customize an interface to participate in EIGRP routing:


passive-interface {default | if-name}




Example:


hostname(config)# router eigrp 2


hostname(config-router)# network 10.0.0.0 
255.0.0.0


hostname(config-router)# passive-interface 
{default}

This step prevents an interface from sending or receiving EIGRP routing message.

Using the default keyword disables EIGRP routing updates on all interfaces. Specifying an interface name, as defined by the nameif command, disables EIGRP routing updates on the specified interface. You can have multiple passive-interfacecommands in your EIGRP router configuration.


no default-information {in | out | WORD}




Example:


hostname(config)# router eigrp 2


hostname(config-router)# network 10.0.0.0 
255.0.0.0


hostname(config-router)# no 
default-information {in | out | WORD}

This allows you to control the sending or receiving of candidate default route information.

Configuring no default-information incauses the candidate default route bit to be blocked on received routes. Configuring no default-information out disables the setting of th edefault route bit in advertised routes.

Configuring the Summary Aggregate Addresses on Interfaces

You can configure a summary addresses on a per-interface basis. You need to manually define summary addresses if you want to create summary addresses that do not occur at a network number boundary or if you want to use summary addresses on a ASA with automatic route summarization disabled. If any more specific routes are in the routing table, EIGRP will advertise the summary address out the interface with a metric equal to the minimum of all more specific routes.
To create a summary address, perform the following steps:

Detailed Steps



Command

Purpose

Step 1 

interface phy_if




Example:


hostname(config)# interface phy_if

Enter interface configuration mode for the interface on which you are changing the delay value used by EIGRP.

Step 2 

summary-address eigrp as-num address mask 
[distance]




Example:


hostname(config-if)# summary-address eigrp 2 address mask [20]



This step creates the summary address.

By default, EIGRP summary addresses that you define have an administrative distance of 5. You can change this value by specifying the optionaldistance argument in the summary-addresscommand.

Thursday 26 February 2015

EIGRP (Cont).

Routing Concepts: - EIGRP relies on four fundamental concepts: neighbor tables, topology tables, route states, and route tagging. Each of these is summarized in the discussions that follow.

Neighbor Tables

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. When a neighbor sends a hello packet, it advertises a hold time, which is the amount of time that a router treats a neighbor as reachable and operational. If a hello packet is not received within the hold time, the hold time expires and DUAL is informed of the topology change.
The neighbor-table entry also includes information required by RTP. Sequence numbers are employed to match acknowledgments with data packets, and the last sequence number received from the neighbor is recorded so that out-of-order packets can be detected. A transmission list is used to queue packets for possible retransmission on a per-neighbor basis. Round-trip timers are kept in the neighbor-table entry to estimate an optimal retransmission interval.

Topology Tables

The topology table contains all destinations advertised by neighboring routers. The protocol-dependent modules populate the table, and the table is acted on by the DUAL finite-state machine. Each entry in the topology table includes the destination address and a list of neighbors that have advertised the destination. For each neighbor, the entry records the advertised metric, which the neighbor stores in its routing table. An important rule that distance vector protocols must follow is that if the neighbor advertises this destination, it must use the route to forward packets.
The metric that the router uses to reach the destination is also associated with the destination. The metric that the router uses in the routing table, and to advertise to other routers, is the sum of the best-advertised metric from all neighbors and the link cost to the best neighbor.

Route States

A topology-table entry for a destination can exist in one of two states: active or passive. A destination is in the passive state when the router is not performing a recomputation; it is in the active state when the router is performing a recomputation. If feasible successors are always available, a destination never has to go into the active state, thereby avoiding a recomputation.
A recomputation occurs when a destination has no feasible successors. The router initiates the recomputation by sending a query packet to each of its neighboring routers. The neighboring router can send a reply packet, indicating that it has a feasible successor for the destination, or it can send a query packet, indicating that it is participating in the recomputation. While a destination is in the active state, a router cannot change the destination's routing-table information. After the router has received a reply from each neighboring router, the topology-table entry for the destination returns to the passive state, and the router can select a successor.

Route Tagging

EIGRP supports internal and external routes. Internal routes originate within an EIGRP AS. Therefore, a directly attached network that is configured to run EIGRP is considered an internal route and is propagated with this information throughout the EIGRP AS. External routes are learned by another routing protocol or reside in the routing table as static routes. These routes are tagged individually with the identity of their origin.
External routes are tagged with the following information:
  • Router ID of the EIGRP router that redistributed the route
  • AS number of the destination
  • Configurable administrator tag
  • ID of the external protocol
  • Metric from the external protocol
  • Bit flags for default routing
Route tagging allows the network administrator to customize routing and maintain flexible policy controls. Route tagging is particularly useful in transit ASs, where EIGRP typically interacts with an interdomain routing protocol that implements more global policies, resulting in a very scalable, policy-based routing.
EIGRP Packet Types
EIGRP uses the following packet types: hello and acknowledgment, update, and query and reply.
Hello packets are multicast for neighbor discovery/recovery and do not require acknowledgment. An acknowledgment packet is a hello packet that has no data. Acknowledgment packets contain a nonzero acknowledgment number and always are sent by using a unicast address.
Update packets are used to convey reachability of destinations. When a new neighbor is discovered, unicast update packets are sent so that the neighbor can build up its topology table. In other cases, such as a link-cost change, updates are multicast. Updates always are transmitted reliably.
Query and reply packets are sent when a destination has no feasible successors. Query packets are always multicast. Reply packets are sent in response to query packets to instruct the originator not to recompute the route because feasible successors exist. Reply packets are unicast to the originator of the query. Both query and reply packets are transmitted reliably.

Conclusion: - 

Cisco Systems's EIGRP is one of the most feature-rich and robust distance vector routing protocols to ever be developed. EIGRP is also remarkably easy to configure and use, as well as remarkably efficient and secure in operation. It can be used in conjunction with IPv4, AppleTalk, and IPX. More importantly, its modular architecture will readily enable Cisco to add support for other routed protocols that may be developed in the future.

Wednesday 25 February 2015

Enhanced Interior Gateway Routing Protocol (EIGRP)

The Enhanced Interior Gateway Routing Protocol (EIGRP) represents an evolution from its predecessor IGRP (refer to Interior Gateway Routing Protocol). This evolution resulted from changes in networking and the demands of diverse, large-scale internetworks. EIGRP integrates the capabilities of link-state protocols into distance vector protocols. Additionally, EIGRP contains several important protocols that greatly increase its operational efficiency relative to other routing protocols. One of these protocols is the Diffusing update algorithm (DUAL) developed at SRI International by Dr. J.J. Garcia-Luna-Aceves. DUAL enables EIGRP routers to determine whether a path advertised by a neighbor is looped or loop-free, and allows a router running EIGRP to find alternate paths without waiting on updates from other routers.
EIGRP provides compatibility and seamless interoperation with IGRP routers. An automatic-redistribution mechanism allows IGRP routes to be imported into EIGRP, and vice versa, so it is possible to add EIGRP gradually into an existing IGRP network. Because the metrics for both protocols are directly translatable, they are as easily comparable as if they were routes that originated in their own autonomous systems (ASs). In addition, EIGRP treats IGRP routes as external routes and provides a way for the network administrator to customize them.
This article provides an overview of the basic operations and protocol characteristics of EIGRP.

Capabilities and Attributes:-

Key capabilities that distinguish EIGRP from other routing protocols include fast convergence, support for variable-length subnet mask, support for partial updates, and support for multiple network layer protocols.
A router running EIGRP stores all its neighbors' routing tables so that it can quickly adapt to alternate routes. If no appropriate route exists, EIGRP queries its neighbors to discover an alternate route. These queries propagate until an alternate route is found.
Its support for variable-length subnet masks permits routes to be automatically summarized on a network number boundary. In addition, EIGRP can be configured to summarize on any bit boundary at any interface.
EIGRP does not make periodic updates. Instead, it sends partial updates only when the metric for a route changes. Propagation of partial updates is automatically bounded so that only those routers that need the information are updated. As a result of these two capabilities, EIGRP consumes significantly less bandwidth than IGRP.
EIGRP includes support for AppleTalk, IP, and Novell NetWare. The AppleTalk implementation redistributes routes learned from the Routing Table Maintenance Protocol (RTMP). The IP implementation redistributes routes learned from OSPF, Routing Information Protocol (RIP), Intermediate System-to-Intermediate System (IS-IS), Exterior Gateway Protocol (EGP), or Border Gateway Protocol (BGP). The Novell implementation redistributes routes learned from Novell RIP or Service Advertisement Protocol (SAP).

Underlying Processes and Technologies: -

To provide superior routing performance, EIGRP employs four key technologies that combine to differentiate it from other routing technologies: neighbor discovery/recovery, reliable transport protocol (RTP), DUAL finite-state machine, and protocol-dependent modules.
The neighbor discovery/recovery mechanism enables routers to dynamically learn about other routers on their directly attached networks. Routers also must discover when their neighbors become unreachable or inoperative. This process is achieved with low overhead by periodically sending small hello packets. As long as a router receives hello packets from a neighboring router, it assumes that the neighbor is functioning, and the two can exchange routing information.
Reliable Transport Protocol (RTP) is responsible for guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast or unicast packets. For efficiency, only certain EIGRP packets are transmitted reliably. On a multiaccess network that has multicast capabilities, such as Ethernet, it is not necessary to send hello packets reliably to all neighbors individually. For that reason, EIGRP sends a single multicast hello packet containing an indicator that informs the receivers that the packet need not be acknowledged. Other types of packets, such as updates, indicate in the packet that acknowledgment is required. RTP contains a provision for sending multicast packets quickly when unacknowledged packets are pending, which helps ensure that convergence time remains low in the presence of varying speed links.
The DUAL finite-state machine embodies the decision process for all route computations by tracking all routes advertised by all neighbors. DUAL uses distance information to select efficient, loop-free paths and selects routes for insertion in a routing table based on feasible successors. A feasible successor is a neighboring router used for packet forwarding that is a least-cost path to a destination that is guaranteed not to be part of a routing loop. When a neighbor changes a metric, or when a topology change occurs, DUAL tests for feasible successors. If one is found, DUAL uses it to avoid recomputing the route unnecessarily. When no feasible successors exist but neighbors still advertise the destination, a recomputation (also known as a diffusing computation) must occur to determine a new successor. Although recomputation is not processor-intensive, it does affect convergence time, so it is advantageous to avoid unnecessary recomputations.
Protocol-dependent modules are responsible for network layer protocol-specific requirements. The IP-EIGRP module, for example, is responsible for sending and receiving EIGRP packets that are encapsulated in IP. Likewise, IP-EIGRP is also responsible for parsing EIGRP packets and informing DUAL of the new information that has been received. IP-EIGRP asks DUAL to make routing decisions, the results of which are stored in the IP routing table. IP-EIGRP is responsible for redistributing routes learned by other IP routing protocols.

Tuesday 24 February 2015

Interior Gateway Routing Protocol (IGRP)

The Interior Gateway Routing Protocol (IGRP) is a routing protocol that was developed in the mid-1980s by Cisco Systems, Inc. Cisco's principal goal in creating IGRP was to provide a robust protocol for routing within an autonomous system (AS). Such protocols are known as Interior Gateway Routing Protocols.
In the mid-1980s, the most popular Interior Gateway Routing Protocol was the Routing Information Protocol (RIP). Although RIP was quite useful for routing within small- to moderate-sized, relatively homogeneous internetworks, its limits were being pushed by network growth. In particular, RIP's small hop-count limit (16) restricted the size of internetworks; single metric (hop count) support of only equal-cost load balancing (in all-Cisco networks only!) did not allow for much routing flexibility in complex environments. The popularity of Cisco routers and the robustness of IGRP encouraged many organizations with large internetworks to replace RIP with IGRP.
Cisco's initial IGRP implementation worked in Internet Protocol (IP) networks. IGRP was designed to run in any network environment, however, and Cisco soon ported it to run in OSI Connectionless-Network Protocol (CLNP) networks. Cisco developed Enhanced IGRP in the early 1990s to improve the operating efficiency of IGRP. This article discusses IGRP's basic design and implementation.

Charactersitics: - IGRP is a distance vector Interior Gateway Protocol (IGP). Distance vector routing protocols mathematically compare routes using some measurement of distance. This measurement is known as the distance vector. Routers using a distance vector protocol must send all or a portion of their routing table in a routing-update message at regular intervals to each of their neighboring routers. As routing information proliferates through the network, routers can identify new destinations as they are added to the network, learn of failures in the network, and, most importantly, calculate distances to all known destinations.
Distance vector routing protocols are often contrasted with link-state routing protocols, which send local connection information to all nodes in the internetwork.
IGRP uses a composite metric that is calculated by factoring weighted mathematical values for internetwork delay, bandwidth, reliability, and load. Network administrators can set the weighting factors for each of these metrics, although great care should be taken before any default values are manipulated. IGRP provides a wide range for its metrics. Reliability and load, for example, can take on any value between 1 and 255; bandwidth can take on values reflecting speeds from 1200 bps to 10 Gbps, while delay can take on any value from 1 to 224. These wide metric ranges are further complemented by a series of user-definable constants that enable a network administrator to influence route selection. These constants are hashed against the metrics, and each other, in an algorithm that yields a single, composite metric. Thus, the network administrator can influence route selection by giving higher or lower weighting to specific metrics. This flexibility allows administrators to fine-tune IGRP's automatic route selection.
To provide additional flexibility, IGRP permits multipath routing. Dual equal-bandwidth lines can run a single stream of traffic in round-robin fashion, with automatic switchover to the second line if one line goes down. Multiple paths can have unequal metrics yet still be valid multipath routes. For example, if one path is three times better than another path (its metric is three times lower), the better path will be used three times as often. Only routes with metrics that are within a certain range or variance of the best route are used as multiple paths. Variance is another value that can be established by the network administrator.

Stability Features

IGRP provides a number of features that are designed to enhance its stability. These include holddowns, split horizons, and poison-reverse updates.
Holddowns are used to prevent regular update messages from inappropriately reinstating a route that might have gone bad. When a router goes down, neighboring routers detect this via the lack of regularly scheduled update messages. These routers then calculate new routes and send routing update messages to inform their neighbors of the route change. This activity begins a wave of triggered updates that filter through the network. These triggered updates do not instantly arrive at every network device. Thus, it is possible for a device that has yet to be informed of a network failure to send a regular update message, which advertises a failed route as being valid to a device that has just been notified of the network failure. In this case, the latter device would contain (and potentially advertise) incorrect routing information. Holddowns tell routers to hold down any changes that might affect routes for some period of time. The holddown period usually is calculated to be just greater than the period of time necessary to update the entire network with a routing change.
Split horizons derive from the premise that it is never useful to send information about a route back in the direction from which it came. Router 1 (R1) advertises that it has a route to Network A. There is no reason for Router 2 (R2) to include this route in its update back to R1 because R1 is closer to Network A. The split-horizon rule says that R2 should strike this route from any updates that it sends to R1. The split-horizon rule helps prevent routing loops. Consider, for example, the case in which R1's interface to Network A goes down. Without split horizons, R2 continues to inform R1 that it can get to Network A (through R1). If R1 does not have sufficient intelligence, it actually might pick up R2's route as an alternative to its failed direct connection, causing a routing loop. Although holddowns should prevent this, split horizons are implemented in IGRP because they provide extra algorithm stability.
Figure: The Split-Horizon Rule Helps Protect Against Routing Loops illustrates the split-horizon rule.
Figure: The Split-Horizon Rule Helps Protect Against Routing Loops
CT844201.jpg
Split horizons should prevent routing loops between adjacent routers, but poison-reverse updates are necessary to defeat larger routing loops. Increases in routing metrics generally indicate routing loops. Poison-reverse updates then are sent to remove the route and place it in holddown. In Cisco's implementation of IGRP, poison-reverse updates are sent if a route metric has increased by a factor of 1.1 or greater.

Timers

IGRP maintains a number of timers and variables containing time intervals. These include an update timer, an invalid timer, a hold-time period, and a flush timer. The update timer specifies how frequently routing update messages should be sent. The IGRP default for this variable is 90 seconds. The invalid timer specifies how long a router should wait in the absence of routing-update messages about a specific route before declaring that route invalid. The IGRP default for this variable is three times the update period. The hold-time variable specifies the holddown period. The IGRP default for this variable is three times the update timer period plus 10 seconds. Finally, the flush timer indicates how much time should pass before a route should be flushed from the routing table. The IGRP default is seven times the routing update period.

Monday 23 February 2015

Advanced Configuration of RIP

Disabling Route Summarization

RIP Version 1 always uses automatic route summarization. You cannot disable this feature for RIP Version 1. RIP Version 2 uses automatic route summarization by default. The RIP routing process summarizes on network number boundaries. This can cause routing problems if you have non-contiguous networks.
For example, if you have a router with the networks 192.168.1.0, 192.168.2.0, and 192.168.3.0 connected to it, and those networks all participate in RIP, the RIP routing process creates the summary address 192.168.0.0 for those routes. If an additional router is added to the network with the networks 192.168.10.0 and 192.168.11.0, and those networks participate in RIP, they will also be summarized as 192.168.0.0. To prevent the possibility of traffic being routed to the wrong location, you should disable automatic route summarization on the routers creating the conflicting summary addresses.
To disable automatic router summarization, enter the following command in router configuration mode for the RIP routing process:

Detailed Steps


Command

Purpose

Step 1 


router rip 




Example:


hostname(config)# router rip 

This starts the RIP routing process and places you in router configuration mode.

Step 2 



no auto-summarize




Example:


hostname(config-router):# no 
auto-summarize


This step disables automatic route summarization.

Filtering Networks in RIP

To filter the networks received in updates, perform the following steps:


Detailed Steps


Command

Purpose

Step 1 


router rip 




Example:


hostname(config)# router rip 

This starts the RIP routing process and places you in router configuration mode.

Step 2 


distribute-list acl in [interface if_name]


distribute-list acl out [connected | eigrp 
| interface if_name | ospf | rip | static]




Example:


hostname(config-router)# distribute-list acl2 in [interface interface1]

hostname(config-router): distribute-list acl3 out [connected]

This step filters the networks sent in updates.

You can specify an interface to apply the filter to only those updates received or sent by that interface. You can enter this command for each interface you want to apply a filter to. If you do not specify an interface name, the filter is applied to all RIP updates.

Redistributing Routes into the RIP Routing Process

You can redistribute routes from the OSPF, EIGRP, static, and connected routing processes into the RIP routing process.
To redistribute a routes into the RIP routing process, perform the following steps:

Detailed Steps

Command

Purpose

Step 1 

Do one of the following to redistribute the selected route type into the RIP routing process. You must specify the RIP metric values in the redistribute command if you do not have a default-metriccommand in the RIP router configuration.


redistribute connected [ metric 
<metric-value> | transparent ] [route-map 
<route-map-name>]




Example:


hostname(config-router): # redistribute 
connected [ metric <metric-value> | 
transparent ] [route-map <route-map-name>]


Use this step to redistribute connected routes into the RIP routing process.


redistribute static [metric {metric_value 
| transparent}] [route-map map_name]




Example:


hostname(config-router):# redistribute 
static [metric {metric_value
transparent}] [route-map map_name]

Use this step to redistribute static routes into the EIGRP routing process.


redistribute ospf pid [match {internal | 
external [1 | 2] | nssa-external [1 | 2]}] 
metric {metric_value | transparent}] 
route-map map_name]




Example:


hostname(config-router):# redistribute 
ospf pid [match {internal | external [1 | 
2] | nssa-external [1 | 2]}] [metric 
{metric_value | transparent}] [route-map map_name]


Use this step to redistribute routes from an OSPF routing process into the RIP routing process.


redistribute eigrp as-num [metric 
{metric_value | transparent}] [route-map 
map_name]




Example:


hostname(config-router):# redistribute 
eigrp as-num [metric {metric_value | 
transparent}] [route-map map_name]

Use this step to redistribute routes from an EIGRP routing process into the RIP routing process.

Configuring RIP Send/Receive Version on an Interface

You can override the globally-set version of RIP the ASA uses to send and receive RIP updates on a per-interface basis.
To configure the RIP send and receive version, perform the following steps:

Detailed Steps


Command

Purpose

Step 1 


interface phy_if




Example:


hostname(config)# interface phy_if

This step enters interface configuration mode for the interface you are configuring.

Step 2 

Do one of the following to to send or receive RIP updates on a per-interface basis.


rip send version {[1] [2]}




Example:


hostname(config-if)# rip send version 1

This step specifies the version of RIP to use when sending RIP updates out of the interface.

In this example, version 1 is selected.


rip receive version {[1] [2]}




Example:


hostname(config-if)# rip receive version 2

This step specifies the version of RIP advertisements permitted to be received by an interface.

In this example, version 2 is selected.

RIP updates received on the interface that do not match the allowed version are dropped.

Enabling RIP Authentication

RIP route authentication provides MD5 authentication of routing updates from the RIP routing protocol. The MD5 keyed digest in each RIP packet prevents the introduction of unauthorized or false routing messages from unapproved sources.

RIP route authentication is configured on a per-interface basis. All RIP neighbors on interfaces configured for RIP message authentication must be configured with the same authentication mode and key for adjacencies to be established.
     To enable RIP authentication on an interface, perform the following steps:

Detailed Steps


Command

Purpose

Step 1 


router rip 




Example:


hostname(config)# router rip 

This creates an RIP routing process, and the user enters router configuration mode for this RIP process.

The as-num argument is the autonomous system number of the RIP routing process.

Step 2 


interface phy_if




Example:


hostname(config)# interface phy_if

Enter interface configuration mode for the interface on which you are configuring RIP message authentication.

Step 3 


rip authentication mode {text | md5}




Example:


hostname(config-if)# rip authentication 

mode md5

This step sets the authentication mode. By default, text authentication is used. We recommend MD5 authentication.

Step 4 


rip authentication key key key-id key-id




Example:


hostname(config-if)# rip authentication 
key cisco key-id 200

Configure the authentication key used by the MD5 algorithm.

The key argument can contain up to 16 characters.

The key-id argument is a number from 0 to 255.

Monitoring RIP

You can use the following commands to monitor or debug the RIP routing process.
We recommend that you only use the debug commands to troubleshoot specific problems or during troubleshooting sessions with Cisco TAC.
Debugging output is assigned high priority in the CPU process and can render the system unusable. It is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system performance. For examples and descriptions of the command output, see the Cisco Security Appliance Command Reference.
To monitor or debug various RIP routing statistics, perform one of the following tasks:

Command

Purpose

Monitoring RIP Routing


show rip database

Display the contents of the RIP routing database.


show running-config router rip

Displays the RIP commands.

Debug RIP


debug rip events

Displays RIP processing events.


debug rip database

Displays RIP database events.

Configuration Example for RIP

The following example shows how to enable and configure RIP with various optional processes:

Step 1 Enable RIP:

hostname(config)# router rip 2


Step 2 Configure a default route into RIP:
hostname(config-router): default-information originate

Step 3 Specify the version of RIP to use:
hostname(config-router): version [1]

Step 4 Specify the interfaces that will participate in the RIP routing process:
hostname(config-router)# network 225.25.25.225

Step 5 Specify an interface to operate in passive mode:
hostname(config-router)# passive-interface [default]
Step 6 Redistribute a connected route into the RIP routing process
hostname(config-router): redistribute connected [metric bandwidth delay reliability
Loading mtu] [route-map map_name]


Feature History for RIP

Table 22-1 lists the release history for this feature.

Table 22-1 Feature History for RIP

Feature Name

Releases

Feature Information

router rip

7.0

This feature allows you to route data, perform authentication, redistribute and monitor routing information, using the Routing Information Protocol (RIP) routing protocol.
a