EDGECLOUD-5230: Envoy crashing for UDP packet size larger than 1500

[ashxjain]

Issues Fixed

• EDGECLOUD-5230: Envoy crashing for UDP packet size larger than 1500

Description

• This issue was faced by CloudSLAM. Their Android App was sending UDP packets of size 3088 and it was crashing envoy. We were hitting this bug:
  crash when udp packet size large than 1500 envoyproxy/envoy#14113
• This was fixed in envoy version 1.15.3, but it was still dropping UDP packets with size > 1500. They added support to set max datagram size as part of version 1.18.x. But 1.18.x transitioned to v3 API and we are using v2 API. Have updated the code to use v3 API and also envoy version 1.18.x
• Have added pktsize config to specify datagram size for UDP ports. Note: using value > 1500 means envoy will allocate more memory, hence set it only for those ports which require this configuration
• We won't need UI support for this, as it will be used very rarely (as of now only by CloudSLAM). We can document it so that users can use CLI for setting it up
• Added debug command to get the list of envoy versions used by RootLBs. Sample output:

sharedrootlb: test.test.net
  container: envoycloudslam1341-stable14ub1804
    envoy  version: 98c1c9e9a40804b93b074badad1cdf284b47d58b/1.18.3/Clean/RELEASE/BoringSSL
  container: envoycloudslam1341-stable
    envoy  version: 98c1c9e9a40804b93b074badad1cdf284b47d58b/1.15.3/Clean/RELEASE/BoringSSL

dedicatedredrootlb: test121.test.net
  container: envoycloudslam1341-stable14ub1804
    envoy  version: 98c1c9e9a40804b93b074badad1cdf284b47d58b/1.18.3/Clean/RELEASE/BoringSSL
  container: envoycloudslam1341-stable
    envoy  version: 98c1c9e9a40804b93b074badad1cdf284b47d58b/1.15.3/Clean/RELEASE/BoringSSL

[gainsley]

So this will only affect new deployments, right? I might suggest adding some way for us to determine at runtime which version of envoy each AppInst is using, in case they still hit the issue, so we can verify if they recreated their AppInst and have the correct envoy version. A crm debug cmd would probably be sufficient.

[ashxjain]

So this will only affect new deployments, right? I might suggest adding some way for us to determine at runtime which version of envoy each AppInst is using, in case they still hit the issue, so we can verify if they recreated their AppInst and have the correct envoy version. A crm debug cmd would probably be sufficient.

Yes, it will only affect new deployments. For cloudSLAM, they can re-create their cluster and none of our other developers have this problem.

Sure, debug cmd makes sense. I will add it. Thanks!

[gainsley]

Looks good!

[gainsley]

Thanks!