[Gelöst] Regeln für Multicast und IGMP Relay
-
Hallo,
nach zwei Tagen Suchen im Internet und erfolglosem Ausprobieren hoffe ich hier Hilfe zu finden.
Folgendes ist ein Teil meiner Konfiguration:
.-----+-----. LAN1 WDS | pfSense +----------------------------+ '-----+-----' .1 192.168.2.0/24 .10 |.1 | | LAN2 192.168.0.0/24 | PC1 + .140 | PC2 + .141Alle drei Computer sind virtuelle Maschinen in Hyper-V und sind dort mit je einem privaten Switch (LAN1, LAN2) verbunden.
pfSense 192.168.0.1 und 192.168.2.1 Version 2.4.1-RELEASE
WDS 192.168.2.10 Windows Server 2016 Eval. mit den Rollen DHCP-Server und Windows-Bereitstellungsdienste
PC1 192.168.0.140 (dyn.) Windows 10 bzw. ohne Betriebssystem
PC2 192.168.0.141 (dyn.) Windows 10 bzw. ohne BetriebssystemZiel ist eine Multicastübertragung des Windows 10-Images.
Auf pfSense ist in diesem Zusammenhang folgendes konfiguriert:
IGMP Proxy
LAN1 upstream 192.168.2.0/24, 224.0.0.0/4 LAN2 downstream 192.168.0.0/24Firewall-Regeln
LAN1 Protocol Source Port Destination Port * * * LAN1 Address 80 IPv4 * LAN1 net * * * (IP Options erlaubt) IPv6 * LAN1 net * * * LAN2 Protocol Source Port Destination Port IPv4 UDP * * 239.2.3.9 1234 IPv4 * * * * * (IP Options erlaubt) IPv4+6 * * * WDS *Ergebnis ist, dass keine Multicastübertragung stattfindet. Das Windows-Image wird per Unicast ausgerollt.
Zum Testen habe ich mir SimpleMulticastAnalyzer heruntergeladen und folgendermaßen gestartet:
WDS: simplemulticastanalyzer -sender -dest-ip="239.2.3.9" -dest-port=1234 -verbose PC1: simplemulticastanalyzer -receiver -dest-ip="239.2.3.9" -dest-port=1234 -verboseAuch hier werden keine Pakete empfangen.
Im Protokoll der Firewall (Status, System Logs, Firewall) sehe ich keine blockierten Pakete, die mit der Multicastübertragung im Zusammenhang stehen.
Wireshark auf WDS zeigt
6 UDP-Pakete 142 Byte 192.168.2.10 -> 239.2.3.6
2 IGMPv3-Pakete 192.168.2.1 -> 224.0.0.2 Membership Report / Join group 239.2.3.9 for any service
danach nur noch UDP-Pakete wie obenWireshark auf PC1 zeigt
1 IGMPv3-Paket 192.168.0.1 -> 224.0.0.2 Membership Report group 224.0.0.2
2 IGMPv3-Pakete 192.168.0.140 -> 239.2.3.9 Membership Report group 239.2.3.9Diese Ergebnisse sind beim Testen mit dem SimpleMulticastAnalyzer entstanden.
Was mache ich falsch?
-
Erstmal eine Verständnisfrage: Warum muß überhaupt ein Windows-Image per Multicast übertragen werden? Und warum soll das zwischen getrennten Netzwerken erfolgen? Macht Windows das zufällig basierend auf mDNS / Zeroconf?
Die Wireshark-Auswertung sieht gar nicht schlecht aus. IGMP scheint zu funktionieren. Du kannst noch Traffic auf der pfSense aufzeichnen und das mit Wireshark auswerten. Dann siehst Du auch diese Seite.
-
Warum muß überhaupt ein Windows-Image per Multicast übertragen werden?
Na, damit bei x zu installierenden Computern das Image nicht x Mal über das Netzwerk übertragen werden muss. Also aus Geschwindigkeitsgründen.
Und warum soll das zwischen getrennten Netzwerken erfolgen?
Weil sich der WDS in einem Netz und die zu installierenden PCs in anderen Netzwerken befinden.
Macht Windows das zufällig basierend auf mDNS / Zeroconf?
Nein, wieso zufällig. Das wäre ja Chaos! (Obwohl ich mir bei Windows manchmal nicht ganz sicher bin, ob die Programmierer bei Microsoft verstehen, was sie tun.)
Auf dem WDS wird eine Multicastübertragung eingerichtet. Nachdem die zu installierenden Computer ihre IP-Konfiguration bekommen haben, sollen sie das Windows Image per Multicast herunterladen und installieren.
-
Mach Dir mal Floating-Regeln wie folgt:
Protocol Source Port Destination Port IPv4 UDP * * 224.0.0.0/4 * IPv4 IGMP * * 224.0.0.0/4 *Mit "quick"-Option und "options allowed".
Ich kenne kein Setup bisher, wo der IGMP-Proxy nicht auf ein WAN-Interface zeigt. Andererseits wüßte ich nicht, warum es nicht gehen sollte.
Ob diese Art der Software-Distribution besonders sinnig ist, wage ich dennoch zu bezweifeln. Bei Multicast wird ein verlorenes Paket nicht neu gesendet (wegen UDP). Das ist ok für IPTV und VoIP, aber nicht für eine Software-Verteilung. (Ok, vielleicht kommt es bei Windows nicht so drauf an. 8)) Und dann müssen alle Empfänger ihre Installation gleichzeitig durchführen. Wenn einer der Clients abkachelt oder das Netz nur kurz weg ist, dann hat er halt die Software nicht. Jetzt kann der WDS natürlich das Image im Stundentakt ausstrahlen oder gleich das Netz kontinuierlich fluten, aber ob das besser ist als ein simpler Download mit z.B. tftp (also TCP)? Und das Ganze bei lumpigen 2 PCs, die zu installieren sind??? :o Ist das evtl. ein Labor-Setup?
-
So, nun hab ich es. Der Tipp mit den beiden floating rules war gut, aber noch nicht ausreichend. Es mussten noch ein paar mehr Ports geöffnet werden.
Hier ein Zusammenfassung:
Auf der Schnittstelle, an die die WDS-Clients angeschlossen sind, sind folgende Regeln nötig:
IPv4 UDP any -> 224.0.0.0/4 mit IP-Optionen
IPv4 IGMP any -> 224.0.0.0/4 mit IP-Optionen
IPv4 UDP any -> WDS:4011
IPv4 UDP amy -> WDS:69
IPv4 TCP any -> WDS:135
IPv4 TCP any -> WDS:5040
IPv4 UDP any -> WDS:61000-65000 (muss auch im WDS konfiguriert werden)Damit (und den in den anderen Posts vorgenommenen Einstellungen) gelingt die Multicast-Übertragung. Aber sie bringt überhaupt keinen Zeitvorteil, obwohl das Image nur einmal übertragen werden muss! Ursache ist, dass bei UDP die Pakete nur 1500 Byte groß sind. Bei TCP werden dagegen bis zu 65 KB große Pakete gesendet. Damit ist der Protokolloverhead bei TCP deutlich geringer als bei UDP. Während die Multicastübertragung des Windows 10 Abbildes ca. 15 Minuten dauert und dann muss es auf den Clients erst ausgepackt werden, dauert die Übertragung mit TCP im Unicastverfahren nur 2 Minuten bei zwei Clients. Getestet in einer Hyper-V-Umgebung, bei der 10 Gbit/s-Netzwerkkarten emuliert werden. Die Anzahl der Clients verhält sich übrigens nicht linear zur Übertragungsdauer:
1 Client: < 2 min
2 Clients: > 2 min
3 Clients: > 3 minDabei wurden alle Clients gleichzeitig gestartet.
Vielen Dank an flo!
-
Schön wenn es funktioniert!
-
@u1: Was ich mich von WDS Präsentationen noch erinnern kann ist, dass beim Streaming im Multicast Modus die Clients das Image nicht alle gleichzeitig bekommen, sondern jeder Client sich per Multicast in den Stream einklinkt und der Server den Kram eben so lange endlos wiederholt (Image streamt immer und immer wieder), bis es jeder quittiert hat. Daher ist wohl eher der Zeitunterschied in deinem Test zu resultieren, dass der zweite und ggf. dritte Client sich eben nicht exakt zeitgleich mit Client 1 in den Stream einhängen können und damit warten müssen, bis der Stream durch ist (3-4min) und dann bekommen sie ihr Abbild im zweiten oder dümmsten Fall dritten durchrutsch.
Das mit den Paketen kann ich aber nicht ganz glauben ;) denn die MTU von 1500 bleibt auf Layer 2 und gilt damit für jedes Protokoll, egal ob TCP oder UDP. Package Size bleibt Package Size und solange du keine Jumbo Frames von 9000 auf deinem Switch konfiguriert hast, bleibt ein TCP oder UDP Package maximal 1500 Byte groß :)
-
Ah, interessant. Der Mechanismus erlaubt ungefähr zeitgleiche Installationen für mehrere Clients in annähernd konstanter Zeit – also unabhängig von der Zahl der Clients. Das wird bei einer Messung mit zwei oder drei Clients wahrscheinlich nicht sichtbar, bei 10 Clients dürfte das aber nicht viel länger dauern als mit drei. Und bei 100 Clients auch nicht, aber es spart dann erheblich Netzwerklast ein.
-
… dass beim Streaming im Multicast Modus die Clients das Image nicht alle gleichzeitig bekommen...
Das wäre die Standardeinstellung einer Multicastübertragung. Die lässt sich aber ändern:
Das mit den Paketen kann ich aber nicht ganz glauben ;)
Ursache scheint TCP segmentation offload zu sein. Wireshark zeigt mir TCP-Pakete mit 62.384 Byte Länge an und kennzeichnet sie als TCP segment of a reassembled PDU. Die Länge des IP-Datagramms beträgt 62.820 Byte, allerdings vermerkt Wireshark dazu: reported as 0, prsumed to because of "TCP segmantation offload" (TSO). Die Framelänge beträgt 62.834 Byte.
-
Der Mechanismus erlaubt ungefähr zeitgleiche Installationen für mehrere Clients in annähernd konstanter Zeit – also unabhängig von der Zahl der Clients.
Ich schätze (das in einem Test zu verifizieren ist mir zu aufwändig), dass sich der Geschwindigkeitsvorteil erst ab etwa 20 bis 30 Clients bemerkbar macht. Darunter dürfte es eher ein Geschwindigkeitsnachteil sein.
-
Das würde mich wundern wenn tcp schneller wäre.
Wie schon geschrieben wurde , kann ein Paket unfragmentiert nicht größer werden als 1500 Byte (vergessen wir mal Jumbo Franes)Zudem hat tcp einiges an Protokoll Overhread durch die ACK Pakete
-
Ich habe mal 99 Pakete aus Wireshark exportiert, die den SMB-Verkehr zwischen dem WDS-Server (hier 192.168.2.10) und zwei Clients (192.168.0.100 und 192.168.0.101) enthalten. Insgesamt habe ich etwa eine Minute aufgezeichnet, das sind etwas mehr als 1 GB, deutlich zu groß für diese Forum.
Vielleicht kann ja ein Experte Aufklärung liefern.
-
Das sieht interessant aus. Ich würde mal im Hyper-V in die Einstellungen der Netzwerk-Adapter schauen.
-
Hab ich geschaut. Und nun?
<glaskugel an="">Ich vermute, du möchtest die Einstellungen der Netzwerkadapter wissen.
<glaskugel aus="">```PS C:\WINDOWS\system32> Get-VMNetworkAdapter -VM $VM | Format-List -Property *
VMCheckpointId : 00000000-0000-0000-0000-000000000000
VMCheckpointName :
ClusterMonitored : True
MacAddress : 00155D09C80B
DynamicMacAddressEnabled : True
AllowPacketDirect : False
IsLegacy : False
IsSynthetic : True
IPAddresses : {}
DeviceNaming : Off
IovWeight : 0
IovQueuePairsRequested : 1
IovInterruptModeration : Default
PacketDirectNumProcs : 0
PacketDirectModerationCount : 64
PacketDirectModerationInterval : 1000000
IovQueuePairsAssigned : 0
IovUsage : 0
VirtualFunction :
MandatoryFeatureId : {}
MandatoryFeatureName : {}
PoolName :
Connected : True
SwitchName : Büro
AdapterId :
TestReplicaPoolName :
TestReplicaSwitchName :
StatusDescription :
Status :
IsManagementOs : False
IsExternalAdapter : False
Id : Microsoft:6F06FC55-3E67-4CF7-A0F4-958C2A027645\D876E580-C712-4518-8E2B-63258D012432
SwitchId : a9982010-820a-4b19-9025-a068b71f2d21
AclList : {}
ExtendedAclList : {}
IsolationSetting : VMNetworkAdapterIsolationSetting
RoutingDomainList : {}
VlanSetting : VMNetworkAdapterVlanSetting
BandwidthSetting :
CurrentIsolationMode : Vlan
MacAddressSpoofing : Off
DhcpGuard : Off
RouterGuard : Off
PortMirroringMode : None
IeeePriorityTag : Off
VirtualSubnetId : 0
DynamicIPAddressLimit : 0
StormLimit : 0
AllowTeaming : Off
FixSpeed10G : Off
VMQWeight : 100
IPsecOffloadMaxSA : 512
VrssEnabled : True
VrssEnabledRequested : True
VmmqEnabled : False
VmmqEnabledRequested : False
VmmqQueuePairs : 0
VmmqQueuePairsRequested : 16
VmqUsage : 0
IPsecOffloadSAUsage : 0
VFDataPathActive : False
VMQueue :
BandwidthPercentage : 0
IsTemplate : False
Name : Netzwerkkarte
VMId : 6f06fc55-3e67-4cf7-a0f4-958c2a027645
VMName : xxx
VMSnapshotId : 00000000-0000-0000-0000-000000000000
VMSnapshotName :
CimSession : CimSession: .
ComputerName : xxx
IsDeleted : FalseDas sind die Einstellungen des WDS-Server und der Clients. Es ist also alles auf den Standardeinstellungen. Die VM "pfSense" hat sogar Legacy-Adapter. Falls mich meine Glaskugel getäuscht hat präzisiere bitte deine Anfrage.</glaskugel></glaskugel> -
Offen gestanden kann ich auch nur raten. In Deinem Trace sind tatsächlich sehr große Frames. Das geht nur, wenn alle Komponenten mitmachen, also insb. alle (virtuellen) Netzwerkadapter. Ich kenne mich mit Hyper-V aber auch nicht aus.
Von so großen Frames habe ich auch noch nie gehört, aber TCP erlaubt m.W. ein theoretisches Maximum von 64K.
