Aiuto Hiperlan Ospf.

[meconiotronic]

Salve.

L'hanno scorso ho migrato una piccola rete da bridged a routed implementando ospf.

Attualmente ha un tunnel eoip per ogni bst bridgiato con le interfacce che fanno da access point e dall'altra parte della rete c'è un concentratore di tunnel bridgiato con due server pppoe.

Vorrei invece effettuare l'autenticazione pppoe direttamente sulle bst, ma per fare questo ho bisogno in qualche modo di portare gli ip pubblici fino alle bst.

Qui il diagramma di cio che mi piacerebbe realizzare.
http://forum.mikrotik.com/download/file.php?id=10105



Il ccr che concentra i tunnel sui pppoe servers si affaccia su internet e quindi sui pubblici.

Tutta la rete ospf è una backbone senza aree, la prima domanda è qual'è il tipo di area più adatta ad un server PPPoE? stub? nssa?

E la seconda è: E' possibile portare i pubblici nelle varie postazioni senza ricorrere a tunnel? Se si come?

Grazie in anticipo

[ppraz]

Gli ip che assegni tramite pppoe/radius sono privati o direttamente i pubblici?
Te lo chiedo perché OSPF trasporta tutti gli IP che gli dici di annunciare.
Quindi ogni router A, B e C saprà la rotta per raggiungere qualsiasi CPE utente.
Sulla frontiera, se lì effettui la NAT, non cambia nulla

[meconiotronic]

Ecco infatti è venuto fuori subito questo problema.
Allora da Radius ho due pool il 95% delle cpe ha un pool privato il rimanente un pubblico.
Ho fatto un test su una bst ho creato un area chiamata PPPoE In area range ho dichiarato un piccolo pool di pubblici. Ho creato un PPPoE server e fatto un test.

In ospf instance ho dichiarato "Redistribuite connected"

Ho assegnato un pubblico via radius ad una cpe e funziona perfettamente, solo che così facendo tutte le macchine della rete hanno ricevuto la rotta per quella cpe. Se gli assegno un privato (effettuando un nat sulla bst) stesso discorso.

Come si può fare?

[meconiotronic]

Allora ho parzialmente risolto.
Ho dichiarato la network 172.25.0.0/16 Area PPPoE Ho creato un pool 172.25.0.0/16 da assegnare ai client.
Ho usato area range e ho aggregato tutta la 172.25.0.0 e funziona perfettamente, quando i client si connettono viene dichiarata un unica rotta 172.25.0.0 piuttosto che varie /32
Ora il problema è che il sistema radius di questa rete assegna un singolo pool /16 172.23.0.0 quindi se usassi radius su più postazioni assegnerebbe ad esempio 172.23.0.2 a un client collegato su una bst e 172.23.0.60 su un altro server su un altra bst rendendo di fatto l'aggregate inutilizzabile.

Qualche consiglio? Anche se alla conclusione tragica di dover cambiare sistema radius credo di esserci arrivato

[ppraz]

Non vedo quale sia il problema di avere nella routing table 1000 rotte di tipo /32
E' quello il modo standard di lavorare.
Sommarizzare le rotte è una azione che fai in frontiera per esportare verso fuori una rotta aggregata anzichè tante /32
Hai fatto bene a mettere "Redistribuite connected" sennò non avrebbe funzionato nulla
Se usi rotte /32 come ti ho suggerito non hai nessun problema se

"... assegnerebbe ad esempio 172.23.0.2 a un client collegato su una bst e 172.23.0.60 su un altro server su un altra bst... "

non è vero che renderesti inutilizzabile la cosa, l'importante è non assegnare lo stesso IP a due client.

[steste64]

Mi inserisco.... secondo voi quale è il limite di rotte che un 2011 può gestire? A che percentuale di CPU si puo' arrivare prima di considerare un cambio dell'Hardware magari con 110ahX2? I miei valori sono 500 rotte e 30-40 percento utilizzo CPU.

[ppraz]

Non so quanto il numero di rotte influenzi la CPU, sicuramente influenza la memoria, ma non so darti numeri per quantificare.
Per esperienza Mikrotik quando deve gestire troppa roba non ce la fa più e serve Cisco o altri brand "blasonati"

[figheras]

Con il comando:

Codice: Seleziona tutto

ip route cache print
cache-size: 1022
  max-cache-size: 16384

Puoi visualizzare la cache della tua tabella di routing e quindi capire quanta memoria ha ancora a disposizione!
Per la gestione della CPU c'è da capire quanti altri servizi girano su quel router...e comunque mai portare l'hw al 100% di utilizzo!