Cisco 6500 virtual switching

spidey07

No Lifer
Aug 4, 2000
65,469
5
76
http://www.cisco.com/en/US/pro...0900aecd806ed74b.shtml

Now that it's public knowledge we can talk about it. It's pretty slick - combine 2 switches into one. Eliminate all the layer2 problems with redundant network designs. Future releases will be more than 2 switches to have an entire data center be a virtual network.

There are down sides of course, most service blades aren't supported yet.
 

jlazzaro

Golden Member
May 6, 2004
1,743
0
0
good riddens STP! this seems very innovative...do you know of any other vendors with a similar technology?

too bad no 4500 support...then again, in environments where you would actually implement this type of virtualization that chassis probobly wouldnt cut it.

VSS 1440 whitepaper
 

Cooky

Golden Member
Apr 2, 2002
1,408
0
76
Looks cool, but I wouldn't use it for my critical apps until several months or even a year later...there's gotta be a ton of bugs w/ something this new; not to mention to re-design the whole core.
 

spidey07

No Lifer
Aug 4, 2000
65,469
5
76
meh, my design roadmaps have switched to this. core and server aggregation will be using VSS for all greenfield networks.
 

cmetz

Platinum Member
Nov 13, 2001
2,296
0
0
I'm with Cooky. This has a lot of promise, but I'll let others be the beta testers.
 

spidey07

No Lifer
Aug 4, 2000
65,469
5
76
Agreed that this is a whole lot of trickery. They spun an entirely new ASIC just for this to build all the features in. We'll see. It is promising and goes along the whole "virtualize everything" push from all aspects of IT.
 

bruceb

Diamond Member
Aug 20, 2004
8,874
111
106
STP is not going anyplace anytime soon. There are many companies that
are currently using it and others that are implementing it. And any current
installs will still need maintenance until the equipment is updated, which
usually only happens if something fails and can't be replaced with the same
item or if capacity needs dictate a change.
 

spidey07

No Lifer
Aug 4, 2000
65,469
5
76
STP of course isn't going anywhere, it is absolutely necessary. But in redundant designs you hate it, you can do your best with it but the protocol and it's behavior were not meant for the kinds of networks seen today. 30-50 seconds layer2 convergence time just isn't acceptable anymore.

route when you can, bridge when you must.
 

nightowl

Golden Member
Oct 12, 2000
1,935
0
0
I would not recommend using VSS in the core as that should be all L3 in most cases. The main place you will see VSS is in the distribution layer and server access like Spidey said. As far as other technologies that are similar to VSS, there is one that comes to mind but is not as robust as VSS.

Also, while STP is not going anywhere, it is going to be enhanced greatly.
 

spidey07

No Lifer
Aug 4, 2000
65,469
5
76
nightowl,

I'm still torn on VSS at the core. I want deterministic traffic paths at L3. Maybe because that what I'm used to have more control over.
 

cmetz

Platinum Member
Nov 13, 2001
2,296
0
0
spidey07, by my read of the feature's description, I don't see why any reasonable existing ASIC implementation would preclude this feature. I see a lot of control-plane stuff necessary to make this feature work, but I don't see why this needs anything changed at the data plane.

That might be just an excuse to sell everyone the Sup++ along with a whole second box. It'd be a highly profitable restriction, and Cisco has occasionally done things like that in the past ;)
 

nightowl

Golden Member
Oct 12, 2000
1,935
0
0
cmetz, there is a need for new ASICS to handle the VSS frames that pass between the systems and you do not want something like this to operate completely in software. Also as I look at it, this is not necessarily a way to sell more HW (while it will do that) it is barely any more HW (chassis, fan, and power supplies) than a normal HA deployment.

spidey, I am guessing that you are referring to troubleshooting when there are problems and traffic engineering when you say deterministic L3 paths?
 

cmetz

Platinum Member
Nov 13, 2001
2,296
0
0
nightowl, could you please explain what new/different frames are in the data plane? I really don't see anything in the linked document.

Could you please explain why I wouldn't want this to operate completely in software? As far as I can tell, all the work is in software. Extensive state table syncing, software. I'm not sure how you'd do L2/L3 protocol syncing any other way, the hardware can only reasonably sync what the hardware can see (e.g., ASIC state) and that's a derivative of what the software knows. Heartbeat and master/slave election, software. I guess you could do that in hardware, but I'm not sure what it buys you. The good box is the one doing the electing, the only thing it needs of the bad box is to have a way for the former to shut down the latter.

The document spidey07 linked to is a bit sparse on details, maybe I need to find more detailed documentation.
 

spidey07

No Lifer
Aug 4, 2000
65,469
5
76
The new PFC3C is the ASICs that deal with control plane stuff. This is what the new PFC is for. This new multichassis ethernet (MEC they're calling it) needed new asics AFAIK. That's what maintains the L2 flows through both 6500s and keep it symmetrical/optimal.

As far as cost it isn't that big of a deal. 10K more for each supervisor x2 chassis that would be configured the same anyway, after all is said and done with after discounts you're looking at an incremental cost of maybe 10K for the entire redundant system. So 260K vs 270K. Not too big of a deal for all that is offered.

Nightowl, yes...I'm specifically referring to traffic engineering and deterministic L2/L3 paths. With this technology the lines between L2/L3 blur from a traffic engineering perspective.
 

nightowl

Golden Member
Oct 12, 2000
1,935
0
0
Also, with for VSS to work, there is a new header on the Ethernet frames that travel between the chassis that requires the new asics in addition to what spidey mentioned. This is not something that you want to do in software because as we all know the more things that operate in SW the slower things become. Hence for high speed operations like we are dealing with here, you want the functions handled in HW.

Also, CEF720 cards with CFCs are supported the last time I checked and not just cards with DFC3C(XL)s.

Spidey, from my perspective this is a godsend for designing distribution and server access layers as I can now eliminate STP to the Access layer and add BW to servers. Traffic will stay on the chassis that it is originally came in on so I guess that can affect TE but I do not see it being that much different than dealing with L3 links. Then again your experience differs from mine and hence a different perspective on things.