Hello Joe,
On Fri, 6 Apr 2001, Joseph Mack wrote:
> > With this patch applyed the template is changed only to the
> ^^^^
> > fwmark-based services.
>
> you say "only" here, like the template is only going to use fwmarks
"only for", sorry.
We have such persistence templates:
CIP:* -> VIP:VPORT -> RIP:RPORT VIP:VPORT service
CIP:* -> VIP:0 -> RIP:* VIP:0 (catch-all) service
FWMARK
Now:
CIP:* -> VIP:0 -> RIP:*
After the patch:
CIP:* -> FWMARK:0 -> RIP:*
> Then we have both kinds of templates in the
> > connection table. And they don't collide.
>
> here you say there are both kinds of templates in the connection table.
>
> Can you clarify this for me?
The templates are Proto,CIP,CPORT,VIP,VPORT,RIP,RPORT entry.
VIP:VPORT and FWMARK used as Virtual Service key:
1. *** -> VIP:VPORT -> ***
2. *** -> FWMARK:0 -> ***
> But this feature uses the
> > fact the 0.0.0.0/8 network is not used and the fwmarks are in the
> > range of 1 - 2^24-1.
Ops, my mistake, 0.0.0.0/4. And the FWMARK templates can't
collide with the normal because they are created with proto IP, the
normal are created with proto UDP/TCP. So, any FWMARK values can be
used.
> I don't understand what this is about. You are using some coding trick
> here that I don't need to know about? Can I use -d 0.0.0.0/0 for a target
> in the iptables rules (eg if a real-server is a transparent web cache,
> where I would be using an iptables rule of --dport 80 in the director,
> so that the director would forward any http packets)?
Yes, you can use any addresses.
> If the fwmark is not in this range these templates
> > can collide with the normal VIP templates.
>
> you are saying that the templates don't collide now.
> What if I deliberately setup a VIP rule and an
> ipchains/fwmarks rule that both accept the same connection?
> (presumably someone will do this, without realising
> what they have done)
The fwmark-based service will accept it.
> > > Are people expecting the original behaviour now
> > > or are they not aware of the choices?
> >
> > I assume nobody tried such setups. May be only Ted Pavlic?
> >
> > http://marc.theaimsgroup.com/?l=linux-virtual-server&m=96542157330362&w=2
>
> yes I know this posting. This is why I thought that Ted's use of
> fwmarks was the standard use. How did he get it to work if the standard
> ip_vs code has the VIP-fwmark collision problem?
Not sure but may be Ted is now busy with other things and LVS
is in background :)))
> > Yes, the persistence for fwmark-based services covers all ports
> > to one VIP and this is a problem. This is the reason the above feature
> > to help for such setups. But for now we don't see more problems with
> > the feature enabled except the load imbalance.
>
> I haven't seen this problem. What does it look like?
>
> But that depends on
> > the used scheduling and the cluster software too. And this feature
> > clearly isolates the traffic when some of the fwmark-based services
> > share same Virtual Addresses (with different ports) but with different
> > real servers where the problem can be visible (traffic sent to the
> > wrong virtual service hits innocent real server).
>
> These problems aren't obvious to me. Can you explain this some more?
Currently, when the first packet comes for persistent fwmark
service the kernel creates template CIP:0,VIP:0,RIP:0. But if you have
two fwmark-based virtual services that use same virtual IP and the
client accesses these two persistent fwmark services, the kernel will
create only one template for this client host. Then when the next packet
comes the lookup finds the template (for the service which created it).
The lookup looks for CIP:0, VIP:0, any RIP and any RPORT. This lookup
can match any template created for this CIP to our VIP. And in our
case instead of two different, we create only one template. So, all
packets from the client go to the real server of the first added
template with same CIP and VIP. The problem is that the two fwmark
services use same VIP and the traffic can be forwarded to the wrong
fwmark service. With this patch we want the two services to create
two different templates when they use same VIPs:
CIP:0,FWMARK_A:0,RIP_A_1
CIP:0,FWMARK_B:0,RIP_B_1
> > So, may be it is a time we to discuss it again. Cons/Pros?
>
> sure. After Ted's posting, I thought the specs were set for fwmarks.
>
> Joe
Regards
--
Julian Anastasov <ja@xxxxxx>
|