RIPv2: Strange Rule in Advertising

Question

In the current version of Quagga on Linux, I found there is a rule which can suppress some kind routes information from advertising out to neighbor routers via RIPv2.

If router r1 connects to another router r2 via an interface 'nic0', and r1 has another interface 'nic1' connect to another network 'net1'. Then r1 hopes to advertise route to 'net1' to its neighbor r2. The network, say net0, is the network connecting r1 and r2, which is, say, 10.3.1.32/27, and the network 'net1' is, say, 10.3.1.0/24.

In this case, the route entry of 10.3.1.0/24 (via nic1) will not be sent to r2 because the RIPv2 program in Quagga internally suppressed the entry and drop it.

I checked the source code of RIPv2 of Quagga, and found that is because of a rule: 10.3.1.0/24 has a network prefix which is contained by the network prefix of 10.3.1.32/27, in other words, the leftmost 24 bits of 10.3.1.0 is a substring of the leftmost 27 bits of 10.3.1.32.

But I don't understand why there is such a rule. Is it defined by RIPv2 standard or just a quirk of Quagga? In my understanding, the overlapping between net0 and net1 is valid and should not be a problem because of the 'Longest Network Prefix Matching Rule' in routing, and to the router r2, it really need to know there exists a bigger network net1 (comparing to net0) can be reached via r1. If this route info was suppressed by Quagga, r2 will not know that and the hosts in net1 cannot be accessed from net0 from r2 side.

Is there someone who know that?

Thanks, woody

Answer 1

If the 10.3.1.0/24 network is directly connected to R1, that might pose a problem. In this case, R1 has overlapping IP addresses on both of its interfaces. I'm not a linux expert, but I know that this is not supported on Cisco routers (and I'm pretty sure it's not supported either on any other router/firewall).

If the network is not directly connected to R1 then there must be a third router in the network, let's call that one R0. R0 is directly connected to the 10.3.1.0/24 network and connects to R1 via some other network, e.g. 172.16.0.0/24. In that case the setup should work just fine. I've tested this on Cisco routers.

      10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
R        10.3.1.0/24 [120/1] via 172.16.0.101, 00:00:13, Ethernet0/1 (nic1)
C        10.3.1.32/27 is directly connected, Ethernet0/0 (nic0)

Perhaps Quagga -- although not complaining about it -- also cannot handle these overlapping IP ranges on both of its interfaces.