Posts Tagged 'Traceroute'

October 14, 2013

Product Spotlight: Vyatta Network Gateway Appliance

In the wake of our recent Vyatta network gateway appliance product launch, I thought I'd address some of the most common questions customers have asked me about the new offering. With inquiries spanning the spectrum from broad and general to detailed and specific, I might not be able to cover everything in this blog post, but at the very least, it should give a little more context for our new network gateway offering.

To begin, let's explore the simplest question I've been asked: "What is a network gateway?" A network gateway provides tools to manage traffic into and out of one or more VLANs (Virtual Local Area Networks). The network gateway serves a customer-configurable routing device that sits in front of designated VLANs. The servers in those VLANs route through the network gateway appliance as their first hop instead of Front-end Customer Routers (FCR) or Back-end Customer Routers (BCR). From an infrastructure perspective, SoftLayer's network gateway offering consists of a single server, and in the future, the offering will be expanded to multi-server configurations to support high availability needs and larger clustered configurations.

The general function of a network gateway may seem a little abstract, so let's look at a couple real world use cases to see how you can put that functionality to work in your own cloud environment.

Example 1: Complex Traffic Management
You have a multi-server cloud environment and a complex set of firewall rules that allow certain types of traffic to certain servers from specific addresses. Without a network gateway, you would need to configure multiple hardware and software firewalls throughout your topology and maintain multiple rules sets, but with the network gateway appliance, you streamline your configuration into a single point of control on both the public and private networks.

After you order a gateway appliance in the SoftLayer portal and configure which VLANs route through the appliance, the process of configuring the device is simple: You define your production, development and QA environments with distinct traffic rules, and the network gateway handles the traffic segmentation. If you wanted to create your own VPN to connect your hosted environment to your office or in-house data center, that configuration is quick and easy as well. The high-touch challenge of managing several sets of network rules across multiple devices is simplified and streamlined.

Example 2: Creating a Static NAT
You want to create a static NAT (Network Address Translation) so that you can direct traffic through a public IP address to an internal IP address. With the IPv4 address pool dwindling and new allocations being harder to come by, this configuration is becoming extremely popular to accommodate users who can't yet reach IPv6 addresses. This challenge would normally require a significant level of effort of even the most seasoned systems administrator, but with the gateway appliance, it's a painless process.

In addition to the IPv4 address-saving benefits, your static NAT adds a layer of protection for your internal web servers from the public network, and as we discussed in the first example, your gateway device also serves as a single configuration point for both inbound and outbound firewall rules.

If you have complex network-related needs, and you want granular control of the traffic to and from your servers, a gateway appliance might be the perfect tool for you. You get the control you want and save yourself a significant amount of time and effort configuring and tweaking your environment on-the-fly. You can terminate IPSec VPN tunnels, execute your own network address translation, and run diagnostic commands such as traffic monitoring (tcpdump) on your global environment. And in addition to that, your gateway serves as a single point of contact to configure sophisticated firewall rules!

If you want to learn more about the gateway appliance, check out KnowledgeLayer or contact our friendly sales team directly with your questions:


December 5, 2011

Quick Tip: Copy and Paste from the DOS Prompt

Having worked in SoftLayer's technical support department for a few years now, I can tell you that the more information you provide us, the faster we can get you to a resolution. If you can show us exactly the problem you're seeing with details from when you see it, it's much easier for us to troubleshoot, so I wanted to post a quick blog on the heels of Todd's "Global Network: The Proof is in the Traceroute" post to help you get information to us much more easily.

Document Format
Many people consider a Microsoft Word document the lowest common denominator when it comes to formatting an attachment or file while others prefer plain text for everything. I always advocate the use of plain text. Plain text is universally accessible, it doesn't require a third-party application to view, it doesn't add funky encoding, and it uses monospaced fonts that format the text like you'd see in a command prompt if you were sharing troubleshooting results from ping and traceroute commands. It's quite unnecessary to take a screen capture of a ping or traceroute when you run it, and it's doubly unnecessary to paste that screen capture into a Microsoft Word document.

Copying Your Ping/Traceroute
The problem many Windows users run into is that it's not very clear how to copy text from the command prompt ... The familiar keyboard shortcuts for copying (CTRL+C) and pasting (CTRL+V) don't work from the DOS Prompt, so the screen capture route is usually the easiest to execute. There is an easy way to copy, though.

Microsoft documented the instructions you need, and I wanted to share them with SoftLayer customers here:

  1. Open the command prompt. If you're unsure how to do this, open the Start Menu, click Run, enter "cmd" (without the quotes) and click OK.
  2. Execute your command. Use "tracert" to follow along with this test.
  3. Right-click the title bar of the command prompt window, point to Edit, and then click Mark.
  4. Click the beginning of the text you want to copy.
  5. Press and hold down the SHIFT key, and then click the end of the text you want to copy (or you can click and drag the cursor to select the text).
  6. Right-click the title bar, point to Edit, and then click Copy.

Now the text is in the clipboard. You can paste it anywhere, including the body of a ticket. To preserve layout, I usually paste the text in Notepad and attach that file to the ticket. If you don't want to go through the hassle of opening Notepad, just paste the results into the comment field below.

If you enjoy reading quick tips like this one that can make life easier, be sure to check out KnowledgeLayer.


Bonus tip: If you want to submit your traceroute in a comment on this blog without losing the mono-spaced formatting, surround the pasted content with the <code> and </code> tags.

December 2, 2011

Global Network: The Proof is in the Traceroute

You've probably heard a lot about SoftLayer's global expansion into Asia and Europe, and while the idea of geographically diversifying is impressive in itself, one of the most significant implications of our international expansion is what it's done for the SoftLayer Network.

As George explained in "Globalization and Hosting: The World Wide Web is Flat," our strategic objective is to get a network point of presence within 40ms of all of our users and our users' users to provide the best network stability and performance possible anywhere on the planet. The reasoning is simple: The sooner a user gets on on our network, the quicker we can efficiently route them through our points of presence to a server in one of our data centers.

The cynics in the audience are probably yawning and shrugging that idea off as marketing mumbo jumbo, so I thought it would be good to demonstrate how the network expansion immediately and measurably improved our customers' network experience from Asia to the United States. Just look at the traceroutes.

As you're probably aware, a traceroute shows the "hops" or routers along the network path from an origin IP to a destination IP. When we were building out the Singapore data center (before the network points of presence were turned up in Asia), I ran a traceroute from Singapore to, and immediately after the launch of the data center, I ran another one:

Pre-Launch Traceroute to from Singapore

traceroute to (, 64 hops max, 52 byte packets
 1 (  1.884 ms  1.089 ms  1.569 ms
 2 (  2.006 ms  1.669 ms  1.753 ms
 3 (  3.380 ms  3.388 ms  4.344 ms
 4 (  3.684 ms  3.348 ms  3.919 ms
 5 (  9.002 ms  3.516 ms  4.228 ms
 6 (  3.716 ms  3.965 ms  5.663 ms
 7 (  4.442 ms  4.117 ms  4.967 ms
 8 (  6.807 ms  55.288 ms  56.211 ms
 9 (  187.953 ms  188.447 ms  187.809 ms
10 (  184.143 ms (  189.510 ms (  289.039 ms
11 (  187.645 ms  188.700 ms  187.912 ms
12 (  186.482 ms  188.265 ms  187.021 ms
13 (  188.569 ms  191.100 ms  188.736 ms
14 (  381.645 ms  410.052 ms  420.311 ms
15 (  415.379 ms  415.902 ms  418.339 ms
16 (  417.426 ms  417.301 ms (  416.692 ms
17  * * *

Post-Launch Traceroute to from Singapore

traceroute to (, 64 hops max, 52 byte packets
 1 (  2.850 ms  1.409 ms  1.206 ms
 2 (  1.550 ms  1.680 ms  1.394 ms
 3 (  1.812 ms  1.341 ms  1.734 ms
 4 (  35.550 ms  1.999 ms  2.124 ms
 5 (  174.726 ms  175.484 ms  175.491 ms
 6 (  203.821 ms  203.749 ms  205.803 ms
 7 (  306.755 ms (  208.669 ms  203.127 ms
 8 (  203.518 ms (  305.534 ms (  204.150 ms
 9  * * *

I won't dive too deep into what these traceroutes are telling us because that'll need to be an entirely different blog. What I want to draw your attention to are a few key differences between the pre- and post-launch traceroutes:

  • Getting onto SoftLayer's network:. The first reference to "networklayer" in the pre-launch trace is in hop 12 (~187ms). In the post-launch trace, we were on "networklayer" in the second hop (~1.5ms).
  • Number of hops: Pre-launch, our network path took 16 hops to get to Post-launch, it took 8.
  • Response times from the destination: The average response time from to Singapore before the launch of our network points of presence in Asia was about 417ms (milliseconds). After the launch, it dropped to an average of about ~250ms.

These traceroutes demonstrate that users in Singapore travel a much better network path to a server in one of our U.S. data centers than they had before we turned up the network in Asia, and that experience isn't limited to users in Singapore ... users throughout Europe and Asia will see fewer hops and better speeds now that the data centers and points of presence on those continents are live. And that's without buying a server in either of those markets or making any changes to how they interact with us.

Managing a worldwide network for a worldwide customer base with thousands of different ISPs and millions of possible routes is not a "set it and forget it" endeavor, so we have a team of engineers in our Network Operations Center that focuses on tweaking and optimizing routes 24x7. Branching out into Europe and Asia introduces a slew of challenges when working with providers on the other side of the globe, but I guess it's true: "If it were easy, everyone would do it."

Innovate or die.


Subscribe to traceroute