mfischer70

Hallo zusammen,

unter Windows 8 hatte ich auf meinem PC die WSUS Management Console installiert, um von meinem PC aus den Zustand der PC's im Netzwerk kontrollieren zu können. Nach dem Upgrade auf Windows 10 ist die Management Console verschwunden. Gibt es eine Möglichkeit, das genauso machen zu könne wie unter Windows 8? Die Console lässt sich leider nichtneu installieren.

Das gleiche Problem habe ich für die Active Directory Verwaltung. Das alte Snap-In funktioniert auch nicht mehr. Gibt es hier eine Lösung?

Gruß Mike

Für alle, die das gleiche Problem haben, ich habe die Lösung gerade selbst gefunden:

Remote Server Administration Tools für Windows 10 downloaden und installieren

Unter Programme und Features / Windows Features aktivieren

Remote Server Administration Tools aktivieren

und schon gibt's in der Verwaltung die benötigten Tools.

Hatte es vorher nicht gefunden...sorry.

Gruß Mike

die meisten User arbeiten mit Laptops und benötigen Daten auch unterwegs. Bei den speziellen Usern mit dem Problem jetzt handelt es sich allerdings um stationäre Clients. Abschalten für diese stationären wäre also tatsächlich eine Lösung, wenn der User tatsächlich offline Files nutzt, denn das steht ja erst heute Nachmittag fest.

Problem gelöst. Wenn jemand in mehreren Pfaden (mal hier und mal da) was ablegt und diese Pfade auch noch verdammt ähnlich im Namen sind (nur eine Ordnerebene drüber oder drunter), dann führt das natürlich zu Verwirrung bei den Usern, die dann im falschen Ordner mit nahezu identischem Inhalt sind. Da muss man erstmal drauf kommen. 

Danke trotzdem für Eure Hilfe.

Gruß Mike

Offline Dateien nutzen nur sehr wenige bei uns und auch nur auf den persönlichen Laufwerken. Die Kollegin selbst nutzt nach eigenen Angaben keine offline Files. Momentan ist in dem Zimmer allerdings auch ein Meeting. Ich komme frühestens heute Nachmittag da an den PC.

Hallo Leute,

ich habe hier ein Windows Netzwerk. Der DC und der Datenserver sind beide Win2008 R2. User arbeiten mit Win7

In letzter Zeit kommt es öfter vor, dass User veraltete Dateien im Netz sehen. Wenn jemand in ein gemeinsames Serverlaufwerk eine Datei ablegt, dann sieht der User über einen längeren Zeitraum immernoch die alten Dateien und nicht die neuen. Wenn er die öffnet, sind es auch tatsächlich noch die alten Daten und nicht die aktualisierten. Das Problem tritt sporadisch bei verschiedenen Leuten auf. Wo fange ich am Besten an zu suchen?

Danke für Hinweise

Mike

Hallo Leute, da bin ich nochmal.

Die Switche sind inzwischen in Betrieb und das Daten Netz läuft sehr stabil. Im Moment läuft eine VoIP Messung vom Lieferanten über mehrere Tage, bei dem mehrere Geräte im Netzwerk verteilt sind und Telefonate untereinander simuliert werden. Die Messung sieht bisher meist ganz gut aus und ergibt bisher einen MOS von knapp 4,3

Ich habe nochmal eine Verständnisfrage:

Verbaut sind ja jetzt die 1910er HP-Switche. Jeder Port hat dann entweder ein Telefon, oder einen PC. Es wird also nichts durchgeschliffen.

Das ganze wird der Einfachheit halber in einem VLAN gemacht, welches als Voice gekennzeichnet ist.

Auf allen 5 Switchen sind die uplink Ports und die Telefon Ports tagged und alle anderen Ports untagged.

Die Telefone senden den DSCP Wert ef, also 46. Im Priority Mapping der Switche ist für 46 im Standard Queue 5 vorgesehen, das habe ich nicht verändert

Jetzt die eigentliche Frage:

Reicht es aus, bei den Switchen im Punkt "Port Priority" die jeweiligen Ports und uplink Ports auf "Trust Mode" DSCP zu stellen und als Priority die 5 einzutragen, damit QoS sauber funktioniert, oder bedarf es noch mehr?

Habs mal editiert...besser so? :-)

Ob es so gelingt weiß ich ja nicht, deshalb frage ich ja. Die Telefone kommen erst nächste Woche, aber ich muss natürlich soviel wie möglich vorbereiten.

Hallo Leute,

da bin ich wieder. Urlaub ist vorbei und weiter geht es mit den inzwischen getauschten Switchen.

Ich habe jetzt die HP1920 48-port POE+. folgender Zustand:

2 VLANS sind erstellt (Daten und Voice).

DHCP Relay funktioniert inzwischen auch hervorragend. PC's aus beiden Netzen bekommen eine IP Adresse aus dem jeweiligen Bereich vom DHCP Server. PC's in Daten können PC's in Voice anpingen und umgekehrt, das Routing funktioniert also.

Jetzt bin ich beim Einrichten des Voice Netzes. PC's und Telefone teilen sich ja dann einen Port. Dieser Port ist dann jeweils im Daten VLAN untagged und im Voice VLAN tagged.

Soweit so gut. Wenn ich jetzt versuche unter Voice VLAN/ Port Setup den VLAN Port Mode auf Auto zu setzen und den Port State auf Enable setze, dann kommt eine Fehlermeldung, dass im Automodus der Port nicht für Voice aktiviert werden kann, wenn er bereits im Voice VLAN ist. Klar...der Port ist untagged im Daten- und tagged im Voice VLAN.

Heißt das, dass ich den Port in den Porteinstellungen dann erstmal nur für das Daten Netz untagge und das tagging für Voice entferne? Wenn ich das tue, dann lässt sich der Port unter Voice VLAN/ Port Setup auch auf AUTO einstellen. Was ist Euer Rat?

Gruß Mike

so...ich bekomme im Tausch gegen die HP2530 jetzt HP1920 Switche, welche sogar noch preiswerter sind. Die 2530er waren ja keine Layer3 Switche und gehen zurück an den Anbieter. Es waren ja Layer 3 Switche gewünscht. Der Tausch erfolgt zum Glück problemlos. Damit sollte das Ganze eigentlich kein großes Problem mehr sein, da die 1920er ja sowohl DHCP Relay, als auch Routing...zumindest statische Routen beherrschen. Qos und CoS auch und mehr brauche ich nicht wirklich. Dann also auf ein neues mit den neuen Switchen, aber nächste Woche ist erstmal Urlaub angesagt. Ich melde mich wieder ob alles funktioniert hat, oder wenn noch Fragen auftauchen.

Danke für Eure Hilfe und Geduld Leute, ich hab zu dem Thema jetzt einiges an Wissen hier mitgenommen!

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

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

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?

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.

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?

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

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

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

Nein. Die Telefone sollen ihre Frames selber mit einem DSCP versehen. An den Switches musst du üblicherweise nichts mehr machen. Die ProCurven haben standardmäßig ein Mapping von DSCP zu COS. In dem ist hinterlegt das z.B. DSCP 101110 auf COS 7 gemappt wird.

Das die Telefone die Frames selber mit einem DSCP versehen sollen, hatte ich so auch verstanden. Was ich mit meiner Aussage meinte war, dass ich am Switch noch die DSCP Policies konfigurieren muss, denn eine Standard DSCP Regel von 101110 auf COS7 gibt es in der Tat, aber diese sind von Haus aus auf dem Switch disabled. (101110 Default Priority: 7-High Priority and Current Priority: disabled). Alles was dann noch zu tun ist, ist dem Telefon beibringen das DS Feld mit 101110 zu befüllen. Ich denke dann hab ich es?!

Um nochmal zusammenzufassen:

Du meinst ich soll das Ganze mit einem VLAN machen, dieses als Voice markieren und die uplinks zu den anderen Switchen Taggen. Bei den anderen Switchen dann genau das Gleiche.

Dann auf dem Switch mit dem Befehl: qos type-of-service diff-services  die Diff Services aktivieren (das geht sogar in der Weboberfläche). Beim Sevicetyp DSCP Remapping auswählen und eine entsprechende DSCP-Policy erstellen. Das sorgt für die Priorisierung der IP-Telefone?

Ich bin auf diesem Gebiet komplett neu, aber lt. Wiki steht das drin:

"DSCPs dienen lediglich der Klassifizierung, nicht aber der Priorisierung. Das heißt, dass ein höherer Zahlenwert nicht unbedingt einer bevorzugten Behandlung entspricht."

Ich lasse mich aber gern eines besseren belehren. Am Ende muss es nur sauber funktionieren.

Gruß Mike

das mit dem DHCP bezog sich nur auf Deinen Link vorhin...hab mich falsch ausgedrückt.

Nochmal anders: Habe ich eine Möglichkeit den VoIP Traffic über Port Priorisierung sauber zu priorisieren, wenn die Telefone im gleichen Netz sind wie die PC's? Theoretisch sollte das ja gehen, aber praktisch?

Hab ein Firmwareupdate gemacht. IP Helper kann er tatsächlich nach wie vor nicht. Die Aussage in dem Forum kann man dann mal getrost in die Tonne hauen. Hab genau den gleichen Switch und die gleiche Firmware...super.

Frage 1: Würde es was bringen, wenn ich einen der 5 Switche (den der dann das DHCP Relay machen soll) ersetze gegen einen, der DHCP Relay kann und die anderen mit den vorhandenen 2530 belasse? Falls ja, was würdet ihr für einen einfachen empfehlen?

Frage 2: Ohne Windows 2012 Server für DHCP (habe ja leider nur 2008 Server)...was habe ich für eine Chance, eine Priorisierung zu machen? Funktioniert die Port Priorisierung genauso stabil?

Gruß Mike

Der 2530 kann kein ip helper-address. Das ist ein reiner Layer 2 Switch. Siehe dazu auch die QuickSpecs zu dem Modell.

Das hatte ich befürchtet, aber warum finde ich dann diese Aussage hier bei HP? Der schreibt doch, dass seiner das kann...bin jetzt etwas verwirrt:

Re: DHCP Helper-add​ress HP 2530 (j9779a)

‎03-30-2015 05:48 AM

Ist denn ein Trennen der Adressbereiche zwingend notwendig?

 

Ich habe zwar vehement die Ansicht vertreten, VLAN anzuwenden, ich bin aber bereit, meine Meinung zu ändern und neu zu denken. Was spräche gegen portbasierte Priorisierung?

eigentlich sind die Adressen vorgegeben, aber selbst der Konzern hält sich nicht daran. So ist für WLAN ja auch ein eigener Bereich vorgegeben, aber sämtliche WLAN Geräte bekommen Adressen aus dem ganz normalen Bereich für PC's. Wenn ich also mal sagen würde...die Trennung der IP-Bereiche ist nicht notwendig, wie würde man dann vorgehen? Das ganze in einem VLAN lassen und die Priorisierung über die Ports der Anwendung abwickeln? Wäre sicher sie einfachste Lösung, da müsste ich nur beim Hersteller die Ports erfragen. Aber ob das dann wirklich sauber funktioniert? Ich habe gelesen, dass es bis etwa 200 Geräte funktionieren soll, aber das ist blanke Theorie. Über VLAN wäre schon sauber.

über exakt diesen Beitrag bin ich auch gerade gestolpert. Mein 2530 ist ein J9772A und im letzten Beitrag schreibt jemand, dass er IP-Helper konfigurieren kann. Ich kann das bei mir nicht, also werde ich wohl erstmal ein Firmware update machen müssen. Damit wäre dann die Frage, ob der Switch IP-Helper überhaupt kann hoffentlich klar. Allerdings habe ich auch folgendes in einem anderen Beitrag dort gefunden:

This is layer 2 switch and doesnt support ip routing at all. So it is not enabled by default and cannot be enabled by a command.

Wenn er kein IP Routing kann, wie kann er dann gleichzeitig DHCP Relay spielen?

Die Telefone brauchen zu beiden Netzen Verbindung, da sich die IP-Phones wohl immer erst im Datennetz eine IP vom DHCP holen. Über die DHCP Option 43 bekommen die Telefone dann gesagt, dass sie im VLAN Voice arbeiten sollen, booten neu und holen sich dann dort eine neue IP des Voice VLAN. Das ist allerdings nur angelesene Theorie.

Zum DHCP Relay Agent gibt es hier eine gute Seite:

https://technet.microsoft.com/de-de/library/dd759168.aspx

Über die Bereichsgruppierung des DHCP Servers kann man tatsächlich 2 komplett verschiedene Netze über ein und denselben DHCP Server verteilen. Man braucht eben nur einen DHCP Relay Agent, der das ganze routet. Hier kommt wieder die Idee von vorhin ins Spiel...warum nicht den Switch routen lassen?

Danke wieder mal für die Antworten und Anregungen.

Ins HP Forum habe ich inzwischen geschaut und auch viel gelesen, aber nichts passendes gefunden. Zumindest habe ich eine Übersicht über die Befehle, mit denen ich ja auch die bisherige Konfiguration schon gemacht habe.

Auf den DHCP Server (2008 Server) habe ich keinen Zugriff. Ich kann dort weder ein 2. Interface aktivieren, noch irgendetwas konfigurieren. Ein zweites Netzwerkinterface scheidet daher aus. Die IP-Adressen für die Telefone sind vom Konzern mit dem Bereich 10.86.88.1 - 10.86.89.254 vorgegeben, was so m.M. nach nicht funktionieren kann. Es wäre das gleiche Netz und damit funktioniert kein VLAN.

 @ DocData 

den Switch DHCP Relay spielen lassen ist ja ok, aber wo bekommen die IP-Phones ihre IP her? Der DHCP hat ja einen Scope im Bereich 10.86.80.0 definiert und der 2. Bereich 10.86.88.0 (für die Phones) ist damit so nicht möglich auf dem DHCP

Hi Leute,

ich hoffe Ihr hattet ein schönes WE.

Das easy-to-use graphical Interface kann man bei den HP Switchen glaube ich vergessen, weil man da nur eine Grundkonfiguration machen kann. Das meiste ist konsolenbasiert und ich bin leider absolut neu auf dem Gebiet. Ip Routing ist noch nicht aktiviert.

mein Netz ist 10.86.80.0/20  Maske ist also: 255.255.255.240

meine Rechner bekommen vom DHCP Adressen im Bereich 10.86.84.1 - 10.86.85.254

Ich habe jetzt am WE noch folgende Informationen von unserem Konzern erhalten:

die IP-Phones sollen Adressen aus dem Bereich 10.86.88.1 - 10.86.89.254 bekommen. Auf den DHCP habe ich keinen Zugriff. Ein 2. Bereich wird dort vom Konzern eingerichtet.

Damit ist es ja das gleiche IP-Netz. Wie soll man da am Ende mit VLAN's arbeiten, oder habe ich jetzt einen totalen Denkfehler? 

Gruß Mike