April 2011 - TBL Networks

Patrick Tredway at Virginia’s Region 2000 Technology Council’s “Wired Wednesday” – April 27th

Posted on April 21, 2011 by Steve Glissman

TBL Network’s Patrick Tredway will be featured as a panelist at Virginia’s Region 2000 Technology Council’s upcoming “Wired Wednesday” luncheon on Wednesday, April 27^th in Lynchburg, Virginia. The topic for the panel is “Mobile Computing For Business & Education.”

The event and presentation will include:

Pros & Cons of handheld devices/phones…Android vs. iPhone vs. Blackberry.
The rising use of tablet PCs.
How tablet PCs can integrate into your IT plan/work environment.
A look at the various players in the tablet PCs market.
Hands-on demonstration of tablet PCs in a work environment.

Patrick Tredway is co-owner for TBL Networks, and is TBL’s Collaboration Practice Lead and Account Engineer. Patrick is a CCIE Voice certified engineer and has been working with Cisco Unified Communications since 2002 as an end customer, integrator and consultant.

A proud member of Virginia’s Region 2000 Partnership, Virginia’s Region 2000 Technology Council’s mission is to foster an environment that stimulates innovation and growth of technology-focused organizations in our community.

Where: City of Lynchburg Information Technology Center | 3150 Young Place Lynchburg, VA 24501 (NOTE: different location)
When: April 27, 2011, noon until 1:30 p.m.
Cost: $10 for Tech Council Members, $15 for non-members

For additional information about the event, please go to http://www.techcouncil.us/news-events/wired-wednesday-mobile-computing-for-business-and-education-april-27/

Ask Harley: Guitar Hero Edition

Posted on April 14, 2011 by Steve Glissman

Harley Stagner knows virtualization. He’s the first person in the Commonwealth of Virginia to receive the title of VMware Certified Design Expert (VCDX), and just the 46^th person worldwide to earn this elite certification. From ESXi to VDI, public cloud to private cloud, virtual machines to virtual networks, Harley Stagner is the man when it comes to virtualization and VMware.

But what about Harley’s other talents? Just because he is TBL Networks’ resident expert on VMware, it doesn’t mean that Harley’s skills end at the network server.

On May 5th, we plan to show one more of the many sides of Mr. Stagner with “Ask Harley: Guitar Hero Edition.”

On Thursday, May 5th, starting at 7PM , Harley will answer your questions about virtualization live on Twitter. Following this presentation, Harley and his band, the 46ers, will play the song of your choice from Guitar Hero: World Tour – LIVE ON THE INTERNET.

To participate, you need to do just three things:

1) SUBMIT YOUR VIRTULIZATION QUESTION

You can submit your questions three simple ways:

Twitter – Post your questions on Twitter and tag with #AskHarley.
Email – Send your questions to twitter@tblnetworks.com.
Facebook – Post your question on the Wall at www.facebook.com/tblnetworks.

To ensure that Harley has adequate time to review your questions, please submit them by end of business on Wednesday, May 4th.

2) VOTE ON A SONG

To vote on a song, go to www.facebook.com/tblnetworks and vote on the Poll.

3) GO TO WWW.TWITTER.COM/TBLNETWORKS ON MAY 5th, AT 7PM EST

Once Harley has finished answering your questions on Virtualization, the 46ers will hit the virtual stage and rock your world.

If you want to know more about virtualization, ask Harley, and then prepare to be rocked.

End to end virtual network security with the Cisco Nexus VSG

Posted on April 11, 2011February 11, 2019 by admin

So I’ve been spending a lot of time in our lab with the Cisco Nexus Virtual Security Gateway. I have come to the conclusion that it rocks! Finally, the virtual infrastructure is no longer treated as a second class citizen when it comes to securing network traffic between virtual machines. We are at a point now with the Cisco VSG that we can have robust Cisco infrastructure, including security, from the upstream physical network to the virtual network.

The Cisco Nexus VSG builds upon the Nexus 1000v distributed virtual switch and communicates with the Virtual Ethernet Modules in the Nexus 1000v to provide a very robust security policy engine that can perform granular filtering and matching on a number of parameters. For example:

Network (ip address, port number, etc.)
VM (VM Name, Installed OS Name, Cluster, Host, Zone)

Yep, that’s right, I said VM. Since the Cisco VSG integrates with the vSphere API’s and vCenter, you can filter on items like a virtual machine name or partial name, installed OS, cluster, etc. This is very powerful. I no longer have to rely on network and IP rules alone to filter traffic between virtual machines. This is a more intelligent approach to filtering that really highlights the synergies that Cisco and VMware have established. Best of all, once it is set up everything is managed from a single Cisco Virtual Network Management Center (VNMC) instance. This web-based management tool let’s you manage multiple Virtual Security Gateway instances. Let’s look at a simple example of how easy it is to perform traffic filtering in the virtual infrastructure with the Cisco VSG.

Topology and Components:

vSphere 4.1 Enterprise Plus Host Servers
Cisco VNMC VM
Cisco Nexus 1000v Infrastructure
Cisco VSG Infrastructure
tenanta-srv1 VM
tenanta-srv2 VM
tenantb-srv1 VM
tenantb-srv2 VM

The goal of this configuration is to allow the following communication flows:

tenanta-srv1 and tenanta-srv2 should communicate
tenantb-srv1 and tenantb-srv2 should communicate
The Tenant A servers(tenanta-srv1 and tenanta-srv2) should not be able to communicate with the Tenant B servers (tenantb-srv1 and tenantb-srv2)
Anyone else should be able to communicate with both the Tenant A and Tenant B servers
There is a further caveat that the Tenant A and Tenant B servers are both on the same subnet (don’t worry these servers belong to the same company )

Below are the network settings:

tenanta-srv1 VM – 10.91.41.200
tenanta-srv2 VM – 10.91.41.201
tenantb-srv1 VM – 10.91.41.202
tenantb-srv2 VM – 10.91.41.203
a client with another ip address

Here are the general steps for setting up this scenario once the Cisco VSG infrastructure is in place:

Create a tenant
Assign the VSG to the tenant
Create a zone each for the Tenant A and Tenant B servers (these zones match VM’s with names that contain “tenanta” and “tenantb” respectively)
Create a firewall policy for the VSG
Create a policy set that includes the policy
Bind the policy set to the VSG
Bind the tenant to a port-profile so that any VM that is on that port-profile is filtered with the policy rules

Below are the screenshots of the results after the VSG was configured.

These are the only rules that are required for the communication flows.

Here is what the port-profile looks like on the Nexus 1000v. Notice the org and vn-service entries. This means that this port profile is VSG aware.

The ICMP traffic from the Tenant A Servers.

The ICMP traffic from the Tenant B Servers (same result as the Tenant A servers. Only one is shown here.)

Finally the results from the external client

As you can see, we achieved our goal with just three filtering rules. Also, we were able to leverage VM name filtering instead of IP filtering which allowed us to filter on the same subnet without resorting to naming each IP address or different port numbers. Very cool! The Cisco VSG is capable of many complex configurations combining both networking categories (ip, port number, etc.) and VM categories. This was just a quick example of what can be done. As always, if you have any questions or would like to see a live demo feel free to contact me.

SIP – Are you ready?

Posted on April 4, 2011 by Patrick Tredway

If you haven’t heard yet, there’s a new kid on the block as it relates to connecting dial tone to your phone switch. Nearly all of the traditional service providers (and even some new ones) have come up with some sort of SIP offering for PSTN connectivity. However, seeing as the technology is still in an embryonic stage when compared to its ISDN forefathers, each service provider seems to have their own little tweaks to SIP delivery.

Now, not every PBX or phone switch out there is ready to support SIP dial tone…which, in my opinion, should be the second thing you investigate. The first and most important question to ask is “What does SIP offer to my company that traditional TDM based dial tone does not?”

To illustrate this important point, let’s go back a few years – the birth of VoIP. Back in those days, a little more than a decade ago now, Cisco led the charge in converging TDM based voice technologies onto a packetized, often IP driven, data networks. In doing so, we all became ever so aware of some of the risks and more importantly the risk mitigation techniques needed to be employed to make the conversion plausible. While we got the benefit of toll bypass, we picked up the responsibility of assuring an even level of service to RTP streams across our wide area network – quality of service (QoS). While we assumed all the advantages of a single PBX instance for an entire enterprise, we acquired the responsibility for providing local call processing for a remote site when a network failure occurs.
Some had to learn these lessons through hard knocks. So, my question is to you, how will you learn from history and avoid being doomed to repeat it? I have a few suggestions…

Start with a solid business case (or lack thereof) for a SIP rollout. From my position, I see two strong cases:
a. Cost Savings – I have a few clients who have multiple remote sites that require PRIs for functional reasons, but may not have the usage requirements to support 23 bearer channels. A regional bank is probably the best illustration of this. While a bank branch may need DID, DNIS, addressable CLID functionality, they typically will have fewer than 3 or 4 concurrent calls during any period of the work day. So in this case, if we can bring those 3 or 4 talk paths onto a data circuit and relieve the cost of the PRI loop, we can save some money.

b. Disaster Recovery – This is a big one. When you have a site or a remote PBX go down, you have few options to get those numbers re-routed to another site and avoid the “All circuits are busy” message being played repeatedly to your customers. At best, you can call your service provider and request an emergency call forward on a few numbers which typically gets put in place within a few hours – just in time for your circuit to come back online…wash, rinse, repeat. With SIP, most carriers allow for backup IP addressing for where a call is delivered to your network. This gives us the flexibility to offer at least one other point of entry to the network for those numbers…without having to call a soul.
TEST, TEST, TEST and then TEST some more. Seeing as most of these service offerings come from providers who are already offering you data services today, it stands to reason that you could have a few test numbers lit up and use those to test. Some key items you will want to watch out for – voice quality, DTMF exchange (call into an IVR), call forwarding and outbound CLID preservation. Once you think everything is working fine, port a few DIDs for a few users. Nothing says you need to cut an entire site or even a heavily used number the first time.

Pick a good partner. SIP cutovers don’t always go as smoothly as you might like. You’ll want to have a partner who has done a number of these cuts before and is adamant about having a solid reversion plan. If you’re having trouble finding one, give me a call…I should have a recommendation or two.