pysesl
Goto Top

Cisco SG350 als DHCP mit zwei Routern ins Internet

Guten Tag/Abend Gemeinde Admins

Ich bin im Moment daran in meinem alten Netz die Komponenten zu erneuern und stark abzuspecken.
An mir sind aber auch die Jahre nicht stehen geblieben und Mutter Natur hat mir vor ein paar Jahren
einen dicken Strich durch die Rechnung gemacht, so dass, wie man so schön sagt, der Traffic und Speicher Probleme macht, aber eben nicht so einfach zu ersetzen ist wie andere Hard- oder Software.
Ich war auch im IT-Bereich tätig, aber seit damals hat sich die Situation total verändert und vieles verunmöglicht.
Trotzdem habe ich mir gesagt, dass ein bisschen Hirntraining nicht schaden kann und mich an dieses Projekt gewagt das der Familie dienen soll.
Ich wende mich deshalb mit der Bitte an euch um etwas Hilfe, falls ich irgendwo etwas übersehen habe oder den Faden nicht mehr finden konnte.

Nun genug der Worte, zum Projekt.
Im bestehende Netz habe ich die SG300er durch SG350er ersetzt (Kupfer 6a und Fiber zwischen den Switches belassen).
MS-DC, DHCP-, DNS-, Data- und Backup Server ausser Betrieb genommen und durch zwei Qnap TS451DeU ersetzt.
Beide sind mit vier 4TB 24/7 Platten bestückt und als Raid 10 konfiguriert.
Einer als reiner Data der zweite als Sync-Backup, beide mit Portbündelung am SG350-28MP Switch im L3 Mode.
Diese reichen uns jetzt völlig aus für Scans und müssen noch alle Daten und Fotos der Familie der letzten Jahre bewirtschaften.
Sämtliche VLans am SG350-28MP (L3), sowie die Uplinks über die Combos via Fiber Lc/Lc Multimode Duplex und Kupfer Cat.7 als Redundanz sind erstellt.
Soweit ich das beurteilen kann, scheint das bis zum L3 Switch alles in Ordnung zu sein.
Im Moment sind noch keine ACLs definiert, die Pings sind im 1ms Bereich zwischen den VLan's, GW's, Switches, Clients, ISP Router und die weite Welt.
Nslookup Server Auflösungen im guten Bereich, Tracert ebenso. 1GB Daten mit Copy/Paste vom Client aus, der am Access Switch02 hängt zum QNap-Data Server am Core, rutschte mit 136 MB/Sek durch. Damit bin ich total zufrieden.

Meine Bitte an euch, könnt ihr euch einmal das Design was GW's ab L3, Routing, DHCP Relays und das nicht produktive VLan99 für den Internet-Zugang anschauen.

Folgende Problematik besteht.

1) Client wartet lange bis er einen Adresslease des DHCP vom Layer3 bekommt. Etwa 20-30 Sekunden.
Quasi, weisser Mann starrt durch Glasscheibe auf animierten Kreis.
(Ein erstelltes Test Vlan21 auf dem VPN Router (RV260) mit DHCP funktioniert aber einwandfrei.)

2) Option: DHCP-Relais oder ARP aktivieren, wenn ja was/wo macht Sinn.
Routing oder GW's falsch platziert, macht irgendwo einen Loop.

3) Dann habe ich echt Mühe mit diesen neuen GUI des Cisco-RV260, aber vorab CLI ist für mich überhaupt keine Option mehr.
Wollte statt VLan1 das VLan99 (das auf dem L3 erstellt wurde) als Management Vlan am RV-260 nutzen, für den Internet Traffic. Nur ????
L3 GW 10.26.99.254 => 10.26.99.1 am RV-260. Hatte das vorher am Server mit zwei Physischen Nics und Routing gelöst.
Ein globales DHCP-Relais am RV-260 scheint auch nicht möglich, Relais Funktion ist nur bei erstellten VLans möglich.
Alternativ hätte ich noch einen TP-Link ER7206 und ein D-Link DRS-1000 statt des RV-260, habe aber beide nicht getestet.

Ich habe mit Visio das Netzwerk versucht zu veranschaulichen, sind aber nicht alle Komponenten vertreten.
Was ja soweit nicht relevant sein sollte.
Einzig was vielleicht bei der Konfig relevant wäre ist, zu einem späteren Zeitpunkt möchte ich die Telefone über VoiP anschliessen.
Aber eins nach dem anderen.

Auf jeden Fall möchte ich mich jetzt schon recht herzlich dafür bedanken, dass ihr euch die Zeit diesen Beitrag zu lesen genommen habt und vielleicht sogar eine Lösung mir anzubieten könnt.

Nachfolgend jetzt noch den Netzwerkplan.

netzdesign_v1_16-9

Freundlich grüsst
Pysels

Content-ID: 1270440940

Url: https://administrator.de/forum/cisco-sg350-als-dhcp-mit-zwei-routern-ins-internet-1270440940.html

Ausgedruckt am: 08.04.2025 um 19:04 Uhr

aqui
aqui 17.09.2021, aktualisiert am 18.07.2024 um 15:53:35 Uhr
Goto Top
Dein Design ist soweit korrekt. Es ist ein klassisches Layer3_Design mit zentralem VLAN Routing auf dem 350X Core Switch. Alles bestens also und auch (fast) alles richtig gemacht.

Allerdings gibt es einige kosmetische Fehler im Setup einiger Komponenten:
  • Router RV260: Die /24er Return Routen sind Unsinn wenn VORHER das gesamte /16er VLAN Netz geroutet wird. Diese dann völlig überflüssigen Routen solltest du alle entfernen !
  • Core Switch 350X: Hier ist es völlig unverständlich wenn du DHCP Relay auf einen zentralen DHCP Server betreibst wieso du dann zusätzlich noch DHCP Server pro VLANs auf dem Switch definiert hast ? Das ist ein Riesenfehler und wir dir vermutlich die zentralen DHCP Problematiken bescheren weil jetzt überall 2 DHCP Server pro L2 Segment gegenseitig Amok laufen und Adress Chaos fabrizieren !
  • Der Trunk Uplink zum RV260 hat ein überflüssiges VLAN zuviel konfiguriert. 1 benötigst du nicht. Es macht dann mehr Sinn den Port UNtagged in VLAN 99 zu legen (99U) und 21 und 111 Tagged. So wäre es korrekt. Die gesamte Broad- und Multicast Last aus 1 müllt dir überflüssigerweise diesen Links zu.

Vermutlich besteht bei dir hier ein völlig fehlerhaftes Verständnis der DHCP Server Funktion obwohl die Logik ganz einfach ist:
  • Kein zentraler DHCP Server = Switch macht DHCP im VLAN, Switch macht kein Relay
  • Zentraler DHCP Server = Switch macht KEIN DHCP und NUR Relay (kein DHCP Server)
Wie immer gilt bei DHCP pro Layer 2 Domain die goldene Regel: "Es kann nur einen geben !"
Hier liegt also sehr wahrscheinlich dein fataler Verständnis- und daraus resultierend dann der Konfig Fehler den du zwingen korrigieren musst !

Wenn du einen zentralen DHCP Server in deiner MS Server Infrastruktur betreibst musst du alle DHCP Server auf dem Switch zwingend entfernen !
Dort wird auf den VLAN IP Interfaces lediglich NUR die Relay Funktion aktiviert auf die Ziel IP des DHCP Servers ! Außer....dem VLAN Interface in dem der DHCP Server selber liegt. Logisch, denn dort ist natürlich kein DHCP Forwarding am Interface erforderlich !
Wenn du diesen fatalen (Denk)Fehler in deiner DHCP Konfig beseitigst sollten die DHCP Antworten in unter 1 Sekunde kommen.

Weitere Infos zu Swisscom xDSL Setup mit Cisco Routern und DHCP Anforderungen auch HIER.
pysesl
pysesl 17.09.2021 um 13:27:19 Uhr
Goto Top
Guten Tag Aqui

Vorab recht herzlichen Dank für deine Antwort auf meine Anfrage.
Bezüglich deiner Antworten.

=> "Router RV260: Die /24er Return Routen sind Unsinn wenn VORHER das gesamte /16er VLAN Netz geroutet wird. Diese dann völlig überflüssigen Routen solltest du alle entfernen !"

Das habe ich etwas verwirrend und nicht genau im Plan definiert.
Das 16er auf dem RV260 hatte ich zu Testzwecken erfasst, als ich mit der VLan Kosmetik herumspielte.
Jede Route kann dort auf Enabled oder Disabled gestellt werden. Ist auch disabled seit dem die 24er erfasst und aktiv sind. Sorry, hätte diese 16er Testroute vom Plan löschen sollen, was zu dieser Verwirrung geführt hat.

=> "Core Switch 350X: Hier ist es völlig unverständlich wenn du DHCP Relay auf einen zentralen DHCP Server betreibst wieso du dann zusätzlich noch DHCP Server pro VLANs auf dem Switch definiert hast ? Das ist ein Riesenfehler und wir dir vermutlich die zentralen DHCP Problematiken bescheren weil jetzt überall 2 DHCP Server pro L2 Segment gegenseitig Amok laufen und Adress Chaos fabrizieren !"

Nur auf dem Core sind die DHCP Pools der Vlans mit entsprechenden Ranges definiert und auch kein DHCP Relay. Kann meines Wissens, wenn "DHCP enabled ist" gar nicht aktiviert werden. Habs alledings noch nie versucht. Nochmals Sorry, zu ungenau von mir erklärt. DHCP ist nur dem Core 10.26.1.254. Auf den beiden Access Switches SG350-10MP habe ich "DHCP Relay" aktiviert, sprich pro Interface auf den Core 10.26.1.254. Was aber auf die der Geschwindigkeit der Adressvergabe des DHCP gar keinen Einfluss hatte. Dann wieder auf die Suche. Auf dem RV260 habe ich deshalb zu Testzwecken einen DHCP Pool und ein 21Vlan erfasst, dann einen Client angehängt zum testen wie schnell der Lease vom RV260 DHCP kommt. Das war in Ordnung.

=>"Wenn du einen zentralen DHCP Server in deiner MS Server Infrastruktur betreibst musst du alle DHCP Server auf dem Switch zwingend entfernen !"

MS-DC, DHCP-, DNS-, Data- und Backup Server ausser Betrieb genommen. Hatte ich anfänglich doch erwähnt.
Diese existieren nicht mehr im Netz. Der SG350-28MP ist jetzt DHCP und das NAS als Data Ablage, was aber nicht auf dem Plan ist.

=> "Der Trunk Uplink zum RV260 hat ein überflüssiges VLAN zuviel konfiguriert. 1 benötigst du nicht. Es macht dann mehr Sinn den Port UNtagged in VLAN 99 zu legen (99U) und 21 und 111 Tagged. So wäre es korrekt. Die gesamte Broad- und Multicast Last aus 1 müllt dir überflüssigerweise diesen Links zu."

Dass ist allerdings ein Ansatzpunkt den ich noch umsetzen werde und erklärt vielleicht einiges.
Vorab nochmals recht herzlichen Dank und ich melde mich wieder nach der Umsetzung.
Plan werde ich auch noch anpassen, damit keine Verwirrung mehr aufkommt.

Beste grüsse
Pysesl
NixVerstehen
NixVerstehen 17.09.2021 um 21:51:31 Uhr
Goto Top
Zitat von @pysesl:
Nur auf dem Core sind die DHCP Pools der Vlans mit entsprechenden Ranges definiert und auch kein DHCP Relay. Kann meines Wissens, wenn "DHCP enabled ist" gar nicht aktiviert werden. Habs alledings noch nie versucht.
Korrekt...das geht nicht. Entweder ist der Switch selbst DHCP-Server oder DHCP-Relay. Steht auch so in der Doku,
aqui
aqui 18.09.2021 aktualisiert um 11:05:29 Uhr
Goto Top
Auf den beiden Access Switches SG350-10MP habe ich "DHCP Relay" aktiviert, sprich pro Interface auf den Core 10.26.1.254.
Das kann so niemals technisch funktionieren, denn die DHCP Server auf den Switches sind NICHT Multi Scope fähig wie ein zentraler DHCP Server ala Windows Server oder Linux_ISC_DHCP !
Das kann also niemals funktionieren und siehst du ja auch an deinem aktuellen, fehlerhaften DHCP Verhalten.
Dazu kommt das DHCP Relay auf reinen Layer 2 Switches natürlich völliger Quatsch ist. DHCP Relay ist eine reine Layer 3 Router Funktion. Auf L2 Devices ist sie völlig wirkungslos... Kollege @NixVerstehen hat es oben schon richtig angemerkt.
Es bleibt also dabei das deine DHCP Konfig völlig falsch ist und deine massiven Fehler verursacht. Du solltest zum Thema besser nochmal etwas lesen um die Technik dahinter zu verstehen. face-wink
Das musst du also zwingend korrigieren.

P.S.: Wenn zitieren dann bitte auch richtig machen ! Vor den zu zitirenden Passagen darf lediglich nur ein "> " mit einem Leerzeichen stehen !! So ist das schwer im Kontext zu lesen und verwirrt kollossal. face-sad Fällt einem ja auch selber auf wenn man seine eigenen Antwort nach dem Absenden sieht (Zitate sind beige hinterlegt)...!
pysesl
pysesl 23.09.2021 aktualisiert um 18:22:34 Uhr
Goto Top
Guten Tag aqui

Entschuldigt die späte Antwort, eine weitere Blutgefässentzündung in meinem Obergeschoss hatte mich mal wieder lahmgelegt.
Jetzt muss ich alles akribisch aufschreiben, sonst gehen bei mir die Pakete wieder gänzlich verloren. face-smile
So ist halt das Leben, kein Wunschkonzert, dann halt wieder Step-by-Step.
Genug der Worte und zur Sache.
Vorab besten Dank, dass du dir die Zeit genommen hast zu antworten, natürlich auch Kollege.

Das kann so niemals technisch funktionieren, denn die DHCP Server auf den Switches sind NICHT Multi Scope fähig wie ein zentraler DHCP Server ala Windows Server oder Linux_ISC_DHCP !

Danke für den Hinweis, hab's Fett notiert.

Dazu kommt das DHCP Relay auf reinen Layer 2 Switches natürlich völliger Quatsch ist. DHCP Relay ist eine reine Layer 3 Router Funktion.

(OSI Modell Layer2).

P.S.: Wenn zitieren dann bitte auch richtig machen ! Vor den zu zitirenden Passagen darf lediglich nur ein "> " mit einem Leerzeichen stehen !! So ist das schwer im Kontext zu lesen und verwirrt kollossal. face-sad face-sad Fällt einem ja auch selber auf wenn man seine eigenen Antwort nach dem Absenden sieht (Zitate sind beige hinterlegt)...!

Cool. Es sollte jetzt klappen.

Zu meinem eigentlichen Vorgehen:
In einem ersten Schritt habe ich das Design etwas angepasst und mich danach zuerst mal um die Basis, den Core SG350 im L3 Mode gekümmert. Wie es sich eigentlich gehört, auf der Basis wird ja aufgebaut.
Deshalb entschuldigt, dass ich mich nochmals an dich/euch wende.
Ich muss wirklich Step-by-Step vorgehen und abschliessen.
Vorgängig habe ich einige Test- ping, tracert- und nslookup- Befehle abgesetzt und die Ergebnisse unten eingefügt.

Es wäre eine super Sache, wenn ihr kurz ein Auge darauf werfen könnt und falls notwendig eure Vorschläge resp. Kritiken schreiben würdet.
Ich möchte danach die Konfigurationen sichern um weiter darauf aufzubauen, sprich einer der beiden Access Switch per Uplink mit dem Core verbinden, dann wieder Testreihe starten.

netzdesign_v2_1500x2100

Nachfolgend noch ein paar Infos zum jetzigen Stand.
Netz ist nicht im produktiven Betrieb, altes W7 ThinkPad und ein NAS (ohne DHCP, face-smile) für Testzwecke in die verschieden VLans.
Auf die vielleicht kommende Frage, wieso zwei Router.
Der ISP-Router bleibt im Moment noch (Tel., Notruf) und der Rest der Familie sollte noch Internetzugang haben.
Nächstes Jahr wird Glasfaser gelegt, dann wäre vielleicht eine Option den RV260 direkt anzuschliessen.
Im Moment ist er aber dazwischen geschaltet, so dass mir Internet zur Verfügung steht, oder vielleicht zwischendurch auch mal nicht mehr. face-smile

Zur Ausgangslage: Aktiv am geschehen sind Cisco SG350-28MP, Cisco RV260, ISP Router, ein alter Laptop (W7 Enterprise) und das NAS.

Core SG350-28MP:
IP: 10.26.1.254/24 Default (VLan1)
Default GW: 10.26.1.10 (RV260)
DNS: 192.168.1.1 (ISP Router)
Default Route: 0.0.0.0/0.0.0.0/10.26.1.10 (RV260)

IPv4 Routing => Enabled
PNP State =>Disabled
ACL's => noch keine
CDP => Disabled
Spanning Tree => Enabled und auf 4096 gesetzt (dann im Mod 4096 hoch).
  • Kann die Defaultvorgabe so bleiben (Rapid STP) oder besser Multiple STP.
Switches sind alle von der gleichen Serie. Hab's mal irgendwo aufgeschnappt. Null Ahnung.
IPv4 IGMP Snooping => Enabled
IPv4 IGMP Cuerrier => Enabled
LLDP => Enabled
ntp => ch.pool.npt.org, 0.ch.pool.npt.org
Jumbo Frames => Enabled

VLan1: => 10.26.1.0/24
DHCP Range => 101 - 150 (nur für die Testumgebung im Moment)
GW: => 10.26.1.254
DNS: => 192.168.1.1

VLan10: => 10.26.10.0/24
DHCP Range => 101 - 150
GW: => 10.26.10.254
DNS: => 192.168.1.1

VLan20: => 10.26.20.0/24
DHCP Range => 101 - 150
GW: => 10.26.20.254
DNS: => 192.168.1.1

VLan30: => 10.26.30.0/24
DHCP Range => 101 - 150
GW: => 10.26.30.254
DNS: => 192.168.1.1

VLan80: => 10.26.80.0/24
DHCP => Disabled
GW: => 10.26.80.254
DNS: => 192.168.1.1

VLan666: => Dead_End (Port Blocker)
DHCP => Disabled
GW: => -
DNS: => -

GE25 Trunk Port => 1U/10T/20T/30T/80T (Uplink Access Switch 01)
GE26 Trunk Port => 1U/80T (Uplink RV260)

Cisco RV260:
IP LAN: 10.26.1.10/24 Default (VLan1)
IP WAN: 192.168.1.10/24
Default GW: 192.168.1.1 (ISP Router)
DNS: 192.168.1.1 (ISP Router)
Firewall Disabled im Moment
Default Route: 10.26.0.0/255.255.0.0/10.26.1.254 (zum Core Sg350-28MP)

Jetzt zu den Tests
Ping-Test aus dem vlan1
Client / Switch Port 01 / access 1U

Beschreibung. . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Physikalische Adresse . . . . . . : F0-DE-F1-96-38-A8
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 10.26.1.150(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Donnerstag, 23. September 2021 12:44:09
Lease läuft ab. . . . . . . . . . : Freitag, 24. September 2021 12:44:08
Standardgateway . . . . . . . . . : 10.26.1.254
DHCP-Server . . . . . . . . . . . : 10.26.1.254
DNS-Server . . . . . . . . . . . : 192.168.1.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert

Pings jeweils nur einen der 4
ISP Router => Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=63
RV260 => Antwort von 10.26.1.10: Bytes=32 Zeit<1ms TTL=64
vlan20 => Antwort von 10.26.20.254: Bytes=32 Zeit<1ms TTL=64
vlan80 => Antwort von 10.26.80.254: Bytes=32 Zeit=1ms TTL=64
9.9.9.9 => Antwort von 9.9.9.9: Bytes=32 Zeit=4ms TTL=54
www.switch.ch => Antwort von 130.59.31.80: Bytes=32 Zeit=4ms TTL=52

Ping-Test aus vlan20
Client / Core Port 20 / access 20U

Beschreibung. . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Physikalische Adresse . . . . . . : F0-DE-F1-96-38-A8
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 10.26.20.150(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Donnerstag, 23. September 2021 14:35:19
Lease läuft ab. . . . . . . . . . : Freitag, 24. September 2021 14:35:18
Standardgateway . . . . . . . . . : 10.26.20.254
DHCP-Server . . . . . . . . . . . : 10.26.20.254
DNS-Server . . . . . . . . . . . : 192.168.1.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert

Pings jeweils wieder nur einen der 4
ISP Router => Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=62
RV260 => Antwort von 10.26.1.10: Bytes=32 Zeit<1ms TTL=64
vlan1 => Antwort von 10.26.1.254: Bytes=32 Zeit<1ms TTL=64
vlan20 => Antwort von 10.26.20.254: Bytes=32 Zeit=1ms TTL=64
vlan80 => Antwort von 10.26.80.254: Bytes=32 Zeit=1ms TTL=64
9.9.9.9 => Antwort von 9.9.9.9: Bytes=32 Zeit=4ms TTL=54
www.switch.ch => Antwort von 130.59.31.80: Bytes=32 Zeit=4ms TTL=51

>nslookup switch.ch
Server: centrobusiness
Address: 192.168.1.1

Nicht autorisierende Antwort:
Name: switch.ch
Addresses: 2001:620:0:ff::5c
130.59.31.80

>tracert switch.ch
Routenverfolgung zu switch.ch [130.59.31.80] über maximal 30 Abschnitte:

1 1 ms 1 ms 1 ms 10.26.20.254
2 <1 ms <1 ms <1 ms 10.26.1.10
3 1 ms <1 ms <1 ms centrobusiness [192.168.1.1]
4 3 ms 3 ms 3 ms 1.92.0.85.dynamic.wline.res.cust.swisscom.ch [85.0
5 * * * Zeitüberschreitung der Anforderung.
6 7 ms 7 ms 7 ms i71lzf-000-ae30.bb.ip-plus.net [193.134.95.208]
7 4 ms 3 ms 3 ms i71lzf-005-ae3.bb.ip-plus.net [138.187.129.196]
8 4 ms 4 ms 4 ms i79zhb-015-ae14.bb.ip-plus.net [138.187.129.195]
9 4 ms 4 ms 3 ms i79tix-025-ae11.bb.ip-plus.net [138.187.130.38]
10 5 ms 4 ms 4 ms 193.134.95.27
11 5 ms 4 ms 4 ms swiEZ3-100GE-0-1-0-4.switch.ch [130.59.38.109]
12 4 ms 4 ms 4 ms lec7701-eth-1-48.switch.ch [130.59.115.34]
13 5 ms 4 ms 4 ms prod.www.switch.ch [130.59.31.80]

>tracert 192.168.1.1
Routenverfolgung zu centrobusiness [192.168.1.1] über maximal 30 Abschnitte:

1 1 ms 1 ms 1 ms 10.26.20.254
2 <1 ms <1 ms <1 ms 10.26.1.10
3 1 ms <1 ms <1 ms centrobusiness [192.168.1.1]

  • Die Antwortzeiten der Pings sind immer so knapp um 1ms (= oder<)
Knapp oder o.k.????
Das zweite was mich irritiert.
  • Wenn der DNS Eintrag am Core auf den ISP-Router zeigt (192.168.1.1) funktioniert NPT Server abgleich nicht.
Wenn ich aber auf den RV260 wechsle (10.26.1.10) sind die NPT's wieder online. Hab ich was übersehen?
  • Datendurchsatz Copy,Paste (Client=>NAS so um die 118-132 MB/Sek.
  • DHCP habe ich das Gefühl könnte noch etwas zügiger sein. Teste es aber zuerst noch mit einem neueren
Client.

Ich hoffe diesmal auf dem richtigen Weg zu sein.
Was sicher noch erwähnenswert ist, dass ich den Internet Traffic in ein separates VLan legen möchte, also weg vom Default 1. Core und Router müssen ja im gleichen Subnetz sein wie jetzt im Vlan1.
Reicht es ein neues Vlan zu erstellen und die Default Route am Core und RV260 anzupassen oder gibt es eine bessere/sauberere Lösung ohne zusätzliche HW?

Besten Dank
pysesl
aqui
aqui 23.09.2021 um 23:04:25 Uhr
Goto Top
Sieht soweit alles OK aus. face-smile
pysesl
pysesl 24.09.2021 um 15:33:59 Uhr
Goto Top
Hallo aqui

Recht herzlichen Dank für deine Antwort und ist super lieb, dass du ein Auge darauf geworfen hast.
Meine natürlich nicht physisch! face-smile

Auf meine vorherige Frage bezogen, was die Spanning Tre Einstellung betrifft.
Da bin ich noch unsicher.

Im Moment ist der Core auf 4096 gesetzt.
Access Switch 01 auf 12288 gesetzt.
Access Switch 02 auf 24576 gesetzt.
Alle im (Rapid STP). Was die Standard Vorgabe von Cisco im GUI-Maske ist.

  • Kann ich das so stehen lassen, oder wäre (Multiple STP) sinnvoller?

Das zweite, wo ich anstehe und froh um deinen Ratschlag bzw. dein Wissen super wäre.
  • Namensauflösung zwischen den Subnetzen, sollte das nicht irgenwie möglich sein?

Hab's mal versucht. Hier die Ausgangslage:
Am Layer3 angeschlossen sind die beiden Geräte direkt und beziehen die IP's auch von dort.

Port 10 (NAS) IP von DHCP i.o (vlan10 => 10.26.10.0/24)
Port 15 (W7 client) IP vom DHCP i.o. (vlan20 => 10.26.20.0/24)
Client => NAS Mapping über die IP-Adresse problemlos.

Dann meine Überlegung:
Unter "UDP Relay/IP Helper" ein paar Einstellungen vorab testen.
Hier die Gehversuche:

Source IP Interface Destination IP Address
10.26.10.254 Port 137 10.26.20.255
10.26.10.254 Port 137 10.26.255.255
All Port 137 10.26.255.255

zweite Überlegung:
  • Liegt es am Port und irgenwie sollte doch der Broadcast noch durch/mit?

Leider aber geht bei mir jetzt nichts mehr, sprich kein klarer Gedanke, Hirnkino. face-sad
Wäre trotzdem super nett von dir, für eine Hilfestellung oder Meinung.
Ich weiss es wirklich zu schätzen. Danke.

pysesl
aqui
aqui 24.09.2021 aktualisiert um 16:43:38 Uhr
Goto Top
Im Moment ist der Core auf 4096 gesetzt.
Ist richtig. Der Core muss immer die höchste Prioriät haben. Diese muss nur besser sein als die Standard STP Default Prio von 32768 (kleiner = höhere Prio und immer modulo 4096)
Access Switch 01 auf 12288 gesetzt.
Das ist überflüssig und brauchst du nicht zu machen und ist auch kontraproduktiv weil man sich damt leicht verzettelt. Es reicht in einem einfachen Design wie deinem wenn man einzig nur den Core in der Prio hochsetzt. Der gibt dann damit automatisch die Root Ports vor. Alle andere Switches belasse einfach auf dem Default !
RSTP ist OK und richtig. MSTP muss man nur in heterogenen Umgebungen mit inkompatiblen Spanning Tree Protokollen machen. Ist bei dir nicht der Fall.
Namensauflösung zwischen den Subnetzen, sollte das nicht irgenwie möglich sein?
Das hat aber nichts mit der Netzwerk Infrastruktur zu tun !! Ist ne andere Baustelle und betrifft deinen lokalen DNS Server und wie du den eingerichtet hast.
Wenn du im Netz z.B. einen Pi-Hole betreibst der dir dein Netz frei von Werbung, Trojanern und anderer Malware hält kannst du dort auch lokale Hostnamen eintragen. Siehe hier.
Wie bereits gesagt: Andere Baustelle.

Was du meinst ist aber vermutlich das automatischen Naming Broadcast über UDP NetBios_Broadcasts oder mDNS, richtig ? Das scheitert natürlich, Prinzip bedingt, an Router Schnittstellen.
UDP Relay ist da schon genau der richtige Ansatz. Der Teufel lauert da aber im Detail, denn das bei vielen billigen Websmart Switches hat das einen Haken, denn das ist oft lediglich nur für UDP 67 und 68 (DHCP) und TFTP definiert. Manchmal noch für TIME. UDP 137 haben viele entfernt. Ob die SGs das noch machen müsste man mal im Handbuch recherchieren.
Die besseren Systeme haben das Kommando ip forward-protocol udp <udp_port>
https://ipwithease.com/how-to-forward-udp-broadcast-on-cisco-routers/
wo man sehr granular einstellen will was man an UDP Broadcast Ports mit der Helper Funktion in andere IP Segmente forwarden will. Müsste man mal also mal etwas genauer checken. Oder ausprobieren ?! face-wink
Source IP Interface Destination IP Address
Auch das ist erstmal richtig gedacht mit der .255 als Broadcast. Cisco will hier aber konfigtechnisch immer die Netzwerk Adresse sehen !
Zumindestens ist es so bei IOS wenn man UDP Brodcasts mit der Helper Funktion auf ganze Netze senden will. Vielleicht versuchst du es statt der .255 mal mit der .0 ?! Versuch macht klug...
Liegt es am Port und irgenwie sollte doch der Broadcast noch durch/mit?
Nimm dir immer den Wireshark Sniffer zur Hand und prüfe damit ob diese Pakete am Ziel ankommen !
pysesl
pysesl 25.09.2021 um 11:42:37 Uhr
Goto Top
Guten Tag aqui

Ein dickes Dankeschön! für deine Antworten zum Voraus.

  • Access Switch 01 auf 12288 gesetzt
Das ist überflüssig und brauchst du nicht zu machen und ist auch kontraproduktiv weil man sich damt leicht verzettelt. Es reicht in einem einfachen Design wie deinem wenn man einzig nur den Core in der Prio hochsetzt. Der gibt dann damit automatisch die Root Ports vor. Alle andere Switches belasse einfach auf dem Default ! >
RSTP ist OK und richtig. MSTP muss man nur in heterogenen Umgebungen mit inkompatiblen Spanning Tree Protokollen machen. Ist bei dir nicht der Fall. >
Mach ich, Danke für den Hinweis.
  • Namensauflösung zwischen den Subnetzen, sollte das nicht irgenwie möglich sein?
Das hat aber nichts mit der Netzwerk Infrastruktur zu tun !! Ist ne andere Baustelle und betrifft deinen lokalen DNS Server und wie du den eingerichtet hast. >
Wie du sagst. Andere Baustelle.
Was du meinst ist aber vermutlich das automatischen Naming Broadcast über UDP NetBios_Broadcasts oder mDNS, richtig ? Das scheitert natürlich, Prinzip bedingt, an Router Schnittstellen. >
Ja, richtig geraten und wie du dich schon richtig ausdrückst.
Der Teufel lauert da aber im Detail >
Einerseits das Mapping über Hostnamen statt IP's und zweitens Zeitabgleich des Netzes.
Unser NAS (Qnap TS451DeU) kann als NPT-Server aktiviert werden und sollte die Zeit im Netz bereitstellen, damit nicht alle über die öffentlichen Server eingerichtet werden müssen, was ja eine gute Sache wäre, wenn es dann das auch zuverlässig macht, ala SO HO"pe".
Zudem würde vermutlich nur der Core davon profitieren, bei den Layer 2 wäre ich nicht so sicher. Liebes OSI-Modell, würdest du, könntest du! Spass bei Seite. -face-smile
Vorgängig habe ich erstmal beim NAS auf alles aktiviert gestellt. Das heisst, vermutlich ist sicher Boadcast, Multicast und Manycast aktiv. Wie zuverlässig das Teil aber arbeitet, weiss ich noch nicht. Sehe es dann beim checken der Clients, diverser Devices und der Netzwerkkomponenten. Vielleicht lauert aber da schon wieder das kleine Teufelein.!
Websmart Switches hat das einen Haken, denn das ist oft lediglich nur für UDP 67 und 68 (DHCP) und TFTP definiert. Manchmal noch für TIME. UDP 137 haben viele entfernt. Ob die SGs das noch machen müsste man mal im Handbuch recherchieren. >
Sollte eigentlich bei den SG's zur Verfügung stehen, aber eben, es ist leider in der heutigen Zeit so, dass nicht immer alles genau so drin ist, wie draufsteht. Oder so, in etwa. Quasi.
Als ich noch den Satz von dir
Die besseren Systeme haben das Kommando ip forward-protocol udp <udp_port> >
gelesen habe, waren doch vereinzelt Erinnerungen wieder da.
Soweit ich mich erinnern kann kann, wurde der Befehl ip helper address bei uns oft zwischen den Routern verwendet mit der Zieladresse des DHCP's. Zum zweiten, wie du ja im Verlauf dieses Posts auf meine Frage der DHCP Relais Funktion geschrieben hast.
Das kann so niemals technisch funktionieren, denn die DHCP Server auf den Switches sind NICHT Multi Scope fähig wie ein zentraler DHCP Server ala Windows Server oder Linux_ISC_DHCP ! >
Ich weiss, dass es nicht dasselbe ist, meine aber damit nur. Vielleicht ist die UDP Relais Funktion der SG's anders ausgelegt bzw. in Bezug. Nur so ne Vermutung.
Auf jeden Fall versuche ich mich etwas schlau zu machen.
Dein Vorschlag mit Wireshark ist sicher der beste Weg, um mal zu schauen, wohin überhaupt die Reise dieser Pakete/Einstellung geht.
> Vielleicht versuchst du es statt der .255 mal mit der .0 ?! Versuch macht klug... >
Das ist ja schnell geklärt und wer weiss.

Ich gehe der Sache mal nach, brauche aber etwas Zeit. Ist halt bei mir jetzt so. face-sad
Auf jeden Fall, melde ich mich diesbezüglich, denn ich gehe davon aus, dass es einige Mitglieder auch noch interessieren könnte, wie sich diese Websmart Switches verhalten.

Vorab wünsche ich dir ein schönes Weekend und Danke! Und ich schätze es wirklich.
pysesl
aqui
aqui 25.09.2021 um 14:04:11 Uhr
Goto Top
kann als NPT-Server aktiviert werden
NPT ??? Was soll das sein ? Du meinst sicher NTP, oder ? NTP nutzt aber kein Broadcast, das ist komplett routebar. Das Time Protokoll was so gut wie niemand mehr verwendet nutzt Broadcast. Mit NTP bist du also immer safe !
Vielleicht ist die UDP Relais Funktion der SG's anders ausgelegt bzw. in Bezug. Nur so ne Vermutung.
Nope die funktioniert wie der Standard weltweit immer gleich. Spannend ist immer nur WELCHE UDP Ports die Hersteller mit der Relay/Helper Funktion forwarden. Nur da scheiden sich die Geister... face-wink
pysesl
pysesl 25.09.2021 um 18:10:31 Uhr
Goto Top
NPT ??? Was soll das sein ? Du meinst sicher NTP, oder ? NTP nutzt aber kein Broadcast, das ist komplett routebar. Das Time Protokoll was so gut wie niemand mehr verwendet nutzt Broadcast. Mit NTP bist du also immer safe ! >
Klar, NTP, Sorry. Hab Time und Protokoll richtig im Kopf, aber BS vertauscht. So eine Eigenart die sich eingeschlichen hat, wenn ich Abkürzungen schreibe. Es kamen schon wirklich kuglige Buchstabenfolgen zustande. face-smile
Nope die funktioniert wie der Standard weltweit immer gleich. Spannend ist immer nur WELCHE UDP Ports die Hersteller mit der Relay/Helper Funktion forwarden. Nur da scheiden sich die Geister.. >
Ich mache mich auf jeden Fall diesbezüglich mal schlau und melde mich wieder.
Jetzt noch auf Schweizerdeutsch ohen Abkürzungen. Gemerkt, natürlich "ohne"
Heb es schöns Weekend met emene gruess us CH, Danke.