ringrazio tutti coloro che mi risponderanno perchè so che l' argomento è complesso.
Posto in allegato stralcio di mappa infrastruttura con le sole cose che interessano; in alcuni casi vado a semplificare ciò che nn serve sapere in questo caso ( tipo associo ad un collegamento semplice LAN un segnale che arriva invece per esempio da un altro/altri link P2P "dritti" cioè assimilabili ad un cavo ... )
Dato che il disegno è complesso racconto lo schema:
TUTTE LE ANTENNE SONO IN BRIDGE WDS ( ap o sta ) e con MULTICAST DISATTIVATO.
1. Si parte da AP- PBM5 - con ip 192.168.1.124/24 e gtw 192.168.1.100
Nello specifico il gateway 100 è un videoserver ( MWS2008r2 ) che riceve lo stream video da tutto ciò che è classe 192.168.1.X ( 25 sorgenti video, tutte esclusivamente unicast udp )
L' AP in oggetto ha 2 client station:
- la prima ( 192 - sta rosso ) riceve in LAN 5 camere.
- la seconda ( 172.16.12.252/24 con gateway 172.16.12.1 ) inietta in tutta la 192 da qui un PROXY HOTSPOT che e collegato a lei via LAN e che fa da dchp server e da gateway verso il web
L' access point che collega le due antenne ha il client iso attivato.
Via cavo l' ap in oggetto arriva in uno switch managed dove ho attivato l STP ( come su tutte le antenne )
Lo switch collega via cavo LAN il Videoserver in 192.168.1.100 e altre 3 tratte composte in modo identico a quella che segue:
- STA in classe 192
- AP in classe 192 --> via lan all' ap sono collegate diverse camere in classe 192 ( ap con client ISO off in questo caso )
- STA in classe 172 con a cascata lan un AP ( pico 2 ) anche lui in classe 172.
A quest' ultimo AP si collegano in radio poi diversi client wifi 2.4 Ghz ( pc, smart, ecc ) che usufruiscono del servizio hotspot in classe 172.16.12.X trasportato sulla rete 192.168.1.X
Quindi in sostanza usiamo la stessa infrastruttura di rete per portare due classi di rete distinte, per due servizi distinti, e con 2 gateway distinti ( 192.168.1.100 e 172.16.12.1 )
Regole di firewall ad-hoc bloccano sulla WLAN della 172.16.12.252 tutto ciò che è UDP in ingresso dalla 192 e sempre sulla WLAN tutto ciò che ha provenienza 0.0.0.0/0 e destinazione 192.168.1.X/24.
In aggiunta su tutti gli AP pico2 ci sono delle regole del tipo:
IF ATH0 DROP 0.0.0.0/0 --> 192.168.1.X/24
IF ATH0 DROP 192.168.1.X/24 --> 0.0.0.0/0
In questo modo chi è dietro gli AP non può accedere alla 192 in alcun caso e l' hotspot cmq dal suo lato non può vedere ne lo stream video udp ( che blocca la WLAN dell' antenna ) ne cmq tutta la 192 ( un eventuale ping nn troverebbe cmq risposta alcuna un quanto qualsiasi sorgente viene bloccata sempre dalla WLAN dell' antenna in risposta ad una destinazione in classe 192 ).
ORA:
tutto funziona stabilmente, lo stream scorre, la banda c'è perchè i link sono buoni, e il dhcp si propaga ovunque senza problemi raggiungendo i client finali e concedendogli una corretta e buona navigazione web.
SUCCEDE QUESTO:
random, ma credetemi, veramente random, si generano dei loop o meglio vengono propagati dei pacchetti, non si capisce cosa, che arrivano a generare da un traffico medio di 20Mbps un trafficio di anche 60-70Mbps.
Questo propagarsi random, manda tutto in collasso, stream, navigazione e gli stessi link di alcune antenne.
ORA:
osseviamo il fenomeno da diversi mesi: può accadere 10 volte al giorno come una volta ogni 72 ore. Il loop può durare diversi miunti o alcuni secondi, prima di esaurirsi naturalmente. Il traffico nn si capisce da dove si genera, ma solo che si propaga ovunque, su tutte e due le classi.
Il tipo di traffico, monitorato con wireshark in diversi punti, è normale traffico di rete, semplicemente moltiplicato alla n.
di sicuro se viene staccato il gateway in classe 172 ( l' hotspot ) il problema si risolve.
Quindi --> rete con due gateway = PROBLEMA
Pensavamo quindi di sviluppare una soluzione del genere: VLAN
Partendo dal punto di ingresso dell' hotspot: la STA 172.16.12.252
Fare un bridge di questo tipo:
BRIDGE0:
LAN0
WLAN0.2 ( VLAN radio con ID = 2 )
In questo modo notiamo che sul suo AP 192.168.1.124 il link radio è su ma il traffico in 172 non è disponibile.
Quindi:
Sull' AP 192.168.1.124 facciamo una regola di questo tipo:
BRIDGE0:
LAN0
WLAN0
bridge per portare la 192
BRDIGE1:
WLAN0.2 ( VLAN radio con ID = 2 )
LAN0.3 ( VLAN di rete con ID = 3 )
In questo modo notiamo che lo switch ci indica come info che ha trovato un VLAN con ID=3 sulla porte di rete corrispondente all' AP in questione.
Proseguendo sulla STA in classe 192 che è collegata nello switch inseime all' AP di cui sopra, facciamo una regola del tipo:
BRIDGE0:
LAN0
WLAN0
bridge per portare la 192
BRDIGE1:
LAN0.3 ( VLAN di rete con ID = 3 )
WLAN0.2 ( VLAN radio con ID = 2 )
A questo punto lo switch ci dice che ha trovato un altra porta di rete con VLAN tag=3 e ci chiede se vogliamo permettere il join: ok, permettiamo il join e sulla STA ci compaino nei dettagli della sua bridge table in BRDIGE 0 i MAC degli apparati in 192 e in BRIDGE1 i mac di quelli in 172.
Ottimo.
Da qui non riusciamo però a proseguire....Ciò che è in VLAN ( la classe 172 ) ci risulta sempre inaccessibile anche se andiamo avanti a fare regole come sopra fino agli AP finali.
Nello specifico andando avanti, abbiamo saltato l' AP successivo in classe 192 in quanto non ha client ISO e abbiamo fatto subito la regola sulla prima su STA in 172.
BRDIGE0
LAN0
WLAN0.2 ( VLAN radio con ID = 2 )
Sulla sta nei dettagli della bridge table ci compaiono in questo caso giustamente solo tutti i MAC degli apparati in 172 ( mentre prima vedevamo tutto ) correttamente peraltro associati all' interfaccia WLAN0.2, ma anche dal ping test interno non sono + raggiungibili.
......
xkè ? cosa sbagliamo ?
Grazie mille
.gif ")")