Forum Replies Created

Viewing 15 posts - 1 through 15 (of 22 total)
  • Author
  • in reply to: QOS and VoIP #46254

    It can be a problem for very small business where the DSL link is shared between Data and VoIP.

    In our country there are lots of very small business companies.

    It is not possible here to have multi play offers (multiple ATM VCI channels). Tier 1 providers keep this technology too expensive, they are using it but only for their residential offers (triple play : data, TV and Voice).

    As the global DSL infrastructure in the country is managed by only two tier1 providers (France Telecom and SFR), there is no possibility to solve the problem.

    So we are using at small clients sites a normal ADSL link.

    As we can’t have neither ADSL annex M in France, because it is forbidden by the telcom regulation authority (ARCEP), the maximum upload speed we can have is about 800 to 900 kbps in best cases with ADSL2+.

    When we have this speed, there is no real problem, QOS is working good enough for VoIP.

    But in the field, we can have upload speeds from 256 to 600 kbps or sometimes less when reach extended ADSL is used for very long lines.

    In this case, a 1500 bytes packet cause a delay that can be bigger than some VoIP providers buffers using old hardware designed for fiber links where small buffers are enough.

    Reducing the MTU to about 500 bytes is not a solution, because some web sites and applications do not tolerate this, for example if you do this, the Maxtrox.com web site will stop to work.

    One of the main benefit of using QOS is costs reductions.

    To allow QOS to work on slow links for realtime traffic like VoIP, there is no other solution than reducing the data MTU, or better, fragmenting the data traffic between edge routers.

    This could be done through a specific router interface. An example of such a special router interface is the one we can have on Mikrotik routers, where we can use a “packer” interface, to compress IP headers between two routers.

    This concept could be extended to an autofragmenting interface, managed by the linux kernel, or eventualy inside a user land process if M Torwald do not want this inside the kernel. Using such an interface between two routers would allow to reduce the Data MTU size transparently, only when needed.

    in reply to: QOS and VoIP #46252

    Yes it should but this has never been done.

    I think that the reason is :

    Most telcom providers do no want to see this inside IP protocols, because they want to keep their ATM hardware and links as long as possible.

    The furur is IP, not ATM. We need a strong QOS inside IP now. We need a reliable fragmentation mecanism between WAN routers.

    Without this, even HFSC is not strong enough to give the same level of jitter than ATM on slow links.

    in reply to: QOS and VoIP #46250

    I think that it this should be implemented in the linux kernel, not in user mode for performance reasons.

    Cisco did it with AutoQOS. AutoQOS is a group of methods to manage VoIP traffic effectively and simply.

    Fragmenting is something that Linux can do easily, for UDP and TCP. This should be extended to QOS, adding auto detection and fragmentation of non VoIP frames.


    Those problems seems related to Linux and BSD. I’ve seen similar problems inside PFsense, based on BSD 7.1.

    The problem is that those systems have not been tested correctly with multiwan setups.

    Multiwan seems simple in the beginning, but is often complex and buggy in the end.

    Here is what i did on an openwrt install to avoid problems :

    # iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE
    iptables -t nat -A POSTROUTING -o $WAN -j SNAT –to-source 65.xxx.xxx.xxx

    you’ll need to adapt according to your needs. to-source is your wan public IP address.

    replace $WAN by the name of your wan interface.

    I do not know where are located those commands inside Zeroshell. You’ll have to find the right file.

    This works only if you have a static IP. If not you’ll need to make a script to dynamically configure iptables.


    has been done. sorry.

    in reply to: Failover IP addresses should be defined by gateway #47863

    yes you are right.

    it is done like this in the bonding driver as well if i remeber correctly, where we can define a set of targets for all links, not separately for each link.

    Inside Pfsense i think we can define separate targets for each gateway, and choose as well tcp port checks instead of icmp.
    Medium priced commercial Multiwan routers does allow this too.


    in reply to: DNS forwarder does not support NAPTR for ENUM requests #47859

    What are you using for the DNS forwarder ?

    DNSMASQ seems to not have the NAPTR reverse DNS problem as it is working flawlessly inside openwrt.

    in reply to: Major Netbalancer Issue #47707

    I had a similar problem, when using a failover bonding, sending packets to a bridge at the other side through two different tunnels, each one using a different provider wan link.

    the bridge at the other side was sending back arp traffic sent by the bonding dead link arp detection, causing unuseful traffic on the spare link.

    A solution is to use IP target failover detection instead of ARP, this is implemented in the bonding driver, but the switching response time is in the second range instead of millisecond.

    Using the bonding driver in arp detection mode is a must for VoIP tunnels, it does allow to switch a dead wan link in about 40 ms, almost not noticeable on a phone call.

    There is a setting in the bonding driver that give the possibility to setup the arp time between each request.

    It would be nice to have access to those bonding driver settings in the GUI, as well as giving access to other bonding modes (there are about 5 modes if i remember correctly).

    in reply to: Failover IP addresses should be defined by gateway #47861


    Perhaps a small explanation should be added in the GUI :

    “A link will be considered faultly if all the targets defined here are down seen from this link.

    If only one target is down seen from this link, it will stay active or spare.”

    in reply to: Matching by DSCP field for QOS and load balancing rules. #47866

    The problem with manipulating iptables manually is that if you don’t do it every day, you forget all syntax details and the process become very long.

    That’s why i think it is very important to keep the GUI interface working for most jobs.

    Zeroshell is really the smarter router i’ve ever seen, just a couple of details are missing to be able to use it for advanced work.

    The difference between zeroshell and other similar routers, is that when you do advanced things it does work. Other routers generally stop to work correctly as soon as you try to do multiwan, multilan, multi port forwarding, inbound load balancing and other things you can do reliabily on professional routers.

    Pfense version 2 alpha seems to have interesting possibilities, but the testing i’ve done on it a couple of days ago show that advanced functions are extremely buggy or not working at all. The road seems very long to get a stable version, if there is one one day.

    Pfsense version 1.2 is just not powerfull enough regarding routing possibilities in a multilan – multiwan setup. It does work with multiwan, but stop to work as soon as you try to add multilan at the same time.

    At opposite zeroshell seems efficient and stable, more usable in the real life, even if the Pfsense GUI is better in some aspects, specially in the OpenVPN area.

    in reply to: Forwarding a port range with zeroshell ? #47870

    I’ve found a patch in this forum to update the GUI interface. Working great.

    I hope this will be included in the next version.


    in reply to: DNS resolution not working from shell #47875

    Strangely the nameservers here are the one of the fault link.

    I have a dual wan failover setup, with actually a fault link, the first one in the list with higher weight.

    More strange is that DNS resolution is now working, since the first link is down.

    How does work name resolution inside zeroshell when load balancer is used ?

    the first link is a pppoe link, with dns given by the provider

    The second link is a DHCP link, but the provider does not send the DNS server addresses in the DHCP offer.

    Thanks for your help.

    in reply to: Load Balancer and MultiLan #47857

    What i’d like to do with two wan is :

    – a balanced rule for Internet access

    – a failover rule for telephony, with link #1 as primary

    – a failover rule for Data, with link #2 as primary

    Is it possible to do this with the actual implementation ?

    in reply to: Load Balancer and MultiLan #47856

    Thanks ! i didn’t tought it was working like this.

    If i’m right, all traffic not catched by a balancing rule goes directly to the balancer gateways (Auto routing), but it is possible to send some traffic to a selected gateway by a specific rule.

    Then, if the gateway is not up, the traffic goes to the automaticaly selected gateway from the balacing group.

    This is not easy to understand and This is easy to do for two wans but is a bit limiting for a multiwan setup, where it is simpler to define a balancing group for each user group.

    Next, it is not possible with this setup to have a failover balance for a users group, and load balancing for another group.


    Unfortunately i’m not aware of this :=(

    I think that it is something to create, nobody seems really aware of this problem.

    Most of the time, professionals say : use a dedicated ADSL or SDSL link for VoIP or it will not work correctly. Well… Why do we have QOS if it is not efficient ?

    In fact, it is perfectly possible to share a link with Data, as soon as the data MTU do no exceed about 200 Bytes.

    A simple calculus :

    For a 1 Mbps uplink Wan speed, we need about 12 ms to transmitt a full 1500 bytes IP frame.

    So, as soon as there is a big data transfer on the Wan, even with the best QOS algorythm, a VoIP paquests need to wait between 0 and 12 ms in the best case before to be sent, if it can be queued just after the actual Data paquet. In the worst case, if the queue is not almost empty, or if the QOS algorythm decide to not give full priority to the VoIP paquet, then evntually the VoIP paquet will need to wait more than 12 ms to be transmitted.

    0-12 ms of jitter is the best case, for a 1 Mbps link. If the upload link is slower, then jitter will be higher. A good test is to issue a ping during a heavy upload. You will see that even with the highest ICMP priority you will set on QOS settings, the ping timing value will dramatically increase during this upload. This is a symptom of the bad realtime QOS of Linux.

    12 ms of jitter is something quite high, not for asterisk, but for some VoIP providers, who sometime do not have equipment to compensate for such a high jitter (this is because historically they were working on high bandwith links, and their hardware do not care slow speed links with high jitter).

    I think that there is no other way than fragmenting the Data traffic, to create holes for VoIP paquets in the upstream QOS queue.

    In a fisrt implementation attempt, perhaps it would be simpler to forget the automatic fragmentation, forcing fragmentation on all data traffic ?

    After all, a dedicated link is a compromize. But VoIP cannot tolerate jitter. So i think that in the case of a shared link, it is better to reduce Data efficiency, fragmenting all data traffic.

    In a second phase, it would be interesting to implement an auto VoIP traffic detection, to fragment data only when necessary, like in cisco routers.


Viewing 15 posts - 1 through 15 (of 22 total)