RIP route question

Here is my configuration of RIPv2. I'am expecting my RIP to take a path of R2>R3 when I would ping 10.1.1.9 since RIP uses the least hop count. To my surprise it goes the other way R2>R1>R5>R4>R3. I'am trying to troubleshoot the problem, and found out on my routing table that My R2 uses the R1 as its next hop address.

how do you fix RIP to take the least hop count to the destination network? can I manipulate it's next hop address? thank you!

1.jpg

2.jpg

3.jpg

4.jpg

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Mrock4

I would check the link between R2 and R3 with regards to RIP and ensure it's included in your "network" statements- since R2 is taking the longest path around to reach the 10.1.1.8/30 network, it seems to suggest there's an issue between R2 and R3.

That being said, if it was working normally and you wanted to push traffic a different route, you could use an offset list to increase the metric for the shorter path (and thus force traffic over the other path).

chapapa

Mrock4 wrote: »

I would check the link between R2 and R3 with regards to RIP and ensure it's included in your "network" statements- since R2 is taking the longest path around to reach the 10.1.1.8/30 network, it seems to suggest there's an issue between R2 and R3.

That being said, if it was working normally and you wanted to push traffic a different route, you could use an offset list to increase the metric for the shorter path (and thus force traffic over the other path).

The link between R2 and R3 are working. so how do you do that offset list?

jdballinger

Can you post your router configs for R2 and R3 (just the routing statements and RIP config would be fine) as it's much easier to troubleshoot when you have that available.

Mrock4

Do a "debug ip rip" and verify you are actually receiving RIP routes via the link between R2/R3...being able to ping between them verifies the link itself is up, but does not mean RIP is talking over that link. If you're not receiving RIP routes via this link, the offset list will do nothing but increase the metric of the only available path.

for the offset list, create an ACL matching the routes you want to increase the metric for, then:

router rip
offset-list [ACL name] {in | out} offset X where X = the amount of hop counts to add to the current metric.

To verify check the ip routing table on the neighboring devices or debug ip rip and verify it's sending those routes with the new (higher) metric.

chapapa

jdballinger wrote: »

Can you post your router configs for R2 and R3 (just the routing statements and RIP config would be fine) as it's much easier to troubleshoot when you have that available.

r2
router rip
version 2
network 10.0.0.0

r3
router rip
version 2
network 10.0.0.0

Mrock4 wrote: »

Do a "debug ip rip" and verify you are actually receiving RIP routes via the link between R2/R3...being able to ping between them verifies the link itself is up, but does not mean RIP is talking over that link. If you're not receiving RIP routes via this link, the offset list will do nothing but increase the metric of the only available path.

for the offset list, create an ACL matching the routes you want to increase the metric for, then:

router rip
offset-list [ACL name] {in | out} offset X where X = the amount of hop counts to add to the current metric.

To verify check the ip routing table on the neighboring devices or debug ip rip and verify it's sending those routes with the new (higher) metric.

is that offset-list is still on CCNA level?

Mrock4

No offset-lists on the CCNA that I am aware of, but why limit yourself!

Dynaice

Do you have a no auto-summary on all of the router statements? It may be possible that the router doesn't know which way to go since you are just stating a 10.0.0.0 network and due to split horizon router 3 isn't learning routes to router 2 on that interface since it learned them initially from router 4?

d6bmg

@OP: did you modify the default hop count between R2 & R3?

d6bmg

chapapa wrote: »

is that offset-list is still on CCNA level?

No, But why limit yourself? You are getting knowledge about a new idea. Learn it, use it.

theodoxa

Dynaice wrote: »

Do you have a no auto-summary on all of the router statements? It may be possible that the router doesn't know which way to go since you are just stating a 10.0.0.0 network and due to split horizon router 3 isn't learning routes to router 2 on that interface since it learned them initially from router 4?

Why does auto-summary even exist? It seems to create nothing but problems. I remember creating a test network using RIPv2 and VLSM a while back. For some reason (turned out to be auto-summary since both interfaces had multiple subnets derived from the same classful network), it was sending packets destined for a subnet off of Fa0/1 out Fa0/0.

Dynaice

theodoxa wrote: »

Why does auto-summary even exist? It seems to create nothing but problems. I remember creating a test network using RIPv2 and VLSM a while back. For some reason (turned out to be auto-summary since both interfaces had multiple subnets derived from the same classful network), it was sending packets destined for a subnet off of Fa0/1 out Fa0/0.

I believe the reason auto-summary is there is because if you had one side of your network that is not contiguous and many more routes than we are dealing with in these small networks or labs then you will shorten your routing table.

If you say have 50 routers in a contiguous network on one side, then instead of having all of those single routes in the border router, you can summarize it to just 10.0.0.0 is out said interface. It would reduce the memory needed in the router to store all of those routes.

This is at least the way I understood it. Correct me if I'm wrong.

d6bmg

theodoxa wrote: »

Why does auto-summary even exist? It seems to create nothing but problems. I remember creating a test network using RIPv2 and VLSM a while back. For some reason (turned out to be auto-summary since both interfaces had multiple subnets derived from the same classful network), it was sending packets destined for a subnet off of Fa0/1 out Fa0/0.

Auto summery is very useful for small home network.

chapapa

alright! i'll do my research on offset!

thank you guys!