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

                    Wikipedia:Vital articles Мазмуну Biography - Өмүр баян Philosophy and psychology - Философия жана психология Religion - Дин Social sciences - Коомдук илимдер Language and literature - Тил жана адабият Science - Илим Technology - Технология Arts and recreation - Искусство жана эс алуу History and geography - Тарых жана география Навигация менюсу

                    Bruxelas-Capital Índice Historia | Composición | Situación lingüística | Clima | Cidades irmandadas | Notas | Véxase tamén | Menú de navegacióneO uso das linguas en Bruxelas e a situación do neerlandés"Rexión de Bruxelas Capital"o orixinalSitio da rexiónPáxina de Bruselas no sitio da Oficina de Promoción Turística de Valonia e BruxelasMapa Interactivo da Rexión de Bruxelas-CapitaleeWorldCat332144929079854441105155190212ID28008674080552-90000 0001 0666 3698n94104302ID540940339365017018237

                    What should I write in an apology letter, since I have decided not to join a company after accepting an offer letterShould I keep looking after accepting a job offer?What should I do when I've been verbally told I would get an offer letter, but still haven't gotten one after 4 weeks?Do I accept an offer from a company that I am not likely to join?New job hasn't confirmed starting date and I want to give current employer as much notice as possibleHow should I address my manager in my resignation letter?HR delayed background verification, now jobless as resignedNo email communication after accepting a formal written offer. How should I phrase the call?What should I do if after receiving a verbal offer letter I am informed that my written job offer is put on hold due to some internal issues?Should I inform the current employer that I am about to resign within 1-2 weeks since I have signed the offer letter and waiting for visa?What company will do, if I send their offer letter to another company