In broadcast and multicast RIP on the same interface?, you wrote:

Is there any reason why broadcast and multicast RIP can't be run on the same interface? I haven't read the RFCs, but we'd only be using this in a student lab setting with the multicast interface in mode "quiet", so I think it should be okay.

Well, don't waste too much time on RIP. It's pretty worthless in today's enviroment, subnetting/CIDR is too common. OSPF in bird can use this sort of debugging/experimenting. About every 5-6 hours, I lose all routing for 10 minutes. Usually I chain login to the remote machine (via all the intermediate machines), restart the protocol and get connectivity back quickly. The only clue I have is: Feb 20 12:47:00 rudder bird: Netlink: Network is unreachable Feb 20 12:47:38 rudder last message repeated 6 times I suspect it is a recent 2.4 kernel change somehow, or that bird does not have a robust 'maintain the link' technique. I ran bird before in a 2.0/2.2 kernel enviroment on a T1, no problems. The above outage occurs in 2.4 kernels on a 28k modem link (the desert does not have good telephone lines). Surely the decision to declare a dead link should depend on the link speed/bandwidth? OSPF/BGP4 cover all routing needs. When someone talks about IPv6, just smile and move away slowly, it will be years before it's prime time. Upstreams have simply raised the costs of retaining IPv4 addresses, which causes customers to divest their surplus and switch to NAT systems -- classic market actions, reduced supply causes smarter demand.