Zum Inhalt wechseln


Foto

VoIP mit HP 2530 Switchen


  • Bitte melde dich an um zu Antworten
56 Antworten in diesem Thema

#31 mfischer70

mfischer70

    Junior Member

  • 136 Beiträge

 

Geschrieben 13. Oktober 2015 - 09:18

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



#32 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 13. Oktober 2015 - 09:21

Mapping passt doch:   101110         46         7           ef


Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#33 mfischer70

mfischer70

    Junior Member

  • 136 Beiträge

 

Geschrieben 13. Oktober 2015 - 09:53

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:

  1. Device Priority (destination or source IP address)
  2. IP Type of Service (ToS) field
  3. Protocol Priority (IP, IPX, ARP, DEC LAT, AppleTalk, SNA, and NetBeui)
  4. VLAN Priority
  5. 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



#34 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 13. Oktober 2015 - 10:02

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?

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#35 mfischer70

mfischer70

    Junior Member

  • 136 Beiträge

 

Geschrieben 13. Oktober 2015 - 10:34

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/rn...uration_cos.htm etwa in der Mitte



#36 lefg

lefg

    Expert Member

  • 20.474 Beiträge

 

Geschrieben 13. Oktober 2015 - 10:45

Ist es möglich, den Port hybrid "zu machen"? Z.B. VLAN1 untagged, VLAN2 tagged?

 

Ansonsten eben das Kabel sharen, splitten.


Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#37 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 13. Oktober 2015 - 11:27

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.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#38 mfischer70

mfischer70

    Junior Member

  • 136 Beiträge

 

Geschrieben 13. Oktober 2015 - 11:37

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?



#39 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 13. Oktober 2015 - 11:42

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.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#40 mfischer70

mfischer70

    Junior Member

  • 136 Beiträge

 

Geschrieben 13. Oktober 2015 - 12:10

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 von mfischer70, 13. Oktober 2015 - 12:10.


#41 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 13. Oktober 2015 - 12:15

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?!

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#42 mfischer70

mfischer70

    Junior Member

  • 136 Beiträge

 

Geschrieben 13. Oktober 2015 - 13:15

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?



#43 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 13. Oktober 2015 - 13:43

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.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#44 mfischer70

mfischer70

    Junior Member

  • 136 Beiträge

 

Geschrieben 13. Oktober 2015 - 13:58

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.... 



#45 mfischer70

mfischer70

    Junior Member

  • 136 Beiträge

 

Geschrieben 14. Oktober 2015 - 13:06

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          0
de-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
   exit
vlan 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
   exit
password 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 von mfischer70, 14. Oktober 2015 - 13:08.