Hi,
i need to dynamically change the destination IP address
of UDP packets for an ongoing UDP flow. That means
when the flow starts for the first time no change
is needed and after some time a change of the destination
IP address must be done to redirect the packets to another
machine
On Sat, 2005-12-03 at 07:04 +0100, Andreas Klauer wrote:
On Friday 02 December 2005 23:24, Brian J. Murrell wrote:
Yeah, that is what I want, but why do I need HTB?
You need it only if you also want to limit bandwidth somehow.
But surely HTB is overkill for simply limiting bandwidth and
OK, reading back through the thread at Brian's previous comment: As I wrote before I'm not interested in dividing bandwidth up, just prioritizing the use of the full bandwidth by all-comers.And then being confused by this one:On Dec 4, 2005, at 8:48 AM, Brian J. Murrell wrote:On Sat, 2005-12-03 at
I thought I had this all worked out, but it seems not. The following tc
configuration:
tc qdisc del dev ppp0 root 2 /dev/null /dev/null
tc qdisc add dev ppp0 root handle 1: tbf rate 120kbit burst 1200 limit 1
tc qdisc add dev ppp0 parent 1:1 handle 2: prio bands 3
tc qdisc add dev ppp0 parent
On Sunday 04 December 2005 17:36, Brian J. Murrell wrote:
Even if they end up in 2:3, they should at least be treated fairly.
2:3 will not be treated at all as long as 2:1 and 2:2 (which have higher
priority) are occupied. If the queues in 2:1 and 2:2 resp. never empty,
the packets in 2:3 will
On Sun, 2005-12-04 at 10:14 -0500, Jeffrey B. Ferland wrote:
To prioritize, you must classify. HTB allows prioritization and
classification... and limitation as well.
Seems the combination of TBF and PRIO does too.
Attaching something like this: Root -- TBF -- Prio would be nice,
but I
On Sun, 2005-12-04 at 17:54 +0100, Andreas Klauer wrote:
On Sunday 04 December 2005 17:36, Brian J. Murrell wrote:
Even if they end up in 2:3, they should at least be treated fairly.
2:3 will not be treated at all as long as 2:1 and 2:2 (which have higher
priority) are occupied.
Right. I
Brian J. Murrell wrote:
I thought I had this all worked out, but it seems not. The following tc
configuration:
tc qdisc del dev ppp0 root 2 /dev/null /dev/null
tc qdisc add dev ppp0 root handle 1: tbf rate 120kbit burst 1200 limit 1
But it seems that some outbound flows are being blocked
On Sunday 04 December 2005 19:17, Brian J. Murrell wrote:
There is no fair treatment in PRIO.
No, it's priority based. Got that. Exactly what I am looking for in
fact.
Sorry, seems that I misunderstood you in your message in the point that you
meant SFQ and not PRIO when you were talking
I'm trying to shape each machine on an interface to 256k each, but I'm
getting stuck and only able to shape an entire interface to 256k. What
should I be doing differently here?
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1:
Dnia niedziela, 4 grudnia 2005 23:11, Dave Weis napisał(a):
I'm trying to shape each machine on an interface to 256k each, but I'm
getting stuck and only able to shape an entire interface to 256k. What
should I be doing differently here?
tc qdisc del dev eth0 root
tc qdisc add dev eth0
On Sunday 04 December 2005 23:11, Dave Weis wrote:
What should I be doing differently here?
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 100MBit ceil
100MBit
tc qdisc add dev eth0 parent 1:10 handle
On Sun, 2005-12-04 at 19:46 +0100, Patrick McHardy wrote:
Your burst is too small. It needs to be at least one MTU.
Bingo! I guess it's obvious that I don't really understand how burst
works. :-) But setting it to 1600 seems to have solved the problem.
Thanx!
b.
--
My other computer is
On Thu, Dec 01, 2005 at 06:45:42PM +0100, Andreas Unterkircher wrote:
Good suggestion to use ulog for this. So I could dump the exactly
traffic which would run through a class (CLASSIFY)
to analyze and extract the necessary data to draw the graphs. So I do
not have to parse my class (IP or
Hello.
I wonder how just correct couple of spdadd commands like
spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec
esp/tunnel/10.1.0.1-10.2.0.1/require;
spdadd 192.168.2.0/24 192.168.1.0/24 any -P in ipsec
esp/tunnel/10.2.0.1-10.1.0.1/require;
makes _routing_ of packets from 192.168.1/24
Alexander Kotelnikov schrieb:
Ok, I would not ask all this if I have no problem with
tunnelling. With configuration like described above, where multihomed
maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1,
10.2.0.1) tunneling works for all machines, but these two
routers. This
On Monday 05 December 2005 00:52, Brian J. Murrell wrote:
Well, things seem to be going really well with tbf, prio and sfq. But
I'm a nosey bugger. :-) I'd love to be able to audit what's going
through each of the prio bands.
The super ideal solution would be to be able to attach tcpdump
17 matches
Mail list logo
