[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  + .141
    
    

    Alle 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 Betriebssystem

    Ziel 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/24
    
    

    Firewall-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 -verbose
    
    

    Auch 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 oben

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

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



  • @-flo-:

    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.

    @-flo-:

    Und warum soll das zwischen getrennten Netzwerken erfolgen?

    Weil sich der WDS in einem Netz und die zu installierenden PCs in anderen Netzwerken befinden.

    @-flo-:

    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??? 😮 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 min

    Dabei wurden alle Clients gleichzeitig gestartet.

    Vielen Dank an flo!



  • Schön wenn es funktioniert!


  • Moderator

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



  • @JeGr:

    … 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:

    @JeGr:

    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.



  • @-flo-:

    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.

    99packets.pcapng



  • 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                      : False

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


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy