Well.. I''ve been using shorewall since a few years now, but the first time involved in making it work with (a lot of) vlan''s. The problem is, we''ve got approx 70 vlan''s on a switched cisco network, working fine. The only ''problem'' is the time it takes when we do a shorewall restart.. Each vlan is configured as a separate interface and zone. All vlan''s use their own private /28 subnet. I''ve tested with using bash as a shorewall shell and ash: bash : 3m59 sec ash : 2m43 sec Okay, so I will use ash no matter what :) But still it''s a long waiting time. (the machine''s a Xeon2.8 with 512mb ram) Any idea on how to improve this? Or even, throwing a bunch of vlan''s in 1 zone but make sure they can not route to each other? (I don''t seem to be able to do this) Anyway, I''m gonna keep looking but in the meantime, feel free to suggest what might be usefull.. cheers!
On Wed, 2004-12-01 at 14:11 +0100, Kristof Hardy wrote:> Well.. I''ve been using shorewall since a few years now, but the first > time involved in making it work with (a lot of) vlan''s. > > The problem is, we''ve got approx 70 vlan''s on a switched cisco network, > working fine. The only ''problem'' is the time it takes when we do a > shorewall restart.. Each vlan is configured as a separate interface and > zone. All vlan''s use their own private /28 subnet. > > I''ve tested with using bash as a shorewall shell and ash: > bash : 3m59 sec > ash : 2m43 sec > > Okay, so I will use ash no matter what :) But still it''s a long waiting > time. (the machine''s a Xeon2.8 with 512mb ram) > > Any idea on how to improve this? Or even, throwing a bunch of vlan''s in > 1 zone but make sure they can not route to each other? (I don''t seem to > be able to do this)The number of zones isn''t the important factor -- see below.> > Anyway, I''m gonna keep looking but in the meantime, feel free to suggest > what might be usefull..This is pretty much a fact of life, so long as Shorewall uses a shell and has to run iptables for each rule that it generates. The cost of starting a Shorewall firewall is O( n ** 2 ) where n = the number of "networks". A network is a <interface>:<address> pair; each entry in /etc/shorewall/interfaces (that has a zone specified) and each entry in /etc/shorewall/hosts is a network. So if you double the number of networks, the time to start Shorewall increases by roughly a factor of 4! You should definitely use "shorewall save" and then use "shorewall restore" wherever possible. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote on 03/12/2004 14:01:58:> On Wed, 2004-12-01 at 14:11 +0100, Kristof Hardy wrote: > > > > The problem is, we''ve got approx 70 vlan''s on a switched cisconetwork,> > working fine. > > > > I''ve tested with using bash as a shorewall shell and ash: > > bash : 3m59 sec > > ash : 2m43 sec > > > > This is pretty much a fact of life, so long as Shorewall uses a shell > and has to run iptables for each rule that it generates. The cost of > starting a Shorewall firewall is O( n ** 2 ) where n = the number of > "networks".Tom, I''m a long time user of shorewall and for almost the same long time I''ve been thinking of the way shorewall handles the restart command. I think the problem is not how long it will take to examine and compile that long list of zones and rules but the time the firewall is stopped. Wouldn''t it be possible to change the way this command is executed so that the stop (cleaning rules and chains etc etc) was executed just before the creation of the new rules? (eg, writing the new set of rules to a file and, after parsing all files and making all checks, stop/clean old rules and just then execute the file with the new set). just my 2c... ________________________ Eduardo Ferreira Icatu Holding S.A. Supervisor de TI (5521) 3804-8606
On Fri, 2004-12-03 at 14:38 -0200, Eduardo Ferreira wrote:> Tom Eastep wrote on 03/12/2004 14:01:58: > > > On Wed, 2004-12-01 at 14:11 +0100, Kristof Hardy wrote: > > > > > > The problem is, we''ve got approx 70 vlan''s on a switched cisco > network, > > > working fine. > > > > > > I''ve tested with using bash as a shorewall shell and ash: > > > bash : 3m59 sec > > > ash : 2m43 sec > > > > > > > This is pretty much a fact of life, so long as Shorewall uses a shell > > and has to run iptables for each rule that it generates. The cost of > > starting a Shorewall firewall is O( n ** 2 ) where n = the number of > > "networks". > Tom, > > I''m a long time user of shorewall and for almost the same long time I''ve > been thinking of the way shorewall handles the restart command. I think > the problem is not how long it will take to examine and compile that long > list of zones and rules but the time the firewall is stopped. Wouldn''t it > be possible to change the way this command is executed so that the stop > (cleaning rules and chains etc etc) was executed just before the creation > of the new rules? > (eg, writing the new set of rules to a file and, after parsing all files > and making all checks, stop/clean old rules and just then execute the file > with the new set). >This assertion could be proved if someone with a large configuration wants to perform the following test: a) time shorewall restart > /tmp/shorewall.out b) shorewall save test c) hack up /var/lib/shorewall/test to run iptables for each entry in the iptables-restore commands. Those commands would need to be preceded by code to iterate through the tables flushing all rules in all chains and deleting all user chains. d) time /var/lib/shorewall/test > /tmp/restore.out Now compare the times. Note that the difference in times will be larger than we could expect by rewriting Shorewall to do as you suggest because the current Shorewall strips most of the config files of comments and parses several of them before it disables new connections. I performed this test on my firewall with the following results: time shorewall restart > /tmp/shorewall.out real 0m21.270s user 0m6.853s sys 0m12.929s gateway:~ # gateway:~ # time /var/lib/shorewall/test > /tmp/out.test real 0m9.433s user 0m3.337s sys 0m6.064s gateway:~ # So on my little k6-II/350, it looks like about half of the time is taken up parsing and thinking in the firewall scripts. I''ve placed the restore and test scripts in http://shorewall.net/pub/shorewall/perftest so people can see the modifications needed to the restore script to reproduce these results. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Fri, 2004-12-03 at 09:56 -0800, Tom Eastep wrote:> > I performed this test on my firewall with the following results: > > time shorewall restart > /tmp/shorewall.out > > real 0m21.270s > user 0m6.853s > sys 0m12.929s > gateway:~ # > > gateway:~ # time /var/lib/shorewall/test > /tmp/out.test > > real 0m9.433s > user 0m3.337s > sys 0m6.064s > gateway:~ #But of course, "restore" still wins hands down... gateway:~ # time shorewall restore > /tmp/restore.out real 0m2.390s user 0m1.485s sys 0m0.878s gateway:~ # -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
[This email is either empty or too large to be displayed at this time]
Please post in plain text -- otherwise, the HTML->TEXT converter built into Gnu Mailman may fail and the result is an empty message. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Marcelo F. Mujica wrote:> _______________________________________________ > 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.htmguessing that you want to know the best way to manage them, I''d put them all in one zone :) interestingly enough, I seem to recall that the last thread about large numbers of VLANs also had about 70. Check the archives. -- Jack at Monkeynoodle dot Org: It''s a Scientific Venture... Riding the Emergency Third Rail Power Trip since 1996!