Home Lab Server

Currently I’m doing a lot of testing at home on Network Virtualization solutions, like VMware NSX, Juniper Contrail, etc. Therefore I was stressing my current single home server quite a lot. Which is a custom build Xeon E3-1230 quad core with 32GB of RAM and 128GB SSD. I built this server according to the specifications found at: http://packetpushers.net/vmware-vcdx-lab-the-hardware/ . This has been a great investment as I’m running nested virtualization for both KVM and ESXi hypervisors and run the testing in there. Due to the fact that for a decent Network Virtualization (NV) set-up you need quite some memory, especially if you look at the memory utilisation of the NV Controller VMs, I had to expand my lab. I chose to extend it with an additional server so I would be physically redundant as well, making it easier to run upgrades on the physical machines.

Requirements

My requirements aren’t difficult as I mainly perform feature testing in my lab I don’t need a lot of CPU performance. There are no “Production” VMs running, everything is there to play around, so downtime is not a problem if necessary.
Other requirements:

• Average CPU performance
• Nested virtualization support
• At least 32GB of Continue reading

Accelerating Open vSwitch to “Ludicrous Speed”

[This post was written by OVS core contributors Justin Pettit, Ben Pfaff, and Ethan Jackson.]

The overhead associated with vSwitches has been a hotly debated topic in the networking community. In this blog post, we show how recent changes to OVS have elevated its performance to be on par with the native Linux bridge. Furthermore, CPU utilization of OVS in realistic scenarios can be up to 8x below that of the Linux bridge.  This is the first of a two-part series.  In the next post, we take a peek at the design and performance of the forthcoming port to DPDK, which bypasses the kernel entirely to gain impressive performance.

Open vSwitch is the most popular network back-end for OpenStack deployments and widely accepted as the de facto standard OpenFlow implementation.  Open vSwitch development initially had a narrow focus — supporting novel features necessary for advanced applications such as network virtualization.  However, as we gained experience with production deployments, it became clear these initial goals were not sufficient.  For Open vSwitch to be successful, it not only must be highly programmable and general, it must also be blazingly fast.  For the past several years, our development efforts have focused on Continue reading

Dell Open Networking Switches Now Run Big Switch’s SDN Fabric Software

Accurate Dependency Mapping – One Day?

Recently I’ve been thinking about Root Cause Analysis (RCA), and how it’s not perfect, but there may be hope for the future.

The challenge is that Automated RCA needs an accurate, complete picture of how everything connects together to work well. You need to know all the dependencies between networks, storage, servers, applications, etc. If you have a full dependency mapping, you can start to figure out what the underlying cause of a fault is, or you can start doing ‘What If?’ scenario planning.

But once your network gets past a moderate size, it’s hard to maintain this sort of dependency mapping. Manual methods break down, and we look for automated means instead – but they have gaps and limitations.

Automated Mapping – Approaches & Limitations

Tools such as HP’s CMS suite attempt to discover all objects and dependencies using a combination of network scanning and agents. They’ll use things like ping, SNMP, WMI, nmap to identify systems and running services. Agents can then report more data about installed applications, configurations, etc.

Network sniffing can also be used to identify traffic flows. Most tools will also connect to common orchestration points, such as vCenter, or the AWS console, to Continue reading

Ansible Tower Webinar

We have an Ansible Tower webinar scheduled for next week.

This webinar will provide an example of how Ansible Tower allows you to centralize your Ansible infrastructure from a modern UI, featuring role-based access control, job scheduling, and graphical inventory management. Tower's REST API and CLI make it easy to embed Tower into existing tools and processes.

Tower now includes real-time output of playbook runs, an all-new dashboard and expanded out-of-the-box cloud support. 

Sign-up today

Does the Internet need “Governance”?

Dave Reed just published concerning network neutrality. Everyone interested in the topic should  carefully read and understand  Does the Internet need “Governance”?

One additional example of “light touch” help for the Internet where government may play a role is transparency: the recent MLAB’s report and the fact that Cogent’s actions caused retail ISP’s to look very badly is a case in point. You can follow up on that topic on the MLabs’s mailing list, if you are so inclined. If a carrier can arbitrarily delay/deprioritize traffic in secret, then the market (as there are usually alternatives in transit providers) cannot function well. And if that provider is an effective monopoly for many paths, that becomes a huge problem.

Show 211 – Should IT Engineers Get Fired For Production-Impacting Mistakes?

First off, apologies for the serialization error. We know, the last show was #212 in the title but #211 on the filename, when it should have been #211 through and through. We get it, and we’re very sorry, especially to you OCD folks who are twitching uncontrollably right now. Don’t fire us. Why didn’t we […]

Author information

Ethan Banks

Co-host at Packet Pushers

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks

TwitterGoogle+LinkedIn

The post Show 211 – Should IT Engineers Get Fired For Production-Impacting Mistakes? appeared first on Packet Pushers Podcast and was written by Ethan Banks.

“On the fly” IPsec VPN with iproute2

Vagrant – Overview and Opendaylight Vagrant Image

How Marketers Use Social Media Evilly

Load balanced ESXi cluster with Host memory usage alarm

Using Schprokits to Automate Big Switch’s Big Cloud Fabric

Goodbye Lync, Hello “Skype for Business”

Microsoft Lync, perhaps the most well known business communication and collaboration tools, is getting a new name in 2015. The next version of Microsoft Lync, according to the Lync Team on Microsoft’s Office Blog will be called “Skype for Business.”

In other news, the next version of iTunes will be called “Napster for People With Credit Cards” and we’ll also hear from Cisco about the now-defunct plans they made five years ago to rebrand themselves as “Linksys Plus for Data Center.”

First, and most importantly, Microsoft’s Marketing Department is ahead of the game and producing videos that explain all you need to know about this new product.

Insert Emotive but Factually Lacking Video

So here it is; all you need to know:

I feel all warm and fuzzy about this new electronic communication paradigm optimizing and synergizing all the information flows in my business! Let’s check out those key changesimprovements:

“We’re really excited about how Skype for Business takes advantage of the strengths of both Skype and Lync. For example, as you can see in the screenshots, we’re adopting the familiar Skype icons for calling, adding video and ending a call.”

Icons. Icons are one of Skype’s Continue reading

Goodbye Lync, Hello “Skype for Business”

Microsoft Lync, perhaps the most well known business communication and collaboration tools, is getting a new name in 2015. The next version of Microsoft Lync, according to the Lync Team on Microsoft’s Office Blog will be called “Skype for Business.” … Continue reading →

If you liked this post, please do click through to the source at Goodbye Lync, Hello “Skype for Business” and give me a share/like. Thank you!

Use Protection if Peering Promiscuously

Last week, I wrote a blog post discussing the dangers of BGP routing leaks between peers, illustrating the problem using examples of recent snafus between China Telecom and Russia’s Vimpelcom.  This follow-up blog post provides three additional examples of misbehaving peers and further demonstrates the impact unmonitored routes can have on Internet performance and security.  Without monitoring, you are essentially trusting everyone on the Internet to route your traffic appropriately.

In the first two cases, an ISP globally announced routes from one of its peers, effectively inserting itself into the path of the peer’s international communications (i.e., becoming a transit provider rather than remaining a peer) for days on end.  The third example looks back at the China Telecom routing leak of April 2010 to see how a US academic backbone network prioritized bogus routes from one of its peers, China Telecom, to (briefly) redirect traffic from many US universities through China.

Recap: How this works

To recap the explanation from the previous blog (and to reuse the neat animations our graphics folks made), we first note that ISPs form settlement-free direct connections (peering) in order to save on the cost of sending Continue reading

The requirements for IT’s Third Platform

With the blurring of technology lines, the rise of competitive companies, and a shift in buying models all before us, it would appear we are at the cusp of ushering in the next era in IT—the Third Platform Era. But as with the other transitions, it is not the technology or the vendors that trigger a change in buying patterns. There must be fundamental shifts in buying behavior driven by business objectives.

The IT industry at large is in the midst of a massive rewrite of key business applications in response to two technology trends: the proliferation of data (read: Big Data) and the need for additional performance and scale. In many regards, the first begets the second. As data becomes more available—via traditional datacenters, and both public and private cloud environments—applications look to use that data, which means the applications themselves have to go through an evolution to account for the scale and performance required.

Scale up or scale out?

When the industry talks about scale, people typically trot out Moore’s Law to explain how capacity doubles every 18 months. Strictly speaking, Moore’s Law is more principle than law, and it was initially applied to the number of transistors Continue reading

Network Design Concepts Part-3

In the first article of the series, reliability and resiliency are covered. We should know that whatever device, link type or software you choose eventually they will fail. Thus designing resilient system is one of the most critical aspects of IT. I mentioned that one way of providing resiliency is redundancy. If we have redundant […]

Author information

Orhan Ergun

Orhan Ergun, CCIE, CCDE, is a network architect mostly focused on service providers, data centers, virtualization and security.

He has more than 10 years in IT, and has worked on many network design and deployment projects. Orhan works as a freelance network instructor, for training you can add ' Orhan Ergun ' on skype.

In addition, Orhan is a:
Blogger at Network Computing.
Blogger and podcaster at Packet Pushers.
Manager of Google CCDE Group.
On Twitter @OrhanErgunCCDE
https://www.linkedin.com/in/orhanergun

TwitterLinkedIn

The post Network Design Concepts Part-3 appeared first on Packet Pushers Podcast and was written by Orhan Ergun.

Scaling the Cloud Security Groups

Most overlay virtual networking and cloud orchestration products support security groups – more-or-less-statefulish ACLs inserted between VM NIC and virtual switch.

The lure of security groups is obvious: if you’re willing to change your network security paradigm, you can stop thinking in subnets and focus on specifying who can exchange what traffic (usually specified as TCP/UDP port#) with whom.

Using Schprokits to Automate Big Switch’s Big Cloud Fabric

I gave a presentation at Interop last month and tried to make two major points about network automation. One, network automation is so much more than just “pushing configs” and two, network automation is still relevant in Software Defined Network environments that have a controller deployed as part of the overall solution. And I’m referring to controllers from ANY vendor including, but definitely not limited to Cisco’s APIC, NSX Controllers, Nuage Controller/Director, Juniper Contrail, Plexxi Control, OpenDaylight, and Big Switch’s Big Cloud Fabric.

A few months ago, I was at Network Field Day 8 and got to see a live demo of Big Switch’s newly released Big Cloud Fabric solution. It seemed slick, but I was curious on automating the fabric using the northbound APIs exposed from their controller. As it turns out, I was able to get access to a small fabric (2 leafs / 2 spines) to get familiar with Big Cloud Fabric. In parallel to that, I started testing Schprokits as I mentioned in my previous post.

So, sure enough I spent some time putting together a demo to show what can be done with network automation tools and how they could integrate with SDN controllers. The Continue reading

Fixed-Price, or T&M?

Recently I posted about Rewarding Effort vs Results, how different contract structures can have different outcomes. This post covers Time & Materials vs Fixed-Price a little more, looking at pros & cons, and where each one is better suited.

Definitions:

• Time & Materials: Client & supplier agree on the requirements, and an hourly rate. The client is billed based upon the number of hours spent completing the job. Any costs for materials are also passed on. If the job takes 8 hours, the client pays for 8 hours. If it takes 800 hours, the client pays for 800 hours. To prevent bill shock, there will usually be review points to measure progress & time spent. Risk lies with the client.
• Fixed-Price: Client & Supplier agree beforehand on what outcomes the client needs. It is crucial that this is well-documented, so there are no misunderstandings. The supplier will estimate how long the job will take, allow some extra margin, and quote a figure. The client pays the same amount, regardless of how long the job takes. Risk lies with the supplier.

Comparison: