edi.pfisterer
Goto Top

Verständisproblem von ACLs auf einem 3COM 4500G

Ich dachte ja, ich kenne mich damit aus, aber offensichtlich ist dem nicht so..

Hallo Jungs und Mädls...

Ich versuche, auf einem 3COM 4500G (Layer3) eine ACL zu konfigurieren, allerdings ohne jeden Erfolg...

Meine Ausgangssituation:

25 VLANs (172.16.0.0/24 bis 172.16.25.0/24)
Server: 172.16.0.0/24
Admins: 172.16.19.0/24

Der Wunsch:
Traffic soll nur möglich sein ins Server- und AdminVlan, kein Traffic zwischen den anderen VLANs (also eigentlich trivial).

Ich habe nun - da das oben verlinkte Manual wenig hergibt - dieses hier zur Hand genommen:
A simple traffic filtering example for the 3Com 4500G

Zusammengefasst meint Dave, dass der 3Com folgendes verarbeiten könnte:
1.) Ich definiere den gewünschen Traffic in der ACL mit DENY
2.) Ich definiere den unerwünschten Traffic in der ACL mit PERMIT
3.) Da die ACL die Rules von oben nach unten durcharbeitet, bleibt am Ende nur der unerwünschte Traffic übrig, der wird nun auch durch die ACL "geschoben"
4.) ich definiere als BEHAVIOR DENY, das heisst, jener Traffic, der zuvor mit PERMIT durch die ACL durchgelassen wurde, wird nun per DENY verworfen.
Jener Traffic, der zuvor in der ACL mit DENY verworfen wurde, bleibt unberührt und kann passieren...

Klingt ja gar nicht mal soooo unlogisch face-wink

Bei mir schaut das auszugsweise so aus:

[4500G]acl number 3100
[4500G-acl-adv-3100]rule deny ip source 172.16.0.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.1.0 0.0.0.255 destination 172.16.1.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.2.0 0.0.0.255 destination 172.16.2.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.3.0 0.0.0.255 destination 172.16.3.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.4.0 0.0.0.255 destination 172.16.4.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.5.0 0.0.0.255 destination 172.16.5.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.6.0 0.0.0.255 destination 172.16.6.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.7.0 0.0.0.255 destination 172.16.7.0 0.0.0.255

usw

4500G-acl-adv-3100]rule deny ip source 172.16.0.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
Error: The rule already exists.
[4500G-acl-adv-3100]rule deny ip source 172.16.1.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.2.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.3.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.4.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.5.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.6.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.7.0 0.0.0.255 destination 172.16.0.0 0.0.0.255

usw

[4500G-acl-adv-3100]rule deny ip source 172.16.0.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
Error: The rule already exists.
[4500G-acl-adv-3100]rule deny ip source 172.16.0.0 0.0.0.255 destination 172.16.1.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.0.0 0.0.0.255 destination 172.16.2.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.0.0 0.0.0.255 destination 172.16.3.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.0.0 0.0.0.255 destination 172.16.4.0 0.0.0.255
[4500G-acl-adv-3100]rule deny ip source 172.16.0.0 0.0.0.255 destination 172.16.5.0 0.0.0.255

usw
Das gleiche dann nochmal für 172.16.19.0 als source und destination..
Dann die Rule mit PERMIT:

[4500G-acl-adv-3100]rule permit ip source 172.16.0.0 0.0.255.255 destination 172.16.0.0 0.0.255.255
[4500G-acl-adv-3100]quit

[4500G]traffic behavior deny-traffic
[4500G-behavior-deny-traffic]filter deny
[4500G-behavior-deny-traffic]quit

[4500G]traffic classifier nur-ins-0erVLAN
[4500G-classifier-nur-ins-0erVLAN]if-match acl 3100
[4500G-classifier-nur-ins-0erVLAN]quit

[4500G]qos policy nur-ins-0erVLAN
[4500G-qospolicy-nur-ins-0erVLAN]classifier nur-ins-0erVLAN behavior deny-traffic
[4500G-qospolicy-nur-ins-0erVLAN]quit

[4500G]interface GigabitEthernet 1/0/19
[4500G-GigabitEthernet1/0/19]qos apply policy nur-ins-0erVLAN inbound
[4500G-GigabitEthernet1/0/19]undo qos apply policy inbound
[4500G-GigabitEthernet1/0/19]

Leider funktioniert das ganze nicht wie gewünscht...

Ich wäre Euch sehr sehr dankbar, wenn ihr mir auf die Sprünge helfen könntet, wie ich dieses Problem lösen könnte...

Danke im Voraus
glg
Edi

Content-ID: 152331

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

Ausgedruckt am: 05.11.2024 um 02:11 Uhr

brammer
brammer 04.10.2010 um 16:49:10 Uhr
Goto Top
Hallo,


1.) Ich definiere den gewünschen Traffic in der ACL mit DENY
2.) Ich definiere den unerwünschten Traffic in der ACL mit PERMIT

Da permit erlauben heißt und deny verbieten solltest du dir diese Formulierung nochmal genau ansehen...

Ich kenne mich bei 3com nicht mit den ACL aus, bei Cisco besser.

Wenn ich bei Cisco allerdings Traffic zwischen VLans auf einem L3 regelmentieren will nehme ich dafür Routing und keine ACL.

brammer
aqui
aqui 04.10.2010 um 16:49:37 Uhr
Goto Top
Du machst einen fatalen Denkfehler ! ACL auf Consumer Switches meist immer nur INCOMING auf dem Layer 3 VLAN IP Interface !
Logisch richtig müsste dein Liste also dann so lauten:
1.) Ich definiere den ungewünschen Traffic in der ACL mit DENY
2.) Ich definiere den erwünschten Traffic in der ACL mit PERMIT

3.) Da die ACL die Rules von oben nach unten durcharbeitet, bleibt am Ende nur der unerwünschte Traffic übrig, der wird nun auch durch die ACL "geschoben"
Falsch: Es gilt immer der first Hit, Danach wird die ACL nicht mehr weiter abgearbeitet ! Deshalb muss der DENY Traffic immer zuerst kommen ! 4.) ich definiere als BEHAVIOR DENY, das heisst, jener Traffic, der zuvor mit PERMIT durch die ACL durchgelassen wurde, wird nun per DENY verworfen. Jener Traffic, der zuvor in der ACL mit DENY verworfen wurde, bleibt unberührt und kann passieren... //
Du gehst von falscher Logik aus ! Siehe Punkt 1 und 2 und falsches Verhalten siehe 3
Mal mit Cisco Syntax gesprochen (3Com dürfte das gleich sein) als beispiel eine Liste die den Verkehr aus VLAN 10 ins VLAN 3 und 7 verbietet und den rest erlaubt:
access-list vlan3u7 deny ip 172.16.10.0 0.0.0.255 172.16.3.0 0.0.0.255
access-list vlan3u7 deny ip 172.16.10.0 0.0.0.255 172.16.7.0 0.0.0.255
access-list vlan3u7 permit ip 172.16.10.0 0.0.0.255 any

Eine Liste die aus VLAN 20 nur Traffic zu VLAN 1 erlaubt:
access-list vlan1only permit ip 172.16.20.0 0.0.0.255 172.16.1.0 0.0.0.255
access-list vlan1only deny ip 172.16.20.0 0.0.0.255 any

Eigentlich eine sehr simple Logik....wie immer bei IP !
Edi.Pfisterer
Edi.Pfisterer 04.10.2010 um 16:59:20 Uhr
Goto Top
Vielen Dank für die raschen Kommentare...

Da haben mich ja tatsächlich meine Englischkenntnisse widerlichst im Stich gelassen (oder Dave hat da einfach etwas falsches geschrieben...).

Jetzt gibt das ganze ja auch gleich viel mehr Sinn und ist vor allem auch Logisch face-wink

Ich werd das jetzt gleich mal umsetzen...
Vielen vielen Dank vorerst!

lg
Edi.Pfisterer
Edi.Pfisterer 04.10.2010 um 17:16:22 Uhr
Goto Top
Hallo acqui!

Danke für Deine Erklärung!!!

Leider funktioniert diese Herangehensweise bei mir nicht...
(oder ich bin einfach zu blöd, das könnte natürlich auch sein...)

Ich habe nun folgendes versucht:

[4500G-acl-adv-3100]display acl 3100
Advanced ACL  3100, named -none-, 25 rules,
ACL's step is 5  
 rule 0 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.2.0 0.0.0.255
 rule 5 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.3.0 0.0.0.255
 rule 10 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.4.0 0.0.0.255
 rule 15 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.5.0 0.0.0.255
 rule 20 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.6.0 0.0.0.255
 rule 25 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.7.0 0.0.0.255
 rule 30 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.8.0 0.0.0.255
 rule 35 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.9.0 0.0.0.255
 rule 40 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.10.0 0.0.0.255
 rule 45 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.11.0 0.0.0.255
 rule 50 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.12.0 0.0.0.255
 rule 55 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.13.0 0.0.0.255
 rule 60 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.14.0 0.0.0.255
 rule 65 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.15.0 0.0.0.255
 rule 70 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.16.0 0.0.0.255
 rule 75 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.17.0 0.0.0.255
 rule 80 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.18.0 0.0.0.255
 rule 85 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.19.0 0.0.0.255
 rule 90 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.20.0 0.0.0.255
 rule 95 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.21.0 0.0.0.255
 rule 100 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.22.0 0.0.0.255
 rule 105 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.23.0 0.0.0.255
 rule 110 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.24.0 0.0.0.255
 rule 115 deny ip source 172.16.1.0 0.0.0.255 destination 172.16.25.0 0.0.0.255
 rule 120 permit ip source 172.16.1.0 0.0.0.255

Das ganze habe ich dann an das Interface 1/0/1 gehängt (nicht gleich ans VLAN)....
Ab diesem Zeitpunkt sind die an diesem Interface hängenden PCs aus dem 172.16.1.0/24 total ausgeknipst...

Das ganze ändert sich, wenn ich den traffic behavior auf permit setze, dann wird aber gleich gar nichts mehr denied...

irgendwie blick ich einfach nicht durch...

[edit:]
Verstehe ich das richtig, dass (durch inbound auf consumer-teilen - wie Du erwähnt hast) hier nur jener Traffic definiert wird, der über Interface 1/0/1 von außen ankommt?

allerdings hat eine zusätzliche Regel
 rule 125 permit ip destination 172.16.1.0 0.0.0.255
ebenfalls keine positive Auswirkung...

Außerdem:
Wird Traffic, der hier nicht explizit erwähnt wird, verworfen?
Und: Falls dem so ist, wie definiere ich, das der Traffic ins Internet zugelassen wird...
[/edit]


[edit2:]
sobald ich (siehe erstes Posting) folgendes vornehme, kann ich in der ACL konfigurieren, was ich will, der Filter lässt jeden Traffic durch...
traffic behavior deny-traffic
filter permit
quit
???????
[/edit2]


Bin für jeden Tipp sehr dankbar!!!

lg
aqui
aqui 04.10.2010 um 20:06:30 Uhr
Goto Top
Am Port ist der Switch ein Layer 2 Switch ! Du machst hier vermutlich wieder einen Denkfehler was den korrekten Sinn von Filtern ausmacht bzw. WO diese zu plazierensind.
Alle VLAN Ports gehören zu einem Layer 2 VLAN und werden dort nur anhand ihrer Mac Adressen "gesehen". Nur wenige Switches können direkt am Endgeräte Port auf Layer 3 filtern. Und wenn sie es können muss man ihnen das explizit in der Konfig sagen.
Ob dein 3Com Geraffel Layer 3 Filter am Port kann, musst du im Handbuch nachsehen.
In der Regel ist es ja auch völliger Unsinn am Port zu filtern, denn dort sind Endgeräte dran. Sinnvoll ist es den Netzwerkzugriff dort zu filtern wo auch das VLAN gerouetet wird also am virtuellen Layer 3 Interface des Switches. Dort werden die IP Pakete ja in andere IP Netze geroutet und nicht am VLAN Port wo alles auf Layer 2 arbeitet.
Syntaktisch ist die ACL aber so richtig. Bau die ACL also am L3 Port ein und gut ist.
Edi.Pfisterer
Edi.Pfisterer 04.10.2010 um 23:29:30 Uhr
Goto Top
Hallo!
Dass die ACLs am Layer3 besser aufgehoben wären, habe ich mir auch schon gedacht... face-wink

Ob dein 3Com Geraffel Layer 3 Filter am Port kann, musst du im Handbuch nachsehen.
Das hab ich schon, alle Befehle habe ich mir in laaangen Stunden aus diesem Handbuch zusammengeklaubt...

blöderweise gibt dieses Manual aber nichts her, wie ich die ACLs dem Layer3 zuweise (oder ich finde es nicht, könnte auch sein...)

Ich habe hier noch etwas gefunden (in Example 3 sogar noch etwas mit VLANs, aber mit dem vielen deny und permit-behavior geht mir schon wieder der Durchblick verloren), (abgesehen davon, dass dieser Link nicht zum 4500G passt... )
http://knowledge.3com.com/service/main.jsp;jsessionid=304F63E42E4A191AE ...

Mit den wenigen verbliebenen analytischen Fähigkeiten schaut das soeben erwähnte aber nun doch wieder so aus, als würde Virtual Dave das durchschaut haben, und deny in der ACL wird durch behavior deny nun wieder letztendlich durch den Routing Table geschickt, wohingegen ACL permit mit Behavior Deny ins Nirvana verschwindet...

Könntest Du so nett sein, und Dir - falls Du etwas Zeit abzweigen kannst - mal den entsprechenden Teil im Manual und bei Virtual Dave (links oben) ansehen?
Ich versteh nur Bahnhof...

Vielen Dank im Voraus

lg
Edi

PS: 3-Com-Geraffel trifft die Sache wirklich gut face-wink
aqui
aqui 06.10.2010 um 11:26:25 Uhr
Goto Top
Schrott....wäre wohl eher angebracht. Naja ist ja jetzt HP Schrott face-wink
Dein Dokument von oben ist komplett falsch, denn das beschreibt ein PBR Szenario ! Vergiss das also ! Das richtige 3Com Dokument findest du hier:
http://knowledge.3com.com/service/main.jsp?t=documentTab&ft=searchT ...
In Chapter 7 auf Seite 129 wird dein Vorhaben ganz genau mit Schritt für Schritt Beispielen erklärt.
Damit solltest du es dann hinbekommen....auch mit 3Com.
Edi.Pfisterer
Edi.Pfisterer 06.10.2010 um 14:30:26 Uhr
Goto Top
Vielen Dank für Deine bisherige Hilfe!!!
Leider hängt das von Dir vorgeschlagene Manual die ACL ebenfalls an den Port und nicht ans VLAN
(oder hab ich da etwas übersehen?).

Außerdem bin ich im Zuge des Konfigurierens des DHCP-Relays draufgekommen, dass 3Com vorgibt, dieses Manual sei für die gesamte 4500er Family, tatsächlich allerdings ist der Befehlssatz stark differierend mit jenem vom 4500G
(DHCP-Relay funktioniert definitiv NICHT, wenn man nach diesem Manual vorgeht ;-(

Man muss sich folgedessen ausschließlich an dieses Manual halten:
http://support.3com.com/infodeli/tools/switches/4500/3Com_Switch-4500G_ ...

hm....

Ich bin Dir weiterhin für jede Minute, die Du meinem Problem widmest, sehr dankbar!

glg
Edi
Edi.Pfisterer
Edi.Pfisterer 06.10.2010 um 14:34:14 Uhr
Goto Top
Ha!
Ich hab nun im letzt erwähnten Manual auf Seite 423 ff / Chapter 45 den entscheidenden Hinweis gelesen...

<3Com> system-view
[3Com] traffic classifier cl1 operator or
[3Com-classifier-cl1] if-match acl 2000
[3Com-classifier-cl1] quit
[3Com] traffic behavior be1
[3Com-behavior-be1] car cir 64
[3Com-behavior-be1] quit
[3Com] qos policy test
[3Com-qospolicy-test] classifier cl1 behavior be1
[3Com-qospolicy-test] quit
[3Com] qos vlan-policy test vlan 200 300 400 500 600 700 800 900 inbound

[edit: dieser Beitrag hat sich mit dem letzten erledigt!]
Edi.Pfisterer
Edi.Pfisterer 06.10.2010 um 23:33:08 Uhr
Goto Top
JAAAAAAAAAAAAAAAAAAAAAAAAAA!!!!!!
HURRA HURRA HURRA HURRA HURRA HURRA HURRA HURRA

Ich habe es geschafft!!!!

Des Rätsels Lösung (für alle, die den selben Fehler begehen sollten, den ich beging, als ich mir diese 3COM-Kiste 4500G kaufte):

Es muss ZWINGEND der time-range wie folgt VOR dem Anlegen von ACLs definiert werden!!!
AAARRRGGGHHHHH - Ein Ausruf des Schreckens und der Dankbarkeit darüber, dass ich durch stundenlanges herumprobieren zufällig darüber gestolpert bin...

Fehlender time-range liefert KEINE Fehlermeldung oder sonstige Anzeichen, dass er nicht definiert ist!!!
(Abgesehen davon, dass bei behavior deny ALLES geblockt wird und bei behavior permit ALLES ungeblockt bleibt...)

Falls VOR der erstmaligen Konfiguration des Time-Range bereits ACLs angelegt wurden, MÜSSEN alle gelöscht werden!!!
(Es ist nicht etwa so, dass diese zuvor angelegten einfach nicht laufen würden, sondern vielmehr läuft keine einzige, bevor nicht ALLE gelöscht wurden UND der Time-Range definiert wurde ...
________________________________________________________________________

LÖSUNG, falls jemand bei einem 3Com 4500G (Achtung: gilt explizit nur für G) das Problem hat, dass keine ACLs funktionieren:
(Das Manual lässt den User diesbezüglich ja komplett im Dunkeln - leider!)

1.) Anzeige vorhandener ACLs
display acl all
display traffic behavior user-defined
display qos policy user-defined
display traffic classifier user-defined

Es darf kein Ergebnis angezeigt werden...
Wenn dem so ist: weiter zu 3.)

2.) Falls schon ACLs vorhanden seni sollten, sind diese wie folgt in genau dieser Reihenfolge zu löschen:

undo qos policy [name der Policy]
undo traffic classifier [name des Classifiers]
undo traffic behavior [name des Behaviors]
undo acl number [ACL-Nummer]

Anschließend erneut 1.) durchführen, ob auch wirklich nichts mehr vorhanden ist...

3.) Time Range anlegen
time-range fuer-immer from 15:00 2000/1/28 to 15:00 2090/1/28
ob diese Einstellung greift kann wie folgt getestet werden:

[4500G]display time-range all
Current time is 14:52:42 5/6/2000 Saturday

Time-range : fuerimmer ( Active )
 from 15:00 1/28/2000 to 15:00 1/28/2090

Augenmerk ist auf ( Active ) zu legen!!!
(Anmerkung: Mein System glaubt, es wäre "Back in Time" im Jahre 2000 unterwegs und ist mit dem entsprechenden Befehl clock datetime time date auch nicht dazuzubewegen, mir in die Zukunft zu folgen - weil meine Softwareversion diesen Befehl einfach nicht kennt face-wink

4.) eine ACL definieren und auf einem VLAN anwenden:

Das Szenario:
ServerVLAN ID 10 -- 172.16.0.0/24
Buchhaltungs-VLAN ID 119 -- 172.16.19.0/24
Office-VLAN ID 117 -- 172.16.17.0/24

Das Ziel:
Buchhaltung und Office sollen ins ServerVLAN und ins Internet dürfen, sollen sich aber NICHT gegenseitig sehen

4a) eine ACL anlegen:
Diese muss eine sog. Advanced IPv4 ACL sein und somit eine ID zwischen 3000 und 3999 haben!!!

acl number 3117
rule 0 deny ip source any destination 172.16.19.0 0.0.0.255
quit
acl number 3119
rule 0 deny ip source any destination 172.16.17.0 0.0.0.255
quit
Anmerkung:
3117 hindert jeglichen Traffic daran, nach 172.16.19.0/24 zu gelangen
0.0.0.255 ist NICHT die Subnetzmaske, sondern die Wildcard, dh, umgekehrt zu lesen
3119 macht das selbe für 172.16.17.0/24

display acl 3117
dient zum Anzeigen der jeweiligen ACL
die Anzeige von (Count x) wie im Manual beschrieben läuft bei mir definitiv NICHT

4b) ein Verhalten festlegen, was mit dem gefilterten Traffic passiern soll

traffic behavior deny
filter deny
quit
Anmerkung: jeder Traffic, der durch die ACL identifiziert wird und für deny vorgesehen ist, wird gefiltert

4c) einen Classifier festlegen und diesen mit der ACL zusammenhängen
traffic classifier deny19
if-match acl 3117
quit
traffic classifier deny17
if-match acl 3119
quit
Anmerkung:
deny19 verhindert über ACL 3117 Traffic mit 172.16.19.0/24
deny17 verhindert über ACL 3119 Traffic mit 172.16.17.0/24

4d) eine Policy definieren und diese mit dem classifier und dem behavior zusammenhängen
qos policy pol19
classifier deny17 behavior deny
quit
qos policy pol17
classifier deny19 behavior deny
quit

4e) die Policy dem entsprechenden VLAN zuweisen
qos vlan-policy pol17 VLAN 117 inbound
qos vlan-policy pol19 VLAN 119 inbound

Anmerkung:
pol17 wird mit VLAN 117 verknüpft
pol19 wird mit VLAN 119 verknüpft
mit undo qos vlan-policy VLAN 117 inbound kann die entsprechende Policy wieder vom VLAN entfernt werden..

Falls das wer brauchen sollte:
Diese Rumpl kann die ACL auch an den Port hängen: (hier die pol17 an Port # 1)
interface GigabitEthernet 1/0/1
qos apply policy pol17 inbound
quit

Ergebnis dieses Beispiels
ping 172.16.0.1 --- 172.16.19.1 OK (und vice versa)
ping 172.16.0.1 --- 172.16.17.1 OK (und vice versa)
ping 172.16.19.1 --- 172.16.17.1 Zeitüberschreitung der Anforderung (und vice versa)

generelle abschließende Anmerkungen zu ACLs bei 3 Com 4500G:
- Anders als landläufig üblich wird jeder Traffic, der nicht in der ACL definiert ist, wie permit behandelt
- in der jeweiligen Rule ist source das jeweilige VLAN, für das die ACL erstellt wird, daher kann any verwendet werden
(das verursacht in Verbindung mit inbound beim Zuweisen der ACL an die jeweilige VLAN zwar einige Verwicklungen im Hirn, aber da muss man durch face-wink )

[off Topic 1]:
das DHCP-Relaying läuft auf der Kiste AUSSCHLIESSLICH bei Einhaltunger folgender Befehlsreihenfolge!!!
<Sysname> system-view
[Sysname] dhcp enable
[Sysname] interface vlan-interface 10
[Sysname-Vlan-interface1] dhcp select relay
[Sysname-Vlan-interface1] quit
[Sysname] dhcp relay server-group 1 ip 10.1.1.1
[Sysname] interface vlan-interface 1
[Sysname-Vlan-interface1] dhcp relay server-select 1
Es kursieren Manuals im Netz (sowohl für die 4500er Family als auch für den 4500G, in denen fehlt der Befehl dhcp select relay...
Auch hier - wie bei den ACLs: Keine Fehlermeldung deutet auf die fehlende Eingabe hin, DHCP-Relaying funktioniert nur einfach nicht!
[/off Topic 1]


[off Topic 2]:
Das von mir im Februar 2010 fabriksneu erworbene Modell 4500G 48-Port (3CR17762-91) wurde mit einer veralteten Softwareversion ausgeliefert, die lediglich 8 (in Worten ACHT) VLAN-Interfaces zulässt...
Da kommt man natürlich auch erst drauf, nachdem man alle 8 konfiguriert hat... face-wink

Mein Ratschlag daher:
SOFORT nach dem Auspacken eine der letzten SW-Versionen aufspielen...
man kann sich da eine Menge Zeit sparen...
[/off Topic 2]

In diesem Sinne
ENDE GUT, ALLES GUT

Danke an aqui für Deine Hilfe!!!

glg
Edi "Happy" Pfisterer
Edi.Pfisterer
Edi.Pfisterer 07.10.2010, aktualisiert am 18.10.2012 um 18:43:43 Uhr
Goto Top
Zusatz:
1.) Ich würde gerne Titel ändern von "Verständnisfrage" in "Wer versteht dieses 3-Com Geraffel"
2.) Ich bin ziemlich happy, dass ich mich nicht getäuscht habe, als ich meinte, mich mit ACLs auszukennen face-wink
3.) Falls es außer mir auch nur einen Einzigen geben, der auch diesen Fehler machen sollte (nicht den, dass er sein Wissen unterschätzt, sondern dass er sich leichtsinnig zu einem Fehlkauf hinreisen lässt...), habe ich schnell 3 Scripts gebastelt, die Arbeit ersparen:

hier

lg
aqui
aqui 07.10.2010 um 19:59:18 Uhr
Goto Top
Zu Punkt 1: Das kannst du machen wenn du oben auf "Bearbeiten" klickst ! face-wink
Zu Punkt 2. und 3.: Da fehlt von dir noch ein 2ter Ratschlag: "Finger weg vom 3Com (jetzt HP) Geraffel !"
Wenn man sich nur einmal oben diese zugegeben ziemlich kranke Syntax der ACL Einrichtung ansieht und vergleicht das mal mit Cisco, Brocade, Entensys, Extreme und sogar HP Procurve fällt einem nix mehr ein außer solche Produkte nicht mehr zu kaufen...aber zum Glück gibts ja immer noch genug Leidenswillige. Komplizierter und verworrener kann man es einem Anwender ja wahrlich nicht mehr machen.
brammer
brammer 08.10.2010 um 09:33:39 Uhr
Goto Top
Hallo,

nur so nebenbei:
3com hat mal richtig gute Netzwerkkarten gebaut.
Aber die richtigen Trieber dazu zu finden war schon immer ein großes Rätselraten.
Vermutlich wird HP das 3com Geraffel mit den ProCurve Geräten durcheinander mischen, und die schlechtesten Features als großen Wurf in 2 Jahren auf den Markt bringen.

Wer einen Cisco Switch konfigurieren kann, kann das auch mit einem Procurve und einem Brocade oder Extreme (Entensys habe ich keine Erfahrungen) aber die 3com Syntax ist schon
"sehr speziell".
Selbst kleinere Switch Hersteller wie NTRON lassen sich mmit der Cisco Logik verstehen.
Allerdings überlege ich noch was schlimmer ist, 3com oder Siemens Scalance Switche....

brammer
Edi.Pfisterer
Edi.Pfisterer 08.10.2010 um 11:45:44 Uhr
Goto Top
3com hat mal richtig gute Netzwerkkarten gebaut.
jaja, die gute alte 3C905 oder 3C900Combo...

diese Nostalgie hat mich ja auch dazu veranlasst, dem befreundeten Netzwerkguru zu glauben und dieses Zeug zu kaufen...

ARGHH, wäre man nur etwas jünger, dann hätte man sich an die 3C905 gar nicht mehr erinnern können, und hätte etwas anderes gekauft
(Cisco war mir einfach entschieden zu teuer...), und preislich ist der 4500G mit 48 Gigabitports u L3 ja mehr als OK...
(wenn man die Stunden nicht mitrechnet, die fürs konfigurieren draufgehen face-wink