|
On Sat, Apr 09, 2016 at 01:13:02PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 5 Apr 2016, Marco Angaroni wrote:
>
> > When using LVS-NAT and SIP persistence-egine over UDP, the following
> > limitations are present with current implementation:
> >
> > 1) To actually have load-balancing based on Call-ID header, you need to
> > use one-packet-scheduling mode. But with one-packet-scheduling the
> > connection is deleted just after packet is forwarded, so SIP responses
> > coming from real-servers do not match any connection and SNAT is
> > not applied.
> >
> > 2) If you do not use "-o" option, IPVS behaves as normal UDP load
> > balancer, so different SIP calls (each one identified by a different
> > Call-ID) coming from the same ip-address/port go to the same
> > real-server. So basically you don’t have load-balancing based on
> > Call-ID as intended.
> >
> > 3) Call-ID is not learned when a new SIP call is started by a real-server
> > (inside-to-outside direction), but only in the outside-to-inside
> > direction. This would be a general problem for all SIP servers acting
> > as Back2BackUserAgent.
> >
> > This patch aims to solve problems 1) and 3) while keeping OPS mode
> > mandatory for SIP-UDP, so that 2) is not a problem anymore.
> >
> > The basic mechanism implemented is to make packets, that do not match any
> > existent connection but come from real-servers, create new connections
> > instead of let them pass without any effect.
> > When such packets pass through ip_vs_out(), if their source ip address and
> > source port match a configured real-server, a new connection is
> > automatically created in the same way as it would have happened if the
> > packet had come from outside-to-inside direction. A new connection template
> > is created too if the virtual-service is persistent and there is no
> > matching connection template found. The new connection automatically
> > created, if the service had "-o" option, is an OPS connection that lasts
> > only the time to forward the packet, just like it happens on the
> > ingress side.
> >
> > The main part of this mechanism is implemented inside a persistent-engine
> > specific callback (at the moment only SIP persistent engine exists) and
> > is triggered only for UDP packets, since connection oriented protocols, by
> > using different set of ports (typically ephemeral ports) to open new
> > outgoing connections, should not need this feature.
> >
> > The following requisites are needed for automatic connection creation; if
> > any is missing the packet simply goes the same way as before.
> > a) virtual-service is not fwmark based (this is because fwmark services
> > do not store address and port of the virtual-service, required to
> > build the connection data).
> > b) virtual-service and real-servers must not have been configured with
> > omitted port (this is again to have all data to create the connection).
> >
> > Signed-off-by: Marco Angaroni <marcoangaroni@xxxxxxxxx>
>
> Nice addition, thanks! Simon, please apply.
>
> Acked-by: Julian Anastasov <ja@xxxxxx>
Thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
