daking

Hi, @Otaku19: L2 Switch ohne jedliche Routingfunktion? cheers

Hallo, unter dem Vlan Interface no autostate oder unter den interfaces switchport autostate exclude. Falls das nicht klappt - schwierig (denke da werden dummy interfaces + no keepalive nicht funktionieren.) cheers

Hallo, schon mal auf die Idee gekommen, dass die Provider Leitung einfach suboptimal ist und gefixt werden muss? Wenn es bei 50 Komponenten funzt und hier nicht - dann wird es wohl eher der provider sein - also hier Case + escalation. Open failed: Req. min. rate + noise margin LOCAL:Max noise margin for power cutoff 31 ==> no showtime @ adsl Der Provider "muss" hier einheitliche (es soll funzen) Qualität liefern - sonst wird bei jedem Problem eine andere Firmware verwendet und irgendwas optimiert. Dies sollte die Betreibarkeit des Netzwerkes aus Kundensicht nicht gerade optimieren.. cheers

Hallo, BGP gibts nicht ohne BGP Scanner (:-). Der Scanner hat folgende Aufgaben [full scan]: Validate nexthop reachability Validate bestpath selection Route redistribution and network statements Conditional advertisement Route dampening BGP Database cleanup Falls sich dort was ändert - bemerkt dies der Scanner und kalkuliert --> gibt weiter an RIB bla bla. Der Scanner bearbeitet somit alles (nicht nur den next hop). Das macht dieser alle 60s für alle Prefixe - wenn sich nichts ändert kostet das nur ressourcen. Das ist dann eher suboptimal mit großen Routingtabellen --> desshalb hat man dieses Verhalten geändert. cheers

------------------------- 12.2(33)SXH ------------------------- BGP Support for Next-Hop Address Tracking ------------------------- The BGP Support for Next-Hop Address Tracking feature is enabled by default when a supporting Cisco IOS software image is installed. BGP next-hop address tracking is event driven. BGP prefixes are automatically tracked as peering sessions are established. Next-hop changes are rapidly reported to the BGP routing process as they are updated in the RIB. This optimization improves overall BGP convergence by reducing the response time to next-hop changes for routes installed in the RIB. When a bestpath calculation is run in between BGP scanner cycles, only next-hop changes are tracked and processed. ------------------ :-) SXF --> non default by the way: die PFC3B unterstützt kein VSS (falls noch nicht bekannt..)

Hi Poison Nuke, okay --> kein TCAM Problem. Welche IOS Version? BGP Scanner sollte Event Driven sein (muss nicht alle Prefs im Table checken) und via ATF (NHT) bei Problemen getriggert werden (und bald via BGP PIC). Sicher das der Scanner nervt? oder doch eher BGP Router Task...:-) ==>Teil 2: richtig. cheers

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

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

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.

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.

Hi, mit ASICs oder FPGAs usw. wird das wohl nichts zu tun haben - sondern eher mit der onboard batterie auf dem baseboard der der sup (nvram ist hier noch immer batterie gepuffert). oder einem defekte nvram ciao

Hallo, hier nur eine kurze Anmerkung. .. Interessant ist hier der Channel Loadbalancing Algorithmus. In manchen Konstellationen und mit mancher Hardware wird der Channel suboptimal ausgelastet sein oder kein Loadbalancing stattfinden. Vielleicht unterstützt der NIC Treiber "per Packet" Lastverteilung - ein Cisco Switch wird dies bei einem L2 Channel niemals unterstützen. Im Default sollte hier (6k) nach SRC+DST MAC oder SRC Mac der Bucket selektiert werden. Ist der Server hinter einer L3 Instanz in einem eigenen VLAN wird hier recht wenig Lastverteilung stattfinden. (:-). Man sollte also die Konfiguration optimieren oder sich Gedanken machen, ob die Konstellation so Sinn macht.

Hi, scheint wohl eher interrupt traffic / sw switched traffic zu sein. welchen Traffic teilt der Loadbalancer auf? Was ist die Aufgabe? Folgende Pakete werden via SW Pfad geforwarded: - Pakete mit gesetzten IP Optionen - Pakete mit abgelaufener TTL - ARP - Software ACL's - Pakete die an die CPU gesendet werden müssen (:-) (show controller CPU) ==> ist hier igmp/mcast im einsatz? ==> pbr? ==> fehlende ressourcen (show platform tcam utilization) ciao

Hallo, habt ihr eigentlich Probleme durch die hohe control plane Last? Im Moment ist noch immer unklar welcher task hier ressourcen frisst. die cpu threshold config erzeugt keine probleme und keine zusätzliche last. habe die config schon 100mal in größeren netzen verwendet. Also sollte nun erst mal gecheckt werden welcher task hier last erzeugt. Welche Features hast du aktiviert? pbr? Im oben angegeben output sind 10% der 21% gesamt cpu last interrupt basierend. also bis jetzt max 11% cpu und 10% software forwarding - wo sind die 70%? ciao

Hola, 1. wie sieht dein setup aus? 2: hohe CPU Auslastung kommt meist durch Flows die nicht in HW geforwarded werden können. Interessant wäre natürlich zu wissen welcher Task hier die CPU auslastet. Dies kannst du herausfinden indem du im richtigen moment sh proc cpu | exc 0.00% absetzt (bla bla ist klar). Falls dies nur sporadisch passiert kannst du entweder über den embedded ressource manager (ERM - falls dies die HW unterstützt) oder über das process cpu threshold feature (falls von der hw unterstützt - habe gerade meinen 3750 nicht zur hand) erkennen welcher task hier stress macht: process cpu threshold total rising 60 int 5 falling 20 int 5 ==> Nun wird falls dir CPU über 60 prozent ist eine log message mit dem Task ausgegeben. Generell muss man beim 3750 wissen, dass 16 Queues Richtung CPU existieren. Auf diese Queues werden verschiedene Protokolle aufgeteilt, um sich nicht gegenseitig zu beeinflussen. wäre dumm, wenn "normaler" IP Traffic der nicht in der HW gefowarded wird die gesamte STP Kommunikation unterbrechen würde.. deshalb verschiedene Queues. Im ersten Step könnte man mal sehen, ob es hier Probleme gibt: sh platform port-asic stats drop (in der ersten page sollten nun die 16 Queues ausgegeben werden) --> in welcher Queue wird gedropped? wahrscheinlich 6, da diese für Software Forwarding (punted to cpu) verwendet wird. Welche Pakete hier das Problem sind kann mit debug platform cpu-queues software-fwd.. ausgegeben werden. dieser debug sollte eigentlich safe sein ---> würde jedoch eher mal im wartungsfenster (falls vorhanden und möglich) testen und natürlich wie immer mit logging rate-limit. sonst wird man selber zum debugging problem. ciao

Hier noch ein paar mehr Infos zu Loadbalancing: Cisco IOS hints and tricks: load balancing ciao

Hallo zusammen, warum soll Loadbalancing in dieser Konstellation (zwei Provider) ein Problem sein. Das Default CEF Loadbalancing bildet den Hashwert für das Loadbalancing nach der SRC + DEST IP Adresse. Also wird dies mit allen L4 Protokollen funktionieren..natürlich auch UDP. Der Rückweg wird auch immer über den Ausgangsprovider verwendet. ==> no problem. (Wär ja schlimm, wenn man zwischen zwei Providern kein Loadbalancing realisieren könnte) Falls verschiedene Bandbreiten verwendet werden und statische Routen, kann man hier auch ein unequal Loadbalancing hinbekommen. Dann wird die stärkere Leitung mehr verwendet. Das Failover wird über bekannte Tracking Setups realisiert. ciao

Hallo, die Karten sind natürlich OIR fähig. Sollte kein Problem sein. Ein reboot ist hier definitiv nicht nötig. Bei manchen älteren Karten kann es zu einem kurzen BUS Stall kommen (200ms-500ms) und dadurch zu PKT Verlusten kommen. In der 67 Serie passiert dies im Normallfall nicht. Falls möglich kannst du die Karte im Slot auch für den Tausch auf Shutdown setzen. Karte tauschen und dann die neue wieder auf no shut setzten. Sollte jedoch generell kein Problem sein. Einfach tauschen. Bei einem optimalen Tausch sollte die Karte nicht "mädchenhaft" (sorry aber mir fällt gerade nichts ein) in das Chassis geschoben werden, sondern relativ schnell Kontakt zur Backplane bekommen.... ciao

Hallo, generell können die 2960 Switches PVLAN Edge Ports wie die 2950 dies schon konnten. Dies sollte ausreichend sein, da die 2960 Switches eh nur Ports im Accessbereich zur Verfügung stellen sollen. In anderen Bereichen könnten dann andere Features eingesetzt werden. Mit der richtigen Mischung aus L2 und L3 Features kann dann die Anforderung realisiert werden. Die Frage ist nur was du eigentlich genau machen magst. Falls du Endgeräte über eine L2 Access seperieren willst und diese untereinander in einem VLAN nicht kommunizieren sollen kannst du PVLAN einsetzten. Das macht im Enterprise oder Campusumfeld bei kleinen oder größeren Netzen Sinn. Im L3 Bereich könnte man sich vorstellen, dass die durch das PVLAN Feature getrennten Hosts dann gebündelt über eine oder mehrere VRFs wieder bestimmten Services oder Anwendungen zugewiese werden. Im Providerumfeld würde man vielleicht den schwachen Cat4k im minimalistischen Metroaccess benutzen (in einer vrf lite konstellation). Diese Anbindungen würden dann wohl an die Grenzen der normalen 4k oder 4kE angepasst sein also nicht mehr als 6 oder 20 Gbit/s benötigen. In den nächsten Layer können weitere Features eingesetzt werden. Interessant wäre ein genaues Ziel um eine sinnvole Designlösnug zu finden. Bezieht sich diese Anfrage auf das gewagte DC Design aus der anderen Anfrage? ciao

Hallo, wenn du nicht weißt welche DSCP Werte ein Server generiert, kanns du diesen nicht vertrauen. Im Normalfall würde ich in diesem Fall die Server auf untrusted konfigurieren. Wichtig ist, dass der VoIP Traffic priorisiert wird und die Markierungen nicht in der DS Domain verloren gehen. Der "normale" Traffic kann sich dann selber handeln. Natürlich kann man sich über komplexere Konfigurationen Gedanken machen, jedoch muss man dann mehr Zeit investieren und ein sauberes Design entwickeln. Nach der Umsetzung sollte das geplante Design dann durch prof Benchmarks validiert werden.. Generell geht es nicht um die Server oder Komponenten, sondern um Traffic Klassen die gesondert behandelt werden sollen. ciao

Hola, absolut richtig. Die Trust Boundary sollte so nah am Endgerät plaziert werden wie möglich. Falls nun Server (das war denke ich die Frage) am 4k angeschlossen sind, sollte dort die Trust Boundary plaziert werden. ciao

Hallo, die Sup-6E unterstützt keine qos kommandos (außer qos trust device cisco-phone) Falls du die COS/DSCP Werte eines Ports zurücksetzten (untrusted) willst geht dies über eine policy-map: ! policy-map in_untrusted class class-default set dscp default set cos 0 ! interface x/y service-policy input in_untrusted ! ciao

Hallo, falls du ein Design ohne STP realisieren willst: L3 Routed Campus: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns656/net_design_guidance0900aecd804ab689.pdf VSS falls 6k env: Virtual Switching System (VSS) Q&A [Cisco Catalyst 6500 Virtual Switching System 1440] - Cisco Systems oder in Zukunft und dann auch L2 (Datacenter) - DCE / CEE / TRILL und Co.: http://www.cisco.com/web/DK/assets/docs/presentations/CiscoDCE_UnifedFabric-June-2008.pdf ciao

Hallo, du willst zwei pysikalische Interfaces im gleichen Segment betreiben. Dies geht nur mit einer bridge-group. WLAN und Eth (VLAN) Interfaces sind dann aus L2 Sicht verbunden. Fall hier noch eine L3 instanz vorhanden sein soll muss irb aktiviert sein. Dann kann unter dem Bridge Virtual Interface eine IP Adresse vergeben werden. Ohne BVI müsste zwischen den beiden Segmenten Routing konfiguriert werden. Der Router muss jedoch ebenfalls wissen, welche Interfaces verbunden werden sollen: int vlan 1 bridge-group 1 ! int dot11 bridge-group 1 ciao

Hallo, mit shutdown / no shutdown muss das funktionieren. Wenn natürlich noch immer ein nicht erlaubtes Gerät am Port hängt (sticky mac), geht der Port sofort wieder runter. Natürlich kann man auch das errdisable recovery timout anpassen (sollte man eh immer). ciao