Routing mixed protocols on external machines

Traefik Traefik v3 (latest)
,
1

Hi
the config below seems functional for a single server
but i'm stuck on balancing non http calls.
First : traefik is installed on docker, but i have two external machine with the same CloudXR service (fixed network ports)
is a new XR service that for now need six ports,
1 in rtsp (TCP) for the connection and
5 in udp for transactions,
all for a single client connection.

In traefik a TCP with SNI seems not possible without TLS, but rtsp do not use tls.
An healthcheck on the TCP connection could be useful (i can temporarely shutdown the service on one of the external machine for to set as "non part of the balance) but in the documentation is not clear if in traefik 3 is possible.

I tried adding an http service so I can drop one of the ip addresses if the service is down, but I don't know if this is also reflected in the tcp and udp configurations.

# -- HTTP routing
http:
  routers:
# --
    cxr-https:
      entrypoints:
        - websecure
      tls:
        true:
      rule: Host(`cxr.somedomain.org`)
      service: cxr-https
# --
  services:
    cxr-https:
      loadBalancer:
        healthcheck:
          path: /
          port: 8000
          interval: 2s
        sticky:
         cookie:
           httpOnly: false
           name: lvl2
           secure: true
           sameSite: strict
        servers:
        - url: http://192.168.1.2:8000
        - url: http://192.168.1.3:8000

# --------------------------------------
# --  TCP routing
tcp:
  routers:
    cxr-rtmp:
      entrypoints:
        - cxr-rtmp
      service: cxr-rtmp
      rule: HostSNI(`*`)
  services:
    cxr-rtmp:
      loadBalancer:
        servers:
        - address: 192.168.1.2:48010
        - address: 192.168.1.3:48010

# --------------------------------------
# --  UDP routing
udp:
  routers:
    cxr47999:
      entrypoints:
        - cxr47999
      service: cxr47999
    cxr48000:
      entrypoints:
        - cxr48000
      service: cxr48000
    cxr47998:
      entrypoints:
        - cxr47998
      service: cxr47998
    cxr48005:
      entrypoints:
        - cxr48005
      service: cxr48005
    cxr48002:
      entrypoints:
        - cxr48002
      service: cxr48002

  services:
    cxr47999:
      loadBalancer:
        servers:
        - address: 192.168.1.2:47999
        - address: 192.168.1.3:47999
    cxr48000:
      loadBalancer:
        servers:
        - address: 192.168.1.2:48000
        - address: 192.168.1.3:48000
    cxr47998:
      loadBalancer:
        servers:
        - address: 192.168.1.2:47998
        - address: 192.168.1.3:47998
    cxr48005:
      loadBalancer:
        servers:
        - address: 192.168.1.2:48005
        - address: 192.168.1.3:48005
    cxr48002:
      loadBalancer:
        servers:
        - address: 192.168.1.2:48002
        - address: 192.168.1.3:48002
2

Not sure if this will work at all.

UDP is stateless, without a session. So Traefik will forward a UDP packet, it will have Traefik as sender.

So unless the client's own IP is encoded within the proprietary packet content, the application will not be able to send return UDP packets to the right IP.

I think there are special proxies able to handle UDP packets.

Further note that with TCP and UDP you don’t have the cookie, so the matching to the target service is random and can change for every request/packet. Don’t know if your application also requires the same server to be connected like for http.

3

hi
thnks for the reply.

it's Nvidia CloudXR, a system where you can connect your Headmount (like a meta quest)
to a remote server that can calculate graphics for you.
This way you eliminate the problem of the power variables of the various devices,
since the server that performs the calculations is always the same
and can afford a different level GPUs.

The actual problem is that the software has the ports wired in the code, yet in client and server,
than seems (to me) the only solution is to balance with a healtcheck on pool of ip, start only the server needed, or with a number of public ip equal to the servers...

4

From the doc and the mention of minimal hops, latency and fast ethernet connection, I would expect it’s not made for a proxy server in between.

5

it's a service that have a good latency control over 5G network,
and yet tested many times over a Quest2/3 connected in wifi to a 5G CPE router with a cloudxr server in an edge datacenter. Possibly the proxy/gateway is the lesser latency creator.
The real problem now are the fixed network ports