RE: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs
Hi, The machine has two ethernet interfaces: eth0 and eth1. My LAN is connected to eth0. The eth1 port is connected to a hub with two Internet routers. eth1 has two IP addresses, one for each router. Dynamic routing (or some other complex routing mechanism) is used. NAT is not used. It is not possible to change the hardware. I want to configure traffic shaping. But it is not supported to attach a qdisc to a virtual interface (or in other words to attach a separate qdisc to each one of the two external Ips that are defined on the WAN NIC). So far this seems to be impossible. Thanks for your help, Aron -Original Message- From: Martin A. Brown [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 4:34 AM To: Aron Brand Cc: [EMAIL PROTECTED] Subject: RE: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs Aron, I do not understand your network. In a prior note, I thought I understood that you had multiple serial (T1) interfaces. If you have multiple interfaces, then your statement about having one physical WAN interface is misleading. You may have only one T1 card (physical device), with several logical interfaces (for example, wan0, wan1 ...), which is not an uncommon configuration. Anyway, I don't understand your network, so cannot help. Please give ip addr and a small ASCII netmap. : The scenario I am working on is the second one - there is one internal : network and two ISPs. Then you have two WAN interfaces? : How can I do fwmark based on the outgoing interface? iptables -t mangle -A POSTROUTING -o wan0 -j MARK --set-mark $wan0_mark iptables -t mangle -A POSTROUTING -o wan1 -j MARK --set-mark $wan1_mark : Remember that there is just one physical WAN interface, with two IP : addresses. Is it possible to fwmark somehow based on the routing : decision? I'm not sure. Maybe somebody else can pick up that question. It's certainly possible to use -j ROUTE based on the fwmark, though [0]. I don't really think that will be required in your situation, but I won't know until I understand your network better. Best of luck, -Martin [0] http://netfilter.gnumonks.org/documentation/pomlist/pom-extra.html#ROUTE -- 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] RE: LARTC digest, Vol 1 #1564 - 6 msgs
Hi Martin,
The scenario I am working on is the second one - there is one internal
network and two ISPs.
How can I do fwmark based on the outgoing interface? Remember that there
is just one physical WAN interface, with two IP addresses. Is it
possible to fwmark somehow based on the routing decision?
Thanks
Aron
-Original Message-
From: Martin A. Brown [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 12:00 AM
To: Aron Brand
Cc: [EMAIL PROTECTED]
Subject: Re: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs
Aron,
: If I understand whay you are suggesting, there is a problem in your
: design: It will only work if you use Hide NAT.
...and multiple public IPs.
: The problem is that the ip_src == IP0 rule is wrong: The ip_src is
not
: changed by the router and it is not equal to the IP of any of the
: machine interfaces.
OK--maybe the 'ip_src == IP0' rule is not applicable to your situation,
but that doesn't make it wrong. You describe a different network
configuration than I was envisioning based on Gordan's description.
: Can you think of a solution that will work in the following
reasonable
: scenario:
I can try!
: Lets say I have two T1 internet connections connected to one ethernet
: interface. I do not use Hide-NAT. I want to guarantee at least
512kbps
: to HTTP traffic on each line (separately) in the 'virtual circuit'
: method that you mentioned.
Are you pushing different networks across each T1? If you have
Network-A from ISP-A and Network-B from ISP-B, then you have different
addresses to use in your configuration.
See an untested configuration with some fabricated addresses and
netmasks below.
#define NETA 216.109.118.64
#define NETAMASK 28
#define NETB 63.209.4.192
#define NETBMASK 27
dev eth0 {
egress {
class ( $neta ) if ip_src:NETAMASK == NETA/NETAMASK ;
class ( $netb ) if ip_src:NETBMASK == NETB/NETBMASK ;
htb () {
$neta = class ( rate 512kbps, ceil 512kbps ) ;
$netb = class ( rate 512kbps, ceil 512kbps ) ;
}
}
}
I would think this should provide a skeleton configuration for limiting
outbound (transmitted) traffic originating from separate IP networks on
the same host.
: I see no way do do this unless I can attach a qdisc to a specific
: virtual interface.
If you are using a single IP network and you have two different
providers (you're using BGP or similar), then you could consider marking
the packets
(fwmark) based on outgoing interface, and perform traffic control based
on this mechanism.
These are just some thoughts based on how I interpret your description
of your network.
Good luck,
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs
Martin,
If I understand whay you are suggesting, there is a problem in your
design: It will only work if you use Hide NAT. The problem is that the
ip_src == IP0 rule is wrong: The ip_src is not changed by the router and
it is not equal to the IP of any of the machine interfaces.
Can you think of a solution that will work in the following reasonabl
scenario:
Lets say I have two T1 internet connections connected to one ethernet
interface. I do not use Hide-NAT.
I want to guarantee at least 512kbps to HTTP traffic on each line
(seperately) in the 'virtual circuit' method that you mentioned.
I see no way do do this unless I can attach a qdisc to a specific
virtual interface.
Aron
Message: 3
Date: Wed, 28 Jan 2004 00:54:39 -0600 (CST)
From: Martin A. Brown [EMAIL PROTECTED]
To: Gordan Bobic [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [LARTC] Shaping Device Aliases
Gordan,
I've noticed that you are trying to use aliased IP addresses and
traffic control together, and you are a bit frustrated that tc doesn't
handle aliased interface names.
: I understand that device aliases (e.g. eth2:3) are not
shapeable.
: Does anybody know if this functionality is planned in the
future?
:
: None of the new(er) networking tools recognise device aliases,
: because on all recent linux releases, aliases don't exist.
: the ethX:X notation is a legacy notation used only by the
ifconfig
: program. everything else just sees a ethX with more than one IP
: address.
:
: So you just run your shaping rules on the real interfaces, and
: restrict it's operation with IP address filtering.
:
: Yes, I am aware of that. However, that makes shaping multiple
: independent streams going through one interface much more
difficult.
I don't understand why this becomes much more difficult--it just
becomes a little more difficult, depending on the number of IP
addresses you have active on a given interface. If you can handle
multiple addresses on an interface, then shaping traffic on these
(known) addresses shouldn't be much more difficult than managing each
address.
: The only other thing I can think of is setting up a dummy network
: device and giving it the IP addresses on all the non-primary
subnets
: (e.g. multiple DSL lines), and setting up the arp and routing to
make
: the packet actually go via the primary interface.
This sounds like a very confused idea. I'm not sure it's worth the
hassle--as I hope I can convince you below.
[ more stuff snipped ]
: Has anybody got any thoughts on this?
I have some thoughts, which I hope can help you understand why you
will be able to use the traffic control tools to accomplish your
filtering. For posterity, I'll reiterate some of what has come
before.
IP aliases don't exist. This is a convention for ifconfig. ip addr
show will display all IP addresses active on a given interface.
Traffic control is the last thing performed before turning the packet
over to the device driver and hardware. Similarly, it is the first
thing called on receipt of a packet. See diagrams KPTD [0] and
ebtables packet flow [1].
In this case, you can use any number of techniques to identify the
packets with tc tools based on their IP addresses--the convenience of
the aliased interface naming is simply an obstruction of the real path
the packet takes.
: If this would work, maybe it should be documented in the advanced
: routing howto, as I can see how there might be a lot of people out
: there who would find it useful.
Let me suggest a possibility, if we assume a nested configuration.
Let's say you have IP0 and IP1 active on interface eth3 and you want
to make sure that bandwidth is split 75/25 between these two and you
want them to share bandwidth. Classic bandwidth-sharing
situationin the tcng config below, you'd need to #define IP0 and
IP1, but then you'd have a simple configuration. If you needed to
further subdivide traffic within each of the IP0 and IP1 classes,
you'd have an easy way to do so.
dev eth0 {
egress {
class ( $ip0 ) if ip_src == IP0 ;
class ( $ip1 ) if ip_src == IP1 ;
htb () {
class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed
*/
$ip0 = class ( rate 1024kbps, ceil 1544kbps ) ;
$ip1 = class ( rate 384kbps, ceil 1544kbps ) ;
}
}
}
}
Alternately, you may wish to simulate virtual circuits with each of
the IP addresses on a machine. In this case, you could use separate
root classes attached to the HTB qdisc, or another class. You can
prevent the two classes from competing with each other by setting the
rate and ceil to the same value. Here's a very simple permutation of
the above.
dev eth0 {
egress {
class ( $ip0 ) if ip_src == IP0 ;
class ( $ip1
[LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
Hi Roy, Strange. kernel will resend then together with new ones - this is interesting, since the firewall DOES know how to drop locally generated packets and the kernel doesn't attempt to retry them. I am not an expert on this, but I think it might be interesting to check how the firewall does this. Another option would be to trick the kernel that the packet has been transmitted, to prevent the immediate retries, while actually vanishing the packet. Aron --__--__-- Message: 8 From: Roy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [LARTC] NEW imq driver Date: Tue, 27 Jan 2004 06:42:29 +0200 Seems I was to fast to declare success, my version is not much more stable than the original one,everything depends on dropped packets. This is even not imq fault afterall, can be prowed in other way also: atempts to police outgoing trafic it will be ok until you dont touch localy generated packets if you try to drop them you will be sorry, because kernel will resend then together with new ones of cource policer will drop them too, but linux kernel keeps resending then thus increasing rate progresively. I noticed that with my trafic counter. internal trafic grew to enormous levels 10X more than it can be. In reality there was almost no output at all. so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on 100mb/s it probably can kill computer (not tested). Seems imq have similar problem even if driver itself have no leaks kernel consumes all resousces on resnending droped packets so that computer stops responding for now I dont have good idea how to fix it so I will try to avoid localy generated trafic so it will me possible to shape ingress and forward, egress will be left for real device. maybe later I will find how fix that It seems to capture ingress and egress traffic of all interfaces; wouldn't this count packets twice ? No, ingress is for local and egress for everything so everything should be ok (in theory) If the machine is doing SNAT or DNAT, what IP addresses would be seen by the qdisc ? I made driver see the final destination address because it is more usefull Rubens ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs
I agree, but this is still better than crashing the machine... Aron -Original Message- From: Michael Renzmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 27, 2004 1:33 PM To: Aron Brand Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Hi. Aron Brand wrote: does this. Another option would be to trick the kernel that the packet has been transmitted, to prevent the immediate retries, while actually vanishing the packet. I'm also no pro in this area, but I think this would be a bad idea. I guess this would have impact on the interface's statistics about sent, received and dropped packets, making it hard to look for network configuration errors and similar things. Bye, Mike ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] IMQ Stability
Hi Roy, This is great news! Shaping in+out at once is not always wanted... Usually you want to shape them seperately because each direction has a different bandwidth and limits. So I think it should be optional (i.e. you should be able to configure if you want the ingress and/or the egress side). Your efforts are highly appreciated! Aron --- From: Roy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [LARTC] IMQ Stability Date: Sun, 25 Jan 2004 05:49:15 +0200 Internet (eth0) - ppp0 - ppp1 - LAN (eth1) 10.0.0.0/8 this way dont seem excelent because it still lacks some functionality and what about using LO or dummy type interface instead of ppp? the new imq driver that i am developing will have unlimited posibilities it willbe fake interface wich passes all ip trafic without exception no mater which direction, destination and so on even localy generated and received trafic should pass it I removed iptables module so noo need to configure it just everything is catched. so you will be able to shape in + out in one also I am thinking about the chaining functionality is there any need to make chain of imq devices ? ( they will get the all same trafic) you will be able to use few shapers then but it will add latency. I almost finished my driver , but unfortunately there is no way to avoid patching kernel. I need to export ip_finish_output2 and ip_local_deliver_finish functions but dont know how to do that, and where is the best place. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Ingress Shaping using IMQ
Hi Stef, Thanks for the helpful information. What do I need to set as the line rate for the LAN side shaper? I assume that if I want it to work it must be slower than the real downlink speed - is this right? Are there recommended values - such as 10% lower than the real downlink speed? I am wondering, has anyone done any benchmarks that indicate how accurate is shaping of TCP streams in the inbound direction? For example, say that during peak periods the customer wants to enforce 20% of the traffic to web and 80% to FTP downloads, how long will it take until it stabilizes on these rates? And how accurate can I expect it to be? Thanks, Aron -Original Message- From: Stef Coene [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 8:28 PM To: Aron Brand; [EMAIL PROTECTED] Subject: Re: [LARTC] Ingress Shaping using IMQ On Monday 19 January 2004 14:19, Aron Brand wrote: Hi Guys, Here is a question that is probably of concern to many of us. I am under pressure to provide some solution for ingress traffic shaping. What my customer demands is to divide the downstream (ingress) of an ADSL lines to two classes of traffic - important traffic and non important downloads. He has a very reasonable requirement: he wants a guarantee of at least 1000kbps at all times for the important traffic on the downstream. Using ingress policing would be the trivial solution. But no says the customer - when the important traffic is not fully utilizing its rate, I want it to share the excess with other classes. After looking around, the answer I found was to use imq, which claims to allow traffic shaping on ingress traffic. So far so good. And now I arrive to the question: It is possible to configure everything in THEORY. The question is, it it really possible for me to give the guarantee that my customer is asking for? I can think of examples why it seems that the answer is no. For example, lets say the ingress line is completely saturated with non-important traffic. How on earth can the poor HTB determine whether important traffic is being drowned out - or there is simply no important traffic? It can, but it will take some time before the non-important traffic will slow down. My speculation so far - it is possible to configure these rules, and indeed this is what IMQ was invented for, but in true life there is no solution that works - since it is inherently impossible! It's impossible because you can never control what people send to you. Tcp will throttle down if there is less bandwidth, but this can take some time. So you can only hope the other side will stop sending packets if you drop packets (I try the same with spam but it'snot woring :( ) Has anyone really created and tested a working ingress traffic shaping solution? You don't need imq for this. If you put a router (or bridge) between the ADSL and the LAN, you can shape on both interfaces. So the LAN interface can be used to shape incoming traffic. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Ingress Shaping using IMQ
Title: Ingress Shaping using IMQ Hi Guys, Here is a question that is probably of concern to many of us. I am under pressure to provide some solution for ingress traffic shaping. What my customer demands is to divide the downstream (ingress) of an ADSL lines to two classes of traffic - important traffic and non important downloads. He has a very reasonable requirement: he wants a guarantee of at least 1000kbps at all times for the important traffic on the downstream. Using ingress policing would be the trivial solution. But no says the customer - when the important traffic is not fully utilizing its rate, I want it to share the excess with other classes. After looking around, the answer I found was to use imq, which claims to allow traffic shaping on ingress traffic. So far so good. And now I arrive to the question: It is possible to configure everything in THEORY. The question is, it it really possible for me to give the guarantee that my customer is asking for? I can think of examples why it seems that the answer is no. For example, lets say the ingress line is completely saturated with non-important traffic. How on earth can the poor HTB determine whether important traffic is being drowned out - or there is simply no important traffic? My speculation so far - it is possible to configure these rules, and indeed this is what IMQ was invented for, but in true life there is no solution that works - since it is inherently impossible! Has anyone really created and tested a working ingress traffic shaping solution? Aron
[LARTC] RE: LARTC digest, Vol 1 #1523 - 17 msgs
Hi Roy, It seems that I wasn't clear. Lets give an example. I have a machine with a single ethernet interface, with two IP addresses A and B. This is done using two virtual interfaces. A is my IP address in ISP-A. B is my IP address in ISP-B. The physical line to ISP-A is 1.5Mbps. The physical line to ISP-B is 256kbps. I want to shape the traffic so that, for example, HTTP traffic will take no more than 10% of the ISP-B link, and no more than 20% of the ISP-A link. There seems to be no way to do this without the ability to attach a qdisc to a virtual interface. Please correct me if I am wrong... Aron --- From: Roy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [LARTC] virtual interface Date: Mon, 5 Jan 2004 16:29:40 +0200 There is no need to use imq ant everything is easy to do anyway interface name is usefull only to attach qdisc to something and that all you need to clasify packets by source or destination ip antway if you have idea how to use imq there then just use your interface instead. also why it is so obvious that they must be shaped separately, ususly it is much better to shape everything in one einterface Hi guys, I have this problem too. I have two Internet routers connected to the same Ethernet interface (using a hub). And each one obviously needs to be shaped seperately. It seems like a very common and logical scenario and this issue seems like a design problem. Any Ideas on a workaround? Perhaps IMQ can be used somehow (although I hear it has serious stability problems...)? Aron ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] virtual interface
Alen, : can i add HTB rule on virtual interface? : example: eth0:0 First, it's not really a virtual interface--it's just a convention from the old days of IP aliasing to have names like eth0:0. The IP exists and is active on an interface, eth0 in your case. The short answer is no. Traffic control occurs just prior to the release of the packet for transmission by the hardware driver. See the KPTD [0]. You can however select packets based on many characteristics, so you may be able to accomplish what you need. You'll use characteristics other than the label eth0:0. Hi guys, I have this problem too. I have two Internet routers connected to the same Ethernet interface (using a hub). And each one obviously needs to be shaped seperately. It seems like a very common and logical scenario and this issue seems like a design problem. Any Ideas on a workaround? Perhaps IMQ can be used somehow (although I hear it has serious stability problems...)? Aron ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Controlling only delay using HTB without stealing excess bandwidth
Hi Gurus, The documentation isn't terribly clear, but it seems that the HTB 'prio' field has two separate functions: 1. Classes with lower prio get all the excess bandwidth first. 2. Classes with lower prio get lower delay. I want just #2 - and not #1 In other words, for example lets say that I have a 100kbps link, divided to classes A and B as following. A - rate=20kbps limit=100kbps B - rate=20kbps limit=100kbps How can I get class B to have a lower delay than A, while still sharing the excess bandwidth fairly with A? Thanks, Aron Brand ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
