I''ve got packet shaping set up with a basic config and I''m wondering if anyone has any recommendations for these settings. The main thing to be moving along priority 4 should be p2p. Is this only shaping the outbound traffic or is it doing ingress too? tcdevices: eth0 1000kbps 100kbps tcclasses: eth0 1 full*9/10 full 1 eth0 2 full*8/10 full*9/10 2 eth0 3 full*7/10 full*9/10 3 eth0 4 full*1/10 full*5/10 4 default tcdevices: 1 0.0.0.0/0 0.0.0.0/0 udp 5060,5061 1 0.0.0.0/0 0.0.0.0/0 tcp 22 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2 0.0.0.0/0 0.0.0.0/0 udp 53 2 0.0.0.0/0 0.0.0.0/0 tcp 80,443 3 0.0.0.0/0 0.0.0.0/0 tcp 873 3 0.0.0.0/0 0.0.0.0/0 udp 873 - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:> I''ve got packet shaping set up with a basic config and I''m wondering > if anyone has any recommendations for these settings. The main thing > to be moving along priority 4 should be p2p. Is this only shaping the > outbound traffic or is it doing ingress too? > > tcdevices: > eth0 1000kbps 100kbps > > tcclasses: > eth0 1 full*9/10 full 1 > eth0 2 full*8/10 full*9/10 2 > eth0 3 full*7/10 full*9/10 3 > eth0 4 full*1/10 full*5/10 4 defaultYour guarantees add up to > full. So this config won''t work well at all.> > tcdevices: > 1 0.0.0.0/0 0.0.0.0/0 udp 5060,5061 > 1 0.0.0.0/0 0.0.0.0/0 tcp 22 > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply > 2 0.0.0.0/0 0.0.0.0/0 udp 53 > 2 0.0.0.0/0 0.0.0.0/0 tcp 80,443 > 3 0.0.0.0/0 0.0.0.0/0 tcp 873 > 3 0.0.0.0/0 0.0.0.0/0 udp 873 >It is not possible to look at a set of rules and tell if they are ''good'' or not. That is because we don''t know what kind of services you provide. If you are running servers (including SSHD), your rules are not good at all since they categorize traffic only by DEST PORT. Responses from servers need to be categorized by SOURCE PORT. Also, your UDP rule for port 873 is silly. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:> I''ve got packet shaping set up with a basic config and I''m wondering > if anyone has any recommendations for these settings. The main thing > to be moving along priority 4 should be p2p. Is this only shaping the > outbound traffic or is it doing ingress too?Given that you are asking this question, you can''t have read the documentation very carefully. But to answer your question, you are only shaping outbound traffic. You are dropping inbound traffic in excess of 1000kbps.> > tcdevices: > eth0 1000kbps 100kbpsYour values look like you have just used the published (max) data rates specified by your ISP. Those are usually too high. There is a procedure in the documentation for tuning IN-BANDWIDTH; OUT-BANDWIDTH is usually set between 80 and 90% of the maximum. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>> I''ve got packet shaping set up with a basic config and I''m wondering >> if anyone has any recommendations for these settings. The main thing >> to be moving along priority 4 should be p2p. Is this only shaping the >> outbound traffic or is it doing ingress too? >> >> tcdevices: >> eth0 1000kbps 100kbps >> >> tcclasses: >> eth0 1 full*9/10 full 1 >> eth0 2 full*8/10 full*9/10 2 >> eth0 3 full*7/10 full*9/10 3 >> eth0 4 full*1/10 full*5/10 4 default > > Your guarantees add up to > full. So this config won''t work well at all. > >> >> tcdevices: >> 1 0.0.0.0/0 0.0.0.0/0 udp 5060,5061 >> 1 0.0.0.0/0 0.0.0.0/0 tcp 22 >> 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request >> 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply >> 2 0.0.0.0/0 0.0.0.0/0 udp 53 >> 2 0.0.0.0/0 0.0.0.0/0 tcp 80,443 >> 3 0.0.0.0/0 0.0.0.0/0 tcp 873 >> 3 0.0.0.0/0 0.0.0.0/0 udp 873 >> > > It is not possible to look at a set of rules and tell if they are ''good'' > or not. That is because we don''t know what kind of services you provide. > If you are running servers (including SSHD), your rules are not good at > all since they categorize traffic only by DEST PORT. Responses from > servers need to be categorized by SOURCE PORT. Also, your UDP rule for > port 873 is silly.Thank you for your advice. I''m running sshd and cupsd so I''ve adjusted tcrules. Should I also prioritize traffic with source port 5060,5061 for inbound calls? I''m not sure how that works. I now have: tcrules: 1 0.0.0.0/0 0.0.0.0/0 tcp 22,5060,5061 1 0.0.0.0/0 0.0.0.0/0 tcp - 22 1 0.0.0.0/0 0.0.0.0/0 udp 5060,5061 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request,echo-reply 2 0.0.0.0/0 0.0.0.0/0 tcp 80,443 2 0.0.0.0/0 0.0.0.0/0 udp 53 2 0.0.0.0/0 0.0.0.0/0 tcp - 631 3 0.0.0.0/0 0.0.0.0/0 tcp 873 tcclasses: eth0 1 full*5/10 full 1 eth0 2 full*3/10 full 2 eth0 3 full*2/10 full 3 eth0 4 full*1/10 full 4 default Why would I want to set CEIL to any less than full? - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>> I''ve got packet shaping set up with a basic config and I''m wondering >> if anyone has any recommendations for these settings. The main thing >> to be moving along priority 4 should be p2p. Is this only shaping the >> outbound traffic or is it doing ingress too? > > Given that you are asking this question, you can''t have read the > documentation very carefully. But to answer your question, you are only > shaping outbound traffic. You are dropping inbound traffic in excess of > 1000kbps. > >> >> tcdevices: >> eth0 1000kbps 100kbps > > Your values look like you have just used the published (max) data rates > specified by your ISP. Those are usually too high. There is a procedure > in the documentation for tuning IN-BANDWIDTH; OUT-BANDWIDTH is usually > set between 80 and 90% of the maximum.I actually used data from the various flash tests around the internet to arrive at those numbers. I read shorewall-tcdevices.html and I''d like to move the inbound queue off of my cable provider, but it doesn''t say how to do that. Should I just set it to the max? - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
> If you are running servers (including SSHD), your rules are not good at > all since they categorize traffic only by DEST PORT. Responses from > servers need to be categorized by SOURCE PORT.I''ve been trying to get my mind around this but I can''t seem to. Responses from my servers will have a DEST PORT too right? That won''t work for classification? - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:>> If you are running servers (including SSHD), your rules are not good at >> all since they categorize traffic only by DEST PORT. Responses from >> servers need to be categorized by SOURCE PORT. > > I''ve been trying to get my mind around this but I can''t seem to. > Responses from my servers will have a DEST PORT too right? That won''t > work for classification?It''s disheartening to have to explain the very basic principles of sockets to people but here goes. For the purposes of this discussion, the world is separated into clients and servers. Servers provide services to clients. When a server starts, it creates a socket and *binds* the socket to an *address*. For AF_INET (IPv4) and AF_INET6 (IPv6) sockets, that address is an ordered triple consisting of an IPv4 or IPv6 address, a protocol, and possibly a port number. Port numbers are only used when the protocol is TCP, UDP, SCTP or SCCP. The protocol and port number used by a server are typically well-known so that clients will be able to connect to it. So SSH servers bind to TCP port 22, SMTP servers bind to TCP port 25, etc. We will call this port the SERVER PORT. When a client want to use the service provided by a server, it also creates a socket. Like the server''s socket, the client''s socket must also be bound to an address. But in the case of the client, the socket is usually given an automatic address binding. For AF_INET and AF_INET6 sockets. the IP address is the IP address of the client system (loose generalization) and the port number is selected from a *local port range*. On Linux systems, the local port ranges can be seen by ''cat /proc/sys/net/ipv4/ip_local_port_range''. So it is not possible in advance to determine what port the client will be using. Whatever it is, we''ll call it the CLIENT PORT. Now: Packets send from the client to the server will have: SOURCE PORT = CLIENT PORT DEST PORT = SERVER PORT Packets send from the server to the client will have: SOURCE PORT = SERVER PORT DEST PORT = CLIENT PORT Since the SERVER PORT is generally the only port known ahead of time, we therefore categorize traffic from the server to the client using the SOURCE PORT. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:>>> I''ve got packet shaping set up with a basic config and I''m wondering >>> if anyone has any recommendations for these settings. The main thing >>> to be moving along priority 4 should be p2p. Is this only shaping the >>> outbound traffic or is it doing ingress too? >> Given that you are asking this question, you can''t have read the >> documentation very carefully. But to answer your question, you are only >> shaping outbound traffic. You are dropping inbound traffic in excess of >> 1000kbps. >> >>> tcdevices: >>> eth0 1000kbps 100kbps >> Your values look like you have just used the published (max) data rates >> specified by your ISP. Those are usually too high. There is a procedure >> in the documentation for tuning IN-BANDWIDTH; OUT-BANDWIDTH is usually >> set between 80 and 90% of the maximum. > > I actually used data from the various flash tests around the internet > to arrive at those numbers. I read shorewall-tcdevices.html and I''d > like to move the inbound queue off of my cable provider, but it > doesn''t say how to do that. Should I just set it to the max?A) go to http://www.shorewall.net/traffic_shaping.htm B) scan down the page until you get to the description of IN-BANDWIDTH. C) read ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Shorewall Guy wrote:> Grant wrote: >>> If you are running servers (including SSHD), your rules are not good at >>> all since they categorize traffic only by DEST PORT. Responses from >>> servers need to be categorized by SOURCE PORT. >> I''ve been trying to get my mind around this but I can''t seem to. >> Responses from my servers will have a DEST PORT too right? That won''t >> work for classification? > > It''s disheartening to have to explain the very basic principles of > sockets to people but here goes.I''ve added Shorewall Guy''s writeup to the traffic shaping page under the description of the tcrules file (and I''ve corrected his typos ;-) ) -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peasefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>>>> I''ve got packet shaping set up with a basic config and I''m wondering >>>> if anyone has any recommendations for these settings. The main thing >>>> to be moving along priority 4 should be p2p. Is this only shaping the >>>> outbound traffic or is it doing ingress too? >>> Given that you are asking this question, you can''t have read the >>> documentation very carefully. But to answer your question, you are only >>> shaping outbound traffic. You are dropping inbound traffic in excess of >>> 1000kbps. >>> >>>> tcdevices: >>>> eth0 1000kbps 100kbps >>> Your values look like you have just used the published (max) data rates >>> specified by your ISP. Those are usually too high. There is a procedure >>> in the documentation for tuning IN-BANDWIDTH; OUT-BANDWIDTH is usually >>> set between 80 and 90% of the maximum. >> >> I actually used data from the various flash tests around the internet >> to arrive at those numbers. I read shorewall-tcdevices.html and I''d >> like to move the inbound queue off of my cable provider, but it >> doesn''t say how to do that. Should I just set it to the max? > > A) go to http://www.shorewall.net/traffic_shaping.htm > B) scan down the page until you get to the description of IN-BANDWIDTH. > C) readThanks for the link. It sounds like my download pipe needs to be full when running that test. Do you know of a good way to do that? - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>>> If you are running servers (including SSHD), your rules are not good at >>> all since they categorize traffic only by DEST PORT. Responses from >>> servers need to be categorized by SOURCE PORT. >> >> I''ve been trying to get my mind around this but I can''t seem to. >> Responses from my servers will have a DEST PORT too right? That won''t >> work for classification? > > It''s disheartening to have to explain the very basic principles of > sockets to people but here goes. > > For the purposes of this discussion, the world is separated into clients > and servers. Servers provide services to clients. > > When a server starts, it creates a socket and *binds* the socket to an > *address*. For AF_INET (IPv4) and AF_INET6 (IPv6) sockets, that address > is an ordered triple consisting of an IPv4 or IPv6 address, a protocol, > and possibly a port number. Port numbers are only used when the protocol > is TCP, UDP, SCTP or SCCP. The protocol and port number used by a server > are typically well-known so that clients will be able to connect to it. > So SSH servers bind to TCP port 22, SMTP servers bind to TCP port 25, > etc. We will call this port the SERVER PORT. > > When a client want to use the service provided by a server, it also > creates a socket. Like the server''s socket, the client''s socket must > also be bound to an address. But in the case of the client, the socket > is usually given an automatic address binding. For AF_INET and AF_INET6 > sockets. the IP address is the IP address of the client system (loose > generalization) and the port number is selected from a *local port > range*. On Linux systems, the local port ranges can be seen by ''cat > /proc/sys/net/ipv4/ip_local_port_range''. So it is not possible in > advance to determine what port the client will be using. Whatever it is, > we''ll call it the CLIENT PORT. > > Now: > > Packets send from the client to the server will have: > > SOURCE PORT = CLIENT PORT > DEST PORT = SERVER PORT > > Packets send from the server to the client will have: > > SOURCE PORT = SERVER PORT > DEST PORT = CLIENT PORT > > Since the SERVER PORT is generally the only port known ahead of time, we > therefore categorize traffic from the server to the client using the > SOURCE PORT.Thank you very much for that. I think I understand now. I thought the SOURCE and DEST ports involved in a connection always matched. Illuminating.... - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>>>> I''ve got packet shaping set up with a basic config and I''m wondering >>>> if anyone has any recommendations for these settings. The main thing >>>> to be moving along priority 4 should be p2p. Is this only shaping the >>>> outbound traffic or is it doing ingress too? >>> Given that you are asking this question, you can''t have read the >>> documentation very carefully. But to answer your question, you are only >>> shaping outbound traffic. You are dropping inbound traffic in excess of >>> 1000kbps. >>> >>>> tcdevices: >>>> eth0 1000kbps 100kbps >>> Your values look like you have just used the published (max) data rates >>> specified by your ISP. Those are usually too high. There is a procedure >>> in the documentation for tuning IN-BANDWIDTH; OUT-BANDWIDTH is usually >>> set between 80 and 90% of the maximum. >> >> I actually used data from the various flash tests around the internet >> to arrive at those numbers. I read shorewall-tcdevices.html and I''d >> like to move the inbound queue off of my cable provider, but it >> doesn''t say how to do that. Should I just set it to the max? > > A) go to http://www.shorewall.net/traffic_shaping.htm > B) scan down the page until you get to the description of IN-BANDWIDTH. > C) readBTW, here''s my latest incarnation. Priority 1 is meant to be for SIP and 192.168.100.5 is my Nokia N82 for wifi calls. The RTP port it uses seems to be random and non-configurable so I used its static IP. Priority 6 is meant to be a catch-all for p2p since one of my bittorrent clients seems to use random ports as well. 1 192.168.100.5/24 0.0.0.0/0 1 0.0.0.0/0 0.0.0.0/0 udp 5060 1 0.0.0.0/0 0.0.0.0/0 udp 8000 2 0.0.0.0/0 0.0.0.0/0 tcp 22 2 0.0.0.0/0 0.0.0.0/0 tcp - 22 2 0.0.0.0/0 0.0.0.0/0 udp 123 2 0.0.0.0/0 0.0.0.0/0 icmp echo-request,echo-reply 3 0.0.0.0/0 0.0.0.0/0 tcp - 631 3 0.0.0.0/0 0.0.0.0/0 udp - 631 4 0.0.0.0/0 0.0.0.0/0 tcp 80,443 4 0.0.0.0/0 0.0.0.0/0 udp 53 5 0.0.0.0/0 0.0.0.0/0 tcp 873 eth0 1 full*5/10 full*9/10 1 eth0 2 full*1/10 full*9/10 2 eth0 3 full*1/10 full*9/10 3 eth0 4 full*1/10 full*9/10 4 eth0 5 full*1/10 full*9/10 5 eth0 6 full*1/10 full*9/10 6 default - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:> > Thanks for the link. It sounds like my download pipe needs to be full > when running that test. Do you know of a good way to do that?Download a very large file from a fast site. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
On Wed, Jan 28, 2009 at 03:45:22PM -0800, Shorewall Guy wrote:> Grant wrote: > > > > > Thanks for the link. It sounds like my download pipe needs to be full > > when running that test. Do you know of a good way to do that? > > Download a very large file from a fast site. >kernel.org fits that bill. Its upstream bandwidth is crazy big. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
> BTW, here''s my latest incarnation. Priority 1 is meant to be for SIP > and 192.168.100.5 is my Nokia N82 for wifi calls. The RTP port it > uses seems to be random and non-configurable so I used its static IP. > Priority 6 is meant to be a catch-all for p2p since one of my > bittorrent clients seems to use random ports as well. > > 1 192.168.100.5/24 0.0.0.0/0 > 1 0.0.0.0/0 0.0.0.0/0 udp 5060 > 1 0.0.0.0/0 0.0.0.0/0 udp 8000I''m wondering about the above 2 lines. They''re for my SIP phone (twinkle) and I''m not sure if 5080 and 8000 should be DEST or SOURCE ports. Does anyone know how that works with SIP phones? I did an ''nmap localhost'' of the system running twinkle and it has all ports closed. Does that mean they should be DEST ports above? - Grant> 2 0.0.0.0/0 0.0.0.0/0 tcp 22 > 2 0.0.0.0/0 0.0.0.0/0 tcp - 22 > 2 0.0.0.0/0 0.0.0.0/0 udp 123 > 2 0.0.0.0/0 0.0.0.0/0 icmp echo-request,echo-reply > 3 0.0.0.0/0 0.0.0.0/0 tcp - 631 > 3 0.0.0.0/0 0.0.0.0/0 udp - 631 > 4 0.0.0.0/0 0.0.0.0/0 tcp 80,443 > 4 0.0.0.0/0 0.0.0.0/0 udp 53 > 5 0.0.0.0/0 0.0.0.0/0 tcp 873 > > eth0 1 full*5/10 full*9/10 1 > eth0 2 full*1/10 full*9/10 2 > eth0 3 full*1/10 full*9/10 3 > eth0 4 full*1/10 full*9/10 4 > eth0 5 full*1/10 full*9/10 5 > eth0 6 full*1/10 full*9/10 6 default > > - Grant------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:>> BTW, here''s my latest incarnation. Priority 1 is meant to be for SIP >> and 192.168.100.5 is my Nokia N82 for wifi calls. The RTP port it >> uses seems to be random and non-configurable so I used its static IP. >> Priority 6 is meant to be a catch-all for p2p since one of my >> bittorrent clients seems to use random ports as well. >> >> 1 192.168.100.5/24 0.0.0.0/0I doubt that you really want that rule. It says that you want traffic coming from all 256 addresses in 192.168.100.0/24 to get mark 1.>> 1 0.0.0.0/0 0.0.0.0/0 udp 5060 >> 1 0.0.0.0/0 0.0.0.0/0 udp 8000 > > I''m wondering about the above 2 lines. They''re for my SIP phone > (twinkle) and I''m not sure if 5080 and 8000 should be DEST or SOURCE > ports. Does anyone know how that works with SIP phones?If you are in doubt, double each rule -- have one for SOURCE PORT and one for DEST PORT. You can then look at the output of "shorewall show mangle" and see which ones are getting matches when you use your phone. 1 0.0.0.0/0 0.0.0.0/0 udp 5060 1 0.0.0.0/0 0.0.0.0/0 udp - 5060 1 0.0.0.0/0 0.0.0.0/0 udp 8000 1 0.0.0.0/0 0.0.0.0/0 udp - 8000 ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Shorewall Guy wrote:> Grant wrote: >>> BTW, here''s my latest incarnation.I also notice that you have no rules for marking traffic that originates on the firewall itself. Is that intentional or an oversight? ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>>> BTW, here''s my latest incarnation. Priority 1 is meant to be for SIP >>> and 192.168.100.5 is my Nokia N82 for wifi calls. The RTP port it >>> uses seems to be random and non-configurable so I used its static IP. >>> Priority 6 is meant to be a catch-all for p2p since one of my >>> bittorrent clients seems to use random ports as well. >>> >>> 1 192.168.100.5/24 0.0.0.0/0 > > I doubt that you really want that rule. It says that you want traffic > coming from all 256 addresses in 192.168.100.0/24 to get mark 1.Thank you, I''ve changed that to: 1 192.168.100.5 0.0.0.0/0>>> 1 0.0.0.0/0 0.0.0.0/0 udp 5060 >>> 1 0.0.0.0/0 0.0.0.0/0 udp 8000 >> >> I''m wondering about the above 2 lines. They''re for my SIP phone >> (twinkle) and I''m not sure if 5080 and 8000 should be DEST or SOURCE >> ports. Does anyone know how that works with SIP phones? > > If you are in doubt, double each rule -- have one for SOURCE PORT and > one for DEST PORT. You can then look at the output of "shorewall show > mangle" and see which ones are getting matches when you use your phone. > > 1 0.0.0.0/0 0.0.0.0/0 udp 5060 > 1 0.0.0.0/0 0.0.0.0/0 udp - 5060 > 1 0.0.0.0/0 0.0.0.0/0 udp 8000 > 1 0.0.0.0/0 0.0.0.0/0 udp - 8000Thanks, done. - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>>>> BTW, here''s my latest incarnation. > > I also notice that you have no rules for marking traffic that originates > on the firewall itself. Is that intentional or an oversight?Aren''t I shaping everything that goes out over eth0, including traffic which originates on the firewall? The latest: tcdevices: eth0 1200kbps 75kbps tcclasses: eth0 1 full*4/10 full*9/10 1 eth0 2 full*1/10 full*9/10 2 eth0 3 full*3/10 full*9/10 3 eth0 4 full*1/10 full*9/10 4 eth0 5 full*1/10 full*8/10 5 default tcrules: 1 192.168.100.5 0.0.0.0/0 1 0.0.0.0/0 0.0.0.0/0 udp 5060 1 0.0.0.0/0 0.0.0.0/0 udp - 5060 1 0.0.0.0/0 0.0.0.0/0 udp 8000 1 0.0.0.0/0 0.0.0.0/0 udp - 8000 2 0.0.0.0/0 0.0.0.0/0 tcp 22 2 0.0.0.0/0 0.0.0.0/0 tcp - 22 2 0.0.0.0/0 0.0.0.0/0 udp 123 2 0.0.0.0/0 0.0.0.0/0 tcp - 631 2 0.0.0.0/0 0.0.0.0/0 udp - 631 2 0.0.0.0/0 0.0.0.0/0 icmp echo-request,echo-reply 3 0.0.0.0/0 0.0.0.0/0 udp 53 3 0.0.0.0/0 0.0.0.0/0 tcp 80,443 3 0.0.0.0/0 0.0.0.0/0 udp 465 3 0.0.0.0/0 0.0.0.0/0 udp 993 4 0.0.0.0/0 0.0.0.0/0 tcp 873 - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:>>>>> BTW, here''s my latest incarnation. >> I also notice that you have no rules for marking traffic that originates >> on the firewall itself. Is that intentional or an oversight? > > Aren''t I shaping everything that goes out over eth0, including traffic > which originates on the firewall?No you are not -- that''s why I brought up the issue. Under the description of the tcrules SOURCE column in both the man page and in the Traffic Shaping HOWTO: "... all packets for connections masqueraded to eth0 from other interfaces can be matched in a single rule with several alternative SOURCE criteria. However, a connection whose packets get to eth0 in a different way, e.g., direct from the firewall itself, needs a different rule. Accordingly, use $FW in its own separate rule for packets originating on the firewall. In such a rule, the MARK column may NOT specify either :P or :F because marking for firewall-originated packets always occurs in the OUTPUT chain. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>>>>>> BTW, here''s my latest incarnation. >>> I also notice that you have no rules for marking traffic that originates >>> on the firewall itself. Is that intentional or an oversight? >> >> Aren''t I shaping everything that goes out over eth0, including traffic >> which originates on the firewall? > > No you are not -- that''s why I brought up the issue. > > Under the description of the tcrules SOURCE column in both the man page > and in the Traffic Shaping HOWTO: > > "... all packets for connections masqueraded to eth0 from other > interfaces can be matched in a single rule with several > alternative SOURCE criteria. However, a connection whose > packets get to eth0 in a different way, e.g., direct from the > firewall itself, needs a different rule. > > Accordingly, use $FW in its own separate rule for packets > originating on the firewall. In such a rule, the MARK column may > NOT specify either :P or :F because marking for > firewall-originated packets always occurs in the OUTPUT chain.Thank you, I never would have figured that out. With only 5 systems making up the network, I''m starting to wonder if I should just specify each system instead of 0.0.0.0/0. Latest tcrules: 1 192.168.100.5 0.0.0.0/0 1 0.0.0.0/0 0.0.0.0/0 udp 5060 1 0.0.0.0/0 0.0.0.0/0 udp 8000 2 0.0.0.0/0 0.0.0.0/0 tcp 22 2 $FW 0.0.0.0/0 tcp - 22 2 0.0.0.0/0 0.0.0.0/0 udp 123 2 $FW 0.0.0.0/0 udp 123 2 0.0.0.0/0 0.0.0.0/0 tcp - 631 2 0.0.0.0/0 0.0.0.0/0 udp - 631 2 0.0.0.0/0 0.0.0.0/0 icmp echo-request 2 $FW 0.0.0.0/0 icmp echo-request,echo-reply 3 0.0.0.0/0 0.0.0.0/0 udp 53 3 $FW 0.0.0.0/0 udp 53 3 0.0.0.0/0 0.0.0.0/0 tcp 80,443 3 $FW 0.0.0.0/0 tcp 80,443 3 0.0.0.0/0 0.0.0.0/0 udp 465 3 0.0.0.0/0 0.0.0.0/0 udp 993 4 0.0.0.0/0 0.0.0.0/0 tcp 873 4 $FW 0.0.0.0/0 tcp 873 - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword