Cisco VSS

[v-rtc 88]

Hallo zusammen.

 

Das klingt gar nicht so schlecht.

Hattet Ihr schon einmal einen Failover testen können?

 

Ihr versorgt ja Euer Netz mit einem von beiden im Notfall.

Wie habt Ihr dies verkabelt? Soweit ich weiß, sollte dieses ja dann

eine Ringverkabelung sein?

 

Grüße

 

Rolf

[jpzueri 10]

Hi Wolff,

du solltest die Switche immer mit einem Port-Channel anbinden und mindestens ein Uplink auf sw1 und einen auf sw2.

Failovertrst haben wir auch durchgeführt.

Ihr solltet auch verschiedene Ausfallzenarien durchspielen.

LG

JP

[v-rtc 88]

Hallo JP.

 

Danke für die Infos. Noch sind sie nicht bestellt, aber wohl kurz davor.

Wichtig ist wohl auch das Spanning-Tree, bezüglich eines Loops.

(Wenn ich mich richtige ausdrücke).

 

Dann sind wir mal gespannt.

 

Vielen Dank für Eure Meldungen.

 

Grüße

 

Rolf

[Otaku19 33]

STP spielt bei etherchannel keine Rolle, also bezogen auf die Leitungen die in dem Channel zusammengefasst werden

[jpzueri 10]

Hi R.Wolff

 

für den etherchannel würde ich folgende load-balance einstellen:

src-dst-mixed-ip-port

die Defaulteinstellung ist auf src-mac

 

vss(config)#port-channel load-balance ?

..........

src-dst-mixed-ip-port Src XOR Dst IP Addr and TCP/UDP Port

..........

 

Auf den Switchen (3560G und 3750G) etherchannel auf src-dst-ip

So habe wir es bei uns eingestellt um eine Lastverteilung im Channel zu machen. Mit scr-mac wird hauptsächlich nur ein Verbindung im Channel genutzt.

 

Gruß

JP

[bernd.zschill 10]

Hallo alle zusammen,

obwohl STP bei Etherchannel keine Rolle spielt, sollte es sauber aufgesetzt werden (mstp-instanz 0 für alle vlan, ID 0).

Zweck: Sollte ein Multiventor-Adapter zweifelhafter Herkunft (ID-0) im Netz erscheinen (hatten wir schon !) spielt das Netz .... und bereitet unnötig Kopfschmerzen.

Gruß

B

[Poison Nuke 10]

eine Verständnisfrage zu VSS:

 

es wird ja als VSS 1440 bezeichnet, sollte rechnerisch also die doppelte Leistung bringen von einem Switch...klar in der Rechnung.

 

Nur hier lese ich jetzt, dass es im Endeffekt eine Active/Passive Lösung ist, somit ist immer nur ein Switch aktiv und der andere ist im Hot-Standby?

 

ergo wäre das marketing von CIsco falsch oder kann man auch beide als einen virtuellen großen Switch konfigurieren der effektiv wirklich mit der doppelten Bandbreite läuft, wenn der Traffic idealerweise nicht von einem Sw auf den anderen rübermuss?

Was passiert in so einem Fall wenn der eine ausfällt, läuft das ganze ohne merkbare Probleme mit halber Leistung weiter oder gibt es in so einem Fall größere Probleme?

 

 

Wie sieht es mit BGP Sessions aus, habt ihr auf euren VSS BGP laufen? Wenn ja wie lange ist die Konvergenz wenn ein Failoverfall eintritt? Wie sieht es mit den Nachbarn bezüglich authentifizierung, MAC usw aus? Weil normalerweise sind die meisten BGP Peers ja zusätzlich an eine MAC gebunden, demzufolge müsste man erstmal zwei Leitungen zum Carrier haben und dann auch noch denen sagen dass über beide Leitungen dennoch nur ein einzelner Peer angesprochen wird. Geht das so ohne weiteres bei VSS?

 

Würde es vllt sogar eine Art Lastverteilung bei BGP geben? Weil die 65er von Cisco haben ja das Problem, dass ein BGP Fulltable die so ziemlich ans Limit von der CPU bringt, wenn mehr als ein Fulltable drauf ist wirds erst recht lustig. Wie läuft das bei VSS dann, macht dass da nur ein Switch und teilt dem anderen die Routinginformationen mit?

[daking 10]

Hi Poison Nuke,

 

nur der RP (Control Plane) des Standby Switches ist im Hot Standby Modus. Der SP, die PFC und natürlich alle DFC's der LC's sind aktiv. Aus Sicht der angebundenen Geräte handelt es sich um einen logischen Switch/Router. Natürlich sind auch beide Crossbar Fabrics aktiv. Das VSS hat also im Marketing Modus eine 1440Gbit/s Fabric :-)).

 

Die Lastverteilung von den angebundenen Endsystemen oder angebundenen anderen Routern/Switches muss via ECMP (Equal Cost Multipath) oder MEC (Multi Chassis Etherchannel) erfolgen. Dann verteilen sich die Sessions mehr oder weniger gleichmäßig auf die beiden Komponenten. Falls einer der Switches ausfällt funktionieren natürlich alle einfach angebunden Komponenten nicht mehr - alle redundant angebundenen Komponenten können in diesem Fall die "Hälfte" der Bandbreite übertragen. Die Performance sinkt natürlich. Ob in diesem Fall Probleme auftreten kommt auf das Design an.

 

Warum sollten BGP Peering an MAC Adressen gebunden sein?

Falls der Provider oder was auch immer nur einfach an einem der VSS Komponenten angebunden ist - wird das wieder suboptimal sein. Sonst sollte die Gegenstelle NSF (graceful restart) unterstützen - da bei Ausfall des aktiven Switches erst der Hot Standby RP gestartet werden muss. In diesem Fall ist es auch eher suboptimal Subsecond Hellos für das IGP zu verwenden (oder auch "agressive" Dead Timer) - da dann NSF (gracefule restart) auch nichts hilft. Benötigt halt eine kurze Zeit bis der Standby RP läuft und die Control Plane aktiv ist. Das IGP sollte kleiner <200ms konvergieren (ECMP). Falls die Gegenstelle NSF unterstützt - sollte IMHO BGP nichts an der Dataplane ändern - die Routen werden natürlich neu propagiert.

 

Es gibt keine Lastverteilung zwischen den beiden RP's - Beim Aufbau der Sessions kann es zu höherer CPU Last kommen - sind alle Routen gelernt und die RIB-->zu FIB übertragen - sollte es hier in stabilen Umgebungen zu keiner hohen CPU Last kommen - die CPU hat ihre Arbeit getan. Passen nicht alle "Routen" in die HW (TCAM) - ist das natürlich schlecht... die kleinste PFC/DFC bestimmt dann die Kapazität.. Da natürlich alle PFCs/DFCs alle Infos haben müssen.

 

Hope this helps.

[Poison Nuke 10]

hallo,

 

danke für die info, damit fällt also VSS definitiv flach als hochverfügbarkeitslösung weil sie es in unserem Fall nicht ist. Das wäre nämlich als multi 10GbE Knotenpunkt zwischen mehreren BGP AS gedacht. Da hat ein c6500 so ziemlich dauerhaft 100% CPU Load, ganz einfach daher weil der BGP Scanner jede Minute mal eben etliche hunderttausend Routen durchackert.

 

Naja bleibt es doch bei der aktuellen lösung mit zwei getrennt agierenden 6500er und ECMP läuft so oder so schon bei den intraAS Routern (fällt einer der Cores aus läuft es mit 50% Kapazität über den verbleibenden weiter, aber es ist eh so dimensioniert dass selbst das dauerhaft reichen würde)

 

 

Die Hoffnung war halt einfach das man zwei getrennte Router zu einem großen logischen Router zusammenfassen kann um über mehrere Anbindungen eine gezielte (nicht ECMP) Lastverteilung machen kann, die über zwei getrennte Router nunmal nicht in der gewünschten Form realisierbar ist.

 

 

 

wäre also nur die Frage wie sich VSS im Distribution Bereich macht im Vergleich zu GLBP oder HRSP ?

gibt es da Vorzüge? Bei den letzten beiden Protokollen ist es im Endeffekt ja genau das gleiche, der eine Router ist im Hotstandby und hat auch schon alle Routen und übernimmt dann bei Ausfall des anderen die virtuellen IPs

oder hätte hier VSS vllt sogar wirklich den Vorzug das man bei bei 2x 1GBit Uplinks im Access Bereich dann effektiv auch 2Gbit als PC auf zwei Chassis nutzen kann und nur beim Failover dann 50% zur Verfügung stehen?

[daking 10]

Hi Poison Nuke,

 

warum sollte die VSS Lösung in eurer Umgebung keine Hochverfügbarkeitslösung sein? Im Moment, wenn ich es Richtig verstehe, habt ihr zwei 6k Chassis die via ECMP an mehrere andere Router weiterleiten. Aus Sicht der HA Lösung könnte man die zwei Chassis in einen logischen Router wandeln und die Komponenten wieder via ECMP aufteilen. Vielleicht sogar, wenn noch 10G Ports vorhanden in einem Mix aus ECMP + MEC (also über Kreuz auf die Chassis via Channel). Das bringt dann den Vorteil, dass ihr euch das IGP usw Tuning spart und natürlich nur noch eine Box zu konfigurieren habt. Im Wartungsfall (eine Kiste muss ausgeschalten werden) ist die Konvergenzzeit nicht mehr von IGP und anderen Dingen abhängig. Die Verfügbarkeit der Lösung ist somit höher als vorher.

 

Das CPU "Problem" ist natürlich ein anderes (hat nichts mit VSS zu tun). Eine Lastverteilung wird hier schwierig, da beide RP's synchron sein müssten und somit so oder so alles wissen müsssten.

P.S. (Da das IGP und andere Prozesse weniger genutzt werden - entlastet VSS auch die CPU :-))

 

Welche SW habt ihr im Einsatz? - Welche SUP? Wie groß ist der BGP Table?

 

==> Ist hier wirklich der BGP Scanner Task das Problem (sh proc cpu)?

==> Da müsste man ggf. dir ControlPlane performanter machen oder optimierte BGP Scanner + Features in neueren IOS SW's verwenden.

 

[off topic - welche 10G Karten verwendet ihr für die 10 agg??]

 

//

wäre also nur die Frage wie sich VSS im Distribution Bereich macht im Vergleich zu GLBP oder HRSP?

\\

 

Der Hauptvorteil in den "normalen" non L3 routed Campus Designs (und hier hat Cisco eine Lösung bringen müssen, da eine Migration auf L3 routed Campus IMHO in den meisten Fällen sehr teuer wird, da die Access Switches nun routen müssen--> somit meist getauscht werden müssen) die es bei dem Kunden draußen gibt ist, dass man sich den "nervigen" STP spart und einen logischen Switch hat. Ebenfalls, wenn richtiges Design umgesetzt, wird die Lastverteilung durch MEC (hier unabhängig von GLBP - es ist eine Box) um einiges besser (per tcp port hashing + per [int]vlan hashing) und ohne Tricks (manche Hosts GW Mac A, manche Hosts GW Mac B) umgesetzt. Wie gesagt, fällt das Timertuning weg und der Kunde hat "konstante" Umschaltzeiten. Das gefällt den VoIP und MCAST Komponenten. Auch die Standardfehler, wie Unicast Flooding durch async routing und Co. fallen weg.

 

Ein PC könnte theoretisch mit zwei oder mehr Sessions 2G nutzen. Das hängt jedoch auch von den EC Hash Features des Access Switches ab.

 

Hope this helps.

bearbeitet 7. Januar 2010 von daking

[jpzueri 10]

Hi,

ich kann mir dies auch nicht vorstellen, dass die CPU-Auslastung vom BGP kommt.

Wir haben auch zwei c6500 mit sup720 und die sind bei 3-5% CPU-Auslastung und wir hatten früher sämtliche BGP-Routingeinträge.

Das Problem bei uns war die TCAM, würde ich auch kontrollieren:

sh platform hardware capacity | beg L3 Forwarding

Hier hatten wir eine Auslastung von 99-100%.

Deswegen haben wir die Routingtabelle kleiner gemacht.

 

ip as-path access-list 1 permit ^xxxx$

ip as-path access-list 1 permit ^xxxx_[0-9]+$

ip as-path access-list 1 permit ^xxxx_[0-9]+_[0-9]+$

 

route-map ..........

match as-path 1

 

router bgp xxxxxxxx

neighbor a.b.c.d route-map ......... in

 

also Prefixe mit 1,2 oder 3 AS einträgen in der Path-List, alles anderen Einträge über eine default-route zum Provider.

 

LG

JP

[daking 10]

Hi,

 

@jpzueri: Habt ihr vor der BGP Anpassung mal den TCAM angepasst (TCAM resize)? Oder wäre das sinnlos gewesen?

 

Jau - interessant wäre noch der output von sh proc cpu | exc 0.00% oder falls das nur ab und zu passiert (und das IOS passt) ein "process cpu threshold type total rising 80 interval 5 falling 50 interval 5" um den root cause zu finden.

 

cheers

[Poison Nuke 10]

da es mehrere Provider gibt fällt die Variante mit irgendeiner Default Route weg. BGP Fulltable (mehrere davon) sind also unumgänglich. Sprich so ca. 1,2Mio Routen-Einträge sind das kumuliert die der BGP Scanner verwalten muss.

 

TCAM liegt bei 30% oder so, sollte also nicht das Problem sein.

 

PFC3BXL mit DFC3BXL

 

das ganze soll dann aber mal auf einen Routereflektor ausgelagert werden, damit würde die Last schonmal deutlich geringer für den SUP werden.

 

mal schauen ich lass mir das nochmal durch den Kopf gehen.

 

Achja, ich meinte schon den Distribution Bereich im Enterprise Campus MOdell von Cisco. Also Access Switche sind da ja weiterhin L2 und sollten es auch denke bleiben, meiner Meinung nach handelt man sich viel mehr Probleme mit einer kompletten L3 Architektur ein, zumindest solange man noch IPv4 verwendet. Bei IPv6 würde ich mir das auch dann schon vorteilhafter vorstellen. Zumindest war jetzt halt einfach meine Überlegung, die Access Switche mit 2x 1G an je einen 6k, zwei davon laufen als VSS. Dann sollte man ja im Normalfall einen 2G Trunkt haben der als Portchannel läuft, wo im Failoverfall von einem 6k lediglich die Bandbreite von dem L2 Trunk dann sich halbiert aber nix weiter passiert, oder?

[jpzueri 10]

Hi

 

@daking: nein habe wir nicht gemacht und hatte ich auch noch nie das Vergnügen. Ist dies nei heikle Angelegenheit?

 

Ja, dieser output (sh prc cpu | exc 0.00%) ist auch sehr wichtig.

 

Noch was zu GLBP und HSRP.

GLBP ist ne schöne Sache, aber ich bevorzuge HSRP. Man hat zwar keine Lastverteilung, aber in der Fehlersuche ist es einfacher.

 

LG

JP

[daking 10]

Hi,

 

@jpzueri: Eigentlich nicht (man muss halt sicher sein, dass man die TCAM Ressourcen der anderen Protokolle die man "klaut" auch wirklich nicht benötigt)

Das nervigste an der Sache ist der benötigte Reboot - ohne den geht es nicht.

 

Die Ausbeute ist statt 192k TCAM für IPV4 dann 239k TCAM für IPv4... ist in manchen Situationen also auch nicht gerade der Anlass eine Party steigen zu lassen. :-)

---

 

==>Vorteil VSS: keine FHRP wird benötigt - easy Troubleshooting.. :-)

 

cheers