OpenBSD Journal

Ask undeadly: using OpenBSD to add latency (not just lower bandwidth)?

Contributed by grey on from the starband simulations dept.

P. Pruett asks:
Could it be feasible to setup an openbsd box that is working as a router/firewall (2 network cards forwarding IPv4) to not only shape down traffict and limit to 128K but also add latency, like 500 miliseconds?

That way the box could allow admin to see how things might behave over a limited vpn or satellite or whatever connection...
I know that pf can throttle the bandwidth... but how can I add latency?
It would be useful to see how applications behave between lans that are connected remotely.

(Comments are closed)


Comments
  1. By Philipp (85.74.8.52) pb@ on

    Hi, check: http://www.iijlab.net/~kjc/software/dist/tunbridge-0.1.tar.gz README ----------------------------------------------------------------------- tunbridge(1) emulate a long, possibly lossy, link using the tun device. tunbridge(1) reads packets from the tun(4) device, creates a delay, packet loss, and packet shaping, and then, reinjects the packets to the same tun device. tunbridge(1) reports statistics every 5 seconds, or when the SIGUSR1 signal is received. Note that, since the delay is controlled in the userland, the precision is affected by process scheduling. Also note that the precision of the delay and shaping control is limited by the kernel clock tick granularity (10ms in popular platforms).

    Comments
    1. By Anonymous Coward (192.25.19.11) on

      I've been using Freebsd's dummynet for this with good success

      Comments
      1. By Anonymous Coward (65.190.56.4) on

        will it work on obsd?

        Comments
        1. By Anonymous Coward (134.58.253.113) on

          No, dummynet relies on IPFW. OpenBSD has PF of course.

          Comments
          1. By Jake Von Slatt (12.30.32.50) jake@vonslatt.com on http://www.vonslatt.com

            Dummynet http://info.iet.unipi.it/~luigi/ip_dummynet/ is also available on a picoBSD floppy - you can sim a satellite network in minutes after downloading.

    2. By drkfiber (207.241.43.115) drkfiber at retortion.net on

      Tunbridge works great. I have been looking for something like this for a while now. Thanks.

  2. By Anonymous Coward (209.170.130.44) on

    I have used FreeBSD for this with great success. My only complaint about it is that there is no way to vary the delay, I mean what link do you know that always has 200ms delay exactly..... It would be nice to have the option to say vary delay from 200-300ms so the per packet delay would be random, like in real networks. Anyway it is a great tool!

    Comments
    1. By steve latif (64.174.237.206) steve at latif dot org on

      Yeah FreeBSD and dummynet are a good combination to use. I've tried the Linux alternatives: 2.4 kernel + nistnet, and 2.6 kernel and the traffic
      shaping module. These are both very unstable and 2.6 kernel traffic
      shaping has one of the most unusable user interfaces.

    2. By Anonymous Coward (216.254.17.65) on

      No way to vary the latency? Surely you have not been exploring the true wonderful depths of freebsd's dummynet! Simply slap a probablistic modifyer to the rule that, if the rule matches, it then throws a roll of the dice to see if it *really* matched. If the roll fails, it goes on. You can put numerous similar rules all back to back with different delay values and probability ratings and create a rather complex random delay cocktail. Couple with that with a few rules with low probability that drop packets and you can go a long way towards simulating complex internetworks. Check the ipfw and dummynet manpages in freebsd (search for 'random' or 'prob'.. it's somewhat tucked away in the documentation).

      My job requires me to do some rather tricky things with TCP sometimes and when I need to add delay or packet loss to a network for a reproduction, dummynet is my tool of choice and is a significant reason i keep some FreeBSD boxes lying around in addition to my OpenBSD ones.

  3. By iGsys (80.229.197.106) on

    Use Honeyd, it rocks at this sort of thing

  4. By cruel (195.39.211.10) on

    assume queue 1Mbit/s. assume 1500 bytes packet size, which is 12000 bits.

    1 000 000 / 12 000 = 83.3 pps.

    1 / 83.3 = 0.012 s, which is 12 ms delay.

    bandwidth is DIRECTLY related to packet round-trip time.

    Comments
    1. By Otto (82.197.192.49) otto@drijf.net on

      What is your point?

      Individual packet round trip time does not say anything about bandwidth, since multiple packets can be on a link at the same time.

      Reducing the bandwidth of a link with altq like you suggest will only have effect on a saturated link, so your simulation does nor produce the same behaviour as a real high latency link.

      Comments
      1. By masoud (47.248.0.43) mas at masoud.ir on

        Imagine trans-atlantic links. They are big fat pipes, but Turn-around-time is still higher than your locla 10 megabit network.

      2. By cruel (195.39.211.10) on

        > What is your point?

        32Kbit/s is 32Kbit/s on dialup equally as on some altq queue built over Ethernet device. nothing else.

        pppd has buffers. ip stack has buffers. interface driver has buffers. altq queue is a buffer after all. and yes, multiple packets almost always are on the long osi stack path.

        > Reducing the bandwidth of a link with altq like you suggest
        > will only have effect on a saturated link, so your simulation
        > does nor produce the same behaviour as a real high latency link.

        so? calculate round-trip time from traceroute/ping against real link and use my formula in revers manner to know what bandwidth setting you need to set with altq to simulate.

        if i will need to test 32Kbit/s with high latency which is (in real) higher than theoretical, i will calculate appropriate bandwidth and go into pf.conf to configure it.

        > Imagine trans-atlantic links. They are big fat pipes, but
        > Turn-around-time is still higher than your locla 10 megabit
        > network.

        so? big atlantic pipes are highly VARIABLE DELAY links. how can mythic "delay" option (which will add CONSTANT DELAY) help?

        all you need is average round-trip time close to what you have in real. after this number is uncovered, just configure altq queue with bandwidth which will reflect your average round-trip time.

        Comments
        1. By masoud (70.28.15.40) on

          He is more worried about rtt, which is the time it takes for ONE packet to go from A to B, and be back. this has NOTHING to do with the bandwidth, since for ONE packet, you have to do all of the processing in all of routers along the way, go to a satellite and back, etc. I guess another example is car manufacturing lines. How many cars are built in a given factory per day? say around 300 How much time does it take for ONE car to be built and be seen at the end of production line? 4 days. You could install more machinery to make more cars, but unless you do a massive technology change (say, robots), you can't reduce that 4 day time.

          Comments
          1. By cruel (195.39.211.10) on

            i repeat againt and again: altq is you friend.

            if you want to watch interactive applications (like terminal sessions), rtt is important since you need to care about every single packet: increasing queue's qlimit will increase rtt since packets will be dequeued less frequently.

            if you want to watch download time, only bandwidth does matter. so you need to care about entire flow: decreasing queue's bandwidth will produce longer delays for entire flows.

            but everybody in the thread agreed with synthetic manner of these tricks. there are close to real life but real life is always bit diff...

        2. By Anonymous Coward (217.65.148.187) on

          What about if you want to roughly simulate for instance video streaming over a satellite connection? How can altq simulate 10mbps with 1000ms latency?

          Comments
          1. By cruel (195.39.211.10) on

            > What about if you want to roughly simulate for instance video
            > streaming over a satellite connection? How can altq simulate
            > 10mbps with 1000ms latency?

            use 10Mbps bandwidth and play with qlimit to achieve 1000ms rtt latency.

            look, i greatly suspect FreeBSD's dummynet do similar thing: dequeue packet after internal per-packet timer (user configured rtt) expired.

            i also agreed dummynet's delays are more user-friendly, but somebody will not install FreeBSD for that. somebody will. i will not :)

            i just want people on the thread to recall original question:

            > Could it be feasible to setup an openbsd box that is working as a
            > router/firewall (2 network cards forwarding IPv4) to not only shape
            > down traffict and limit to 128K but also add latency, like 500
            > miliseconds?

            got it? no dummynet. no delay knob. just user with "openbsd box" and the need in real life scenario simulation.

            btw, hfsc may be more suitable for streaming applications due to fine-grained bandwidth control and lot of knobs.

  5. By cruel (195.39.211.10) on

    if you want to simulate packet loss, there is "probability" keyword in pf:

    probability _number_

    A probability attribute can be attached to a rule, with a value set
    between 0 and 1, bounds not included. In that case, the rule will
    be honoured using the given probability value only. For example,
    the following rule will drop 20% of incoming ICMP packets:

    block in proto icmp probability 20%

    Comments
    1. By mark r (62.231.57.115) on

      Does the probability option work? No matter what % I set on my 3.7 box all packets get through.

      Comments
      1. By sthen (81.168.66.229) on

        If you're using rules with 'keep state', try without, because the probability applies to the rule, not the state.

        Comments
        1. By Nice one (62.231.57.115) on

          Makes perfect sense too. Thanks for that. Cheers.

  6. By wob (69.247.79.93) wob@bonch.org on

    I work for a satellite ISP and we have to do lots of mockups in the lab. From my experience, FreeBSD's dummynet has worked the best by far in scalability terms. If OpenBSD ever does something like this, I'd definitely give it a shot.

  7. By P.Pruett (67.78.160.141) ppruett@webengr.com on

    It appears that dummynet is the most frequent answer, as aforementioned it is available also on boot floppy... The down side is that it uses IPFW so we would not use it as is with existing openbsd routers. boo hoo.

  8. By Jörg Sonnenberger (139.30.252.72) joerg@leaf.dragonflybsd.org on

    I have an item on my TODO list for adding an ALTQ policy to DragonFly, which can simulate e.g. WLAN or satellite links. It would be a combination of latency, bandwidth and loss simulation.
    Once done, it should be pretty easy to port to OpenBSD.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]