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 situation....in 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> ) if ip_src == IP1 ;
htb () {
class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */
$ip0 = class ( rate 1024kbps, ceil 1024kbps ) ;
$ip1 = class ( rate 384kbps, ceil 384kbps ) ;
}
}
}
}
Best of luck, Gordan!
-Martin
[0] http://www.docum.org/stef.coene/qos/kptd/
[1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
