|
Hi Joe,
> you must be in culture shock.
:) Yeah, but it's more a thermo shock. I had 90+ degrees in Florida
and 70 in Switzerland. And I found out that Alligators don't like me.
> > Good idea. Did you add the policy DENY to INPUT and OUTPUT chains?
>
> later, just doing the early steps first, I did it the first time and was
> frozen out of my director, apparently because my rules aren't working.
> I'll put it back in later.
It's always a good prove that netfilter really works, sometimes :)
I agree, if you're designing your firewall rules while trying to
maintain the DENY policy you have to put a --log after every rule
and a DENY rule at the end because the policy doesn't log (Rusty
is a dickhead sometimes:). Only a bunch of people out there write
down the firewall rules for a network setup, put a policy DENY and
have it working correctly :)
> > >From the iptables howto:
> > COMPATIBILITY WITH IPCHAINS
> > This iptables is very similar to ipchains by Rusty Rus
> > sell. The main difference is that the chains INPUT and
> > OUTPUT are only traversed for packets coming into the
> > local host and originating from the local host respec
> > tively. Hence every packet only passes through one of the
> > three chains; previously a forwarded packet would pass
> > through all three.
>
> I don't know whether that's an improvement or not, but it sure makes it
> hard to keep up with the changes.
I don't yet understand all of it but it helped making the whole filtering
and NAPT stuff more smooth and more flexible. You have more possibilies to
manage the traffic. If it is better has to be proven in reality, so far
there are not many setups with complex firewall settings and I mean really
complex, like merging different advanced routing aspects with QoS and own
Targets over different networks with all kind of non-TCP/UDP traffic and
an maybe IPV6 connection ... (See what happens if European people go to
America, they get all confused)
> It's in the ipchains man page I see, but it's an "unknown arg" for iptables.
I haven't checked out the most recent man-page from the cvs but I reckon
they simply forgot it and it seems that not a lot of people knew about this
nice help before.
> Yes this is just what I'm looking for (I'd forgotten what was in there).
> You can't expect me to know about these details -
I would never do that.
> I mean it's not even in the HOWTO :-)
Holy cow, this has to be fixed soon :)
> Can I zero out these counters if I want to get rates,
> or should I store the last count?
There was a recent (2 months ago) talk about zeroing in-kernel counters
and I'm not so sure if all the kernel hacker gurus agreed but:
You must not zero a counter in the kernel!
I didn't really understand the arguments against or pro zeroing counters
so I'm not a big help here, but if others agree we certainly can add this
feature. It would be ipvsadm -Z as an analogy to ip{chains|tables}. BTW,
we are proud of haveing 64bit counters in the kernel :)
Storing ... there are different approaches to this (complexity order):
1. Use a script that extracts the info and writes it flat to a file
2. Use mrtg or rrdtool since I reckon you wanted to use the stats to
generate some graphics anyway. These tools handle the problem for
you.
3. Write a MIB for LVS stats, which is what I would love to see but am
currently unable to write.
HTH a little bit,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
