This discussion is locked

Configuring and Troubleshooting Virtual Switching System (VSS)

Unanswered Question
Aug 23rd, 2013

Managing Controllers with Cisco Prime™With Anand Ganesan

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about how to monitor, configure, and troubleshoot the Virtual Switching System (VSS) in Cisco Catalyst 6500 Series Switches with expert Anand Ganesan.

VSS is network system virtualization technology that pools multiple Cisco Catalyst 6500 Series Switches into one virtual switch, increasing operational efficiency, boosting nonstop communications, and scaling system bandwidth capacity to 1.4 Tbps. At the initial phase, a VSS will allow two physical Cisco Catalyst 6500 Series Switches to operate as a single logical virtual switch called a virtual switching system 1440 (VSS1440). 

For more information, visit:  www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/prod_qas0900aecd806ed74b.html

The VSS simplifies network configuration and operation by reducing the number of Layer 3 routing neighbors and by providing a loop-free Layer 2 topology.

Anand Ganesan is a customer support engineer in the High-Touch Technical Service team at Cisco specializing in switching protocols. He has been supporting major service providers and enterprise customers in switching and all other switching technologies for more than two years with Cisco. He has a total of eight years of experience in the IT industry. He holds a bachelor of engineering degree from Bharathiyar University, Coimbatore.

Remember to use the rating system to let Anand know if you have received an adequate response. 

Because of the volume expected during this event, Anand might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure subcommunity, LAN Switching & Routing shortly after the event. This event lasts through September 6, 2013. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

      

I have this problem too.
7 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.6 (11 ratings)
vinayaka.raman Tue, 08/27/2013 - 07:51

Thank you for this opportunity..I have two questions:

1) I have a VSS 1440..(2*6509)...below error message is contineously popping up..Can you please help ?

Let me know if you need additional details..

Aug 27 10:46:06.305: EIGRP-IPv4(1): Neighbor 10.48.0.21 not on common subnet for  GigabitEthernet1/3/48


CS9#show run int GigabitEthernet2/3/48
Building configuration...

Current configuration : 171 bytes
!
interface GigabitEthernet2/3/48
description Switch 2 BFD Interface
no switchport
ip address 10.48.0.21 255.255.255.252
bfd interval 100 min_rx 100 multiplier 3
end

CS9#show ver | i IOS
Cisco IOS Software, s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 1
2.2(33)SXI6, RELEASE SOFTWARE (fc4)


S9#show switch virtual
Switch mode                  : Virtual Switch
Virtual switch domain number : 1
Local switch number          : 2
Local switch operational role: Virtual Switch Active
Peer switch number           : 1
Peer switch operational role : Virtual Switch Standby

2) How do i find which chassis is active and which one is stanby? I need this based on serial numbers of the chassis.

Regards
Vinayak

ag2 Wed, 08/28/2013 - 01:35

Hi Vinayak,

Thank you for posting your queries. I am very glad to help you answering your queries.

Reg. the Q: 1,

Could you please provide me the output of 'show run int GigabitEthernet1/3/48'? I would be able to provide my answer after having a look of the output of Gig1/3/48.

Reg. the Q: 2,

In VSS, there will be only one single control plane active (after logically merging two physical chassis) and hence there is no straight command to see the serial# of other standby chassis. Ofcourse, we will be having two data plane in VSS.

With the command 'show switch virtual', we will come to know which chassis is currently Active.  As per your output, the switch# 2 is Active.


Local switch number          : 2

Local switch operational role: Virtual Switch Active

Hence, with 'show version' or 'show inventory', you will come to know the chassis serial#.

If you still want to know the serial# of other chassis, it can be seen upon doing switchover.

Please let me know if you have any further queries.


Thanks,

Anand G.

vinayaka.raman Wed, 08/28/2013 - 02:05

CS9#show run int gi 1/3/48
Building configuration...

Current configuration : 171 bytes
!
interface GigabitEthernet1/3/48
description Switch 1 BFD Interface
no switchport
ip address 10.48.0.17 255.255.255.252
bfd interval 100 min_rx 100 multiplier 3
end

Regards
Vinayak

ag2 Wed, 08/28/2013 - 02:24

Hi Vinayaka Raman,

Thanks for the logs.

If you see the IP address for Gig1/3/48, it is 10.48.0.17 with subnet 255.255.255.252

Whereas for Gig2/3/48, the IP address is 10.48.0.21 with subnet 255.255.255.252

If you calculate the subnet for .252, the subnets are multiples of 4, i.e., 4,8,12,16,20,24, etc.

So, the .17 IP is from a different subnet and .21 is from a different subnet.

Hence, you need to make sure that both sides are on the same subnet in order to run EIGRP between them.

Hope this clarifies ! If you have any further questions, please let me know.

Thanks,

Anand G.

vinayaka.raman Wed, 08/28/2013 - 02:55

Okay..they are two different /30 networks.

my BFD interfaces are GigabitEthernet1/3/48 and GigabitEthernet2/3/48 and they work fine.

interface GigabitEthernet1/3/48

description Switch 1 BFD Interface

no switchport

ip address 10.48.0.17 255.255.255.252

bfd interval 100 min_rx 100 multiplier 3

end

interface GigabitEthernet2/3/48

description Switch 2 BFD Interface

no switchport

ip address 10.48.0.21 255.255.255.252

bfd interval 100 min_rx 100 multiplier 3

end

switch virtual domain 1

switch mode virtual

switch 1 priority 110

dual-active pair interface GigabitEthernet1/3/48 interface GigabitEthernet2/3/48 bfd

show switch virtual dual-active bfd

Bfd dual-active detection enabled: Yes

Bfd dual-active interface pairs configured:

interface-1 Gi1/3/48 interface-2 Gi2/3/48

router eigrp 1

network 10.0.0.0

network 10.1.201.0 0.0.0.255

network 10.48.0.12 0.0.0.3

network 10.48.177.0 0.0.0.255

network 97.0.0.0

network 99.0.0.0

network 100.0.0.0

network 100.7.7.0 0.0.0.255

network 192.34.145.0

network 192.168.15.0

show ip ei in

EIGRP-IPv4 Interfaces for AS(1)

                       Xmit Queue   Mean   Pacing Time   Multicast   Pending

Interface       Peers Un/Reliable SRTT   Un/Reliable   Flow Timer   Routes

Gi1/2/40           1       0/0         1       0/1           50           0

Gi1/2/41           0       0/0         0       0/1           0           0

Vl1               1       0/0         1       0/1           50           0

Vl7               0       0/0         0       0/1           0           0

Vl13               0       0/0         0       0/1           0           0

Vl15               0       0/0         0       0/1           0           0

Vl21               0       0/0         0       0/1           0           0

Vl25               0       0/0         0       0/1            0           0

Vl26               0       0/0         0       0/1           0           0

Vl134             0       0/0         0       0/1           0           0

Vl135             0       0/0         0       0/1           0           0

Vl140             0       0/0         0       0/1           0           0

Vl300             0       0/0         0       0/1           0           0

Vl400             0       0/0         0       0/1           0           0

Vl199             0       0/0         0       0/1           0           0

Vl6               0       0/0         0       0/1           0           0

Vl20               0       0/0         0       0/1           0           0

Vl24               0        0/0         0       0/1           0           0

Vl30               0       0/0         0       0/1           0           0

Vl31               0       0/0         0       0/1           0           0

Vl37               0       0/0         0       0/1           0           0

Vl2               0       0/0         0       0/1           0           0

Gi1/3/48           0       0/0         0       0/1           0           0

Gi2/3/48           0       0/0         0       0/1           0           0

Vl17               0       0/0         0       0/1           0           0

Gi2/6/40           0       0/0         0       0/1           0           0

Gi2/6/41           0       0/0         0       0/1           0           0

Gi2/1/45           1        0/0         1       0/1           50           0

Gi1/1/33           1       0/0         1       0/1           50           0

My questions revolve around the same point.

Are there any significance in running eigrp or any other routing protocol over this BFD link?

Is the Dual active scenario detected by BFD or BFD notifies a routing protocol like eigrp and in turn dual active is detected?

Should I suppress the eigrp HELLOs on these interfaces to get rid of the log message?

Regards
Vinayak

ag2 Wed, 08/28/2013 - 06:09

Hi Vinayaka Raman,

Thanks for your questions.

At the end of this mail, I believe I would have answered all your queries.

Let me explain.

Basically, one of the IP routing protocols supported by BFD must be configured on the routers before BFD is deployed. In our case, EIGRP is already running.

From the logs, I see that the major network 10.0.0.0 is advertised in EIGRP.

router eigrp 1

network 10.0.0.0                             >>>>> this will cover the BFD interfaces as well.

network 10.1.201.0 0.0.0.255

network 10.48.0.12 0.0.0.3

network 10.48.177.0 0.0.0.255

So, this major network advertised in routing protocol will also cover the BFD interfaces, i.e., Gig1/3/48 & Gig2/3/48. For BFD detection method to work, there is no need to advertise those IP's into any routing protocol.

Here, what happens, during the EIGRP hello packet exchange, those IPs are also will be shared which is really not required. The below error message is appeared when those IPs with different subnet are noticed.

Aug 27 10:46:06.305: EIGRP-IPv4(1): Neighbor 10.48.0.21 not on common subnet for  GigabitEthernet1/3/48

To suppress the error message, you can follow either of the two methods.

1) Remove the major 10.0.0.0 network from the EIGRP.

2) Make those BFD interfaces as passive.

With respect to the below question,

Is the Dual active scenario detected by BFD or BFD notifies a routing protocol like eigrp and in turn dual active is detected?

The answer would be, the dual active scenario will be detected by BFD.

I am providing few cisco references which would have for a better understanding.

http://tools.cisco.com/squish/68e80

http://tools.cisco.com/squish/81957

http://tools.cisco.com/squish/48fD5

Please let me know if you have any further questions.

Thanks,

Anand G.

azad.jobs86 Wed, 08/28/2013 - 10:17

Sir,

I am fully new to Cisco Please can you refer me any books for VSS

ag2 Thu, 08/29/2013 - 01:42

Hello Azad,

I really appreciate to come forward to learn VSS.

The VSS is small area with very wider scope with respect to scalability, etc. 

I would recommend at this point to go through the Cisco white paper for VSS which gives the complete coverage in an easy manner.

http://iwe.cisco.com/c/document_library/get_file?p_l_id=205211671&groupId=133901246&folderId=411004923&name=DLFE-407418453.pdf

The other URL which I recommend for best practices is provided below.

http://tools.cisco.com/squish/Ac71b

Use your Cisco CCO to open.

I do not want to give you too many links to confuse. The white paper will cover in an excellent manner and use the other CCO for best practices.

Please let me know if you need any additional information.

All the best !

Thanks,

Anand G

devavratoka Wed, 08/28/2013 - 22:11

Anand, I have seen a VSS deployment without a Heart Beat Link. A 'show switch virtual' will show the chassis is in VSS and VSS is successful. What are the implications of operating a VSS without the HBL? Shouldn't VSS always need an HBL to form a VSS pair in the first place?

When I say I didn't see a HBL, I mean I did not see BFP or dual active configs on any ethernet interfaces.

ag2 Thu, 08/29/2013 - 03:10

Hi Devavrat Oka,

Thanks for posting your query.

Let me explain the basic functionality of VSL links and why a heart beat link is required and what if happen if it is not used.

If the VSL fails, the VSS standby chassis cannot determine the state of the VSS active chassis. To ensure that switchover occurs without delay, the VSS standby chassis assumes the VSS active chassis has failed and initiates switchover to take over the VSS active role.

If the original VSS active chassis is still operational, both chassis are now VSS active. This situation is called a dual-active scenario. A dual-active scenario can have adverse affects on network stability, because both chassis use the same IP addresses, SSH keys, and STP bridge ID. The VSS must detect a dual-active scenario and take recovery action.

The VSS deployment which you have seen; though it works fine, but it is recommended to implement any one of three dual active detection mechanisms available.

  • Enhanced PAgP
  • Fast-Hello—VSLP framework-based hello
  • Bidirectional Forwarding Detection (BFD)


These methods will help us to prevent any network instability in case of VSL link failure resulting in dual active state.

Hope the explanation answers your question.

Please let me know if you have any further questions.

Thanks,

Anand G.

devavratoka Thu, 08/29/2013 - 13:31

Thank you Anand.

For a previous VSS install, I manually configured the HBL as follows:

switch virtual domain 1

dual-active detection fast-hello

interface GigabitEthernet1/3/48

no switchport

no ip address

dual-active fast-hello

I couldn't find an HBL config on the new VSS deployment, but from the new VSS switch:


Core-VSS#sh switch virtual dual-active summary

Pagp dual-active detection enabled: Yes

Fast-hello dual-active detection enabled: Yes

No interfaces excluded from shutdown in recovery mode

In dual-active recovery mode: No

So it seems even though there isn't an HBL configured, dual-active is still enabled. There isn't a 'dual-active detection fast-hello' under 'switch virtual domain 100' on the new VSS.

ag2 Fri, 08/30/2013 - 00:28

Hi Devavrat,

Yes. you are right. Only the functionality is enabled but to activate we need to configure either of the 3 options.

The below ones are captured from my lab. I didn't configured any 'dual-active detection fast-hello' in my VSS setup, however, the below result shows it as 'enabled'.

Please see the below outputs.

VSS-1#sho swi virtual dual-active fast-hello

Fast-hello dual-active detection enabled: Yes

Fast-hello dual-active interfaces:

Port       Local State    Peer Port    Remote State

---------------------------------------------------

VSS-1#

VSS-1#sh run | i hello

VSS-1#

VSS-1#sho swi virtual dual-active summary

Pagp dual-active detection enabled: Yes

Bfd dual-active detection enabled: Yes

Fast-hello dual-active detection enabled: Yes

No interfaces excluded from shutdown in recovery mode

In dual-active recovery mode: No

VSS-1#

So, all the three functionalities are showing as enabled in the last output but I didn't configure for any of the above 3 functions.

But, it is advised to configure any of these functions for detecting dual-active scenarios.

Please let me know if you have any further questions.

Thanks,

Anand G.

csc010627097 Thu, 08/29/2013 - 13:13

Hi Anand, I am planning to implment VSS on my Datacenter. I Have a 6509 and a 6506-E both with Supervisor 720. At the moment the 6509 is working with ios12.2(33)SXI as an standalone switch. The 6506-E is a brand new. I would like to know what are the advantages in using VSS or VSS Quad Supervisor! Aditional if I decide to use Quad Supervisor wich IOS version do you recommend? 15.1?

Thanks a lot for your time

Regards

moongoolioo Thu, 08/29/2013 - 23:27

Hi Leonardo.

First of all you need supervisors 720-10G  and 6509-NEB-A chassis at least,  to make up your VSS.

About 15.1 version of IOS - it does not support quad sup redundancy for SUP2T   - http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.1SY/config_guide/sup2T/virtual_switching_systems.html#wp1300164, but for SUP720-10G is ok.

BTW i have negative experience of upgrading to 15.1 after that i had to rollback to more stable 12.2.33. So I will recommend you to use 12.2 line until you really need smth what only 15.1 can give to you.

Regards,

moongoolioo Fri, 08/30/2013 - 02:20

Good day, Anand.

I need to deploy distributed datacenter, and I decide to build it based on two Catalyst 6509 united into VSS. But to make VSL link redundant I plan to use different optical connections - one link with approximately length 4 km and second 15 km.

So as I can imagine those links can have slightly different delays when transmit, so how do you think can this results in problem?

Regards,

ag2 Fri, 08/30/2013 - 03:58

Dear Alexey,

Thanks for posting the query. I am glad to answer the query.

One of the main advantage of the VSS setup is the distance between the physical chassis.

The underlying physical switches do not have to be colocated. The two physical switches are connected with standard 10 Gigabit Ethernet interfaces and as such can be located any distance based on the distance limitation of the chosen 10 Gigabit Ethernet optics.

For example, with X2-10GB-ER 10 Gigabit Ethernet optics, the switches can be located up to 40 km apart.

So, the distance which you have mentioned is max.15km and ideally it should work without any issues.

As far as I know, there are no issues reported so far.

Regarding pros & cons of a large split like this; sometimes, it is difficult to find diverse paths when you are going longer distances like this even in a campus environment. I would recommend planning out your paths and methods of dual-active detection to make sure your risks of split-braining the VSS are not increasing significantly by splitting them across campus.

Hope this clarifies ! Please let me know if you have any further questions.

Thanks,

Anand G.


moongoolioo Tue, 09/03/2013 - 04:21

Good day, Anand.

Thnx for reply, but can you specify such moment as:

VSL consists of two links - one link 4 km length, other one 15 km length, so those links have different delays - can this negatively affect inter VSS control traffic passed over those links? As far I understand only one link will be used by each chassis to communicate to other one (based on cef principles), so there are no possibility for control packets to get to other side of VSL link out of order. And consequently this design (with different links length forming one VSL link) is acceptable. Can you confirm this or disprove?

Regards,

ag2 Tue, 09/03/2013 - 19:32

Dear Alexey,

Thanks for your question.

With respect to your first question, I would like to let you know about a protocol named Link Management Protocol (LMP), The LMP runs on each individual link that is part of the VSL, and is used to program information such as member details, forwarding indices, etc.

By default LMP hello transmit timer(T4) and receive (min_rx) timer is 500 msec. The hold-timer known as T5 timer derived from a min_rx and default multiplier of 120. Thus by default VSL member link time out is detected in 60 second.

So, as long as the links on VSL receives the response from peer before the T4 & T5 values gets time out, there will not be any delay issues that affects inter-VSS control traffic passed over those links.

The VSL bundle is special purpose EtherChannel that can have up to eight members. Only one link out of a configured member is selected as the control link and that control link is the only link that can carry the inter-chassis control plane. The control link carries the inter-switch External Out-of-Band Channel (EOBC) control traffic that includes the Switch Control Packet (SCP) for line card communication, Inter-process Communication Packets (IPC), and Inter-Card Communication (ICC) for communicating the protocol database and state—as well as updates to the hot-standby supervisor.

In addition, the same link can carry user and other network control traffic—depending how the traffic is hashed (i.e., based on source and destination MAC and/or IP addresses). The remaining bundled links carry network control plane and user data traffic, but not the inter-chassis control plane traffic.

Another important point which I would like to mention here is, the control-link selection procedure is determined by the VSS system and cannot be managed by the user. During the bootup process, the first VSL link that establishes LMP relationship (state-machine) will be selected as the control link. Based on the Cisco Catalyst 6500 architecture, the supervisor module becomes operational ahead of any other module installed in the switch. If the 10-Gbps port of Sup720-10G module is bundled in the VSL EtherChannel, then it will be selected as control-link interface whenever both switches undergo the boot process.

Hope this answers your question.

Please let me know if you have any additional questions. I am very glad to provide more details.

Thanks,

Anand G.

csc010627097 Fri, 08/30/2013 - 07:41

Hi Anand,

I ask again with new information:

I am planning to  implment VSS on my Datacenter. I Have a 6509-E and a 6506-E both with  Supervisor 720-10G. At the moment the 6509-E is working with ios12.2(33)SXI as an standalone switch. The 6506-E is a brand new. I would like to  know what are the advantages in using VSS or VSS Quad Supervisor!  Aditional if I decide to use Quad Supervisor wich IOS version do you  recommend? 15.1?

Thanks a lot for your time

Regards

ag2 Fri, 08/30/2013 - 09:41

Hi Leonardo,

Thanks for posting your query.

Let me provide you the advantages of using VSS/Quad Supervisor.

Beginning in software release 12.2(33)SXI4, VSS supports a feature called Quad-Sup Uplink Forwarding which allows a redundant in-chassis Supervisor to operate primarily as a line card. Prior to this release with a second supervisor in the chassis it will be forced into rommon and not be allowed to boot, however there are no issues keeping the 2nd sup in the chassis.

A Supervisor failure event will down the affected chassis decreasing the VSS bandwidth by 50%.

A Second Supervisor installed in the chassis will boot as a Linecard with all of its ports active. It is supported in 12.2(33)SXI4 and newer on supervisor VS-Sup720-10G.

Another advantage is, if the active Supervisor in the chassis fail, the In-Chassis Standby will reload and then take over the chassis Supervisor functions without human intervention.

Here are some keypoints which I would like to highlight.

  1. Quad Supervisor Uplink Forwarding feature is available starting with release in 12.2(33)SXI4
  2. Quad Supervisor Uplink Forwarding is not available on Supervisor Engine 2T based VSS, future software releases will provide support for fully redundant Supervisors with VSS
  3. Quad Supervisor Uplink Forwarding allows for deterministic recovery from a Supervisor failure event
  4. In-Chassis Standby Uplinks are active and operational under normal conditions
  5. In-Chassis Standby Supervisor runs in new redundancy mode called RPR-WARM
  6. Switchover to the In-Chassis Supervisor does require a reload of the chassis
  7. Supervisor role negotiation occurs first within the chassis, then the “winning” In-Chassis active Supervisor performs VSS role negotiation between chassis

The Supervisor 720-10 G supports the Quad-Sup Uplink Forwarding4 feature, which allows for a redundant in-chassis supervisor module. Again, it is recommended to build the VSL with at least one port from each supervisor module. If desired, you can use all the 10 Gigabit ports from the supervisor modules for the VSL. With this configuration, you should cross-connect one port form each supervisor to one port on each supervisor on the peer chassis. This will help ensure an active VSL port member local to the active supervisor, regardless of any supervisor module failure.

Quad-Sup Uplink Forwarding VSL design using all 10 Gigabit ports on the supervisor modules:

  • Maintains 20 Gbps VSL bandwidth in the event of a supervisor failure
  • Maintains at least one locally attached VSL port to the active supervisor, in the event of a supervisor module failure
  • Requires no additional line cards

If additional bandwidth is needed for the VSL, additional 10 Gigabit ports from supported line cards can be used. Up to eight ports per port channel can be added, just like any other port channel interface.

With respect to the image 15.1, I see from my database repository, there are couple of bug applicable for 15.1.

To highlight an example, I have come across a situation where the customer did a manual switchover in 15.1 VSS setup.

They got the below error messages.

Jul 10 04:14:07.075: ISSU-SW2-3-PEER_IMAGE_INCOMPATIBLE Peer image (s2t54-IPSERVICESK9-M), version (15.1(1)SY1) on peer uid (262) is incompatible
Jul 10 04:14:07.075: ISSU-SW2-3-PEER_IMAGE_INCOMPATIBLE Peer image (s2t54-IPSERVICESK9-M), version (15.1(1)SY1) on peer uid (262) is incompatible 

Hence, I would recommend to use the standard 12.2(33)SXI and above.

Please let me know if you have any questions.

Thanks,

Anand G

sandevsingh Tue, 09/03/2013 - 08:37

Hi Anand, I had a question on Layer 3 peering with VSS. As VSS is logically one control plane, so if I dual attach any layer 3 device with the VSS pair, will it see only 1 IGP neighbor (i.e the active switch)? If yes, this is a big advantage over nexus-vpc as you have 2 control planes there and each layer 3 device sees both the nexus as its IGP neighbor (one of them over the vpc peer link)  which leads to 50% of the traffic being dropped over the vpc peer link due to the in-built vpc loop avoidance technique.

thnx

ag2 Wed, 09/04/2013 - 04:19

Hi Sandevsingh,

Thanks for posting the query.

Yes. your assumption is perfectly right. The Layer-3 device when attached with the VSS pair, it will see the VSS switch as a single neighbor (whichever the active in a VSS pair).

Please let me know if you have any questions.

Thanks,

Anand G

patelronak Thu, 09/05/2013 - 03:52

I have 2 Cisco 4950 switches. Is VSS supported on Cisco 4950  switch? If yes, Which IOS image I need?

ag2 Thu, 09/05/2013 - 09:55

Dear Ronak,

Thanks for posting your query.

Yes, the VSS is well supported in 4900 series switches. It should have the Supervisor Engine 7E or 7LE for VSS support and we need an identical pairs (7E/7LE)  in hardware front.

With respect to your question about software (IOS) support, we need to have Cisco IOS XE 3.4.0SG and ROMMON IOS Version 15.0(1r)SG7 or later release would support VSS. Coming to the license part, you may need a minimum license of IP Base or higher (7-E) or special license (7-LE and Catalyst 4500-X).

I would like to provide some additional information on SSO and NSF.

SSO and nonstop forwarding (NSF) must be configured on each switch. If a VSS does not meet the requirements for SSO redundancy; it will be incapable of establishing a relationship with the peer switch. Catalyst 4500/4500-X series switches' VSS does not support route processor redundancy (RPR) mode.

Hope this answers your question!

If you have any further queries, please let me know.

Thanks,

Anand G.

tissebastian Fri, 09/06/2013 - 01:16

hi anand, i am new to networking field. could you please provide some information  on how the 2 standalone switches establish a VSS connection? what are the  protocols involved?

ag2 Fri, 09/06/2013 - 06:47

Hello Tismol,

Thanks for your query and the interest shown on knowing the technical aspects.

As you are new to this field, let me explain in a very simple manner.

The two standalone switches can be combined using a link called VSL, Virtual Switch Link. It provides the mechanism to keep both the chassis in sync upon VSS is formed.

The VSL initialization happens in 3 steps.

1) Bringing the link Up.

This is to determine which ports form the VSL

2) LMP (Link Management Protocol)

This protocol is used to track and reject unidirectional links, exchange chassis ID and other information between the 2 switches.

3) RRP (Role Resolution protocol)

This protocol is used to determine the compatible hardware and software versions to form the VSL as well as determine which switch becomes Active and Hot standby from a control plan perspective.

Hope this answers your question.

Please let me know if you have any questions.

Thanks,

Anand G.

subaviswesvaran Fri, 09/06/2013 - 04:58

Hi Anand,

I have the following questions.

1) what are the various detection methods available in case of dual-active scenario?

2) which method is ideally used in fast converging?

Thanks

Suba

ag2 Fri, 09/06/2013 - 06:57

Dear Subbulakshmi,

Thanks for posting your query.

There are three detection methods can be configured while dual-active scenario is observed.

1) Enhanced PAgP

It uses PAgP messaging over the MEC links to communicate between the two chassis through a neighbor switch. Enhanced PAgP is faster than IP BFD, but requires a neighbor switch that supports the PAgP enhancements.

2) IP BFD (Bi-directional Forwarding Detection)

It uses BFD messaging over a backup Ethernet connection. IP BFD uses a direct connection between the two chassis and does not require support from a neighbor switch.

3) Dual-active fast-hello method

It uses special hello messages over a backup Ethernet connection. Dual-active fast-hello is faster than IP BFD and does not require support from a neighbor switch.

This method is available only in Cisco IOS Release 12.2(33)SXI and later releases,

You can even configure all three detection methods to be VSS active at the same time.

For line redundancy, we recommend dedicating at least two ports per switch for dual-active detection. For module redundancy, the two ports can be on different switching modules in each chassis, and should be on different modules than the VSL links, if feasible.

Coming to the other question, teh Enhanced PAgP and Fast Hello methods have a sub-second convergence whereas the IP-BFD method has seconds of convergence.

The few things which you need to remember is, the PAgP requires a PAgP capable neighbor, the Fast-hello is a direct L2 connection and the IP BFD method is direct L3 connection.

Hope this answers your queries.

Please let me know if you have any further questions.

Thanks,

Anand G.

ag2 Fri, 09/06/2013 - 08:32

Hi RB,

Sorry for the inconvenience !

I have attached the white paper (pdf) for your kind reference.

Thanks,

Anand G.

Actions

Login or Register to take actions

This Discussion

Posted August 23, 2013 at 3:49 PM
Stats:
Replies:30 Avg. Rating:4.58333
Views:6890 Votes:7
Shares:1
Categories: Switches
+

Related Content

Discussions Leaderboard

Rank Username Points
1 15,007
2 8,150
3 7,725
4 7,083
5 6,742
Rank Username Points
165
82
69
65
55