I must be slow today. I have read over your analysis many times, but I am still not understanding this. Let’s continue to use your range of 10 addresses for the example.
If I take the entire set of 10. addresses, and run them through the ACL_ODDEVEN filter, just one is left:
10.1.0.1
If I take the entire set of 10. addresses, and run them through the ACL_COMBO filter, a total of four is left (which is what you found above):
10.0.0.1
10.1.0.1 <------ Also the result of ACL_ODDEVEN
10.1.1.1
10.2.0.1
If we look at the results of the ACL_COMBO in binary (just the 2nd and 3rd octet):
00000000 00000000 <------ This should have been filtered
00000001 00000000 <------ Correct, also the result of ACL_ODDEVEN
00000001 00000001 <------ This should have been filtered
00000010 00000000 <------ This should have been filtered
I have bolded the bits that would have caused the set of numbers above to have failed ACL_ODDEVEN. The question is why isn’t ACL_COMBO also failing these? Is there some kind of logic change between these?
#1 (ACL_ALLOWODDEVEN, essentially)
----------------------------
deny 0.0.0.0 255.254.255.255
deny 0.0.1.0 255.255.254.255
----------------------------
#2 (ACL_Combo, essentially)
----------------------------
deny 0.0.1.0 255.254.254.255
----------------------------
#1 looks for an exact match of the least significant bit of the 2nd octet for the first line, then
looks for an exact match of the least significant bit of the 3rd octet for the second line.
#2 looks for an exact match of the least significant bit of both the 2nd and 3rd octet.
So in both cases, an exact value is being matched on in the second and third octet. The difference is #1 does it in two statements, while #2 does it in one statement.
In the lab, these two behave differently.