Hi
I am search a sample config for my linux box:
Shorewall 3.2.3
Eth0 => Internet Access 4Mbits on ethernet
Eth1 => Lan
Eth2 => Lan 2
Eth3 => Lan 3
i want limit the internet access:
Eth1 = 2 Mbits
Eth2 = 0,5 Mbits
Eth3 = 1,5 Mbits
but if eth1 don''t use 2 Mbits other lan can use it
anyone have a simple sample config for help me ?
Thanks bye
Jpc
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
NOC Phibee wrote:>Hi > >I am search a sample config for my linux box: > Shorewall 3.2.3 > Eth0 => Internet Access 4Mbits on ethernet > Eth1 => Lan > Eth2 => Lan 2 > Eth3 => Lan 3 > >i want limit the internet access: > Eth1 = 2 Mbits > Eth2 = 0,5 Mbits > Eth3 = 1,5 Mbits > >but if eth1 don''t use 2 Mbits other lan can use it > >anyone have a simple sample config for help me ?Do you require inbound limiting as well as outbound ? If so then it becomes a bit harder. I''ll start with the outbound as that''s fairly easy : There''s an article on the shorewall site about configuring traffic shaping, that together with the articles at http://lartc.org/howto/lartc.cookbook.ultimate-tc.html and http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm should give you enough information to figure out how to do it. In short, you attach an HTB queue to eth0, and then define classes below that to control/shape the traffic. Inbound is a lot harder to do, and in this setup I''m not entirely certain what''s required. You can only shape traffic that is leaving an interface - you CANNOT shape traffic that is coming in. In a simple two-interface box you can apply traffic shaping to the internal interface and it will have the effect of shaping the inbound traffic (I''ve just set this up at a clients site) - but here you have multiple interfaces. So what I suspect you need to do is create an Intermediate Queing Device (http://lartc.org/howto/lartc.imq.html). You can then apply the traffic shaping to traffic ''exiting'' via this interface, and after that it can be routed out of the real interfaces. Don''t forget that in these cases, you need to allow for traffic that originated either on the firewall, or from other local nets, and allow it an ''unrestricted'' class so that you don''t shape ''internal'' traffic to the speed of your internet connection. Beyond that though, it''s into territory I haven''t been (yet). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
I know shorewall is amazing as a firewall but it is not the best QoS ToS, look at www.mastershaper.org Fermando Rodriguez iPhone On Jan 31, 2008, at 3:56, NOC Phibee <noc@phibee.net> wrote:> Hi > > I am search a sample config for my linux box: > Shorewall 3.2.3 > Eth0 => Internet Access 4Mbits on ethernet > Eth1 => Lan > Eth2 => Lan 2 > Eth3 => Lan 3 > > i want limit the internet access: > Eth1 = 2 Mbits > Eth2 = 0,5 Mbits > Eth3 = 1,5 Mbits > > but if eth1 don''t use 2 Mbits other lan can use it > > anyone have a simple sample config for help me ? > > Thanks bye > Jpc > > --- > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Thu, Jan 31, 2008 at 11:38:26AM +0000, Simon Hobson wrote:> Inbound is a lot harder to do, and in this setup I''m not entirely > certain what''s required. You can only shape traffic that is leaving > an interface - you CANNOT shape traffic that is coming in. > > ... > > So what I suspect you need to do is create an Intermediate Queing > Device (http://lartc.org/howto/lartc.imq.html). You can then apply > the traffic shaping to traffic ''exiting'' via this interface, and > after that it can be routed out of the real interfaces.While this is technically possible, it doesn''t address the real issue with shaping inbound traffic: you can''t actually do it. Outbound traffic shaping works by holding the packets in a queue, and sending them over the shaped link at the desired rate - this does exactly what you expect, controlling the rate of traffic over the link. Inbound traffic shaping occurs *after* the traffic has already moved over the link you''re trying to shape. It is already too late to control the rate at which these packets have moved. The mechanism used to create the appearance of inbound traffic shaping is to selectively degrade the reliability of the link: the inbound shaper drops packets on the floor, and hopes that the remote system interprets this as the link being overloaded, and slows down the rate at which it is sending packets in the future. In the case where the remote system is a well-behaved TCP application (such as a typical web server), this will work. In the case where it''s some game or VoIP system using its own UDP-based traffic management, it probably won''t. Against a hostile system that is attacking you, it is completely worthless. And never forget that inbound traffic shaping is always deliberately making your link unreliable: packets will be lost. This can cause more problems than it solves; it wrecks most VoIP systems, rather than improving them. It does have applications, but it''s far from universally appropriate. When in doubt, don''t do it, just do the outbound part. ("Real" QoS means outbound shaping only, on both ends of the link - that''s your end, and your ISP, who will be charging extra for this service.) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Andrew Suffield wrote:> > Inbound is a lot harder to do, and in this setup I''m not entirely >> certain what''s required. You can only shape traffic that is leaving >> an interface - you CANNOT shape traffic that is coming in. >> >> ... >> >> So what I suspect you need to do is create an Intermediate Queing >> Device (http://lartc.org/howto/lartc.imq.html). You can then apply >> the traffic shaping to traffic ''exiting'' via this interface, and >> after that it can be routed out of the real interfaces. > >While this is technically possible, it doesn''t address the real issue >with shaping inbound traffic: you can''t actually do it.It depends on what you want to achieve. In this case, the user wants to control bandwidth usage of a shared internet connection by several classes of user - so traffic shaping would be appropriate for this.>Outbound traffic shaping works by holding the packets in a queue, and >sending them over the shaped link at the desired rate - this does >exactly what you expect, controlling the rate of traffic over the >link.But ultimately that queue is limited in size - so either the incoming traffic slows down or packets are lost. See below ...>Inbound traffic shaping occurs *after* the traffic has already moved >over the link you''re trying to shape. It is already too late to >control the rate at which these packets have moved. The mechanism used >to create the appearance of inbound traffic shaping is to selectively >degrade the reliability of the link: the inbound shaper drops packets >on the floor, and hopes that the remote system interprets this as the >link being overloaded, and slows down the rate at which it is sending >packets in the future. In the case where the remote system is a >well-behaved TCP application (such as a typical web server), this will >work. In the case where it''s some game or VoIP system using its own >UDP-based traffic management, it probably won''t.Which is why I am moving away from just randomly dropping packets on the floor, and prioritising which ones I drop - for example not dropping VoIP packets. If your UDP traffic is exceeding bandwidth, then some "user education" is probably called for ;-)>Against a hostile >system that is attacking you, it is completely worthless.Is anything - without some fairly "high end" gear ?>And never forget that inbound traffic shaping is always deliberately >making your link unreliable: packets will be lost. This can cause more >problems than it solves; it wrecks most VoIP systems, rather than >improving them.As mentioned above, the (partial) answer to that is to not drop your VoIP packets ! If you shape to below line speed, then the upstream buffers will mostly be empty. In that situation, you can tolerate bursts although a large burst will increase latency & jitter until the upstream buffer empties again. The more you throttle your traffic below the available link speed, the better the approximation. In our case, we have a 6mbps line, but the actual fibre connection is 10mbps and the 6m limit is imposed by a Cisco router at the other end of the link. Using one online speed checker, we register 7m upstream because the checker doesn''t run long enough to exhaust the burst the router is obviously configured with, and on the downstream test, you can see it jump up to over 7m and then settle down to 6. I agree that you cannot completely do the job at the receiving end, but you can do a fairly good approximation with a little care and given the right circumstances. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Thu, Jan 31, 2008 at 04:23:54PM +0000, Simon Hobson wrote:> >Against a hostile > >system that is attacking you, it is completely worthless. > > Is anything - without some fairly "high end" gear ?The attack is usually against the fact that your DSL line has a meagre ~6Mbit downstream capacity. The same filter applied inside your ISPs network would work - very few people have the capacity to DoS an entire ISP (the operators of the large botnets are about the only ones). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Andrew Suffield wrote:>On Thu, Jan 31, 2008 at 04:23:54PM +0000, Simon Hobson wrote: >> >Against a hostile >> >system that is attacking you, it is completely worthless. >> >> Is anything - without some fairly "high end" gear ? > >The attack is usually against the fact that your DSL line has a meagre >~6Mbit downstream capacity. The same filter applied inside your ISPs >network would work - very few people have the capacity to DoS an >entire ISP (the operators of the large botnets are about the only >ones).But if someone is attacking you with 20mbit of traffic, then the ISP throttling that down to 6mbit will still leave you with no service - 70% packet loss is somewhat beyond what TCP/IP will cope with. Granted, if the attack is using traffic you don''t normally use, AND the ISP is prepared to filter it out, then that''s a different matter. I still contend that provided you understand the limitations, shaping/prioritising your inbound traffic at below line rate does have a place. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Thu, Jan 31, 2008 at 08:16:55PM +0000, Simon Hobson wrote:> Andrew Suffield wrote: > >On Thu, Jan 31, 2008 at 04:23:54PM +0000, Simon Hobson wrote: > >> >Against a hostile > >> >system that is attacking you, it is completely worthless. > >> > >> Is anything - without some fairly "high end" gear ? > > > >The attack is usually against the fact that your DSL line has a meagre > >~6Mbit downstream capacity. The same filter applied inside your ISPs > >network would work - very few people have the capacity to DoS an > >entire ISP (the operators of the large botnets are about the only > >ones). > > But if someone is attacking you with 20mbit of traffic, then the ISP > throttling that down to 6mbit will still leave you with no service - > 70% packet loss is somewhat beyond what TCP/IP will cope with. > Granted, if the attack is using traffic you don''t normally use, AND > the ISP is prepared to filter it out, then that''s a different matter.I''m assuming that the ISP is running real QoS for you, so all your normal traffic is going through fine and they''re just dropping the DoS traffic. Blind throttling wouldn''t help, naturally.> I still contend that provided you understand the limitations, > shaping/prioritising your inbound traffic at below line rate does > have a place.As I noted earlier, it does have applications, it''s just quite limited in scope, doesn''t do what people expect it to, and probably not what you really want most of the time. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> NOC Phibee wrote: >>Hi >> >>I am search a sample config for my linux box: >> Shorewall 3.2.3 >> Eth0 => Internet Access 4Mbits on ethernet >> Eth1 => Lan >> Eth2 => Lan 2 >> Eth3 => Lan 3 >> >>i want limit the internet access: >> Eth1 = 2 Mbits >> Eth2 = 0,5 Mbits >> Eth3 = 1,5 Mbits >> >>but if eth1 don't use 2 Mbits other lan can use it >> >>anyone have a simple sample config for help me ? > > Do you require inbound limiting as well as outbound ? If so then it > becomes a bit harder. I'll start with the outbound as that's fairly > easy : > > > There's an article on the shorewall site about configuring traffic > shaping, that together with the articles at > http://lartc.org/howto/lartc.cookbook.ultimate-tc.html and > http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm should give you > enough information to figure out how to do it. > > In short, you attach an HTB queue to eth0, and then define classes > below that to control/shape the traffic. > > > Inbound is a lot harder to do, and in this setup I'm not entirely > certain what's required. You can only shape traffic that is leaving > an interface - you CANNOT shape traffic that is coming in. In a > simple two-interface box you can apply traffic shaping to the > internal interface and it will have the effect of shaping the inbound > traffic (I've just set this up at a clients site) - but here you have > multiple interfaces. > > So what I suspect you need to do is create an Intermediate Queing > Device (http://lartc.org/howto/lartc.imq.html). You can then apply > the traffic shaping to traffic 'exiting' via this interface, and > after that it can be routed out of the real interfaces. Don't forget > that in these cases, you need to allow for traffic that originated > either on the firewall, or from other local nets, and allow it an > 'unrestricted' class so that you don't shape 'internal' traffic to > the speed of your internet connection. > > Beyond that though, it's into territory I haven't been (yet).1. IMQ now replaced on IFB (http://www.linux-foundation.org/en/Net:IFB). 2. If we have several interfaces we can shape inbound traffic on external interface if we would shape outbound traffic on internal interfaces (for external connections). Alex ---------- Любишь фотографироваться? И выигрывать? Получай приз 'Прайм Телеком' и Fotoblog.by! Потрясающий цифровой Olympus, стильный MP3-плеер и другие призы ждут тебя на www.Fotoblog.by! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
> Hi > > I am search a sample config for my linux box: > Shorewall 3.2.3 > Eth0 => Internet Access 4Mbits on ethernet > Eth1 => Lan > Eth2 => Lan 2 > Eth3 => Lan 3 > > i want limit the internet access: > Eth1 = 2 Mbits > Eth2 = 0,5 Mbits > Eth3 = 1,5 Mbits > > but if eth1 don''t use 2 Mbits other lan can use it > > anyone have a simple sample config for help me ? > > Thanks bye > JpcHi, I attached my shorewall-tc-configfiles. Alex ---------- Любишь фотографироваться? И выигрывать? Получай приз ''Прайм Телеком'' и Fotoblog.by! Потрясающий цифровой Olympus, стильный MP3-плеер и другие призы ждут тебя на www.Fotoblog.by! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 1. IMQ now replaced on IFB (http://www.linux-foundation.org/en/Net:IFB). > > 2. If we have several interfaces we can shape inbound traffic on >external > interface if we would shape outbound traffic on internal interfaces (for > external connections). > > AlexSorry, sorry, sorry! In two sentences i made mistake twice. I am fixing them accordingly: 1. IMQ WAS replaced by IFB. 2. It's true for one to one interfaces (one external and one internal). But if we have several interfaces in same direction we MUST use aggregating device (as is IFB) for have one control under inbound traffic queues (so as one device don't know anything about queues another devices and can't lend or borrow bandwidth). Alex ---------- Встречай День Влюбленных с www.fotoblog.by! Играй и выигрывай. Чтобы начать игру, отправь SMS-сообщение “фото\foto” на номер 9922, ответь правильно на все вопросы викторины и выиграй Оlympus и множество других замечательных призов!! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users