| ▲ | dijit 20 hours ago |
| Well, if you've set it up then you're aware that you need conntrack; Conntrack is not always your friend, and even when it is: it's adding a lot of overhead. https://www.tigera.io/blog/when-linux-conntrack-is-no-longer... |
|
| ▲ | yjftsjthsd-h 20 hours ago | parent [-] |
| Well yes, a stateful NAT is stateful. But as that article notes: > For most workloads, there’s plenty of headroom in the table and this will never be an issue. And yes, if you're doing thousands of connections per second then you should evaluate things more carefully for performance, but again... That's rather a lot. |
| |
| ▲ | dijit 19 hours ago | parent [-] | | It's interesting that you'd think that. Connection table of a single IP is as high (by default) as 16,383[0]. I've hit this limit personally, and due to limitations in stateful firewalling we had to move to stateless filters inside our network equipment instead. [0]: https://learn.microsoft.com/en-us/troubleshoot/windows-clien... | | |
| ▲ | yjftsjthsd-h 18 hours ago | parent [-] | | It's interesting that I agree with the article that you linked? I'm not contesting that it's completely possible to hit the limits in play, but 16k connections (per IP) is high enough that I don't think that's a common problem, even in public-facing web services. Granted, I suspect the services I've run professionally all dealt with it by making it the problem of a load balancer in front of the application and internal network, but... you probably have that anyways, so I'm still not seeing the problem. | | |
| ▲ | dijit 18 hours ago | parent [-] | | it’s interesting because I think youve internalised the constraint and built mechanisms around it rather than engaging directly with it, subconsciously. | | |
| ▲ | yjftsjthsd-h 17 hours ago | parent [-] | | I'm not sure why that would be interesting either, but no, it's not a constraint I've ever hit so I doubt that I'd bother avoiding it, subconsciously or otherwise. |
|
|
|
|
