Re: ipfw dummynet - adsl link(s) simulieren

> > Irgendwie reicht mir das nicht ;-)
> >
> > Ich habe jetzt nochmals etwas weiter "gegraben".
> >
> > So, wie meine Regeln z.Zt. sind bekommt jeder ADSL-Link seine eigene
> > Queue (Grund: config mask all).
> > Wenn ich nun 'config mask dst-ip 0xffffff00' bzw. 'config mask src-ip
> > 0xffffff00' verwende, bekommt jeder ADSL-Link seine eigene Queue.
> > Richtig?
>
> Ah, sorry, so genau hatte ich nicht hingeschaut.
>
> Der Punkt ist, dass Du so maskieren musste, dass die
> dynamisch generierten Pipes genau die Hardware abbilden,
> die Du simulieren möchtest. Da jeder Client-Rechner
> einen ADSL-Link hat, brauchst Du also eine Dummynet-Pipe
> pro Client.
>
> Nun maskiert aber "mask all" nicht nur nach den Adressen
> der Clients, sondern auch nach den Adressen der Gegen-
> stellen und nach den Ports. Du bekommst also pro Ver-
> bindung eine dynamische Pipe, nicht pro Client.
>
> Daher musst Du stattdessen "mask src-ip 0xffffffff" bzw.
> "mask dst-ip 0xffffffff" verwenden (für Output von den
> Clients bzw. Input zu den Clients). Dann bekommt jeder
> Client eine dynamische Pipe, also einen eigenen ADSL-
> Link.
>
>

Dann habe ich es jetzt richtig.

> > > > Die ipfw manpage sagt:
> > > >
> > > > In practice, pipes can be used to set hard limits to the bandwidth
> > > > that a flow can use, whereas queues can be used to determine how
> > > > different flow share the available bandwidth.
> > >
> > > Richtig, das sagt sie, unter anderem.
> >
> > Das würde doch bedeuten, dass ich für das Begrenzen des Links für alle
> > ADSL-Links am Schluss eine Queue verwenden sollte?
>
> Nein, ich dachte, dass die 100 Mbit ein "hard limit"
> darstellen sollen, oder habe ich Dich missverstanden?
>

Ja genau.
Ich möchte im Prinzip, dass alle ADSL-Links zum Schluss nochmal durch
eine Pipe/Queue müssen, die die gesamte Bandbreite begrenzt.

Danke für die weiteren Erläuterungen!

Gruß
Sebastian

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 07 May 2009 - 11:49:04 CEST