-
Notifications
You must be signed in to change notification settings - Fork 2
Description
See test .../tests/istio_testcases/example_policies/testcase2/testcase2-istio-scheme.yaml, the difference between istio6 and istio7 configs.
In istio6 the action is 'ALLOW', and thus the only allowed sources connected to the selected peers are those explicitly defined in the policy rules. Since IP blocks are not mentioned in the rules, they are not connected to the selected peers.
In istio7, on the other hand, the action is 'DENY'. and thus all connections to the selected peers are allowed except of those mentioned in the policy rules. Since only IPv4 blocks are mentioned in the policy, all the rest (IPv6) blocks are connected to the selected peers.
Thus, the connectivity maps of istio6 and istio7 differ by IPv6 block (this difference may be observed when setting the option excludeIPv6Range to false (by default it is true and the difference cannot be observed).
This change in the connectivity maps is observed due to the inclusion of all IPs block in peers to compare, as follows:
ref_ip_blocks = IpBlock.disjoint_ip_blocks(self.config.get_referenced_ip_blocks(exclude_ipv6),
IpBlock.get_all_ips_block_peer_set(exclude_ipv6), exclude_ipv6)
However, in the equivalence query, peers to compare are calculated as follows (in the function disjoint_referenced_ip_blocks)
IpBlock.disjoint_ip_blocks(self.config1.get_referenced_ip_blocks(exclude_ipv6),
self.config2.get_referenced_ip_blocks(exclude_ipv6), exclude_ipv6)
Thus, the EquivalenceQuery returns that istio6 and istio7 configs are equivalent, even when the excludeIPv6Range is false.
This inconsistency between ConnectivityMapQuery and EquivalenceQuery is misleading and should be resolved in either way.