Networking & IPs

You most certainly can pre-arrange bandwidth additions if you would like to do so.

We offer a variety of bandwidth limits. Examples include:

• 1Tb per month

• 3Tb per month

• 10Tb per month

• Unlimited

The bandwidth used by your device(s) can also be measured in a variety of ways; including based on an individual device’s bandwidth usage, or across multiple devices accosted with the account’s bandwidth usage.

You can use your MyServers control panel to identify how much bandwidth each device is currently using and identify what bandwidth limit is current applied to each device. To do this, after signing in to your MyServers account, navigate to the My Servers tab and then the Bandwidth per Server tab. You will then see a table which displays this information for each device on each account. Under the My Servers tab, you can also see the ‘Total Bandwidth Usage’, ‘BW Graphs per Server’ and ‘BW Graphs per Switch’ tabs; which all also display information on the bandwidth.

If you only require additional bandwidth for a specific amount of time (minimum one month), then we can change the bandwidth limit back to the original limit once you no longer need the additional bandwidth, at your request.

If you do wish to increase your bandwidth limits, please feel free to get in touch and let us know what you want the bandwidth to be set to, and we can work out a price for you. If you have any questions, please get in touch and we will be happy to help.

Yes - we provide both dedicated 1Gb connections and 10Gb connections. We can also provide 1GB vLANs.

Please be aware that, while some hosting companies claim to be providing gigabit connections but in fact share this connection amongst users, we do not do operate in this manor and we provide genuine 1Gb connections.

If you wish to upgrade to a 1Gb / 10Gb connection, please feel free to get in touch by raising a support ticket and a member of our team will be happy to discuss this with you. If you are ordering a new server, both 1Gb and 10Gb connection options can be found through our MyServers Shop.

If you are looking at upgrading to gigabit / ten gigabit connectivity, we would advise checking your current burst rate to see if you require in excess of 300Mbps / 3Gbps respectively, before upgrading, as you may also need to request an increase in the port policy of your device’s connection.

If you have any further questions, please feel free to get in touch and we will be happy to help.

The 10Gbps connections we offer are 10Gbps/Contended connections; which means we do not guaranty a constant speed of 10Gbps. The speed reached on a 10Gb connection is dependent on several factors, including the location you are trying to reach the server from and the top of the rack switch’s total usage amongst clients in the rack.

If you do have a 10Gb device hosted with us, to make sure other clients within this rack do not impact your service by saturating the top of the rack switch, we operate a fare usage policy; meaning any client who does begin to saturate the switch’s bandwidth through unfair over usage, will have action taken against them, including suspension of service in serious cases.

If you believe the speed of your server is very low, please feel free to run a speed test using third party software and then get in touch with the results in a support ticket. We will then be happy to investigate this issue for you.

If you have any further questions, please feel free to get in touch and we will be happy to help.

Once you order a new dedicated firewall, our standard package includes an initial configuration to bring the firewall online, then you can make any additional configurations changes you may require going further.

If you have any more questions about firewalls, or if you need help deciding which firewall setup is best for you, please feel free to get in touch and we will be happy to help. You can also purchase a new dedicated firewall through our MyServers shop.

Yes, you are able to have cPanel on a server behind a firewall. Please be aware that most control panels prefer a routed mode setup on the firewall, however.

If you would like more information on this, just get in touch and our team will be happy to assist.

Yes, we do support and provide IPv6 addresses.

Before you can have an IPv6 address, however, you would need to have a private IPv4 subnet on your account and have IPs from this private subnet assigned to any server that your wish to have an IPv6 address assigned to. I am afraid we cannot supply IPv6 addresses to servers on one of our public subnet ranges.

If you have a private IPv4 subnet and want IPv6, or if you want to order a private IPv4 subnet and then have IPv6 addresses assigned to your account, please get in touch in a ticket and we will discuss having this set up for you.

If you have any more questions, please feel free to look through our FAQ section, or raise a ticket and we will be happy to help.

We provide 1 IPv4 address with each dedicated server purchased through us, as standard, included in the cost of the server. Additional IPv4 addresses can be assigned to a device, either during the setup or added later at any time, for an additional cost.

The maximum number of IPv4 addresses that can be assigned to a single device is dependent on whether the device has IP addresses assigned from a public or private subnet. If you have IP addresses assigned from a public subnet, the maximum amount of addresses that can be assigned is 30 addresses per device. There is no maximum limit per device if you are using IP addresses from a public subnet; you are just limited to the amount of IP addresses available in your subnet.

If you wish to have additional IP addresses assigned to a new server you will be ordering with us, you can select how many address you want assigned to the new server through the MyServers Shop, when you order the server.

If you require additional IP addresses assigned to an existing server, IP addresses are available from our shared subnet ranges for a fee. If you require additional IPv4 addresses assigned to your server from one of our shared subnet ranges, please feel free to get in touch through a support ticket and we will be happy to discuss this with you.

Alternatively, you can have your own private range. We offer a variety of private subnet sizes, so if you want a larger amount of IPs assigned to your account and/or want control over which IPs are assigned where, this may be the better option for you. All subnet requests are subject to being approved and justified in line with RIPE usage guidelines. If you want to discuss ordering a private subnet, please feel free to get in touch through a support ticket and a member of our team will be happy to discuss this with you.

If you already own an IPv4 private subnet range, you are able to assign the available IP addresses from this subnet, to any server on your account through the control panel without letting us know. If you require additional IP addresses, please feel free to get in touch and we will discuss what options are available to you.

If you have any further questions, please look through this FAQ page or raise a ticket with us and we will be happy to help.

The easiest way to request additional IP addresses is to raise a support ticket through the MyServers control panel; containing how many additional IP addresses you require, which device(s) you would like the additional address(es) assigned to, and if you want an IP address from a public or private subnet.

This way our team will be able to discuss any costs associated with additional IP addresses and ask any justification questions that are required.

If you have any further questions, please look through this FAQ page or raise a ticket with us and we will be happy to help.

You can find the details of your package's IP Address(es) or Subnet through your MyServers customer control panel.

To do this, first login to the MyServers customer control panel, using your credentials.

Once you are logged in, click on the ‘My Servers' tab, and then click on the name of the package you wish to check the details of.

Now, click on ‘Network’ and then click on ‘IPv4 Addresses’.

You will now be presented with the list of IPv4 Addresses assigned to this device, which port on the device they are assigned to, and you can even set some Reverse DNS settings. To find more details about about a specific IPv4 Address, click on the ‘View’ button. Here you can see the DNS servers addresses.

If you have any more questions, please feel free to look through our FAQ section, or raise a ticket and we will be happy to help.

We don't change the Geo-Location of IPS, as this is down to the individual customer to do so.

If you believe that your server is experiencing a slow network connection, you should first consider and check the following:

• Is there anything on your server that may be causing this issue; e.g. a client on your device sending high volumes of traffic?

• Is your server trying to send or receive an abnormally large amount of data?

• Is your server’s connection speed and duplex settings configured correctly? Your server’s connection to our switch should always be set to full duplex and the speed setting should always match what our switch port is set to.

If you have considered and checked the above, and believe that none of these factors could be causing the slow network issue, then we would suggest hard power-cycling your machine to see if this fixes the issue. Please be aware that there is always a chance of data-loss when power-cycling a server, so we can only advise you to power-cycle your machine and the decision to do so must be your own.

If you have considered all the above, attempted to reboot the server, and this has not resolved the issue, please raise a support ticket with the following information and answers to the following questions, so that we can effectively troubleshoot this problem for you:

• Are you experiencing any complete outages or just high latency/delay to your service?

• When did you start to notice the interruption to the service?

• Is the interruption still ongoing? If not, when did it end?

• Can you please supply an MTR of 1000 cycles to your hosted server from your remote machine (forward direction)?

• Can you please supply an MTR of 1000 cycles to your remote machine from your hosted server (reverse direction)?

• Please confirm the public address you are using at the remote location; and also the IP address of the affected service hosted with us?

• Can you please confirm the geographical location you are trying to reach the server from?

• Have you have tried to re-boot your server?

• Can you please confirm the speed and duplex settings of this server?

Once you get in touch with the above information, our team will be able to look into this issue for you as soon as possible. If you have any further questions, please get in touch and we will be happy to help.

If you believe that your server is experiencing packet loss, you should first consider and check the following:

• Is there anything on your server that may be causing this issue?

• Is your server trying to send or receive an abnormally large amount of data / packets? If so, can I resolve this?

• Is your server’s connection speed and duplex settings configured correctly? Your server’s connection(s) to our switch should always be set to full duplex and the speed setting should always match what our switch port is set to.

If you have considered and checked the above, and believe that none of these factors could be causing the slow network issue, then we would suggest hard power-cycling your machine to see if this fixes the issue. Please be aware that there is always a chance of data-loss when power-cycling a server, so we can only advise you to power-cycle your machine and the decision to do so must be your own.

If you have considered all the above, attempted to reboot the server, and this has not resolved the issue, please raise a support ticket with the following information and answers to the following questions, so that we can effectively troubleshoot this problem:

• Are you experiencing a complete outage or high latency/delay to your service?

• When did you start to notice the interruption to service?

• Is the interruption still ongoing? If not, when did it end?

• Can you confirm the speed/duplex setting for the interface with the issue?

• Can you supply an MTR of 1000 cycles to your hosted server from your remote machine (forward direction)?

• Can you supply an MTR of 1000 cycles to your remote machine from your hosted server (reverse direction)?

• Please confirm the public address you are using at the remote location; and also the IP address of the affected service hosted with us.

• Have you have tried to re-boot your server?

• Can you please confirm the speed and duplex settings of this server?

Once you get in touch with the above information, our team will be able to look into this issue for you as soon as possible. If you have any further questions, please get in touch and we will be happy to help.

If you have a problem accessing a device hosted with us from one location, but not another, before you get in touch you should consider the following:

• Could this be caused by a software problem on my external device? Does some software need updating?

• Is there a firewall rule on my hosted device or within my infrastructure that could be blocking this access?

If you have considered the above, but cannot find a resolution, please raise a support ticket with the following information:

• The device, IP address / Subnet that cannot be reached.

• The public IP address of the device that cannot reach the device in our DC.

• The geographical location of the device that cannot reach the device in our DC.

• Is this problem with more than one IP/Subnet and/or device, or just the one?

• The OS of the device that cannot be reached (please include the version).

• Is there any firewall rules that could be blocking the access to this device?

• The following Trace Routes:

  • A MTR of 1000 cycles to your hosted server from your remote machine (forward direction).

  • A MTR of 1000 cycles to your remote machine from your hosted server (reverse direction).

• The network configuration of the problem device (IP, subnet mask, default gateway, speed and duplex settings).

Once you get in touch with the above information, our team will be able to look into this issue for you as soon as possible. If you have any further questions, please get in touch and we will be happy to help.

If you have a routing issue with devices hosted with us, before you get in touch you should consider the following:

• Is there a firewall rule on one of my hosted devices that could be blocking this access?

• Are both servers accessible, online and reachable externally?

If you have considered the above, but cannot find a resolution, please raise a support ticket with the following information:

• The IP address / Subnet that cannot be reached.

• The IP address / Subnet that you are trying to reach it from.

• Is this problem with more than one IP addresses/Subnets and/or device, or just the one?

• Can you reach both devices externally?

• The OS of the devices (please include the version).

• If there any Firewall rules that could be blocking the access to this device?

• Can you please supply bi-directional MTRs of 1000 cycles (from device A to device B; then from device B to device A).

• The network configuration of the problem devices (IP, Subnet Mask, Default Gateway, Speed and Duplex settings).

Once you get in touch with the above information, our team will be able to look into this issue for you as soon as possible. If you have any further questions, please get in touch and we will be happy to help.

MTR, or My Traceroute, is a free network diagnostic tool, designed to combine the functionality of traceroute and ping monitoring programs. A MTR works by sending around one packet per second from the host device to the destination device, while probing the routers along the route path and checking how many packets were lost between each hop.

The results of an MTR will show the host each packet passes through, how many packets have been sent, the percentage of packets lost between hops and the details surrounding the results of Pings on each host. MTRs are often used when there is suspected packet loss between two devices, or a routing issue, to determine if and where any issue may reside. If you suspect either of these two issues are occurring on a device hosted with us, we will require you to run an MTR to help diagnose where the issue is.

Please see our FAQ section for information on how to run MTRs. If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

To run a MTR from a CentOS device, you first need to install the MTR package provided by Linux. If you have not installed MTR on your CentOS device before, run the following install commands:

Once you have installed the MTR package, you can now issue a command to begin the MTR.

When issuing the below command, you will need to enter the IP address of the destination device. What the destination device is depends on what problem you are experiencing and trying to diagnose. If you are experiencing packet loss or if there is a routing issue between two devices, you will need enter the IP address of the other device. In my example, I am running a MTR from one of my servers to another, as I believe that there may be packet loss between the two servers.

The MTR will now start running and it should send roughly one packet per second. You can see how many packets have been sent from the host you are running the MTR on in the top row, in-line with the host’s IP, under the sent column. You must now leave the MTR running.

Once the MTR has sent 1000 packets, you can use the results to identify where the issue lies. We require at least 1000 packets to be sent, so the results are accurate.

If you are checking for packet loss, you can use the Loss% column to identify the percentage of packets lost within this hop, and you can use the Host column in line with the Loss% column to identify where the packet loss began. If you are checking for a routing issue, you can use the Host column to identify the path the route has taken.

Once the MTR has sent 1000 packets, you should copy the entire MTR table and paste it into a text document. If you do identify an issue, you will need these results later. To copy the table from a putty window, you simply need highlight the whole table. You can see an example of a copied table below.

Once you have finished running the MTR on this device and copied the table, press Q to stop the MTR.

You should now run the MTR on the destination device, to the device you just ran the MTR on above, then copy the table (reverse direction). If you do discover any issues that lie within our network, please supply both MTRs in a support ticket with the details of the problem you are experiencing, and our team will investigate this issue.

If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

To run a MTR from an Ubuntu device, you first need to install the MTR package provided by Linux. If you have not installed MTR on your Ubuntu device before, run the following install commands:

Once you have installed the MTR package, you can now issue a command to begin the MTR.

When issuing the below command, you will need to enter the IP address of the destination device. What the destination device is depends on what problem you are experiencing and trying to diagnose. If you are experiencing packet loss or if there is a routing issue between two devices, you will need enter the IP address of the other device. In my example, I am running a MTR from one of my servers to another, as I believe that there may be packet loss between the two servers.

The MTR will now start and it should send roughly one packet per second. You can see how many packets have been sent from the host you are running the MTR on in the top row, in-line with the host’s IP, under the sent column.

Once the MTR has sent 1000 packets, you can use the results to identify where the issue lies. We require at least 1000 packets to be sent to make sure that the results are accurate.

If you are checking for packet loss, you can use the Loss% column to identify the percentage of packets lost within this hop, and you can use the Host column in line with the Loss% column to identify where the packet loss began. If you are checking for a routing issue, you can use the Host column to identify the path the route has taken.

Once the MTR has sent 1000 packets, you should copy the entire MTR table and paste it into a text document. If you do identify an issue, you will need these results later. To copy the table from a putty window, you simply need highlight the whole table. You can see an example of a copied table below.

Once you have finished running the MTR on this device and copied the table, press Q to stop the MTR.

You should now run the MTR on the destination device, to the device you just ran the MTR on above, then copy the table (reverse direction). If you do discover any issues that lie within our network, please supply both MTRs in a support ticket and our team will investigate this issue.

If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

To run a MTR from a Debian device, you first need to install the MTR package provided by Linux. If you have not installed MTR on your Debian device before, run the following install commands:

Once you have installed the MTR package, you can now issue a command to begin the MTR.

When issuing the below command, you will need to enter the IP address of the destination device. What the destination device is depends on what problem you are experiencing and trying to diagnose. If you are experiencing packet loss or if there is a routing issue between two devices, you will need enter the IP address of the other device. In my example, I am running a MTR from one of my servers to another, as I believe that there may be packet loss between the two servers.

The MTR will now have started and it should send roughly one packet per second. You can see how many packets have been sent from the host you are running the MTR on in the top row, in-line with the host’s IP, under the sent column.

Once the MTR has sent 1000 packets, you can use the results to identify where the issue lies. We require at least 1000 packets to be sent to make sure the results are accurate.

If you are checking for packet loss, you can use the Loss% column to identify the percentage of packets lost within this hop, and you can use the Host column in line with the Loss% column to identify where the packet loss began. If you are checking for a routing issue, you can use the Host column to identify the path the route has taken.

Once the MTR has sent 1000 packets, you should copy the entire MTR table and paste it into a text document. If you do identify an issue, you will need these results later. To copy the table from a putty window, you simply need highlight the whole table. You can see an example of a copied table below.

Once you have finished running the MTR on this device and copied the table, press Q to stop the MTR.

You should now run the MTR on the destination device, to the device you just ran the MTR on above, then copy the table. If you do discover any issues that lie within our network, please supply both MTRs in a support ticket along with details of the issue you are facing and our team will investigate this issue.

If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

To run a MTR on a Windows device, you will first need to download a Windows compatible program, capable of running an MTR. The most common piece of software used to run an MTR on a Windows device is WinMTR; you can download this software from WinMTR’s website:

http://winmtr.net/download-winmtr/

Once you are on the WinMTR website, press download on the appropriate version of the software. A .zip file will now download; you will then need to extract all the files from this zip folder. Then locate the appropriate version of the software’s file (x32 Vs x64) and run the WinMTR.exe file. The WinMTR program will now launch.

You now need to enter the IP address of the destination device in the Host text box. Once you have entered the destination device’s IP address, press Start. What the destination device is depends on what problem you are experiencing and trying to diagnose. If you are experiencing packet loss or if there is a routing issue between two devices, you will need enter the IP address of the other device. In my example, I am running a MTR from one of my servers to another, as I believe that there may be packet loss between the two servers.

The MTR should send roughly one packet per second. You can see how many packets have been sent from the host you are running the MTR on in the top row, in-line with the host’s IP, under the sent column.

Once the MTR has sent 1000 packets, you can use the results to identify where the issue lies. We require at least 1000 packets to be sent to make sure the result are accurate.

If you are checking for packet loss, you can use the Loss% column to identify the percentage of packets lost within this hop, and you can use the Host column in line with the Loss% column to identify where the packet loss began. If you are checking for a routing issue, you can use the Host column to identify the path the route has taken.

Once the MTR has sent 1000 packets, you should copy the entire MTR table and paste it into a word document. If you do identify an issue, you will need these results later. To copy the table, simply press the Copy Text to clipboard button.

You can see an example of a copied table below.

Once you have finished running the MTR on this device and copied the table, press the Stop button or simply close the window.

You should now run the MTR on the destination device, to the device you just ran the MTR on above, then copy the table (reverse direction). If you do discover any issues that lie within our network, please supply both MTRs in a support ticket and our team will investigate this issue.

If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

A broadcast storm is when we have an excessive amount of broadcast traffic on the network then all devices within the broadcast domain will suffer. The switch has to flood all broadcast frames to interfaces in the same VLAN, hosts within the VLAN might have to process these frames (ARP requests for example).

Too much broadcast traffic could be caused by malicious software but also by a malfunctioning NIC. To protect ourselves against this, Cisco switches offer the storm-control feature which automatically disables the switch port to protect against the switch CPU overheating and potentially taking down other devices in the rack. We configure a threshold on interfaces to set a limit to the number of broadcasts, multicast or unknown unicast traffic and an action when the threshold is exceeded.

As long as limits have been set and adhered, you shouldn’t get any issues with the port dropping.

We supply IPv4 addresses from two different types of subnets; Public Subnets and Private Subnets.

As standard, our dedicated devices are supplied with an IPv4 address from a public subnet and all additional IP addresses will come from this same public subnet. A public subnet’s IP addresses are shared amongst a multitude of clients; with several clients using addresses from the same subnet. The benefits of having IPv4 addresses from a public subnet is that it is generally cheaper than having a private subnet, per IP address. However, you are limited to 30 IP addresses per device from a shared subnet – so this is only an option for devices that require 30 or less IP addresses on each device, you cannot have IPv6 addresses while on a public subnet, and you cannot directly control which address is assigned to which device under your account.

A private subnet is assigned to a single client; with this client having access to every usable IP addresses within this private subnet. A private subnet is leased through us as a separate product and is billed for monthly. The benefits of having a private subnet is that you have full control over which device each IP address is assigned to, with a private subnet you can also have IPv6 addresses, you can have more than 30 IPs assigned to a single device and only your devices will have access to the vLAN the subnet resides upon, providing greater security. With a private subnet, you are also less likely to be affected by NAC violations. Our private subnets come in a range of sizes, to suit a range of requirements.

Please note, clients cannot have IP addresses assigned to a single device from both a public and a private subnet; it must be one or the other.

If you have any further question or wish to purchase a private subnet, please feel free to get in touch through a ticket and a member of our team will be happy to help.

Yes, we provide both IPv4 and IPv6 private subnets.

We offer private subnets in a variety of sizes; from a /27 to a /24 subnet; to cater to all our client’s needs. You can also have multiple subnets on your account, subject to justification. Our system also allow you to have multiple private subnets placed onto a single vLAN, if you require more ranges/IP within the same vLAN.

All subnet applications are subject to full RIPE justification. Please be aware that you can only have an IPv6 private subnet, if you already have, or have also ordered a private IPv4 subnet.

If you are interested in having a private subnet, please get in touch and we can work out what subnets would be best for you. Please also feel free to get in touch if you have any further questions.

Yes, we do offer private vLANs that will be assigned to your account, and can only utilised by devices on your account. Your devices can be attached to the private a vLAN, so traffic sent between these devices attached to this vLAN can be kept separate and secure from other traffic.

VLAN connections can be provided for an additional monthly fee; which we put in place just to cover the costs of the utilised networking infrastructure. We offer both 100Mb and 1Gb vLAN connections; both of which have different pricing associated.

We also allow clients to have multiple vLANs under their account; however, this is subject to justification review.

If you want to add a vLAN connection to an existing device or if you have any further questions, please feel free to get in touch, and we will be happy to discuss this with you.