-----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@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