Hi List,
I am afraid in the rip_output_process(), the arguments order when invoking prefix_match() is just reversed, so it looks like a bug to my understanding.
I like to explain with an example. Say, r1 as a router connects to another router r2 via it's interface nic1. r1 also has another interface nic2 which are configured with expectation to be advertised to r2. nic1 = 10.3.255.33/27 and nic2 = 10.3.255.1/24. I think it's reasonable to have r2 to understand network of 10.3.255.0/24 since its a kind of information that cannot be inferred from the r1-r2 interconnected network 10.3.255.32/27. In the other words, 10.3.255.0/24 contains more hosts that can only be reached if r2 know the route. Hence the wise of advertising from r1 is health and will not cause routing problem such as infinite looping.
But, the code in ripd.c, in the function body of rip_output_process(), the router entry 10.3.255.0/24 was intended suppressed because the checking of prefix_match((struct prefix *)p, ifc->address) returned true. In the function call, the p is 10.3.255.0/24 and ifc is 10.3.255.32/27. It returned true because p's network prefix is contained in ifc-address's prefix, in this case, 24 bits of 10.3.255.0 is contained in 10.3.255.32. I think this is not reasonable and has nothing to do with the split-horizon algorithm used in RIPv2. If it's just a bug, and we should have been invoked the checking function as rather prefix_match(ifc, p), then everything will appear understandable and clear to me.
I want to confirm, if this is a bug or not.
Cheers,
woody
I am afraid in the rip_output_process(), the arguments order when invoking prefix_match() is just reversed, so it looks like a bug to my understanding.
I like to explain with an example. Say, r1 as a router connects to another router r2 via it's interface nic1. r1 also has another interface nic2 which are configured with expectation to be advertised to r2. nic1 = 10.3.255.33/27 and nic2 = 10.3.255.1/24. I think it's reasonable to have r2 to understand network of 10.3.255.0/24 since its a kind of information that cannot be inferred from the r1-r2 interconnected network 10.3.255.32/27. In the other words, 10.3.255.0/24 contains more hosts that can only be reached if r2 know the route. Hence the wise of advertising from r1 is health and will not cause routing problem such as infinite looping.
But, the code in ripd.c, in the function body of rip_output_process(), the router entry 10.3.255.0/24 was intended suppressed because the checking of prefix_match((struct prefix *)p, ifc->address) returned true. In the function call, the p is 10.3.255.0/24 and ifc is 10.3.255.32/27. It returned true because p's network prefix is contained in ifc-address's prefix, in this case, 24 bits of 10.3.255.0 is contained in 10.3.255.32. I think this is not reasonable and has nothing to do with the split-horizon algorithm used in RIPv2. If it's just a bug, and we should have been invoked the checking function as rather prefix_match(ifc, p), then everything will appear understandable and clear to me.
I want to confirm, if this is a bug or not.
Cheers,
woody