There are RIPv2 and IPv6 RIPng posts previously regarding this subject, so I will be Rippng (pun intended) right on through this article, if you type “Rip” into the search function a lot of the articles for RIPv2 will be redistribution and one for RIPng which is very straight forward.
However those are more focused on configuration / verification when things are working, and for TSHOOT we need to know where issues may be introduced!
The long list of possible issues for any Routing Protocol route propagation issue!
As RIPv2 is not seen on the TSHOOT as far as published by Cisco, however theory from v2 carries over to Next Gen RIP, so wanted to cover some possible issues for exam day.
The below list was covered in the RIPng chapter of OCG, but it can be applied to any routing protocol, so this will serve as a possible issue list for all of them!
Though some will be specific to RIP such as hop count and AutoSummarization.
The long list of why RIP (OR ANY ROUTING PROTOCOL) may be missing routes:
- Interface is shut down – RIP facing interface must be Up/Up to receive Routing Updates or the routes will be missing from the IP route table
- Wrong Subnet – The device sending updates must be on the same subnet and the interface receiving those updates, or they are considered invalid and discarded
- Bad / Missing Network segment – This is for a single route missing, in the event when entering the “network …” statement the info is incorrect
- Passive Interface – Suppresses an interface from sending router updates, configured in router process config, Cisco passive interface article for reference.
- Wrong Version – Pretty hard to imagine a RIPv1 deployment anywhere, but needs to be mentioned, also RIPv2 and RIPng obviously don’t work together
- Max Hop Count Exceeded – Both RIPv2 and RIPng have a max hop count of 15 before the packet is considered dead on the 15th hop / decrement
- Authentication failure – If authentication is misconfigured for RIP, route updates will be ignored
- Route Filtering – Filters such as “Prefix-Lists” might be setup to filter routes in the network, this may cause RIP routes not to populate an IP Route Table
- Split Horizon – Loop-Prevention mechanism that prevents a router from advertising routes out the same interface they were learned from, the biggest concern for this behavior would be a Frame-Relay Topology for TSHOOT exam day!
- Autosummarization – RIPv2 and RIPng but do auto-summ, no way to disable, not a good protocol for discontiguous networks
- Route learned from better source – Route to same destination learned from a source with a lower AD than 120 for RIP
- ACL’s blocking updates – Routing Protocols will be included in the implicit deny all at the end of an ACL, so if an inbound ACL is set, it needs to permit traffic from the routing protocol its participating in!
- Load-Balancing – If Max-Paths value is not set correctly, certain equal-cost routes may not appear in routing table
A few of these are RIP specific, but in general, that list applies to most of them.
How to troubleshoot issues from the list above in regards to RIP
A lot of these will also be universal across all Dynamic Routing Protocols, however I will review them here in terms of RIP, as this is the first Dynamic Routing Protocol discussed.
- “sh ip rip database” – Shows all directly connected neighbors of RIP injected routes
- “sh ip route rip” – Shows all RIP learned routes in IP Route Table
- “debug ip rip” – Debugging to show rip traffic sent / received
- “sh ip int (int)” – Shows interface info to determine proper IP and Mask is in use, and if any Access-Group commands (ACLs) are applied and in which direction
- “sh ip protocols” – Shows inbound / outbound filters set, Redistribution, Timers, Authentication, load-balancing, Passive Interfaces, basically everything!
- “sh key chain” – Shows key chain info as RIP uses key chains to authenticate, key chain name is locally significant only but key ID / #’s and key string must match between the interface sending and interface receiving RIP updates
- “sh prefix-list …” / “sh distribute-list” – These will be defined in the route-filter section of “sh ip proto” and will need to be verified that they are not blocking any traffic that should be making it to the IP Route table
- “sh route” – This is for route-maps, and may be used for tagging route if two way redistribution is happening, use the search function of this website and many articles can be found on redistribution / Route-Maps / Route Tagging
- “sh access-list” – RIP uses UDP port 520, so if that is being blocked either inbound or outbound on an interface, RIP updates will be filtered where it is applied
- “ip summary address rip (network segment) (mask)” – On interface to apply a Summary Route beyond the default Auto Summary already happening with RIP that creates Summary Routes for the Major Classful networks
- “default-information originate” – Configured in router rip process to propagate a default route pointed at the default router the command is issued on
So there is a whole myriad of things that go along with RIP, despite it being hardly used in real world networks, that we have to know for TSHOOT day.
Fortunately most issues can be seen with a review of “debug ip rip” and “sh ip proto” along with the accompanying “show” and configuration commands to verify an issue and fix the issue once found.
Most if this also applies to RIPng, so I will be moving onto that to finish this RIP review!
RIPng changes for IPv6, verification, and troubleshooting
There is not a lot different between RIPv2 and RIPng, however there were some enhancements for IPv6 of course, starting with how it is enabled.
To enable RIPng is per interface rather a global router process, so every interface participating in RIPng will need “ipv6 rip (value) enable” to enable RIPng, the (value) is the process name / # which must match among other interfaces to be considered in the same RIP domain which can be verified in “sh ip proto” or “sh run int gi1/0” to see the manual configurations in the running config.
Given that IPv6 does not do Broadcast traffic, RIPng uses the ALL RIP Router Multicast address of FF02::9 to Multicast updates, and any RIPng enabled interfaces will listen for updates destined for this IPv6 Multicast Address.
RIPng and RIPv2 both have the AD value of 120, and Metric is still “hops” with a maximum of 15 hops before the destination is considered unreachable.
RIPng uses UDP port 521 to send updates every 30 seconds with full route table updates the same as RIPv2, so for IPv6 Access-Lists, deny port 521 is blocking RIPng updates.
- “ipv6 unicast-routing” – This enables IPv6 routing on the device, required to run any IPv6 protocols / addressing
- “ipv6 rip (name / #) enable” – This enables RIPng per interface, case sensitive and must match between interfaces to be considered in the same RIP domain
- “sh ipv6 proto” – This will show all IPv6 protocols running and information for them
- “sh ipv6 rip (process name optional)” – Process name optional to hone in on a specific process otherwise will see all with “sh ipv6 rip” command, this will show all info related to this instance of RIPng such as Port # used for communication, Multicast Group Address, Max-Paths #, local interfaces running this instance, Split-Horizon (on or off), timers, etc
- “default-information originate only“ – This will tell the interface to only advertise the default route, all other routes that would have been advertised are suppressed
- “debug ipv6 packets” – This will show if an ACL is discarding your routing protocol packets in real time
If an ACL is applied to the RIPng enabled interface, make adding the line “permit udp any any eq 521” should fix the issue if the ACL is a problem.
To get an idea of the information in “sh ipv6 rip” with two processes running:
R2#sh ipv6 rip
RIP process “Process1”, port 521, multicast-group FF02::9, pid 54
Administrative distance is 120. Maximum paths is 16
Updates every 30 seconds, expire after 180
Holddown lasts 0 seconds, garbage collect after 120
Split horizon is on; poison reverse is off
Default routes are not generated
Periodic updates 39, trigger updates 3
Interfaces:
FastEthernet0/0
Redistribution:
None
RIP process “Process2”, port 521, multicast-group FF02::9, pid 78
Administrative distance is 120. Maximum paths is 16
Updates every 30 seconds, expire after 180
Holddown lasts 0 seconds, garbage collect after 120
Split horizon is on; poison reverse is off
Default routes are not generated
Periodic updates 12, trigger updates 0
Interfaces:
Loopback2
Redistribution:
None
R2#
The link at the top of this article is a more detailed configuration of the above output, however that is a glimpse of what the output looks like.
Good troubleshooting commands for exam day
- “sh ipv6 rip” – To view all RIPng process information
- “sh ipv6 access-list (name)” – To see ACL lines of what is being allowed, and to see if hits are incrementing on the ACL, and to match IP’s on the ACL to IPv6 RIPng interface IP’s that should be sending traffic
- “traceroute ipv6” – This drops into an extended ping type prompt
- “sh ipv6 route 2001:db8::3” – This can be used as a quick way to check if Host IP is reachable from the first hop router to the Host having issues, if there is a route to that Host IP it will display Route Information including next-hop IP and Egress interface the traffic will take
- “sh ipv6 int (int)” – This will show if there is a “traffic-filter” with is equal to an ipv4 “access-group” meaning it ties an IPv6 ACL to the interface in a direction
- “ipv6 access-list (name)” – Drops into ACL of traffic-filter on an interface to add lines, can add “permit udp any any eq 521” to confirm RIPng traffic is flowing
- “sh ipv6 route” – Shows entire IPv6 Route table
Half the battle is really just knowing those verification commands, as the theory from IPv4 carries over almost exactly to IPv6 outside of concepts like Multicast vs Broadcast and different port #, how ACL’s are applied, etc.
And that is it for RIPv2 and RIPng!
This should be more than enough for exam day for RIPng, next up will be EIGRP v4 and v6, and all the messy details for that! 🙂
The DEVNET GRIND! 