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/
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/ >
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 encBut 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/
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/ >
>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)?
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
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
Reasonably Related Threads
- $100 USD to the first person that can provide the rules/scripts that will solve the QOS latency & bandwidth allocation issue !!!!
- [Bug 74002] New: [un]docking Lenovo W530 results in interrupt storm
- Shaping per IP in PPPoE
- Shaping per IP in PPPoE borrowing or sharing Uplink or Downlink
- IPSec gateway configuration