Category Archives: Network

Network

Routers with SIP, NAT and ALGs

Getting some routers working with VOIP can be a pain. The problem is caused by NAT, and the translation of a private IP address (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) in to a IP address that works on the internet.

This is difficult with SIP/VOIP because IP addresses are not only included in the packet header, but also inside the packet itself. There are various methods that can be used to try and resolve this issue, and various places that ‘fixes’ can try and work.

The issue is this …

  • a local device (phone) sends a SIP packet to a device on the internet (Asterisk)
  • this packet will include local IP addresses in it but the Asterisk server needs to respond to the public address

There are a few different methods to try and ‘fix’ the issue

  • the phone uses STUN/ICE and tries to replace the private IP with the public IP in the packets it sends
  • the broadband firewall includes rules (a SIP ALG) to modify the packet as it’s forwarded
  • Asterisk tries to fix the issue by seeing where the packet came from (source address) and using that to modify the SIP packets

The 3 things working above can cause chaos, and failed calls!

The most difficult to troubleshoot is the firewall SIP ALG one as a packet will go in from the local network, some changes will be made!, and then the packet will be forwarded to the internet device. Some routers do a better job making changes to the packets than others.

I came across a great list written by Vonage including many routers and steps that can be taken to try and get them working with VOIP/SIP – https://support.vonagebusiness.com/app/answers/detail/a_id/21546

D-Link POE switch review – powering VOIP handsets

If you use more than a single VOIP phone then powering it using power over ethernet (POE) makes sense. Instead of plugging the phone into a regular power socket it can draw its power from the Ethernet cable. Much neater than having lots of power blocks.

To do this you need a special switch to provide the power. For the past year I’ve been using the D-Link DGS-1008P. This is an 8 port gigabit switch, with 4 of the ports able to provide power. The switch is relatively inexpensive for a POE switch and is unmanaged, so just plug in and play.

DGS-1008P

One thing to consider when using POE is the power requirement of the device being used. The DGS-1008P can provide up to 15.4 watts per port, with a total load of 52 watts across the 4 ports. This is unlikely to be an issue with a VOIP handset. My two day to day phones are the Yealink T22P and Aastra 53i, both of which draw up to around 2.5 watts.

So if you’re looking for a simple ‘desk’ switch to provide network/power to up to 4 handsets the DGS-1008P could be a good choice.

Understanding latency and packet loss with mtr

If you have call quality issues with VOIP then one of the first things to check is if there is any packet loss or unexpected high latency on the network connections. A great tool for this is called ‘mtr’.

However, I often see some misunderstanding of the reports produced by mtr.

I was going to write a guide to mtr but there is a really good one already that you can find here – https://library.linode.com/linux-tools/mtr

Two of the most important things the post highlights can be summarised like this …

Packet loss

This packet loss is OK …

[email protected]:~# mtr --report www.google.com
HOST: ducklington               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                50.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

This packet loss is BAD …

[email protected]:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  50.0%    10    7.2   8.3   7.1  16.4   2.9
  6. 209.85.254.247                40.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 40.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          40.0%    10   39.6  40.5  39.5  46.7   2.2

Latency

If you’re expecting a ping/latency of around 40ms this is OK (even with a 254ms latency along the route) …

[email protected]:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

If you’re expecting latency of a lot less than 400ms then this report is BAD …

[email protected]:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7   0.2
  5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7   0.2
  6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7   0.4
  7. 64.233.174.46                 0.0%    10  391.8 360.4 342.1 396.7   2.1
  8. gw-in-f147.1e100.net          0.0%    10  392.0 360.4 342.1 396.7   1.2

Go read the guide to find out more and read a description of the traces above – https://library.linode.com/linux-tools/mtr

VoIP latency (ping) test for SysAdminMan servers

I get asked quite a lot for example IP addresses that potential customers can ping to get an idea of latency to the SysAdminMan servers.

You can ping the following addresses to get an idea of latency –

UK Server – ping uk-test.sysadminman.net
US Server – ping us-test.sysadminman.net

Latency below 150ms should be fine – http://voip.about.com/od/glossary/g/latency.htm

The UK servers should work well for customers in Europe and the US servers for customers in the US and Canada.

If you see unexpectedly high latency to either of the test servers please get in touch and we can look to see where the delay is being introduced.

OpenWRT review

I’ve been using OpenWRT for a couple of years now, so I thought it was time to talk a little about it.

First off what is OpenWRT? It’s a replacement firmware for many domestic router models. There are a few different replacement firmwares but if you’re looking for something comprehensive and geeky I would definitely check out OpenWRT. You can see a list of supported routers on the OpenWRT homepage. My current favourite router is the TP-Link 1043 as it’s inexpensive with plenty of onboard memory and a reasonable CPU.

You flash the OpenWRT firmware image just as you would an update form the router manufacturer (this varies depending on the router). Then you can log in to the web management interface.

From there you can configure your network connections, firewall, etc … There are useful information pages such as realtime graphs –

openwrt-graphs

Continue reading

Fasthosts blocks server to server traffic – anyone know why?

I had a customer yesterday that was trying to set up Asterisk on a Fasthosts dedicated server. This was working well apart from inbound calls from a specific DID/DDI provider. It turned out that the call provider was also using a Fasthosts dedicated server and that traffic between Fasthosts dedicated servers is blocked (although some basic ports are allowed – 22,25,53 and 80 just to confuse things even more!).

This meant that the SIP traffic going from the call provider to the customers Asterisk server was being blocked.

Fasthosts helpdesk confirmed that this is the case and the usual solution suggested is to set up a private LAN between the 2 servers. However this is only possible where both servers are owned by the same customer, which is obviously not the case here.

Does anyone know the reason for this policy? This is the second customer I’ve seen in the past few months where this has caused an issue. I can’t think of a logical reason. Thanks!

IPv6 tunnel on OpenWRT using tunnelbroker.net

I’m far from an IPv6 expert so this is more a detail of my experiences, rather than a detailed setup guide.TP-LINK TL-WR1043ND

My ISP does not provide native IPv6 yet to their ADSL customers but I wanted to set up IPv6 on my local network, and be able to access the Internet using IPv6. To do this I’m using a free tunnel from tunnelbroker.net. The way this works is that your IPv6 packets are wrapped up in IPv4 and sent to tunnelbroker. There they are unwrapped and sent on their way, as IPv6 packets. Once set up this is transparent to you and you just treat it as a normal IPv6 network.

When you sign up for a free tunnel with tunnelbroker you will receive several pieces of information that you will need to set up your tunnel.

Continue reading

TP-LINK TL-WR1043ND OpenVPN performance on OpenWRT

This is a brief follow-up to this post – sysadminman.net/blog/2011/openvpn-sysadminman-asterisk-tl-wr1043nd-3431 – which details OpenVPN on a TP-LINK TL-WR1043ND running OpenWRT.

I used iperf to max out my ADSL link which will run at 8mb. This showed around 35% CPU usage on the TP-LINK so it looks good, at least for my line speed.

Here is the iperf report –

[ 3] local 10.10.10.248 port 56167 connected with 10.20.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 9.25 MBytes 7.65 Mbits/sec

and CPU usage by running ‘top’ on the TP-LINK –

CPU: 17% usr 8% sys 0% nic 63% idle 0% io 0% irq 9% sirq
Load average: 0.00 0.00 0.00 1/35 1194
PID PPID USER STAT VSZ %MEM %CPU COMMAND
1154    1 root S 4516 15% 34% /usr/sbin/openvpn --syslog openvpn(sa
1194 1188 root R 1376  5%  0% top

OpenVPN with a TP-LINK TL-WR1043ND

TP-LINK TL-WR1043NDThere are several potential benefits to setting up a VPN to your Asterisk server. All traffic is encrypted and you don’t need to open lots of ports in the firewall. Also there are no issues with SIP and NAT as traffic is routed over the VPN tunnel.

This is a pretty advanced setup but here is a walkthrough for setting up a SysAdminMan VPS as an OpenVPN server and then connecting to it with a TP-LINK router running OpenWRT.

Specifically this router is used – http://www.tp-link.com/en/products/details/?model=TL-WR1043ND. I paid around £40 from Amazon, an absolute bargain for something that will run OpenWRT.

Setting up the router

First you need to flash OpenWRT on to the router. This replaces the original firmware. Here are some instructions for this TP-Link router – http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd?s. I got version 18 of the router and flashed Backfire 10.03.1-rc6 version of OpenWRT.

Continue reading

Want to earn lots of money over the next few years? Learn IPv6!

Over the past few years there has been increasing concern about the shortage of IPv4 addresses. It’s now starting to grab the attention of the media, and for good reason.

At one point it must have seemed like the 4 billion IPv4 addresses would be more than enough but there are currently less than 10% left, and they’re going fast.

Exactly when they will run out is difficult to predict. The widespread usage of NAT has helped to prolong the availability of public addresses, but an interesting page here predicts only 86 days left at the time of writing. This will probably be extended as organisations hand back unused blocks, but they won’t last long.

What’s the answer? IPv6!

IPv6 provides 340 billion billion billion billion IP addresses so we really shouldn’t run out of those. However, IPv4 and IPv6 are incompatible. They do not work together, so soon we are going to have 2 separate Internets. There is going to be a huge demand over the transition period (which will take years) for people that understand IPv4 and IPv6 and how to make them work together.

So if you’re looking for something new to learn – start playing with IPv6! Your skills will definitely be in demand.

Here’s some reading to get you started –