SDN Playground – getting started with OpenFlow

Most every big Networking company has announced something related to SDN. Whether simple marketing to concrete legit solutions, its a question of time until the market is filled with SDN-related products. It is thus essential to start getting familiar with it, and you know damn well there’s nothing like getting your hands dirty. So here are some helper-notes on getting started with sandboxing OpenFlow (OF) environments.

To do so I’m using Mininet – a VM created part of an OpenSource Project to emulate a whole complete environment with a Switch, an OF Controller, and even three linux hosts. Also note I’m using my desktop as a Host, with VirtualBox.

So what you’ll need:

  • If you don’t have it yet, download VirtualBox, or another PC hyper-visor Software such as VMware Player. VirtualBox has the advantage of being free for Windows, Linux and Mac.
  • Download Mininet VM OVF image.
  • After decompressing the image, import the OVF.

VB Import Applicance

  • In order to establish terminal session to your VM, you’ll need to add a Host-only Adaptor on the Mininet VM. So first (before adding the adaptor on the VM itself) go to VirtualBox > Preferences. Then select the Networking tab, and add and adaptor.


  • Next edit Vm Settings, and add an Host-only Adaptor. Save it and boot the VM.
  • User: mininet       Password: mininet
  • Type sudo dhclient eth1 (or if you haven’t added another adaptor and simply changed the default Adaptor from NAT to Host-only adaptor then type eth0 instead of eth1) to enable DHCP service on that interface.
  • Type ifconfig eth1 to get the IP address of the adaptor.
  • Establish an SSH session to the Mininet VM. Open terminal, and type ssh -X [user]@[IP-Address-Eth1], where the default mininet user is “mininet” and IP address is what you got after ifconfig. So in my case it was: ssh -X mininet@
  • Mininet has its own basics tutorial – the Walkthrough. Also interesting is the OpenFlow tutorial.

The Mininet Walkthrough is designed for less than an hour tutorial. Here are some simple shortcuts to speedup your playing around:

  • Type sudo mn –topo single,3 –mac –switch ovsk –controller remote. This will fire up the emulated environment of the switch, OF controller, and 3 linux hosts.

OF topology

  • Type nodes to confirm it. “h” stands for hosts, “s” for switch and “c” for controller. If you want, for instance, to now the addresses of a specific node such as Host2, type h2 ifconfig. If you want to establish a terminal session to the same host, type xterm h2. Note that xterm command only works if you first established ssh session by typing ssh -X

This should already get you started.

Have fun!

Basic BGP Concepts

Here is a very short introduction to Border Gatway Protocol (BGP) – or Bloody Good Protocol as some like to call it. BGP is a routing Protocol, which is used mainly for:

  • Sharing prefixes (networks) between ISPs, thus enabling the Internet to scale;
  • Multi-home an organization to several ISPs (whereby Internet prefixes from ISPs are learned, and its own networks are advertised)
  • Scaling internally in very large organizations

BGP is an Exterior Gateway Protocol (EGP), which differentiates from IGPs – such as RIP, OSPF, IS-IS, EIGRP – mainly for:

  • Uses TCP (port 179) for transport ensuring reliable delivery of BGP messages between peers (Routers)
  • Can scale hundreds of thousands of Routes (without crashing like IGPs would)
  • Peers are manually configured – there is no automatic peer discovery, all peers must be manually added
  • Besides prefix, mask and metric, BGP carries several additional attributes. Though being a major advantage against other protocols, attributes also have the disadvantage of making BGP more complex to configure
  • BGP is “political in nature” when it comes to finding best paths, meaning Best Paths can be flexibly changed (using attributes). IGPs on the contrary have fixed best path algorithm, namely Short Path First, and chose it by metric. It is much harder to manually influence the Best path choosen in an IGP (for instance you can change the cost of an interface, but it is not possible to set a different cost on the same interface for different destinations), whereas in BGP it is much easier.
  • BGP may converge more slowly when failures occur, whereas IGPs usually converge faster
  • Since BGP is not a link state protocol, BGP does not share every prefix in its BGP table with every peer. Instead, it only shares the best routes with peers (even though it might know several paths to the same destination).

BGP carries several attributes with each prefix. Since there is no space in the routing table to hold all those attributes, BGP has its own table where it stores prefixes with all its attributes. However, BGP table is not used directly to route IP packets. Instead BGP places only the best prefixes in the routing table with administrative distance of 255 (so that ii the prefix is learned by both BGP and IGP, the IGP route will always be preferred), while maintaining all prefixes in its table. This allows for redundancy as well as load balancing capabilities.

Attributes are what makes BGP so flexible and thus interesting. Most are optional, only the first three are mandatory. Here is a list of BGPs attributes:

  • Origin (mandatory) – indicates how the attribute was originally created into BGP; in other words, it indicates if a certain prefix was imported from another Routing protocol or static routes, or if it was specifically originated by the administrator manually, or even if it was originated by the EGP (obsolete)
  • AS Path  (mandatory) – allows eBGP to be loop free. Subsequent AS can distinguish how the route was created, be being able to see a ordered list of AS between local (first AS Path number) and destination prefix (last AS Path number).
  • Next hop  (mandatory) -is an IP address, that should be used for packets destined to a certain prefix. It allows a peer to deduce the interface to use to send packets to the appropriate border router.
  • Multi-Exit Descriminator (MED) (optional) – used to influence inbound traffic from a neighboring AS. It only influences direct neighbor peers. It is a low-power attribute (comes late in the decision process), but can be useful in organizations that are multi-homed to the same ISP. The lowest MED value wins
  • Local preference (optional) – used to influences outbound traffic, also in organizations multi-homed to the same ISP. Local preference value is only advertised within iBGP peers, and is not advertised to a neighboring AS. Prefix with highest local preference value wins decision process, with the advantage of being able to load balance traffic while maintaining redundancy.
  • Atomic Aggregate (optional) – Used in prefix summarization to warn throughout the Internet that a certain prefix is an aggregate
  • Aggregator (optional) -Also used in prefix summarization, shared throughout the Internet and it includes the router-id and AS number of the router that performed the summarization
  • AS 4 Path (optional) – used to support the longer 32 bit AS numbers through AS that support only 16 bit AS numbers
  • Communities  (optional) – it is a special marking for policies usually deployed by ISPs. It allows to group prefixes together in order to give special and common treatment for a set of prefixes
  • Extended communities  (optional) – as the name indicates, it extends the Communities attribute length, allowing for additional provider offerings such as MPLS VPNs, etc.
  • Originator ID (optional) – attribute intended for iBGP environments where Route Reflectors (RR) are used. It prevents from misconfiguration of RR, by ignoring  duplicate prefixes that a client has advertised and received back.
  • Cluster List (optional) – helps preventing loops when using multiple clusters of Route Reflectors (in redundant HA mode). Cluster List operates much like AS Path does, collecting the sequence of Cluster IDs through which the update has traversed. This attribute is also exclusive for iBGP environments, and will not traverse to eBGP peers

Finally the BGP decision process hierarchy, from highest to lowest. BGP will chose the best path considering the many attributes associated with the multiple copies of one prefix, instead of the cost or metric like IGPs. Since the attributes can be changed by the administrator, the best path configuration is indeed based on the preferences of the administrator. BGP will also maintain several paths in its table, so that when a prefix is no longer available (for example due to a link failure which BGP monitors through its keep-alive messages in the TCP session) a new best path is populated in the routing table.

Whenever a tie, move to next lower level in order to choose the best path chosen to populate the routing table:

  • Next hop reachable – a route must exist to next hop IP address, and will not be considered if not reachable
  • Preferred Value – the highest preferred value will be chosen. It is a proprietary parameter and local to the router.
  • Local preference – the highest local preference value will be chosen. The policy is local to the AS
  • Locally originated – prefix originated by the local router
  • Shortest AS Path – shared throughout between local and destination.
  • Origin – “i” preferred over “?”
  • Multi-Exit Discriminator – influences neighboring AS only
  • External BGP versus internal BGP – eBGP preferred over iBGP
  • Router-ID – the lowest value will be chosen. It is the final tiebraker

iBGP basics

BGP peers that belong to the same Autonomous System (AS) are considered iBGP peers. Why is this important? Because iBGP behavior is different from eBGP, even though the commands might be quite similar. Here is a summary of the differences:

  • AS-Path is only pre-pended at eBGP border, not in iBGP. iBGP has thus its own loop prevention mechanism, which consists of prohibiting the advertising of iBGP prefixes from other iBGP peers amongst themselves
  • BGP sets the TTL in its messages’ IP packet equal to one (1), so that it is restricted to one hop. In iBGP TTL is set to the maximum value of 255, as connections between iBGP peers may be multiple hops away
  • BGP attributes are not changed within iBGP communications. Next-hop remains the eBGP next-hop. Moreover, Local preference attribute will only remain within iBGP peers and will not traverse to neighboring AS.
  • Route selection process will prefer an eBGP route over iBGP route when AS-Path is the same.

It is the IGP’s responsibility to find a path to the loopback’s interface. However, if the IGP process fails, iBGP will also fail. So the first troubleshooting task should be confirming if both routers can reach the peer’s loopback interface.

Since best practices recommend using loopback interfaces for establishing connection with iBGP peers redundancy reasons, remember to advertise each peer’s loopback interface into the IGP.

On the other hand loop prevention mechanism is different as well between eBGP and iBGP. eBGP uses AS Path attribute to guarantee loop free behavior, where iBGP uses almost sacred rules in terms of prevention:

  • Prefixes received from an eBGP peer will always be advertised to all other BGP peers (in other words, directly connected)
  • Prefixes received from iBGP peers are only sent to eBGP peers.

So by not advertising iBGP prefixes from other iBGP peers amongst themselves, iBGP is able to prevent loops. However the problem being is that such functioning mechanism requires full-mesh topology between iBGP peers. If not in full-mesh, a second hop away iBGP peer router may not receive certain eBGP routes, breaking reachability.

However, since full-mesh topology requirement makes it quite hard to scale, another mechanism was created, which explicitly breaks the stated above rules about iBGP loop prevention mechanism: Route Reflectors (RR). RR allow one iBGP Router to send prefixes to another iBGP peer (client). So the RR iBGP client does not need to be fully meshed, it only needs to maintain a session with the RR Router.

RR iBGP routers should mirror prefixes to its iBGP RR client with BGP attributes unchanged. Note that you can configure 1:N relationship in terms of iBGP RR router and several iBGP RR clients. Also noteworthy in terms of scalability is the fact that a RR client can also be a RR router for other RR clients, and of the same routes. However the more you cascade, the bigger the risk, since RR Routers represent a Single Point of Failure (SPOF). It is always a best practice to configure a redundant Route reflector, acting as a cluster (so that updates are not duplicated by the reflectors).

Moreover, you can have an hibrid iBGP AS, where you use Route Reflectors for some non fully meshed iBGP routers, and fully meshed another set of routers that follow traditional iBGP rules.

Finally Originator ID attribute and Cluster List attribute can prevent from misconfigurations when using RR.

New HP VC Cookbook for iSCSI

Even though its been here for such a long time, iSCSI SANs still have not convinced everyone. Though I do not want to go through that discussion, every help one can get on recommendations how to set it up is helpful. HP just released its “HP Virtual Connect with iSCSI“, so here are some notes about it.

  • Array supportability: Any Array with iSCSI ports.
  • You can use Accelerated iSCSI (and NIC behaves like an iSCSI HBA), if you choose Blade NICs that support so. Max MTU size in such scenario is limited to 8342 bytes, unchangeable. Both on Windows and VMware you have no control, as this is automatically negotiated (I am still refering on Accelerated iSCSI option). On Windows Box, when TCPMSS displays 1436, the MTU negotiated is 1514, and when it displays 8260 the MTU negotiated is 8342.
  • Note that though you can directly connect Storage Host ports to Virtual Connect (except with HP P4000 or any other IP-Clustered Storage), I would definetely not do so, since it limits your options. VC does not behave as a Switch in order to prevent loops and simplify Network management, so traffic will not be forwarded out of the Enclosure (say for instance if you had another Rack Server Host wanting iSCSI). This is also the reason you cannot setup more than one box of HP P4000 to it, since you do require inter box communication for metadata and cluster formation.
  • Do not forget iSCSI basics: Keep it L2, enable 802.3x Flow control everywhere (Storage Ports, Switch ports, Virtual Connect uplink ports (enabled by default on downlink ports, and Host ports if using Software iSCSI) enable Jumbo Frame support on OS level if you are using Software iSCSI (instead of Accelerated iSCSI), configure iSCSI multipathing when possible (either by using the Storage vendor DSM, or if possible the OS own MPIO), dedicate at least an isolated VLAN or with dedicated physical devices (Switches), and finally isolate at least a FlexNIC on the Host for iSCSI traffic.


This figure illustrates a mapping of VC config from the Blade’s FlexNICs, to interior of VC (two SUS with corporate VLANs plus dedicted vNet for iSCSI VLAN, and exterior VC uplinks. For redundancy reasons and to limit contention between Downlinks and Uplinks, one would recommend using at least two Uplink Ports on each VC module dedicated to the iSCSI vNet. Whenever a VC module has a one-to-one relationship towards the upstream ToR switch (or several ToR switches when using MLAG, such as HP IRF, Cisco Catalyst VSS or Nexus vPC, etc). When configuring the iSCSI vNets, make sure you enable “Smart Link” feature, to ensure for faster failovers.

You might also want to take advantage of new VC firmware 4.01 features, which include two helpful ones. The first is flexible overprovision of Tx Bandwidth. Ensure a minimum pipeline for that iSCSI Host port, and let it fly (by assigning higher Max Bandwidth) if other pipes are empty on other FlexNICs.

Finally, the second concerns QoS. You might want to use a dedicated 802.1p class for your iSCSI traffic, which is mapped for Egress traffic.

Careful with that dual-hop FCoE setup with HP Virtual Connect and Nexus 5500/5000

HP just recently launched its new Firmware release, the 4.01 – for its Blade Interconnect darling, the Virtual Connect. You can find the release notes here. Also noteworthy are the cookbooks, and HP just released its “Dual-Hop FCoE with HP Virtual Connect modules Cookbook” .

One of the new features is dual-hop FCoE. What this means is that until so far you had only one hop FCoE from Virtual Connect to the server Converged Network Adaptor (CNA). This facilitates quite a lot FCoE implementation, since you don’t need any of the DCB protocols – its only one hop. Starting from version 4.01 you can now have an uplink connection where you pass FCoE traffic.


The VC serves thus as a FIP-snooping device and the upstream switch as Fiber Channel Forwarder (FCF), in case you want to have retrocompatibility with former existing FCP environments. Please note that only a dual-hop topology is supported. You cannot continue hopping FCoE traffic accross your Network. Well you can, but its just not supported.Dual-hp-FIP-snooping

Some important considerations:

  • On HP side, only VC FlexFabric (FF) and Flex10/10D are able to do dual-hop FCoE. On Cisco’s side, only Nexus 5500 and 5000 (NX-OS version 5.2(1)N1(3)) are supported.
  • Only Nexus FCF mode is supported (NPV mode is not supported), and Nexus ports must be configured as trunk ports and STP edge ports;
  • VC-FF, only ports X1 to X4 support FCoE; VC Flex10/10D supports using all its Uplinks;
  • Only VC uplink Active/Active design is supported; Active/Standby design will not be supported due to potential extra-hop on VC stacking links due to misconfiguration on Server profile;
  • Cross-Connect links between VC uplinks to Nexus are not supported. Even if you’re using vPC, it will be a design violation of traffic mix in SAN A (say connected to Nexus 01) and SAN B (say connected to Nexus 02).

VCFF - Dual-hp-constraints

  • Moreover, if you want to converge all traffic on the same uplink LAG ports, you will have to have a single Shared Uplink Set (SUS) per VC. Note that this SUS can only have one FCoE Network.

Dual-hop SUS

  • However, if you have more uplink portson your VCs available, then consider seperating Ethernet traffic from Ethernet traffic, using SUS for Ethernet, and a vNet for the FCoE traffic. So in this scenario, and when using vPC on the Nexus it is still advisable to cross-connect VC SUS Uplinks from the same VC Module to different Nexus for pure Ethernet traffic.


  • Note: Remember VC rules. You assign uplinks from one VC module to one SUS and uplinks from anotherdifferent VC module to the other SUS. It is very important that you get this right, as VC modules are not capable of doing IRF withemselves (yet). More on how setup VC with IRF here.


  • So when using port-channels on VC FCoE ports, you will need to configure ports on the Nexus to belong to the same Unified Port Controller (UPC) ASIC. Nexus 5010/5020 support a maximum of 4 ports when carrying FCoE traffic, 5548/5596 a maximum of 8.


More on the VC setup and installation “HP Virtual Connect for c-Class BladeSystem Version 4.01 User Guide” here.

Disclamer: note that these are my own notes. HP is not responsable for any of the content here provided.

Setup for VMware, HP Virtual Connect, and HP IRF all together

Trying to setup your ESXi hosts networking with HP Virtual Connect (VC) to work with your HP’s IRF-Clustered ToR switchs in Active-Active mode?


This setup improves performance, as you are able to load balance traffic from several VMs across both NICs, across both Virtual Connect modules, and across both ToR switchs, while in the meanwhile gaining more resilience. Convergence on your network will be much faster, either if a VC uplink fails, a whole VC module fails, or a whole ToR fails.

Here’s a couple of docs that might help you get started. First take a look on the IRF config manual of your corresponding HP’s ToR switches. Just as an example, here’s the config guide for HP’s 58Xo series. Here are some important things you should consider when setting up an IRF cluster:

  1. If you have more than two switches, choose the cluster topology.  HP IRF allows you to setup a daisy-chained cluster, or in ring-topology. Naturally the second one is the recommended for HA reasons.
  2. Choose which ports to assign to the cluster. IRF does not need specific Stacking modules and interfaces to build the cluster. For the majority of HP switchs, the only requirement is to use 10GbE ports, so you can flexibly choose whether to use cheaper CX4 connections, or native SFP+ ports (or modules) with copper Direct Attach Cables or optical transcevers. Your choice. You can assign one or more physical ports into one single IRF port. Note that the maximum ports you can assign to an IRF port varies according to the switch model.
  3. Specify IRF unique Domain for that cluster, and take into consideration that nodes will reboot in the meanwhile during the process, so this should be an offline intervention.
  4. Prevent from Split-brain Condition potential events. IRF functions by electing a single switch in the cluster as the master node (which controls Management and Control plane, while data plain works Active-Active on all nodes for performance). So if by any reason stacking links were to fail, slave nodes by default initiate new master election, which could lead into a split-brain condition. There are several mechanisms to prevent this front happening (called Multi-Active Detection (MAD) protection), such as LACP MAD or BFD MAD.

Next hop is your VC. Whether you have a Flex-Fabric or a Flex-10, in terms of Ethernet configuration everything’s pretty much the same. You setup two logically identical Shared Uplink Sets (SUS) – note that VLAN naming needs to be different though inside the VC. Next you assign uplinks from one VC module to one SUS and uplinks from another different VC module to the other SUS. It is very important that you get this right, as VC modules are not capable of doing IRF withemselves (yet).

If you have doubts on how VC works, well nothing like the VC Cookbook. As with any other documentation that I provide with direct links, I strongly recommend that you google them up just to make sure you use the latest version available online.

If you click on the figure above with the physical diagram you will be redirected to HP’s Virtual Connect and IRF Integration guide (where I got the figure in the first place).

Last hop is your VMware hosts. Though kind of outdated document (as Vmware already launched new ESX releases after 4.0), for configuration purposes the “Deploying a VMware vSphere HA Cluster with HP Virtual Connect FlexFabric” guide already allows you to get started. What you should take into consideration is that you will not be able to use the Distributed vSwitch environment with new vmware’s LACP capabilities, which I’ll cover in just a while. This guide provides indications on how to configure in a standard vSwitch or distributed setup on your ESX boxes (without using VMware’s new dynamic LAG feature).

Note that I am skipping some steps on the actual configuration, such as the Profile configuration on the VC that you need to apply to the ESX hosts. Manuals are always your best friends in such cases, and the provided ones should provide for the majority of steps.

You should make sure that you use redundant Flex-NICs if you want to configure your vSwitchs with redundant uplinks for HA reasons. Flex-NICs are present themselves to the OS (in this case ESXi kernel) as several distinct NICs, when in reallity these are simply Virtual NICs of a single physical port. Usually each half-height HP Blade comes with a single card (the LOM), whcih has two physical ports, each of which can virtualize (up to date) four virtual NICs. So just make sure that you don’t choose randomly which Flex-NIC is used for each vSwitch.

Now comes the tricky part. So you should not that you are configuring Active-Active NICs for one vSwitch.


However, in reality these NICs are not touching the same device. Each of these NICs is mapped statically to a different Virtual Connect module (port 01 to VC module 01, and port 02 to VC module 02). Therefore in a Virtual Connect environment you should note that you cannot choose the load balancing algorithm on the NICs based on IP-hash. Though you can choose any other algorithmn, HP’s recommendation is using Virtual Port ID, as you can see on the guide (this is the little piece of information missing on VC Cookbook on Active-Active config with Vmware).

Finally, so why the heck can’t you use IP-hash, nor VMware’s new LACP capabilities? Well  IP-Hash is intended when using link aggregation mechanisms to a single switch (or Switch cluster like IRF, that behaves and is seen as a single switch). As a matter a fact, IP-SRC-DST is the only algorithm supported for NIC teaming on the ESX box as well for the Switch when using port trunks/EtherChannels:

” […]

  • Supported switch Aggregation algorithm: IP-SRC-DST (short for IP-Source-Destination)
  • Supported Virtual Switch NIC Teaming mode: IP HASH
  • Note: The only load balancing option for vSwitches or vDistributed Switches that can be used with EtherChannel is IP HASH:
    • Do not use beacon probing with IP HASH load balancing.
    • Do not configure standby or unused uplinks with IP HASH load balancing.
    • VMware only supports one EtherChannel per vSwitch or vNetwork Distributed Switch (vDS).

Moreover, VMware explains in another article: ” What does this IP hash configuration has to do in this Link aggregation setup? IP hash algorithm is used to decide which packets get sent over which physical NICs of the link aggregation group (LAG). For example, if you have two NICs in the LAG then the IP hash output of Source/Destination IP and TCP port fields (in the packet) will decide if NIC1 or NIC2 will be used to send the traffic. Thus, we are relying on the variations in the source/destination IP address field of the packets and the hashing algorithm to provide us better distribution of the packets and hence better utilization of the links.

It is clear that if you don’t have any variations in the packet headers you won’t get better distribution. An example of this would be storage access to an nfs server from the virtual machines. On the other hand if you have web servers as virtual machines, you might get better distribution across the LAG. Understanding the workloads or type of traffic in your environment is an important factor to consider while you use link aggregation approach either through static or through LACP feature.

So given the fact that you are connecting your NICs to different VC modules (in a HP c7000 Enclosure), the only way you will be able to have active-active teaming is with static etherchannel, and without IP-Hash.

None-the-less please note that if you were configuring for instance a non-blade server, such as a HP Dl360, and connecting it to an IRF ToR cluster, then in that case you would be able to use vDS with LACP feature, and thus use IP-Hashing. Or if you were using a HP c3000 Enclosure, which is usually positioned for smaller enviroments. So it does not make that much sense to be using a c3000 and in the meanwhile having the required vSphere Enterprise Plus licensing.

That’s it, I suppose. Hopefully this overview should already get your ESX farm up-and-running.


Disclamer: note that these are my own notes. HP is not responsable for any of the content here provided.

HP’s new Switching platform 11900

HP showcased one of its soon to release new big&mean switching platform in InterOp 2013, the 11900, and today you can already get prices on this peace. Although having been considered hottest products in InterOp 2013, if you ask me, this might not be a game changer for HP’s portfolio as I believe the 12900 might be when it releases. But it is interesting enough to be noted.

This box is positioned for aggregation layer in the Datacenter (HP’s FlexFabric Portfolio), right next to today’s main Datacenter core platform, the 12500. Although probably a lot of work like me in countries qith “slightly” different companies as the US does. In countries where big companies considering substituting their Cisco 6500 with a 11900 might be more than enough, and therefore surely suffice as a core.

So we are talking about another platform with CLOS architecture designed to provide a non-blocking architecture with 4 Fabric Modules (each with 3x 40Gbps per I/O line card), with performance figures of 7,7Tbps, 5.7 Mpps, and achieving latency levels of 3 μs.

As for scalability, we are talking about being able to scale up to 64x 40GbE ports (non-blocking), and 384x 10GbE (also non-blocking) now-a-days. As a matter a fact, technically each I/O line card has 480Gbps (4x3x40) of total backend bandwidth,

Anyway, as you may already suspect, it does indeed run HP’s new version of Network OS, the Comware 7 (Cw7), and will therefore also contain almost all of the cool “Next-Generation” Datacenter features, namely:

  • DCB and FCoE
  • OpenFlow 1.3 (thus standards-based SDN-ready)
  • Though not available in this first release, MDC (context/ Virtual Switchs inside your chassis box) and SPB (sort of alternative to TRILL) will also become available

You might be wondering why the hell have a new Box, when HP has just released new management modules for the 10500, which also bring Comware 7 to it, and some of its features. Note that the 10500 is positioned for Campus-Core, not DC. As such, it will not support features as DCD/FCoE and EVB/VEPA, and those the major differences in the mid-term that you can count on.

As for it being positioned as a Core platform, please note that when it comes to scalability numbers in terms table size of FIB, ARP, MAC, etc 11900 platform does not even scale as near as HP’s 12500. Along with high buffering capability, these might be important features in DC environments with high density and number of VMs.

Networktest also publiced its test results on the 11900. The tests consist essentially of a Spirent TestCenter hitting a L2&3 bombardment simultaneously on all 384 10Gbps ports (all 8 I/O slots filled with 48 10GbE line cards), and another bombardment simultaneously on all 64 40Gbps ports (all 8 I/O slots filled with 8 40GbE line cards).

Disclamer: note that these are my own notes. HP is not responsable for any of the content here provided.