"What's your server's uplink speed?"

"What?"

"How fast is your server's network connection?"

"OC3 I think."

That's not an actual discussion but I could see it being a common one with many people getting started in dedicated hosting. Non-administrators just assume the server is "connected to the Internet" and can perform at whatever speed the host advertises for network bandwidth. That is of course not quite accurate.

When reviewing differences between our standard managed dedicated hosting options and some cheap competitor options, something that shows up (much more often than many would believe) is the server's uplink speed. This is the speed of the server's connection to the web host's network core. It amazes me that some hosts have default uplink speeds of 10 Mbps then charge for an increase to 100 Mbps and charge further for an increase to 1000 Mbps (gigE).

Now, I can understand why the host would do that because the lower the uplink speed, the lower the total impact on their overall bandwidth. It would also allow them to use older network equipment (10 Mbps wasn't bad 10 years ago).

But how does that impact the hosting client? Well, it can actually have a rather large impact on the client.

Time Warner Road Runner is the ISP I use at home and when things are running well I get about 6 Mbps of download speed. How many concurrent users at 6 Mbps would it take to saturate a 10 Mbps uplink? Not many. It is more than just 1.5 because visitors don't all click at exactly the same second, but still, anything busier than just the smallest of sites is likely to see a performance impact if their server's connection is only 10 Mbps.

100 Mbps is a lot better and might be fine for small sites at an average time during the day. We host servers for many clients though who burst past 100 Mbps on the servers and who would notice performance impact at these levels.

I mention "might" because there are additional factors. Like what happens if your site is medium sized and justifies running web and database services on two different machines? That means that not only do you have visitor traffic using the uplink port, but also the communication and data being transferred between the web and database server... and you want that connection to be fast because applications can slow down quickly if the database becomes a bottleneck.

At ORCS Web all of our servers have 1000 Mbps (gigE) uplink connections to our network core. This provides for excellent burst speeds as traffic increases on the servers, great low-latency connections between the web and database servers, and no network impact when our managed backups are running. Could we save some bandwidth costs with slower uplink speeds? Sure. Could we save some network costs with older equipment? Sure. But our focus is not on providing a "cheap" solution with potentially client-impacting shortcuts just to make more money. Our focus is on providing quality solutions at competitive rates. Our focus is on maximizing value for our clients and providing solutions that best meet their needs both short and long term as their businesses, and therefore their web sites and applications, grow over time.

What's your server's uplink speed?

This is a follow-up to a recent blog post titled "Managed Web Hosting - Compare Features and Services".

The announcement of a future release of Wifi supporting gigabit speeds has sparked some very interesting discussions here at ORCSWeb. Topics like this are constant reminders of just how technically geeky our team is. :-)

So, gig-wifi... what can we do? Well, maybe there is a future enterprise level implementation scenario? Imagine when speeds reach 10 gig - or more! Imagine a data center with no network cables! Imagine the built-in redundancy rather than physical multi-path switch deployments. Imagine the ease of deployment, changes, and other network maintenance items. Nice.

Also though imagine the Wifi band congestion. There would need to be a solution to allow a ton more traffic and data flow than current standards support. There would also need to be a solution to allow many more private networks to be supported in reasonable proximity without stepping all over each other and generating interference.

Security would be another topic to dig deeply into and address. I can picture a future enterprise Wifi feature though that combines current-day security like WEP or WPA with some built-in VPN-type features... sort of like VLAN'ing and encrypting the wireless connections.

Of course if we are eliminating cables, how about those pesky power cables. There are already some very interesting advancements in wireless power - just check out some of the results from searching "wireless power" in Google.

Well, you heard it here first folks. The data center of the future - cable-free.

I generally don't think of Verizon as a very cutting edge company. I give them a thumbs-up though for the new Verizon Hub product that they've made available.

The video phones buzz was a short fad and flopped. It seems many people don't want to be seen when making a call. (I don't :>)

"Internet phones" though perhaps? I'm not talking about VOIP, but turning the phone into an actual useful Internet device.

Verizon is selling their product as a central "hub" for a variety of things, which I think is pretty cool.

Cell phones can easily connect to the Internet now (CDMA, EVDO, 3G, etc.) - as could even "normal" home phones (DSL uses the same lines) and obviously VOIP can (connected to the Internet as a necessity).

Why not advance the physical phone part like Verizon has? Whip up a touch screen (I picture Microsoft Surface but many times smaller), give it a fairly simple interface (Vista but that actually works well?), add some basic features - multiple email account access, web browser, SMS, VOIP, caller id, contacts, calendar, grocery list (!) - and wow... that could be both a cool, and a very useful, product.

With the Internet-enabling of more and more devices, one thing is for sure: you better have an Internet presence. You want to be "available" to people anytime they get the inclination to look you up. And your website shouldn't be just some boring brochure-ware -> Make it useful. You should also make sure that your site is managed somewhere or by someone so that it can be both fault-tolerant and scale to handle heavy traffic as needed. If people have access to the Internet “all the time” then you and/or your company need to be available when requested… or it’s an easy step to jump over to a competitor’s site to purchase their product instead.

~Brad

More fun with PowerShell today! Today's script is a function, testIP, that accepts a string input and verifies whether it is a valid IPv4 address. Someday I will write one for IPv6, but I need to figure out how exactly those 128-bits worth of rules work. *shudders*

Let’s break it down, shall we? And, as usual, there may be better or perhaps built-in ways to do this. I’m not an expert programmer so doing stuff like this is a good learning experience for me, and may be helpful to someone down the line.

First let me define what $ValidIp is and what it does. This a Boolean variable used to validate and store the results of the tests. If at any point during the function a test fails, all of the following tests will simply not run. With a couple of foreach exceptions. In the end, $ValidIp, is used to return or output the result of the tests.

Test 1 is very simple. I use the split method of System.String to divide the string into parts, with a period (.) as the separator. The values are stored in an array named $crushIt. The if-statement then checks the length of the array (i.e. how many strings are in there). If that number is not 4, the number of octets in an IPv4 address, then the test fails and $ValidIp is changed to $False.

Test 2 is a wee bit more complex, as it checks to make sure each character entered is a number. First it runs a check to see if test 1 failed. If it hasn’t, then the script moves along. An array is built with the character values of the numbers 0-9, followed by a foreach loop which goes through every octect. I did it this way to make test 3 go smoothly.

$mashIt is created by converting the octet to a character array, another nifty method in System.String, and then sent through yet another foreach loop. Inside this loop each character is compared to the array storing the string values of the numbers 0-9. If any character doesn’t fit the mold the fashion show ends in tears and sorrow, $ValidIp is set to false and test 3 is summarily ignored (where the tears and sorrow come into play).

Test 3 is the easiest rule of them all. After checking whether $ValidIp is true or false, it converts the string value of the octet to an integer (if true that is). Remember, we already made sure only numbers are involved in test 2 so there will be no conversion errors here. I looked for an hour trying to figure out the convert command, only to discover you just have to save the string to an integer variable, by using [int] or [int32] before the variable name, and PowerShell does the conversion automagically. Well, technically .NET does it, but let’s not get too picky.

Once the conversion is done a very simple if-statement is run to see whether the value of the integer is less than zero or greater than 254. If that statement is false then $ValidIp is set to false. And now we’re done.

I know there are a lot of other tests that could be run, especially if subnet mask was added in the picture, but that’s not the purpose of this function. This is a very simple function to make sure a letter or extra number was not fat fingered into an IP range. The script I am building this for is adds IPs to a server, this function just makes sure the script doesn’t try to add IPs 192.168.1.2 through 192.168.1.2000 to the server and cause all sorts of fun and exciting errors.

If you are interested in data center advancements, and have a lot of time on your hands to read and digest a lot of content, you might want to check out this recent long blog post by someone in Microsoft's Global Foundation Services department.

http://loosebolts.wordpress.com/2008/12/02/our-vision-for-generation-4-modular-data-centers-one-way-of-getting-it-just-right/

The other day I came across something out of the ordinary.  After some major configuration changes to the server after a reboot it lost network connectivity.  After looking at the server from the console, the Local Area Connection was missing from Network Connections and I couldn't connect to it through RDC.  Checking system event viewer gave some information:

 4292 - The IPSec driver has entered Block mode. IPSec will discard all inbound and outbound TCP/IP network traffic that is not permitted by boot-time IPSec Policy exemptions. User Action: To restore full unsecured TCP/IP connectivity, disable the IPSec services, and then restart the computer.

32777 - The LSA was unable to register its RPC interface over the TCP/IP interface. Please make sure that the protocol is properly installed.

12291 - SAM failed to start the TCP/IP or SPX/IPX listening thread.

Well I took the advice of the first error, disabled the IPSec service, rebooted the server, and voila!  I was able to connect to the server.  However Local Area Connection was still not showing in Network Connections.  After some digging I found a solution:

Solution:  (This involves a direct registry edit.  Be very careful with changes that you make because incorrect changes could make your system unstable or inoperable) 

Go into services and find Remote Procedure Call (RPC) Service.  Change the account that it runs under to a Local System Account.

Open registry editor (regedit from a command prompt) and backup the following keys: