No matter how well planning is attended to; life is good at challenging that. It’s a little late but here it is. I am very pleased to announce the SP Handbook is now available for purchase.
Not so long ago, Mr Vivek Tivari from http://www.2doubleccies.com contacted me and asked if I would be interested in writing a review for a book that himself and Mr Dean Bahizad wrote. Being always intrigued by what others have done and whether finding use for my own or the benefits of others, I accepted the request.
Vivek, (CCIE# 18616) and Dean, (CCIE# 18887) both have double CCIEs – R&S and SP. While preparing for their CCIE exams, they realised (like many other candidates) that there was a portion of the CCIE cycle lacking material. There are many books on theory and technology, ample lab work books and a multitude of microblogs/study groups available. However, some of the important requirements for successfully studying for a CCIE exam, such as the level of commitment required, a sound approach to studying and an effective strategy, are not to be found in any single publication, or website. Some necessary information is scattered among various microblogs and study groups, but spending time searching for it makes little sense. Often the same questions regarding these topics are asked in forums and study groups.
The aim of the guide “Your CCIE Lab Success Strategy” is to coalesce all this non-technical information into a single book.
An interesting client problem in one of our multi-tenant data centers came to my attention the other day. A delay sensitive client noticed a slight increase in latency (20 ms) at very intermittent intervals from his servers in our data center to specific off-net destinations. The increase in latency was localized to the pair of Nexus 7000′s functioning as the core switch layer (CSW) and the layer3 edge for this particular data center. Beyond that all appeared normal on the N7K CSWs.
A TCP dump from a normal trunk interface attached to the N7Ks, showed unicast traffic on the N7K-2 device when the N7K-1 device was setup to receive internet traffic inbound and forward it into the data center client VLANs. The N7Ks are setup using the Cisco VPC (Virtual Port Channels).
We all too familiar with the devastating impact a talented layer 2 loops could have on a data center lacking sufficient controls and processes being in place. If you are using Cisco Nexus switches in your data center, you would be happy to know that NX-OS offers an interesting new tool you should add to your loop detection list. The somewhat undocumented feature is known as (for the lack of a better name) FWM-Loop Detection. FWM refers to the NX-OS Forwarding Manager.
Here is an old post I never finished. With the benefits of the Nexus 2000 and the FEX architecture (a earlier post), scalability, simplified management, flexibility, Cisco extended its use further into the servers all the way up to the virtual hosts.This allows much greater control and flexibility. After all network guys should look after all aspects of networking, server guys should look after the servers and today virtual hosts.
A summary of the different FEX implementations:
Read the rest of this entry »
I have used my iPad to console onto Cisco routers and switches for about 2 years now. I started using the Flex-Serial cable on my jailbroken iPad and iPhone, with the iSSH app and a ported version of Minicom (earlier blog post). Amidst some minor bugs and irritations this worked well and was considerably more convenient than carrying a laptop around the data centers. Earlier this year I ordered the RedPark RS232 cable from Get-Console.com, since the Flex-Serial cable was not available anymore. (It’s easy to notice to wear on my Flex-Serial cable). I have used the Get-Console solution ever since and will share the other reasons why I switched and give a product review. If you been thinking of getting this, it might be in your best interested to read this post.
The Redpark cable
Let me first compare the RedPark and the Flex-Serial cables.
“Fabric” is a loosely used term, which today creates more confusion instead of offering direction.
What exactly is a Fabric ? What is a Switch Fabric?
Greg Ferro did a post here explaining how Ethernet helped the layer 2 switch fabric evolve. Sadly the use of switch fabric did not stop there. And this is the part where the confusion trickles in.
The term fabric has been butchered (mostly by marketing people) to incorporate just about any function these days. The term ‘switch fabric’ today (in the networking industry) is broadly used to describe among others the following:
- The structure of an ASIC, e.g., the cross bar silicon fabric.
- The hardware forwarding architecture used within layer2 bridges or switches.
- The hardware forwarding architecture used with routers, e.g., the Cisco CRS and its 3-stage Benes switch fabric.
- Storage topologies like the fabric-A and fabric-B SAN architecture.
- Holistic Ethernet technologies like TRILL, Fabric-Path, Short-Path Bridging, Q-Fabric, etc.
- A port extender device that is marketed as a fabric extender (a.k.a. FEX) namely the Cisco Nexus 2000 series.
In short, a switch fabric is basically the interconnection of points with the purpose to transport data from one point to another. These points, as evolved with time, could represent anything from an ASIC, to a port, to a device, to an entire architecture.
Cisco added a whole new dimension to this by marketing a Port Extender device as a Fabric Extender and doing so with different FEX architectures namely VM-FEX and Adapter FEX…. More on that in the next post. :)