14
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
Bei mir schaut das auszugsweise so aus:
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
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
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
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: 152331
Url: https://administrator.de/forum/verstaendisproblem-von-acls-auf-einem-3com-4500g-152331.html
Ausgedruckt am: 22.12.2024 um 16:12 Uhr
14 Kommentare
Neuester Kommentar
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
1.) Ich definiere den gewünschen Traffic in der ACL mit DENY
2.) Ich definiere den unerwünschten Traffic in der ACL mit PERMIT
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
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 !
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 !
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
Ich werd das jetzt gleich mal umsetzen...
Vielen vielen Dank vorerst!
lg
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
Ich werd das jetzt gleich mal umsetzen...
Vielen vielen Dank vorerst!
lg
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:
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
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...
???????
[/edit2]
Bin für jeden Tipp sehr dankbar!!!
lg
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.255Das 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.255Auß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
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.
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.
Hallo!
Dass die ACLs am Layer3 besser aufgehoben wären, habe ich mir auch schon gedacht...
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
Dass die ACLs am Layer3 besser aufgehoben wären, habe ich mir auch schon gedacht...
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
Schrott....wäre wohl eher angebracht. Naja ist ja jetzt HP Schrott
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.
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.
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
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
Ha!
Ich hab nun im letzt erwähnten Manual auf Seite 423 ff / Chapter 45 den entscheidenden Hinweis gelesen...
[edit: dieser Beitrag hat sich mit dem letzten erledigt!]
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!]
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
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:
Anschließend erneut 1.) durchführen, ob auch wirklich nichts mehr vorhanden ist...
3.) Time Range anlegen
ob diese Einstellung greift kann wie folgt getestet werden:
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
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!!!
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
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
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
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
4e) die Policy dem entsprechenden VLAN zuweisen
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)
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 )
[off Topic 1]:
das DHCP-Relaying läuft auf der Kiste AUSSCHLIESSLICH bei Einhaltunger folgender Befehlsreihenfolge!!!
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...
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
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-definedEs 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[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/2090Augenmerk 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
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
quit3117 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 3117die 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
quit4c) 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
quitdeny19 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
quit4e) die Policy dem entsprechenden VLAN zuweisen
qos vlan-policy pol17 VLAN 117 inbound
qos vlan-policy pol19 VLAN 119 inboundAnmerkung:
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
quitErgebnis 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
)[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 1Auch 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...
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
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
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
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
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
Zu Punkt 1: Das kannst du machen wenn du oben auf "Bearbeiten" klickst !
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.
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.
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
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
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
