collegare più router in parallelo

r-mario92

Mi sembra che ti serva uno switch, non un altro router - i router si usano appunto quando si hanno sottoreti diverse e occorre farle comunicare fra di loro.

Se i PLC sono configurati per usare DHCP e ci dipende l'intero processo dell'azienda non mi affiderei al server DHCP di un Fritz o altro router consumer. Ci sono switch [smart] managed che hanno anche un server DHCP.

Comunque se metti tutti i dispositivi nella stessa subnet, e hai due server DHCP nella subnet (che offrono range separati), i dispositivi prenderanno l'IP del server che risponde per primo, non puoi decidere tu facilmente da quale server ottenere l'IP - specialmente con server DHCP non configurabili come quelli di router consumer. Comunque finché hanno un IP valido per la sottorete funzioneranno.

Se vuoi soluzioni fault-tolerant è possibile avere server DHCP in cluster/failover - si può fare con un paio di serverini Linux.

r-mario92 Il tutto vorrei farlo sullo stesso livello IP, per intenderci allo stesso indirizzo 192.168.1 e ad ogni router assegnare un diverso intervallo di IP (così da non mandarli in conflitto nell'assegnazione degli indirizzi ai vari dispositivi)

E qual è il senso o la ragione di questi vincoli?

r-mario92 in caso di caduta del fritz i plc rimarranno sconnessi

Non mi è chiaro cosa scrivi: se la subnet è la stessa per tutti i PLC, cosa gliene importa del Fritz?

r-mario92 ma non ha più senso, anche per una questione di sicurezza, prendere un router decente che gestisca il tutto, tenere separati PLC e altri dispositivi in 2 vlan distinte, e magari eliminare anche il router Tim (se contrattualmente si può fare)?

Un velocissimo spunto relativo all'alta disponibilità a livello di gateway, che ho citato prima.
Ti riporto un'immagine per darti un'idea:

I dispositivi in alto sono firewall della Sophos (nel tuo caso ovviamente non sono necessari quei modelli, punterei verso l'XGS87 o simili).

Detto ciò un'infrastruttura del genere deve essere un minimo giustificata, perché il costo di questi dispositivi, più il cablaggio, più la necessità di avere due connessioni ad Internet (preferibilmente con due provider diversi) non sono da poco. Se in azienda potete accettare un disservizio temporaneo che richieda intervento manuale allora non m'inoltrerei nel mondo dell'alta disponibilità sia per i costi che per il tempo richiesti

Suxsem Ciò ti permette di raggiungere i PLC anche dall'esterno configurando il port forwarding sul tim hub (al fritzbox), sul fritzbox (al tplink) e sul tplink, MA NON LO FAREI IN ALCUN CASO in quanto stai esponendo i PLC all'esterno! Il tplink ha un buon supporto VPN, mi configurerei quella per raggiungere i PLC da casa.

Ammettendo per ipotesi che lo voglia fare ("esporre" su Internet i PLC), invece del port forwarding non potrebbe semplicemente mettere una /22 come netmask per tutti e quindi con un unico dominio di broadcast far lavorare ARP per il discovery?

mark129 sono piuttosto convinto che non funzionerebbe a causa del nat, ma ci penso meglio!

r-mario92 Quindi, se ho capito bene, configurando un ip statico nelle impostazioni dei PLC, essi continueranno a comunicare tra loro anche senza router, ma solamente se collegati ad uno switch?

Con un IP statico non avranno bisogno di DHCP. Se usare DHCP o meno è una tua scelta. Comunque finché c'è almeno un server DHCP che funziona sulla rete, i dispositivi saranno in grado di ottenere un indirizzo IP, il problema è se non ci sono server funzionanti perché allo scadere del lease potrebbero non funzionare più.

Ovviamente perché i dispositivi si parlino fra loro ci vuole almeno uno switch. Quello che tu chiami "router" è in realtà un dispositivo che fa sia da router (fra interfaccia WAN e interfacce LAN) sia da semplice switch (fra interfacce LAN). Può essere più pratico separare i due dispositivi, anche per avere più porte perché difficilmente un router consumer ha più di 4/5 porte LAN - gli switch arrivano facilmente fino a 48 e sono anche "stackabili".

Uno switch di solito lavora a livello Ethernet - guarda a quale MAC address è indirizzato un pacchetto, guarda nella sua tabella a che porta è quell'indirizzo, e manda il pacchetto lì. Un dispositivo manda il pacchetto al suo gateway (router) solo quando è per una rete diversa dalla sua. Il router guarda l'indirizzo di destinazione IP e cerca nella sua tabella di reti per vedere se sa dove inoltrarlo.

Quindi finché i dispositivi sono nella stessa rete, basta uno switch. Quando devono andare su internet che è una rete diversa ci vuole un router - oppure se nella LAN ci sono più sottoreti separate. Ci sono valide ragioni per creare sottoreti separate in una LAN, per isolare il traffico. Nel tuo caso potrebbe essere opportuno che i PLC non siano nella stessa rete di altre macchine che non hanno bisogno di accederci.

L'isolamento delle reti viene fatto di solito con le VLAN - queste funzionano a livello Ethernet e isolano il traffico (i Fritz non supportano le VLAN) efficacemente. Poi, se si vuole che tutto o parte del traffico sia in grado di passare da una VLAN all'altra, si assegnano sottoreti (a livello IP, quindi) alle VLAN, e si usa un router per far passare il traffico fra una VLAN e un'altra, e magari anche un firewall per limitare quale traffico può passare).

r-mario92 ci sono diverse tipologie di Switch per supportare tale cosa o va bene uno qualsiasi?

Ci sono diversi tipi di switch, a costi diversi:

• unmanaged: sono i più economici ma non hanno altra funzione che far comunicare tra loro i dispositivi
• managed layer 2: costano un po' di più ma offrono funzioni più sofisticate a livell Ethernet come VLAN, link-aggregation, ecc. Le versione chiamate "smart managed" sono in genere un po' semplificate nelle funzioni, e hanno una interfaccia web di gestione, a costi un poco inferiori. Comunque le funzioni base e più utili ci sono
• manager layer 3: costano di più ma offrono anche funzionalità di routing e altri servizi a livello TCP/IP. Anche questi si trovano in versione smart managed.

Trovi anche alcuni switch a metà fra i L2 e L3, in genere con funzioni L3 un po' più limitate.

Direi che devi prima decidere che rete vuoi (un'unica rete, sottoreti separate) e poi si può decidere come implementarla al meglio. Se non sei esperto però mi farei seguire da un professionista, specialmente se è un'azienda e ci sono costi importanti in caso di fermo.

Suxsem Ciò ti permette di raggiungere i PLC anche dall'esterno configurando il port forwarding sul tim hub (al fritzbox), sul fritzbox (al tplink) e sul tplink, MA NON LO FAREI IN ALCUN CASO in quanto stai esponendo i PLC all'esterno! Il tplink ha un buon supporto VPN, mi configurerei quella per raggiungere i PLC da casa.

Meglio usare un tunnel cloudflare a quel punto piuttosto che esporre diretto con un port forwarding

r-mario92 Sostituire il router2 con uno switch, magari uno managed, senza attivare vlan, vpn ecc.... per semplificare la configurazione

Puoi anche cominciare con una configurazione semplice e poi man man che acquisisci esperienza passare a una configurazione più complessa. Uno switch manged appena installato funziona come un unmanaged - finché non lo configuri altrimenti. Tocca te decidere quanto vuoi spendere per lo switch. Se pensi però di non usare mai certe funzioni può non aver senso spendere di più.

r-mario92 collegandoli tra loro con solamente lo switch dovrebbero continuare a poter comunicare tra loro?

Se hanno IP statici continueranno a comunicare finché funziona lo switch. Se non vai proprio al risparmio estremo, gli switch sono dispositivi piuttosto robusti.

r-mario92 Quindi se poi collego lo switch al fritz gli do accesso non solo ad internet, ma soprattutto (quello che interessa) alla lan dove è connesso l'ufficio da cui posso "gestirli".

Esatto. Senza configurazioni particolari, uno switch è un "replicatore di porte" per connettere più dispositivi alla stessa rete. Se tutto quello che occorre è ampliare una rete, è molto più semplice usare uno switch che un router - gli switch hanno proprio quello scopo.

MaxBarbero dipende dal tipo di protocollo da esporre. Gli argo tunnel di Cloudflare consentono solo traffico web (http, https e websocket)

@"r-mario92" in linea di principio ciò che hai detto funziona. A quel punto ricordati solo di limitare il pool (ovvero il range) degli indirizzi assegnati dal dhcp del fritz e di scegliere per i plc indirizzi statici fuori da quel pool ma sempre all'interno della subnet del fritz (192.168.1.x)

Suxsem dipende dal tipo di protocollo da esporre. Gli argo tunnel di Cloudflare consentono solo traffico web (http, https e websocket)

in realtà ho visto che esporta anche altri protocolli (tcp, ssh, rdp, etc..), ma come dici tu, va visto il metodo di connessione per stabilire se può essere una soluzione.

Non sapendo il budget, io comunque sostituirei il tutto con un sistema semplice ma almeno prosumer che mi permetta abbastanza semplicemente di configurare il tutto con le vlan. Se è un sistema di produzione non farei troppi esperimenti con dei router e switch customer che, per carità funzionano anche, ma troppe cose diverse diventano difficili da gestire.

MaxBarbero
per qualunque protocollo non web-based è necessario connettere i client remote alla rete cloudflare attraverso Cloudflare WARP (https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/), di fatto diventa una VPN.
Inoltre, anche se fosse web-based, sarebbe comunque esporre i PLC all'esterno; in questo caso invece di conoscere l'IP WAN devi conoscere l'hostname del tunnel (ovvio che la sicurezza migliora in quanto viene esposta una specifica porta e volendo uno specifico path ma essendo PLC che controllano potenzialmente macchinari industriali metterei la sicurezza al primo posto).
Infine, è necessario avere un server attivo h24 (e configurato) su cui far girare il demone di cloudflared. Visto che ha già il router della tplink con supporto VPN forse nel SUO caso è più semplice

r-mario92 grazie per il dettaglio, a quel punto, anche se l'IP è fuori dal pool del fritz, stando sollo stesso livello, riesco a raggiungerlo digitando l'indirizzo nel browser (giusto per fare un esempio)
così avrei la conferma definitiva (grazie ai vostri consigli e risposte positive alla mia proposta) che posso fare questa prova.

"stando sullo stesso livello" intendi dire che fanno parte della stessa rete IP e sì, è corretto