[LARTC] couldn't get available bandwith
Hello all. We have three tunnels over the internet between our central gateway and some branch office gateway. Each gateway has eth0 on its LAN an eth1 on the internet. We use DSL lines and eth1's have the internet IP directly attached on it. Each gateway, also, acts as iptables NAT gateway. The outgoing bandwith is 300 kbit, and we tried this (i.e.) on each tunnel: tc qdisc add dev tun2 handle 1:0 root dsmark indices 4 default_index 0 tc qdisc add dev tun2 handle 2:0 parent 1:0 htb tc class add dev tun2 parent 2:0 classid 2:1 htb rate 4000bps ceil 4000bps tc class add dev tun2 parent 2:1 classid 2:2 htb rate 250bps ceil 1000bps tc qdisc add dev tun2 handle 3:0 parent 2:2 sfq tc class add dev tun2 parent 2:1 classid 2:3 htb rate 250bps ceil 3500bps tc qdisc add dev tun2 handle 4:0 parent 2:3 sfq tc class add dev tun2 parent 2:1 classid 2:4 htb rate 3250bps ceil 4000bps tc qdisc add dev tun2 handle 5:0 parent 2:4 sfq tc filter add dev tun2 parent 2:0 protocol all prio 1 tcindex mask 0x3 shift 0 tc filter add dev tun2 parent 2:0 protocol all prio 1 handle 3 tcindex classid 2:4 tc filter add dev tun2 parent 2:0 protocol all prio 1 handle 2 tcindex classid 2:3 tc filter add dev tun2 parent 2:0 protocol all prio 1 handle 1 tcindex classid 2:2 tc filter add dev tun2 parent 1:0 protocol all prio 1 handle 1:0:0 u32 divisor 1 tc filter add dev tun2 parent 1:0 protocol all prio 1 u32 match u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 1:0:0 tc filter add dev tun2 parent 1:0 protocol all prio 1 handle 1:0:1 u32 ht 1:0:0 match u16 0x16 0x at 0 classid 1:1 tc filter add dev tun2 parent 1:0 protocol all prio 1 handle 2:0:0 u32 divisor 1 tc filter add dev tun2 parent 1:0 protocol all prio 1 u32 match u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 2:0:0 tc filter add dev tun2 parent 1:0 protocol all prio 1 handle 2:0:1 u32 ht 2:0:0 match u16 0x19 0x at 2 classid 1:2 tc filter add dev tun2 parent 1:0 protocol all prio 1 u32 match u32 0x0 0x0 at 0 classid 1:3 We try classify SSH and SMTP and limit it to 2 kbytes/sec. It could get more bandwith if available. Other traffics must get more bandwith in all cirscumstances. Also, tc -s says: tc -s -d class show dev tun2 class htb 2:1 root rate 4000bps ceil 4000bps burst 1639b/8 mpu 0b cburst 1639b/8 mpu 0b level 7 Sent 1671352 bytes 2143 pkts (dropped 0, overlimits 0) lended: 937 borrowed: 0 giants: 0 tokens: 319488 ctokens: 319488 class htb 2:2 parent 2:1 leaf 3: prio 0 quantum 1000 rate 250bps ceil 1000bps burst 1601b/8 mpu 0b cburst 1609b/8 mpu 0b level 0 Sent 73221 bytes 99 pkts (dropped 0, overlimits 0) lended: 52 borrowed: 47 giants: 0 tokens: -4594059 ctokens: 1132136 class htb 2:3 parent 2:1 leaf 4: prio 0 quantum 1000 rate 250bps ceil 3500bps burst 1601b/8 mpu 0b cburst 1634b/8 mpu 0b level 0 Sent 1227729 bytes 857 pkts (dropped 0, overlimits 0) lended: 70 borrowed: 787 giants: 0 tokens: -265392 ctokens: 360214 class htb 2:4 parent 2:1 leaf 5: prio 0 quantum 1000 rate 3250bps ceil 4000bps burst 1631b/8 mpu 0b cburst 1639b/8 mpu 0b level 0 Sent 370402 bytes 1187 pkts (dropped 0, overlimits 0) lended: 1084 borrowed: 103 giants: 0 tokens: 391201 ctokens: 319488 AND tc -s -d qdisc show dev tun2 qdisc sfq 5: quantum 1450b limit 128p flows 128/1024 Sent 370402 bytes 1187 pkts (dropped 0, overlimits 0) qdisc sfq 4: quantum 1450b limit 128p flows 128/1024 Sent 1227729 bytes 857 pkts (dropped 0, overlimits 0) qdisc sfq 3: quantum 1450b limit 128p flows 128/1024 Sent 73221 bytes 99 pkts (dropped 0, overlimits 0) qdisc htb 2: r2q 10 default 0 direct_packets_stat 0 ver 3.7 Sent 1671352 bytes 2143 pkts (dropped 0, overlimits 2823) qdisc dsmark 1: indices 0x0004 default_index 0x Sent 1671352 bytes 2143 pkts (dropped 0, overlimits 0) but if we send big emails, when it passes trough tun2, and in absebce of other traffic, it only gets about 45 kbit/sec. Apparently, SMTP gets bandwith limitation, but it doesn't get available bandwith. Any light on it? --Miguel ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Timeout problem !
Hey all I have 5 adsl lines and have the following setup INTERNET ADSL lines 192.168.1.1-5 | | | | | - switch - | - eth1 linux nat box eth0 - | - LAN Right now i do the following, which are working correctly: I mark incoming packets via mark in iptables, connection are marked 1-5 Then i via 5 ip route tables adsl1-5 in each of them i specify the gateway (one of the adsl lines 192.168.1.1-5) This all works correctly. However i would like to have all adsllines i on multipath. i have tried: Marking all traffic with mark 1 ip route table adsl1 ip route add table adsl1 default equalize proto static nexthop via 192.168.1.1 dev eth1 nexthop via 192.168.1.2 dev eth1 nexthop via 192.168.1.3 dev eth1 nexthop via 192.168.1.4 dev eth1 nexthop via 192.168.1.5 dev eth1 I have applied the patches to the kernel from http://www.ssi.bg/~ja/#routes I have a ping-operation in the background as descripted in the dgd-usage.txt All traffic now is now sent via on of the adsl lines, everything seems to work, but Programs from the lan-computer seems to timeout, i have tried quite some thing but nothing seems to work! Please help ;) LBJ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb v3 not as good as htb v2?
Anton Yurchenko wrote: Hello, I`ve been using htb v2 for more then a year without any major problems. Recently I needed to upgrade to newer kernel becouse of non LARTC related issues. After installing 2.4.22 when the htb qdisc was attached to the interface even without any rules, I was not able to send more ~1mbit through the interface. After I reversed the htb3 patch and rebuild with htb2 everything works as normal. Has anyone experienced the same issue? thanks check your burst and quantum settings. maybe they are too low. bye, wilfried ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
PATCH : [Re: [Fwd: [LARTC] broadcast over gre tunnel?]]
Hi Guys,
Here is our patch to allow broadcast packets over a GRE tunnel.
Hopefully it might be accepted into the source someday.
You need to enabled bridging and GRE tunnels in your kernel. No other
options are required. The gre patch determines what type of protocol
type to put in the GRE header based on the whether the packet is
forwarded from a bridge or not.
To use the patch:
# Create your GRE tunnel
ip tunnel add gre1 mode gre remote 10.4.4.1 local 10.4.4.2
ifconfig gre1 up
# Bring the ethernet device up
ifconfig eth1 up
#create the bridge and add the devices:
brctl addbr br0
brctl addif br0 gre1
brctl addif br0 eth1
ifconfig br0 10.4.1.1 netmask 255.255.255.0 broadcast 10.4.1.255
regards
--
~~~
Damion de Soto - Software Engineer email: [EMAIL PROTECTED]
SnapGear --- ph: +61 7 3435 2809
| Custom Embedded Solutions fax: +61 7 3891 3630
| and Security Appliancesweb: http://www.snapgear.com
~~~
--- Free Embedded Linux Distro at http://www.snapgear.org ---
diff -ru linux-2.4.22/include/linux/if_tunnel.h linux-2.4.22.patched/include/linux/if_tunnel.h
--- linux-2.4.22/include/linux/if_tunnel.h Mon Dec 1 08:00:38 1997
+++ linux-2.4.22.patched/include/linux/if_tunnel.h Wed Oct 8 15:26:00 2003
@@ -15,6 +15,8 @@
#define GRE_FLAGS __constant_htons(0x00F8)
#define GRE_VERSION __constant_htons(0x0007)
+#define GRE_P_ETH_BR __constant_htons(0x6558)
+
struct ip_tunnel_parm
{
char name[IFNAMSIZ];
diff -ru linux-2.4.22/net/bridge/br_if.c linux-2.4.22.patched/net/bridge/br_if.c
--- linux-2.4.22/net/bridge/br_if.c Mon Aug 25 21:44:44 2003
+++ linux-2.4.22.patched/net/bridge/br_if.c Wed Oct 8 14:45:46 2003
@@ -226,8 +226,10 @@
if (dev-br_port != NULL)
return -EBUSY;
+#if 0
if (dev-flags IFF_LOOPBACK || dev-type != ARPHRD_ETHER)
return -EINVAL;
+#endif
if (dev-hard_start_xmit == br_dev_xmit)
return -ELOOP;
diff -ru linux-2.4.22/net/ipv4/ip_gre.c linux-2.4.22.patched/net/ipv4/ip_gre.c
--- linux-2.4.22/net/ipv4/ip_gre.c Mon Aug 25 21:44:44 2003
+++ linux-2.4.22.patched/net/ipv4/ip_gre.c Wed Oct 8 14:45:46 2003
@@ -18,6 +18,7 @@
#include asm/uaccess.h
#include linux/skbuff.h
#include linux/netdevice.h
+#include linux/etherdevice.h
#include linux/in.h
#include linux/tcp.h
#include linux/udp.h
@@ -119,6 +120,14 @@
static int ipgre_fb_tunnel_init(struct net_device *dev);
+
+/*
+ * we need a special function to be able to be able to pull the ethernet
+ * buffer out. It is nearly the same as the eth_type_trans structure except
+ * the header size is adjusted.
+ */
+unsigned short gre_eth_type_trans(struct sk_buff *skb, struct net_device *dev);
+
static struct net_device ipgre_fb_tunnel_dev = {
gre0, 0x0, 0x0, 0x0, 0x0, 0, 0, 0, 0, 0, NULL, ipgre_fb_tunnel_init,
};
@@ -566,6 +575,7 @@
u32seqno = 0;
struct ip_tunnel *tunnel;
intoffset = 4;
+ unsigned short proto;
if (!pskb_may_pull(skb, 16))
goto drop_nolock;
@@ -573,6 +583,7 @@
iph = skb-nh.iph;
h = skb-data;
flags = *(u16*)h;
+ proto = *(u16*)(h+2);
if (flags(GRE_CSUM|GRE_KEY|GRE_ROUTING|GRE_SEQ|GRE_VERSION)) {
/* - Version must be 0.
@@ -606,23 +617,6 @@
read_lock(ipgre_lock);
if ((tunnel = ipgre_tunnel_lookup(iph-saddr, iph-daddr, key)) != NULL) {
- skb-mac.raw = skb-nh.raw;
- skb-nh.raw = __pskb_pull(skb, offset);
- memset((IPCB(skb)-opt), 0, sizeof(struct ip_options));
- if (skb-ip_summed == CHECKSUM_HW)
- skb-csum = csum_sub(skb-csum,
- csum_partial(skb-mac.raw, skb-nh.raw-skb-mac.raw, 0));
- skb-protocol = *(u16*)(h + 2);
- skb-pkt_type = PACKET_HOST;
-#ifdef CONFIG_NET_IPGRE_BROADCAST
- if (MULTICAST(iph-daddr)) {
- /* Looped back packet, drop it! */
- if (((struct rtable*)skb-dst)-key.iif == 0)
-goto drop;
- tunnel-stat.multicast++;
- skb-pkt_type = PACKET_BROADCAST;
- }
-#endif
if (((flagsGRE_CSUM) csum) ||
(!(flagsGRE_CSUM) tunnel-parms.i_flagsGRE_CSUM)) {
@@ -639,6 +633,70 @@
}
tunnel-i_seqno = seqno + 1;
}
+
+ if (proto == GRE_P_ETH_BR) {
+ struct sk_buff *skb2;
+
+ /* Pull off the offset. */
+ skb-mac.raw = __pskb_pull(skb, offset);
+//#define OLD_WAY
+#ifndef OLD_WAY
+ /* ensure it is linear so we can simply copy the data out */
+ skb_linearize(skb, GFP_ATOMIC);
+
+ skb2 = dev_alloc_skb(skb-len+2);
+ if (!skb2) {
+printk(KERN_ERR Memory squeeze.\n);
+goto drop;
+ }
+
+ skb2-dev = tunnel-dev;
+
+ /* Packet allignment apparently. */
+ skb_reserve(skb2, 2);
+
+ /* copy data and then set length */
+ memcpy(skb2-data, skb-data, skb-len);
+ skb_put(skb2, skb-len);
+
+ /* setup protocol */
+ skb2-protocol = gre_eth_type_trans(skb2, tunnel-dev);
+
+ /* update counters */
+ tunnel-stat.rx_packets++;
+ tunnel-stat.rx_bytes += skb-len;
+
+#ifdef CONFIG_NETFILTER
+
Re: [LARTC] 10Mbit on HTB
On Sat, 11 Oct 2003, Kristiadi Himawan wrote: I want to try to shape 20-30Mbps traffic using HTB. It's possible? Anyone already try this? Yes. It's working very good. You may want to use hashes if you have a lot of filters. Thanks. --- Catalin(ux) BOIE [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
