Jump to content
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

war Anfang des Jahres in San Jose zum VSS testen. Funktioniert soweit ganz gut. Wichtig ist hier, dass du nur 67 Karten und eine 3C PFC / DFC benötigst. Im Moment benötigts du einen dedizierten Link für Dual Active Detection.

Service Module wie FWSM usw. werden ab Withney 2 unterstützt (mal sehen..).

Pass auf wenn du den VSL Link konfigurierst ==> die portchannel ID ist nur ohne VSS local significant. Mit VSS ist es ungut, wenn du auf beiden Seiten po1 konfigurierst. Es gibt auch die Möglichkeit Switche [ohne] Ausfall auf VSS zu migrieren.. Für die Dual active detection kannst du entweder PAGP+ oder BFD verwenden. Ich würde da eher BFD priorisieren....

 

Cisco Catalyst 6500 Series Virtual Switching System (VSS) 1440  [Cisco Catalyst 6500 Virtual Switching System 1440] - Cisco Systems

Virtual Switching System (VSS) Q&A  [Cisco Catalyst 6500 Virtual Switching System 1440] - Cisco Systems

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/white_paper_ciscos_virtual_switch_smashes_throughput_records.pdf

 

brgds

 

TS

Link zu diesem Kommentar
So weit ich das verstanden habe, IST VSS nichts anderes als eine Stacking-Methode - eben halt nur für die 6500er Core-Switche.

 

D.h. am besten die Finger davon lassen...

 

Hmm .. das verstehe ich nicht.

Was ist denn schlecht an Stacks?

Also ich seh den Einsatzzweck eher im DataCenter / Distribution Bereich als im Core ... im Core hast du ja eigentlich nur geroutete Pt-to-Pt Verbindungen.

Interessant ist es eben, wenn du beispielsweise im Datacenter ein und dasselbe Subnetz auf 4 Büchsen zur Verfügung stellen musst. Das schöne ist, dass man mit VSS das ohne Spanning-Tree hinbekommt, indem man einfach EtherChannels Chassisübergreifend spannen kann.

 

Anderer (einfacherer) Anwendungfall, der mir auf die schnelle einfällt, ist der Uplink zum Access-Layer. Normalerweise hast du zwei Distries und jeweils eine Verbindung zwischen Distri und Access (Triangel). Sprich bei PVST ist ein VLAN pro Link auf blocking.

Mit VSS kann man zum Access-Switch wunderbar nen EtherChannel fahren - also man nutzt beide verfügbaren Links wunderbar aus.

Schöner Nebeneffekt: Man braucht für ein VLAN auch kein HSRP/VRRP mehr - was oft ja der Konvergenzkiller ist, mit den Defaulttimern.

 

 

Natürlich sollte das VSS nicht auseinanderfallen - sonst hat man ein echtes Problem :-)

Link zu diesem Kommentar

Hallo,

 

falls der VSL Link down geht [sOLLTE] Dual Active Detection greifen und der Standby Switch alle LCs down nehmen (ausser den Link für Dual Active).

Das hat teilweise noch eher suboptimal mit einer ganzen Latte an Tracebacks funktioniert...

 

Sonst ist VSS definitiv hot und die Konvergenzzeiten sind natürlich sehr gut. Wenn nun noch Service Module und MPLS unterstützt werden ist die Sache ready (Withney 2).

 

VSS könnte man als Stacking Variante bezeichnen. Eigentlich wird ein Fabric Channel über den VSL erweitert wie der Stacking Link beim C3750. Hier wurde auch diesmal gleich an sinnvolle Kommunikation gedacht (nicht wie bei der non E Serie des C3750 wo Port zu Port Kommunikation auf dem gleichen Switch gut mal über alle Stackmember gehen kann (;-() ==> Der VSL Link sollte für Datentraffic "fast" nicht benutzt werden. Eine redundante Auslegung des VSL ist auch nur für redundanzzwecke gedacht, d.h. über den zweiten Link des Po wird kein Traffic laufen.. Kein portchannel loadbalance..

 

Bin mal gespannt wie die erste Withney 2 mit Servicemodulen läuft. Das wird denke ich ein spass.....

Link zu diesem Kommentar
Hmm .. das verstehe ich nicht.

Was ist denn schlecht an Stacks?

 

Das ist nun vielleicht Ansichstsache, aber mit Stacks habe ich schon viele schlechte Erfahrungen gemacht (übrigens nicht nur mit Cisco)

 

Der Hauptnachteil ist einfach, dass es oft genügt dass 1 Switch ausfällt oder verrückt spielt damit der ganze Stack ausfällt. Da ziehe ich es doch vor, jedem Switch ein Trunk-Interface zum Core-Switch zu widmen. Wird zwar teuerer (wegen dem Cabling und event. SFP's) und umständlicher zum Konfigurieren, aber in Problemfällen ist diese Lösung wesentlich einfacher zu handhaben.

Link zu diesem Kommentar

Hola,

 

Hat bei uns geklappt.wie sieht deine Config aus? Switch IDs richtig gesetzt?

was sagt

sh switch virt link?

sh switch virt red?

sh switch virt role?

brgds

 

TS

Hallo,

 

//Trotz preemt muss ich die Zuordnung per reload mit beiden wiederherstellen.//

 

das verstehe ich nicht?! Du musst nach dem reboot die Zuordnung von Switch_A =1 und Switch_B = 2 neu definieren. Beim Boot sollte dies durch die Variable:

 

Sys_A#switch set switch_num [1 | 2]

Set rommon's switch_num to 1

Sys_A#switch read switch_num

Read switch_num from rommon is 1

 

definiert werden. Eigentlich sollten die vars beim convertieren automatisch gesetzt werden. Nur beim Tausch der Sup muss man diese neu setzten.

Was gibt bei die switch read .. aus?

 

brgds

 

TS

Link zu diesem Kommentar

hallo, hier CLI

 

#sh switch virtual role

 

Switch Switch Status Preempt Priority Role Session ID

Number Oper(Conf) Oper(Conf) Local Remote

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

LOCAL 1 UP TRUE (Y*) 110(110) ACTIVE 0 0

REMOTE 2 UP FALSE(N ) 100(100) STANDBY 8071 4985

 

Active configured preempt timer(switch 1): 7 minutes

 

 

In dual-active recovery mode: No

 

 

sh switch virtual link

VSL Status : UP

VSL Uptime : 23 hours, 27 minutes

VSL SCP Ping : Pass

VSL ICC Ping : Pass

VSL Control Link : Te1/5/4

 

 

sh switch virtual redundancy

My Switch Id = 1

Peer Switch Id = 2

Last switchover reason = none

Configured Redundancy Mode = sso

Operating Redundancy Mode = sso

 

Switch 1 Slot 5 Processor Information :

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

Current Software state = ACTIVE

Uptime in current state = 23 hours, 27 minutes

Image Version = Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSE

RVICESK9_WAN-VM), Version 12.2(33)SXH2a, RELEASE SOFTWARE (fc2)

Technical Support: Cisco - Shortcut

Copyright © 1986-2008 by Cisco Systems, Inc.

Compiled Fri 25-Apr-08 21:00 by prod_rel_team

BOOT =

CONFIG_FILE =

BOOTLDR =

Configuration register = 0x2102

Fabric State = ACTIVE

Control Plane State = ACTIVE

 

Switch 2 Slot 5 Processor Information :

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

Current Software state = STANDBY HOT (switchover target)

Uptime in current state = 23 hours, 27 minutes

Image Version = Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSE

RVICESK9_WAN-VM), Version 12.2(33)SXH2a, RELEASE SOFTWARE (fc2)

Technical Support: Cisco - Shortcut

Copyright © 1986-2008 by Cisco Systems, Inc.

Compiled Fri 25-Apr-08 21:00 by prod_rel_team

BOOT =

CONFIG_FILE =

BOOTLDR =

Configuration register = 0x2102

Fabric State = ACTIVE

Control Plane State = STANDBY

 

 

Mein Problem vermute ich in dem Fakt, dass ich das dual-active pair bfd konfigurieren kann,

jedoch nicht die beiden Interface dual-active excluden kann.

 

(config-vs-domain)#$ exclude interface gigabitEthernet 1/5/1

Cannot configure exclusion on bfd dual-active interface

 

Wenn exclude, dann nach pair- Auflösung. Danach geht jedoch kein dual-active pair mehr ...

 

Damit geht mit der standby- Umschaltung nach VSL- Unterbrechung auch das dual-active pair down. Eine Saubere Art mir eine Schleife zu basteln ...

Link zu diesem Kommentar

Hallo,

 

die BFD neighbours sollten sich sehen, wenn der VSL Down ist (das ist der Trigger).

 

Folgende Vorraussetzungen werden benötigt

 

-->An ip address must be configured on the interface.

!!-->The two interfaces must be on a different subnet.

-->Bfd interval parameters must be configured on the interfaces.

-->The bfd dual-active detection mechanism must be enabled – this is configured using the “dual-active detection bfd” command.

-->The pair of interfaces to be used in the detection mechanism must be specified using the “dual-active pair interface” command.

 

But:

 

Action upon Dual-Active Detection:

------------------------------------ !!

Upon detecting the dual-active condition, the original !!active chassis !! enters into recovery mode and brings down all of its interfaces except the VSL and nominated management interfaces, effectively removing the device from the network.

To nominate specific interfaces to be excluded from being brought down during dual-active detection recovery, use the following commands:

vss(config)#switch virtual domain 10

vss(config-vs-domain)#dual-active exclude interface gigabitEthernet 1/5/3

WARNING: This interface should only be used for access to the switch when in dual-active recovery mode and should not be configured for any other purpose

vss(config-vs-domain)#dual-active exclude interface gigabitEthernet 2/5/3

WARNING: This interface should only be used for access to the switch when in dual-active recovery mode and should not be configured for any other purpose

vss(config-vs-domain)#

 

==> Doch das active chassis (;-(.. module down...

==> Nach dem stecken des links sollte der nun standby reloaden ( vorher active)..

==> nach dem rebooten wird der switch nun in prefered standby starten..

==> nicht die BFD Interfaces excluden ==> die sind schon excluded..

==> da hab ich falsch gedacht ..

 

Hope this helps (;-)

Link zu diesem Kommentar

Hallo, besten Dank für die Tip´s.

Gestern sind wir mit Koll von Cisco die Punkte durchgegangen:

 

1.VSS- Steuerung:

Es ist kein Bug, es ist ein Feature. In Erklärung einleuchtend, am System beliebig oft nachvollziehbar:

 

- Bei Ausfall VSLink geht das System (der Active-1) von einem Fehler im System, nicht nur physischen/L2-Fehler aus!

Da der dual-active noch den Peer- Hardwareswitch sieht, schaltet der Active-1 all seine Line Card down, sein Management bleibt aktiv (Ich hab dann 2 Con CLI/ aber nur ein vty zur Verfügung - kann per sh swi virt red den Erreichten anzeigen lassen).

- Dem Standby- Switch wird unterstellt, dass er OK ist - er hatte bisher noch nichts eigenständig getan, alle Forwrdinginformationen wurden vom Active-1 bezogen, seine Interface sind oben. Er wird zum Activen, erarbeitet die Forwarding Info´s selbständig weiter, der alte Active-1 ist durch fehlende Linie Card blind.

- Mit UP von VSL-Link sieht der ehemalige Acitve-1 seinen Peer wieder, prüft sein System durch einen automatischen Reboot mit Selftest und landet gewollt in der Standby-Role.

Da stimmt sich das System ab und nach preemt wird Sw-1 Active, der Sw-2 bootet zum Standby.

Von dem Stress merkt der Netzverkehr, inklusive Routing usw. nichts. Ich habe Kreuzverkehr mit Solarwind´s und Brix (mit max Last) zu laufen gehabt.

 

2. Uplinkstabilität:

65xxVSS spricht pagp+, derzeit die 3750ér pagp. Damit gibt es ggf. Missverständnisse und errordisable shlägt zu. Mit Umstellen der channel-group´s auf mode desirable scheint das Problem vom Tisch zu sein. Ich habe nichts mehr gesehen.

 

Gruß an ALLE

Link zu diesem Kommentar
  • 3 Wochen später...

hallo veteranß und newbie´s

mein VSS-System arbeitet jetzt sehr stabil.

Folgender Hinweis: Uplink across über C3750 Stack funktionieren nur im channelgroup mode active.

 

Im Sommer soll ein C3750-IOS mit pagp+ kommen. Geht dann mode on wieder und/oder wir das Problem mode desirable für PO´s across eines Stack gelöst.

 

Gruß, ich erwarte Hinweise/ stehe für Fragen zur Verfügung

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...