mfischer70 12 Geschrieben 13. Oktober 2015 Autor Melden Teilen Geschrieben 13. Oktober 2015 nichts lieber als das. Ich habe jetzt die aktuelle 101110 Regel auf die Default Regel angepasst und das kommt dabei heraus : de-ber-switch1# show qos dscp-map DSCP Policies DSCP CodePoint DSCP Value 802.1p tag DSCP Policy name -------------- ---------- ----------- -------------------------------- 000000 0 0 cs0 000001 1 No-override 000010 2 No-override 000011 3 No-override 000100 4 No-override 000101 5 No-override 000110 6 No-override 000111 7 No-override 001000 8 1 cs1 001001 9 No-override 001010 10 1 af11 001011 11 No-override 001100 12 1 af12 001101 13 No-override 001110 14 2 af13 001111 15 No-override 010000 16 2 cs2 010001 17 No-override 010010 18 0 af21 010011 19 No-override 010100 20 0 af22 010101 21 No-override 010110 22 3 af23 010111 23 No-override 011000 24 3 cs3 011001 25 No-override 011010 26 4 af31 011011 27 No-override 011100 28 4 af32 011101 29 No-override 011110 30 5 af33 011111 31 No-override 100000 32 4 cs4 100001 33 No-override 100010 34 6 af41 100011 35 No-override 100100 36 6 af42 100101 37 No-override 100110 38 7 af43 100111 39 No-override 101000 40 5 cs5 101001 41 No-override 101010 42 No-override 101011 43 No-override 101100 44 No-override 101101 45 No-override 101110 46 7 ef 101111 47 No-override 110000 48 6 cs6 110001 49 No-override 110010 50 No-override 110011 51 No-override 110100 52 No-override 110101 53 No-override 110110 54 No-override 110111 55 No-override 111000 56 7 cs7 111001 57 No-override 111010 58 No-override 111011 59 No-override 111100 60 No-override 111101 61 No-override 111110 62 No-override 111111 63 No-override Zitieren Link zu diesem Kommentar
DocData 85 Geschrieben 13. Oktober 2015 Melden Teilen Geschrieben 13. Oktober 2015 Mapping passt doch: 101110 46 7 ef Zitieren Link zu diesem Kommentar
mfischer70 12 Geschrieben 13. Oktober 2015 Autor Melden Teilen Geschrieben 13. Oktober 2015 ja jetzt...die Regel war aber vorher in der Current Policy disabled. Ich habe sie dann auf die Default Policy zurückgestezt und heraus kam das gepostete. Sieht so aus, als ob da schonmal jemand was verändert hatte...vielleicht ich sogar beim probieren. Ich werde den Switch nochmal komplett zurücksetzen und dann das bisschen neu konfigurieren. Ist ja jetzt kein Hexenwerk mehr dank der Hilfe hier. :thumb1: Eine letzte Frage habe ich noch. Da ich ja dabei auch was lernen will (was ich ja jetzt auch schon habe)...Das VLAN was ich dann habe ist ja nur an den uplink Ports tagged und alle anderen Ports sind untagged, da die Telefone und PC's sich ja immer einen Port teilen. Alleine das taggen der uplink Ports reicht aus, um die CoS Informationen an den nächsten Switch weiterzureichen? Beim lesen im Internet bin ich da nämlich nicht 100% schlau geworden. Was ich auch noch gelesen habe ist, dass die CoS Priorisierung nach 5 Kriterien in einer festgelegten Reihenfolge arbeitet. 802.1p ist da die kleinste Priorität. Wenn ich zukünftig mal ein VLAN für irgendetwas konfigurieren muss und dort z.B. CoS die Priorität 1 gebe, dann würden die Pakete trotzdem bevorzugt werden, weil VLAN in der Priorität höher ist als 802.1p...siehe hier...habe ich das so richtig verstanden?: You can configure CoS prioritization on the basis of five criteria ranked as follows: Device Priority (destination or source IP address) IP Type of Service (ToS) field Protocol Priority (IP, IPX, ARP, DEC LAT, AppleTalk, SNA, and NetBeui) VLAN Priority Incoming 802.1p Priority (present in tagged VLAN environments) If more than one criteria is present in a packet, the highest ranked of the criteria is used to prioritize the packet; all lower-ranked criteria are ignored. For example, if CoS assigns: High priority to ‘‘red’’ VLAN packets Normal priority to IP packetsSince Protocol Priority (third in precedence, as shown above) has precedence over VLAN priority (fourth in precedence, as shown above), IP packets on the ‘‘red’’ VLAN will be set to normal priority. The "Priority Criteria and Precedence" table provides a more detailed description of how this operates. Gruß Mike Zitieren Link zu diesem Kommentar
DocData 85 Geschrieben 13. Oktober 2015 Melden Teilen Geschrieben 13. Oktober 2015 Eine letzte Frage habe ich noch. Da ich ja dabei auch was lernen will (was ich ja jetzt auch schon habe)...Das VLAN was ich dann habe ist ja nur an den uplink Ports tagged und alle anderen Ports sind untagged, da die Telefone und PC's sich ja immer einen Port teilen. Alleine das taggen der uplink Ports reicht aus, um die CoS Informationen an den nächsten Switch weiterzureichen? Beim lesen im Internet bin ich da nämlich nicht 100% schlau geworden. Nein, reicht nicht aus. Der Port vom Telefon muss tagged sein. Was ich auch noch gelesen habe ist, dass die CoS Priorisierung nach 5 Kriterien in einer festgelegten Reihenfolge arbeitet. 802.1p ist da die kleinste Priorität. Wenn ich zukünftig mal ein VLAN für irgendetwas konfigurieren muss und dort z.B. CoS die Priorität 1 gebe, dann würden die Pakete trotzdem bevorzugt werden, weil VLAN in der Priorität höher ist als 802.1p...siehe hier...habe ich das so richtig verstanden?: Quelle? Zitieren Link zu diesem Kommentar
mfischer70 12 Geschrieben 13. Oktober 2015 Autor Melden Teilen Geschrieben 13. Oktober 2015 Dann stehe ich wieder am Anfang. Wie ich ja am Anfang geschrieben habe....die Telefone stecken im Switchport und die PC's dann im Telefon. Damit kann ich ja den Port nicht auf tagged setzen. Was habe ich noch für ne Möglichkeit? Quelle: http://www.hp.com/rnd/device_help/help/hpwnd/webhelp/HPJ4121A/configuration_cos.htm etwa in der Mitte Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 13. Oktober 2015 Melden Teilen Geschrieben 13. Oktober 2015 Ist es möglich, den Port hybrid "zu machen"? Z.B. VLAN1 untagged, VLAN2 tagged? Ansonsten eben das Kabel sharen, splitten. Zitieren Link zu diesem Kommentar
DocData 85 Geschrieben 13. Oktober 2015 Melden Teilen Geschrieben 13. Oktober 2015 Dann stehe ich wieder am Anfang. Wie ich ja am Anfang geschrieben habe....die Telefone stecken im Switchport und die PC's dann im Telefon. Damit kann ich ja den Port nicht auf tagged setzen. Was habe ich noch für ne Möglichkeit? Wie ich bereits mehrfach sagte: Du hast ein konzeptionelles Problem. Ist es möglich, den Port hybrid "zu machen"? Z.B. VLAN1 untagged, VLAN2 tagged? Die ProVision kennen kein Hybrid und ein Port kann nur tagged ODER untagged sein. Aber nicht beides. In dem Dann dann doppelte Portanzahl. Ein Port für TK und einen für den PC. Zitieren Link zu diesem Kommentar
mfischer70 12 Geschrieben 13. Oktober 2015 Autor Melden Teilen Geschrieben 13. Oktober 2015 Ist es möglich, den Port hybrid "zu machen"? Z.B. VLAN1 untagged, VLAN2 tagged? es gibt ja mit den Switchen leider nur die Möglichkeit das Ganze über ein VLAN abzuwickeln. In jedem Büro sind 2 Dosen für 2 Mitarbeiter (mal mehr und mal weniger), wie soll ich da splitten? Und auf den Switchen sind zwar jeweils ein paar Ports frei, aber bei weitem nicht genügend für alle Telefone. :suspect: Wie ich bereits mehrfach sagte: Du hast ein konzeptionelles Problem. das Glaube ich gern, aber was wäre denn Dein Konzept an meiner Stelle? Ich habe genau die vorhandenen Switche und pro Mitarbeiter habe ich einen Port an dem der PC hängt und in die Mitte muss ein IP-Phone. Das ganze muss so priorisiert sein, dass die Telefonie Vorrang hat. Alles andere lassen wir jetzt mal außen vor. Was wäre Dein Vorschlag? Zitieren Link zu diesem Kommentar
DocData 85 Geschrieben 13. Oktober 2015 Melden Teilen Geschrieben 13. Oktober 2015 Rolle ein dediziertes Voice-VLAN aus. Konfiguriere dieses als tagged, das Client VLAN als untagged. Hänge den PC an das Telefon, das Telefon an den Switch. Konfiguriere ein DHCP Relay in deinem Netz. Teile deiner IT mit, dass du für VoIP ein anderes Subnetz brauchst und das die ihren DHCP entsprechend konfigurieren sollen. Zitieren Link zu diesem Kommentar
mfischer70 12 Geschrieben 13. Oktober 2015 Autor Melden Teilen Geschrieben 13. Oktober 2015 (bearbeitet) Rolle ein dediziertes Voice-VLAN aus. Konfiguriere dieses als tagged, das Client VLAN als untagged. Hänge den PC an das Telefon, das Telefon an den Switch. Soweit waren wir ja schon, das ist kein Problem. Teile deiner IT mit, dass du für VoIP ein anderes Subnetz brauchst und das die ihren DHCP entsprechend konfigurieren sollen. das wird auch nicht das Problem sein. Konfiguriere ein DHCP Relay in deinem Netz. Das hatte ich ja schonmal gefragt. Meine Frage war: Wenn ich einen Switch austausche in einen Layer 3 Switch, der DHCP Relay kann, löst das dann mein Problem? Die Antwort dazu war nein. bearbeitet 13. Oktober 2015 von mfischer70 Zitieren Link zu diesem Kommentar
DocData 85 Geschrieben 13. Oktober 2015 Melden Teilen Geschrieben 13. Oktober 2015 Das hatte ich ja schonmal gefragt. Meine Frage war: Wenn ich einen Switch austausche in einen Layer 3 Switch, der DHCP Relay kann, löst das dann mein Problem? Die Antwort dazu war nein. Wo wir wieder beim Kontext wären. Wenn du kein VLAN und kein anderen DHCP Subnetz zur Verfügung stellen kannst, dann löst ein DHCP Relay dein Problem nicht. Eingangs hast du gesagt, dass du mit dem, was dir die IT gibt, leben musst. Also was denn nun?! Zitieren Link zu diesem Kommentar
mfischer70 12 Geschrieben 13. Oktober 2015 Autor Melden Teilen Geschrieben 13. Oktober 2015 Jetzt drehen wir uns im Kreis... Jetzt also ganz von vorn mit diesen Gegebenheiten: Und schon mal Danke für Deine Geduld! Ich habe mit unserer lokalen Geschäftsleitung geklärt, dass wir abweichend von den Richtlinien ein Subnetz erstellen werden. Dieser Punkt ist also geklärt. Parallel dazu habe ich mit dem Lieferanten der Telefonanlage gesprochen. Die Anlage hat einen eigenen DHCP Server integriert und kann auch als DHCP Relay Agent arbeiten. Wenn ich jetzt wie beschrieben ein Data VLAN und ein Voice VLAN einrichte, die Ports für das Data VLAN untagged und für das Voice VLAN tagge, die uplink ports für beide Netze tagge und dann die PC's in die Telefone und die Telefone in die Switche stecke. Die Telefonanlage sollte ja dann als DHCP Relay Agent arbeiten können. Muss der Port für die Telefonanlage dann tagged oder untagged sein? Dann würden sich doch die Telefone eine IP aus dem Voice Netz ziehen und die PC's aus dem Datennetz und ich könnte ganz normal QoS über die VLAN's machen. Habe ich da noch einen Denkfehler? Zitieren Link zu diesem Kommentar
DocData 85 Geschrieben 13. Oktober 2015 Melden Teilen Geschrieben 13. Oktober 2015 Jetzt drehen wir uns im Kreis... Was nicht an mir liegt... Ich habe mit unserer lokalen Geschäftsleitung geklärt, dass wir abweichend von den Richtlinien ein Subnetz erstellen werden. Dieser Punkt ist also geklärt. Parallel dazu habe ich mit dem Lieferanten der Telefonanlage gesprochen. Die Anlage hat einen eigenen DHCP Server integriert und kann auch als DHCP Relay Agent arbeiten. Soweit okay. Wenn ich jetzt wie beschrieben ein Data VLAN und ein Voice VLAN einrichte, die Ports für das Data VLAN untagged und für das Voice VLAN tagge, die uplink ports für beide Netze tagge und dann die PC's in die Telefone und die Telefone in die Switche stecke. Die Telefonanlage sollte ja dann als DHCP Relay Agent arbeiten können. Muss der Port für die Telefonanlage dann tagged oder untagged sein? Die TK Anlage braucht ein Interface in dem VLAN für das sie Relay spielen soll. Ob der Port tagged oder untagged sein muss, kann dir der Hersteller verraten. Wenn die TK Anlage die Frames nicht bearbeitet, also kein VLAN Tagging beherrscht, dann muss der Port untagged im Voice VLAN sein. Und da du das Ding ja auch administrieren willst, sollte sie wohl auch noch ein Interface in deinem Client-VLAN haben. Also auch dort untagged. Wenn deine TK Anlage nur EINEN Anschluss hat, hast du ein Problem. Dann würden sich doch die Telefone eine IP aus dem Voice Netz ziehen und die PC's aus dem Datennetz und ich könnte ganz normal QoS über die VLAN's machen. Habe ich da noch einen Denkfehler? Du machst kein QoS über die VLANs... du lässt die Telefone DSCPs setzen und sagst den Switches was sie damit machen sollen (eben DSCP auf CoS mappen und das entsprechend berücksichtigen). Wenn die TK Anlage DHCP für beide Welten, also TK und Clients spielen soll, dann brauchst sie in beiden VLANs ein Interface. Und dann brauchst du eigentlich auch kein DHCP Relay. DHCP Relay brauchst du immer dann, wenn du DHCP Requests aus einem Subnetz an einen DHCP weiterleiten willst. Wenn dein DHCP aber multi-homed ist (das wäre deine TK Anlage ja, wenn sie DHCP spielt und in jedem VLAN ein Interface hat), dann brauchst du kein DHCP Relay. Zitieren Link zu diesem Kommentar
mfischer70 12 Geschrieben 13. Oktober 2015 Autor Melden Teilen Geschrieben 13. Oktober 2015 die Anlage hat einen WAN und einen LAN Port. Da wir nach extern momentan noch über NTBA arbeiten, bleibt der WAN Port unbenutzt. Später kommt der an die jetzt noch mit NTBA betriebene Telefonleitung (SIP). Also bleibt mir nur der eine LAN Port. Würde also nur der Weg bleiben, die Telefonanlage DHCP fürs Telefonnetz machen zu lassen oder die Telefone manuell zu konfigurieren. Damit würde zwar soweit alles funktionieren, aber wie Du schon schreibst...ich will die Anlage ja auch noch administrieren und der ein oder andere User bekommt ja noch den Client für die Telefonanlage auf dem PC installiert, um gewisse Sachen komfortabel einstellen zu können und dazu braucht die Anlage ein Interface im im Client-VLAN. Fazit: Sche.... Zitieren Link zu diesem Kommentar
mfischer70 12 Geschrieben 14. Oktober 2015 Autor Melden Teilen Geschrieben 14. Oktober 2015 (bearbeitet) so...heute habe ich mit dem Techniker gesprochen, der die Anlage bei uns aufbauen wird. Die Anlage selbst kann auch VLAN tagging. Die Lan Schnittstelle kann somit an einen für beide Netze tagged Port. Damit ist der Weg nun doch frei zur Umsetzung. Ich hab mir heute eine Testumgebung aufgebaut und praktisch versucht das umzusetzen. Den Switch habe ich mit der neuesten Firmware geflashed und siehe da....ein kurzer Befehl und es kam keine Fehlermeldung mehr...DHCP-Relay ist aktiviert. Hier der Ausdruck aus der CLI: de-ber-switch1(config)# show dhcp-relay DHCP Relay Agent : Enabled DHCP Request Hop Count Increment : Enabled Option 82 : Disabled Response validation : Disabled Option 82 handle policy : replace Remote ID : mac DHCP Relay Statistics: Client Requests Server Responses Valid Dropped Valid Dropped ---------- ---------- ---------- ---------- 0 0 0 0 DHCP Relay Option 82 Statistics: Client Requests Server Responses Valid Dropped Valid Dropped ---------- ---------- ---------- ---------- 0 0 0 0de-ber-switch1(config)# Anschließend konnte ich auch die IP helper-address sauber eintragen, siehe hier: vlan 1 name "Data" no untagged 1-2 untagged 3-48 tagged 49-52 ip address 10.86.80.17 255.255.240.0 exitvlan 2 name "Voice" untagged 1-2 tagged 3-52 ip address 192.168.0.2 255.255.255.0 ip helper-address 10.86.81.3 voice exitpassword manager de-ber-switch1(vlan-2)# Der DHCP steht im Data VLAN. Ich habe dann in beide Netze jeweils einen PC an einen untagged Port gehängt und geschaut, ob sie beide eine IP bekommen. Der Rechner aus dem Data VLAN bekommt erwartungsgemäß eine IP, der andere nicht. Hier noch ein Auszug aus der Routing Tabelle: de-ber-switch1(vlan-2)# show ip route IP Route Entries Destination Gateway VLAN Type Sub-Type Metric Dist. ------------------ --------------- ---- --------- ---------- ---------- ----- 10.86.80.0/20 Data 1 connected 1 0 127.0.0.0/8 reject static 0 0 127.0.0.1/32 connected 1 0 192.168.0.0/24 Voice 2 connected 1 0 Ich weiß, dass es nur ein Layer 2 Switch ist, allerdings hat er Layer 3 Funktionalitäten, wie man hier sehen kann: de-ber-switch1(vlan-2)# disable layer3 Enable/disable layer 3 functionality. Wenn ich das mit dem DHCP Relay jetzt hinbekomme, dann bin ich aus dem Schneider. Hat zum DHCP Relay noch jemand eine Idee? Falls nicht würde ich evtl. kostenneutral auf HP 1920 POE+ Switche umsteigen können. Laut QuickSpec unterstützen die QoS, CoS, Auto voice VLAN, DHCP Relay und Layer 3 Routing (32 statische Routen bei bis zu 8 VLAN) und erkennen. Das sollte für das Projekt doch dann reichen oder fehlt da noch etwas? Gruß Mike bearbeitet 14. Oktober 2015 von mfischer70 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.