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;








18















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?










share|improve this question




























    18















    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?










    share|improve this question
























      18












      18








      18


      6






      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?










      share|improve this question














      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked May 15 '12 at 15:38









      Matt WhiteMatt White

      4471415




      4471415




















          4 Answers
          4






          active

          oldest

          votes


















          13














          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.






          share|improve this answer























          • 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



















          10














          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.






          share|improve this answer

























          • 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


















          1














          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





          share|improve this answer























          • 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


















          0














          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.






          share|improve this answer























            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
            );



            );













            draft saved

            draft discarded


















            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









            13














            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.






            share|improve this answer























            • 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
















            13














            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.






            share|improve this answer























            • 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














            13












            13








            13







            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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


















            • 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














            10














            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.






            share|improve this answer

























            • 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















            10














            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.






            share|improve this answer

























            • 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













            10












            10








            10







            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.






            share|improve this answer















            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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

















            • 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











            1














            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





            share|improve this answer























            • 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















            1














            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





            share|improve this answer























            • 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













            1












            1








            1







            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





            share|improve this answer













            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






            share|improve this answer












            share|improve this answer



            share|improve this answer










            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

















            • 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











            0














            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.






            share|improve this answer



























              0














              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.






              share|improve this answer

























                0












                0








                0







                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.






                share|improve this answer













                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Apr 24 at 11:03









                Nicolas HenneauxNicolas Henneaux

                1012




                1012



























                    draft saved

                    draft discarded
















































                    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.




                    draft saved


                    draft discarded














                    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





















































                    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







                    Popular posts from this blog

                    Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

                    Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

                    Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020