notes: Troubleshooting RIP

1. Problem: RIP Routes Not in the Routing Table


The possible causes for this problem are as follows:

a. Missing or incorrect network statement
- show ip protocols
- debug ip rip
- show ip route

b. Layer 2 down. - One cause for routes not in the routing table is Layers 1 or 2 being down. If Layers 1 or 2 are down, it's not a RIP problem. The following is a list of the most common things to check if the interface or line protocol is down:
Unplugged cable
Loose cable
Bad cable
Bad transceiver
Bad port
Bad interface card
Layer 2 problem at telco, in case of a WAN link
Missing clock statement, in case of back-to-back serial connection

- show int
- debug ip rip - nothing is being sent if l2 is down.

c. Distribute list blocking the route
- check the acl in the distribute list if the network is allowed or not.

d. Access list blocking RIP source address - access lists may be applied on the interface
- debug ip rip - reveals its not receiving any routes

e. Access list blocking RIP broadcast/multicast - When using access lists on the interface inbound, always make sure that they are not blocking the RIP broadcast or UDP port 520, which is used by RIP-1 and RIP-2 (or the RIP multicast address, in cases of RIP-2).
- rip1 - access-list 100 permit ip host 131.108.1.1 host 255.255.255.255
- rip2 - access-list 100 permit ip host 131.108.1.1 host 224.0.0.9

f. Incompatible version type
- debug ip rip (illegal version)
- sho ip protocols

g. Mismatch authentication key (RIP-2)
- debug ip rip (invalid authentication)

h. Discontiguous network
- solution is to create a static route.
- enable version 2

i. Invalid source - it performs a source-validity check. If the source is not on the same subnet as the local interface, RIP ignores the update and does not install routes in the routing table coming from this source address.
- debupg ip rip (bad source)
- solution "no validate-update-source "

j. Layer 2 problem (switch, Frame Relay, other Layer 2 media)
- debug ip packet 100 detail
access-list 100 permit ip any host 255.255.255.255
access-list 100 permit ip any host 224.0.0.9
- ping 224.0.0.9 is failing
solution: fix the layer 2 problem.

k. Offset list with a large metric defined
- show ip route rip (check the metric on the local router and neigh
- show ip route x.x.x.x
- debug ip rip (inaccessible)
-
j. Routes that reached RIP hop-count limit
- show ip route rip (check the metric on the neighbor router)
- show ip route x.x.x.x
- debug ip rip (inaccessible) on the local router


2. Problem: RIP Is Not Installing All Possible Equal-Cost Paths—Cause: maximum-path Command Restricts RIP from Installing More Than One Path

- By default, Cisco routers support only four equal paths for the purpose of load balancing. The maximum-path command can be used for up to six equal-cost paths. If the command is not configured properly, it can cause a problem, as discussed in this section. When con-figured improperly, the maximum-path command allows only one path to the destination, even though more than one path exists. Configuring the command as maximum-path 1 should be done only when load balancing is not desired.
- debug ip rip

3. Troubleshooting RIP Routes Advertisement

Two of the most prevalent problems that can go wrong on the sender's end deal with RIP route advertisement:

a. Problem: The sender is not advertising RIP routes.

When the routing information differs from one router to the other, one of two possibilities could exist:

• Some routers are not advertising the RIP routes.

• Some routers are not receiving the RIP routes.

this section deals in sending RIP routes.

a.1 Missing or incorrect network statement
- since RIP v1 is a classful network ensure you have a proper network statement.

a.2 Outgoing interface that is down
- show int
- debug ip rip

a.3 distribute-list out blocking the routes
- check the acl used n the distribute-list if the network is allowed or not.

a.4 Advertised network interface that is down
- verify the layer 2 and 1.

a.5 Outgoing interface defined as passive
- show ip protocols.

a.6 Broken multicast capability (encapsulation failure in Frame Relay)
- in a NBMA FR setup. make sure that in the frame-relay map statement the "broadcast"
keyword is present.
- debug ip packet 100 detail ( encapsulation failed: for 255.255.255.255)
access-list 100 permit ip host 131.108.1.1 host 255.255.255.255

a.7 Misconfigured neighbor statement
- the neighbor statement must be configured properly.

a.8 Advertised subnet is VLSM
- RIP1 does not support VLSM solution is to change to version 2.

a.9 Split horizon enabled
3 main uses for disabling split horizon.
- hub and spoke frame relay setup.
- in which a router has an external route that has a next-hop address also known
through some interface where other RIP routers are sitting
- secondary ip address


b. Subnetted routes are missing. Cause: Autosummarization Feature Is Enabled
- In RIP-1, this is not a problem because RIP-1 is a classful protocol and the network should
be designed with this understanding. With RIP-2, however, Cisco routers can be configured
to stop the autosummarization process.

3. Troubleshooting Routes Summarization in RIP

a. Problem: RIP-2 Routing Table Is Huge— Cause: Autosummarization Is Off
- Disabling the autosummarization feature increases the size of the routing table. In some
situations, this feature must be turned off (for example, if discontiguous networks exist).

b. Problem: RIP-2 Routing Table Is Huge— Cause: ip summary-address Is Not Used
using manual summarization on the interface level.

4. Troubleshooting RIP Redistribution Problems
- The most common cause of this is a metric that is not defined during redistribution into
RIP.
- show ip route
- debug ip rip

5. Troubleshooting Routes Flapping Problem in RIP
- Route flapping refers to routes coming into and going out of the routing table. To check
whether the routes are indeed flapping, check the routing table and look at the age of the
routes. If the ages are constantly getting reset to 00:00:00, this means that the routes are
flapping. Several reasons exist for this condition. This section discusses one of the common
reasons—packet loss because the packet is dropping on the sender's or receiver's interface.

The example in this section considers Frame Relay because it is the most common medium
in which this problem occurs. The packet loss can be verified through the interface statistics
by looking at the number of packet drops and determining whether that number is
constantly incrementing.

Hub#show ip route rip
R 155.155.0.0/16 [120/1] via 131.108.1.1, 00:02:08, Serial0
R 166.166.0.0/16 [120/1] via 131.108.1.1, 00:02:08, Serial0

note that the updates was received last 2 minutes and 8 seconds ago. udpate should be received every 30 seconds. /timers are at a value lower than 30 seconds.

Hub#show interfaces serial 0

Broadcast queue 64/64, broadcasts sent/dropped 1769202/1849660, interface broadcasts 3579215

also the show interface reveals that broadcast packets are dropped. the frame relay broadcast queue must be tuned.
- In a non-Frame Relay situation, the input or output hold queue might need to be increased.

notes: RIP Authentication

*===================================*
Authentication
*===================================*
- Only supported on RIPv2.
- Supports clear text and MD5.
- Configured using key-chains.
- RIP, unlike EIGRP does not require the same key-number on both sides.
- When configuring, order of operation is important.
- When making changes to the key-chain, first remove the config of the interface.

Steps involved
1. Define a key chain with a name.
2. Define the key or keys on the key chain.
3. Enable authentication on an interfaces and specify the key chain to be used.
4. Specify whether the interfaces will use clear text or MD5. If not specified, clear is used.
5. Optionally configure key management.

-----------
COMMANDS
-----------

Step 1: Defines a key-chain

key chain NAME

Step 2: Defines the key/s on the chain/Specifies the key-string

key 1
key-string STRING

Step 3: Enable authentication on an interfaces by using the key-chain

interface ethernet 0
ip rip authentication key-chain NAME

Step 4: Specifies whether the interfaces will use clear text or MD5

ip rip authentication mode md5

note: some version of ios you need to define accept lifetime and send lifetime. this happens when you noticed that peering is down after some time between 2 routers.

---------------------------
verification
---------------------------

show ip protocols | begin rip - Shows the key-chain in use

notes: RIP Default Routing, Route tagging

Default Routing

1. Generates and advertises an unconditional default route to neighbors

default-information originate

2. Using distribute-list with prefix list sending default routes

ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
!
router rip
distribute-list prefix DEFAULT out

3. using route-map advertising default route conditionally


ip sla monitor 1
type echo protocol ipIcmpEcho 204.12.1.254 source-interface
FastEthernet0/0
timeout 50
frequency 1
ip sla monitor schedule 1 start-time now
!
track 1 rtr 1
!
router rip
default-information originate route-map RELIABLY_TRACK_LINK_TO_BB3
!
ip route 169.254.0.1 255.255.255.255 Null0 track 1
!
ip prefix-list DUMMY_ROUTE_TRACKED_VIA_SLA seq 5 permit 169.254.0.1/32
!
route-map RELIABLY_TRACK_LINK_TO_BB3 permit 10
match ip address prefix-list DUMMY_ROUTE_TRACKED_VIA_SLA

note:

With this example an IP SLA instance is introduced into conditional default origination. The SLA instance checks reachability to BB3 via ICMP every five seconds, with a timeout of two seconds. The SLA instance is then called from an enhanced object, which is called from a static route. This link local route of 169.254.0.1/32 could be any arbitrary dummy prefix. The dummy prefix is then called from a route-map which is tied to the default route origination. Therefore if R4 loses ICMP reachability to BB3 the default route is withdrawn. With the network properly functioning R4 advertises its default route to R5.


Route Tagging

-used in redistribution, then in a route-map

verification:

show ip rip database

notes: RIP Filtering

*===================================*
Filtering
*===================================*

- RIP can use distribute-lists, offset-lists and the distance command to filter traffic.
- Inbound filtering can be source based, like the distribute-list/ACL example below.
- If required to match the subnet mask, rather use prefix lists.
- Access-list "0" matches all routes.
- If no interface is identified, the list will modify all incoming or outgoing updates specified by the access list on any interface.
- If no access-list is called (by using a zero as the access list number), the offset list will modify all incoming or outgoing updates.


1. Distribute-lists
- can use either prefix-list or ACL

a. using prefix-list to filter routes coming in or out

config set1:

router rip
distribute-list prefix RIP_FILTER_TO_SW2 out FastEthernet0/0
distribute-list prefix PERMIT_ALL gateway NOT_FROM_R4 in
!
ip prefix-list NOT_FROM_R4 seq 5 deny 155.1.0.4/32
ip prefix-list NOT_FROM_R4 seq 10 permit 0.0.0.0/0 le 32
!
ip prefix-list PERMIT_ALL seq 5 permit 0.0.0.0/0 le 32
!
ip prefix-list RIP_FILTER_TO_SW2 seq 5 deny 30.0.0.0/14
ip prefix-list RIP_FILTER_TO_SW2 seq 10 deny 31.0.0.0/14
ip prefix-list RIP_FILTER_TO_SW2 seq 15 permit 0.0.0.0/0 le 32


config set2:

this allow 10.0.0.0/8 network from 1.2.3.4
router rip
distribute-list prefix ROUTE gateway SOURCE in
!
ip prefix-list ROUTE permit 10.0.0.0/8
ip prefix-list SOURCE permit 1.2.3.4/32



- Filters all routers to/from a neighbor using gateway

distribute-list gateway {prefix-list} {in|out} {interface}

- Filters prefixes from a specific source from entering the routing table

distribute-list prefix {prefix-routes} gateway {prefix-source} {in|out}

- filter routes coming form particular neighbor or gateways.

i.e.

ip prefix-list only24 seq 5 permit 0.0.0.0/0 ge 24 le 24 --allow only /24
!
ip prefix-list badgateway seq 5 permit 208.102.37.113/32
!
router rip
distribute-list prefix-list only24 gateway badgateway in


b. using Access-list to filter routes coming in or out

standard ACL

router rip
distribute-list 1 in Serial0/0
!
access-list 1 permit 0.0.1.0 255.255.254.255

extended ACL

router rip
distribute-list 100 in
!
access-list 100 permit ip host 1.2.3.4 host 10.0.0.0

Note: this accepts route only from 1.2.3.4 for network 10.0.0.0


2. Offset-list

- A "offset-list" can be used to modify the metric, but only to increase the metric.The metric cannot be decreased.
- A "offset-list" can also be used to filter traffic, by setting the metric to unreachable.

configset1:

access-list 1 permit 10.33.0.0 0.0.0.0
!
router rip
network 10.0.0.0
offset-list 1 in 2 Serial0

configset2:

router rip
offset-list 0 out 5 FastEthernet0/0.146

note: all routes going to fa0/0.146 will have an additional metric of 5.


3. Distance AD

Even though administrative distance is locally significant to the router, the RIP
process, like the EIGRP process, cannot advertise a route that is not actually
installed in the routing table.

distance AD {source address} {wildcard mask} {acl no}

configset1:

router rip
distance 255 0.0.0.0 255.255.255.255 1
!
access-list 1 permit 150.1.4.0

note: 0.0.0.0 255.255.255.255 - is from any source.

By setting the distance of the route 150.1.4.0 to
255, it is invalidated from being installed in the routing table, and hence
invalidated from being advertised to any neighbors.

configset2:

router rip
distance 55 150.0.1.1 0.0.0.0

all routes advertise by 150.0.1.1 neighbor will be having an admin distance of 55.

notes: RIP Summarization, Maximum Paths

*===================================*
Summarization
*===================================*

- By default auto-summarization is enabled for RIP.

Limitation of RIP summarization:

- More than one major network summary per interface is not allowed.
- Cannot summarize past the major network. For example the summary 10/7 is not allowed.

- When doing manual summarization, make sure auto-summary is off.
- The defining characteristic of a classful routing protocol is that it does not advertise an address mask along with the advertised destination address.

- For every packet passing through the router:
1- If the destination address is a member of a directly connected major network, the subnet mask configured on the interface attached to that network will be used to determine the subnet of the destination address. Therefore, the same subnet mask must be used consistently throughout that major network.
2- If the destination address is not a member of a directly connected major network, the router will try to match only the major class A, B, or C portion of the destination address.

-----------
COMMANDS
-----------

1. Limits the advertisements out of that interface to ONLY the summary

interface fa0/0
ip summary-address rip {ip} {mask}

- It's subject to a subnet of this aggregate being in the RIP database


Maximum Paths

-default max value of 4


command:

router rip:
maximum paths #

verification:

show ip protocols

notes: RIP Split-horizon, RIP triggered

*=====================================*
Split-Horizon, RIP Triggered
*=====================================*
- RIP employs split-horizon with poison reverse and triggered updates.

Split-Horizon

- Updates received in an interface will not be sent out of the same interface.
- Might be undesirable on partial mesh NBMA networks like multipoint interfaces.
- Is enabled for all interfaces by default, except main physical interfaces in frame-relay which has it disabled by default.

RIP triggered

- A triggered update occurs whenever the metric for a route is changed and, unlike regularly scheduled updates, includes only the entries that have changed.
- The receiving router does not reset its update timer when a triggered update is received.
- The command "ip rip triggered" enables the triggered extensions of RIP. It is needed on both sides of a link.
- Route table updates are minimized to include only the initial exchange of route tables and updates when changes to the route tables occur.
- The triggered state goes from DOWN, through INIT and LOADING, to FULL.
- Should only be configured on a point-to-point serial link.

-----------
COMMANDS
-----------
1. Enabled triggered updates on interface level.

ip rip triggered

- Only available on serial link, if both sides are enabled

2. Disables split-horizon

no ip split-horizon

---------------
verification
---------------

1. show ip protocols

notes: RIP Network statement, Passive-interface

Network statement on RIP has no mask option, and assumes classful boundaries, even with RIPv2.
- The updates sent to neighbors uses the assigned subnet masks from the interface on which the "network" address is configured.

command under router rip process

network {ip}

*===================================*
Passive interfaces
*===================================*

- no neigbhor relationship will be formed.
- "Passive-interface" is not a RIP-specific command.
- "Passive-interface" stops the sending of updates (Response.Msg) out of the interface specified.
- The router will still listen to RIP updates and update its routing table accordingly upon receipt of a response update message on the passive interface.
- The router will still advertises that interface address in normal updates to other peers.
- To stop the transmission of broad/multicast updates and send only unicast updates to a neighbor, include the passive-interface command along with the neighbor command under the RIP process.

-----------
COMMANDS
-----------
1. Disables sending of RIP updates on all interfaces

passive-interface default

2. then individually Stops the sending of updates out of the interface specified

[no] passive-interface {interface}

- Still receives updates and populates the routing table
- Still advertises that interface in normal updates to other peers

notes: RIP version, Update Types

- By default, a RIP process configured on a Cisco router sends only RIPv1 messages but listens to both RIPv1 and RIPv2.

V1

- classfull ( class A, B, C)
- default RIP configuration
- send updated as broadcast

v2
- supports VLSM/subnet mask/classless
- route summarization
-external route tags
- authentication
- uses multicast address for updates (224.0.0.9)
- "version 2" to enable v2 under RIP routing process
- The version 2 command causes RIP to send and listen to RIPv2 messages only.

note: v1 and v2 can received v1 & v2 updates by default.

to change the sending and receiving behavior using global under process

router rip
ip rip send v1
ip rip receive v1 v2


under interface:

ip rip receive version 1 2


*===================================*
Updates Types
*===================================*

1. Broadcast

- Default for RIPv1
- RIPv2 optional

to Enable broadcasts at a interface level for RIPv2.

ip rip v2-broadcast

note:it doesn't reflect in the "show ip protocols"

verification

debug ip rip

2. Multicast

- RIPv2 default to 224.0.0.9


3. Unicast

- RIPv1/RIPv2 optional

Under the process, send unicast updates to neighbor
- Useful on NBMA networks like frame-relay
- This does not stop the sending of broad/multicasts, use "passive-interfaces" for that

neighbor {IP}

Note: network statement should be there in which the neighbor belongs.

verification:

1. debug ip packets

2. show ip protocols

notes: RIP Metrics & Timers

- RIP uses hop-count as a metric.
- 1 hop per interface.
- 16 hops = unreachable

Timers:

1. Update timer (30sec) - A router sends a response message out every RIP-enabled interfaces every 30 seconds on average.

2. Invalid timer (180sec)- Amount of time a route can stay in the routing table without being updated.

3. Holddown (180sec) - An update with a hop count higher that the metric recorded in the table will place a route in holddown.
- cisco proprietary. if you you are connecting a non cisco devices set holdtime to 0.

4. Flush timer (240sec) - The time when a invalid route get removed from the routing table.

- Before the flush timer expires, the invalid route will be advertised with the unreachable metric.
- Shows in the routing table as "x.x.x.x is possibly down"
- Timers must be changed in all RIP domain

-----------
COMMANDS
-----------
1. to change the timers under rip routing process.

timers basic {update} {invalid} {holddown} {flush}

notes: RIP Operation

RIP Operation:

All RIP messages are encapsulated in UDP with source/destination ports being 520.

2 Message types:

1. Request: Used to ask neighboring routers to send an updates.
2. Response: Carries the update/routing entries.

- If a router must send an update with more than 25 route entries, multiple RIP messages will be produced.

- If more than one route exists to the same destination with equal hop counts, equal-cost load balancing will be performed.

- RIP sees a secondary IP addresses on a interfaces as separate data links, and can exchange routes with a secondary IP. But take note tha tall traffic generated by a router will always have the primary address as a source.
- RIP performs a soure-validation check, where the source IP address of incoming routing updates must be on the same IP network as one of the addresses defined for the receiving interface.

- Another instance where it might be needed to disable the source-validation, is when the source address is on a different subnet that, the locally configured address, ie local has a /32 and remote side a /24. This can be seen with "debug ip rip events".

- Output-delay

Can be used to sets a inter-packet gap between 8 and 50ms (default=0).
Can be used when a high-speed router is sending updates to a low-speed router.


-----------
COMMANDS
-----------

1. enable the RIP process:

router rip

2. Disables the validation of the source address in updates

no validate-update source

3. Sets an inter-packet gap (value 8-50), (Default=0)

output-delay {ms}


------------------
verification
------------------

1. All RIPv2 enabled routers will answer the ping and respond

ping 224.0.0.9

2. Displays RIP protocol events

debug ip rip events

3. to show which interface is participating

show ip protocols