Re: [LARTC] How to limit bandwidth by port?
On Sat, 2002-12-14 at 03:57, Andrea Rossato wrote:
> DOWNLINK=220
> UPLINK=125
> DEV=ppp0
>
> tc qdisc add dev $DEV root handle 1: htb default 10
>
> tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6
>
> tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
> ceil $[UPLINK}kbit burst 6k prio 1
>
> tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[3*$UPLINK/10]kbit\
> ceil $[9*$UPLINK/10]kbit burst 6k prio 2
>
> tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
> tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
>
> tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
> match ip dport 8080 0x flowid 1:20
>
>
> traffic to dport 80 will get 3/10 of bandwith (with possibility to
> borrow up to 9/10)
> andrea
Andrea,
I have another script (attached) Im just wondering how i could implement
the above script into it. Im not the most knowledgable on shaping in
general :)
thanks
-mdew (resent-again)
#! /bin/sh
EXT_IFACE=eth0
modprobe imq numdevs=1
# del the qdisc already loaded (if there)
tc qdisc del dev imq0 root
tc qdisc add dev imq0 handle 1: root htb default 12 r2q 1
# [ HTB queue ]
#|
#|
# [256] (class 1:1)
# / | \
#/ | \
# /|\
# / | \
# / | \
# [64] [64][128] (note: these add up the the parent's 256)
# (1:10) (1:11) (1:12)
# |||
# |||
# [sfq][sfq][sfq]
# (20:0) (21:0) (22:0)
# The main link: 252kbit (less is better)
tc class add dev imq0 parent 1: classid 1:1 htb rate 254kbit
# For 10.0.0.9 - 64kbit all to itself - Paul
tc class add dev imq0 parent 1:1 classid 1:10 htb rate 20kbit burst 1kbit prio 1 ceil 36kbit
# For 10.0.0.2 - 64kbit all to itself - Mark
tc class add dev imq0 parent 1:1 classid 1:11 htb rate 20kbit burst 1kbit prio 1 ceil 60kbit
# For 10.0.0.3 and 10.0.0.8 - 128kbit between them - Ryan - Mike
tc class add dev imq0 parent 1:1 classid 1:12 htb rate 200kbit burst 10kbit prio 1 ceil 252kb
it
# SFQ makes things a bit fairer (in theory)
tc qdisc add dev imq0 parent 1:10 handle 20:0 sfq
tc qdisc add dev imq0 parent 1:11 handle 21:0 sfq
tc qdisc add dev imq0 parent 1:12 handle 22:0 sfq
# Match iptables mark 1 and send to class 1:10 (64kbit A)
tc filter add dev imq0 protocol ip pref 1 parent 1: handle 1 fw classid 1:10
# Match iptables mark 2 and send to class 1:11 (64kbit B)
tc filter add dev imq0 protocol ip pref 2 parent 1: handle 2 fw classid 1:11
# Match iptables mark 3 and send to class 1:12 (128kbit)
tc filter add dev imq0 protocol ip pref 3 parent 1: handle 3 fw classid 1:12
# The IMQ device must be up before this will work...
# ip link set imq0 up (set below)
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -N incoming
iptables -t mangle -A incoming -d 10.0.0.9 -j MARK --set-mark 1
iptables -t mangle -A incoming -d 10.0.0.2 -j MARK --set-mark 2
iptables -t mangle -A incoming -m mark --mark 1 -j RETURN
iptables -t mangle -A incoming -m mark --mark 2 -j RETURN
iptables -t mangle -A incoming -j MARK --set-mark 3
iptables -t mangle -A FORWARD -i $EXT_IFACE -j incoming
iptables -t mangle -A FORWARD -i $EXT_IFACE -j IMQ
ip link set imq0 up
tc -s -d class show dev imq0
Re: [LARTC] Can I Classify Non-IP Traffic?
Hello all (and Griff in particular), I stand corrected! Thank you for the note, Hannes. I'll speculate below and show how I would solve this problem, although I have not actually tried it. But an interesting exercise captivates the imagination! So let's be off! : i just quote what julian wrote some time ago, seems as if it would : possible what griff wants to do: It certainly seems like this should work, according to Julian's description. So, I'll take a stab at trying to write a basic rule to classify IPX (I have no way to test, as I have no IPX network available). The first thing we'll want to do is identify IPX packets. On first googling I found one page [1] identifying the ethernet frame type code for encapsulated IPX packets, 0x8137. After further googling, I found a lengthy discussion [2] of the characteristics of IPX data carried on ethernets. I will assume (incorrectly, to be sure) that ethernet frame type 0x8137 identifies an IPX packet. In that case, U32="tc filter add dev $DEV parent 1:0 protocol ip u32" $U32 match u16 0x8137 0x at -2 flowid 1:1 should classify all all such IPX packets, correct? (Please note that the above command fails if "protocol ip" is omitted from the command string.) If that is the case, then we should be able to select the correct byte ranges from an IPX packet to classify the IPX packet into the desired flow/class, correct? According to the packet structure [3], we should select on: IPX packet field byte offset --- --- destination network +6 destination node +10 source network +18 source node +22 Now, I cannot assure the reader that my math is correct. With reference to the detailed history of IPX encapsulation on ethernet [2], a reader should be able to locate the initial byte of an IPX packet. I suspect the writing of filters will require detailed and accurate knowledge about the characteristics of the IPX packets on the network. This knowledge shouldn't be too difficult to gain with a bit of judicious use of tcpdump (maybe "tcpdump -nn -e -l -x not ip" or something like that). I have tested the technique of classifying packets based on MAC addresses in my own network, with fabulous success, however. They end up in the specified queue exactly as I desire. : >Why not, just use negative offsets with U32 to access : > the 14-byte eth frame header before the IP header: : > : > Decimal OfsDescription : > --- : > -14: DST MAC, 6 bytes : > -8:SRC MAC, 6 bytes : > -2:Eth PROTO, 2 bytes, eg. ETH_P_IP : > 0: Protocol header (IP Header) Thanks very much to Hannes for his gentle prod, and to Julian who posted the original suggestion. Maybe if you have success, Griff, you might post a summary of your method and math for posterity? You are probably not the only one out there who wishes to mix bridging, traffic control, and IPX. -Martin [1] http://www.geocities.com/SiliconValley/Haven/4824/ethernet.html [2] http://www.ncat.co.uk/Net_Lib/nov_frm.htm [3] http://www.novell.com/documentation/lg/nw6p/ipx_enu/data/hc1w6pvi.html P.S., after reading a bit about IPX, I'm somewhat relieved to return to the world of IP. -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] speed problem
There are collisions in the eth0 interface while there are no collisions in the eth1 wireless interface I have tried the mii-tool as suggested by [EMAIL PROTECTED] it did help to some extent but I was not successful in the overall situation I would like to elaborate the setup in more detail A(eth0) <->distance 2mts <---> (intel Switch 550T) <>distance30mts (hub) distance 20mts <--->B(eth0) (eth1 wireless card wan) < ~ ~ ~ ~ ~ > (eth1 wireless card wan) (eth0) <>distance 2mts (hub) <-->distance 10mts (PC) A(eth0) the value of this interface card as per the dmesg of the box is as below eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:90:27:B2:04:82, IRQ 10. Receiver lock-up bug exists -- enabling work-around. Board assembly 677173-001, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). Receiver lock-up workaround activated. B(eth0) the value of this interface card as per the dmesg of the box is as below eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:90:27:24:EC:8C, IRQ 15. Receiver lock-up bug exists -- enabling work-around. Board assembly 689661-004, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). Receiver lock-up workaround activated. B(eth1) this is a wireless aironet 4800 isa card mounted on a RH 7.3 box who's bitrate is set to 11mbps and its status is as below Every 2s: /bin/cat /proc/driver/aironet/eth1/Status Fri Jan 3 16:20:26 2003 Mode: 1f Signal Strength: 57 Signal Quality: 125 SSID: solgold AP: Freq: 0 BitRate: 11mbs Driver Version: airo.c 1.5.2 2001/01/22 (Benjamin Reed ) + CISCO EXTENTIONS Device: PC4800A Manufacturer: Aironet Wireless Communications Firmware Version: 3.82 Radio type: 2 Country: 1 Hardware Version: 52 Software Version: 382 Software Subversion: 0 Boot block version: 138 C(eth1) this is a wireless aironet 4800 isa card mounted on a MikroTik 2.4 ver router box who's bitrate is set to 11mbps and its status is as below [GOLDEN] > interface pc monitor pc1 quality: 48 strength: 142 current-rate: 11Mbit/s current-frequency: 2452MHz synchronized: yes associated: no ssid: solgold access-point: CA:03:35:02:16:02 access-point-name: error-number: 0 Regards, Vishal Gandhi - Original Message - From: "Martin A. Brown" <[EMAIL PROTECTED]> To: "Vishal Gandhi Kommineni" <[EMAIL PROTECTED]> Cc: "LARTC" <[EMAIL PROTECTED]> Sent: Thursday, January 02, 2003 9:49 PM Subject: Re: [LARTC] speed problem > Vishal, > > : > the first thing i'd like to check is if the ethernet cards are running > : > in full- or half-duplex mode. AFAIK running one card in half-duplex mode > : > and the other trying to force full-duplex mode can lead to lots of > : > collisions, so this could be a reason for slow speed. > > I agree with Ulrich, and apparently that may have been your problem. > > : thanks for the reply, i found that there are collission when i use a > : hub in between, How do i make sure that both the ethernet cards are > : running in half or full duplex mode, how do i check if weathere an > : ethernet is in half or full duplex mode > > You may find that one of the following tools helps you to determine what > your ethernet card has negotiated with its peer: > > - ethtool ( the tool which will probably continue to be maintained and > supported under linux ) > http://www.gnu.org/directory/sysadmin/Monitor/ethtool.html > > - mii-diag, aka mii-tool, ( one of these two is usually available on > common distributions available today ) > http://freshmeat.net/projects/mii-diag/ > > -Martin > > Here's some example output from mii-diag and mii-tool: > > # mii-tool --help > usage: mii-tool [-VvRrwl] [-A media,... | -F media] [interface ...] >-V, --version display version information >-v, --verbose more verbose output >-R, --reset reset MII to poweron state >-r, --restart restart autonegotiation >-w, --watch monitor for link status changes >-l, --log with -w, write events to syslog >-A, --advertise=media,... advertise only specified media >-F, --force=media force specified media technology > media: 100baseT4, 100baseTx-FD, 100baseTx-HD, 10baseT-FD, 10baseT-HD, >(to advertise both HD and FD) 100baseTx, 10baseT > # mii-tool eth0 > eth0: negotiated 100baseTx-FD flow-control, link ok > > > # mii-diag --help > Usage: mii-diag [-aDfrRvVw] [-AF ] [--watch] . > >Show the link status of the specified netwo
Re: [LARTC] speed problem
I dont see any collisions when make ifconfig, i feel the problem is in forwarding the packets by the linux box inbetween the interfaces, it is here that there is lot of packet loss, Do you think it to be so Thanks & Regards, Vishal Gandhi - Original Message - From: "Lars Gaarden" <[EMAIL PROTECTED]> To: "LARTC" <[EMAIL PROTECTED]> Sent: Thursday, January 02, 2003 4:52 PM Subject: Re: [LARTC] speed problem > Vishal Gandhi Kommineni wrote: > > Warm wishes for the new year 2003, > > thanks for the reply, i found that there are collission when i use a hub in > > between, > > How do i make sure that both the ethernet cards are running in half or full > > duplex mode, > > how do i check if weathere an ethernet is in half or full duplex mod > > > Could you provide the output from 'ifconfig' and 'route -n' on A, B and > C? This is either a reverse DNS, duplex mismatch or routing problem. > > To see if your are full or half duplex, see if ifconfig reports any > collisions on the eth interface - on full duplex you never get any > collisions. > > If it takes a long time from you try to connect until it starts > downloading, you have a DNS problem. > > If the download is incredibly slow and one or more of the network > interfaces on A, B or C report a huge amount of collisions, you > have a duplex problem. > > Routing problems usually result in not being able to connect at > all, which doesn't seem to be the case here. > > -- > The content of this message can either be used according to normal > copyright law (including quoting and personal copies) or by the terms of > the GNU Free Documentation License http://www.gnu.org/licenses/fdl.html > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] speed problem
I have tried the mii-tool as suggested by [EMAIL PROTECTED] it did help to some extent but I was not successful in the overall situation I would like to elaborate the setup in more detail A(eth0) <->distance 2mts <---> (intel Switch 550T) <>distance30mts (hub) distance 20mts <--->B(eth0) (eth1 wireless card wan) < ~ ~ ~ ~ ~ > (eth1 wireless card wan) (eth0) <>distance 2mts (hub) <-->distance 10mts (PC) A(eth0) the value of this interface card as per the dmesg of the box is as below eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:90:27:B2:04:82, IRQ 10. Receiver lock-up bug exists -- enabling work-around. Board assembly 677173-001, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). Receiver lock-up workaround activated. B(eth0) the value of this interface card as per the dmesg of the box is as below eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:90:27:24:EC:8C, IRQ 15. Receiver lock-up bug exists -- enabling work-around. Board assembly 689661-004, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). Receiver lock-up workaround activated. B(eth1) this is a wireless aironet 4800 isa card mounted on a RH 7.3 box who's bitrate is set to 11mbps and its status is as below Every 2s: /bin/cat /proc/driver/aironet/eth1/Status Fri Jan 3 16:20:26 2003 Mode: 1f Signal Strength: 57 Signal Quality: 125 SSID: solgold AP: Freq: 0 BitRate: 11mbs Driver Version: airo.c 1.5.2 2001/01/22 (Benjamin Reed ) + CISCO EXTENTIONS Device: PC4800A Manufacturer: Aironet Wireless Communications Firmware Version: 3.82 Radio type: 2 Country: 1 Hardware Version: 52 Software Version: 382 Software Subversion: 0 Boot block version: 138 C(eth1) this is a wireless aironet 4800 isa card mounted on a MikroTik 2.4 ver router box who's bitrate is set to 11mbps and its status is as below [GOLDEN] > interface pc monitor pc1 quality: 48 strength: 142 current-rate: 11Mbit/s current-frequency: 2452MHz synchronized: yes associated: no ssid: solgold access-point: CA:03:35:02:16:02 access-point-name: error-number: 0 Regards, Vishal Gandhi - Original Message - From: <[EMAIL PROTECTED]> To: "Vishal Gandhi Kommineni" <[EMAIL PROTECTED]> Sent: Thursday, January 02, 2003 3:24 PM Subject: Re: [LARTC] speed problem > Vishal Gandhi Kommineni wrote: > > Warm wishes for the new year 2003, > > Thanks. > > > How do i make sure that both the ethernet cards are running in half or > > full duplex mode, how do i check if weathere an ethernet is in half or > > full duplex mode > > You can use mii-tool. To set eth0 to 100MBit/s halfduplex, run: > > # mii-tool -F 100BaseTx-HD eth0 > > Note: This only works if your card supports this. Or should i say if the > driver supports it? Anyway, give it a try. > > > Thanks in advance > > Vishal Gandhi > > You're welcome, cheers, > Alex. > > -- > "The most likely way for the world to be destroyed, most > experts agree, is by accident. That's where we come in. We're > computer professionals. We cause accidents." >-- Nathaniel Borenstein > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tc qdisc show - statistics truncated
On Thu, 2 Jan 2003, Jingsong Fu wrote: > > I am trying to show PRIO qdisc stats, and always get statistics truncated as >follows, could someone help to explain why and how correct it? > Thanks, > Jingsong > > # tc -s qdisc show dev eth0 > qdisc prio 1: bands 8 priomap 7 6 5 4 3 2 1 0 7 7 7 7 7 7 7 7 > statistics truncated Your tc binary is not matching your kernel version, i would say. Install a new tc version, preferably from source. Patrick ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tc qdisc show - statistics truncated
I am trying to show PRIO qdisc stats, and always get statistics truncated as follows, could someone help to explain why and how correct it? Thanks, Jingsong # tc -s qdisc show dev eth0 qdisc prio 1: bands 8 priomap 7 6 5 4 3 2 1 0 7 7 7 7 7 7 7 7 statistics truncated ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can I Classify Non-IP Traffic?
hi martin, Martin A. Brown wrote: Seems like he needs a "protocol generic" (or better yet for him, "protocol ipx"), which would allow him to count byte offsets in the manner of u32. I know of no such tool. i just quote what julian wrote some time ago, seems as if it would possible what griff wants to do: --snip-- Hello, On Sun, 22 Dec 2002, Nickola Kolev wrote: > I need to classified the traffic by looking at the packet destination > and source MAC address. Can anyone here suggest ways to do this. > > I have read through the HOWTO documentation, from there I know that > U32 filter can only filter out IP or higher layer. May I know why U32 > filter did not support datalink layer (MAC address)? Is it that when This is a lie. > packet entering TC, the datalink layer no longer there? Are there any > filter which can filter the MAC address? You can filter with U32 by src/dst MAC on ingress and by dst MAC on egress. On egress the src MAC is replaced with new one and there is no good reason to apply U32 filters for sender's MAC. > Before this, I have successfully implement QoS through source and > destination IP address using CBQ. Here I would like to thanks LARTC > for the help. > Yes, you can do this, but using fw marking, not u32 classifier. Just Why not, just use negative offsets with U32 to access the 14-byte eth frame header before the IP header: Decimal Ofs Description --- -14: DST MAC, 6 bytes -8: SRC MAC, 6 bytes -2: Eth PROTO, 2 bytes, eg. ETH_P_IP 0: Protocol header (IP Header) search through the various netfilter extensions - you really can do miracles with them :)) E-gards, Nickola Regards -- Julian Anastasov <[EMAIL PROTECTED]> --snap-- regards, hannes ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 3c905 or intel with 82550 chip? for htb + bridge + (u32 & fw filters)
>(realtec 8029/8139) have been using them since Yeah, I recently bought two 8139s to use in a bridge with shaping, they have been working great and was _very_ cheap. Ive also never had a problem with realtek. --- John Bäckstrand ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 3c905 or intel with 82550 chip? for htb + bridge + (u32& fw filters)
Some time ago i saw a test where the vere cheap realtek chipset came out best (realtec 8029/8139) have been using them since never had a problem with them Magazine was CT (german) a quality magazine Frank ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 3c905 or intel with 82550 chip? for htb + bridge + (u32 & fw filters)
Yea my gut want intels i´m just making sure... some times i read diferent things in linux or bsd routing projects about that some cards being better than others, issues about the tulip chip (dec), 3coms, etc and since i had some problems in the past with earlier version of 2.x having multiple 3c905, i´m asking know agree with you and thanks for the reply --- "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: > On Thu, 2003-01-02 at 13:58, Stef Coene wrote: > > > > The chip doesn't mather. All shaping is done in > the kernel so in software. > > > > With that said, I use and recommend Intel nics. I > used to use some 3com > ones, but they were crap. > > I personally like the 82557-9, mostly the 9's since > they are tiny. > > But basically any Intel card that is supported by > the e100 driver. The > e100 driver for Intel cards is my favorite. Intel is > always releasing > new versions. Not to mention the IANS software that > is also available. > > My two cents, Intel all the way. > > -- > Sincerely, > William L. Thomson Jr. > Support Group > Obsidian-Studios Inc. > 439 Amber Way > Petaluma, Ca. 94952 > Phone 707.766.9509 > Fax707.766.8989 > http://www.obsidian-studios.com > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 3c905 or intel with 82550 chip? for htb + bridge +(u32 & fw filters)
On Thu, 2003-01-02 at 13:58, Stef Coene wrote: > > The chip doesn't mather. All shaping is done in the kernel so in software. > With that said, I use and recommend Intel nics. I used to use some 3com ones, but they were crap. I personally like the 82557-9, mostly the 9's since they are tiny. But basically any Intel card that is supported by the e100 driver. The e100 driver for Intel cards is my favorite. Intel is always releasing new versions. Not to mention the IANS software that is also available. My two cents, Intel all the way. -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax707.766.8989 http://www.obsidian-studios.com ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 3c905 or intel with 82550 chip? for htb + bridge + (u32 & fw filters)
On Thursday 02 January 2003 18:32, Victor Cassar wrote: > Hi: > > finally i´m working with htb + bridge on 2.4.20 to > shape ip traffic, and i want to build a system but i´m > not up2date with these specific driver issues > > mi primary need is to shape small bandwidths 128 or > 256 > > are there any diferences between these 2 options? > Since i need more granularity in the queuing > behavior..i dont know how relevant this decision can > be.. The chip doesn't mather. All shaping is done in the kernel so in software. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] How HTB treats priorities?
On Thursday 02 January 2003 19:03, ISC Robert Kryczało wrote: > Hi there, > > >> > Lets assume all classes try to send at their maximum speed trying to > >> > >> saturate the link. According to what you have written class D will > >> get 64kbit/s, class E 128kbit/s and class F will get 32kbit/s. The > >> sum is 224kbit/s if I am correct. Am I right? > >> Yes. So the rate of the parent B must also be at least 224kbit/s. > >> And not 8kbis/s like you wrote before. > >> > >> > I dont want it to happen since customers have paid for 128kbit/s > >> > >> with guaranteed rato of 8kbit/s. Is there a way to acomplish my > >> task???. Can it be done using HTB only? > >> Yes, make the sum of D,E and F = 128kbit/s. > > > > This is the same kind of setup I've been shooting for. When you say the > > sum of D, E and F, are you talking rate or ceil? I would imagine ceil. > > That makes it hard to please the customer who is paying for 128kbit, yet > > only sees it in 3 42kbit streams, or some other breakdown of the 128k. > > If I understand you right, there is no way to run three seperate > > children for prioritizing packets, and still give full bandwidth of > > parent to any of the three, without allowing the use of all three at the > > same time to exceed the parent? > > Yes, I am talking about ceil. I was talking about the rate. The ceil must be 128kbit/s so they can borrow up to 128kbit/s. > And the problem is that (and you as well) I > want 128kbit/s go to class E in case D and F are idle. There must be a way > to set this up, but for now I don't know how. If neither ceiling nor rate > of parent class is respected, what are parents in htb for. Flat structure > would be enough. I would like to receive more feedback on this. That's no problem IF you follow some basic rules. You can find them on www.docum.org on the faq page. You have to see the ceil as a maximum of the class. And the rate as a minimum bandwidth and a "divider". The other problem is the parent rate and ceil. I did some test and I have strange results. I still have to find a way to find out how you can configure the parent rate and ceil to get a good setup. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can I Classify Non-IP Traffic?
Jose, If I read his query correctly, he wants to classify IPX or something else. /etc/protocols is a mapping of identifiers for the contents of IP packets, so in this case, /etc/protocols doesn't help him. Seems like he needs a "protocol generic" (or better yet for him, "protocol ipx"), which would allow him to count byte offsets in the manner of u32. I know of no such tool. -Martin : > My question is can classify the non-IP traffic? Ideally I'd like to be : > able create a queue for IPX traffic.I know the tc filters command has a : > protocol statement but I can't find any information about setting this : > to anything but ip or ipv6. : > : Well, you seem to be already using "iptables" and the "fw" filter to : mark and categorize traffic. "iptables" can also match non-IP : protocols, using "--protocolo PROTOCOL". You can't go deeper into these : non-IP packets, but you can mark them by protocol, using any of the : protocols in the "/etc/protocols" file. : : Hope it helps. : : -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can I Classify Non-IP Traffic?
On Thursday, 02 January 2003, at 16:40:34 +, Griff@BP3Web wrote: > My question is can classify the non-IP traffic? Ideally I'd like to be > able create a queue for IPX traffic.I know the tc filters command has a > protocol statement but I can't find any information about setting this > to anything but ip or ipv6. > Well, you seem to be already using "iptables" and the "fw" filter to mark and categorize traffic. "iptables" can also match non-IP protocols, using "--protocolo PROTOCOL". You can't go deeper into these non-IP packets, but you can mark them by protocol, using any of the protocols in the "/etc/protocols" file. Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.20-xfs) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] How HTB treats priorities?
Hi there, >> > Lets assume all classes try to send at their maximum speed trying to >> saturate the link. According to what you have written class D will >> get 64kbit/s, class E 128kbit/s and class F will get 32kbit/s. The >> sum is 224kbit/s if I am correct. Am I right? >> Yes. So the rate of the parent B must also be at least 224kbit/s. >> And not 8kbis/s like you wrote before. >> >> > I dont want it to happen since customers have paid for 128kbit/s >> with guaranteed rato of 8kbit/s. Is there a way to acomplish my >> task???. Can it be done using HTB only? >> Yes, make the sum of D,E and F = 128kbit/s. > > This is the same kind of setup I've been shooting for. When you say the > sum of D, E and F, are you talking rate or ceil? I would imagine ceil. > That makes it hard to please the customer who is paying for 128kbit, yet > only sees it in 3 42kbit streams, or some other breakdown of the 128k. > If I understand you right, there is no way to run three seperate > children for prioritizing packets, and still give full bandwidth of > parent to any of the three, without allowing the use of all three at the > same time to exceed the parent? Yes, I am talking about ceil. And the problem is that (and you as well) I want 128kbit/s go to class E in case D and F are idle. There must be a way to set this up, but for now I don't know how. If neither ceiling nor rate of parent class is respected, what are parents in htb for. Flat structure would be enough. I would like to receive more feedback on this. The real reason for this is to limit p2p traffic, still allowing customer to surf the web, send email, play counter strike at full speed. Robert Kryczało ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] How HTB treats priorities?
Hello, >> A >> / \ >> B C >> >> Class A rate and ceiling is set to something like 490kbit/sek (or >> lower) >> to move queues to my linux traffic shaper. I set equal prios, rate for >> B and C equals 8 kbit/s, ceiling for B and C equals 128 kbit/s. This >> setup is supposed to fulfill my needs. It should work as expected, >> right? > No. Why don't you take rate = ceil = 128kbit/s ?? If A uses all it > can, 128, there is still 512-128 left for the other as his mimum > bandwidth. Or do you want so say 8kilobyte ? No, 8 kilobits or 1kilobyte per second. The reason for this is that I want to have around 40-50 customer classes inside A. With guaranteed rate of 8kbit/s and ceiling of 128kbit/sek. The statistics data I have gathered leads me to a conclusion that one of every three users utilizes 33% of his bandwidth (33% of 128kbit/s), two others are idle. In pratice we can have 80-100 customers per 1Mbit and it works well if no p2p software (like Kazaa is involved). This is why I want to switch to htb and its ceiling feature. Customers pay relatively low rates and thanks to current cbq setup receive relatively good service. Anyway, we have customers using 128/128(rate/ceiling) which pay 8 times more. >> A >>/ \ >> B C >> /|\ /|\ >> D E F G H I >> >> D,G rate=4/ceil=64 >> E,H rate=3/ceil=128 >> F,I rate=1/ceil=32 >> >> Priorities for all classes are the same. >> >> Lets assume all classes try to send at their maximum speed trying to >> saturate the link. According to what you have written class D will get >> 64kbit/s, class E 128kbit/s and class F will get 32kbit/s. The sum is >> 224kbit/s if I am correct. Am I right? > Yes. So the rate of the parent B must also be at least 224kbit/s. And > not 8kbis/s like you wrote before. I understand but... I still want to limit customer B to 128 kbit/s. And guarantee them 8kbit/s. > >> I dont want it to happen since customers have paid for 128kbit/s with >> guaranteed rato of 8kbit/s. Is there a way to acomplish my task???. >> Can it be done using HTB only? > Yes, make the sum of D,E and F = 128kbit/s. Let's say I give D bandwidth of 32 kbit/s, E bandwidth od 64 kbit/s and F bandwidth 32 kbit/s. When every classes are idle ond only E attempte to transmit at maximum speed, it will be given 64kbit/sek not 128kbit/s:(. Customers will not be happy, because in current setup they can reach 128kbit/s (and thanks to cbq inaccuracies even more - around 155kbit/s). > >> >> >Remaining bandwidth inside class B is distributed first to class >> D, >> >> >> >> then E and then F and is limited by ceiling parameter . Right??? >> >> yes, what you have said is right. >> > >> > Confirmed. Lowest prio classes are allowed to send first. >> >> It is intuitive. Thanks for confirmation. Anyway, classes D,E,F are >> limited only by their ceil, not by ceil of class B. Hm?. Performance >> reasons, right? > I have some rules on the faq page on www.docum.org regarding the rate > and ceil of parent and child classes. If you follow these rules, it > will be easier to understand how each class will behave. I have read it. In simple cases I totaly agree. But there must be something missing (or I am totally wrong:) ). Or the setup I require is not possible to create. >> > Nor the rate, nor the ceil are respected if the child class can >> send. So if B end C can send the remaining bandwidth, they will. >> Even if the parent ceil is not permitting it. >> >> Well... I hoped for opposite. If the ceiling of parent class is not >> respected, then setting htb up the way I require is rather >> impossible.? Right:( ? > No. You have to see the rate as a minimum bandwidth and also like a > "proportion". I mean if you have a class with child rate = 10 and an > other child class with rate = 30, the first class will get 25% of the > bandwidth. So the real value of rate doesn't mather. I think exactly the way you described. I see rate the same way you do. Unfotunetaly this leads me to a conclusion that htb has serious drawbacks. If the ceiling of the parent is not respected then it is impossible to create setup I require. In this case it is also not necesary to create parent classes. I hardly belive that. I must omit something important. There follows interesting quote from http://luxik.cdi.cz/~devik/qos/htb/old/develnotes.htm "Lower levels are completely dequeueued before borrowing from higher levels.". So is it possible that prio and rate and ceiling of parent class matters? And teator of htb qdisc often uses term of borrowing bandwidth from parent.. >> >> >What if C and B have different rates? >> >> >Is prio parameter taken into account when htb tries to meet >> >> guaranteed rate rules? >> >> >> >>I think the "prio" parameter is only used after all classes have >> >> reached their guaranteed minimum rate, to allow the user to create >> classes that will borrow bandwidth over other classes. >> > >> > Yep. >> >> OK. You have cleared thing up:) > I think
[LARTC] 3c905 or intel with 82550 chip? for htb + bridge + (u32 & fw filters)
Hi: finally i´m working with htb + bridge on 2.4.20 to shape ip traffic, and i want to build a system but i´m not up2date with these specific driver issues mi primary need is to shape small bandwidths 128 or 256 are there any diferences between these 2 options? Since i need more granularity in the queuing behavior..i dont know how relevant this decision can be.. thanks in advance for your coments __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can I Classify Non-IP Traffic?
On Thu, Jan 02, 2003 at 04:40:34PM +, Griff@BP3Web wrote: > Background: Thanks to the LARTC howto, this list and Stef Coene's and > devik's excellent web sites I now have an ethernet bridge (patch > bridge-nf.0.0.7) happily prioritising traffic (12Mbit) into 10 queues > (9 for IP and 1 for non-IP) using a combination of iptables (fwmark) > and htb3 and sfq. Many thanks. > > At the moment I'm filtering all non-IP traffic by setting the default > queue on the htb root qdisc to my non-IP class and having my last rule > in iptables (POSTROUTING) marks all IP packets such that htb places > these packets into my lowest priority IP queue (note this is different > from the default). > > My question is can classify the non-IP traffic? Ideally I'd like to be > able create a queue for IPX traffic.I know the tc filters command has a > protocol statement but I can't find any information about setting this > to anything but ip or ipv6. Using ebtables, it is possible to filter non-ip traffic. It is merged into the 2.5 kernel. For the 2.4, you need patches. http://users.pandora.be/bart.de.schuymer/ebtables/ Greetings, Ivo De Decker ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Can I Classify Non-IP Traffic?
Background: Thanks to the LARTC howto, this list and Stef Coene's and devik's excellent web sites I now have an ethernet bridge (patch bridge-nf.0.0.7) happily prioritising traffic (12Mbit) into 10 queues (9 for IP and 1 for non-IP) using a combination of iptables (fwmark) and htb3 and sfq. Many thanks. At the moment I'm filtering all non-IP traffic by setting the default queue on the htb root qdisc to my non-IP class and having my last rule in iptables (POSTROUTING) marks all IP packets such that htb places these packets into my lowest priority IP queue (note this is different from the default). My question is can classify the non-IP traffic? Ideally I'd like to be able create a queue for IPX traffic.I know the tc filters command has a protocol statement but I can't find any information about setting this to anything but ip or ipv6. Griff ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] How HTB treats priorities?
On Tue, 31 Dec 2002 00:37:44 +0100 Stef Coene <[EMAIL PROTECTED]> wrote > > Lets assume all classes try to send at their maximum speed trying to > > saturate the link. According to what you have written class D will get > > 64kbit/s, class E 128kbit/s and class F will get 32kbit/s. The sum is > > 224kbit/s if I am correct. Am I right? > Yes. So the rate of the parent B must also be at least 224kbit/s. And > not 8kbis/s like you wrote before. > > > I dont want it to happen since customers have paid for 128kbit/s with > > guaranteed rato of 8kbit/s. Is there a way to acomplish my task???. > > Can it be done using HTB only? > Yes, make the sum of D,E and F = 128kbit/s. This is the same kind of setup I've been shooting for. When you say the sum of D, E and F, are you talking rate or ceil? I would imagine ceil. That makes it hard to please the customer who is paying for 128kbit, yet only sees it in 3 42kbit streams, or some other breakdown of the 128k. If I understand you right, there is no way to run three seperate children for prioritizing packets, and still give full bandwidth of parent to any of the three, without allowing the use of all three at the same time to exceed the parent? --- Homer Parker /"\ ASCII Ribbon Campaign \ / No HTML/RTF in email http://www.homershut.net x No Word docs in email telnet://bbs.homershut.net/ \ Respect for open standards This e-mail message is 100% Microsoft free! WARNING: THIS ACCOUNT BELONGS TO A RABID ANTI-SPAMMER NET-NAZI DOT-COMMUNIST!! msg03545/pgp0.pgp Description: PGP signature
Re: [LARTC] speed problem
Vishal, : > the first thing i'd like to check is if the ethernet cards are running : > in full- or half-duplex mode. AFAIK running one card in half-duplex mode : > and the other trying to force full-duplex mode can lead to lots of : > collisions, so this could be a reason for slow speed. I agree with Ulrich, and apparently that may have been your problem. : thanks for the reply, i found that there are collission when i use a : hub in between, How do i make sure that both the ethernet cards are : running in half or full duplex mode, how do i check if weathere an : ethernet is in half or full duplex mode You may find that one of the following tools helps you to determine what your ethernet card has negotiated with its peer: - ethtool ( the tool which will probably continue to be maintained and supported under linux ) http://www.gnu.org/directory/sysadmin/Monitor/ethtool.html - mii-diag, aka mii-tool, ( one of these two is usually available on common distributions available today ) http://freshmeat.net/projects/mii-diag/ -Martin Here's some example output from mii-diag and mii-tool: # mii-tool --help usage: mii-tool [-VvRrwl] [-A media,... | -F media] [interface ...] -V, --version display version information -v, --verbose more verbose output -R, --reset reset MII to poweron state -r, --restart restart autonegotiation -w, --watch monitor for link status changes -l, --log with -w, write events to syslog -A, --advertise=media,... advertise only specified media -F, --force=media force specified media technology media: 100baseT4, 100baseTx-FD, 100baseTx-HD, 10baseT-FD, 10baseT-HD, (to advertise both HD and FD) 100baseTx, 10baseT # mii-tool eth0 eth0: negotiated 100baseTx-FD flow-control, link ok # mii-diag --help Usage: mii-diag [-aDfrRvVw] [-AF ] [--watch] . Show the link status of the specified network interface. The default interface is "eth0". The common usage is mii-diag eth0 Frequently used options are -A --advertise -F --fixed-speed Speed is one of: 100baseT4, 100baseTx, 100baseTx-FD, 100baseTx-HD, 10baseT, 10baseT-FD, 10baseT-HD -s --status Return exit status 2 if there is no link beat. Less frequently used options are -a --all-interfaces Show the status all interfaces (Not recommended with options that change settings.) -D --debug -g --read-parametersGet driver-specific parameters. -G --set-parameters PARMS Set driver-specific parameters. Parameters are comma separated, missing elements retain existing value. -M --msg-level LEVELSet the driver message bit map. -p --phy ADDR Set the PHY (MII address) to report. -r --restartRestart the link autonegotiation. -R --reset Reset the transceiver. -v --verboseReport each action taken. -V --versionEmit version information. -w --watch Continuously monitor the transceiver and report changes. This command returns success (zero) if the interface information can be read. If the --status option is passed, a zero return means that the interface has link beat. # mii-diag eth0 Basic registers of MII PHY #1: 3000 7809 02a8 0154 05e1 . Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. End of basic transceiver information. -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] speed problem
Vishal Gandhi Kommineni wrote: Warm wishes for the new year 2003, thanks for the reply, i found that there are collission when i use a hub in between, How do i make sure that both the ethernet cards are running in half or full duplex mode, how do i check if weathere an ethernet is in half or full duplex mod Could you provide the output from 'ifconfig' and 'route -n' on A, B and C? This is either a reverse DNS, duplex mismatch or routing problem. To see if your are full or half duplex, see if ifconfig reports any collisions on the eth interface - on full duplex you never get any collisions. If it takes a long time from you try to connect until it starts downloading, you have a DNS problem. If the download is incredibly slow and one or more of the network interfaces on A, B or C report a huge amount of collisions, you have a duplex problem. Routing problems usually result in not being able to connect at all, which doesn't seem to be the case here. -- The content of this message can either be used according to normal copyright law (including quoting and personal copies) or by the terms of the GNU Free Documentation License http://www.gnu.org/licenses/fdl.html ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] speed problem
Warm wishes for the new year 2003, thanks for the reply, i found that there are collission when i use a hub in between, How do i make sure that both the ethernet cards are running in half or full duplex mode, how do i check if weathere an ethernet is in half or full duplex mode Thanks in advance Vishal Gandhi - Original Message - From: "ulrich schwarz" <[EMAIL PROTECTED]> To: "Vishal Gandhi Kommineni" <[EMAIL PROTECTED]> Cc: "LARTC" <[EMAIL PROTECTED]> Sent: Thursday, January 02, 2003 2:34 PM Subject: Re: [LARTC] speed problem > Vishal Gandhi Kommineni wrote: > > Hi all, > > I have a pecular problem > > > > i have a setup of 3 linux boxes and a windows pc > > > > boxes A, B, C and a pc are connected in the follwoing sequence > > > > > > A (eth0)< > (eth0) B (eth1)< -> (eth0) C (eth1) <--> PC > > > > > > 1) using ftp I am able to transfer data from B to A both ways, the > > speeds are around 1.2e > > 2) I am also able to transfer similarly to and fro from B to PC via box C > > > > but > > > > 3) when i am trying to ftp data from A to PC via B and C to and fro the > > data transfer speed has drastically come down, > > Please note that in both B and C ipforward is enabled. > > > > Kindly help > > > > Thanks in advance, > > > > Vishal Gandhi > > > hi vishal, > > the first thing i'd like to check is if the ethernet cards are running > in full- or half-duplex mode. AFAIK running one card in half-duplex mode > and the other trying to force full-duplex mode can lead to lots of > collisions, so this could be a reason for slow speed. > > you could use a hub or switch instead of the crossover cable and watch > the collision LED (if there is any *g*). > > greetings, > > ulric > > -- > ulrich schwarz, computing center, university of ulm, germany > > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] speed problem
Vishal Gandhi Kommineni wrote: Hi all, I have a pecular problem i have a setup of 3 linux boxes and a windows pc boxes A, B, C and a pc are connected in the follwoing sequence A (eth0)< > (eth0) B (eth1)< -> (eth0) C (eth1) <--> PC 1) using ftp I am able to transfer data from B to A both ways, the speeds are around 1.2e 2) I am also able to transfer similarly to and fro from B to PC via box C but 3) when i am trying to ftp data from A to PC via B and C to and fro the data transfer speed has drastically come down, Please note that in both B and C ipforward is enabled. Kindly help Thanks in advance, Vishal Gandhi hi vishal, the first thing i'd like to check is if the ethernet cards are running in full- or half-duplex mode. AFAIK running one card in half-duplex mode and the other trying to force full-duplex mode can lead to lots of collisions, so this could be a reason for slow speed. you could use a hub or switch instead of the crossover cable and watch the collision LED (if there is any *g*). greetings, ulric -- ulrich schwarz, computing center, university of ulm, germany ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] speed problem
Hi all, I have a pecular problem i have a setup of 3 linux boxes and a windows pc boxes A, B, C and a pc are connected in the follwoing sequence A (eth0)< > (eth0) B (eth1)< -> (eth0) C (eth1) <--> PC 1) using ftp I am able to transfer data from B to A both ways, the speeds are around 1.2e 2) I am also able to transfer similarly to and fro from B to PC via box C but 3) when i am trying to ftp data from A to PC via B and C to and fro the data transfer speed has drastically come down, Please note that in both B and C ipforward is enabled. Kindly help Thanks in advance, Vishal Gandhi
