* Re: [LARTC] Shaping Device Aliases
2004-01-15 11:18 [LARTC] Shaping Device Aliases Gordan Bobic
2004-01-16 6:23 ` Damion de Soto
@ 2004-01-16 11:17 ` Gordan Bobic
2004-01-28 6:54 ` Martin A. Brown
2 siblings, 0 replies; 4+ messages in thread
From: Gordan Bobic @ 2004-01-16 11:17 UTC (permalink / raw)
To: lartc
On Friday 16 Jan 2004 06:23, Damion de Soto wrote:
> Gordan Bobic wrote:
> > 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.
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.
However, therein lies another problem - it means that the primary (real)
interface (with the first subnet) could then not be shaped properly (I
THINK), because shaping it would shape the overall traffic on that
interface, and not only the traffic on the primary connection.
So, the solution might be to set up the real interface with a dummy IP
address, and assigning all valid, real subnets to the dummy interfaces,
and set up the routes for those subnets to go via the real interface,
and set up arp to make sure things go via the real interface.
Has anybody got any thoughts on this?
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.
Regards.
Gordan
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] Shaping Device Aliases
2004-01-15 11:18 [LARTC] Shaping Device Aliases Gordan Bobic
2004-01-16 6:23 ` Damion de Soto
2004-01-16 11:17 ` Gordan Bobic
@ 2004-01-28 6:54 ` Martin A. Brown
2 siblings, 0 replies; 4+ messages in thread
From: Martin A. Brown @ 2004-01-28 6:54 UTC (permalink / raw)
To: lartc
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@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread