waishon
Goto Top

Cisco SG-300 TCAM

Moin,

wir sind aktuell dabei unseren Cisco SG300-10 zu testen.

Wir haben in diesem 4 VLANs eingericht zwischen diesen der Cisco routen soll.
Dann wurde das Routing bei neuen Geräten plötzlich sehr lahm, wo wir dann gesehen haben, dass die TCAM Resources Table voll ist.

Folglich haben wir diese jetzt auf das Maximum von 462 gestellt und neugestartet, worauf wieder alles schnell lief.

Allerdings stellen sich uns folgende Fragen:
Vereinfacht gesagt speichert TCAM ja die Routing Regeln in der Hardware, sodass ein Routing mit Wirespeed möglich ist, soweit ich das verstanden habe.

1. Heißt das, dass maximal 462 Clients mit Wirespeed geroutet werden können, oder liegt die Zahl nochmal deutlich darunter?

2. Gibt es die Möglichkeit dieses TCAM Tabelle weiter zu vergrößern, indem man den Platz der IPv6 Regeln nutzt, die wir in unserem Netz nicht benötigen?

Ich habe noch ein Bild der TCAM Utilization angehängt
routing

Content-Key: 343449

Url: https://administrator.de/contentid/343449

Printed on: April 19, 2024 at 23:04 o'clock

Member: aqui
aqui Jul 14, 2017 updated at 11:29:40 (UTC)
Goto Top
Wie groß ist denn deine Routing Tabelle das du da an die Limits stößt ?! Das ist recht ungewöhnlich bei simplen 4 VLANs. Nicht das der Switch da ne Macke hat ?!
Hast du die aktuellste Firmware und Bootcode auf den Switch geflasht ?? Das solltest du in jedem Falle machen.
Nur wenn man eine riesige Routing Tabelle hat muss man an den TCAM Parameter fummeln.
Und ja...wenn du den v6 Space freigibst ergibt das größere TCAM Resourcen für v4 only.
Nein, die L3 TCAM bezieht sich auf 462 IP Netze bzw. Prefix Masken nicht auf die Clients. Deshalb die Frage nach der Größe der Routing Tabelle.
Member: Waishon
Waishon Jul 14, 2017 updated at 12:06:12 (UTC)
Goto Top
Also die Netzwerkstruktur ist folgendermaßen:
VLAN 10 - 10.10.0./16 -> Internet. Die Default Route liegt auf diesem VLAN (1 Gerät)
VLAN 20 - 10.20.0.0/16 -> Benutzer VLAN (2 Geräte)
VLAN 30 -10.30.0.0/16 -> Gast (2 Geräte)
VLAN 100 - 192.168.0.0/16-> Server und VMs (70 Geräte)

Jetzt schreibst du, dass sich das TCAM auf die IP Netze bzw. Prefix Masken bezieht. Heißt das, dass eigentlich nur 4 belegt sein müssten, weil wir ja nur 4 IP-Netze haben? Die Anzahl "In Use" auf dem angehängten Bild entspricht nämlich in etwa der Anzahl der Clients die sich im gesamten Netzwerk befinden.

Die aktuelle Firmware habe ich tatsächlich noch nicht drauf. Die Installiere ich sofort face-smile

Wie schaffe ich es denn den IPv6 Space für v4 freizugeben? Sind das insgesamt 512 oder habe ich dann 1024?
Member: aqui
aqui Jul 14, 2017 updated at 13:26:11 (UTC)
Goto Top
Gibt es einen Grund warum du /16er Netze verwendest ?? Du wirst ja wohl kaum 65534 Endgeräte in diesen Netzen adressieren wollen. Schon gar nicht im Internet VLAN, denn da ist vermutlich nur noch der Router drin so das eine /30 (255.255.255.252) Maske da vollends reicht. Warum also keine /24 oder /23 Prefixe für die Produktivnetze ?
Richtig, in deinem TCAM wären nur 4 Einträge. Das kann unmöglich sein das du da was umstellen musst.
Da hast du ein ganz anderes Problem was nicht mit TCAMs zu tun hat.
Machst du Spanning Tree oder sowas im Netz ?
Wichtig ist erstmal die aktuellste Firmware. Macht man als verantwortungsvoller Netzwerker eigentlich immer als Erstes.
Member: Waishon
Waishon Jul 14, 2017 updated at 16:55:45 (UTC)
Goto Top
So,

ich habe jetzt die Firmware geupdatet.

Und ja Spanning Tree ist standardmäßig auf dem Cisco aktiviert.
Wenn ich das richtig verstehe, dann versucht das STP ja sicherzustellen, dass es immer nur eine Route zu einem Client gibt.
Heißt das, dass das STP für jeden Client dann eine Route im TCAM hinterlegt, wodurch das ganze "vollgemüllt" wird?

Ansich scheint STP ja nichts schlechtes zu sein face-smile

Edit:// Ich habe das ganze einmal zu testen im Cisco deaktiviert. Leider hat dies nichts geändert
Member: aqui
aqui Jul 14, 2017 updated at 17:22:43 (UTC)
Goto Top
dann versucht das STP ja sicherzustellen, dass es immer nur eine Route zu einem Client gibt.
Nein vollkommen falsch verstanden. Spoanning Tree ist ein reines Layer 2 Protokoll und hat rein gar nix mit Routing (L3) zu tun. Es verhindert Layer 2 Loops. Mit dem TCAM hat das nix zu tun.
https://de.wikipedia.org/wiki/Spanning_Tree_Protocol
Lesen und verstehen...!
Hast du eine reinrassige Umgebung oder Mischmasch an Herstellern bzw. hast du überhaupt mehr als einen Switch im Netzwerk und ggf. redundante Links wo STP ins Spiel kommt ?
Ansich scheint STP ja nichts schlechtes zu sein
Per se stimmt das. Nur man sollte, wenn dann, auch STP richtig customizen mit Root und Backup Root Switch ! Stichwort STP Priority.
Member: Waishon
Waishon Jul 14, 2017 at 17:38:42 (UTC)
Goto Top
Ja wir haben mehrere Switches im Netzwerk. Und ein Mischmasch trifft es ganz gut.

In der "Mitte" befindet sich der Core Switch, der Cisco SG300-10, der Inter-VLAN Routing betreibt. An diesem hängen ein Zyxel XGS2210 L2 und eine HP Gurke 1920-48g auch im L2 Betrieb, die jeweils ein Trunk mit LA auf den Cisco mit den VLANs haben. Also ansich kein großes Netzwerk und folglich keine redunanten Links. Also könnte STP ja eigentlich auch aus, oder?

Hättest du denn noch eine Idee, woran das liegen könnte? Bist du dir sicher, dass das so nicht normal ist?

Wir haben uns an dieser Anleitung inspiriert:
https://www.linuxmuster.net/wiki/dokumentation:addons:subnetting:l3switc ...
Wichtig: damit der Router, wegen seinem kleinen Defaultwert (128) bei TCAM nicht schon bei ca. 100 CLients einen ARP Cache Überlauf bekommt, ist es wichtig den TCAM Wert hoch zu setzen.
Nach diesem "Hinweis" scheint es ja normal zu sein.

Weißt du denn wie man die TCAM Größe von IPv6 noch zu IPv4 hinzufügt? Oder ist 512 das absolute Maximum für IPv4 und IPv6?
Member: aqui
aqui Jul 14, 2017 updated at 17:52:11 (UTC)
Goto Top
Wichtig ist in so einer Konstellation das der Ciscos zwingend Rootbridge ist !
Das stellt man über die Bridge Priority ein:

stp

Die Backup Root sollte 8192 haben. Da du keinen zweiten Core hast kann das entfallen und es reicht eine Root Bridge. STP Priorities werden modulo 4096 konfiguriert !
Das ist extrem wichtig damit nicht irgendein blöder Access Switch Root Bridge wird für den Spanning Tree.
Loopback Guard sollte man auch aktivieren. Schützt vor den DAU Dödels die auf den kleinen 5 Port Tischswitches vom Blödmarkt Loops stecken...!

Ebenso wichtig ist das durchgehend alle Switches auf RSTP (Rapid STP) gestellt sind. Das STP Protokoll muss einheitlich sein !
Wie viel Clients hast du denn insgesamt am Cisco. Wenn das 1000 sind macht es Sinn die TCAM anzupassen bei 150 Clients ganz sicher nicht.
Hast du mal die Logs im Cisco angesehen wenn das passiert ??
Vermutlich hast du irgendein STP Problem aber kein TCAM Problem. Ausnahme natürlich bei einer hohen Clientzahl.
Member: Waishon
Waishon Jul 14, 2017 at 18:00:40 (UTC)
Goto Top
Danke für den Tipp! Ich arbeite mich in STP mal etwas ein. Den Loopback Guard haben wir bereits aus genau diesem Grund an.

Als wir die TCAM auf Default hatten (glaub 128), dann kam folgender Fehler im Log
%ARP-E-ARPTBL: ARP Table Overflow, aggregated (2)

Jetzt steht dieser auf 440, da noch etwas Platz für die ACE/ACLs vorhanden sein muss.

Da wir eigentlich Public Wifi anbieten wollen, kann man eigentlich so mit maximal 300-400 Geräten im Netz rechnen + 100 stationäre Computer.
Aktuell haben wir den ARP Timeout auf 300s gesetzt, sodass möglichst schnell wieder Platz gemacht wird face-smile
Aber optimal ist die Lösung wirklich nicht.
Member: aqui
aqui Jul 15, 2017 updated at 11:46:25 (UTC)
Goto Top
300-400 Geräte dann aber segmentiert hoffentlich und dann zwingend in einem private VLAN oder isolated VLAN damit man eine any zu any Kommunikation der WLAN User zwingend unterbindet und die Broadcast Last minimal hält.
Ebenso natürlich eine Client Isolation auf dem WLAN ist hier zwingend.
Normal sollten in einer Layer 2 Collision Domain nie mehr als 150-200 Clients plus minus sein. Beim WLAN hast du ja schon das Problem das du da entsprechend leistungsfähige Accesspoints brauchst die mindesten 50-60 User bedienen können.
Mit TP-Link und NetGear APs vom Blödmarkt Grabbeltisch wirst du da garantiert Schiffbruch erleiden sofern du da auch auf die Billigschiene setzt wie bei der Switch Infrastruktur.
Das du da den TCAM etwas tunen musst ist klar. Auch der ARP Timeout Timer ist richtig.
Hier muss man allerdings eine gute Balance finden, denn das kann auch erhöhten ARP Broadcast erzeugen was dann wieder negativ wäre.
Was aber komisch ist das du schreibst es wäre langsam. Das kann eigentlich kein TCAM Problem sein.
Kann der Switch kein ARP mehr cachen oder L2 Forwarding Infos dann geht es gar nicht, aber nicht langsam. Das ist was eben noch eine vage Vermutung lässt das das Problem eben ganz woanders liegt.
Member: Waishon
Waishon Jul 15, 2017 updated at 17:53:49 (UTC)
Goto Top
Moin,

danke für die Hinweise face-smile. Ich weiß nur noch nicht ob das mit dem Private VLAN so umsetzbar ist, ---(weil wir in dem WLAN VLAN eigentlich eine Client zu Client Kommunikation erwünschen.)--
Falsch ausgedrückt:
Wir erwünschten eine Kommunikation zwischen WLAN und LAN, da einige Rechner sich im selben VLAN befinden, die erreichbar sein sollen, was man prinzipiell durch Routing lösen könnte, das stimmt, allerdings gibt das unsere Infrastruktur nicht her, weil wir in vielen Trakten keine Managed Switche haben.
Allerdings können die Ubiquitis ja WLAN -> WLAN Kommunikation verhindern, auch wenn das natürlich nicht verhindert, dass sich jemand einen eigenen AP and Netz hängt :D

Ich denke der nächste Logische Schritt wäre es, dass ganze erst einmal mit einer kleinen Benutzergruppe zu testen, sprich 1-2 Räume mit WLAN auszustatten und wenn es wie erwartet läuft, dann ggf. mehrere VLANs einrichten, die bei uns zum Beispiel die einzelnen Schultrakte repräsentieren, wo nie mehr als 100-200 Schüler sind. Und dann ggf. auch das L3 Switch upzugraden. Wäre ein SG500 mit 2000 TCAM Einträgen da besser geeignet, oder sollte man auf eine ganz andere Reihe setzen, die aber nicht direkt ein paar tausend Euro kostet face-smile

Ich kann das nächste Woche ja mal simulieren, indem ich den TCAM Wert für IP Routing auf 50 runterstelle und dann Mal schauen, wie sich die Geräte verhalten face-smile

Edit:Ich habe mir jetzt mal die Private VLANs etwas genauer angeschaut, es kann aber sein, dass ich immernoch ein grobes Verständnisproblem habe, deswegenhier einmal wie ich es verstanden habe:
Wenn ich Isolated Private VLANs an Ports aktiviere dann können Geräte die an diesen Ports hängen nicht mehr untereinander kommunizieren, allerdings mit Geräten die im Primary VLAN sind schon. Wenn ich an diesen Port jetzt allerdings einen Unamanged Switch hänge, und an diesen Wiederum zwei Rechner dran hänge, dann können diese ja wieder untereinander kommunizieren, oder? Und wie ist das, wenn ich z.B. ein Unifi AP dran hänge? Den müsste ich dann ja auch so konfigurieren, dass WLAN Clients Nicht untereinander kommunizieren können, damit der das nicht intern switcht, oder?

Sprich um es vollkommen zu "isolieren" müssten alle Switche im Netzwerk managebar sein und Private VLANs unterstützen?

Noch ein Edit2:

Angenommen ich würde unser Netzwerk in Private VLANs strukturieren statt wie bisher in einzelne VLANs und dann mit einem L3 Switch zwischen diesen Routen.

Sprich Schüler bekommen Isolated Ports zugewiesen, genauso wie Schulinterne Computer. Da alle auf unsere Server zugreifen sollen, könnten die Server in das Primary VLAN bzw. an den Promiscuous Port angeschlossen werden. - Hier bin ich mir nicht sicher: Geht das überhaupt, sprich kann ich mehrere Server hier überhaupt anbinden, sodass alle Clients diesen erreichen können? - Wenn ja, dann können diese Server ja auf L2 mit Wirespeed erreicht werden, ohne dass ich einen L3 Switch benötige. Das Gateway wäre gleichzeitig eine Firewall ohne Wirespeed die verhindert, dass die Isolated Clients auf L3 miteinander kommunizieren können.

Wofür bräuchte man also einen L3 Switch? Weil genau diese Idee, mehrere Server an einen Promiscuous Port/Primary VLAN anzuschließen schlicht nicht möglich ist und man somit einen L3 Switch benötigt, um dazwischen mit Wirespeed zu Routen?
Sprich wo ist genau der Vorteil von VLAN statt Private VLANs, außer das man bei VLANs mehrere Subnetze nutzen kann?
Member: aqui
aqui Jul 16, 2017 at 11:11:50 (UTC)
Goto Top
Wir erwünschten eine Kommunikation zwischen WLAN und LAN
Bei Gästen bist das aber auch immer die Gefahr, das jeder jeden mit Hacker Tools, Trojanern usw. angreifen kann. Das sollte man dann beachten und die Gäste rechtlich entspr. darauf hinweisen um sich vor Schadensersatz Ansprüchen usw. zu schützen.
auch wenn das natürlich nicht verhindert, dass sich jemand einen eigenen AP and Netz hängt
Sowas verindern verantwortungsvolle Netzwerker immer mit simpler 802.1x Port Security:
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
mit einer kleinen Benutzergruppe zu testen,
Der richtige Schritt ! Proof of Concept ist immer der richtige Weg face-wink
Wenn ich an diesen Port jetzt allerdings einen Unamanged Switch hänge,
Ja, damit hebelst du ja logischerweise in PVLAN Konzept aus. Jedenfalls für die die an diesem kleinen Switch hängen.
Sprich um es vollkommen zu "isolieren" müssten alle Switche im Netzwerk managebar sein und Private VLANs unterstützen?
Ja.
sprich kann ich mehrere Server hier überhaupt anbinden, sodass alle Clients diesen erreichen können?
Ja das geht. Das ist der Sinn von PVLANs.
Aber so oder so kannst du das auch über entsprechende IP Accesslisten OHNE die PVLANs erreichen. Zwar nicht so wasserdicht aber doch sicherer als ein offenes Scheunentor. face-smile
ja auf L2 mit Wirespeed erreicht werden
Auch L3 ist heutzutage immer Wirespeed. Beim Switching ist das kein Unterschied mehr da alles in ASIC Hardware.
Wofür bräuchte man also einen L3 Switch?
Immer wenn man in Wirespeed zwischen VLAN Segmenten routen muss !!
PVLANs bruacht man nur in öffentlichen Segmenten oder z.B. bei einem Hoster um any zu any Kommunikation und entsprechende Angriffe sicher zu verhindern.
Member: Waishon
Waishon Jul 16, 2017 updated at 20:09:21 (UTC)
Goto Top
Vielen Dank für die Antwort!
Das hilft uns schonmal weiter face-smile

Also ist es schon richtig und sinnvoll, dass man Schüler, Lehrer und Server jeweils in ein eigenes VLAN packt und dann mit einem L3 Switch zwischen diesen routet, da man dann z.B. entsprechende ACLs und co anlegen kann? Und das mit den PVLANs könnte man intern dann nutzen, wenn man z.B. die Ports am Schüler VLAN isolieren möchte, richtig?

Aber ein gesamtes Netzwerk nur aus L2 PVLANs + Firewall zusammenzubauen, wie oben geschrieben, wäre prinzipiell möglich, aber deutlich sinnvoller für Interne Netzwerke sind VLANs + L3 Switch mit entsprechenden ACLs?

Edit:// Habe gerade die Funktion: Port Isolation gefunden, die auch alle Switche unterstützen die wir einsetzen. Wenn ich das richtig verstehe, dann können alle Ports die auf "Isolated" gesetzt sind nicht mehr miteinander auf L2 reden. Ich denke das reicht vollkommen für unsere Zwecke und die Broadcast Last sollte dadurch auch minimiert werden face-smile. Leider kann die HP Switch Gurke kein PVLAN unsere Zyxel allerdings schon.

Die Port Isolation ist ja L2 only, sprich die können immernoch auf L3 "sprechen" sofern im L3 Switch/Firewall keine ACLs definiert sind, allerdings wird der Traffic zum Router "geleitet" und dort entsprechend zurückgeschickt, oder?
Also vereinfacht gesagt face-smile
Member: aqui
aqui Jul 17, 2017 updated at 11:06:06 (UTC)
Goto Top
dass man Schüler, Lehrer und Server jeweils in ein eigenes VLAN packt
Absolut ! Allein schon die Sicherheit gebietet das !
wenn man z.B. die Ports am Schüler VLAN isolieren möchte, richtig?
Absolut richtig !
aber deutlich sinnvoller für Interne Netzwerke sind VLANs + L3 Switch mit entsprechenden ACLs?
Jein.... Eins oder einige der VLANs können da ja durchaus PVLANs sein. Das sind die in denen man eben keine Any zu Any Kommunikation haben will. Geroutet wird ja trotzdem zwischen den IPs der VLANs.
Leider kann die HP Switch Gurke kein PVLAN
Soviel zum Thema billige HP Gurken !! Die können Drucker und PCs aber kein Netzwerk. No more comment face-wink
der Traffic zum Router "geleitet" und dort entsprechend zurückgeschickt, oder?
Yepp, das ist so richtig !
Member: Waishon
Waishon Jul 17, 2017 at 11:17:31 (UTC)
Goto Top
Danke, dann habe ich das soweit ja schonmal verstanden face-smile

Wir haben jetzt in unserem Zyxel XGS2210 einmal die Port Isolation an den Port 1 und 2 aktiviert, (keine PVLANs), ein Rechner, der an Port 1 hängt, kann nicht mehr mit dem an Port 2 reden. Das ist ja auch schonmal richtig so. Allerdings können diese Rechner auch nicht über L3 kommunizieren, sobald ein Router (in dem Fall Cisco ohne ACLs) angeschlossen ist. Ist das das richtige verhalten?

Laut Zyxel Manual verhindert die Port Isolation eine Kommunikation mit allen Ports, auf denen die Isolation aktiviert ist, was ja auch funktioniert und erlaubt aber gleichzeitig eine Kommunikation mit allen anderen Ports, auf denen keine Isolation aktiviert ist, was auch funktioniert. Allerdings scheint der Zyxel L2 Switch alle Pakete zu droppen, die an die Mac-Adresse des Rechners an dem anderen Isolierten PC addressiert sind und schickt die Pakete nicht an den L3 Switch, der das Paket, dann entsprechend routet. Wenn ich das richtig lese, ist das aber auch das gewünschte verhalten oder?

Gibt es denn eine Möglichkeit genau dies umzusetzen, also dass die Isolierten Ports alle ihre Pakete an den L3 Router schicken, der dass dann mit seinen ACLs abgleicht und dann ggf. das Paket wieder weiterleitet? Klar die Last auf einem L3 Router ist da natürlich höher face-smile
Member: aqui
aqui Jul 18, 2017 at 11:43:25 (UTC)
Goto Top
sobald ein Router (in dem Fall Cisco ohne ACLs) angeschlossen ist. Ist das das richtige verhalten?
Ja das ist klar das das nicht geht ! Denk doch mal selber etwas nach...!!
Der Cisco Router wird vom Switch ja wie ein normaler Client im PVLAN behandelt. Das das ein Router ist "sieht" der Switch ja nicht...wie auch ?
PVLAN Betrieb blockt sämtliche Broadcasts der Ports untereinander mit Ausnahme sog. "Uplink" Ports die man im PVLAN definiert. Dort wird alle so geforwardet wie an einem richtigen Port.
Ohne das am Cisco Port würde ein Endgerät jetzt einen ARP Broadcast loschicken um mit dem Cisco kommunizieren zu können. Der antwortet dann mit seiner HW Adresse und die Kommunikation findet statt.
Da aber in einem PVLAN Broadcasts geblockt werden werden natürlich auch die ARPs geblockt. Der Cisco bekommt seinen ARP also gar nicht und die Verbindung ist blockiert.
Das Blocken der ARP Broadcasts in PVLANs ist der entscheidende Faktor der so die Kommunikation der Clients unterbindet.
Erst wenn du dem Cisco Port im PVLAN dediziert in der Konfig sagst: "Hier bitte Broadcasts..." (was man mit dem Uplink oder bei dir dem "Isolation" Kommando macht) dann kann der Router in einem PVLAN auch erreicht werden.
So einfach ist das... face-wink
also dass die Isolierten Ports alle ihre Pakete an den L3 Router schicken,
Ja, siehe oben ....