Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to build reliable, scalable and easier to operate network with Virtual Switching System 1440 with Cisco expert Balaji Sivasubramanian. Balaji is part of the product management team in the Internet Systems Business Unit at Cisco. He is involved in defining product requirements and marketing of the next-generation products and features on the Cisco Catalyst 6500 Series Switch. In previous roles in Cisco during the last eight years, he served in customer support organization as a team leader in the Cisco Technical Assistance Center and Gigabit Switching Business Unit. He is a coauthor of the Cisco Press book "Building Cisco Multilayer Switched Networksâ and has authored and reviewed many technical white papers on Cisco.com.
Remember to use the rating system to let Balaji know if you have received an adequate response.
Balaji might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through January 11, 2007. Visit this forum often to view responses to your questions and the questions of other community members.
FYI - VSS article on Network World
Balaji, The VSS is very interesting technology and I have seen several tests completed on it. The performance and reduce failover times is impressive. I do have a question. Does the VSS have any IOS upgrade issues. Like in the 3750 Stacking Switch technology you have to be very careful in the IOS upgrades. If you are going from one major release to another, it will most likely break the stack, because of the compatibility of the stacking technology between major releases (as stated within Cisco release notes). Is there going to be a similar concern within VSS. As an example if we where using the current 12.4.xx IOS and wanted to upgrade to 12.5.xx IOS. When upgrading one Catalyst 6500, would it break the VSS between one Cat 6500 at 12.5 and the other at 12.4?
Thanks for the question
I will first explain what you can do today and what you can do in the next software release.
VSS (pair of 2 switches) needs to be kept in mind and also the assumption is that the devices are dual-homed. So even if one of the switch were to under-go reload to load the new image, the second switch will seamlessly provide connectivity to the attached devices.
Today in a VSS:
-Apply in-service patching
-RPR upgrade (similar to dual sup in single chassis today). You would need about 1-2 minute downtime when you are changing major images
In the next software release in a VSS :
- Apply in-service patching
- Apply hit-less software upgrade with ISSU feature.
Version mis-match issue is taken care of in the next software release with ISSU. So you can run two different versions and both the chassis will be up and running.
I just want to confirm in the next software release of ISSU, that you can run different major software releases, like one switch at 12.4 and the other at 12.5?
Catalyst 6500 is based on 12.2 train and we have no plans at this point to move to 12.4 and 12.5 etc. You can move between maintenance releases in 12.2SX software inservice.
what kind of physical connectivity we will have between two switches using 10G on sup720?
and how many switchs can we have in one cluster of VSS?
You can use standard 10GE for connectivity between the two switches. This is similar to switch inter-connect you have today. No change. The link is not a backplane, it is just a interconnect to exchange sync information (very low bw).
Today you can connect up to 2 switches in a cluster. Technology allows further scale up but we are starting off with 2.
We are very interested in what VSS has to offer however we would also need support for WAN connectivity for a full scale deployment across our Enterprise. Please say that the roadmap has support for WAN termination....
We definetly plan to add WAN termination support in a future release.
VSS as a technology can support WAN termination. However we have not enabled it at this time. I understand your need it for end-to-end.
VSS can still be deployed in core/distribution and data center locations and I hope you see the value in these locations. For now, you may have to run the WAN termination swithes as a "standalone" till VSS is available with WAN support.
Thanks, I had heard that the commitment was not that strong for WAN support. Any "rough" idea of its availablilty? I have research and limited deployment planned for 2008. Depending on our experience on the small scale implementation I would like to ramp up to the Enterprise in 2009. Sound like that might fit into Cisco's roadmap?
Let us discuss your requirements further in a live call. Ask your System Engineer or Account Manager to set up a call with me and we can discuss this further regarding timeframe and your designs. Sounds good ?
is there any limitation that i have to use sup720's 10G only or i can use any gig or 10Gig port from any other slot...
and what kind of signaling both switches are exchanging for SVV?
You can use any 10Gig port on Sup720-10G or the 6708-10G modules. No restrictions
The signaling is mostly the SSO(stateful switchover) feature that we already support between the dual supervisor in the same chassis plus some additional mechanism via the VSLP (virtual switch link protocol).
so this is some thing you can only use 10G not for GIG port... same as we can have multiple 10G between both switches and have channeling right!!!
can you post some good technical documentation detail link for the same?
Correct. Only the 10Gig.
You can find whitepaper with details at
You do need the new sup720 but any 67xx series cards without DFC or with DFC3c will do. For VSL (link between the two switches), you can either use the 10GE uplinks or the 6708-10GE ports.
Thanks for having this forum. Do you know of a plan/roadmap form when the FWSM will be supported on the VSS?
Thanks for your participation in the forum.
FWSM is planned in the next software release later this year. Stay tuned.
Looking at the info on VSS, I do not see any documentation on 65xx modules not supported with VSS. Yet I see an enry stating that the FWSM is not supported at this time. Can you provide a link or info on the availablity of modules not supported.
Thanks in advance for the assistance.
I saw this in the FAQ document here.
At this moment, only 67xx with no DFC or DFC3c are supported in VSS. NAM 1/2 are supported. FWSM/IDSM/WiSM and ACE 10/20 are planned for the next software release and we plan to address other modules and features as we go along in various software releases.
You can find the FAQ and other documents at
Main memory is configured to 64 bit mode with parity disabled in cisco 3600 series router
plz give solution...
This specific forum is regarding Catalyst 6500 VSS feature. Please post this in an appropriate forum or open up a TAC case.
Ok, FWSM/IDSM will be supported. Good.
Do I need to buy 2 FWSM/IDSM2 for each of the 6500 in the VSS or just 1?
If 1, how can I make the traffic go thru the IDSM module if it is landed on the port in the other chassis?
If 2, what will happen if one of IDSM modules fail? (The IDSM module does not have built-in mechanism for redundancy, as you know). Are you going to implement some Unified Failover Mechanism for Service Modules in the future release of VSS software? Makes sense, yah?
Also, could you please explain the role of SSO in the VSS? I thought that both 6500 are active (both Sups are active) and passing traffic, which is load splitted to them by the EtherChannel running on upstream/downstream switches. So, the question is: is it really an Active/Active redundancy (both Sups are active) or Active/Standby (single Sup is active, SSO - based)?
- If you have 1 service module, if the traffic lands on the other chassis, then traffic will get to the SM via the VSL. This is not a huge concern since IDSM is less than 1 gig bandwidth and FWSM up to 5.5 gig at worst case.
- If you do have 2 service module of a type, we are looking at some sort of VSS for the service module also but that is sometime in the future.
- Both the 6500 are active/active for data plance. SSO is a control plane feature and one is active and other is standby. So as far as the linecards/switch fabric and asic etc are active and forwarding on both the chassis.
Hope that helps
>> - If you have 1 service module, if the traffic lands on the other chassis, then traffic will get to the SM via the VSL. This is not a huge concern since IDSM is less than 1 gig bandwidth and FWSM up to 5.5 gig at worst case.
Well, suppose that SPAN is used to send traffic to the IDSM and IDSM is installed into the "left" 6500 chassis. The SPAN source port is an Etherchannel link that goes to the access-layer switch (this link is terminated by both 6500 in the VSS). The SPAN destination port is the IDSM module. The traffic comes to the "right" 6500. I can imagine that the "right" 6500 will be aware of the "monitor session" commands and will capture packets on its part of the Etherchannel link, but why and how will those packets be copied over the VSS link ???
Also, it's unclear how to configure the VSS for IDSM to work in inline mode. Can you give an example?
>> - If you do have 2 service module of a type, we are looking at some sort of VSS for the service module also but that is sometime in the future.
This basically means that the failover for service modules will not be statefull, until this feature is implemented, which nullifies all the advantages of the VSS.
First off, IDSM is not supported in the first software release.
VSS is aware to send the packets to the IDSM on the "left" switch even if the packets reach on the right switch for the SPAN. It is done automatically. Exact config examples with VSS will be availabe when we support IDSM in the next release.
Currently the way VSS works if you have 2 service modules is as if you have 2 service module in the SAME chassis (so all contexts in FWSM/ACE etc will be able to do load sharing etc). Any state sync that is available as part of the service module is fully supported in VSS. Also, there is plan to enhance it further. Also, VSS has lot of advantages independent of service modules like single point of configuration, uplink utilization and fast failover. There are lot of deployment scenarios where those benefits will greatly enhnace your network design /reliability and utilizaiton.