Hello, I am trying to set up traffic shaping/control for my voip connection. I am running 4.4.22.3. Here is my current configuration: --- tcdevices --- #NUMBER: IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED #INTERFACE INTERFACES eth1 2048kbps 1500kbps -- tcclasses --- #INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS # DMAX:UMAX eth1 1 100kbps 180kbps 1 tos=0x88/0xfc,tos=0xb8/0xfc eth1 2 full/4 full 2 default -- tcrules --- #MARK SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS CONNBYTES 1 $FW:w.x.y.z a.b.c.d udp 1194 - - - - 0x18/0xa0 My voip traffic goes into an openvpn vpn tunnel. When I log the Openvpn traffic using a log entry in the rules file I notice that the voip traffic in the tunnel (that I have seen so far) have the following TOS byte. eg: TOS=0x18 PREC=0xA0. I want to use traffic control to prioritize this traffic over all else. I am not sure if I am specifying the TOS field in the tcrules file properly. When I remove the TOS field all traffic matches and I see MARK=0x1 in the logs on that traffic. When I add it back and test with a voip connection I see the traffic but it does not have MARK=0x1, nor does anything else. So I assume I am not it in the tcrules TOS field specifying it properly. I have tired various ways (eg. 0x10, upper and lower case, with the name) with no luck so far. My last question is, provided that I get the traffic control configuration above working and matching on the TOS field do I need to specify any more rules in tcrules? Will everything else fall into the default (#2) tcclass rule? Thanks, Jim. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>Hello, > >I am trying to set up traffic shaping/control for my voip connection. >I am running 4.4.22.3. Here is my current configuration: > >--- tcdevices --- >#NUMBER: IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED >#INTERFACE INTERFACES >eth1 2048kbps 1500kbps > >-- tcclasses --- >#INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS ># DMAX:UMAX >eth1 1 100kbps 180kbps 1 tos=0x88/0xfc,tos=0xb8/0xfc >eth1 2 full/4 full 2 default > >-- tcrules --- >#MARK SOURCE DEST PROTO DEST SOURCE > USER TEST LENGTH TOS CONNBYTES 1 $FW:w.x.y.z > a.b.c.d udp 1194 - - - - 0x18/0xa0 > >My voip traffic goes into an openvpn vpn tunnel. When I log the >Openvpn traffic using a log entry in the rules file I notice that the >voip traffic in the tunnel (that I have seen so far) have the >following TOS byte. eg: TOS=0x18 PREC=0xA0. I want to use traffic >control to prioritize this traffic over all else. > >I am not sure if I am specifying the TOS field in the tcrules file >properly. When I remove the TOS field all traffic matches and I see >MARK=0x1 in the logs on that traffic. When I add it back and test >with a voip connection I see the traffic but it does not have >MARK=0x1, nor does anything else. So I assume I am not it in the >tcrules TOS field specifying it properly. I have tired various ways >(eg. 0x10, upper and lower case, with the name) with no luck so far. > >My last question is, provided that I get the traffic control >configuration above working and matching on the TOS field do I need to >specify any more rules in tcrules? Will everything else fall into the >default (#2) tcclass rule? > >Thanks, Jim.Hello, I spent some time on #shorewall and was really lucky to get some got some great help to figure out where I was going wrong. Apparently I wasn''t understanding what the TOS and PREC fields meant. In the logs I saw: TOS=0x18 PREC=0xA0 TOS=0x08 PREC=0x80 Then, with (a lot) of help I worked them out to be 0x88 and 0xb8. So my revised tcrules are: 1 $FW:w.x.y.z a.b.c.d udp 1194 - - - - 0xb8 1 $FW:w.x.y.z a.b.c.d udp 1194 - - - - 0x88 It was sort of there all along but I didn''t realize it, as the tos values (in the tclasses file) were given to me previously by the provider but understanding how to relate them to what I saw in the logs was invaluable. Now I see that this is being marked properly in the logs with MARK=0x1. So my last question is now that I have the right packets being marked, are the rest falling into the second tcclass rule? If so, I am not seeing MARK=0x2 on all the other traffic. Should I be seeing this? Thanks, Jim. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 08/29/2012 12:40 AM, Jim Smitherman wrote:> > So my last question is now that I have the right packets being > marked, are the rest falling into the second tcclass rule?Yes.> If so, I am not seeing MARK=0x2 on all the other traffic. Should I > be seeing this?No. Any packet that isn''t classified by other means (such as packet mark values) are assigned to the default class. You can see the traffic going through both classes in the output of ''shorewall show tc''. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/