Re: [patch v2 03/12] [PATCH 03/12] IPVS: compact ip_vs_sched_persist()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




	Hello,

On Sat, 2 Oct 2010, Simon Horman wrote:

	I'm still wondering, may be it needs separate patch
but we do not support NAT to different dest->port in the
case for fwmark. May be the above logic can be changed to
support it. By this way web to different VIPs and VPORTs
in a single virtual service (fwmark) can use single NAT
real server for name-based virtual hosting. But such change
can create compatibility problems for setups that used
different vports for the fwmark service and still expect
it in that way (vport to same dport).

Hi Julian,

I think that this sounds line a new flavour of fwmark virtual services to me.
Perhaps yet another flag is in order?

To be clear, what you have in mind is essentially to nat *:* (as matched by
a fwmark) to x:y, where as at this time *:y may be natted to x:y.

Yes, the difference is here, persistent services with fwmark ignore dest->port while non-persistent services with fwmark prefer
dest->port:

ip_vs_sched_persist:
        dport = ports[1];
        if (dport == svc->port && dest->port)
                dport = dest->port;
	- before the PE changes even dest->port=0 was selected
	for non-fwmark

ip_vs_schedule:
	dport set as: dest->port ? dest->port : pptr[1]

	It is inconsistent. If we add new option for dest
it should have 3 states:

0: default (current, compatible)
1: prefer real server port
2: keep dport in packet

	But the same can be done with rport or that was the
goal before:

- rport=0 (zero port) - keep dport from packet
- rport>0 - use this real server port

	It works perfectly for ip_vs_schedule but not for
ip_vs_sched_persist, rport>0 is ignored for persistent
fwmark and this is wrong for NAT. Persistence should just
select dest but now it changes the rport semantic. The
right thing is ip_vs_sched_persist to work as ip_vs_schedule
but it can break some setups with persistence and fwmark.

Regards

--
Julian Anastasov <ja@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux