Just got our virtual rack servers, the bandwidth between them is not counted towards the bandwidth quote correct?

Theres no special local IPs for this purpose, I just use the public IPs for MySQL connection from one server to the other?


Thanks

Any traffic going through the public switch will be counted. Our sales group can give you the information on backend switches which will allow traffic to flow between the servers.

So with the virtual rack servers you get a private IP for each virtual rack server to send traffic server to server within the virtual rack for free?

You can set an IP address(10.*, 192.*) but it won't route out of the VLAN that the private rack is on. If this is done via the front end switch port, the bandwidth polling servers will count it towards the pool because all traffic is counted bit by bit.

If it's done on an add-on backend switch or (legacy) cross connect, then it won't be counted towards the front end traffic.

I took the third bullet point at https://www.theplanet.com/servers/pr/ to imply that server to server transfer was via a private network as one of the advantages of the virtual rack servers. Now that I think about it, I suppose unlimited does not mean unmetered -- "limited by your finances only" might be more accurate than "unlmiited" if it is truely metered by default though.

Edit: http://www.theplanet.com/dedicated-servers/private-racks/ actually says more:
so unlimited here does seem to be used to mean unmetered...

My understanding, at least the way it was done at one time, was that you were only billed for what actually left the switch on the uplink port. If the traffic did not go out the uplink port you were not billed for it. I guess the policy may have changed sometime? I would have to check but I am pretty sure we have a few clients using a lot of server <-> server BW without being charged. I wonder if this is just because they are legacy?

What if I have 3 servers all connected to a back-end private network (in a private rack), am I not charged for connecting to the other servers ACTUAL IPs?

ie. web server IP 67.15.111.x and 67.15.111.x communicating back and forth. I don't have 129.0.x.x or 10.0.x.x IPs setup and just connect to the actual IP of the servers at the moment.

The bandwidth charts in Orbit are showing my inter-server transfer based on the above configuration.

When you have a private rack and your servers are communicating over the public switch, some of the broadcast traffic still travels over the uplink port. That small about of data transfer will count towards your bandwidth transfer limits.

In a virtual rack, and data transfer over the server uplink to the switch will count towards the bandwidth transfer limit for that server (or bandwidth pool). The only way to utilize the "unlimited server to server traffic" is to assign private IPs to the secondary network interfaces and communicate over the private back-end VLAN.

internal bandwidth is still bandwidth to most companies I believe. They have no local connections setup unless it's a special case, but I've never witnessed it.

For virtual private racks you can setup your servers to communicate with each other on private IP's. That means they will not communicate over the public switch and you do not have the bandwidth counted against you. Virtual Private Racks or vipr as we call it internally is the way to go in almost every instance.

Can a block of public IP addresses be allocated to the entire rack and then distrubuted among the servers in the rack at our choosing?

In Virtual Private Racks you can port IP's. It works best when you order additional IP's after the server/s are online so they are not attached/bound to that server. For the record it can be done with the original order however it requires some extra work and a pre-sale note that the IP's should be portable. If the proper steps are not taken before the IP's are assigned we may not be able to assist you. Moving IP's from server to server is a standard practice with private racks.

Also, anytime you move IPs between servers, let us know so we're not looking at the wrong servers in case you need some support.