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.
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
No comments:
Post a Comment