cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
37930
Views
59
Helpful
33
Replies

Ask the Expert: Configuring and Troubleshooting Virtual Switching System (VSS)

ciscomoderator
Community Manager
Community Manager

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.

      

33 Replies 33

Vinayaka Raman
Level 1
Level 1

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

Regards Vinayak

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.

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

Regards Vinayak

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.

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

Regards Vinayak

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.

Sir,

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

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

HI,

     4506-E VSS待机层3没有工作,主动正常运行,为什么?

Devavrat Oka
Level 1
Level 1

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.

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.

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.

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
Level 1
Level 1

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco