Armada Data Solutions

A successful 2013 St. Baldricks

Kelly — Fri, 15 Mar 2013 15:47:24 +0000

For the third year Armada Data Solutions has chosen to sponsor St. Baldrick’s Foundation as a part of our Community Involvement program. This year the team raised $25,353 to help fund children’s cancer research.

In addition to finding cures, a lot of research is focused on preventing the lifelong damage that results from surgeries, radiation and chemotherapies given while young bodies and brains are just developing. Even during treatment, kids face all kinds of side effects, some very uncomfortable, others life-threatening. That’s why St. Baldrick’s also funds research to improve supportive care for patients.

Armada Data Solutions raises funds in honor of Courtney Hicks, a 11 year old girl, battling a rare Medulloblastoma brain tumor. To read Courtney’s story and to learn more about the Foundation, visit Armada’s Community Involvement page.

Our best give away yet!

Kelly — Thu, 17 Jan 2013 16:39:07 +0000

If you are not signed up for our newsletter you should sign up now! Our newsletter is a fun an informative way to see what Armada is doing, what is going on in our community and trending in the market. Our January newsletter kicks off the year with a give away.

We have all made the New Year’s resolution to get into shape. Armada wants to help by giving away a cool gadget to help you stay on track and achieve your fitness goals. If you sign up for our news letter you are entered to win a Nike+ Fuelband. The Fuelband has a sports-tested accelerometer, that tracks your daily activity including running, walking, basketball, dancing and dozens of everyday activities. It tracks each step taken and calorie burned. It also tells the time of day. To read more about the Nike+ Fuelband and all its features click here.

We will announce the winner February 28th!

* link

St.Baldrick’s is back!

Kelly — Wed, 16 Jan 2013 17:14:57 +0000

Third time is a charm. It’s That Time of Year Again to . . . Get Bald!

Armada Data Solutions has chosen (for the third consecutive year) the St. Baldrick’s Foundation to sponsor as a part of our Community Involvement program. St. Baldrick’s Foundation is a volunteer-driven charity committed to funding the most promising research to find cures for childhood cancers and give survivors long and healthy lives.

Continuing to build awareness and raise funds for St. Baldrick’s Foundation, Armada’s own Paul Turner and Eric Davis have joined a local St. Baldrick’s team to raise funds and shave their heads! Armada Data Solutions will be raising funds in honor of Courtney Hicks, a 11 year old girl, battling a rare Medulloblastoma brain tumor.

To read Courtney’s story and to learn more about the Foundation, visit Armada’s Community Involvement page.

Click on the shamrocks below to see Paul & Eric’s progress, as well as to make a donation to this worthy cause.

Paul Turner- to help Paul meet his goal, click the BLUE shamrock to make a donation

Eric Davis-to help Eric meet his goal, click the GREEN shamrock to make a donation

(Almost) Everything You Wanted to Know About Traceroute, But Were Afraid to Ask…

Kelly — Mon, 26 Nov 2012 03:31:52 +0000

Throughout my career in networking I have stumbled upon the widespread misconception of how the traceroute tool actually works amongst persons that frequently use the tool. I do know in the beginning, traceroute used ICMP echo requests for functionality, however not all routers or network devices responded properly to these requests and therefore made the tool unreliable, so maybe that’s where the confusion began.

Traceroute on most platforms use UDP Packets primarily and “exploits” the ICMP messaging function for functionality by manipulating the TTL (Time To Live) field in the IP Header. The use of traceroute enables us to see the network paths taken by packets from a source machine to a destination device and also if there are any network abnormalities in between. Understanding how this works correctly is essential to troubleshooting.

The source device executing the traceroute command follows, essentially, the following steps under default conditions:

1. 3 UDP packets are generated, usually somewhere in the 33,000 port range, with the TTL field set to 0 or 1 to a destination address. Three packets are sent to determine if different network routes are taken for each packet sent to indicate a possible network issue, or if the same route is taken for all 3.

2. A time stamp is made on the source system as to when the packets were sent on the wire.

3. The next hop network device, assumed to be a routing device, receives the 3 UDP packets and sees the TTL set to 0 or 1.

4. This device will decrement the TTL if possible and since the initial TTL is set low, will discard the packet and generate an ICMP Message Type 11/Code 0 (Time to Live Count Exceeded) back to the originating device for all 3 packets.

5. The originating device receives the ICMP message from the gateway, makes a note of the time each packet was received (round trip time) and the sending device IP or FQDN, then displays something like the following. Notice the 3 time entries as “<1ms”

Tracing route to www.google.com [74.125.134.99] over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1

6. Now, the source machine will then send 3 identical packets to the first, except that the TTL field is incremented by 1 as well as the destination port, so let’s say TTL is set to 2 in this instance. Time sent is noted when the packets are dumped on the wire.

7. This time, the next hop receives the packets as it did before, decrements the TTL counter by 1 leaving TTL set now to 1 and now forwards these on to its destination gateway.

8. The second network device receives the 3 packets and just like the first time around, decrements the TTL counter by 1, sees TTL as a big “0”, discards the packet and sends and ICMP message (11/0) back to the originating device (the source, not the previous gateway). Notice again the 3 time stamps and the sending device IP.

Tracing route to www.google.com [74.125.134.99] over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1

2 29 ms 28 ms 25 ms 50.129.150.1

This process continues through all network devices by incrementing the TTL until the end device is reached. Once the end device is reached, and presumably NOT listening on the ephemeral UDP port (34,456 for instance) used by traceroute, the end device will discard the UDP Packet and return an ICMP packet Code 3 Type 3 (Destination Port Unreachable)

When the source device receives this 3/3 ICMP message, the traceroute application determines it has in fact arrived at the destination device and will display the following, or something like it:

Tracing route to www.google.com [74.125.137.106] over a maximum of 30 hops:

1 2 ms 2 ms <1 ms 192.168.1.1

2 24 ms 29 ms 28 ms 50.129.150.1

3 11 ms 11 ms 11 ms te-2-8-ur01.elkhart.in.sbend.comcast.net [69.139.173.153]

4 10 ms 11 ms 12 ms te-6-1-ur03.mishawaka.in.sbend.comcast.net [68.87.235.5]

5 20 ms 18 ms 16 ms te-1-7-0-5-ar01.area4.il.chicago.comcast.net [68.87.235.17]

6 19 ms 23 ms 18 ms pos-3-11-0-0-cr01.350ecermak.il.ibone.comcast.net [68.86.90.13]

7 17 ms 16 ms 18 ms pos-1-5-0-0-pe01.350ecermak.il.ibone.comcast.net [68.86.87.126]

8 16 ms 16 ms 15 ms 66.208.228.202

9 14 ms 20 ms 16 ms 209.85.254.120

10 48 ms 22 ms 16 ms 72.14.237.133

11 41 ms 41 ms 42 ms 72.14.239.90

12 47 ms 42 ms 41 ms 209.85.248.31

13 * * * Request timed out.

14 41 ms 44 ms 43 ms yh-in-f106.1e100.net [74.125.137.106]

Trace complete.

A few items of note from this output;

1. The IP 74.125.137.106 is noted as the “trace to” destination at the top of the output and the last entry in the trace…a successful trace.

2. Line 13 indicates a device, like a firewall, that is not configured to respond to traceroute

3. Line 10 indicates to me that Comcast is once again having network issues (GASP!) since the RTT time for the first packet is nearly double the second and 3 times the 3^rd packet. (I in fact had to reboot my router while typing this). Not that this indicates anything terribly wrong, but is an indicator of high latency outside of my network.

The “*” indicates an ICMP packet was not received from a given destination because it was dropped, discarded by another device or there are network issues preventing the successful return of the ICMP packets.

Running subsequent traceroutes to the same destination should provide similar if not identical results. If not, this tool provides a good indicator of where the network issues may lie.

IT Preparedness: Lessons Learned From Natural Disasters

Kelly — Tue, 11 Sep 2012 01:39:39 +0000

With Hurricane Isaac hitting the Southeastern coast recently on the anniversary of Katrina, it brings to mind images of preparedness (or lack thereof) and how it affects our lives and businesses. As these events can have a dramatic impact on both, there are two business-oriented stories that come to mind that occurred during the devastation. Each is about a company that was/is affected by the storms but with very different endings.

Company A has locations throughout the region that lost power and incurred flooding including a key data center. While they had a Disaster Recovery plan, it had not been fully developed and did not incorporate the regional sites but just the data center. To add insult to injury, the data center also incurred issues which left critical services severely degraded for a period of time with no access to resolve them. The end result was scrambling to figure out how to ‘react’ to the large scale impact to the organization. They were unable to serve their customers while still working through how best to get their employees back to work.

Company B also has locations through the affected areas however had fully developed and validated a plan to handle events such as this. In this case, they did not have to ‘react’, they simply executed a well-developed plan which worked without any major issues including employee remote access to systems and how they were to re-open these locations for business immediately following the event.

It is not uncommon for the expense incurred for cleanup after an event such as Company A experienced will be multiple times more costly than if planned and executed effectively up front. One of the many lessons that can be taken from this is that properly preparing for any event; whether a disaster, a change in the environment, or new addition, doing it right the first time pays dividends when you need it most.

- JJ Crump, CTO/Chief Solutions Architect