Using tc to delay packets to only a single IP addressNetwork shaping using `tc netem` doesn't seem to workUsing tc to delay packets to all IP address except for a single IP addressSharing Bandwidth and Prioritizing Realtime Traffic via HTB, Which Scenario Works Better?how to prevent Packet loss due to high delay?TC hashing filters - single rule deletionHow to add delay to incoming traffic?tc filter replace, tc filter change doesn't workiptables & tc limit both upload & download togetherIs there a way to limit bandwidth per ip using HTB + a CIDR range in Linux?Block incoming traffic in bonding mode when primary interface is downWhen add filter in tc have a “RTNETLINK answers: Invalid argument, We have an error talking to the kernel” errortc prio how the packets are prioritized
Has a commercial or military jet bi-plane ever been manufactured?
Can hackers enable the camera after the user disabled it?
Getting a W on your transcript for grad school applications
Using column size much larger than necessary
Why do we use hermite interpolation for finite element method in beams?
What does this colon mean? It is not labeling, it is not ternary operator
Why do money exchangers give different rates to different bills?
Can there be a single technologically advanced nation, in a continent full of non-technologically advanced nations?
What property of a BJT transistor makes it an amplifier?
Pressure inside an infinite ocean?
String won't reverse using reverse_copy
Why is [person X] visibly scared in the library in Game of Thrones S8E3?
Should I replace my bicycle tires if they have not been inflated in multiple years
Using a microphone from the 1930s
On which topic did Indiana Jones write his doctoral thesis?
Where can I go to avoid planes overhead?
How can I support myself financially as a 17 year old with a loan?
Why wasn't the Night King naked in S08E03?
Expressing 'our' for objects belonging to our apartment
What was the first instance of a "planet eater" in sci-fi?
Would Hubble Space Telescope improve black hole image observed by EHT if it joined array of telesopes?
What does a spell range of "25 ft. + 5 ft./2 levels" mean?
Does a card have a keyword if it has the same effect as said keyword?
What are the advantages of luxury car brands like Acura/Lexus over their sibling non-luxury brands Honda/Toyota?
Using tc to delay packets to only a single IP address
Network shaping using `tc netem` doesn't seem to workUsing tc to delay packets to all IP address except for a single IP addressSharing Bandwidth and Prioritizing Realtime Traffic via HTB, Which Scenario Works Better?how to prevent Packet loss due to high delay?TC hashing filters - single rule deletionHow to add delay to incoming traffic?tc filter replace, tc filter change doesn't workiptables & tc limit both upload & download togetherIs there a way to limit bandwidth per ip using HTB + a CIDR range in Linux?Block incoming traffic in bonding mode when primary interface is downWhen add filter in tc have a “RTNETLINK answers: Invalid argument, We have an error talking to the kernel” errortc prio how the packets are prioritized
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I am new to using tc and netem. I want to delay packets being sent to a specific IP address. However, the commands below cause all packets on the system to be delayed, instead of just to the IP address 1.2.3.4:
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
tc filter add dev eth0 parent 1:0 protocol ip pref 55 handle ::55 u32 match ip dst 1.2.3.4 flowid 2:1
My guess is that I need some kind of catch-all filter at the end to specify that all remaining traffic should not go through netem. But I can't get anything to work. How would I get this to work?
linux traffic-shaping tc
add a comment |
I am new to using tc and netem. I want to delay packets being sent to a specific IP address. However, the commands below cause all packets on the system to be delayed, instead of just to the IP address 1.2.3.4:
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
tc filter add dev eth0 parent 1:0 protocol ip pref 55 handle ::55 u32 match ip dst 1.2.3.4 flowid 2:1
My guess is that I need some kind of catch-all filter at the end to specify that all remaining traffic should not go through netem. But I can't get anything to work. How would I get this to work?
linux traffic-shaping tc
add a comment |
I am new to using tc and netem. I want to delay packets being sent to a specific IP address. However, the commands below cause all packets on the system to be delayed, instead of just to the IP address 1.2.3.4:
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
tc filter add dev eth0 parent 1:0 protocol ip pref 55 handle ::55 u32 match ip dst 1.2.3.4 flowid 2:1
My guess is that I need some kind of catch-all filter at the end to specify that all remaining traffic should not go through netem. But I can't get anything to work. How would I get this to work?
linux traffic-shaping tc
I am new to using tc and netem. I want to delay packets being sent to a specific IP address. However, the commands below cause all packets on the system to be delayed, instead of just to the IP address 1.2.3.4:
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
tc filter add dev eth0 parent 1:0 protocol ip pref 55 handle ::55 u32 match ip dst 1.2.3.4 flowid 2:1
My guess is that I need some kind of catch-all filter at the end to specify that all remaining traffic should not go through netem. But I can't get anything to work. How would I get this to work?
linux traffic-shaping tc
linux traffic-shaping tc
asked May 15 '12 at 15:38
Matt WhiteMatt White
4471415
4471415
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
Ok, I solved my own problem. It turns out that if you execute the first 3 lines above (the "tc qdisc" ones), it will delay all packets because there are no filters yet. The 4th line changes it to only delay packets from that single IP address. Additional filter lines can be added to add additional IP addresses to the "delayed" list. So: don't create a "netem delay" line without a filter pointing to it.
Thankyou for coming back and posting the answer. Oddly I found that it worked just fine both ways, but anyway. I wrote a wrapper script around those three commands to help with testing, just thought i'd give back a little :)
– Arran Cudbard-Bell
Sep 17 '13 at 18:04
add a comment |
The chosen answer is incorrect/incomplete. I faced a similar issue, the chosen answer gave some help, but not enough.
First, the following command is not really needed.
tc qdisc del dev eth0 root
It will 'delete' the root qdisc, but inmediately gets substituted by a pfifo_fast one (so you don't lose connectivity).
The second command:
tc qdisc add dev eth0 root handle 1: prio
Will substitute the pfifo_fast qdisc with the prio one. By default, the prio queue has 3 bands (0, 1, 2) each managed by one class (1:1, 1:2 and 1:3).
The packets will be sent to one of those bands using the TOS field of the IP package. This configuration is shown when you execute:
tc qdisc ls
looking at the 'priomap' values.
Then, you add a netem qdisc:
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
With this command you delay all traffic going to the 1:1 band (until the filter is in place).
But there are two caveats:
- Your traffic can have a different TOS value and then being sent to another band.
- The prio qdisc can be configured so the traffic goes to another band.
The following solved my issue to not be affected by the netem while the filter is not applied. Instead of the above steps, I did:
tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
This will send all traffic by default to the band 1:3.
Then, I added the rule to delay traffic:
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 100ms 10ms
This creates the qdisc in the band 0, but since all traffic goes to band 3, it didn't affect me.
Afterwards, I added the filter:
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.1/32 match ip dport 80 0xffff flowid 1:1
Now with the filter, only the chosen IP/port will be affected, since we redirect the chosen traffic to the band 0.
All the other traffic continues unaffected since it continues to flow to band 3.
what is the "ip dst 10.0.0.1/32" ? Is that the destination ip? does that mean there is a "ip src xxx.yyy.zz.www/aa" ?
– Zach Folwick
May 20 '17 at 3:36
Yes, it is the destination IP in my example. And yes, there is an 'ip src' option.
– Telegrapher
May 23 '17 at 9:35
The reason for the first command (tc qdisc del) is to clear out any previous state - like you might have if you are experimenting trying to make this work. FWIW the accepted answer Worked For Me.
– Dan Pritts
Aug 2 '17 at 2:09
add a comment |
Simple example from https://wiki.linuxfoundation.org/networking/netem that lets you delay packets to a given IP without affecting any other traffic, even during configuration:
tc qdisc del dev eth0 root # Ensure you start from a clean slate
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 500ms
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32
match ip dst 192.168.1.2 flowid 1:3
I must add a caveat, it later seemed like the delay applied more broadly that I expected and I could not get to the bottom of it. Not all traffic seemed delayed though.
– NeilenMarais
Jan 18 at 8:18
add a comment |
I haven't manage to delay traffic to one IP while keeping traffic normal to others IP normal with the method described in this thread.
However, I manage to do it using the following commands.
tc qdisc add dev eth0 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 0ms
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src `hostname -I` flowid 1:2
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 15001ms
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst 1.2.3.4 flowid 1:1
To delay 15001ms
traffic to IP 1.2.3.4
from the host where the command is executed. The command hostname -I
is used to get the main IP of the host but the value can be replaced directly inside the command.
I had to add another filter with 0ms
delay to match the traffic coming from the host. For sure it is not elegant but I haven't managed to have something nicer working.
The last command can be replaced to match a single port.
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 18583 0xffff flowid 1:1
To delay traffic to port 18583
instead of IP 1.2.3.4
.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f389290%2fusing-tc-to-delay-packets-to-only-a-single-ip-address%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Ok, I solved my own problem. It turns out that if you execute the first 3 lines above (the "tc qdisc" ones), it will delay all packets because there are no filters yet. The 4th line changes it to only delay packets from that single IP address. Additional filter lines can be added to add additional IP addresses to the "delayed" list. So: don't create a "netem delay" line without a filter pointing to it.
Thankyou for coming back and posting the answer. Oddly I found that it worked just fine both ways, but anyway. I wrote a wrapper script around those three commands to help with testing, just thought i'd give back a little :)
– Arran Cudbard-Bell
Sep 17 '13 at 18:04
add a comment |
Ok, I solved my own problem. It turns out that if you execute the first 3 lines above (the "tc qdisc" ones), it will delay all packets because there are no filters yet. The 4th line changes it to only delay packets from that single IP address. Additional filter lines can be added to add additional IP addresses to the "delayed" list. So: don't create a "netem delay" line without a filter pointing to it.
Thankyou for coming back and posting the answer. Oddly I found that it worked just fine both ways, but anyway. I wrote a wrapper script around those three commands to help with testing, just thought i'd give back a little :)
– Arran Cudbard-Bell
Sep 17 '13 at 18:04
add a comment |
Ok, I solved my own problem. It turns out that if you execute the first 3 lines above (the "tc qdisc" ones), it will delay all packets because there are no filters yet. The 4th line changes it to only delay packets from that single IP address. Additional filter lines can be added to add additional IP addresses to the "delayed" list. So: don't create a "netem delay" line without a filter pointing to it.
Ok, I solved my own problem. It turns out that if you execute the first 3 lines above (the "tc qdisc" ones), it will delay all packets because there are no filters yet. The 4th line changes it to only delay packets from that single IP address. Additional filter lines can be added to add additional IP addresses to the "delayed" list. So: don't create a "netem delay" line without a filter pointing to it.
answered May 22 '12 at 14:47
Matt WhiteMatt White
4471415
4471415
Thankyou for coming back and posting the answer. Oddly I found that it worked just fine both ways, but anyway. I wrote a wrapper script around those three commands to help with testing, just thought i'd give back a little :)
– Arran Cudbard-Bell
Sep 17 '13 at 18:04
add a comment |
Thankyou for coming back and posting the answer. Oddly I found that it worked just fine both ways, but anyway. I wrote a wrapper script around those three commands to help with testing, just thought i'd give back a little :)
– Arran Cudbard-Bell
Sep 17 '13 at 18:04
Thankyou for coming back and posting the answer. Oddly I found that it worked just fine both ways, but anyway. I wrote a wrapper script around those three commands to help with testing, just thought i'd give back a little :)
– Arran Cudbard-Bell
Sep 17 '13 at 18:04
Thankyou for coming back and posting the answer. Oddly I found that it worked just fine both ways, but anyway. I wrote a wrapper script around those three commands to help with testing, just thought i'd give back a little :)
– Arran Cudbard-Bell
Sep 17 '13 at 18:04
add a comment |
The chosen answer is incorrect/incomplete. I faced a similar issue, the chosen answer gave some help, but not enough.
First, the following command is not really needed.
tc qdisc del dev eth0 root
It will 'delete' the root qdisc, but inmediately gets substituted by a pfifo_fast one (so you don't lose connectivity).
The second command:
tc qdisc add dev eth0 root handle 1: prio
Will substitute the pfifo_fast qdisc with the prio one. By default, the prio queue has 3 bands (0, 1, 2) each managed by one class (1:1, 1:2 and 1:3).
The packets will be sent to one of those bands using the TOS field of the IP package. This configuration is shown when you execute:
tc qdisc ls
looking at the 'priomap' values.
Then, you add a netem qdisc:
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
With this command you delay all traffic going to the 1:1 band (until the filter is in place).
But there are two caveats:
- Your traffic can have a different TOS value and then being sent to another band.
- The prio qdisc can be configured so the traffic goes to another band.
The following solved my issue to not be affected by the netem while the filter is not applied. Instead of the above steps, I did:
tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
This will send all traffic by default to the band 1:3.
Then, I added the rule to delay traffic:
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 100ms 10ms
This creates the qdisc in the band 0, but since all traffic goes to band 3, it didn't affect me.
Afterwards, I added the filter:
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.1/32 match ip dport 80 0xffff flowid 1:1
Now with the filter, only the chosen IP/port will be affected, since we redirect the chosen traffic to the band 0.
All the other traffic continues unaffected since it continues to flow to band 3.
what is the "ip dst 10.0.0.1/32" ? Is that the destination ip? does that mean there is a "ip src xxx.yyy.zz.www/aa" ?
– Zach Folwick
May 20 '17 at 3:36
Yes, it is the destination IP in my example. And yes, there is an 'ip src' option.
– Telegrapher
May 23 '17 at 9:35
The reason for the first command (tc qdisc del) is to clear out any previous state - like you might have if you are experimenting trying to make this work. FWIW the accepted answer Worked For Me.
– Dan Pritts
Aug 2 '17 at 2:09
add a comment |
The chosen answer is incorrect/incomplete. I faced a similar issue, the chosen answer gave some help, but not enough.
First, the following command is not really needed.
tc qdisc del dev eth0 root
It will 'delete' the root qdisc, but inmediately gets substituted by a pfifo_fast one (so you don't lose connectivity).
The second command:
tc qdisc add dev eth0 root handle 1: prio
Will substitute the pfifo_fast qdisc with the prio one. By default, the prio queue has 3 bands (0, 1, 2) each managed by one class (1:1, 1:2 and 1:3).
The packets will be sent to one of those bands using the TOS field of the IP package. This configuration is shown when you execute:
tc qdisc ls
looking at the 'priomap' values.
Then, you add a netem qdisc:
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
With this command you delay all traffic going to the 1:1 band (until the filter is in place).
But there are two caveats:
- Your traffic can have a different TOS value and then being sent to another band.
- The prio qdisc can be configured so the traffic goes to another band.
The following solved my issue to not be affected by the netem while the filter is not applied. Instead of the above steps, I did:
tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
This will send all traffic by default to the band 1:3.
Then, I added the rule to delay traffic:
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 100ms 10ms
This creates the qdisc in the band 0, but since all traffic goes to band 3, it didn't affect me.
Afterwards, I added the filter:
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.1/32 match ip dport 80 0xffff flowid 1:1
Now with the filter, only the chosen IP/port will be affected, since we redirect the chosen traffic to the band 0.
All the other traffic continues unaffected since it continues to flow to band 3.
what is the "ip dst 10.0.0.1/32" ? Is that the destination ip? does that mean there is a "ip src xxx.yyy.zz.www/aa" ?
– Zach Folwick
May 20 '17 at 3:36
Yes, it is the destination IP in my example. And yes, there is an 'ip src' option.
– Telegrapher
May 23 '17 at 9:35
The reason for the first command (tc qdisc del) is to clear out any previous state - like you might have if you are experimenting trying to make this work. FWIW the accepted answer Worked For Me.
– Dan Pritts
Aug 2 '17 at 2:09
add a comment |
The chosen answer is incorrect/incomplete. I faced a similar issue, the chosen answer gave some help, but not enough.
First, the following command is not really needed.
tc qdisc del dev eth0 root
It will 'delete' the root qdisc, but inmediately gets substituted by a pfifo_fast one (so you don't lose connectivity).
The second command:
tc qdisc add dev eth0 root handle 1: prio
Will substitute the pfifo_fast qdisc with the prio one. By default, the prio queue has 3 bands (0, 1, 2) each managed by one class (1:1, 1:2 and 1:3).
The packets will be sent to one of those bands using the TOS field of the IP package. This configuration is shown when you execute:
tc qdisc ls
looking at the 'priomap' values.
Then, you add a netem qdisc:
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
With this command you delay all traffic going to the 1:1 band (until the filter is in place).
But there are two caveats:
- Your traffic can have a different TOS value and then being sent to another band.
- The prio qdisc can be configured so the traffic goes to another band.
The following solved my issue to not be affected by the netem while the filter is not applied. Instead of the above steps, I did:
tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
This will send all traffic by default to the band 1:3.
Then, I added the rule to delay traffic:
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 100ms 10ms
This creates the qdisc in the band 0, but since all traffic goes to band 3, it didn't affect me.
Afterwards, I added the filter:
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.1/32 match ip dport 80 0xffff flowid 1:1
Now with the filter, only the chosen IP/port will be affected, since we redirect the chosen traffic to the band 0.
All the other traffic continues unaffected since it continues to flow to band 3.
The chosen answer is incorrect/incomplete. I faced a similar issue, the chosen answer gave some help, but not enough.
First, the following command is not really needed.
tc qdisc del dev eth0 root
It will 'delete' the root qdisc, but inmediately gets substituted by a pfifo_fast one (so you don't lose connectivity).
The second command:
tc qdisc add dev eth0 root handle 1: prio
Will substitute the pfifo_fast qdisc with the prio one. By default, the prio queue has 3 bands (0, 1, 2) each managed by one class (1:1, 1:2 and 1:3).
The packets will be sent to one of those bands using the TOS field of the IP package. This configuration is shown when you execute:
tc qdisc ls
looking at the 'priomap' values.
Then, you add a netem qdisc:
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
With this command you delay all traffic going to the 1:1 band (until the filter is in place).
But there are two caveats:
- Your traffic can have a different TOS value and then being sent to another band.
- The prio qdisc can be configured so the traffic goes to another band.
The following solved my issue to not be affected by the netem while the filter is not applied. Instead of the above steps, I did:
tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
This will send all traffic by default to the band 1:3.
Then, I added the rule to delay traffic:
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 100ms 10ms
This creates the qdisc in the band 0, but since all traffic goes to band 3, it didn't affect me.
Afterwards, I added the filter:
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.1/32 match ip dport 80 0xffff flowid 1:1
Now with the filter, only the chosen IP/port will be affected, since we redirect the chosen traffic to the band 0.
All the other traffic continues unaffected since it continues to flow to band 3.
edited Nov 6 '18 at 15:00
Community♦
1
1
answered Mar 31 '17 at 19:00
TelegrapherTelegrapher
20129
20129
what is the "ip dst 10.0.0.1/32" ? Is that the destination ip? does that mean there is a "ip src xxx.yyy.zz.www/aa" ?
– Zach Folwick
May 20 '17 at 3:36
Yes, it is the destination IP in my example. And yes, there is an 'ip src' option.
– Telegrapher
May 23 '17 at 9:35
The reason for the first command (tc qdisc del) is to clear out any previous state - like you might have if you are experimenting trying to make this work. FWIW the accepted answer Worked For Me.
– Dan Pritts
Aug 2 '17 at 2:09
add a comment |
what is the "ip dst 10.0.0.1/32" ? Is that the destination ip? does that mean there is a "ip src xxx.yyy.zz.www/aa" ?
– Zach Folwick
May 20 '17 at 3:36
Yes, it is the destination IP in my example. And yes, there is an 'ip src' option.
– Telegrapher
May 23 '17 at 9:35
The reason for the first command (tc qdisc del) is to clear out any previous state - like you might have if you are experimenting trying to make this work. FWIW the accepted answer Worked For Me.
– Dan Pritts
Aug 2 '17 at 2:09
what is the "ip dst 10.0.0.1/32" ? Is that the destination ip? does that mean there is a "ip src xxx.yyy.zz.www/aa" ?
– Zach Folwick
May 20 '17 at 3:36
what is the "ip dst 10.0.0.1/32" ? Is that the destination ip? does that mean there is a "ip src xxx.yyy.zz.www/aa" ?
– Zach Folwick
May 20 '17 at 3:36
Yes, it is the destination IP in my example. And yes, there is an 'ip src' option.
– Telegrapher
May 23 '17 at 9:35
Yes, it is the destination IP in my example. And yes, there is an 'ip src' option.
– Telegrapher
May 23 '17 at 9:35
The reason for the first command (tc qdisc del) is to clear out any previous state - like you might have if you are experimenting trying to make this work. FWIW the accepted answer Worked For Me.
– Dan Pritts
Aug 2 '17 at 2:09
The reason for the first command (tc qdisc del) is to clear out any previous state - like you might have if you are experimenting trying to make this work. FWIW the accepted answer Worked For Me.
– Dan Pritts
Aug 2 '17 at 2:09
add a comment |
Simple example from https://wiki.linuxfoundation.org/networking/netem that lets you delay packets to a given IP without affecting any other traffic, even during configuration:
tc qdisc del dev eth0 root # Ensure you start from a clean slate
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 500ms
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32
match ip dst 192.168.1.2 flowid 1:3
I must add a caveat, it later seemed like the delay applied more broadly that I expected and I could not get to the bottom of it. Not all traffic seemed delayed though.
– NeilenMarais
Jan 18 at 8:18
add a comment |
Simple example from https://wiki.linuxfoundation.org/networking/netem that lets you delay packets to a given IP without affecting any other traffic, even during configuration:
tc qdisc del dev eth0 root # Ensure you start from a clean slate
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 500ms
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32
match ip dst 192.168.1.2 flowid 1:3
I must add a caveat, it later seemed like the delay applied more broadly that I expected and I could not get to the bottom of it. Not all traffic seemed delayed though.
– NeilenMarais
Jan 18 at 8:18
add a comment |
Simple example from https://wiki.linuxfoundation.org/networking/netem that lets you delay packets to a given IP without affecting any other traffic, even during configuration:
tc qdisc del dev eth0 root # Ensure you start from a clean slate
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 500ms
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32
match ip dst 192.168.1.2 flowid 1:3
Simple example from https://wiki.linuxfoundation.org/networking/netem that lets you delay packets to a given IP without affecting any other traffic, even during configuration:
tc qdisc del dev eth0 root # Ensure you start from a clean slate
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 500ms
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32
match ip dst 192.168.1.2 flowid 1:3
answered Oct 24 '18 at 10:54
NeilenMaraisNeilenMarais
238128
238128
I must add a caveat, it later seemed like the delay applied more broadly that I expected and I could not get to the bottom of it. Not all traffic seemed delayed though.
– NeilenMarais
Jan 18 at 8:18
add a comment |
I must add a caveat, it later seemed like the delay applied more broadly that I expected and I could not get to the bottom of it. Not all traffic seemed delayed though.
– NeilenMarais
Jan 18 at 8:18
I must add a caveat, it later seemed like the delay applied more broadly that I expected and I could not get to the bottom of it. Not all traffic seemed delayed though.
– NeilenMarais
Jan 18 at 8:18
I must add a caveat, it later seemed like the delay applied more broadly that I expected and I could not get to the bottom of it. Not all traffic seemed delayed though.
– NeilenMarais
Jan 18 at 8:18
add a comment |
I haven't manage to delay traffic to one IP while keeping traffic normal to others IP normal with the method described in this thread.
However, I manage to do it using the following commands.
tc qdisc add dev eth0 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 0ms
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src `hostname -I` flowid 1:2
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 15001ms
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst 1.2.3.4 flowid 1:1
To delay 15001ms
traffic to IP 1.2.3.4
from the host where the command is executed. The command hostname -I
is used to get the main IP of the host but the value can be replaced directly inside the command.
I had to add another filter with 0ms
delay to match the traffic coming from the host. For sure it is not elegant but I haven't managed to have something nicer working.
The last command can be replaced to match a single port.
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 18583 0xffff flowid 1:1
To delay traffic to port 18583
instead of IP 1.2.3.4
.
add a comment |
I haven't manage to delay traffic to one IP while keeping traffic normal to others IP normal with the method described in this thread.
However, I manage to do it using the following commands.
tc qdisc add dev eth0 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 0ms
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src `hostname -I` flowid 1:2
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 15001ms
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst 1.2.3.4 flowid 1:1
To delay 15001ms
traffic to IP 1.2.3.4
from the host where the command is executed. The command hostname -I
is used to get the main IP of the host but the value can be replaced directly inside the command.
I had to add another filter with 0ms
delay to match the traffic coming from the host. For sure it is not elegant but I haven't managed to have something nicer working.
The last command can be replaced to match a single port.
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 18583 0xffff flowid 1:1
To delay traffic to port 18583
instead of IP 1.2.3.4
.
add a comment |
I haven't manage to delay traffic to one IP while keeping traffic normal to others IP normal with the method described in this thread.
However, I manage to do it using the following commands.
tc qdisc add dev eth0 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 0ms
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src `hostname -I` flowid 1:2
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 15001ms
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst 1.2.3.4 flowid 1:1
To delay 15001ms
traffic to IP 1.2.3.4
from the host where the command is executed. The command hostname -I
is used to get the main IP of the host but the value can be replaced directly inside the command.
I had to add another filter with 0ms
delay to match the traffic coming from the host. For sure it is not elegant but I haven't managed to have something nicer working.
The last command can be replaced to match a single port.
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 18583 0xffff flowid 1:1
To delay traffic to port 18583
instead of IP 1.2.3.4
.
I haven't manage to delay traffic to one IP while keeping traffic normal to others IP normal with the method described in this thread.
However, I manage to do it using the following commands.
tc qdisc add dev eth0 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc qdisc add dev eth0 parent 1:2 handle 20: netem delay 0ms
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src `hostname -I` flowid 1:2
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 15001ms
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst 1.2.3.4 flowid 1:1
To delay 15001ms
traffic to IP 1.2.3.4
from the host where the command is executed. The command hostname -I
is used to get the main IP of the host but the value can be replaced directly inside the command.
I had to add another filter with 0ms
delay to match the traffic coming from the host. For sure it is not elegant but I haven't managed to have something nicer working.
The last command can be replaced to match a single port.
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 18583 0xffff flowid 1:1
To delay traffic to port 18583
instead of IP 1.2.3.4
.
answered Apr 24 at 11:03
Nicolas HenneauxNicolas Henneaux
1012
1012
add a comment |
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f389290%2fusing-tc-to-delay-packets-to-only-a-single-ip-address%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown