Total Internet Security Software



How To Configure Cisco Nexus 5500 Virtual Port Channel

Multi-chassis link aggregation (MLAG) lets IT teams multihome servers to two or more physical switches in an MLAG group while still allowing all links to forward traffic bi-directionally. MLAG typically uses 802.3ad (LACP) as the control protocol. As there is no single standard for MLAG deployment, network vendors offer it to their customers in various ways. One commonly deployed MLAG technology from Cisco is virtual port-channel (vPC), available in its Nexus line of data center switches. For more on MLAG and other network architecture options download the report The Virtual Network.


In the Nexus world, the most common use cases for vPC are to create high-bandwidth inter-switch links spanning multiple physical switches, and to uplink virtualization platforms such as blade servers and VMware hosts. 10Gbps links are expensive, and MLAG helps ensure you can use them all. Network engineers that want to deploy vPC should study Cisco’s thorough, scenario-driven vPC design guides, one of which can be found here. While the process of building a vPC domain and creating vPCs does not generate especially complex configuration code, the design implications of vPC should be well understood before using it in a production environment.


The rest of this article demonstrates the process of creating a vPC domain between two Cisco Nexus 5500 switches running NX-OS 5.2. Creating the vPC domain is the necessary foundation before creating host-facing vPCs. Note that Cisco supports only two switches in a vPC domain as of this writing. Other MLAG implementations, especially those based on stacking technologies, can support more than two switches in an MLAG domain.


Key points about this configuration:


-The MGMT interface on each Nexus switch is used for the vPC peer-keepalive (heartbeat) link. This is because the peer-keepalive does not have to be a highly redundant link. Cisco recommends using the MGMT interface for this function, which does not prevent you from using it for other functions such as SNMP, TACACS, and so on. If the MGMT interfaces lose contact with one other, that doesn’t automatically affect the status of the vPC domain. The peer-link must also have problems before vPC domain members will assume the topology is breaking down and begin to take action to preserve the forwarding path.


-Port-channel10 is used as the vPC peer-link between the Nexus switches in this example.


-The vpc domain number will always be the same for the two switches in the domain, or the vPC domain will not form. If switches in one vPC domain are to be plumbed to switches in a different vPC domain, then the vPC domain number you assign each pair should differ. For example, if I assign the number “10″ to two switches in a vPC domain, I would assign a different number, such as “11″ to the two adjacent switches in a second vPC domain.


-The system-priority command is related to LACP negotiation of active vs. standby links in LACP bundles of more than 8 physical links. While it is not required that you configure this value, Cisco recommends you set it so that the Nexus vPC switches can decide which links are to be active vs. standby. Lower system-priorities take precedence. This value must match on both switches, or else the vPC domain will not form.


-The role priority command sets a vPC switch priority. Lower role-priorities take precedence. This helps determine which switch will shut down its vPC ports to prevent a topology loop if vPC communications are interrupted.


-The peer-link interface does not require large amounts of bandwidth, as vPC traffic management and port-channel hashing keeps dual-attached end points talking via one of the two vPC domain switches. The vPC peer link will only be used in the case of an unbalanced uplink (a device is plumbed to two switches, but one link has failed), or possibly in the case of single-attached hosts. Cisco strongly advocates that single attached hosts are connected to a vPC domain via a dual-homed switch or fabric extender.


-The peer-gateway command allows a vPC peer to route a packet that, due to HSRP priorities, should have been forwarded to the vPC peer switch for routing services instead of being routed locally. This overcomes hosts that don’t use the virtual MAC for an HSRP IP, but instead uses the physical MAC. Jeremy Filliben has an excellent write-up on the subject.


-The auto-recovery reload-delay command allows a vPC switch that reloads, but finds its peer gone once it comes back up, to move to an active state after the delay time has expired. Without this command, vPC ports would remain shut down. Also, this command allows the secondary vPC switch to bring its ports back to active, if after a peer-link failure, the primary switch also fails.


-Finally, note that not every possible command or design consideration is mentioned in this article. I’m providing the reader with an introduction to vPC design consideration and domain configuration. Think of this is a good starting point, but then take your own specific data center requirements and apply vPC to them.


The Code


———————————————-


NEXUS-SWITCH1 | MGMT0=10.10.10.1


———————————————-


conf t


!


! NX-OS “features” are used to enable functionality


! that is disabled by default.


feature lacp


!


! The port-channel load-balance command determines the


! hashing algorithm used to determine what physical


! path a flow will be sent down.


port-channel load-balance ethernet source-dest-port


!


! To maximize redundancy and minimize single points of


! failure, I recommend spreading physical links in a


! port-channel across multiple internal ASICs. In the


! case of the Nexus 5596 used in this example,


! contiguous groups of 8 ports are mapped to a single


! ASIC – 1-8, 9-16, etc.


interface e1/1,e1/9


switchport


channel-group 10 mode active


exit


!


interface Port-Channel10


des UPLINK NEXUS-SWITCH2 | 10.10.10.2 | Po10


switchport mode trunk


no shut


exit


!


! With CDP and LLDP, detailed port descriptions might


! seem superfluous, but I find them useful as references


! when monitoring with an NMS.


interface e1/1


des UPLINK NEXUS-SWITCH2 | 10.10.10.2 | Eth1/1


exit


!


interface e1/9


des UPLINK NEXUS-SWITCH2 | 10.10.10.2 | Eth1/9


exit


!


! This enables the vPC feature set. The balance of the


! commands below are discussed in the opening paragraphs.


feature vpc


!


vpc domain 10


peer-keepalive destination 10.10.10.2


system-priority 8192


role priority 8192


peer-gateway


auto-recovery reload-delay 240


exit


!


interface Port-channel10


vpc peer-link


vpc 10


exit


!


exit


!


copy run start


———————————————-


NEXUS-SWITCH2 | MGMT0=10.10.10.2


———————————————-


conf t


!


feature lacp


!


port-channel load-balance ethernet source-dest-port


!


interface e1/1,e1/9


switchport


channel-group 10 mode active


exit


!


interface Port-Channel10


switchport mode trunk


no shut


exit


!


interface e1/1


des UPLINK NEXUS-SWITCH1 | 10.10.10.1 | Eth1/1


exit


!


interface e1/9


des UPLINK NEXUS-SWITCH1 | 10.10.10.1 | Eth1/9


exit


!


feature vpc


!


vpc domain 10


peer-keepalive destination 10.10.10.1


system-priority 8192


role priority 16384


peer-gateway


auto-recovery reload-delay 240


exit


!


interface Port-channel10


vpc peer-link


vpc 10


exit


!


exit


!


copy run start


Verification


Network engineers should verify completed tasks. To verify that a vPC domain has formed successfully, review the output of the “show vpc” command. While the output below shows a functional vPC domain, error messages would indicate issues to be investigated.


NEXUS-SWITCH1# show vpc


Legend:


(*) – local vPC is down, forwarding via vPC peer-link


vPC domain id : 10


Peer status : peer adjacency formed ok


vPC keep-alive status : peer is alive


Configuration consistency status: success


Per-vlan consistency status : success


Type-2 consistency status : success


vPC role : primary


Number of vPCs configured : 0


Peer Gateway : Disabled


Dual-active excluded VLANs : -


Graceful Consistency Check : Enabled


vPC Peer-link status


———————————————————————


id Port Status Active vlans


– —- —— ————————————————–


1 Po10 up 1


NEXUS-SWITCH1#


Ethan Banks is CCIE #20655, a host of the Packet Pushers podcast, and IT practitioner since 1995. He can be reached at @ecbanks.

Comments off

News Roundup: SDN, Network Management and Private Clouds

Startup Pica8 announced the release of a reference architecture for software defined networks (SDN). Pica8 makes Top-of-Rack (ToR) switches that support OpenFlow 1.2 and Open Virtual Switch. The company is targeting cloud providers with its newly announced reference architecture. This reference architecture has certified that the Ryu OpenFlow-based controller from NTT Laboratories will interoperate with Pica8′s switches. Pica8 has four switch models, including the P-3780 that includes 48 10GigE ports.


Pica8 isn’t the only startup with a switch-centric approach to SDN. Earlier this month Plexxi announced its own ToR switch, called Switch 1, along with a two-tier controller architecture, in which some of the controller functions reside in the switch.


EMC Smarts


EMC has announced a new version of its Smarts monitoring software. The latest version, 9.1, includes integration with VMware’s vCenter Server and EMC’s SRM Suite. The company says the new integrations give IT managers a single view that encompasses virtual machines, virtual switches, the physical host, and attached storage. Smarts monitors configurations of all these elements, and can roll back to a previous version if a configuration change causes problems. The software can also perform root cause analysis to help IT managers remediate issues.


Smarts also monitors network configuration. In the latest version, EMC has added a toolkit and template that lets customers add new devices so that the Smarts software can connect to, monitor and restore configurations. Previously, customers would have to wait for EMC to certify devices before it could collect and restore configuration information. In addition, EMC has added the ability for Smarts to monitor configuration of wireless access points and controllers from Cisco Systems and Aruba Networks. Smarts starts at $27,000.


ScienceLogic


ScienceLogic announced a new version of its software for managing private clouds. The company is targeting pre-integrated stacks that bundle compute, networking and storage into a single platform, including VCE Vblocks and FlexPod. VCE is a stand-alone company that grew out of a joint venture between Cisco Systems, EMC and VMware. FlexPods integrate NetApp storage with servers and switches from Cisco.


The ScienceLogic management software incorporates performance and event monitoring, asset management and help desk capabilities in a single product. New features include the ability to visualize individual components of the integrated private cloud stacks.


The management of private and public clouds has gained more attention from vendors this fall, as witnessed by Cisco’s November
acquisition of Cloupia, which makes the Unified Infrastructure Controller software. Around the same time, Dell announced it would purchase Gale Technologies, which makes management, automation and orchestration software for the data center.

Comments off

How to Speak Data Center: IT Power Supplies

In my first two posts on how IT pros can improve their interactions with data center facility pros, I covered the difference between power and energy, and how to covert between kWh and BTUs. This post will address power supply ratings and power supply efficiency.


IT and data center professionals need to understand how much power IT equipment uses. You may have heard of a quick-and-dirty option to use the “nameplate” power rating to estimate energy use. The nameplate is a safety label that comes from the Underwriters Laboratory which was formed in the year 1894 for the independent evaluation of electrical products for safety.


Despite the nameplate’s function as a safety label, it can provide a clue as to the device’s energy use. It’s a gross rule of thumb that most IT power supplies typically sustain a load that’s less than half of the nameplate rating.


However, I do not recommend relying on this method. Get the right tools to measure actual energy consumption. For instance, power distribution equipment often includes reporting that you can use. You can also get tools such as a multi-meter or “amp clamp” for external verification. Don’t touch the power without proper training and safety equipment!


Another unwritten rule in the data center is to pay attention to the power supply efficiency rating, such as the Energy Star External Power Supply (EPS) v2.0 metrics adopted by the Department of Energy. In conjunction with recent European Union efficiency standards, the bottom end of the power supply market has been increasing efficiency, but your choice of efficiency should still depend on your business requirements.


Power Supply Efficiency


You can see in the DoE and LBL diagram above that most power supplies are less than 75% efficient. If you also consider power supply redundancy, splitting the load across multiple power supplies means efficiency can reach below the 30% load. This can take a mediocre 75% efficient power supply and drop it to 60% efficiency. This means 40% of every watt-hour consumed is just turned into waste heat.


Why should you care? Every watt-hour of energy lost to a 40%-inefficient power supply is a watt-hour that you can’t use for another computer. Although you can’t get 100% efficient power supplies, what would you give for 10-20% increase in your UPS capacity? Every watt-hour saved is liberated power capacity on your UPS. Highly efficient power supplies can give you that capacity boost at a fraction of the cost of a new UPS.


Next page: Power Factor CorrectionI mentioned Power Factor Correction (PFC) in a previous posting, but I didn’t explain it. If you can understand Power Factor and Power Factor Correction, you can really build some credibility with the electrical engineers. It is not an easy thing to understand, so don’t get frustrated.


If you think of a car burning a gallon of gas, efficiency is similar to miles per gallon; in other words, how efficient the car is at converting the gallon of gasoline into miles traveled. Power factor is analogous to a leaky fuel line: it’s the fuel that never reaches the engine. This isn’t measured in the computer, it is only evident upstream. Using the car analogy, the car will calculate the same MPG, but you will only notice the gas leaking from your tank if you check the gallons supplied at the pump compared to the gallons used by the car.


We can see the PFC feature in some power supplies in the DoE and LBL graph above. “Efficiency” above shows how watt-hours consumed are wasted by the power supply itself. PFC is about getting more watt-hours out of your existing power entering the power supply.


As discussed above, the conversion of VoltAmps to Watts includes a Power Factor. The Power Factor describes how “reactive” the load is by how far the load lags the voltage waveform. In English, this means that an ideal load would match voltage wave perfectly. Any deviation from ideal creates two problems: stranded capacity and harmonics. PFC is important to deal with both of these problems.


The first problem of a leading or lagging power factor is that it reduces the amount of power that can be used on a power circuit. For example: If you assume an IT power supply is on a 20 amp breaker (rated 16 amps continuous load) at 120 volts, which operates at a 0.80 power factor (very poor), the power supply can only consume 1.536 kWh in an hour (16A*120V*0.8PF). At a 1.0 power factor, the power supply can consume 1.920 kWh per hour (12*120*1.0); an increase of 25%. The 384 watt-hours is the stranded power capacity. The electrical infrastructure is present in the data center to support the full 1.920 kW, but your power supply can’t extract the energy. A crude explanation of the limitation is that power supply is lagging and can’t take advantage of the peak voltage. When the power supplies provide PFC, they take much better advantage of the peak voltage.


Another problem to understand when discussing PFC power supplies with the data center staff is harmonics. When the power supplies lag or lead the voltage, they create “echoes” on the power circuits. These echoes can resonate at specific frequencies and are called harmonics. (like feedback on an audio system). The details aren’t important, but the best way to think about harmonics is that it is “noise” on the electrical system.


Power harmonics can cause many types failures, such as overheating conductors, damaging power supplies or causing logic chip failures due to voltage conditions outside specifications. You can track the historical progression of this issue by reviewing the increasing specification by engineers for Z-rated or “Harmonic Mitigating” transformers.


Why should IT care? Not only can you correct a major source of the harmonics by using Power Factor Correction (PFC) power supplies, you get more out of your electrical infrastructure without any upgrades. By breaking into the data center code, you can show how IT use of PFC power supplies leverages existing investments in data center facilities while reducing noise on the electrical system inside the data center.


Ken Miller is data center architect with the IT Infrastructure and Operation Services division of Midwest ISO, developing mission-critical facilities.

Comments off

SolarWinds Integrates IP Address Management with Microsoft DHCP, DNS

SolarWinds’ latest version of its IP Address Manager software now include support for Microsoft DHCP and DNS, Cisco DHCP, and Cisco Adaptive Security Appliances. The company says this lets customers better manage their IP addresses without abandoning their existing DHCP and DNS systems, or having to invest in more costly appliance-based approaches, such as those offered by Infoblox.


SolarWinds’ IPAM includes a Web-based console to manage the enterprise IP infrastructure. The new integration also lets administrators monitor and manage Microsoft DHCP and DNS services and Cisco DHCP services in real time, while also tracking IP address usage history.


The software can manage both IPv4 and IPv6 addressess. Tracy Corbo, principal research analyst at Enterprise Management Associates, said despite the ongoing transition from IPv4 to IPv6, many organizations still use spreadsheets or even pen and paper to keep track of IP addresses; they don’t yet consider it a big enough pain point to adopt an automated solution.


“It’s been good enough, so people have not been compelled to spend money on it,” she said. “I thought IPv6 would compel people to find an automated solution.” That’s because the length and quantity of addresses in IPv6 make them unwieldy for manual operations.


But first, companies have to migrate to IPv6. Corbo’s research shows that enterprises are dragging their feet when it comes to IPv6 adoption. That’s bolstered by an InformationWeek IPv6 survey of 681 business technology professionals, which found deployment of IPv6 among organizations is slow. For instance, 22% say they will adopt IPv6 within one to two years, while another 38% have no plans to run IPv6 for the foreseeable future.


Even if enterprises aren’t moving to IPv6 yet, manual IP address management is inefficient and prone to errors. In addition to automating IP management, an IPAM product can also provide insight into a company’s use of IP addresses, such as revealing addresses allocated to devices that are no longer on the network, like decommissioned servers or retired network printers.


SolarWinds isn’t the only vendor with an IP address management product. Other options include BlueCat Networks’ Proteus IPAM software. Meanwhile, InfoBlox offers both physical appliances and software for IP address management, including its IPAM Express software for organizations with less than 1,000 employees.


Corbo said there aren’t new entrants in the market nor is there a great deal of innovation occurring. “It’s on cruise control, but I see IPv6 as the tipping point where people are going to have to look at this more seriously and think about automating.”


The latest version of SolarWinds’ IPAM is available in December, including a free, a downloadable 30-day trial version. Pricing starts at $1,995 and includes one year of maintenance.

Comments off

Intel Gets Serious About Microservers with New Chips

Intel’s announcement of twenty low-power Atom server chips is a major push forward for the nascent microserver market. The new chips (dubbed the S1200) are intended for a variety of data center uses ranging from general purpose scale-out servers to controllers for storage appliances, Ethernet switches and other appliance-like applications.


The dual-core systems on a chip include ECC-memory-compatible controllers that can manage up to 8GB of DDR3 RAM, PCI controllers, hyperthreading and hardware-assisted virtualization. Running at 1.5 to 2.0 Ghz, the chips draw between 6 and 9 watts and are priced starting at $50 when purchased in quantity.


There will no doubt be a rush to compare ARM’s new server designs to Intel’s – and there’s nothing wrong with that. Compare away, but be aware that comparisons are fleeting and the business models are very different. A technical comparison of the Intel and ARM low-power server CPUs probably won’t tell you much about how the market will unfold.


Just as Intel has one heck of an uphill climb to get into the smartphone and tablet game, ARM will have at least as big of a challenge in servers. While binary compatibility may not be all that important for many applications, microservers still need to fit into existing systems. Intel, with the Windows/Linux infrastructure that everyone knows, has a leg up on management systems at the very least, because the tools should be the same.


While management tools might be the same, IT shouldn’t expect to use microservers the same way they do traditional servers. That is, don’t expect to throw on a hypervisor and toss all resources into a pool. Because individual microservers are slower and somewhat memory constrained, the best use will probably be without virtualization in true, scale-out applications. In those cases, if a server croaks, you’ll just forget about it. If you need to upgrade software, you’ll use load balancers to direct around servers being upgraded. The thing you won’t want to do is run $5,000 worth of VMware software on your $500 microserver. VMware will probably create products to address this – at least one would hope – but the best uses will likely be to craft major applications to the server architecture itself.


But back to Intel. It wasn’t all that long ago that the company resisted the push for low-power server chips, essentially saying those devices wouldn’t account for more than 10% of the existing market. Given ARM’s success and Intel’s abysmal failure in the mobile devices, Intel is no longer as sure of its prognostications as it once was. ARM also stepped up its game with designs that support virtualization and ECC memory, and as such could make reasonable servers. AMD and lots of others are planning to manufacture systems based on the ARM designs, and are already taking potshots at Intel saying that they’re late to the game and uncommitted. While Intel is a bit late, it also has all the relationships it needs with server makers to do well. Besides, ask Friendster and MySpace how important it is to be first to market. It’s a good thing, but it sure isn’t the only thing.


There’s no doubt that low-power servers will suit a wide range of applications from big data to Web farms and a lot more. My sense is that as the architecture proves itself, the market could be a lot bigger than 10% of the traditional server (macroserver?) market.

Comments off

Network Overlays: An Introduction

While network overlays are not a new concept, they have come back into the limelight thanks to drivers brought on by large-scale virtualization. Several standards have been proposed to enable virtual networks to be layered over a physical network infrastructure: VXLAN, NVGRE, and SST. While each proposed standard uses different encapsulation techniques to solve current network limitations, they share some similarities. Let’s look at how network overlays work in general.


Many advanced virtualization features require Layer 2 adjacency, which is the ability to exist in the same Ethernet broadcast domain. This requirement can cause broadcast domains to grow to unmanageable sizes. Prior to virtualization, network designs emphasized shrinking broadcast domains as much as possible and routing to the edge wherever possible. That’s because routing is extremely scalable, and routing to the edge can improve path utilization and alleviate dependence on Spanning Tree for loop prevention.


Now virtualization is forcing broadcast domains to grow, in part to enable features such as VM mobility. One way to do this is through the use of VLANs. The 802.1q standard defines the VLAN tag as a 12-bit space, providing for a max of 4,096 VLANs (actual implementation mileage will vary.) This is an easily reachable ceiling in multi-tenant environments where multiple internal or external customers will request multiple subnets.


All three proposed network overlay standards solve the scale issue by providing a much larger Virtual Network ID (VNID) space in the encapsulating packet. NVGRE and VXLAN are designed to be implemented in hardware and use a 24-bit VNID tag, which allows for 16 million virtual networks. STT uses a larger 32-bit ID. This provides for more space but would be more expensive to implement in hardware, where increased address size incurs additional cost for implementation in silicon.


Aiming for Flexibility


A need for flexibility in the data center also opens the door to network overlays. That is, the data center network needs to be flexible enough to support workloads that can move from one host to another on short notice, and for new services to be deployed rapidly.


VMs in a data center can migrate across physical servers for a variety of reasons, including a host failure or the need to distribute workloads. These moves traditionally require identical configuration of all network devices attached to clustered hosts. There is also a requirement for common configuration of upstream connecting switches in the form of VLAN trunking, and so on.


Network engineers and administrators face the same problem whether they are deploying new services or updating old ones; namely, the need to configure the network. Much of this work is manual, which limits scalability and flexibility and increases administrative overhead.


Overlay tunneling techniques alleviate this problem by providing layer 2 connectivity independent of physical locality, or underlying network design. By encapsulating traffic inside IP packets, that traffic can cross layer 3 boundaries, removing the need for preconfigured VLANs and VLAN trunking.


These techniques provide massively scalable virtual network overlays on top of existing IP infrastructures. One of the keys to the technique is the removal of the dependence on underlying infrastructure configuration; as long as IP connectivity is available, the virtual networks operate. Additionally, all three techniques are transparent to the workload itself; the encapsulation is done behind the scenes so it is application independent.


How It Works


From a high-level perspective, all three proposed standards operate in the same way. End points are assigned to a virtual network via a Virtual Network ID (VNID). These end points will belong to that virtual network regardless of their location on the underlying physical IP network.


In diagram 1 there are four virtual hosts connected via an IP network. Each host contains a Virtual End Point (VEP), which is a virtual switch capable of acting as the encapsulation/de-encapsulation point for the virtual networks (VNIDs.) Each host has two or more VNIDs operating on it and each workload assigned to a given VNID can communicate with other workloads in the same VNID, while maintaining separation from workloads in other VNIDs on the same or other hosts. Depending on the chosen encapsulation and configuration method, hosts that do not contain a given VNID will either never see packets destined for that VNID, or will see them and drop them at ingress. This ensures the separation of tenant traffic.


Diagram 1


Diagram 1 focuses on virtual workloads running in VMs. The same concept would apply if using a physical switch with the VEP functionality. This would allow physical devices to be connected to the overlay network as pictured in Diagram 2 below.


Diagram 2


With a physical switch capable of acting as the tunnel end-point, you can add both physical servers and appliances (firewalls, load balancers, and so on) to the overlay. This model is key to a cohesive deployment in mixed workload environments common in today’s data centers.


Next page: Network Overlay DrawbacksEncapsulation techniques are not without drawbacks, including overhead, complications with load-balancing and interoperability issues with devices like firewalls.


The overhead with any overlay can come in two forms: encapsulation overhead of the frame size, and processing overhead on the server from lack of ability to use NIC offload functionality. Both NVGRE and VXLAN suffer from the second problem due to encapsulating in IP within the soft switch. STT skirts the processing overhead problem by using a TCP hack to gain Large Segment Offload (LSO) and Large Receive Offload (LRO) capabilities from the NIC.


All three proposals will suffer from the first problem of encapsulation overhead. With any encapsulation technique you are adding additional headers to the standard frame, as shown in Diagram 3.


Diagram 3


With modern networks the actual overhead of a few additional bytes is negligible. Where it does come into play is the size of the frame on the wire. Adding additional information will require either jumbo frame support, or more fragmentation of data to meet standard frame sizes.


The three standards proposals handle this differently. VXLAN is intended to be used within a data center, where jumbo frame support is nearly ubiquitous; therefore VXLAN assumes support and uses a larger frame size. NVGRE has provisions in the proposal for Path Maximum Transmission Unit (MTU) detection in order to use jumbo frames when possible, and standard frame sizes where required. STT will be segmented by the NIC and rely on NIC settings for frame size.


Load balancing spreads traffic across available links to maximize network throughput. It is typically done on a flow basis, i.e. by device-to-device conversation. With encapsulation techniques, the inner header information becomes opaque to devices not hardware-capable of recognizing the encapsulation. This means that data normally used to provide load-balancing disappears and all communication appears as a single ‘flow.’


VXLAN handles this issue using a hash of the of the inner payload header information as the UDP source port in the encapsulated packet. This allows for efficient load-balancing in systems relying on 5-tuple algorithms. STT and NVGRE do not provide for as elegant of a solution, and offer up separate possibilities for providing some level of flow control.


Without a granular method of providing flow control, network traffic will bottleneck and lead to congestion that can be detrimental to the network as a whole. This will be more apparent as traffic scales up and increases the demand on network pipes.


In Diagram 4 we see all traffic from the VMs on both hosts traversing the same path, even though two are available. The same would be the case if the links were bonded such as with LACP: one physical link in the bond would always be used. This problem leaves an available link unused, and can result in performance problems if traffic overwhelms the one link being used.


Diagram 4


The last drawback is the challenge with devices such as firewalls. These devices use header information to enforce policies and rules. Because these devices expect a specific packet format, they may be stymied by encapsulated frames. In designs where firewalls sit in the path of encapsulated traffic, administrators will have to configure specific rules, which may be looser than traditional design.


Network overlays provide for virtualized multi-tenant networks on shared IP infrastructure. This provides for a more scalable design, from 4096 virtual networks to 16 million or more. In addition, a network overlay enables the flexibility and rapid provisioning required by today’s business demands. Using overlays, services can be added, moved, and expanded without the need for manual configuration of the underlying network infrastructure.


For more information, see these deep-dive posts on VXLAN, SST, and NVGRE.


Disclaimer: This post is not intended as an endorsement of any vendor or product.

Comments off

Must ‘Cloud’ Translate To ‘Ungovernable’?

Cloud computing gives us a lot of choices of where to run workloads: our own data centers, a private cloud within a premises data center, a public cloud or a hybrid. But where workloads and services reside isn’t the conversation we need to have. Instead, we must ensure that all workloads are reliable, and that all services meet their SLAs.


For that to happen, IT and business leaders must embrace IT Service Management (ITSM). A service orientation and smart use of clouds can help with operational reliability and improved IT accountability if, as part of that transformation, you adopt some ITSM best practices. Yes, OK, I’m talking about ITIL and other frameworks, but keep reading. My message is that ITSM can’t become an end in itself; in fact, that kind of thinking gives frameworks a bad name. Frameworks are a means to an end.


ITSM and the Cloud


When IT services develop a split personality with an uncontrolled shadow (and sometimes even rogue) element, the danger is that IT’s left holding the bag. ITSM can offer a pragmatic way to rein it all in, while not stifling business optimization and agility. An agile and action-oriented CEO might question the smarts of bringing in COBIT or ITIL when more immediate priorities related to cloud migration are on the agenda. The answer: Do some governance now to avoid having costly mistakes come home to roost later.


The motivation for ITSM shouldn’t be direct monetary benefits as much as indirect savings through governance, risk avoidance and compliance. Yet cost reduction still weighs heavily on the discussion. For instance, in an interesting study by the APM Group showed that reduced costs ranked second among a list of ITIL benefits that include improved service quality, standardized processes and working environments and customer satisfaction.


Cloud Buyer’s Guide: Infrastructure As A Service


12 top vendors. Detailed features matrixes with over 60 data points. Your one stop shop for an IaaS short list.


See Infrastructure As A Service Guide »


Even if you go into it with realistic goals, ITSM adoption is fraught with disappointments and obstacles, especially when pursued as a silver bullet instead of best practices for processes, people and technology. Some pitfalls include:


• Too many standards and too little enforcement of policies. Policy creation and enforcement for clouds has been gaining traction and mindshare only for the last three years or so, but it’s critical.


• A lack of policy portability. Policies are an integral part of your IP and hence your apps and services. And, like apps and services, policies need to be portable. But are they? And what about lifecycle management of polices themselves, important because policies have to move at the same speed as the business?


• Complexity. Many-to-many relationships among workloads/services; users, as in role-based IDM; geographies; and deployment zones demand a powerful policy engine to govern and control all the rules that encapsulate the many permutations and combinations.


• Skepticism about ITSM, and especially its readiness for clouds. In a survey by ITSM provider Axios Systems, more than half of IT professionals (51%) didn’t think their ITSM processes were mature enough to effectively manage cloud-based services.


Contrary to what ITSM and ITIL purists and naysayers alike may attest, cloud is neither at odds nor incompatible with the goals of service management, particularly change management. Cloud is simply a more optimized form of IT delivery, and as such it very much fits within the purview of ITIL’s best practices of service lifecycle management.


Yes, cloud does abstract a lot of the minutiae related to infrastructure change management–and that should be viewed as a big plus. Freedom from those chores, not to mention the money and time saved, should free us up for customer-facing service management.


ITSM will also help make sure certain critical requirements of a cloud service are met, including:


• Well-defined control over physical and virtual environments, both on-premises and in the cloud, for routine health-checks and ability to diagnose and recover from failures.


• Provisioning, metering/billing and cataloging.


• Transparency over on-boarding and off-boarding of resources and services.


• Unified management for on- and off-boarding of resources and services.


ITSM is not plug-n-play, not for hybrid IT, but we have the benefit of proven frameworks, processes, standards, repositories and tools. It’s time to take advantage of them.


Sreedhar Kajeepeta is Global VP & CTO of Technology Consulting for Global Business Services at CSC.

Comments off

Cisco’s Spending Spree: An Analysis

The holiday shopping season is in high gear, but consumers aren’t the only ones opening their wallets. Cisco has been on its own buying spree lately, picking up two software companies and a WLAN vendor in the month of November.


Of the three companies recently purchased–Cariden, Cloupia and Meraki–Cariden is the most striking. Cariden’s core software product could best be described as path and network analysis software. It gathers configuration data from the network devices, then maps data into a network graph, performing mathematical modeling to deliver predictive analytics and resource mediation of the carrier network.


Cariden has solved key analytical problems such as bandwidth structuring, resource prediction and path weakness in the carrier networks. In discussions with Cariden earlier this year, it was clear to me its technology could readily be adapted as an SDN application.


In a Cisco context, Cariden is a mature and proven software platform that carriers trust for network planning and design. Integration with Cisco’s OnePK SDN strategy means that Cariden can close the loop from a “read and report” operation to “read, analyse and configure” for dynamic network configuration. And this matters for demand placement in terms of allocating bandwidth on different paths in carrier backbones on a time of day (sometimes known as “routing for dollars”).


The Cloupia acquisition is intended to bolster Cisco’s data center software automation suite. Cisco already has the Intelligent Automation for Cloud and Network Services Manager options from previous acquisitions, but these tools focus only on Cisco and aren’t usable for customers with non-Cisco assets, such as storage arrays.


Cloupia’s software provides automation within converged infrastructure stacks for tasks such as server provisioning, VDI and orchestration across the compute/network/storage stratum.


This is the first sign that Cisco realizes it must integrate with partners to provide cloud automation. Until now, Cisco has made software for Cisco products and no one else. Cisco’s ‘encourages’ customers to buy only its products by refusing support or integration. Until Cisco buys, at least, a storage company, then third-party integration in cloud platforms will always be a requirement. As such, Cloupia provides a mechanism for integrating NetApp and EMC storage into a Cisco private cloud based on UCS servers and Nexus networking.


And finally, Cisco has a better chance of going head to head with EMC’s Ionix in global accounts. EMC’s software portfolio is an enormous revenue and profit center for the VCE joint venture and, if stories are true, a source of much angst between Cisco and EMC executives because EMC garners as much as 75% of the profit in a vBlock sale.


As for Meraki, it seems most likely the WLAN vendor was acquired for its cloud management platform, given that Cisco already has a large wireless portfolio with wide customer acceptance (if not always a high degree of customer satisfaction).


The cloud-based management involves devices located at the customer premises sending data over encrypted Internet connections to an off premise service. The complexity of wireless networks require software tools to manage, monitor and maintain access points and controllers –the CLI simply isn’t enough to keep the system under control. That challenge is exacerbated if you have a network with many remote sites, each with its own WLAN. The cloud platform provides a unified management interface.


Next page: Coherent Strategy LackingThere is no coherent, company-wide strategy in these acquisitions. Instead, we’re seeing piecemeal deals struck by different business units as these units compete to grow within a shrinking and changing market. Cisco continues to look for more revenue and profits to keep its shareholders content, but when a company has more than 65% of network infrastructure marketplace, and gross margins of 65%, the only competition is really yourself. The fact is, Cisco is many fragmented businesses that compete with each other as much as external companies.


The Cariden acquisition shows that Cisco’s Service Provider team understands the threat that software platforms pose to device sales. Having control of the incumbent software “controller” gives Cisco better control of the market.


Cloupia boosts the existing orchestration tools for Cisco’s server and virtualization team by adding decent automation for non-Cisco products. This also positions Cisco better in the VBlock /Flexpod market for converged orchestration.


Finally, Meraki will be used in the Borderless Networks team to provide cloud-hosted management services for resellers to pass on at cost plus 10%, and further undermine the reseller revenue of professional services.


It’s worth noting that none of these acquisitions is all that large by Cisco standards. Yes, Meraki was picked up at a premium for $1 billion, but mostly in shares rather than cash. Cariden was a $141 million deal and Cloupia went for $125 million.


Compare those sums to March 2012, when Cisco acquired NDS for $5 billion. NDS offers “video software and content security solutions that enable service providers and media companies to securely deliver and monetize new video experiences” (whatever that means). Clearly, John Chambers’ apparent fascination with video remains insatiable.


If there is one overarching theme to these acquisitions, it’s software. Cisco’s various business units are buying the expertise they need to build software products. Cisco has repeatedly failed to deliver acceptable software in the past–products like CS-Mars, Access Control Server, Java clients, and Cisco Works have highlighted the poor quality of Cisco executive leadership when it comes to software. We’ll have to see if the injection of new software developer blood will have a positive effect.

Comments off

Plexxi Cuts a New Path to SDN

Plexxi, a networking startup, has launched an SDN platform. The platform include Plexxi Switch 1, a Top of Rack (ToR) switch; and Plexxi Control, a software controller that abstracts the network and provides configuration instructions to the switches for servers and workloads running on the network. The controller includes an API that provides a programmatic interface for third-party vendors.


Plexxi distinguishes itself from other controller-based SDN architectures in a couple of key ways. First, its ToR switch includes an optical interconnect. The company claims that its optical interconnect provides up to 400Gbps of capacity per switch. Up to 250 Plexxi switches can be linked together via optical ports built into each switch. “We employ WDM technologies that allow for optical meshes of connectivity,” said CEO and co-founder David Husak.


Second, Plexxi doesn’t use OpenFlow to communicate between its controller and its switches. This sets Plexxi apart from a large number of established vendors, including HP, IBM, NEC (and, to some extent, Cisco) that promote an architecture that relies on a controller-plus-OpenFlow design.


Instead, the company uses a two-tier controller architecture, in which some controller functions reside on each individual switch (a co-controller, in Plexxi’s parlance). The output from the central controller consists of what Plexxi calls a set of network directives. “The co-controller on each switch is responsible for translating those network directives into device-specific information like flow table entries,” said Plexxi co-founder Mat Mathews in an e-mail.


Mathews said the central controller can communicate a partially specified topology to the Plexxi switches, in which it provides several path options for a given destination. The switches then figure out how to distribute traffic using those paths. The controller can also define a specific end-to-end path for a given workload.


Rather than transform switches into dumb-but-fast devices that simply shuttle traffic back and forth at the whim of the controller, Husak said there’s value in ensuring that individual switches retain some network intelligence. “There’s a lot of elements and features of the layered protocol stack that have self-healing and the ability to do rapid device detection and bring up and down connections, and we wanted to preserve those functions,” he said.


Plexxi’s API exposes the controller to third-party systems, which can communicate network requirements to the controller. “Initially, they can pull information out of VMware’s VCenter or VCloud Director and use that information to make decisions on how they build a network,” said Eric Hanselman, research director for networks at 451 Research.


Many Paths to SDN


Plexxi isn’t the only startup tackling the SDN market, nor is it the only startup to forgo OpenFlow. This October, a startup called Midokura announced a beta version of its MidoNet software. MidoNet is designed to run on Linux servers at the edge of network. The software sets up tunnels that can run over an IP network, creating a virtual network overlay that moves traffic through physical devices. Back in the OpenFlow camp, a startup called Big Switch Networks launched a software controller and a pair of SDN applications.


451 Research’s Hanselman said Plexxi should appeal to organizations with workloads that can take advantage of the optical interconnect, such as financial services companies engaged in high-frequency trading or media companies that need to move large files.


“If you want to slice and dice a bunch of 1Gig and 10Gig links, OpenFlow does that handily, and you can do it with low-cost systems,” he said. “If you want high capacity and flexibility, that’s where Plexxi holds an advantage.”


That capacity comes at a price: Plexxi’s switches start at $64,000, and the software controller is licensed at $5,000 per switch. The company says its Switch-1 offers 32 10Gbps and 4 40Gbps ports on each box in addition to the optical port.

Comments off

Silver Peak, F5 Put Virtual Appliances in Amazon Cloud

Virtual appliances are a relatively new option for customers buying network systems such as firewalls, load balancers, WAN optimization, and other products. Like a physical appliance, virtual appliances are fairly simple to deploy, and because they’re just software, vendors often make it easy for customers to try a product before they buy it. Now these virtual appliances are also being bundled for public clouds.


This week Silver Peak announced version 6.0 of Virtual Acceleration Open Architecture (VXOA), its WAN optimization software for virtual and physical platforms. The new release touts several enhancements, including the ability to run on multiple hypervisors, including Microsoft Hyper-V, Citrix Xen and KVM. The software already supported VMware vSphere.


VXOA 6.0 also adds support for applications provisioned to the Amazon Web Services public cloud. Silver Peak created an Amazon Machine Interface (AMI) wrapper in VXOA 6.0 so that WAN optimization can be virtually deployed with the application inside Amazon’s network. WAN optimization products require an appliance on each side of the datacenter, which means Silver Peak customers can now enable WAN optimization from their own data center to the Amazon cloud. At present, Amazon Web Services is the only public cloud environment that VXOA 6.0 supports.


It’s often forgotten in the rush to the public cloud, but TCP/IP doesn’t handle packet loss on the WAN very well. For these and other reasons, companies that rely heavily on WAN traffic will often turn to WAN optimization, which can improve application performance by using techniques such as compression, to decrease the volume of bits sent over the WAN; and protocol optimization, which reduces the amount of back-and-forth chatter.


Silver Peak isn’t the only vendor packaging its software for the public cloud. Last week, F5 announced that its Big-IP platform would be available to run as an Amazon AMI starting at the end of the month. As with Silver Peak, F5 customers license a virtual version of Big-IP and deploy it within an Amazon instance. Because BIG-IP for AWS will have equivalent features to physical BIG-IP devices, customers can establish secure tunnels, burst to the cloud, and control the application from end to end.


Riverbed also offers virtual appliances and cloud-based options, including Cloud Steelhead and the Stingray application delivery controller, which is available in AWS. Certeon, Replify, and Netex are other WAN optimization vendors that offer software-based WAN optimization, with a focus on the VMware hypervisor.


The move from physical to virtual appliances, whether on premises or in a public cloud, is a significant market shift that offers organizations a lot more flexibility in the deployment and management of network services. Everyone hates deploying and maintaining more hardware in the network. While initially easy to deploy, the ongoing maintenance and operating costs of physical appliances can be substantial over time, in addition to the effort to upgrade them. In large enterprises, with many distributed locations, it’s even harder to manage the configuration of physical appliances.


In addition, companies are beginning to realize that the virtual appliances provide more flexible deployment options, and may be cheaper for organizations that now can move virtual appliances to trouble-spots instead of permanently deploying physical appliances at every end point. And as companies get more comfortable with virtualization, the move to a virtual appliance isn’t so dramatic.


Silver Peak CEO Rick Tinsley said that only about 20% of its customers use the virtual appliances. However, he does expect that the marketplace for virtual WAN optimization appliances will eventually reach parity with their physical counterparts.

Comments off

« Previous entries Next Page » Next Page »