[LARTC] Classful Queuing

[LARTC] Classful Queuing

[Jamin W. Collins]

OK, I'm stumped.  I've read through most of the LARTC HOWTO and have yet
to find a basis for what I need to accomplish.

I have a Linux box that controls access to and from the Internet at my
workplace.  We have a number of remote employees that connect via PPTP
and IPSEC to the office's internal network.  Some of these remote
employees are currently using SIP phones.  The problem is occasionally
the available bandwidth becomes consumed and the VoIP calls (obviously)
suffer because of this.

Configuration:
eth0 - connected to the internal office
eth1 - connected to the internet
pppX - incoming on eth1 connection
ipsec0 - incoming on eth1 connection

My question, how can I set classful htb queuing up so that it's rules
encompass all traffic on eth1 (including that to and from the ipsec and
ppp connections) while reserving bandwidth for and prioritizing the SIP
traffic?

In looking through chapter 9 it appears that all the configurations
apply to a specific interface, and thus would only get eth1 for example.
While the traffic on the ppp and ipsec connections would arrive on the
eth1 interface only after being placed on their specific interfaces and
encrypted, thus most likely missing proper classification and
prioritization.

Am I over thinking this problem or missing something?

I'll happily provide any clarification or additional information needed.

-- 
Jamin W. Collins

It has always been Debian's philosophy in the past to stick to what
makes sense, regardless of what crack the rest of the universe is
smoking.  -- Andrew Suffield
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Classful Queuing

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

Hi

I think what you need to look for is marking of packets with netfilter -
let it classify and then used tc to place the properly marked packets
into the proper queue

Because you can mark in the PREROUTING table in mangle before it is enc

Alex

On Mon, Oct 11, 2004 at 07:01:57PM -0600, Jamin W. Collins wrote:
> OK, I'm stumped.  I've read through most of the LARTC HOWTO and have yet
> to find a basis for what I need to accomplish.
> 
> I have a Linux box that controls access to and from the Internet at my
> workplace.  We have a number of remote employees that connect via PPTP
> and IPSEC to the office's internal network.  Some of these remote
> employees are currently using SIP phones.  The problem is occasionally
> the available bandwidth becomes consumed and the VoIP calls (obviously)
> suffer because of this.
> 
> Configuration:
> eth0 - connected to the internal office
> eth1 - connected to the internet
> pppX - incoming on eth1 connection
> ipsec0 - incoming on eth1 connection
> 
> My question, how can I set classful htb queuing up so that it's rules
> encompass all traffic on eth1 (including that to and from the ipsec and
> ppp connections) while reserving bandwidth for and prioritizing the SIP
> traffic?
> 
> In looking through chapter 9 it appears that all the configurations
> apply to a specific interface, and thus would only get eth1 for example.
> While the traffic on the ppp and ipsec connections would arrive on the
> eth1 interface only after being placed on their specific interfaces and
> encrypted, thus most likely missing proper classification and
> prioritization.
> 
> Am I over thinking this problem or missing something?
> 
> I'll happily provide any clarification or additional information needed.
> 
> -- 
> Jamin W. Collins
> 
> It has always been Debian's philosophy in the past to stick to what
> makes sense, regardless of what crack the rest of the universe is
> smoking.  -- Andrew Suffield
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] Classful Queuing

[Jamin W. Collins]

On Tue, Oct 12, 2004 at 11:16:54AM +1000, Alexander Samad wrote:
> 
> I think what you need to look for is marking of packets with netfilter -
> let it classify and then used tc to place the properly marked packets
> into the proper queue
> 
> Because you can mark in the PREROUTING table in mangle before it is enc

But will the mark still exist after the encryption/encapsulation?  Plus,
that only deals without outgoing not incoming utilization if I'm
following this correctly.  The incoming packets would not be
identifiable until they were taken off the eth1 interface for their
specific interface (ppp or ipsec), right?

-- 
Jamin W. Collins

"Never underestimate the power of very stupid people in large groups."
-- John Kenneth Galbraith
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Classful Queuing

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On Mon, Oct 11, 2004 at 07:31:28PM -0600, Jamin W. Collins wrote:
> On Tue, Oct 12, 2004 at 11:16:54AM +1000, Alexander Samad wrote:
> > 
> > I think what you need to look for is marking of packets with netfilter -
> > let it classify and then used tc to place the properly marked packets
> > into the proper queue
> > 
> > Because you can mark in the PREROUTING table in mangle before it is enc
> 
> But will the mark still exist after the encryption/encapsulation?  Plus,
> that only deals without outgoing not incoming utilization if I'm
> following this correctly.  The incoming packets would not be
> identifiable until they were taken off the eth1 interface for their
> specific interface (ppp or ipsec), right?

not so about ingres, but the marking stay with the packet after the enc
( well on 2.6 with native stack it does).  I use this for marking
packets.


> 
> -- 
> Jamin W. Collins
> 
> "Never underestimate the power of very stupid people in large groups."
> -- John Kenneth Galbraith
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] Classful Queuing

[rsenykoff]

This is a multipart message in MIME format.
--=_alternative 0014B16386256F2B_Content-Type: text/plain; charset="US-ASCII"

>But will the mark still exist after the encryption/encapsulation?
>>not so about ingres, but the marking stay with the packet after the enc
>>( well on 2.6 with native stack it does).  I use this for marking
>>packets.

Isn't this going to depend on whether you are encrypting the whole packet 
(VPN style) or just the data portion of the packet (SSL style)?

--=_alternative 0014B16386256F2B_Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>&gt;But will the mark still exist after the encryption/encapsulation?</tt></font>
<br><font size=2><tt>&gt;&gt;not so about ingres, but the marking stay
with the packet after the enc<br>
&gt;&gt;( well on 2.6 with native stack it does). &nbsp;I use this for
marking<br>
&gt;&gt;packets.</tt></font>
<br>
<br><font size=2 face="sans-serif">Isn't this going to depend on whether
you are encrypting the whole packet (VPN style) or just the data portion
of the packet (SSL style)?</font>
<br>
--=_alternative 0014B16386256F2B_=--
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Classful Queuing

[Robert Felber]

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On Mon, Oct 11, 2004 at 07:01:57PM -0600, Jamin W. Collins wrote:
> OK, I'm stumped.  I've read through most of the LARTC HOWTO and have yet
> to find a basis for what I need to accomplish.
> 
> I have a Linux box that controls access to and from the Internet at my
> workplace.  We have a number of remote employees that connect via PPTP
> and IPSEC to the office's internal network.  Some of these remote
> employees are currently using SIP phones.  The problem is occasionally
> the available bandwidth becomes consumed and the VoIP calls (obviously)
> suffer because of this.
> 
> Configuration:
> eth0 - connected to the internal office
> eth1 - connected to the internet
> pppX - incoming on eth1 connection
> ipsec0 - incoming on eth1 connection
> 
> My question, how can I set classful htb queuing up so that it's rules
> encompass all traffic on eth1 (including that to and from the ipsec and
> ppp connections) while reserving bandwidth for and prioritizing the SIP
> traffic?

First of all: policing ("shaping" incomming) does not really work as desired.
Not even with RED. The dropping of packets causes to much retransmits, which
will fill up your incomming twice. One could use RED/ECN, but till now i did not
get RED to mark any packets with ECN. However.
Second: look at /etc/protocols or at tcpdump to identify the protocols you 
want to priorize and shape (not police). Use iptables, MARK and the -p option
for that. Besides, I don't know whether you have more than one static IP. If
you have more, you could set up "aliases" and shape via outgoing/source (and 
incomming/destination if you really want to police).

-- 
Robert Felber (EDV-Leitung)
Autohaus Erich Kuttendreier 
Drosselweg 21
81827 Muenchen

Tel: +49 (0) 89 / 453 12-86
Fax: +49 (0) 89 / 453 12-80

PGP: 896CF30B
PGP-Fingerprint: CF36 AA93 9716 63E8 962F 15CC A80E 1A79 BF77 25EA

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

Re: [LARTC] Classful Queuing

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

On Mon, Oct 11, 2004 at 10:46:01PM -0500, rsenykoff@harrislogic.com wrote:
> >But will the mark still exist after the encryption/encapsulation?
> >>not so about ingres, but the marking stay with the packet after the enc
> >>( well on 2.6 with native stack it does).  I use this for marking
> >>packets.
> 
> Isn't this going to depend on whether you are encrypting the whole packet 
> (VPN style) or just the data portion of the packet (SSL style)?

I use it to mark parkets that are then esp enc.  I am using in currently
with 2.6 and native ipsec stack to mark all packets that come in as esp
and then are de - enc, I allow these through the firewall. This was my
way around the old the problem of how to setup the firewall when the
ipsecX interface dissappeared.

I beleive the packet is encaped in place not duplicate.  Then the new
packet is refeed back in to netfilter.

Alex




[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]