5
Ruckus ICX Traffic Policy Rate-Limit Etherconnect
Hallo zusammen,
ich habe hier als Projekt die Anbindung von mehreren Außenstandorten über eine Telekom Etherconnect auf dem Tisch liegen. Laut Aussage des Telekom Supports muss die Bandbreite auf die tatsächlich gebuchte Bandbreite ausgehend am Kundengerät (Ruckus ICX7850) limitiert werden. Am Hauptstandort haben wir eine 10Gbit, an den Außenstandorten jeweils 1Gbit Grundleitung und als gebuchte Bandbreite nur 100Mbit.
Wenn ich das jetzt alles richtig verstehe, haben die RD von der Telekom schon ein Rate Limit eingestellt, verwerfen aber alles was über z.B. 100Mbit gehen würde, somit muss jetzt am Hauptstandort als auch an den Außenstandorten ausgehend nochmals die Bandbreite limitiert werden.
Mein Vorgehen wäre jetzt, als erstes eine Policy anlegen:
ACL erstellen:
Danach im Interface setzen:
Jetzt sehe ich folgendes Problem: Mir schwirrt im Hinterkopf umher, das Regeln ausgehend immer zu Lasten der CPU und nicht der ASICs gehen. Bei dem ICX7850 sehe ich da vielleicht noch kein Problem, aber bei den Außenstandorten sind ICX7450 und ICX7250 als Router im Einsatz. Ab welcher Belastung kann sowas zu Problemen führen?
Insgesamt wäre 4 Standorte jeweils auf 100Mbits und ein Standort 400Mbits zu beschränken.
Was passiert wenn die Bandbreite überschritten wird, werden da die Pakete einfach nur verworfen oder gibt es dafür entsprechende Egress Queues?
Hat jemand Erfahrung mit dem Etherconnect-Produkt von der Telekom?
Grüße
ich habe hier als Projekt die Anbindung von mehreren Außenstandorten über eine Telekom Etherconnect auf dem Tisch liegen. Laut Aussage des Telekom Supports muss die Bandbreite auf die tatsächlich gebuchte Bandbreite ausgehend am Kundengerät (Ruckus ICX7850) limitiert werden. Am Hauptstandort haben wir eine 10Gbit, an den Außenstandorten jeweils 1Gbit Grundleitung und als gebuchte Bandbreite nur 100Mbit.
Wenn ich das jetzt alles richtig verstehe, haben die RD von der Telekom schon ein Rate Limit eingestellt, verwerfen aber alles was über z.B. 100Mbit gehen würde, somit muss jetzt am Hauptstandort als auch an den Außenstandorten ausgehend nochmals die Bandbreite limitiert werden.
Mein Vorgehen wäre jetzt, als erstes eine Policy anlegen:
traffic-policy 100MRate rate-limit byte-based fixed cir 100000 exceed-action drop countACL erstellen:
ip access-list extended 11
permit ip any 10.10.0.0 0.0.0.255 traffic-policy 100MRateDanach im Interface setzen:
int e 1/1/11
ip access-group 11 outJetzt sehe ich folgendes Problem: Mir schwirrt im Hinterkopf umher, das Regeln ausgehend immer zu Lasten der CPU und nicht der ASICs gehen. Bei dem ICX7850 sehe ich da vielleicht noch kein Problem, aber bei den Außenstandorten sind ICX7450 und ICX7250 als Router im Einsatz. Ab welcher Belastung kann sowas zu Problemen führen?
Insgesamt wäre 4 Standorte jeweils auf 100Mbits und ein Standort 400Mbits zu beschränken.
Was passiert wenn die Bandbreite überschritten wird, werden da die Pakete einfach nur verworfen oder gibt es dafür entsprechende Egress Queues?
Hat jemand Erfahrung mit dem Etherconnect-Produkt von der Telekom?
Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-ID: 669809
Url: https://administrator.de/contentid/669809
Printed on: December 7, 2024 at 18:12 o'clock
5 Comments
Latest comment
Bedenke das die CIR Rate ohne das Keyword "byte-based" packets/s meint. Ob in den Paketen dann 64 oder 1500 Bytes enthalten sind ist egal. Das korrespondiert also nicht unbedingt genau zur Bandbreite. Ggf. ist es besser mit byte based zu arbeiten um genauer zu sein.
Du musst schon so vorgehen, da Rate Limiting ohne ACL ja immer nur inbound funktioniert. Um outbound zu limiten musst du Rate Shaping per ACL machen. Das sollten die 74er und 72er aber auch wuppen können es geht ja lediglich im Dropping.
Zu mindestens was TCP basierten Traffic anbetrifft kommt es ja so oder so sofort durch die Sliding Windows zu einer automatischen Reduktion des Traffics allein schon durch die Endgeräte.
Wenn also die Majorität deiner Trafic Volumina eher TCP ist, ist es also generell fraglich ob ein Outbound Rate Shaping dann überhaupt erforderlich ist wie die Telekom es vorgibt. Es gibt Etherconnect Kunden die das aus Unwissenheit oder auch technischer Unfähigkeit ihrer Endgeräte gar nicht machen. Gut, sicher nicht optimal, klappt aber auch. Bei eher UDP lastigem Traffic sieht es natürlich anders aus.
Du musst schon so vorgehen, da Rate Limiting ohne ACL ja immer nur inbound funktioniert. Um outbound zu limiten musst du Rate Shaping per ACL machen. Das sollten die 74er und 72er aber auch wuppen können es geht ja lediglich im Dropping.
Zu mindestens was TCP basierten Traffic anbetrifft kommt es ja so oder so sofort durch die Sliding Windows zu einer automatischen Reduktion des Traffics allein schon durch die Endgeräte.
Wenn also die Majorität deiner Trafic Volumina eher TCP ist, ist es also generell fraglich ob ein Outbound Rate Shaping dann überhaupt erforderlich ist wie die Telekom es vorgibt. Es gibt Etherconnect Kunden die das aus Unwissenheit oder auch technischer Unfähigkeit ihrer Endgeräte gar nicht machen. Gut, sicher nicht optimal, klappt aber auch. Bei eher UDP lastigem Traffic sieht es natürlich anders aus.
Die Telekom hat es lustigerweise auch in ihren Produktinformationen vermerkt, das Traffic Shaping zum Einsatz gebracht werden MUSS.
https://geschaeftskunden.telekom.de/magenta-business-networks/netzwerke- ...
Siehe Seite 11
Scheinbar können deren Geräte nicht soviel zwischenspeichern. Was auch immer das in der Praxis bedeutet. Dann werde ich es mal wie oben eingangs erwähnt konfigurieren, mal sehen was passiert.
Was hat es damit aufsich?...
https://docs.commscope.com/bundle/fastiron-09010-securityguide/page/GUID ...
Was ist in diesem Kontext bei Egress mit CPU-generated Traffic gemeint, sowas wie Routing Protokolle, wie BGP? Also wenn diese Option nicht gesetzt wird, wäre diese vom Shaping nicht betroffen?
https://geschaeftskunden.telekom.de/magenta-business-networks/netzwerke- ...
Siehe Seite 11
Scheinbar können deren Geräte nicht soviel zwischenspeichern. Was auch immer das in der Praxis bedeutet. Dann werde ich es mal wie oben eingangs erwähnt konfigurieren, mal sehen was passiert.
Was hat es damit aufsich?...
https://docs.commscope.com/bundle/fastiron-09010-securityguide/page/GUID ...
Was ist in diesem Kontext bei Egress mit CPU-generated Traffic gemeint, sowas wie Routing Protokolle, wie BGP? Also wenn diese Option nicht gesetzt wird, wäre diese vom Shaping nicht betroffen?
Was auch immer das in der Praxis bedeutet.
Für TCP Verbindungen gar nichts, denn die passen sich immer dynamisch an wie oben schon bemerkt. Die Majorität der Kunden die aus Unwissenheit oder Unvermögen kein Shaping machen, können ja auch arbeiten und bemerken dies in der Regel gar nicht.Was hat es damit auf sich?...
Das ist zuerst einmal ein positives Zeichen das per ACL klassifizierter Outbound Produktivtraffic sehr wahrscheinlich nicht CPU switched ist. Wie du schon sehr richtig angemerkt hast ist damit ausschliesslich eigener Management Traffic des Switches gemeint z.B. auch die von dir genannten dynamischen Routing Protokolle. Da diese Volumina aber sehr sehr klein sind im Vergleich zum Produktivtraffic wird das Aktivieren sicher nicht erforderlich sein. Da einge Dinge davon auch sehr zeitkritisch sind sollte man das m.E. nur dann machen wenn wirklich Nachteile auftreten sollten im laufenden Betrieb.
Ok. Morgen kann ich testen. Ich werde berichten. Durchsatz werde ich mit Iperf3 prüfen, da sollte dann ja relativ schnell klar werden ob es funktioniert oder nicht.
Ich werde berichten.
👍 Das wäre mal interessant!