RIP Configuration

wasiimcisco · ‎01-19-2012

Hi,

I am not able to establish RIP routing between Two routers. Mattise and Dali. Both Router are able to communicate but RIP routes are not able to exchange.

Attached is the configuration of both Routers.

I want to exchange RIP Routes between these routers.

This is my lap setup.

Please assist me where I am doing the wrong configuration.

Peter Paluch · ‎01-19-2012

Hello,

You are running RIPv1. That may account for the troubles. Add the following two commands to the RIP config on both routers:

version 2

no auto-summary

Also, your Dali router is running IOS 11.3, according to the config file attached. That is an extremely old IOS. Do you have an option of upgrading it to at least 12.2? What platform is Dali, anyway?

Best regards,

Peter

wasiimcisco · ‎01-19-2012

Hi

I have changed the routers and I have configured both the routers for RIP ver 2 and no auto-summary.

But still I am not able to see the RIP routes. I have attached the new configuration of both routers.I have even tried by disabling the split horizone on RIP interfaces but no luck.

Matise#sh running-config interface fastEthernet 0/1/0
Building configuration...

Current configuration : 174 bytes
!
interface FastEthernet0/1/0
ip address 172.19.35.15 255.255.255.128 secondary
ip address 192.168.10.33 255.255.255.240
no ip split-horizon
duplex auto
speed auto
end

Matise#sh run | b r r
router rip
version 2
network 172.19.0.0
no auto-summary

===================================================================

Dali#interface Loopback0

ip address 192.168.60.1 255.255.255.0

!

interface Loopback1

ip address 192.168.70.1 255.255.255.0

!

interface Loopback2

ip address 192.168.80.1 255.255.255.0

!

interface FastEthernet0/0

no ip address

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 172.19.35.1 255.255.255.128

duplex auto

speed auto

!

router rip

version 2

network 172.19.0.0

network 192.168.60.0

network 192.168.70.0

network 192.168.80.0

no auto-summary

Dali#show ip rip dat
172.19.0.0/16    auto-summary
172.19.35.0/25    directly connected, FastEthernet0/1
192.168.60.0/24    auto-summary
192.168.60.0/24    directly connected, Loopback0
192.168.70.0/24    auto-summary
192.168.70.0/24    directly connected, Loopback1
192.168.80.0/24    auto-summary
192.168.80.0/24    directly connected, Loopback2
Dali#
*Jan 19 18:59:33.334: RIP: sending v2 update to 224.0.0.9 via Loopback0 (192.168.60.1)
*Jan 19 18:59:33.334: RIP: build update entries
*Jan 19 18:59:33.334:   172.19.35.0/25 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:59:33.334:   192.168.70.0/24 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:59:33.334:   192.168.80.0/24 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:59:33.334: RIP: ignored v2 packet from 192.168.60.1 (sourced from one of our addresses)show ip route rip
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

Dali#

I am seeing following debugs on Mattise router.

Matise(config-router)#
*Jan 19 18:50:25.710: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1/0 (172.19.35.15)
*Jan 19 18:50:25.710: RIP: build update entries - suppressing null update

*Jan 19 18:50:30.370: RIP: received v2 update from 172.19.35.1 on FastEthernet0/1/0
*Jan 19 18:50:30.370:      192.168.60.0/24 via 0.0.0.0 in 1 hops
*Jan 19 18:50:30.370:      192.168.70.0/24 via 0.0.0.0 in 1 hops
*Jan 19 18:50:30.374:      192.168.80.0/24 via 0.0.0.0 in 1 hops
*Jan 19 18:50:55.070: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1/0 (172.19.35.15)
*Jan 19 18:50:55.070: RIP: build update entries - suppressing null update
*Jan 19 18:50:58.778: RIP: received v2 update from 172.19.35.1 on FastEthernet0/1/0
*Jan 19 18:50:58.778:      192.168.60.0/24 via 0.0.0.0 in 1 hops
*Jan 19 18:50:58.778:      192.168.70.0/24 via 0.0.0.0 in 1 hops
*Jan 19 18:50:58.778:      192.168.80.0/24 via 0.0.0.0 in 1 hops
*Jan 19 18:51:21.654: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1/0 (172.19.35.15)
*Jan 19 18:51:21.654: RIP: build update entries - suppressing null update

Dali#debug ip rip

RIP protocol debugging is on

Dali#

*Jan 19 18:51:12.706: RIP: sending v2 update to 224.0.0.9 via Loopback2 (192.168.80.1)

*Jan 19 18:51:12.706: RIP: build update entries

*Jan 19 18:51:12.706: 172.19.35.0/25 via 0.0.0.0, metric 1, tag 0

*Jan 19 18:51:12.706: 192.168.60.0/24 via 0.0.0.0, metric 1, tag 0

*Jan 19 18:51:12.706: 192.168.70.0/24 via 0.0.0.0, metric 1, tag 0

*Jan 19 18:51:12.706: RIP: ignored v2 packet from 192.168.80.1 (sourced from one of our addresses)

*Jan 19 18:51:17.818: RIP: sending v2 update to 224.0.0.9 via Loopback0 (192.168.60.1)

*Jan 19 18:51:17.818: RIP: build update entries

*Jan 19 18:51:17.818: 172.19.35.0/25 via 0.0.0.0, metric 1, tag 0

*Jan 19 18:51:17.818: 192.168.70.0/24 via 0.0.0.0, metric 1, tag 0

*Jan 19 18:51:17.818: 192.168.80.0/24 via 0.0.0.0, metric 1, tag 0

*Jan 19 18:51:17.818: RIP: ignored v2 packet from 192.168.60.1 (sourced from one of our addresses)

*Jan 19 18:51:20.018: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (172.19.35.1)

*Jan 19 18:51:20.018: RIP: build update entries

*Jan 19 18:51:20.018: 192.168.60.0/24 via 0.0.0.0, metric 1, tag 0

*Jan 19 18:51:20.018: 192.168.70.0/24 via 0.0.0.0, metric 1, tag 0

*Jan 19 18:51:20.018: 192.168.80.0/24 via 0.0.0.0, metric 1, tag 0Dali#debug ip rip
RIP protocol debugging is on

Dali#
*Jan 19 18:51:12.706: RIP: sending v2 update to 224.0.0.9 via Loopback2 (192.168.80.1)
*Jan 19 18:51:12.706: RIP: build update entries
*Jan 19 18:51:12.706:   172.19.35.0/25 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:51:12.706:   192.168.60.0/24 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:51:12.706:   192.168.70.0/24 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:51:12.706: RIP: ignored v2 packet from 192.168.80.1 (sourced from one of our addresses)
*Jan 19 18:51:17.818: RIP: sending v2 update to 224.0.0.9 via Loopback0 (192.168.60.1)
*Jan 19 18:51:17.818: RIP: build update entries
*Jan 19 18:51:17.818:   172.19.35.0/25 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:51:17.818:   192.168.70.0/24 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:51:17.818:   192.168.80.0/24 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:51:17.818: RIP: ignored v2 packet from 192.168.60.1 (sourced from one of our addresses)
*Jan 19 18:51:20.018: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (172.19.35.1)
*Jan 19 18:51:20.018: RIP: build update entries
*Jan 19 18:51:20.018:   192.168.60.0/24 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:51:20.018:   192.168.70.0/24 via 0.0.0.0, metric 1, tag 0
*Jan 19 18:51:20.018:   192.168.80.0/24 via 0.0.0.0, metric 1, tag 0

Edison Ortiz · ‎01-19-2012

Matise has received RIP updates

Jan 19 18:50:30.370: RIP: received v2 update from 172.19.35.1 on FastEthernet0/1/0

*Jan 19 18:50:30.370: 192.168.60.0/24 via 0.0.0.0 in 1 hops

*Jan 19 18:50:30.370: 192.168.70.0/24 via 0.0.0.0 in 1 hops

*Jan 19 18:50:30.374: 192.168.80.0/24 via 0.0.0.0 in 1 hops

and those should be in the routing table.

If they aren't, something is wrong with your IOS version.

Edison Ortiz · ‎01-19-2012

Your configuration looks fine because it worked for me, I suspect physical connection issues. You can also turn 'debug ip rip' and examine the output

R1

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

ip address 172.16.1.1 255.255.255.0

no ip split-horizon

duplex auto

speed auto

!

router rip

redistribute connected

network 172.16.0.0

R1#sh ip route rip

R 1.0.0.0/8 [120/2] via 172.16.1.2, 00:00:07, FastEthernet0/0

2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

R 2.0.0.0/8 is possibly down,

routing via 172.16.1.2, FastEthernet0/0

R 192.168.1.0/24 [120/1] via 172.16.1.2, 00:00:07, FastEthernet0/0

R2:

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

ip address 172.16.1.2 255.255.255.0 secondary

ip address 192.168.1.2 255.255.255.0

no ip split-horizon

duplex auto

speed auto

!

router rip

redistribute connected

network 172.16.0.0

R2#sh ip route rip

1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

R 1.0.0.0/8 [120/2] via 172.16.1.1, 00:00:05, FastEthernet0/0

R 2.0.0.0/8 [120/2] via 172.16.1.1, 00:00:05, FastEthernet0/0

Peter Paluch · ‎01-19-2012

Edison,

You are most probably right. However, are there not issues involved with redistributing VLSM-subnetted networks into RIPv1 and advertising them in RIPv1? I have not tried that personally. I think I even saw a document on Cisco website about redistributing classless networks into classful routing protocols but cannot find it right now...

Best regards,

Peter

Edison Ortiz · ‎01-19-2012

RIPv1 is an 'issue' altogether but I don't think the OP is looking for Best Practices.

He is just simply playing around on this lab and see how things work (see the screenshot - he is working out of a workbook)

His design should allow him to exchange RIP routes, now - how well his design is? that's another thread.

Peter Paluch · ‎01-19-2012

Edison,

Agree 100%. With your kind permission, I'll withdraw from this thread, as I've been somewhat hasty in my first answer and you have taken the better approach to the OP's problem.

Best regards,

Peter

Edison Ortiz · ‎01-19-2012

Peter, no need to withdraw over a misunderstanding. Your participation is appreciated

g.mundell · ‎01-19-2012

This is a funny one. As Edison says, I don't see why this isn't working! I have also labbed it up and got it working, using RIP v1. The only issue I found is that on Dali, the "network 192.168.0.0" statement under RIP did NOT advertise out the networks - I had to add the appropriate networks, rather than using the supernet. Which I don't remember having read anywhere previously, although I think from memory RIP is the one protocol that won't let you configure a summary greater than the major network, so maybe this is related.

As Edison says, Mattise is receiving RIP updates for 192.168.60.0/24, 192.168.70.0/24 and 192.168.80.0/24. So why isn't it adding them to the route table? Could you try doing "debug ip routing" and "debug ip rip", then clearing the routing table on Mattise and post the results?