Windows routing table en multicast vraagje

[Tom970G1]

Hallo mensen,

Ik zoek een manier om al het verkeer naar een bepaald multicast-adres ook naar een ander LAN te leiden.
Ik heb 2 netwerkinterfaces, verbonden met verschillende LAN's.
Ik heb onderstaande regels toegevoegd aan mijn routing table:
route -p add 236.99.250.123 MASK 255.255.0.0 172.16.19.254 -> clients in dit netwerk hebben ip 172.16.23.x
route -p add 236.99.250.123 MASK 255.255.0.0 192.168.127.1 -> clients in dit netwerk hebben ip 192.168.137.x

Het multicast-adres is 236.99.250.123.

Klopt het dat mijn machine nu zal fungeren als een doorstuurserver voor alle multicast-berichten naar 236.99.250.123? Dus als ik vanuit LAN1 een bericht naar dit adres stuur, kan ik hetzelfde bericht zien in LAN2?

Bij voorbaat bedankt!

Tom

[Ruben279]

Dat lijkt wel goed.
Je zou even met Wireshark een capture kunnen maken, kijken of het goed gaat

Met Mping kan je multicast packets sturen om het te testen.

[MasterL]

Multicast routing is niet echt mijn specialiteit, is ook een "vak" apart maar ik kan mij niet voorstellen dat bovenstaande werkt.. Wat je nu eigenlijk hebt geconfigureerd is:
Al het verkeer vanaf de machine naar 236.99.0.0/16 (mask 255.255.0.0) wordt gerouteerd naar gateway 172.16.19.254 of 192.168.127.1 (zelfde metric?).

Voor multicast scenarios gebruik je normaal gesproken protocol independent multicast (PIM) of een IGMP proxy, de laatste zie je bijvoorbeeld vaak in IPTV configuraties.

[Tom970G1]

MasterL schreef op dinsdag 23 mei 2023 @ 10:46:
Multicast routing is niet echt mijn specialiteit, is ook een "vak" apart maar ik kan mij niet voorstellen dat bovenstaande werkt.. Wat je nu eigenlijk hebt geconfigureerd is:
Al het verkeer vanaf de machine naar 236.99.0.0/16 (mask 255.255.0.0) wordt gerouteerd naar gateway 172.16.19.254 of 192.168.127.1 (zelfde metric?).

Voor multicast scenarios gebruik je normaal gesproken protocol independent multicast (PIM) of een IGMP proxy, de laatste zie je bijvoorbeeld vaak in IPTV configuraties.

Thx voor de reactie.
Dit is het command syntax: route add destination_network MASK subnet_mask gateway_ip metric_cost

Destination_network is in mijn optiek waar het initiële bericht aan gericht is toch?
ik heb het overigens hier vandaan.

https://www.howtogeek.com...0added%20to%20the%20table.

[MasterL]

Tom970G1 schreef op dinsdag 23 mei 2023 @ 14:22:
[...]


Thx voor de reactie.
Dit is het command syntax: route add destination_network MASK subnet_mask gateway_ip metric_cost

Destination_network is in mijn optiek waar het initiële bericht aan gericht is toch?
ik heb het overigens hier vandaan.

https://www.howtogeek.com...0added%20to%20the%20table.

Ja zoiets dacht ik al maar dit gaat over unicast routing.
Het artikel is niet "fout" maar gewoon niet van toepassing op jouw situatie. Zelfs in een unicast situatie een route aanmaken op een "willekeurige machine" (lees geen "gateway) doet helemaal niks behalve voor de lokale machine. Voordat deze regels "nut" hebben moet je zeker weten dat het verkeer daadwerklijk "door" de machine heen loopt. Voor unicast is dat: Je moet dan een "gateway" zijn, door multicast moet je een "member" zijn. Van wat ik nu kan bepalen ben je geen van beide.

Zou je misschien iets meer info kunnen geven over het doel en de de aanwezige hardware?
Hoe dan ook lijkt hij mij niet handig om wat voor routing (unicast/multicast) te doen op een Windows workstation.

[ Voor 11% gewijzigd door MasterL op 23-05-2023 14:32 ]

[Tom970G1]

MasterL schreef op dinsdag 23 mei 2023 @ 14:30:
[...]


Ja zoiets dacht ik al maar dit gaat over unicast routing.
Het artikel is niet "fout" maar gewoon niet van toepassing op jouw situatie. Zelfs in een unicast situatie een route aanmaken op een "willekeurige machine" (lees geen "gateway) doet helemaal niks behalve voor de lokale machine. Voordat deze regels "nut" hebben moet je zeker weten dat het verkeer daadwerklijk "door" de machine heen loopt. Voor unicast is dat: Je moet dan een "gateway" zijn, door multicast moet je een "member" zijn. Van wat ik nu kan bepalen ben je geen van beide.

Zou je misschien iets meer info kunnen geven over het doel en de de aanwezige hardware?
Hoe dan ook lijkt hij mij niet handig om wat voor routing (unicast/multicast) te doen op een Windows workstation.

Doel:

Wij zijn actief met ons product bij bedrijven waar ze vaak het beheer van verschillende VLAN's bij verschillende partijen hebben liggen. Hierdoor kan onze vaste apparatuur niet communiceren (over multicast specifiek) met onze draadloze apparatuur, omdat dit door 2 aparte switches heen gaat. De netwerk partijen vinden het ontzettend moeilijk om dit voor elkaar te krijgen. Nou heb ik op Debian een geweldig tooltje gevonden genaamd SMCRoute. dit doet precies wat ik hier probeer; hij pakt een multicast bericht van WLAN en gooit hem door naar LAN. Wel met zijn IP als afzender, maar dat is voor ons niet relevant. Hij doet ook vice versa. Dit werkt prachtig, maar voor beheer e.d. willen we deze functie eigenlijk in onze windows server verwerken en niet op een random Raspberry Pi'tje ofzo. Echter krijg ik het op W11Pro niet zo laagdrempelig werkend als op Debian. Ik wil ook liever niet onnodig VM's opzetten.

[ Voor 36% gewijzigd door Tom970G1 op 23-05-2023 16:17 ]

[MasterL]

Hoezo is dit "ontzettend moeilijk"? Ik kan mij er iets bij voorstellen maar ik neem aan dat jij/jullie apparatuur op locatie hebben staan toch? Een (virtual) interface in elk l2 domain zou toch voldoende moeten zijn? wat is daar moeilijk aan?

[Tom970G1]

MasterL schreef op dinsdag 23 mei 2023 @ 16:32:
Hoezo is dit "ontzettend moeilijk"? Ik kan mij er iets bij voorstellen maar ik neem aan dat jij/jullie apparatuur op locatie hebben staan toch? Een (virtual) interface in elk l2 domain zou toch voldoende moeten zijn? wat is daar moeilijk aan?

die virtual interface zou dan op al onze vaste apparatuur moeten zitten, terwijl met deze forwarding optie alleen de server op beide interfaces hoeft te zitten, niet eens virtual. Ook gemakkelijker implementeren, of heb ik het daar verkeerd?

[MasterL]

Oke ja en nee, maar zou het niet veel werkbaarder zijn om alle apparatuur of in ieder geval de apparaten die multicast moeten communiceren in één VLAN te hebben?

Ik ken jouw/jullie applicatie natuurlijk niet maar stel:
* één VLAN/poort etc waarin al "jullie" apparatuur zit.
* Voor eventueel "normaal" unicast verkeer met andere netwerken/WAN > routing/firewalling (inter-vlan).
* Wired: Tagged in apparatuur en indien niet mogelijk op untagged poort.
* Voor wireless > apart SSID in hetzelfde VLAN, eigenlijk zelfde verhaal als wired.

Ik snap dat dit wat werk is maar moeilijk is het zeer zeker niet.
Nogmaals ik ken jullie applicatie niet en/of kan niet inschatten hoe mission critical deze is maar ik persoonlijk zou z'n setup niet willen supporten. Ik heb zo 1,2,3 geen Windows tool kunnen vinden die dit doet. Misschien heeft iemand anders een idee hoe je multicast route in Windows.

[mash_man02]

MasterL heeft hier wel een punt, het lijkt er op dat je een workaround zoekt waamee de uiteindelijke oplossing minder logisch is dan velen zouden verwachten, multicast verkeer gaat een ander pad bewandelen dan je Unicast verkeer.

Je krijgt daarmee ook andere beschikbaarheden, storings symptomen en ga zo maar door.

Multicast is niet heel moeilijk zolang de support in de gebruikte apparatuur maar op orde is.

[Tom970G1]

mash_man02 schreef op vrijdag 26 mei 2023 @ 09:13:
MasterL heeft hier wel een punt, het lijkt er op dat je een workaround zoekt waamee de uiteindelijke oplossing minder logisch is dan velen zouden verwachten, multicast verkeer gaat een ander pad bewandelen dan je Unicast verkeer.

Je krijgt daarmee ook andere beschikbaarheden, storings symptomen en ga zo maar door.

Multicast is niet heel moeilijk zolang de support in de gebruikte apparatuur maar op orde is.

Wij hebben alleen het VLAN van onze apparatuur in beheer, niet die van de wireless omgeving. Dus de access points zitten op een ander VLAN dan onze wired apparatuur. Wij bepalen niet welke netwerkpartij er bij de klant zit, en we willen niet onze apparatuur bij tig verschillende partijen in beheer laten nemen. Dus daarom zitten we hier wat in de knoop. Ook vragen veel netwerkpartijen veel centjes voor het beheer wat er nauwelijks is in onze omgeving.

[ Voor 17% gewijzigd door Tom970G1 op 26-05-2023 09:35 ]

[mash_man02]

Tom970G1 schreef op vrijdag 26 mei 2023 @ 09:34:
[...]

Wij hebben alleen het VLAN van onze apparatuur in beheer, niet die van de wireless omgeving. Dus de access points zitten op een ander VLAN dan onze wired apparatuur. Wij bepalen niet welke netwerkpartij er bij de klant zit, en we willen niet onze apparatuur bij tig verschillende partijen in beheer laten nemen. Dus daarom zitten we hier wat in de knoop. Ook vragen veel netwerkpartijen veel centjes voor het beheer wat er nauwelijks is in onze omgeving.

Dat begrijp ik prima, maar iedereen dan maar zijn eigen work around per applicatie laten bedenken en implementeren brengt weer een volledige set met andere uitdagingen.

Je voorstel is i.i.g. in mijn ogen geen oplossing voor de oorzaak, maar een work around voor het gevolg.

Begrijp hierin bijvoorbeeld ook dat multihomed systemen een attack surface vergroten waarmee veiligheid met vele systemen waarin dat toegestaan wordt niet meer te handhaven is.

[ Voor 9% gewijzigd door mash_man02 op 26-05-2023 09:44 ]

[laurens0619]

Is het niet mogelijk je applicatie middels unicast te laten communiceren en zorgen dat netwerk partij van de klant de routering hierop inricht?

Netwerkbeheerders van bedrijven zijn vaak voorzichtig met multicast en het is vooral cross subnets gedoe.

Begrijp ik het goed dat je nu een server hebt die met een pootje in jullie eigen vlan zit maar ook met een pootje in het Wifi lan?
Als die 2 netwerken doelbewust van elkaar gesegmenteerd zijn dan zou ik die niet zelf aan elkaar knopen maar bij de klant/leverancier de routering aanvragen. Als die routering op unicast kan dan is het geheel waarschijnlijk een stuk minder complex.

[mash_man02]

Hou je er ook rekening mee dat multicasting zonder IGMP snooping schaal beperkingen kent vanwege het feit dat dit CPU driven over alle poorten van het broadcast domein geflood gaan worden los van of dit nodig is ?

Dit is tevens de rede dat netwerk beheerders terecht terughoudend zijn.

Het "gemakkelijke" alternatief is IGMP snooping maar dat betekend dat je systeem de group ook zou moeten joinen wat over meerdere switches alleen gaat werken als er een Mrouter geleerd kan worden in het vlan om de toplologie en daarmee uplink voor IGMP requesten te genereren. Er zijn ook switch vendoren die dit kunnen spoofen middels een proxy functie in een vlan.

[MasterL]

Tom970G1 schreef op vrijdag 26 mei 2023 @ 09:34:
[...]

Wij hebben alleen het VLAN van onze apparatuur in beheer, niet die van de wireless omgeving. Dus de access points zitten op een ander VLAN dan onze wired apparatuur. Wij bepalen niet welke netwerkpartij er bij de klant zit, en we willen niet onze apparatuur bij tig verschillende partijen in beheer laten nemen. Dus daarom zitten we hier wat in de knoop. Ook vragen veel netwerkpartijen veel centjes voor het beheer wat er nauwelijks is in onze omgeving.

Het is helemaal niet zo raar om "eisen" te stellen aan een omgeving wanneer je iets implementeert.
Kijk bijvoorbeeld naar VOIP, deze zitten in de praktijk erg vaak in aparte VLANS vaak met QOS settings en soms zelfs op compleet gescheiden (layer1) infrastructuur.
Het siert je dat je wil meedenken/kosten wil besparen voor jouw klanten maar als je dat echt wil doen
zie de tip van @laurens0619, dus exit multicast. Wil de klant alles in 1 (VLAN)? Prima, wil de klant segregeren en de boel in aparte VLANS plaatsen? Ook prima.
Nu ik erover nadenk.. Waarom doe je dat nu niet eigenlijk? Waarom die twee interfaces?

[Kabouterplop01]

Tom970G1 schreef op maandag 22 mei 2023 @ 17:19:

Het multicast-adres is 236.99.250.123.

Klopt het dat mijn machine nu zal fungeren als een doorstuurserver voor alle multicast-berichten naar 236.99.250.123? Dus als ik vanuit LAN1 een bericht naar dit adres stuur, kan ik hetzelfde bericht zien in LAN2?


Tom

Neen, deze aanname klopt niet.
Alleen voor de machine waar je de routering op zet geldt je configuratie nu.

Als je deze configuratie bijvoorbeeld op je router zou zetten zou dat voor AL je LAN verkeer gelden.
normaliter werkt een router met een default route en dat is al het verkeer wat niet bestemd is voor hetzelfde subnet, wordt naar de default gateway van dat subnet gestuurd.

Zoals je de config nu hebt op je "doorstuurserver" zal er niets gebeuren, immers (met de info die je hebt gegeven) bestaat er geen relatie met je multicastadres en wordt je verkeer in de bittenbak gegooid (oftewel je verkeer wordt gedropped.)

[Tom970G1]

laurens0619 schreef op vrijdag 26 mei 2023 @ 09:52:
Is het niet mogelijk je applicatie middels unicast te laten communiceren en zorgen dat netwerk partij van de klant de routering hierop inricht?

Netwerkbeheerders van bedrijven zijn vaak voorzichtig met multicast en het is vooral cross subnets gedoe.

Begrijp ik het goed dat je nu een server hebt die met een pootje in jullie eigen vlan zit maar ook met een pootje in het Wifi lan?
Als die 2 netwerken doelbewust van elkaar gesegmenteerd zijn dan zou ik die niet zelf aan elkaar knopen maar bij de klant/leverancier de routering aanvragen. Als die routering op unicast kan dan is het geheel waarschijnlijk een stuk minder complex.

Die 2 zijn via unicast gewoon voor elkaar bereikbaar. Alleen lukt het de meerderheid van de partijen niet om multicast over vlan's te routeren zonder een duur beheer contract op ons vlan te eisen.

[Tom970G1]

MasterL schreef op vrijdag 26 mei 2023 @ 11:43:
[...]


Het is helemaal niet zo raar om "eisen" te stellen aan een omgeving wanneer je iets implementeert.
Kijk bijvoorbeeld naar VOIP, deze zitten in de praktijk erg vaak in aparte VLANS vaak met QOS settings en soms zelfs op compleet gescheiden (layer1) infrastructuur.
Het siert je dat je wil meedenken/kosten wil besparen voor jouw klanten maar als je dat echt wil doen
zie de tip van @laurens0619, dus exit multicast. Wil de klant alles in 1 (VLAN)? Prima, wil de klant segregeren en de boel in aparte VLANS plaatsen? Ook prima.
Nu ik erover nadenk.. Waarom doe je dat nu niet eigenlijk? Waarom die twee interfaces?

Copy. Workaround geschrapt. We zullen de eisen die we aan het netwerk stellen aanpassen.

Thanks all

[laurens0619]

Tom970G1 schreef op vrijdag 26 mei 2023 @ 12:44:
[...]

Die 2 zijn via unicast gewoon voor elkaar bereikbaar. Alleen lukt het de meerderheid van de partijen niet om multicast over vlan's te routeren zonder een duur beheer contract op ons vlan te eisen.

nou mooi toch? Waarom niet ombouwen naar unicast? Auto discovery?

[Tom970G1]

laurens0619 schreef op vrijdag 26 mei 2023 @ 12:57:
[...]

nou mooi toch? Waarom niet ombouwen naar unicast? Auto discovery?

werkt auto discovery ook niet via multicast dan?

[laurens0619]

Tom970G1 schreef op vrijdag 26 mei 2023 @ 13:45:
[...]

werkt auto discovery ook niet via multicast dan?

Sorry ik bedoelde het anders
Wat is de reden dat je multicast wilt? Wellicht autidoscovery?

Zonder multicast is dat lastig ja, maar is dat heel
Erg als je een ip of hostnamr moet invoeren?

Aurodiscovery vind ik meer iets voor consumentenomgevingen (ivm multicast)

[Tom970G1]

Standaard situatie:

centrale server
30 apparaatjes (gateways genaamd)

De gateways werken op DHCP en dat willen we graag zo houden. Via multicast zegt gateway 1: EVENT X.
Vervolgens weet gateway 2 dat hij ACTION Z moet uitvoeren aan de hand van de configuratie. Deze events delen wij over multicast. Maar ook communicatie van de smartphone app naar de gateways gaat dus over multicast. En daar ontstaat zhe problem.

[laurens0619]

Kun je die niet de communicatie tussen de server en de gateways laten doen (middels multicast) en dan via unicast vanaf de server naar de smartphone app?

Of staat die server niet in datzelfde netwerk.

Afijn is beetje gissen zo maar als je dit bij grotere bedrijven zou willen uitrollen zou ik wel goed nadenken over deze architectuur keuzes mbt multicast cross segment