3 ms·

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.

by dijit 7mo 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-your-friend/ https://www.tigera.io/blog/when-linux-conntrack-is-no-longer...

yjftsjthsd-h 7mo ago
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 7mo ago
  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-client/networking/tcp-ip-port-exhaustion-troubleshooting#default-dynamic-port-range-for-tcpip https://learn.microsoft.com/en-us/troubleshoot/windows-clien...
  - yjftsjthsd-h 7mo ago
    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 7mo ago
      it’s interesting because I think youve internalised the constraint and built mechanisms around it rather than engaging directly with it, subconsciously.
      - yjftsjthsd-h 7mo ago
        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.

by dijit 7mo ago

yjftsjthsd-h 7mo ago

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 7mo ago
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-client/networking/tcp-ip-port-exhaustion-troubleshooting#default-dynamic-port-range-for-tcpip https://learn.microsoft.com/en-us/troubleshoot/windows-clien...
- yjftsjthsd-h 7mo ago
  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 7mo ago
    it’s interesting because I think youve internalised the constraint and built mechanisms around it rather than engaging directly with it, subconsciously.
    - yjftsjthsd-h 7mo ago
      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.