| |
| |
| |
|
Comments:
<0> hello
<0> ipt_ROUTE when used with --oif eth1 --gw 123.123.123.123 is performing the wrong arp requests, if the destination ip was 231.231.231.231 then it arps for 123.123.231.231 instead of for the gateway of 123.123.123.123, anyone got any ideas?
<1> hi all
<1> hi jengelh
<1> hello xkr47
<2> yello
<1> does the following rule make sense ?
<1> iptables -t mangle -A PREROUTING i lanbr0 -p icmp -m state --state NEW -j CONNMARK --set-mark 1;
<1> does -m state --state NEW make sense with ICMP ?
<2> hmm dunno
<1> cause there is no TCP connection
<1> will CONNMARK will make sense ?
<1> similerly for UDP
<1> iptables -t mangle -A PREROUTING i lanbr0 -p udp --dport ! 53 -m state --state NEW -j CONNMARK --set-mark 1;
<2> for udp it makes sense
<1> r u sure ?
<2> yeah, udp connection tracking works
<2> except if there are long delays between packets from the "same" socket
<3> ie, there is no connection :P
<2> yeah but linux ***umes there is one
<2> :)
<2> so if same source/dest port is used, it ***umes it belongs to the same connection
<2> it "forgets" the connection if no packets have gone through in some time
<1> ok
<2> so it could be the same for icmp, but I don't know
<1> ok
<1> thanks
<1> I'll try it for icmp
<4> gug
<5> can someone here help me with libnetfilter_log ?
<5> i think i found a bug in the library
<5> in nflog_get_payload()
<5> to be specific
<5> well msg me if someone is interested... i am tired of asking this for weeks and weeks
<6> probably reporting it on mailing list is better
<5> the user or the dev list?
<6> I think dev list
<7> anyone can comment on the stability of 2.6.15.3 netfilterwise??
<7> need to setup a 600Mbit/s router with firewalling , BGP
<7> rather smallish packets
<8> kaitseb, I have a 2.6.15 original running on my home cable router, p***ing packets happily.
<8> It's asymmetric of course, 500Mbit down and half or less up.
<9> rob0: cpu ?
<9> rob0: what is the config of that pc?
<8> oh, it's way more than is necessary for the job, but it does other things besides netfilter.
<8> If yours is going to be a dedicated router only (which is what I recommend at commercial sites) you could get by with any old junk.
<7> rob0: I don't think so, we've got huge conntrack table too..
<8> wc < /proc/net/ip_conntrack gives me "108 2037 23035".
<10> rob0: 500Mbit cable router?
<8> It's fast.
<10> I've never heard of a cable connection that fast...
<8> Comcast, USA. Rather than spend the money on fighting abuse to reduce bandwidth needs, they spend money on fattening the pipes.
<8> because they can then brag about "blazing speeds" in advertisements.
<11> 1/2 gigabit is a bit more than blazing imo...
<8> did I get the numbers wrong? Oops. :)
<8> <== needs intravenous caffeine
<8> We regularly see downloads in excess of 500KB/sec.
<7> Gandalf: a router that is connected to multiple gigabit uplinks and is forwarding around 600Mbit/s traffic, with several houndred connections
<7> is the nf_conntrack that is in 2.6.15 similiar in speed to the old one or faster?
<10> similar
<7> pity ;)
<7> we've seen some kind of attack lately that resulted in: kernel: dst cache overflow
<7> are there any suggestions how one can avoid that?
<7> is somebody working on net channels currently?
<10> dst cache overflow is an rcu problem with the route cache
<10> it doesn't manage to free the evicted entries fast enough
<7> what can we do about it?
<7> its quad opteron 848 2.2Ghz, it should manage to free them.. at leas I hope so ;)
<7> but I am running 64bit kernel, maybe I'd be better if I run 32bit kernel?
<10> it has been a problem for a long time, doesn't seem like anyone's really trying to fix it
<7> damn...
<7> it looks like I'm the only user with expectations that big
<7> few more months and there will be no hardware I could throw at the problem here..
<7> oh, maybe conntrack synchronization pathes for vrrpd setup is more mature now, so I could overcome the problem that way?
<7> running two routers?
<10> not really :)
<10> ctsync still isn't ready
<10> especialy not active-active
<10> do you really need conntrack on that machine?
<10> you don't just need a fast core-router and then you can have several smaller firewalls/routers near the servers? iirc you have some kind of IM service running there
<7> Gandalf: well, guess I need conntrack, I don't want to create more SPOFs, would have to duplicate firewalls, you think that in that kind of setup things would be better?
<10> you should always try to push as much of the complexity as far out towars the endusers (servers) as possible
<10> the core should be fairly clean and it should just shuffle lots of packets
<10> so a router without conntrack in the core and several smaller routers with conntrack near the end-users
<10> I'm working on improving conntrack performance but it's going very slowly
<9> gandalf: hi!
<10> hi chentschel
<9> gandalf: what r the things u r working on exactly ?
<9> :)
<7> Gandalf: I see, however, if I move the complexity down, some more spofs arise, which I must take care off. Well, guess I will have to cope with that.
<7> Gandalf: what kernel do you suggest for running such a beast currently?
<10> chentschel: a diffrent more cachefriendly datastructure for conntrack instead of the regular hashtable, and trying to make things lockless and without atomic operations in the fast path
<10> kaitseb: kernel 2.4 actually works better than 2.6 as a router without conntrack etc just because of the rcu problem with the routecache in 2.6
<10> chentschel: currently we take a global read-lock, update a refcount, release the global read-lock, then later we read-lock again, and then we even write-lock the global lock... it's so stupid
<10> taking a lock is an locked instruction which forces the cpus to flush their pipelines, likewise atomic operations like increasing the refcount...
<10> and flushing the pipeline on a cpu like the p4 which has a very long pipeline is a disaster
<10> there's a whole heap of problems with the things I want to do, making things lockless makes us possibly vulnerable to the same rcu problem as the routecache
<10> and removing the refcount is... lets just say, very very tricky
<7> looks like like a real problem.
<10> the only workaround for the routecache problem I think might work is to make the routecache larger
<10> so it doesn't have to evict so much, but during a DoS it can actually make things worse
<7> where does one set it up?
<7> ahm..
<10> the larger the route cache, the more cachemisses you get because you'll probably have to search through more entries during lookup in order to find the entry you want to find
<10> the same as a misconfigured conntrack
<7> what size of the conntrack table do you suggest for big setups?
<10> the same number of buckets as maximum number of entries
<10> s/as/as the/
<10> that should make the access almost O(1)
<10> uses a little bit more memory but it's worth it
<10> what ratio do you have right now between buckets and the current number of entries?
<7> yup, but if the table is too big I get that info during bootup that it goes to some kind of other memory, if i remember correctly
<7> a sec.
<10> vmalloc?
<7> (262144 buckets, 2097152 max)
<7> I think so, but with the above setup I don't see that message
<10> how many conntracks do you have right now?
<7> just a sec.
<10> you can look at the .pdf at http://people.netfilter.org/gandalf/
<10> page 5 and 7
<10> there you have some small performancetests of the normal hashtable with diffrent ratio between the number of buckets and entries
<10> I have to go buy some food, bbl
<7> Gandalf_: thanks
<7> bbl , too..
Return to
#netfilter
or
Go to some related
logs:
#bash
ubuntu sound driver laptop compaq presario v5000
#css
proftpd rpmrebuild mysql fedora
unofficail kubuntu
gentoo docache
+bash +stat +readable +timestamp
gentoo imagemagick fPIC relocation R_X86_64_32
ldapsearch scandinavian characters
#debian
|
|