Hello, my Shorewall was working fine, stop working today with this message kernel: NET: 17 messages suppressed. kernel: ip_conntrack: table full, dropping packet. Thank you.
Javier Pardo wrote:> kernel: ip_conntrack: table full, dropping packet.I usually hate replies like this, but... have you tried putting that message in a search engine? -- - Pieter
From: "Javier Pardo"> Hello, my Shorewall was working fine, stop working today with this message > kernel: NET: 17 messages suppressed. > kernel: ip_conntrack: table full, dropping packet.http://www.shorewall.net/troubleshoot.htm if your still having problems, http://www.shorewall.net/support.htm JBanks
Joshua wrote on 17/06/2004 10:10:31:> > From: "Javier Pardo" > > Hello, my Shorewall was working fine, stop working today with thismessage> > kernel: NET: 17 messages suppressed. > > kernel: ip_conntrack: table full, dropping packet. > > http://www.shorewall.net/troubleshoot.htm > > if your still having problems, > > http://www.shorewall.net/support.htm > > > JBanks >he could also do a search for "ip_conntrack table full" in the mail list archives at shorewall.net. The answer is there... Eduardo
On Thu, 17 Jun 2004 09:43:00 +0200 "Javier Pardo" <jpardo@alerce.es> wrote:> Hello, my Shorewall was working fine, stop working today with this > messageApparently your ip_conntrack table is full, you can review your table with: # cat /proc/net/ip_conntrack The max number of connections is set in # cat /proc/sys/net/ipv4/ip_conntrack_max You can increase it with: # echo "some_number" > /proc/sys/net/ipv4/ip_conntrack_max Which might resolve your problem. It may also depend on the amount of RAM on the machine in question. You could also Google it. I turned up about 888 posts full of info :-) -- Paul Slinski -o) Network Administrator /\ Global IQX, Inc. _\_v
On Thu, 17 Jun 2004 09:43:00 +0200 "Javier Pardo" <jpardo@alerce.es> wrote:> Hello, my Shorewall was working fine, stop working today with this > messageHere''s a good doc for you to read on this topic. http://www.wallfire.org/misc/netfilter_conntrack_perf.txt Cheers! -- Paul Slinski -o) Network Administrator /\ Global IQX, Inc. _\_v Global IQX is the leader in integrated e-business automation solutions for the group life and health insurance industry. We provide web based solutions for quoting, procurement, distribution and enrollment both on a SEMCI and private labeled basis. The information transmitted is intended only for the addressee and may contain confidential, proprietary and/or privileged material. If you received this in error, please contact the sender and delete or destroy this message and any copies.
Thanks a lot. -----Mensaje original----- De: shorewall-users-bounces@lists.shorewall.net [mailto:shorewall-users-bounces@lists.shorewall.net] En nombre de Paul Slinski Enviado el: jueves, 17 de junio de 2004 15:23 Para: Mailing List for Shorewall Users Asunto: Re: [Shorewall-users] kernel message On Thu, 17 Jun 2004 09:43:00 +0200 "Javier Pardo" <jpardo@alerce.es> wrote:> Hello, my Shorewall was working fine, stop working today with this > messageApparently your ip_conntrack table is full, you can review your table with: # cat /proc/net/ip_conntrack The max number of connections is set in # cat /proc/sys/net/ipv4/ip_conntrack_max You can increase it with: # echo "some_number" > /proc/sys/net/ipv4/ip_conntrack_max Which might resolve your problem. It may also depend on the amount of RAM on the machine in question. You could also Google it. I turned up about 888 posts full of info :-) -- Paul Slinski -o) Network Administrator /\ Global IQX, Inc. _\_v _______________________________________________ Shorewall-users mailing list Post: Shorewall-users@lists.shorewall.net Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users Support: http://www.shorewall.net/support.htm FAQ: http://www.shorewall.net/FAQ.htm
Paul Slinski wrote:> > You can increase it with: > > # echo "some_number" > /proc/sys/net/ipv4/ip_conntrack_max >You might also want to increase the size of the connection tracking hash table; I''ve posted instructions on the list before. A search for the subject message in the mailing list archives should locate those instructions. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On June 17, 2004 06:31 am, Paul Slinski wrote:> Here''s a good doc for you to read on this topic. > http://www.wallfire.org/misc/netfilter_conntrack_perf.txt >I was the one that recently had this problem on the list and after having read the document at the above URL it appears that there is a slightly more performant method of configuring conntrack. From the above URL: "On systems with enough memory and where performance really matters, you can really consider trying to get an average of one conntrack entry by hash bucket, that means HASHSIZE = CONNTRACK_MAX." Given that I want as much performance as possible out of my router and I have 1GB of RAM, it makes sense for me to take this approach. So, for those that are interested, here''s how I calculated my new settings. First a bit of context. My router is a IBM x335 with 1GB of RAM, a single 2.8GHz Xeon and 5 network interfaces (all of which are gigE capable, but only one runs at gigE). I work at a small cable ISP and this is our backbone router. With a bit of experimentation and Tom''s initial guidance I have determined that my average number of conntrack entries is around 170000. Note: you can see the number of conntrack entries at any given time by running the command "cat /proc/slabinfo | grep conntrack"; the first number is the number of active objects. I wanted to give myself lots of room to handle spurious spikes due to new viruses and all the other crap that tends to permeate the net these days, so I chose to set my maximum number of conntrack entries to 1 million. Now, I checked that decision to see whether it fit within the amount of RAM I have by using the following formula: <memused in MB> = ((<conntrack max>*<size of each conntrack object>)+(<hashsize>*(2*<size of pointer>))\1024^2 where: conntrack max = 1000000 size of each conntrack object = 320 bytes hashsize = same as conntrack max (1000000) size of pointer (on x86) = 4 bytes Total memory used is 312.8MB I can certainly live with a max memory usage of 313MB. I set my conntrack_max by adding the line "net.ipv4.ip_conntrack_max=1000000" to /etc/sysctl.conf and reloading the config with "sysctl -p". I set my hashsize by putting this line "loadmodule ip_conntrack hashsize=1000000" in /etc/shorewall/modules and then restarted shorewall. Conclusion: The original way that I had implemented this was using 8 conntrack entries per hash bucket which was the recommendation I had received. This meant I had a hashsize of 125000 or 1/8th of my conntrack_max. By setting both the conntrack_max and hashsize to the same value I only use a maximum of a little over 6MB more RAM. For me the little extra bit of RAM used is perfectly acceptable for a bit more performance. -- Mason Schmitt
Mason Schmitt wrote:> I set my > hashsize by putting this line "loadmodule ip_conntrack hashsize=1000000" > in /etc/shorewall/modules and then restarted shorewall.Simply restarting Shorewall won''t reload the module -- you need to clear Shorewall and then remove modules until you can remove ip_conntrack. You can then start Shorewall again which will cause the module to be loaded again. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On June 17, 2004 10:50 am, Tom Eastep wrote:> Mason Schmitt wrote: > > I set my > > hashsize by putting this line "loadmodule ip_conntrack hashsize=1000000" > > in /etc/shorewall/modules and then restarted shorewall. > > Simply restarting Shorewall won''t reload the module -- you need to clear > Shorewall and then remove modules until you can remove ip_conntrack. You > can then start Shorewall again which will cause the module to be loaded > again. >Thanks Tom. I kind of expected that''s the way it would work, but I got lazy in my documentation - sorry about that. Given that this is a fairly important box I''ll probably just reboot it in the wee hours. -- Mason Schmitt
On Thu, 17 Jun 2004 11:13:33 -0700 Mason Schmitt <sysadmin@sunwave.net> wrote:> important box I''ll probably just reboot it in the wee hours.It''s not Windows ;-) -- Paul Slinski -o) Network Administrator /\ Global IQX, Inc. _\_v Global IQX is the leader in integrated e-business automation solutions for the group life and health insurance industry. We provide web based solutions for quoting, procurement, distribution and enrollment both on a SEMCI and private labeled basis. The information transmitted is intended only for the addressee and may contain confidential, proprietary and/or privileged material. If you received this in error, please contact the sender and delete or destroy this message and any copies.
On June 17, 2004 11:26 am, Paul Slinski wrote:> On Thu, 17 Jun 2004 11:13:33 -0700 > > Mason Schmitt <sysadmin@sunwave.net> wrote: > > important box I''ll probably just reboot it in the wee hours. > > It''s not Windows ;-)Funny guy... ;) If I turn off shorewall I break a fair bit of stuff, so I might as well just do a reboot rather than trying to do it all by hand. I don''t play the uptime bragging game :) -- Mason Schmitt
From: "Mason Schmitt" Now, I checked that decision to see whether it fit within the amount of RAM I have by using the following formula: <memused in MB> = ((<conntrack max>*<size of each conntrack object>)+(<hashsize>*(2*<size of pointer>))\1024^2 where: conntrack max = 1000000 size of each conntrack object = 320 bytes hashsize = same as conntrack max (1000000) size of pointer (on x86) = 4 bytes Total memory used is 312.8MB I can certainly live with a max memory usage of 313MB. I set my conntrack_max by adding the line "net.ipv4.ip_conntrack_max=1000000" to /etc/sysctl.conf and reloading the config with "sysctl -p". I set my hashsize by putting this line "loadmodule ip_conntrack hashsize=1000000" in /etc/shorewall/modules and then restarted shorewall. Conclusion: The original way that I had implemented this was using 8 conntrack entries per hash bucket which was the recommendation I had received. This meant I had a hashsize of 125000 or 1/8th of my conntrack_max. By setting both the conntrack_max and hashsize to the same value I only use a maximum of a little over 6MB more RAM. For me the little extra bit of RAM used is perfectly acceptable for a bit more performance.>>>>>>>> Sweet.. Thanks Mason.. :) >>>>>>>> Tom is there any way that we can make this an available advancedFAQ. Mason appears to have the perfect environment to show real-time stats..? Mason would you be willing to put something on the Wiki or make this and FAQ once you get some results of your new findings? This is some really nice and important info for advanced Shorewall users... Thanks, Joshua Banks
From: "Tom Eastep"> Simply restarting Shorewall won''t reload the module -- you need to clear > Shorewall and then remove modules until you can remove ip_conntrack. You > can then start Shorewall again which will cause the module to be loaded > again.Wouldn''t doing a "shorewall stop" and then "shorewall start" do the same ? Thanks, JBanks
Joshua Banks wrote:> From: "Tom Eastep" > >>Simply restarting Shorewall won''t reload the module -- you need to clear >>Shorewall and then remove modules until you can remove ip_conntrack. You >>can then start Shorewall again which will cause the module to be loaded >>again. > > > Wouldn''t doing a "shorewall stop" and then "shorewall start" do the same ? >No it will not. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On June 17, 2004 12:15 pm, Joshua Banks wrote:> >>>>>>>> Sweet.. Thanks Mason.. :)No Problem :)> Mason appears to have the perfect environment to show real-time > stats. Mason would you be willing to put something on the Wiki or make > this and FAQ once you get some results of your new findings? > This is some really nice and important info for advanced Shorewall users... >I''m willing to clean this up a little and put it on the wiki if there is a spot set aside for such things. If anyone has any suggestions I''d appreciate them. One in particular is, what is the cleanest way to apply the changes to the ip_conntrack module? -- Mason Schmitt
Mason Schmitt wrote:> On June 17, 2004 12:15 pm, Joshua Banks wrote: > >>>>>>>>>>Sweet.. Thanks Mason.. :) > > No Problem :) > >>Mason appears to have the perfect environment to show real-time >>stats. Mason would you be willing to put something on the Wiki or make >>this and FAQ once you get some results of your new findings? >>This is some really nice and important info for advanced Shorewall users... >> > > I''m willing to clean this up a little and put it on the wiki if there is a > spot set aside for such things. If anyone has any suggestions I''d appreciate > them. One in particular is, what is the cleanest way to apply the changes to > the ip_conntrack module? >Rebooting is the most foolproof (and probably the fastest) for most people. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Thu, 17 Jun 2004 12:44:47 -0700 Tom Eastep <teastep@shorewall.net> wrote:> > One in particular is, what is the cleanest way to apply the changes to > > the ip_conntrack module? > > Rebooting is the most foolproof (and probably the fastest) for most people.Yes ;-) But - for example I load one shorewall configuration at 8 am (which forbids P2P using iptables-p2p module) and load another one at 8 pm which removes restrictions. But all the *active* P2P connections work even after 8 am, unless I manually break them (using http://www.lowth.com/cutter/ for example). Any idea how to automate it without rebooting? Regards, Nerijus
On 06/17/2004 05:42 PM, Nerijus Baliunas wrote:> Yes ;-) But - for example I load one shorewall configuration at 8 am (which > forbids P2P using iptables-p2p module) and load another one at 8 pm which > removes restrictions. But all the *active* P2P connections work even after 8 am, > unless I manually break them (using http://www.lowth.com/cutter/ for example). > Any idea how to automate it without rebooting?Are you doing a ''shorewall stop'' and then a ''shorewall start''? When I do a ''shorewall stop'', everything dies on my network. It works the same (at least for me) as a ''ifdown ethx''. So if you still have P2P activity after a ''shorewall stop'', then you could do an ''ifdown ethx'' and that would kill everything. Bring it back up with a ''ifup ethx''. -MikeD
Mike Dillinger wrote:> Are you doing a ''shorewall stop'' and then a ''shorewall start''? When I > do a ''shorewall stop'', everything dies on my network.I certainly hope that the behavior after ''shorewall stop'' isn''t a mystery to you because it is (I think) well documented: http://shorewall.net/starting_and_stopping_shorewall.htm -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> > I''m willing to clean this up a little and put it on the wiki if there is a > spot set aside for such things. If anyone has any suggestions I''d appreciate > them. One in particular is, what is the cleanest way to apply the changes to > the ip_conntrack module?The wiki has at least a few gigabytes of space.... Alex Martin http://www.rettc.com>
On June 17, 2004 05:42 pm, Nerijus Baliunas wrote:> On Thu, 17 Jun 2004 12:44:47 -0700 Tom Eastep <teastep@shorewall.net> wrote: > > > One in particular is, what is the cleanest way to apply the changes to > > > the ip_conntrack module? > > > > Rebooting is the most foolproof (and probably the fastest) for most > > people. > > Yes ;-) But - for example I load one shorewall configuration at 8 am (which > forbids P2P using iptables-p2p module) and load another one at 8 pm which > removes restrictions. But all the *active* P2P connections work even after > 8 am, unless I manually break them (using http://www.lowth.com/cutter/ for > example). Any idea how to automate it without rebooting? >Perhaps you read this out of context. We were speaking of how best to apply changes to the hashsize for the ip conntrack netfilter kernel module. If you are simply changing rulesets, there is no need for a reboot as the conntrack module will not need to be reloaded in order for you to change your rulesets. A change in your ruleset only requires a shorewall restart. -- Mason Schmitt
On Fri, 18 Jun 2004 09:11:38 -0700 Mason Schmitt <sysadmin@sunwave.net> wrote:> > > Rebooting is the most foolproof (and probably the fastest) for most > > > people. > > > > Yes ;-) But - for example I load one shorewall configuration at 8 am (which > > forbids P2P using iptables-p2p module) and load another one at 8 pm which > > removes restrictions. But all the *active* P2P connections work even after > > 8 am, unless I manually break them (using http://www.lowth.com/cutter/ for > > example). Any idea how to automate it without rebooting? > > > Perhaps you read this out of context. We were speaking of how best to apply > changes to the hashsize for the ip conntrack netfilter kernel module. If you > are simply changing rulesets, there is no need for a reboot as the conntrack > module will not need to be reloaded in order for you to change your rulesets. > A change in your ruleset only requires a shorewall restart.Yes, it''s a bit out of context. But, if I understand correctly, changing hashsize requires reloading ip conntrack netfilter kernel module, and reloading it should stop all current masqueraded connections, which is exactly what I need. Nerijus
Nerijus Baliunas wrote:> > Yes, it''s a bit out of context. But, if I understand correctly, changing hashsize > requires reloading ip conntrack netfilter kernel module, and reloading it should > stop all current masqueraded connections, which is exactly what I need. >Unfortunately, you often end up in a Catch 22 situation -- you want to unload ip_conntrack so that you can stop current connections but there are modules dependent on ip_conntrack that won''t unload because they have active connections!! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On June 18, 2004 10:15 am, Nerijus Baliunas wrote:> if I understand correctly, changing > hashsize requires reloading ip conntrack netfilter kernel module, and > reloading it should stop all current masqueraded connections, which is > exactly what I need. >Ah! I see what you are after. Perhaps this will do the trick http://www.lowth.com/cutter/ I haven''t used it myself, so this isn''t really a recommendation, it just appears to fit the bill. -- Mason Schmitt
On Fri, 18 Jun 2004 10:45:09 -0700 Mason Schmitt <sysadmin@sunwave.net> wrote:> Ah! I see what you are after. Perhaps this will do the trick > http://www.lowth.com/cutter/Yes, I mentioned it in my first message, and I use it manually sometimes, but thanks anyway ;-). Will need to write scripts to automate it. Regards, Nerijus