[CentOS] RIPd not announcing routes (CentOS 5.4)

Tue Dec 1 10:27:46 UTC 2009
Timo Schoeler <timo.schoeler at riscworks.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

yesterday I sent this eMail to quagga mailing list, however I didn't
receive an answer yet. Unfortunately, I really need this stuff running
or have to switch to another strategy achieving the goals.

Maybe one of you has some experience on this topic and can shed some
light on it -- I really appreciate it.

- -----8<-----8<-----8<-----

I have a setup here that requires me to announce dynamic route that are
created (within some virtual machines) on my CentOS-based machine.

Config looks like this:

(ripd.conf)
!
hostname bla.foo.org
password something
enable password somethingother
log file /var/log/quagga/ripd.log
debug rip events
!
router rip
~ version 2
~ redistribute kernel
~ passive-interface default
~ network eth1.123
~ network eth1.124
!
~ no passive-interface eth1.123
~ no passive-interface eth1.124
!
line vty
!

Now, the problem is that it seems to distribute its routes (as my Cisco
network guy told me), but it does not learn the routes announced by the
(Cisco) neighbours: The speaks to a bunch of Cisco routers (which do,
among OSPF and BGP routing, redistriubution of lots of stuff via RIPv2,
which should feed my machines).

The logfile (as configured above in the config) seems okay (except a
"RIP: update timer fire!" entry every now and then):

2009/11/30 10:16:47 RIP: RIPd 0.98.6 starting: vty at 2602
2009/11/30 10:16:47 RIP: turn on eth1.123
2009/11/30 10:16:47 RIP: Redistribute new prefix x.x.x.x/14 on the
interface eth1.123
2009/11/30 10:16:47 RIP: triggered update!
2009/11/30 10:16:47 RIP: turn on eth1.124
2009/11/30 10:16:47 RIP: Redistribute new prefix y.y.y.y/16 on the
interface eth1.124
2009/11/30 10:16:48 RIP: multicast join at eth1.123
2009/11/30 10:16:48 RIP: multicast request on eth1.123
2009/11/30 10:16:48 RIP: SEND to  224.0.0.9.520
2009/11/30 10:16:48 RIP: multicast join at eth1.124
2009/11/30 10:16:48 RIP: multicast request on eth1.124
2009/11/30 10:16:48 RIP: SEND to  224.0.0.9.520
2009/11/30 10:16:48 RIP: RECV packet from z.z.z.1 port 520 on eth1.123
2009/11/30 10:16:48 RIP: RECV packet from z.z.z.2 port 520 on eth1.123
2009/11/30 10:16:48 RIP: RECV packet from z.0.0.3 port 520 on eth1.123
2009/11/30 10:16:48 RIP: RECV packet from z.z.z.121 port 520 on eth1.124
2009/11/30 10:16:48 RIP: RECV packet from z.z.z.122 port 520 on eth1.124
2009/11/30 10:16:48 RIP: RECV packet from z.z.z.123 port 520 on eth1.124
...

A 'sh ip rip status' shows me following:

QUAGGA# sh ip rip status
Routing Protocol is "rip"
~  Sending updates every 30 seconds with +/-50%, next due in 28 seconds
~  Timeout after 180 seconds, garbage collect after 120 seconds
~  Outgoing update filter list for all interface is not set
~  Incoming update filter list for all interface is not set
~  Default redistribution metric is 1
~  Redistributing: kernel
~  Default version control: send version 2, receive version 2
~    Interface        Send  Recv   Key-chain
~    eth1.123         2     2
~    eth1.124         2     2
~  Routing for Networks:
~    eth1.123
~    eth1.124
~  Routing Information Sources:
~    Gateway          BadPackets BadRoutes  Distance Last Update
~    z.z.z.1                60         0       120   00:00:16
~    z.z.z.3                60         0       120   00:00:22
~    z.z.z.2                60         0       120   00:00:25
~    z.z.z.6                67         0       120   00:00:05
~    z.z.z.5                69         0       120   00:00:28
~    z.z.z.121             68         0       120   00:00:22
~    z.z.z.123             68         0       120   00:00:16
~    z.z.z.122             69         0       120   00:00:10
~    z.z.z.7                61         0       120   00:00:11
~    z.z.z.6             4423         0       120   00:00:27
~    z.z.z.5             5556         0       120   00:00:00
~    z.z.z.7             3460         0       120   00:00:09
~  Distance: (default is 120)

So, I got a *lot* of BadPackets. tcpdump shows nothing 'weird', so I
don't see the problem. Maybe this is something trivial but I don't see
it as I'm new to quagga. Help greatly appreciated.

Best regards,

Timo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFLFO+ifg746kcGBOwRAsvOAJ9jSJ2vJ6Ir02N7DB1tWHgsPR6LCQCgnT1O
j1B+IbniBypTttFLcwmCHlk=
=ZuLM
-----END PGP SIGNATURE-----