Hi @mentalrey, If you don't use the HTTP protocol, you need to use the L4XNAT farm. This profile doesn't inspect information in the application layer, such as domain names; the only way to do this is to assign a different virtual IP per domain. Another option is to use a different TCP-UDP port range per domain to continue using the same virtual IP. 

I hope this helps you. 

Regards!

@emiliocm tnks for the reply

L4XNAT farm can be an option, no http is involved only RTSP on Tcp and Udp for video and audio stream.

The port range is untouchable, because "for now i hope" is hardwired into the code by Nvidia in client and server too,

i have to understandt if this part "assign a different virtual IP per domain" can be done inside skudonet.

Ok, thanks for the update.

Regarding to

Posted by: @mentalrey

↑

i have to understandt if this part "assign a different virtual IP per domain" can be done inside skudonet.

 

What I propose is the following: 

eth0: 192.168.0.1 / 255.255.255.0 

eth0:1 192.168.0.10

eth0:2 192.168.0.11

DNS resolution for cxr1.domain.com should be 192.168.0.10

DNS resolution forcxr2.domain.com should be 192.168.0.11

L4XNAT farm name cxr1 with Virtual IP 192.168.0.10 and required virtual Ports

L4XNAT farm name cxr2 with Virtual IP 192.168.0.11 and required virtual Ports. 

Regards!

it's Something like in the image attached correct?

Hi @mentalrey, That is correct. You reserve a Virual IP per cxr service. 

I hope this configuration fits your requirements

installed and tested,
but something doesn't fit

the server is on 192.168.2.20 and farm on .21, if i try to point .21 never happen.

I also tried indicating TCP and port 48010 (in farm and backend too), but in that case I think the system does not provide the UDP ports which are then in the queue for that call.

Hi @mentalrey, the farm configuration seems to be OK; you are using snat with ALL ports and protocols. So any TCP/UDP request port to the VIP 192.168.2.20 will be forwarded to the backend 192.168.2.21. 

Try to do some tests using a client out of the load balancer in the same network with telnet, a telnet to a TCP backend should work as well through the load balancer. 

if this test doesn't work please share with us screenshot of results and later execute the following command in the load balancer

nft list ruleset

and share the output with us. 

Regards!

Also you can capture traffic in the backend to confirm if the traffic is  reaching it. 

Hi Emilio,

solved with in a custom way.

Skudonet: 192.168.2.20

cxr Farm: 192.168.2.21

Real server: 192.168.2.9

The connection to cloudxr use 6 ports, than seems that skudonek calculate every port

as a connection. With the rule max 6 connection, a client work fine.

And a custom tcp check based on netcat and fixed port 48010 it's the key for to have the right balance.

The downside of this conf with the use of "ALL" protocols is that i have to put Skudonet behind a

reverse proxy like Traefik for to use a single Public IP (not the best latency solution),

because if i put skudonet in front, i have to do a new virtual ip for to route the others call,

equal to 2 public IP.

Next step is to test if is possible to create separate farm for cloudxr TCP and cloudXR UDP

for the routing and the use of a single IP

Thanks for the update. 

I would never recommend using a Layer7 load balancer for Protocols in real time (RTSP) as the latency is going to be increased. SKUDONET L4XNAT works at Kernel level, moving packets fast like a firewall.

For further help, please let us know. 

Regards!