[LARTC] $100 USD to the first person that can provide the rules/scripts
that will solve the QOS latency & bandwidth allocation issue !!!!
Darryl Miles
lartc-list@the-morg.org
Thu, 04 Dec 2003 23:15:53 +0000
Greg Freeman wrote:
>Thank you Darryl,
>
>Hopefully the below will help clarify.
>
>(below was run on the site1 firewall) Does the RX line look bad to you
>for Eth0?
>
>ifconfig -a
>eth0 Link encap:Ethernet HWaddr 00:D0:CF:01:A6:52
> inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:20061386 errors:206047 dropped:5857547
>overruns:138637 frame:0
> TX packets:8390751 errors:0 dropped:0 overruns:1 carrier:0
> collisions:0 txqueuelen:100
> Interrupt:5
>
>eth1 Link encap:Ethernet HWaddr 00:D0:CF:01:A6:53
> inet addr:24.239.167.x Bcast:24.237.169.255
>Mask:255.255.254.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:4246757 errors:0 dropped:0 overruns:0 frame:0
> TX packets:7470351 errors:0 dropped:0 overruns:6 carrier:0
> collisions:48974 txqueuelen:100
> Interrupt:8
>
>ipsec0 Link encap:Ethernet HWaddr 00:D0:CF:01:A6:53
> inet addr:24.239.167.x Mask:255.255.254.0
> UP RUNNING NOARP MTU:16260 Metric:1
> RX packets:625899 errors:0 dropped:1 overruns:0 frame:0
> TX packets:658838 errors:373 dropped:1 overruns:0 carrier:373
> collisions:0 txqueuelen:10
>
>(external IP has been modified)
>
>"640kbps" is the quoted sDSL speed from the ISP, actually see about
>580kbps. The DSL connections are attached to the etho on each firewall,
>
One thing I didn't ask before and had presumed from the configuration,
does your VoIP data get sent over the VPN ? I had presumed yes.
I would guess from your configuration of site1 the Internet is presented
to you by ethernet on eth1 and that its the only thing on that interface ?
Your output of eth0 maybe because you are running a mismatching ifconfig
tools version to the kernel version, check the response from 'cat
/proc/net/dev' manually.
>IPSEC tunnel configured as a tunnel to the "remote network" and not as a
>gateway (this is done on both sides -site1 & site2). Site1 VPN endpoint
>is a SnapGear SME550, site 2 is a SnapGear Pro. Both firewall have a
>640kbps SDSL connection.
>
>
I'm not familar with SnapGear, I would like to know what VoIP handsets
you are running ?
I'm not sure what you mean by "remote network" as opposed to "gateway".
Since the definition of a "gateway" means to provide access to a
"remote network".
>If you have any ideas on what rules I should try please let me know!
>
I don't know if this will even run, what I'm trying to say would look something like this:
#######################################################################
#
# Remote site end (with 3 phones)
#
# Mark VoIP protocol for special treatment
iptables -A PREROUTING -t mangle -j TOS -p udp -s 10.0.1.20 --set-tos 0x10
iptables -A PREROUTING -t mangle -j TOS -p udp -s 10.0.1.21 --set-tos 0x10
iptables -A PREROUTING -t mangle -j TOS -p udp -s 10.0.1.22 --set-tos 0x10
# eth1, which is your Internet/DSL interface
# Setup the basic reservation of 240kbit
tc qdisc add dev eth1 root handle 1: htb default 20
tc class add dev eth1 parent 1: classid 1:1 htb rate 600kbit ceil 640kbit burst 2k
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 240kbit
tc class add dev eth1 parent 1:2 classid 1:20 htb rate 400kbit
# Match IP Protocol type 47 (Check your VPN technology uses this protocol ID
# number in the IP header)
# Match Low Through put TOS (Check the inner IP-TOS value is copied into the
# outer IP-TOS value by your protocol stack, use
# "tcpdump -i eth1 -n -s 1500 -v" and capture some VPN data with UDP inside)
# Match the IP address of the VPN tunnel endpoint, however if you are on DSL
# with dynamic IP then you might as well scrap this value, otherwise change
# "0.0.0.0/0" to just "10.0.0.something/32" or remove
# "match ip src 0.0.0.0/0" completely.
# This would enforce the IP of the tunnel endpoint gets special treatment so
# that no one else on the lan (like peoples workstations) couldn't start
# using their own VPN with TOS=0x10 and take this bandwidth.
tc filter add dev eth1 parent 1: prio 1 protocol ip u32 match ip protocol 47 0xff match ip tos 0x10 0xff match ip src 0.0.0.0/0 flowid 1:10
# Everything else gets flowid 1:20
tc filter add dev eth1 parent 1: prio 2 protocol ip prio 21 u32 match ip dst 0.0.0.0/0 flowid 1:20
#####################################################################
#
# Corp site end
#
# Mark VoIP protocol from gatekeeper/switch for special treatment
iptables -A PREROUTING -t mangle -j TOS -p udp -s 10.0.0.7 --set-tos 0x10
# eth1, which is your Internet/DSL interface
# Setup the basic reservation of 240kbit
tc qdisc add dev eth1 root handle 1: htb default 20
tc class add dev eth1 parent 1: classid 1:1 htb rate 600kbit ceil 640kbit burst 2k
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 240kbit
tc class add dev eth1 parent 1:2 classid 1:20 htb rate 400kbit
# Match IP Protocol type 47 (Check your VPN technology uses this protocol ID
# number in the IP header)
# Match Low Through put TOS (Check the inner IP-TOS value is copied into the
# outer IP-TOS value by your protocol stack, use
# "tcpdump -i eth1 -n -s 1500 -v" and capture some VPN data with UDP inside)
# Match the IP address of the VPN tunnel endpoint, however if you are on DSL
# with dynamic IP then you might as well scrap this value, otherwise change
# "0.0.0.0/0" to just "10.0.0.something/32" or remove
# "match ip src 0.0.0.0/0" completely.
# This would enforce the IP of the tunnel endpoint gets special treatment so
# that no one else on the lan (like peoples workstations) couldn't start
# using their own VPN with TOS=0x10 and take this bandwidth.
tc filter add dev eth1 parent 1: prio 1 protocol ip u32 match ip protocol 47 0xff match ip tos 0x10 0xff match ip src 0.0.0.0/0 flowid 1:10
# Everything else gets flowid 1:20
tc filter add dev eth1 parent 1: prio 2 protocol ip prio 21 u32 match ip dst 0.0.0.0/0 flowid 1:20
>
>
>PS. I am new to posting, and would like to update the thread, but I
>don't know how to a reply to the thread, I seem to only make a new post.
>
>
You have to subscribe and reply from the address you have subscribed as.
List-Subscribe: <http://mailman.ds9a.nl/mailman/listinfo/lartc>,
<mailto:lartc-request@mailman.ds9a.nl?subject=subscribe>
>Thanks for your suggestions, I will take a look at the Wondershaper, I
>saw some articles mention it but I didn't know if I could use it on the
>firewalls.
>
>
Good use on low bandwidth links.
>
>-----Original Message-----
>From: Darryl Miles [mailto:lartc-list@the-morg.org]
>Sent: Thursday, December 04, 2003 10:39 AM
>To: Greg Freeman
>Cc: lartc@mailman.ds9a.nl
>Subject: Re: [LARTC] $100 USD to the first person that can provide the
>rules/scripts that will solve the QOS latency & bandwidth allocation
>issue !!!!
>
>
>Greg,
>
>
>You do not say in your original article how your 640kbit/640kbit link is
>attached, eth0, eth1 or pppX? If the interface is dedicated only for
>WAN usage, or if the WAN be via a gateway? If your VPN endpoint hosts
>are on the same or a different box to that with the 640kbit link.
>
>You did not say if pinging between the two tunnel endpoint addresses
>(i.e. their non-10.x.x.x addresses) also had any latency reduction
>during the times of increased latency through the tunnel. I'm trying to
>establish if the 640kbit link is the point where the queuing occurs, or
>if its never saturated and the problem with your TC rule set.
>
>
>Since I expect the 640kbit link is your bottle neck, and that there is a
>quantity of non-VPN traffic also passing through this point (web
>browsing, email, internet downloading), rules MUST also be applied here.
>
> It is this point causing your latency issue, the device interface queue
>is whats holding all the packets and thus adding propagation delay.
> While the traffic going into the IPSEC it being controlled, there is
>nothing I can see in your configuration which arbitrates bandwidth usage
>between webbrowsing and VPN data over the 640kbit link.
>
>
>I am not the most knowledgable person about VPN and TC operation, but I
>would look for a solution using ipchains to MARK the DS/TOS field of the
>outside IP header of VPN packets only for VoIP/HiPriority packets, this
>has to be done on the box which is a VPN endpoint at the point each
>packet enters the tunnel. Maybe the inside TOS field is already copied
>into the outside TOS field during encapsulation (this is what I believe
>IPIP and GRE encaps would do). Use tcpdump on both the inside and
>outside interfaces, if possible to see. I would expect the UDP packets
>to already be marked with a "low latency" TOS (due to the nature of the
>applications), if this is the case then you have enough information to
>distinguish your important traffic from the rest over the 640kbit link.
> Other than this suggestion I'm not sure how you can mark the outside IP
>packet header based on the inside IP, UDP/TCP content during
>encapsulation (I'd like to know myself). I do not think any TC rules
>need to be applied to the ipsec0 interface, I believe you only need to
>ensure the packets have been marked at this point.
>
>The next thing to do is, at the box with the 640kbit link, use your TC
>rule set to provide bandwidth reservation based on the protocol byte
>(VPN traffic, ESP/AH, etc..) and the IP DS/TOS header marking to select
>them to be placed in a higher priority queue.
>
>
>Don't forget to account with the packet length increase due to the extra
>layer of headers of VPN traffic, both in overall bandwidth calculation
>and average packet length.
>
>If your 640kbit link were say DSL and your DSL providers equipment was
>between the two 640kbit link interfaces, then there are also other
>issues with managing the inbound packet queue length at your ISP. Check
>out the "WonderShaper" (on google) for information on the problem and
>how the TC rules in it help the situation, but basically your Internet
>downloads need to be controlled to prevent queueing by your ISP when it
>sends inbound data to you.
>
>
>Hope I read your original article correctly and am I'm pitching at the
>real problem,
>
>Darryl
>
>
>
>
>
>
>