Classe TC TC / numerazione dei filtri

Attualmente sto lavorando a una soluzione per la definizione del traffico per le aziende di livello ISP e ho riscontrato un problema interessante (di tipo filosofico).

Per quanto riguarda il numero di endpoint che il sistema dovrebbe gestire (che è di circa ~ 20k), mi sono un po 'preoccupato di cosa sarebbe successo quando avrei bisogno di stabilire criteri / modellare il traffico di più utenti. Dato che attualmente sto utilizzando l'albero di modellazione HFSC (vedi tc-hfsc, principalmente la stessa cosa più interessante del HTB meglio noto) per l'intera rete, dovrei usare più ClassID (ovviamente almeno uno per ogni utente sul Rete). Il problema che ho riscontrato è che i TC ClassID sono in qualche modo limitati: sono numeri a 16 bit, il che mi dà un massimo possibile di 64k utenti modellati da questa soluzione.

Allo stesso modo, se voglio gestire i filtri TC in modo efficiente (ad esempio, non usando la "tecnica di svuotamento completo"), devo essere in grado di eliminare o modificare singole voci di filtro. (Sto usando qualcosa di simile alla tabella hash di LARTC [1]). Ancora una volta, l'unico metodo che sembra funzionare con questo è numerare tutti i filtri usando le priorità individuali (tc filter add dev ... prio 1). Non ci sono altri parametri che potrebbero essere usati per questo scopo e, purtroppo, anche prio è solo a 16 bit.

La mia domanda è la seguente: esiste qualche buon metodo per allargare lo "spazio identificativo" disponibile, come il clsid a 32 bit per il comando 'classe tc' e le priorità a 32 bit (o qualsiasi altro handle di modifica) per 'filtro tc' comando?

Grazie mille,

-mk

(spero che questo non vada allo scenario "64k utenti dovrebbero essere sufficienti per tutti" ...)

— exa
fonte

Tutti questi valori sono memorizzati nello spazio del kernel, per ingrandirli dovresti ricompilare il tuo kernel e le utility dello spazio utente. Hai provato a usare il kernel a 64 bit? Lì possono essere definiti a 32 bit.

— Hubert Kario,

Il kernel a 64 bit utilizza le stesse dimensioni. Ad esempio, il numero di filtro è u32-integer che consiste in parte superiore (protocollo) e parte inferiore (prio) entrambi ovviamente a 16 bit. Gli ID classe sono codificati come u16. Probabilmente proverò a chiedere a qualcuno su LKML.

— exa,

anche usando l'hash per i tuoi filtri, avrai molti problemi di I / O se stai usando tanti filtri (immagino per l'upstream e per il downstream). Ho trascorso molto tempo e ho dovuto patchare l'implementazione delle code all'interno del kernel per far funzionare le cose con te ksoftirqd. Ho usato una patch di un ragazzo di nome Simon Lodal che ho incontrato su LARTC 4 anni fa. Dai un'occhiata alla sua patch mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html . Puoi provare a inviargli un'e-mail perché ha sempre una versione molto aggiornata (rispetto all'ultimo kernel) con lui.

— Pabluez,

@Pabluez Grazie mille, cercherò di ottenere il meglio da esso.

— exa

Penso che il tuo requisito sia valido ma, come ha scritto Pabluez, questo comporta certamente molte modifiche al kernel. Non voglio dire "stai sbagliando", ma ti incoraggio a verificare openflow, in cui le parti inferiori della gestione dei pacchetti vengono eseguite a livello di switch e le attività di polizia vengono eseguite nel software personalizzato, presumibilmente in esecuzione nello spazio utente. Non so se si adatta alle tue esigenze, ma vale sicuramente la pena indagare.

— AndreasM,

Risposte:

penso che non dovresti mettere 64k utenti con classi e filtri upstream e downstream per ognuno di essi sulla stessa interfaccia. Puoi ripetere i gestori per ogni interfaccia che hai, quindi aggiungi più interfacce. Avrai bisogno di un incredibile lavoro / server / NIC per avere queste cose. Se il server si arresta in modo anomalo, avrai 64k utenti offline (e si bloccherà facilmente con quella quantità di traffico). Non dimenticare che OGNI pacchetto che passa attraverso la tua scheda di rete verrà controllato e classificato da un filtro e inviato a una classe da mettere in coda. Questo è molto lavoro per una scheda NIC di un gateway ISP con 64k clienti. Principalmente con tutto il flusso video che abbiamo al giorno d'oggi (che è difficile fare la coda correttamente).

— Pabluez
fonte

Sto assicurando la disponibilità del servizio su qualche altro livello, ma grazie per l'interesse. In realtà, con buone schede NIC, non è così difficile avere un router Linux in grado di inoltrare 10 Gbit.

— exa

Per la domanda originale, ero più interessato a cose come l'aggiunta di 5 classi diverse per ciascun utente, il che mi avrebbe permesso di fare un ottimo lavoro QOS (come gestire i flussi e il traffico in tempo reale separatamente), ma è per lo più impensabile nelle condizioni attuali (con il mio caso d'uso corrente di ~ 20k endpoint sarei già dietro il limite).

— exa

ok, inoltrare 10Gbits non è un problema, il problema è avere molti filtri e classi 64k * 2 (up downs). Buona fortuna però: D

— Pabluez,

È possibile dividere la gestione del traffico in due macchine (usando una terza) invece di gestire tutto il traffico su una macchina. Il traffico può essere instradato semplicemente in base all'indirizzo IP di origine. Quindi, avrai 10k utenti in modo ottimale se puoi dividere uniformemente gli intervalli IP.

Naturalmente, è possibile utilizzare più di due macchine, se necessario. Penso che questo potrebbe essere meglio che rattoppare il kernel Linux e fare altri hack. In breve, il traffic shaping sarà distribuito su più macchine. Il nodo centrale inoltrerà semplicemente il traffico al nodo di elaborazione corretto.

— Khaled
fonte