Tuesday, January 14, 2014

Core router sales to pick up

 Carrier routing and switching worldwide saw a 14 percent sequential increase and a 5 percent year-over-year increase, and is now a $3 billion market, according to ACG Research. Cisco (Nasdaq: CSCO), as usual, topped the list of vendors with $1.52 billion in revenues, followed by Alcatel-Lucent (NYSE: ALU) and Juniper Networks (NYSE: JNPR). Core routing remains soft as carriers moving toward 100G stay cautious about spending, with revenues at $590 million, down 6.6 percent compared to the same period last year. But sequentially, core routing is up 7.4 percent. "Core has been in a soft cycle but we anticipate growth as the delays in upgrades are now starting to be addressed," said  Ray Mota, ACG Research founder. Post
Carrier routing and switching leaders
Posted by at No comments:

Check your link

http://downforeveryoneorjustme.com/
Posted by at No comments:

CIO update: Post-mortem on the Skype outage

Courtesey : http://blogs.skype.com/2010/12/29/cio-update/

CIO update: Post-mortem on the Skype outage

12/29/2010 in Big Blog by
As a follow-up to last week’s outage, here is a detailed explanation of what transpired, the root cause, and plans to mitigate this from happening again in the future. For starters, it helps to understand that Skype is based on a peer-to-peer (P2P) network, which is explained here. Last week, the P2P network became unstable and suffered a critical failure. The failure lasted approximately 24 hours from December 22, 0800 PST/1600 GMT to December 23, 0800 PST/1600 GMT.

What was the cause for the failure?

On Wednesday, December 22, a cluster of support servers responsible for offline instant messaging became overloaded. As a result of this overload, some Skype clients received delayed responses from the overloaded servers. In a version of the Skype for Windows client (version 5.0.0152), the delayed responses from the overloaded servers were not properly processed, causing Windows clients running the affected version to crash.
Users running either the latest Skype for Windows (version 5.0.0.156), older versions of Skype for Windows (4.0 versions), Skype for Mac, Skype for iPhone, Skype on your TV, and Skype Connect or Skype Manager for enterprises were not affected by this initial problem.
However, around 50% of all Skype users globally were running the 5.0.0.152 version of Skype for Windows, and the crashes caused approximately 40% of those clients to fail. These clients included 25–30% of the publicly available supernodes, also failed as a result of this problem.

If approximately 20% of total Skype clients failed, why was there a much bigger disruption to Skype functionality?

Although Skype staff responded quickly to disable the overloaded servers and to eliminate client requests to them, a significant number of supernodes had already failed. A supernode is important to the P2P network because it takes on additional responsibilities compared to regular nodes, acting like a directory, supporting other Skype clients, helping to establish connections between them and creating local clusters typically of several hundred peer nodes per each supernode.
Once a supernode has failed, even when restarted, it takes some time to become available as a resource to the P2P network again. As a result, the P2P network was left with 25–30% fewer supernodes than normal. This caused a disproportionate load on the remaining available supernodes.

Why weren’t the other supernodes available to help?

The failure of 25–30% of supernodes in the P2P network resulted in an increased load on the remaining supernodes. While we expect this kind of increase in the instance of a failure, a significant proportion of users were also restarting crashed Windows clients at this time. This massively increased the load as they reconnected to the peer-to-peer cloud. The initial crashes happened just before our usual daily peak-hour (1000 PST/1800 GMT), and very shortly after the initial crash, which resulted in traffic to the supernodes that was about 100 times what would normally be expected at that time of day.
Supernodes have a built in mechanism to protect themselves and to avoid adverse impact on the systems hosting them when operational parameters do not fall into expected ranges. We believe that increased load in supernode traffic led to some of these parameters exceeding normal limits, and as a result, more supernodes started to shut down. This further increased the load on remaining supernodes and caused a positive feedback loop, which led to the near complete failures that occurred a few hours after the triggering event.
Regrettably, as a result of the confluence of events – server overload, a bug in Skype for Windows clients (version 5.0.0.152), and the decline in available supernodes – Skype’s functionality became unavailable to many of our users for approximately 24 hours.

How did Skype help support supernode recovery?

In order to restore Skype functionality, the Skype engineering and operations team introduced hundreds of instances of the Skype software into the P2P network to act as dedicated supernodes, which we nick-named “mega-supernodes,” to provide enough temporary supernode capacity to accelerate the recovery of the peer-to-peer cloud.
By late Wednesday night (PST) it was evident that only a proportion (about 15-20%) of Skype users connections were ‘healing’ and the volume of load on the supernodes continued to be unusually high. In response, our team introduced several thousand more mega-supernodes through the night. During Wednesday night, full recovery of the P2P network was underway and the majority of users were able to connect to the P2P network normally by early morning (California-PST) on December 23rd.
As we reported during the incident, in order to recover the core Skype functionality as quickly as possible, we utilized resources normally used to support Group Video Calling, to deploy supernodes, and over the course of Thursday night and Friday morning we returned these to their normal use and restored Group Video Calling functionality in time for Christmas.
The supernodes stabilized overnight on Thursday and by Friday, several tens of thousands of supernodes were supporting the P2P network. During Friday, we withdrew a significant proportion of the mega-supernodes from service, leaving some in operation to ensure stability of the P2P network over Christmas and New Year.

What is Skype doing to prevent this from happening again?

We understand how important the reliability, security and quality of our software is to Skype users around the world, and we work hard to maintain high standards, as well as develop new features and products.
First, we will continue to examine our software for potential issues, and provide ‘hotfixes’ where appropriate, for download or automatic delivery to our users. Since a bug was identified in Skype for Windows (version 5.0.0.152), we had provided a fix to v5.0 of our Windows software prior to the incident, and we will provide further updates for download this week. We will also be reviewing our processes for providing ‘automatic’ updates to our users so that we can help keep everyone on the latest Skype software. We believe these measures will reduce the possibility of this type of failure occurring again.
Second, we are learning the lessons we can from this incident and reviewing our processes and procedures, looking in particular for ways in which we can detect problems more quickly to potentially avoid such outages altogether, and ways to recover the system more rapidly after a failure.
Third, while our Windows v5 software release was subject to extensive internal testing and months of Beta testing with hundreds of thousands of users, we will be reviewing our testing processes to determine better ways of detecting and avoiding bugs which could affect the system.
Finally, as we continue to grow, we will keep under constant review the capacity of our core systems that support the Skype user base, and continue to invest in both capacity and resilience of these systems. An investment program we initiated a year ago has significantly increased our capacity already and more investment is planned for 2011 both to support the ongoing roll out of our paid and enterprise products, and to continue to support the growth of our core Skype software that we know millions of users rely on every day.
We are truly grateful to all of our users and humbled by your continued support. We know how much you rely on Skype, and we know that we fell short in both fulfilling your expectations and communicating with you during this incident. Lessons will be learned and we will use this as an opportunity to identify and introduce areas of improvement to our software, further assess and invest in capacity and stability, and develop better processes for outage recovery and communications to our user base. Thank you to everyone.
Posted by at No comments:

Friday, January 3, 2014

SDN Uncovered

Take 2 on my experience in SDN and how things are as off start of 2014.
http://www.cisco.com/en/US/prod/collateral/iosswrel/content/at_a_glance_c45-708540.pdf
http://www.networkcomputing.com/software-defined-networking-comparisons/


Company Product More Coverage
Cisco Systems
Cisco Systems
Cloud ConnectInterOp
BlackHat
C A S
Cisco entered offerings in our controllers, applications and switches categories under the umbrella of its Cisco ONE Portfolio. The Cisco Open Networking Environment SDN controller supports version 1.0 of the OpenFlow standard alongside the Cisco onePK spec. VM support includes ESX, HyperV and KVM via Nexus 1000V. Applications are under the Monitor Manager NSM system. Switches/vswitches are based on onePK and support C, Java and Python APIs. More Detailed Product Information
HP
HP
Cloud ConnectInterOp
BlackHat
C A S
HP offers a complete portfolio of OpenFlow hardware and software, the heart of which is the HP Virtual Application Networks SDN controller. Available as either a software virtual appliance or 2U, quad-core hardware box, it supports OpenFlow versions 1.0 and 1.3 and includes published northbound APIs to enable third-party SDN applications. Four applications are already available: HP Sentinel Security, Virtual Cloud Network portal, Microsoft Lync UC&C and the IMC VAN SDN Manager. HP also has more than 40 OpenFlow-compliant switches, ranging from entry-level products to its just-announced modular 12900 data center core switch, which sports a 36 Tbps switching backplane and up to 16 slots for a maximum of 768 10GbE or 64 100GbE ports. More Detailed Product Information
Juniper
Juniper
InterOpBlackHat
S
Juniper's EX9200 Programmable Switch supports OpenFlow 1.3 and comes in four models. The 6U EX9204 delivers four slots, the EX9208 offers eight slots in an 8U chassis and the 16U EX9214 sports 14 slots. Southbound API support includes Puppet and NetConf; support for the OpenStack Quantum plug-in is planned. The EX9200 can simultaneously handle IP, MPLS, CAPWAP termination, GRE, VPLS, policy/forwarding decisions and new SDN protocols. More Detailed Product Information
Netsocket
Netsocket
Cloud ConnectInterOp
C A S
Netsocket Virtual Network is compatible with OpenFlow 1.0 and Microsoft's vSwitch and Hyper-V, users of which can get started now at no cost. Hardware requirements are straightforward: 64-bit X86, 1 core, 1 GB RAM. The system supports Openstack and RADIUS for user authentication More Detailed Product Information More Detailed Product Information
Nuage Networks (an Alcatel-Lucent venture)
Nuage Networks
Cloud ConnectInterOp
C
Nuage Networks' Virtualized Services Platform (VSP) is based on OpenFlow and is agnostic in terms of physical switches supported. Hypervisor support is likewise broad and includes KVM, Xen, ESXi and Hyper-V. Nuage partners for services support include F5 Networks, Palo Alto More Detailed Product Information
Enterasys
Enterasys
InterOp
C S O
Enterasys has offerings in three of our four catgories. Its OneFabric line lacks OpenFlow support, but the controller sports an integrated GUI for end-to-end network management and an open northbound API. Its entire switch line is SDN-compatible, and support extends to switching, routing and wireless networking gear. More Detailed Product Information
Extreme Networks
Extreme Networks
BlackHat
S
Extreme Summit X440 Series The Summit devices run ExtremeXOS implementations of OpenFlow APIs and come in 10 variants with aggregated bandwidth ranging from 64 Gbps to 134 Gbps. The devices are OpenStack compatible through the Extreme Networks Quantum plug-in. TRILL support is due in Q4. More Detailed Product Information
NEC
NEC
InterOp
C A S
NEC's ProgrammableFlow Controller line is built on OpenFlow 1.0, with OpenFlow 1.3 on the roadmap, and sports a list of compatible software ranging from DoS attack mitigation to QoS to VRRP. NEC has committed code to the open source Open Daylight program and demonstrated interoperability at Interop, PlugFest and ONS with Arista, Brocade, Centec, Dell, Extreme and IBM gear. The PF5240 hybrid switch was named Best of Interop in Infrastructure in 2011 and was the first OpenFlow hybrid switch offered on a commercial basis. More Detailed Product Information
Tail-f Systems
Tail-f Systems
InterOp
C A
Tail-f embraces both top-down and bottom-up approaches to SDN, with support for OpenFlow (1.0 now, 1.3 later this year) and transaction-safe northbound APIs across OpenFlow and legacy devices. More Detailed Product Information
Big Switch Networks
Big Switch Networks
C A S
Big Switch has offerings in three of our four catgories. Its well-known OpenFlow-based controller is available as a physical or virtual appliance that works with a long list of switches from most major hardware vendors. The Big Virtual Switch (network virtualization)and Big Tap (unified network visbility) applications integrate with the controller, and the Switch Light is a software platform for merchant-silicon-based physical and virtual switches within hypervisors. More Detailed Product Information
Embrane
Embrane
A
Embrane heleo is a platform for software-defined network services for load balancing, firewall, VPN termination and SSL offload. Virtual appliances run on any X86 server and can quickly scale up and down to meet demand. Management and provisioning are via the Embrane Elastic Services Manager. Embrane uses REST for communication up and down the stack and between the Elastic Services Manager and virtual appliances. More Detailed Product Information
Pica8
Pica8
A S
Pica8's open switches are white-box devices that run the company's open PicOS NOS. PicOS supports OpenFlow 1.2 and Open vSwitch .1.9. The switches are available in four configurations, with a maximum switching fabric capacity of 176 Gbps for 1 GbE and 1.28 Tbps for 10 GbE platforms. More Detailed Product Information
Plexxi

C A S
Plexxi has entries in three areas with its Switch, Control and API offerings. The Plexxi 1U optical switch comes in two models, the 1 and 1x, with 64 and 72 10 Gbps ports, respectively. The controller runs on Linux and uses the Plexxi Affinities standard REST interface northbound and JMS for southbound control. The Plexxi Affinity Topologies application works as part of Plexxi Control and supports vSphere, vCloudDirector, OpenStack and KVM. More Detailed Product Information
Posted by at No comments:

Tuesday, December 31, 2013

Slideshare collections

http://www.slideshare.net/yamahata/ryu-sdnframeworkupload

Posted by at No comments:

Monday, December 30, 2013

Startup's watch

Startups
http://extragr.am/
https://www.interviewstreet.com/recruit2/howitworks/
http://www.zohocorp.com/index.html
http://www.orangescape.com/
http://freshdesk.com/pricing
http://tenmiles.com
http://www.unmetric.com
http://www.xlabz.com
http://www.unilazer.com/

Article
http://profit.ndtv.com/news/industries/article-the-american-style-startup-takes-root-in-india-376276?pfrom=home-business

Ventures aka VC's
http://www.nexusvp.com/
http://www.jungle-ventures.com/
http://www.blumeventures.com/

Seed Fund
http://500.co/

Sample closed start up
http://www.crunchbase.com/company/stylezen
Posted by at No comments:

Monday, December 23, 2013

Cisco Nexus in Action


Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.0(4)SV1(1)
Overview
Download this chapter
OverviewOverview
Download the complete book
Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.0(4)SV1(1)Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.0(4)SV1(1) (PDF - 1 MB)
 Feedback

Table Of Contents

Overview
Information about the Cisco Nexus 1000V
VEM Port Model
VEM Virtual Ports
Virtual NICs
Virtual Ethernet Ports
Local Virtual Ethernet Ports
VEM Physical Ports
VMware NIC
Uplink Ports
Ethernet Ports
VSM Port Model
Virtual Ethernet Interfaces
Physical Ethernet Interfaces
Port Channel Interfaces
Switching Architecture in Cisco Nexus 1000V
Layer 2 Ethernet Switching
MAC Address Tables
VLANs
Private VLANs
IGMP Snooping
Related Topics

Overview

The Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.0(4)SV1(1) provides an overview of the available Layer 2 features and how to configure them.
This chapter includes the following sections:
•Information about the Cisco Nexus 1000V
•Layer 2 Ethernet Switching
•MAC Address Tables
•VLANs
•Private VLANs
•IGMP Snooping
•Related Topics

Information about the Cisco Nexus 1000V

This section includes the following topics:
•VEM Port Model
•VSM Port Model
•Switching Architecture in Cisco Nexus 1000V

VEM Port Model

The Cisco Nexus 1000V differentiates the following Virtual Ethernet Module (VEM) ports:
•VEM Virtual Ports
•VEM Physical Ports
Figure 1-1 shows how VEM ports are bound to physical and virtual VMware ports.
Figure 1-1 VEM Port View

VEM Virtual Ports

The virtual side of the VEM maps together the following three layers of ports:
•Virtual NICs
•Virtual Ethernet Ports
•Local Virtual Ethernet Ports

Virtual NICs

There are three types of Virtual NICs in VMware. The virtual NIC (vnic) is part of the VM, and represents the physical port of the host which is plugged into the switch. The virtual kernel NIC (vmknic) is used by the hypervisor for management, VMotion, iSCSI, NFS and other network access needed by the kernel. This interface would carry the IP address of the hypervisor itself, and is also bound to a virtual Ethernet port. The vswif (not shown) appears only in COS-based systems, and is used as the VMware management port. Each of these types maps to a veth port within Nexus1000V.

Virtual Ethernet Ports

A virtual Ethernet port (vEth) represents a port on the Cisco Nexus 1000V Distributed Virtual Switch. Cisco Nexus 1000V has a flat space of vEth ports, 0...n. These vEth ports are what the virtual "cable" plugs into, and are moved to the host that the VM is running on.
Virtual Ethernet ports are assigned to port groups.

Local Virtual Ethernet Ports

Each host has a number of local vEth (lvEth) ports. These ports are dynamically selected for vEth ports needed on the host.
Local vEths do not move, and are addressable by the convention, module/port number.

VEM Physical Ports

The physical side of the VEM includes the following from top to bottom:
•VMware NIC
•Uplink Ports
•Ethernet Ports

VMware NIC

Each physical NIC in VMware is represented by an interface called a VMNIC. The VMNIC number is allocated during VMware installation, or when a new physical NIC is installed, and remains the same for the life of the host.

Uplink Ports

Each uplink port on the host represents a physical interface. It acts a lot like an lvEth port, but since physical ports do not move between hosts, the mapping is 1:1 between an uplink port and a VMNIC.

Ethernet Ports

Each physical port added to Cisco Nexus 1000V appears as a physical Ethernet port, just as it would on a hardware-based switch.
Note The uplink ports are handled entirely by VMware, and are used to associate port configuration with VMNICs. There is no fixed relationship between the uplink number and VMNIC number, and these can be different on different hosts, and can change throughout the life of the host. On the VSM, the ethernet interface number, for example, ethernet 2/4, is derived from the VMNIC number, not the uplink number.

VSM Port Model

Figure 1-2 shows the VSM view of the network.
Figure 1-2 VSM View
The Virtual Supervisor Module (VEM) has the following ports or interfaces:
•Virtual Ethernet Interfaces
•Physical Ethernet Interfaces
•Port Channel Interfaces

Virtual Ethernet Interfaces

Virtual Ethernet interfaces (vEths) can be associated with any of the following:
•A virtual machine VNIC on the ESX host
•A virtual machine kernel NIC on the ESX host
•A virtual switch interface on an ESX COS host

Physical Ethernet Interfaces

Physical Ethernet interfaces (Eths) correspond to the physical NICs on the ESX host.

Port Channel Interfaces

The physical NICs of an ESX host can be bundled into a logical interface called a port channel interface.

Switching Architecture in Cisco Nexus 1000V

Each VEM attached to the VSM forwards traffic to and from the ESX server as an independent and intelligent line card. Each VLAN uses its forwarding table to learn and store MAC addresses for ports connected to the VEM.
Figure 1-3 shows the traffic flow between two VMs on different VEMs.
Figure 1-3 Traffic Flow Between VEMs

Layer 2 Ethernet Switching

The congestion related to high bandwidth and large numbers of users can be solved by assigning each device (for example, a server) to its own 10-, 100-, 1000-Mbps, or 10-Gigabit collision domain. Because each LAN port connects to a separate Ethernet collision domain, servers in a switched environment realize full bandwidth access.
Full duplex allows two stations to transmit and receive at the same time. This is unlike 10/100-Mbps Ethernet, which usually operates in half-duplex mode, so that stations can either receive or transmit but not both. When packets can flow in both directions simultaneously, the effective Ethernet bandwidth doubles. 1/10-Gigabit Ethernet operates in full-duplex only.
Each LAN port can connect to a single workstation or server or to another device through which workstations or servers connect to the network.
To reduce signal degradation, each LAN port is considered to be an individual segment. When stations connected to different LAN ports need to communicate, frames are forwarded from one LAN port to the other at wire speed to ensure full bandwidth for each session.

MAC Address Tables

To switch frames between LAN ports efficiently, a MAC addres table is maintained. The MAC address of the sending network is associated with the LAN port on which it was received. For more information about MAC address tables, see Chapter 2, "MAC Address Table."

VLANs

A VLAN is a switched network that is logically segmented by function, project team, or application, without regard to the physical locations of the users. VLANs have the same attributes of physical LANs, but you can group end stations even if they are not physically located on the same LAN segment.
Any switchport can belong to a VLAN, and unicast, broadcast, and multicast packets are forwarded and flooded only to end stations in that VLAN. Each VLAN is considered a logical network, and packets destined for stations that do not belong to the VLAN must be forwarded through a bridge or a router.
All ports, including the management port, are assigned to the default VLAN (VLAN1) when the device first comes up.
The devices support 4094 VLANs in accordance with the IEEE 802.1Q standard. These VLANs are organized into several ranges for different uses. Some of these VLANs are reserved for internal use by the device and are not available for configuration
Note Inter-Switch Link (ISL) trunking is not supported by the Cisco Nexus 1000V.
See Chapter 3, "VLAN Configuration" for complete information on configuring VLANs.

Private VLANs

Private VLANs (PVLANs) are used to segregate Layer 2 ISP traffic and convey it to a single router interface. PVLANs achieve device isolation by applying Layer 2 forwarding constraints that allow end devices to share the same IP subnet while being Layer 2 isolated. In turn, the use of larger subnets reduces address management overhead.

IGMP Snooping

The Internet Group Management Protocol (IGMP) snooping software examines Layer 2 IP multicast traffic within a VLAN to discover the ports where interested receivers reside. Using the port information, IGMP snooping can reduce bandwidth consumption in a multi-access LAN environment to avoid flooding the entire VLAN. The IGMP snooping feature tracks which ports are attached to multicast-capable routers to help the routers forward IGMP membership reports. The IGMP snooping software responds to topology change notifications. By default, IGMP snooping is enabled on the device. For more information, see Chapter 5, "IGMP Snooping Configuration."

Related Topics

The following documents contain related information:
•Cisco Nexus 1000V Interface Configuration Guide, Release 4.0(4)SV1(1)
•Cisco Nexus 1000V Port Profile Configuration Guide, Release 4.0(4)SV1(1)
•Cisco Nexus 1000V Security Configuration Guide, Release 4.0(4)SV1(1)
•Cisco Nexus 1000V System Management Configuration Guide, Release 4.0(4)SV1(1)
Posted by at No comments:
Subscribe to: Posts (Atom)

bee-social