1. Home
  2. Cisco Systems
  3. RIPv2 between Cisco 851 and 871

RIPv2 between Cisco 851 and 871

I have a small lab topology that can be viewed here:

formatting link

Here is what I am trying to do:

1) Get RIP v2 working between routers R1 and R2. 2) Have the routes of 192.168.1.1 and 192.168.4.1 advertised to R2.

The problem I having is that R1 has no problems receiving info from R2 but R2 has problems receiving any updates from R1.

I want to save space in this post so I haven't posted the config. Here is some debug output though:

R1 (Cisco 851)

1124912: .Mar 8 16:02:58.129 PCTime: RIP: sending v2 update to 224.0.0.9 via Vlan1 (192.168.1.1) 1124913: .Mar 8 16:02:58.129 PCTime: RIP: build update entries - suppressing null update 1124914: .Mar 8 16:02:58.129 PCTime: RIP: sending v2 update to 224.0.0.9 via Vlan1 (192.168.2.1) 1124915: .Mar 8 16:02:58.129 PCTime: RIP: build update entries - suppressing null update 1124916: .Mar 8 16:02:58.129 PCTime: RIP: sending v2 update to 224.0.0.9 via Vlan1 (192.168.4.1) 1124917: .Mar 8 16:02:58.129 PCTime: RIP: build update entries - suppressing null update 1124945: .Mar 8 16:04:39.842 PCTime: RIP: received v2 update from 192.168.2.2 on Vlan1 1124946: .Mar 8 16:04:39.846 PCTime: 192.168.3.0/24 via 0.0.0.0 in 1 hops 1124947: .Mar 8 16:04:39.846 PCTime: RIP: Update contains 1 routes

R2 (Cisco 871)

*Mar 2 10:50:18.747: RIP: sending v2 update to 224.0.0.9 via FastEthernet4 (192.168.2.2) *Mar 2 10:50:18.747: RIP: build update entries *Mar 2 10:50:18.747: 192.168.3.0/24 via 0.0.0.0, metric 1, tag 0 *Mar 2 10:50:18.747: RIP: Update contains 1 routes *Mar 2 10:50:18.747: RIP: Update queued *Mar 2 10:50:18.747: RIP: Update sent via FastEthernet4 *Mar 2 10:50:18.747: RIP: ignored v2 packet from 192.168.2.2 (sourced from one of our addresses)

I have occasionally seen an error message: RIP: ignored the request received from unlisted network.

My understanding is that all routes should be advertised between the 2 interfaces and everything should just work.

The main questions I have is:

1) Why isn't R2 receiving updates? Is there something with the 851/71 that needs to be configured differently?

My understanding is that all routes should be advertised between the 2 interfaces and everything should just work.

--Paul

Reply to
Paul
Loading thread data ...

t R2 has problems receiving any updates from

some debug output though:

.9 via Vlan1 (192.168.1.1)

essing null update

.9 via Vlan1 (192.168.2.1)

essing null update

.9 via Vlan1 (192.168.4.1)

essing null update

168.2.2 on Vlan1

.0.0 in 1 hops

net4 (192.168.2.2)

from one of our addresses)

ved from unlisted network.

terfaces and everything should just work.

t needs to be configured differently?

terfaces and everything should just work.

I have not read and studied fully all of the detail and maybe I missed something, however:-

From your diagram, the first thought is that

192.168.2.1 may be a secondary address on R1. Dynamic routing protocols do not work with secondary addresses is the model that I use.

Perhaps the source address fro the RIP from R1 is

192.168.1.1 and R2 (192.168.2.2) is ignoring the updates.

I doubt that many people read this group on 9600bps modems now so I would not worry about posting a couple of configs:)

Reply to
bod43

Yes, it is a secondary address but I've not known this to be a problem with RIP. Perhaps someone else can confirm this?

has problems receiving any updates from

some debug output though:

Vlan1 (192.168.1.1)

null update

Vlan1 (192.168.2.1)

null update

Vlan1 (192.168.4.1)

null update

192.168.2.2 on Vlan1

(192.168.2.2)

one of our addresses)

from unlisted network.

interfaces and everything should just work.

needs to be configured differently?

interfaces and everything should just work.

Reply to
Paul

RIP. Perhaps someone else can confirm this?

You might find -

formatting link
interesting. You should verify that later IOS behaviour has not changed.

I have mostly used OSPF and it ignores secondary addresses. I wonder if "redistribute connected" includes them? I was surprised to note recently (studying obsolete rubbish for cisco exams) that not all routing protocols had similar behaviour. Sadly remembering obsolete rubbish for long enough to pass is proving to be quite tough:(

Secondary addresses are in any case a horrible knudge.

Reply to
bod43

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.