3
Aruba 2930F - ACL Blackout
Hallo zusammen,
nun muss ich doch selber auch mal eure Hilfe bei einem Thema in Anspruch nehmen, bei welchem mein Verstand komplett auszusetzen scheint: Ich möchte ACLs auf einem Aruba 2930F einrichten, scheitere aber an der Logik/Unlogik/meinem eigenen Verstand und bekomme es einfach nicht auf die Reihe.
Folgender relevanter Config-Auszug:
Ziel ist es, dass
1) VLAN 20 und VLAN 21 in beide Richtungen miteinander reden dürfen
2) VLAN 20 und VLAN 22 in beide Richtungen miteinander reden dürfen
3) VLAN 21 mit VLAN 22 reden darf, aber nicht umgekehrt VLAN 22 mit VLAN 21
An der Stelle scheitere ich mit allen Standard- und Extended-RACLs, die ich in allen erdenklichen Kombinationen mit vlan-in und vlan-out an die VLANs anhefte.
Kurzum brauche ich jemanden, der mir den Code kurz anpasst, wenn gewünscht auch gegen Bezahlung.
Vielen Dank im Voraus an Alle!
PS: Nein aqui, du darfst als anerkannter HPE/Aruba-Verweigerer nicht mitspielen ;)
nun muss ich doch selber auch mal eure Hilfe bei einem Thema in Anspruch nehmen, bei welchem mein Verstand komplett auszusetzen scheint: Ich möchte ACLs auf einem Aruba 2930F einrichten, scheitere aber an der Logik/Unlogik/meinem eigenen Verstand und bekomme es einfach nicht auf die Reihe.
Folgender relevanter Config-Auszug:
vlan 20
name "A"
untagged 44-47
tagged 48-52
ip address 10.1.0.10 255.255.255.0
ip forward-protocol udp 10.1.1.255 7
ip forward-protocol udp 10.1.1.255 9
ip forward-protocol udp 10.2.255.255 7
ip forward-protocol udp 10.2.255.255 9
exit
vlan 21
name "B"
untagged 5-12
tagged 48-52
ip address 10.1.1.1 255.255.255.0
ip helper-address 10.1.0.1
exit
vlan 22
name "C"
untagged 13-43
tagged 48-52
ip address 10.2.0.1 255.255.0.0
ip helper-address 10.1.0.1
exitZiel ist es, dass
1) VLAN 20 und VLAN 21 in beide Richtungen miteinander reden dürfen
2) VLAN 20 und VLAN 22 in beide Richtungen miteinander reden dürfen
3) VLAN 21 mit VLAN 22 reden darf, aber nicht umgekehrt VLAN 22 mit VLAN 21
An der Stelle scheitere ich mit allen Standard- und Extended-RACLs, die ich in allen erdenklichen Kombinationen mit vlan-in und vlan-out an die VLANs anhefte.
Kurzum brauche ich jemanden, der mir den Code kurz anpasst, wenn gewünscht auch gegen Bezahlung.
Vielen Dank im Voraus an Alle!
PS: Nein aqui, du darfst als anerkannter HPE/Aruba-Verweigerer nicht mitspielen ;)
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: 376744
Url: https://administrator.de/forum/aruba-2930f-acl-blackout-376744.html
Ausgedruckt am: 21.12.2024 um 16:12 Uhr
3 Kommentare
Neuester Kommentar
Guten Abend,
probier es mal so:
Was meistens für Verwirrung sorgt ist, dass mit in eigentlich der Datenverkehr vom Host zum Switch gemeint ist.
Gruß,
Dani
probier es mal so:
conf t
ip access-list extended "vlan20out"
permit ip 10.1.0.0 0.0.0.255 10.1.1.0 0.0.0.255
permit ip 10.1.0.0 0.0.0.255 10.2.0.0 0.0.255.255
vlan 20
ip access-group vlan20out in
exit
ip access-list extended "vlan21out"
permit ip 10.1.1.0 0.0.0.255 10.1.0.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 10.2.0.0 0.0.255.255
vlan 21
ip access-group vlan21out in
exit
ip access-list extended "vlan22out"
permit ip 10.2.0.0 0.0.255.255 10.1.0.0 0.0.0.255
vlan 22
ip access-group vlan22out in
exit PS: Nein aqui, du darfst als anerkannter HPE/Aruba-Verweigerer nicht mitspielen ;)
Ich fürchte, dass @aqui einer der Wenigen hier ist, der ACLs aus der Hüfte heraus entwerfen kann. Gruß,
Dani
1
der ACLs aus der Hüfte heraus entwerfen kann.
Danke für die Blumen 
Und in der Tat sind ja nun ACL kinderleicht von der Logik !
bei welchem mein Verstand komplett auszusetzen scheint:
Warum ?Das muss nicht sein wenn man nur mal etwas logisch nachdenkt !!!
Zuallererst musst du dir 2 Grundlagen zu ACL aneignen die immer gelten:
- ACL gelten immer nur INBOUND also für Traffic der VOM Netzwerkdraht IN den Switch bzw. L3 Interface fliesst
- Outbound ACL sollte man IMMER vermeiden. Auch wenn sie supportet sein sollten werden NICHT in Hardware sondern in Software realisiert und belasten den Switch massiv in der Performance. Mal ganz davon abgesehen das es ja Blödsinn ist ungewollten Traffic erst in den Switch reinzulassen ihn dann zu verwursten um ihn dann gleich wieder zu löschen. Unsinn..
- First match wins !! = Bedeutet das soewie das erste Statement einer ACL einen positiven "Hit" hat der Rest NICHT mehr abgearbeitet wird.
OK zu Lösung dann keinen weiteren Kommentar. Darf ich ja nicht, obwohl es bei HP/Aruba Schrott auch die gleiche Logik ist wie bei allen anderen auch. Kollege Dani hat ja schon alles dazu gesagt.
Na ja jeder bekommt eben das Netzwerk was er verdient. Besonders die die freiwillig HP Schrott kaufen
1
Volltreffer, Vielen Dank! Hat geklappt Hab die ACLs noch etwas modifiziert, damit die Netze auch mit sich selber sprechen dürfen, aber hat alles super geklappt, Danke
Wir müssen unbedingt mal zusammen ein paar Bier trinken, damit du mir mal in Ruhe erklären kannst, warum du so einen Groll gegen HPE/Aruba hegst.
Im Education Segment z.B. bekommt man Cisco Geräte kaum durch, weil man für annährend gleiche Performance (Aruba 2930F vs. Cisco 2960XR) einen Switch bekommt, der nur ein Drittel, bzw. ein Viertel des Ciscos kostet, der aber auch vermeintlich die gleiche Funktionalität bildet.
Selbst CDP (Reading Mode) und PVRST+ ist mittlerweile implementiert.
Und man braucht bei Aruba keine aktive Subscription, um an Firmware-Updates ran zu kommen.
Aber es wird immer Leute aus verschiedenen Lagern geben, was ja auch gut ist, sonst gäbe es ein Monopol, was machen kann, was es will
Hab die ACLs noch etwas modifiziert, damit die Netze auch mit sich selber sprechen dürfen, aber hat alles super geklappt, Danke Zitat von @aqui:
Das muss nicht sein wenn man nur mal etwas logisch nachdenkt !!!
Zuallererst musst du dir 2 Grundlagen zu ACL aneignen die immer gelten:
Deine 3 Grundlagen sind mir bewusst, das Rückenmark zwischen Hirn und Hand war wohl eher das Problem Das muss nicht sein wenn man nur mal etwas logisch nachdenkt !!!
Zuallererst musst du dir 2 Grundlagen zu ACL aneignen die immer gelten:
Na ja jeder bekommt eben das Netzwerk was er verdient. Besonders die die freiwillig HP Schrott kaufen
Wir müssen unbedingt mal zusammen ein paar Bier trinken, damit du mir mal in Ruhe erklären kannst, warum du so einen Groll gegen HPE/Aruba hegst.
Im Education Segment z.B. bekommt man Cisco Geräte kaum durch, weil man für annährend gleiche Performance (Aruba 2930F vs. Cisco 2960XR) einen Switch bekommt, der nur ein Drittel, bzw. ein Viertel des Ciscos kostet, der aber auch vermeintlich die gleiche Funktionalität bildet.
Selbst CDP (Reading Mode) und PVRST+ ist mittlerweile implementiert.
Und man braucht bei Aruba keine aktive Subscription, um an Firmware-Updates ran zu kommen.
Aber es wird immer Leute aus verschiedenen Lagern geben, was ja auch gut ist, sonst gäbe es ein Monopol, was machen kann, was es will
1
