Closed aauren closed 6 months ago
@manuelbuil - Thanks for the quick feedback! After thinking about this just a bit more in my spare time this weekend, I feel like resetting the ipset handlers so far down in the logic tree is some day going to come back around to bite us.
So I moved it up to the entry point of the network policy enforcement loop. I tested it again in my cluster and found that the reproduction still works as expected, but I was wondering if I could trouble you to test it one more time in your setup just to make double sure that this is still doing what we want?
@manuelbuil - Thanks for the quick feedback! After thinking about this just a bit more in my spare time this weekend, I feel like resetting the ipset handlers so far down in the logic tree is some day going to come back around to bite us.
So I moved it up to the entry point of the network policy enforcement loop. I tested it again in my cluster and found that the reproduction still works as expected, but I was wondering if I could trouble you to test it one more time in your setup just to make double sure that this is still doing what we want?
Thanks! It is working for me as well :)
@mrueg / @manuelbuil
Attempts to separate IP families within the different ipset handlers. This has likely been an issue since the first dual-stack implementation was contributed, but hasn't been discovered until now. The problem was that ipset was being utilized the same way that iptables was where different handlers implicitly meant different families. However, the ipset command doesn't differentiate that way, it has one command that always contains both sets. This was likely missed during the port to dual stack that was contributed ~2 years ago.
Fixes #1665