The Nexus 2000->5000 design does require looking at things a bit differently than you have in the past. Data Center architecture is changing fast due to the rapid onset of Data Center virtualization. Server & Storage administrators have been struggling with this change as well, this isn't something unique to the Network.
There is a tendency to view the Nexus 2000 as a switch. And understandably so because it's packaged like a switch, looks like a switch, and installs in the rack like a switch. Because of this perception it's easy to subject it to the typical switch design criteria. But in doing so you begin an exercise that leads to more frustration than clarity because you are apply old thinking to new technology. It makes more sense to view the Nexus 2000 as a linecard that has been pulled out of a switch, packaged up in sheet metal, and the backplane ports connecting to the supervisor engine changed to SFP+ ports. You know have a linecard that connects to its supervisor engine with cables. Why is that significant? Because it reduces the complexity (and therefore total cost of ownership) of adopting a Data Center virtualization architecture. (10) Nexus 2000's are managed no differently than (10) linecards. I think we can all agree that a linecard requires a lot less management than a switch. It also allows the Data Center to grow into larger L2 domains required by virtualization by minimizing the # of L2 nodes, because the Nexus 2000 links to data center with L1, versus L2. Business leaders are hearing a lot about cloud computing these days, and it's cost advantages to the business. Yet there is a valid concern with data privacy and security that comes with public cloud computing. If internal IT can transform their data centers into a private cloud, or at least drastically improve the operational efficiency and total cost of ownership of their own data centers ... the wholesale outsourcing of the data center applications to the public cloud become less attractive to the business leaders. -- Brad Hedlund, CCIE #5530, VCP Technology Solutions Architect, Data Center [email protected] http://www.internetworkexpert.org On Feb 9, 2010, at 4:40 AM, Livio Zanol Puppim wrote: > Yeah, You are right. > > But I would like to use my nexus 5000 10GE/FCoE ports just for access > servers, maximizing it's use... The uplinks from Nexus 2000 could easially go > directly to my distribution/core. Unfortunally, nexus 2000 is just an fabric > extender and can ONLY be attached to Nexus 5000... Maybe CISCO changes it's > later... > > Let's think: > > 10 nexus 2000 using all uplink ports = 40 ports. Yes, 40 ports that I must > use at my nexus 5000. That's more than 1 entirelly switch (1RU) and almost 1 > switch (2RU). > > I haven't figure out yet what's the advantage of having this design (nexus > 2000 -> nexus 5000) other than the "old" one (catalyst 4948 -> nexus > 7000/cisco 6500). That's what I'm talking about. > > The only REAL advantage so far is the vPC... > > 2010/2/2 Brad Hedlund <[email protected]> > > True, the Nexus 2000 does not locally switch, but lets explore that for a > second... > > 1) a typical enterprise Data Center is running applications that are not > latency sensitive, where latencies in the 10s of microseconds are perfectly > OK and nobody is really counting anyway. Only in the small minority of Data > Centers running high frequency trading, grid computing, or some other ultra > low latency application, every *nanosecond* matters and local switching with > fewer hops is of paramount importance. Furthermore, these applications are > quickly migrating away from 1GE to 10GE attached servers for the obvious low > latency advantages. > > 2) the Nexus 2000 has 4x10GE uplink bandwidth versus the 2x10GE uplink for > 4948. This results in a possible 1:1.2 oversubscription ratio for Nexus 2000 > to handle the additional uplink load that may otherwise not be present on a > 4948. > > 3) The upstream Nexus 5000 implements cut-through switching, and the Nexus > 2000 itself also uses cut-through for frames entering on 1GE and egressing on > 10GE. The two combined often results in port-to-port latencies similar to a > Catalyst 6500, even without the "local switching". If you are comfortable > with your Catalyst 6500 local switching latencies, you can expect similar > performance from a Nexus 2000/5000 combination. > > > -- > Brad Hedlund, CCIE #5530 > Consulting Systems Engineer, Data Center > [email protected] > http://www.internetworkexpert.org > > > > On Jan 31, 2010, at 5:25 PM, David Hughes wrote: > > > > > On 29/01/2010, at 6:54 AM, Livio Zanol Puppim wrote: > > > >> Can anyone please tell me the advantages of using Nexus 2000 over Catalyst > >> 4948 as access layers switches? > >> Using Nexus 2000, I have to use at least 2 ports at my Nexus 5000, that > >> could be used by servers with 10GbE/FCoE servers. > > > > The N2K does no local switching so if you have any east-west traffic > > between ports on the same switch you'll be better served by a more > > "traditional" access switch. Naturally the N2K offers centralised > > management etc etc but that may or may not be of interest depending on the > > size of your deployment. > > > > > > > > David > > ... > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > -- > []'s > > Lívio Zanol Puppim _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
