I have a dockerized SIP application that requires a large number of ports for RTP. Since it recently became possible to expose a port range, I decided to move away from --net=host scenario to using those ranges (-p 30000-40000:30000-40000/udp)
However, when a range is large enough, docker eats up all RAM and fails:
ERRO[0230] Handler for POST /containers/{name:.*}/start returned error: Cannot start container 80df70ab22d94408e9a5a2c60590b1b1281e5a59b5531590738739c9f7c7c485: iptables failed: iptables --wait -t nat -A DOCKER -p udp -d 0/0 --dport 38207 ! -i docker0 -j DNAT --to-destination 172.17.0.3:38207: (fork/exec /sbin/iptables: cannot allocate memory)
ERRO[0230] HTTP Error: statusCode=500 Cannot start container 80df70ab22d94408e9a5a2c60590b1b1281e5a59b5531590738739c9f7c7c485: iptables failed: iptables --wait -t nat -A DOCKER -p udp -d 0/0 --dport 38207 ! -i docker0 -j DNAT --to-destination 172.17.0.3:38207: (fork/exec /sbin/iptables: cannot allocate memory)
It would seem logical to combine those ranges when applied to iptables into something like:
--dports 30000:40000, and afaik we do not need to explicitly specify the new destination ports if they're going to match the original ones. Or am I missing something?
I have a dockerized SIP application that requires a large number of ports for RTP. Since it recently became possible to expose a port range, I decided to move away from --net=host scenario to using those ranges (-p 30000-40000:30000-40000/udp)
However, when a range is large enough, docker eats up all RAM and fails:
It would seem logical to combine those ranges when applied to iptables into something like:
--dports 30000:40000, and afaik we do not need to explicitly specify the new destination ports if they're going to match the original ones. Or am I missing something?