9
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669809
Url: https://administrator.de/forum/ruckus-icx-traffic-policy-rate-limit-etherconnect-669809.html
Ausgedruckt am: 02.01.2025 um 14:01 Uhr
9 Kommentare
Neuester Kommentar
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!
Prinzipiell hat das mit der Traffic Policy geklappt. Bei eingestellten 100.000 Kbyte/s habe ich mit dem Iperf3 ungefähr ca. 75-78 Mbits/sec gemessen. Wobei man sagen muss das hier das die niedrigste QoS-Profile "Standard" gewählt wurde bei einer gebuchten Bandbreite von 100Mbits beim Anschluss "L" (1G).
Ich muss gestehen das ich zum ersten Mal mit einer EC 2.0 in dieser Konstellation arbeite. Davor mal eine OTN-Verbindung in Betrieb gehabt, die war ziemlich einfach... einfach nur wie gebuchte LWL von A nach B. Fertig.
Die Point-to-Multipoint verhält sich völlig anders und ehrlich gesagt unerwartet. Leider geht aus den Buchungen nicht direkt hervor was eigentlich genau gebucht wurde, teilweise konnte das Vertriebler das selbst nicht sagen. Es gibt da mehrere Versionen von diesem Produkt und daran orientiert sich das Verhalten im Detail.
Als erstes war ich überrumpelt das man ein C-Tag festlegen soll, weil die mit QinQ arbeiten. Ich ging von einem stinknormalem geswitchten VLAN mit einer Layer2-Domain aus. Man bekommt aber mehrere Tags pro Anschluss zugewiesen, was die derzeit für eine Bewandnis haben, weiß ich nicht. Das C-Tag wird dann nur als normales VLAN auf dem Ruckus ICX gesetzt. Da es somit aber nicht als QinQ gilt - man kennt ja das Service-Tag nicht, kann ich die Mapping-Funktionalität nicht verwenden und verbaue mir da prinzipiell schon bestimmte VLAN-Tags. Bisher sind auch nur zwei Standorte realisiert, ich bin gespannt ob die anderen Standorte dann andere C-Tags bekommen.
Ich habe dann später sogar noch in der Traffic Policy nur 90.000 kbytes/s konfiguriert, da in der Produktinfo steht das man einen Burst einrichten soll, allerdings geht das bei Ruckus nur mit Port-Based Rate-Limit und nicht bei ACLs. Das würde dann wenig Sinn machen, mit den ACLs kann ich die Subnetze shapen, da alle über den selben Port reinkommen und unter Umständen andere Bandbreiten haben können. Deshalb habe ich einen Puffer manuell gesetzt.
Ich muss gestehen das ich zum ersten Mal mit einer EC 2.0 in dieser Konstellation arbeite. Davor mal eine OTN-Verbindung in Betrieb gehabt, die war ziemlich einfach... einfach nur wie gebuchte LWL von A nach B. Fertig.
Die Point-to-Multipoint verhält sich völlig anders und ehrlich gesagt unerwartet. Leider geht aus den Buchungen nicht direkt hervor was eigentlich genau gebucht wurde, teilweise konnte das Vertriebler das selbst nicht sagen. Es gibt da mehrere Versionen von diesem Produkt und daran orientiert sich das Verhalten im Detail.
Als erstes war ich überrumpelt das man ein C-Tag festlegen soll, weil die mit QinQ arbeiten. Ich ging von einem stinknormalem geswitchten VLAN mit einer Layer2-Domain aus. Man bekommt aber mehrere Tags pro Anschluss zugewiesen, was die derzeit für eine Bewandnis haben, weiß ich nicht. Das C-Tag wird dann nur als normales VLAN auf dem Ruckus ICX gesetzt. Da es somit aber nicht als QinQ gilt - man kennt ja das Service-Tag nicht, kann ich die Mapping-Funktionalität nicht verwenden und verbaue mir da prinzipiell schon bestimmte VLAN-Tags. Bisher sind auch nur zwei Standorte realisiert, ich bin gespannt ob die anderen Standorte dann andere C-Tags bekommen.
Ich habe dann später sogar noch in der Traffic Policy nur 90.000 kbytes/s konfiguriert, da in der Produktinfo steht das man einen Burst einrichten soll, allerdings geht das bei Ruckus nur mit Port-Based Rate-Limit und nicht bei ACLs. Das würde dann wenig Sinn machen, mit den ACLs kann ich die Subnetze shapen, da alle über den selben Port reinkommen und unter Umständen andere Bandbreiten haben können. Deshalb habe ich einen Puffer manuell gesetzt.
Das kommt immer drauf an wie ein Provider sowas auf seinem Backbone umsetzt. Metro Carrier nutzen oft QinQ da sie primär eine Ethernet Infrastruktur haben. Hier kommt es dann darauf an wie sie das dem Endkunden präsentieren. Entweder haben sie einen eigenen Switch davor dann ohne Tags oder du musst als Endkunde selber Doubletagging verwenden.
Bei WAN Carriern ist oft MPLS mit L2VPN dazwischen. Dort bekommt man dann in der Regel auch einen untagged Port. Ohne eine Schnittstellenbeschreibung zu kennen oder das vom Carrier verwendete Verfahren kann man da aber nur frei raten.
Ansonsten alles richtig gemacht oben! 👍
Bei WAN Carriern ist oft MPLS mit L2VPN dazwischen. Dort bekommt man dann in der Regel auch einen untagged Port. Ohne eine Schnittstellenbeschreibung zu kennen oder das vom Carrier verwendete Verfahren kann man da aber nur frei raten.
Ansonsten alles richtig gemacht oben! 👍
Wir haben jetzt den dritten Standort angeschlossen und es waren wiederum völlig neue Tags. Damit wir ein simples Transfernetz bilden konnten und uns nicht sinnlos mehrere dutzend IP-Adressen merken müssen, haben wir die Funktion "IP Follow" im Ruckus ICX auf dem Core-L3 verwendet. Dazu haben wir ein VE-Interface als Dummy mit der primären Adresse angelegt und bei den anderen sekundären VLANs dessen VE-Interfaces dann jeweils diesem Interface folgen lassen. Man hätte das ansonsten mit mehreren kleineren Punkt-zu-Punkt Netzen lösen müssen mit 30er oder 31er Subnetzen. Das empfinde ich aber in der Masse sehr schnell als unübersichtlich.
https://docs.commscope.com/bundle/fastiron-08095-l3guide/page/GUID-3BC76 ...
Derzeit funktioniert es einwandfrei. Mit der Zeit schauen was es eventuell für negative Auswirkungen haben könnte. Aber leider ist die Doku dazu relativ schmal. Wir haben die Empfehlungen genauso umgesetzt, wir haben ein primäres VE ohne ACLs und dann sekundäre mit ACLs gemacht. Einzig der Punkt mit den unterstützten Protokollen hat mich etwas stutzig gemacht. Geschrieben wurde...
RUCKUS ICX devices support IP Follow with OSPF and VRRP protocols only.
Schon klar das da nur Routing-Protokolle mit dieser Installation klar kommen. IS-IS oder OpenFabric hätten damit Probleme. Allerdings sollte ja hier mindestens ebenfalls BGP aufgeführt sein. Das verwenden wir derzeit auch darüber, aber in diesem Zusammenhang habe ich auch keine anderen Erfahrungswerte und wie gesagt... bisher läuft es ohne Probleme.
https://docs.commscope.com/bundle/fastiron-08095-l3guide/page/GUID-3BC76 ...
Derzeit funktioniert es einwandfrei. Mit der Zeit schauen was es eventuell für negative Auswirkungen haben könnte. Aber leider ist die Doku dazu relativ schmal. Wir haben die Empfehlungen genauso umgesetzt, wir haben ein primäres VE ohne ACLs und dann sekundäre mit ACLs gemacht. Einzig der Punkt mit den unterstützten Protokollen hat mich etwas stutzig gemacht. Geschrieben wurde...
RUCKUS ICX devices support IP Follow with OSPF and VRRP protocols only.
Schon klar das da nur Routing-Protokolle mit dieser Installation klar kommen. IS-IS oder OpenFabric hätten damit Probleme. Allerdings sollte ja hier mindestens ebenfalls BGP aufgeführt sein. Das verwenden wir derzeit auch darüber, aber in diesem Zusammenhang habe ich auch keine anderen Erfahrungswerte und wie gesagt... bisher läuft es ohne Probleme.
Danke fürs Feedback!
Das ist sicher deshalb erwähnt, weil diese Protokolle Multicast nutzen was bei "Follow" (IP Unnumbered) oftmals problematisch ist bzw. gar nicht supportet ist. BGP kennt sowas ja nicht da es auch TCP basiert.
Die andere Alternative es zu lösen wäre nur für die Internet Verbindungen ein gemeinsames VLAN zu nutzen. So liegen alle Niederlassungen mit ihren WAN Ports in einem gemeinsamen separaten "Routing" IP Netz.
Das ist sicher deshalb erwähnt, weil diese Protokolle Multicast nutzen was bei "Follow" (IP Unnumbered) oftmals problematisch ist bzw. gar nicht supportet ist. BGP kennt sowas ja nicht da es auch TCP basiert.
Die andere Alternative es zu lösen wäre nur für die Internet Verbindungen ein gemeinsames VLAN zu nutzen. So liegen alle Niederlassungen mit ihren WAN Ports in einem gemeinsamen separaten "Routing" IP Netz.
