Problemi di installazione
Controllare quanto segue:
- La ISO deve essere copiata su un'unità USB con partizioni MBR e modalità DD.
- Il BIOS del server deve avere la modalità di avvio predefinita (ad esempio, DUAL).
- Se è presente un controller RAID, un'unità logica deve essere configurata e contrassegnata come avviabile.
- Verificare se il server utilizzato per l'installazione soddisfa i requisiti hardware di BQN.
- Verificare che l'installazione sia stata eseguita sul disco rigido e non abbia sovrascritto l'unità USB.
Nessun accesso all'indirizzo IP di gestione
Il BQN utilizza un'interfaccia di rete dedicata per la gestione. L'interfaccia di gestione supporta i servizi SSH e WEB (HTTP). In caso di problemi di accesso all'IP di gestione configurato, verificare quanto segue:
- Assicurarsi che la porta dell'interfaccia di rete di gestione sia collegata alla rete appropriata.
- Verificare che lo stato del collegamento dell'interfaccia di rete di gestione sia attivo. Se l'interfaccia di gestione è collegata a uno switch di rete, verificare che la porta nello switch sia attiva e che i suoi attributi corrispondano alle proprietà mostrate dal comando show interface.
- Se si accede all'indirizzo IP di gestione da una rete diversa, assicurarsi che il routing statico sia configurato verso la rete di accesso, come spiegato nella sezione Interfaccia di rete della Guida dell'utente.
- Se nella rete di gestione sono presenti firewall, consentire l'accesso alla porta TCP 22 per il servizio SSH e alla porta TCP 443 per il servizio WEB.
- Verificare con la console di sistema che l'indirizzo IP di gestione e il prefisso di rete siano corretti. Collegare un monitor e una tastiera al server ed eseguire il login come root:
- Se si sospetta che le impostazioni IP OAM siano errate o sconosciute, collegare un monitor e una tastiera al server e accedere come root per modificarle utilizzando la procedura guidata bta in modalità interattiva. Ad esempio, per cambiare l'interfaccia di gestione in en0o1 con l'indirizzo IP 10.10.10.12/24 (premere invio per accettare la risposta suggerita):
Se l'interfaccia non è disponibile al momento della modifica (ad esempio, ha partecipato a un wire), un messaggio richiederà un riavvio. Dopo il riavvio, il BQN dovrebbe avere il nuovo IP e la nuova interfaccia di rete di gestione.
- L'interfaccia di gestione del BQN potrebbe essere protetta da un proprio firewall. Il problema potrebbe essere che l'indirizzo IP di origine non è incluso nella lista bianca del firewall. Questo potrebbe accadere anche per gli indirizzi della stessa subnet dell'IP di gestione del BQN, se la subnet non fa parte delle regole del firewall. È possibile disattivare temporaneamente il firewall finché non viene ripristinata la connessione alla porta di gestione. Collegare un monitor e una tastiera al server e accedere come root:
Una volta che l'IP di gestione è raggiungibile, è possibile definire la nuova lista bianca degli intervalli IP di origine consentiti.
- If the command <span class="character-highlight">wizard bta interactive</span> fails, connect with a console and a keyboard and try changing the configuration directly. In the following example, the management interface is in en0o2 and we will move it to interface en0o1 and from IP address 192.168.0.121 to IP address 10.0.0.121, with default gateway 10.0.0.1:
Web non accessibile
- Verificare che l'indirizzo IP di gestione sia accessibile tramite SSH,
- Verificare che l'accesso avvenga tramite HTTPS (HTTP non è supportato). Esempio di URL: https://192.168.0.121
- Verificare che si stia utilizzando l'utente bqnadm (root non può essere utilizzato nell'accesso alla GUI).
- Quando si installa da zero, assicurarsi che sia stato eseguito il comando guidato bta (altrimenti il servizio web dell'interfaccia grafica non sarà attivo e non verrà creato un utente bqnadm).
- Verificare che la porta SSH del server BQN non sia stata modificata. Per accedere al BQN utilizzando una porta diversa dalla 22, è possibile definire regole di port forwarding nel router del percorso di accesso, ma la porta SSH del BQN non può essere modificata. Accedendo al server come root, è possibile verificare che la porta SSH sia la 22 come segue:
Se necessario, commentare la riga che specifica una porta diversa da 22.
- Verificare che il proprio browser sia supportato (Edge, Firefox, Chrome). MS Explorer, ad esempio, non è supportato.
Interfaccia di rete disattivata
Se l'icona Interfacce di rete nella Dashboard non è verde.
Andare a Configurazione->Interfacce->Dati Wires
In rosso (critico)
- Se non è stato configurato wire , crearne uno.
- Se wires è configurato ma le sue interfacce non sono in stato di UP, ciò indica molto probabilmente che le interfacce non sono compatibili con Intel. Andare a Configurazione->Interfacce->Dati Wires e fare clic sull'interfaccia in basso per vedere il modello(PCI vendor ID) e confermare che non è Intel. Rimuovere il sito wire e crearne uno nuovo con entrambe le interfacce in modalità pcap. Questo dovrebbe portare le interfacce in stato UP, ma con una capacità di throughput molto inferiore (meno di 1Gbps).
- Se è configurato wires , con le interfacce in stato UP ma con LINK down, c'è un problema di connessione con l'altra apparecchiatura. Collegare entrambe le porte di interfaccia tra loro in un loop utilizzando un cavo/fibra adeguato. Se entrambe le interfacce sono attive, il problema è dell'altra apparecchiatura.
Se il collegamento è ancora interrotto e si utilizzano porte ottiche, verificare che i ricetrasmettitori:
- sono compatibili con Intel
- sono supportate (per un elenco, vedere Schede di rete supportate).
- del tipo richiesto dall'installazione (ad esempio, SFP+-LR in un'installazione con fibra monomodale e SFP+-LR dall'altra parte).
In giallo (Avviso)
- Se i wires come "down wires dovrebbero avere traffico, seguire i passaggi wires nella sezione precedente (Critico)
- Se i wires come "inattivi" non vengono utilizzati e si desidera rimuovere il segnale di avviso, è possibile eliminare i wires inutilizzati. Si tenga presente che le modifiche alla wire interromperanno il traffico per un certo periodo di tempo (da 10 secondi a due minuti, a seconda della configurazione del server).
Traffico invertito
Se l'icona "Traffico invertito" nella Dashboard è di colore arancione (Avviso), significa che il volume di traffico in direzione uplink è superiore a quello in direzione downlink. Ciò può essere normale in implementazioni di piccole dimensioni (meno di un centinaio di abbonati, come un BQN in laboratorio), ma in un'implementazione di rete indica molto probabilmente che alcuni wires stati collegati in modo errato, con la porta di accesso collegata al lato Internet e viceversa.
Per verificare che sia effettivamente così, andare su Statistiche->Throughput->Interfacce e selezionare wire configurata sul lato di accesso. Se il throughput ricevuto è superiore a quello inviato, significa che l'wire invertita. È possibile confermarlo selezionando il throughput dell'interfaccia sul lato Internet per verificare che il traffico inviato sia superiore a quello ricevuto.
Per risolvere il problema, accedere a Configurazione->Interfacce->Dati Wires e, nel riquadro wire, premere l'icona Scambia interfacce.
Traffico ridotto
L'icona " Traffico ridotto " nella Dashboard è gialla e si trova nello stato "AVVISO".
Passa il mouse sull'icona per verificare che venga visualizzato l'avviso "Traffico basso". Ciò indica che il traffico che transita attraverso il server BQN è molto scarso. Si tratta di un comportamento normale se il sistema sta ancora aspettando che il traffico venga instradato attraverso di esso. Tuttavia, in un sistema in produzione, ciò può indicare che un guasto in un altro punto della rete sta impedendo al traffico di raggiungere il server BQN.
Traffico asimmetrico
Si parla di traffico asimmetrico quando il server BQN rileva solo una delle direzioni del traffico (uplink o downlink) e non l'altra.
Il traffico asimmetrico può interessare tutto il traffico che transita attraverso il BQN oppure solo una parte di esso.
L'ottimizzazione TCP richiede un traffico simmetrico; pertanto, l'asimmetria comporta un peggioramento dell'esperienza dell'utente e il TCPO deve essere disabilitato nel traffico interessato fino alla risoluzione del problema.
Tutto il traffico è asimmetrico
L'icona " Traffico ridotto " nella Dashboard è arancione e indica lo stato "AVVISO".
Passa il mouse sull'icona. L'avviso dovrebbe riguardare " Traffic-uplink " o"Traffic-downlink". Ciò indica che non vi è traffico in transito attraverso il BQN in quella direzione e che, pertanto, il traffico è asimmetrico.
Per disabilitare il TCPO nel traffico interessato, accedere a Configurazione->Impostazioni di ottimizzazione e disattivare l'opzione " Ottimizzazione TCP complessiva " fino a quando non sarà risolto il problema di instradamento del traffico all'origine dell'asimmetria.
Parte del traffico è asimmetrico
L'icona " Traffico ridotto " nella Dashboard è verde, indica lo stato NORMALE, eppure periamo reclami da parte dei clienti relativi a un peggioramento del servizio.
Per verificare se parte del traffico è asimmetrico, vai su Stato->Abbonati->Metriche QoE e imposta un filtro nella tabella degli abbonati in modo da visualizzare solo gli abbonati con 0 byte nella direzione di uplink (MBYTES-DOWN) o di downlink (MBYTES-UP).
Escludere gli indirizzi IP multicast o broadcast. Per tali indirizzi IP, è del tutto normale che il traffico avvenga in una sola direzione. Ad esempio, l'indirizzo broadcast IPv4 255.255.255.255 o l'indirizzo multicast locale di collegamento IPv6 ff02::,
Se si notano indirizzi IP normali con 0 byte in una direzione e un traffico consistente nell'altra, significa che quell'IP è soggetto a traffico asimmetrico. Poiché il problema è solitamente causato da un instradamento errato del traffico, anche altri indirizzi IP sulla stessa sottorete ne risentirebbero.
Per disabilitare il TCPO nel traffico interessato mentre si corregge l'instradamento, andare su Configurazione->Flussi degli abbonati e creare una politica di flusso con l'ottimizzazione TCP disabilitata; creare poi un profilo di accesso contenente gli indirizzi IP o gli intervalli degli abbonati interessati e collegarli tramite una regola. Per ulteriori dettagli, consultare questo esempio.
Gestore delle licenze
Se l'icona License Manager nella dashboard è in giallo e il testo dice "license-mgr-connection:notice", è perché il server BQN non riesce a raggiungere il license manager. Il gestore delle licenze è responsabile della convalida delle licenze SW BQN e aiuta Bequant a fornire un supporto più proattivo segnalando i problemi del server.
Assicurarsi che il server BQN sia in grado di avviare connessioni in uscita verso l'IP di License Manager (per maggiori dettagli, contattare l'assistenza di Bequant ).
Per verificare che sia possibile stabilire una connessione in uscita, accedere come root ed eseguire un comando telnet all'indirizzo IP e alla porta indicati:
Il comando telnet dovrebbe andare a buon fine se il gestore delle licenze è raggiungibile.
Licenza non OK
Se l'icona della licenza nella Dashboard è rossa e il testo riporta "license-available:critical"o "license-expiration: critical", significa che non è presente alcuna licenza valida. Ciò potrebbe essere dovuto a diversi motivi:
- Non esiste una licenza definita nel nodo
- La licenza non è valida
- La licenza non è più valida (la data finale è scaduta).
Contattare il distributore per ottenere una licenza valida.
È possibile controllare lo stato della licenza in Amministrazione->Licenza.
Quando non c'è una licenza valida, il BQN inoltrerà tutto il traffico in modo trasparente: il servizio non sarà influenzato, ma nessuna delle elaborazioni avanzate del BQN sarà applicata al traffico.
Limite di licenza superato
Se l'icona della licenza nella Dashboard è arancione e il testo recita “license-usage: warning”, significa che la capacità massima della licenza è stata superata (il traffico totale in uscita dal server BQN è superiore al limite previsto dalla licenza).
Contattare il distributore per un aggiornamento della licenza.
È possibile controllare la capacità della licenza in Amministrazione->Licenza.
In Statistiche->Throughput->Overview, una linea rossa mostra il limite della licenza e i livelli di throughput recenti.
Il superamento del limite della licenza deve essere temporaneo, mentre la licenza viene aggiornata alla giusta capacità.
Quando il limite della licenza viene superato, il QoE non fa cadere i pacchetti, ma li fa semplicemente passare in ponte.
L'effetto sul traffico è diverso a livello di flusso e di sessione dell'abbonato.
Effetti a livello di flusso:
- Mentre il limite di licenza viene superato, i nuovi flussi non avranno alcuna licenza.
- I flussi esistenti prima del superamento della licenza sono inalterati: se erano in fase di ottimizzazione rimangono tali e allo stesso modo se senza licenza.
- Quando il traffico ottimizzato scende al di sotto del limite, i nuovi flussi vengono nuovamente ottimizzati.
- I flussi esistenti prima della licenza che scendono al di sotto del limite non sono influenzati: se non avevano la licenza rimangono tali e allo stesso modo se erano in fase di ottimizzazione.
- Un flusso senza licenza presenta:
- Nessun TCPO
- Nessuna modellatura
- Non genera metriche (ritrasmissioni, latenze, DPI, ecc.).
Effetti a livello di sessione abbonati:
- Mentre il limite di licenze viene superato, le nuove sessioni di abbonati non avranno alcuna licenza.
- Le sessioni degli abbonati già in corso prima del superamento del limite della licenza rimangono inizialmente nel loro stato attuale: se erano ottimizzate, rimangono tali, e lo stesso vale se non lo erano.
- Se la licenza rimane al di sopra del limite, le sessioni di abbonati ottimizzate possono passare a nessuna licenza se accumulano un numero elevato di flussi non ottimizzati.
- Quando il traffico ottimizzato scende al di sotto del limite, le nuove sessioni degli abbonati vengono nuovamente ottimizzate.
- Le sessioni degli abbonati che escono prima che la licenza scenda al di sotto del limite rimangono inizialmente nel loro stato attuale: se non avevano licenza rimangono tali e allo stesso modo se erano in fase di ottimizzazione.
- Se la licenza rimane al di sotto del limite, le sessioni degli abbonati senza licenza possono passare a essere ottimizzate se accumulano un piccolo numero di flussi ottimizzati.
- Una sessione di un abbonato senza licenza presenta le seguenti caratteristiche:
- senza ACM,
- nessuna limitazione della velocità
- continua a generare dati sul volume di traffico complessivo.
- La segnalazione dei volumi relativi alle quote è sospesa.
- Non verrà effettuato alcun blocco al raggiungimento della quota.
- Gli altri parametri, come le ritrasmissioni, le latenze, ecc., saranno ridotti ai valori dei flussi oggetto di ottimizzazione.
- Una sessione di abbonato in fase di ottimizzazione sarà influenzata dal fatto che alcuni dei suoi flussi potrebbero non avere una licenza e quindi l'abbonato potrebbe avere un set di misure ridotto rispetto al funzionamento normale. Ciò influisce sull'ACM e anche sulle metriche generate per quell'abbonato.
L'effetto del superamento del limite della licenza è che sempre più traffico non otterrà più la funzionalità QoE e, viceversa, la quantità di traffico che ottiene la funzionalità QoE si riduce. Una volta che la quantità di traffico che ottiene la funzionalità QoE è inferiore al limite della licenza, i nuovi flussi e le sessioni degli abbonati riacquistano la funzionalità QoE. Ciò continua fino al superamento del limite di licenza, dopodiché l'effetto si ripete nuovamente. Con questo comportamento oscillante, il QoE continua a fornire funzionalità al traffico fino al limite della licenza. Il BQN controlla continuamente il livello di throughput rispetto ai limiti di licenza (ogni minuto o meno), quindi l'adattamento è piuttosto rapido.
Elevato carico della CPU
Se l'icona della CPU nella Dashboard non è verde, alcune CPU stanno funzionando a livelli anormalmente alti. Ciò è normalmente dovuto a un traffico sbilanciato (concentrato in alcuni IP di abbonati) o a un traffico eccessivo da parte del server BQN.
È possibile verificare il livello di throughput in Statistiche->Throughput->Panoramica e i livelli di utilizzo della CPU in Statistiche->Sistema->CPU.
Esistono due tipi di allarme, a seconda dei livelli di carico della CPU:
- Arancione se alcuni core della CPU sono sottoposti a un carico elevato (utilizzo superiore all'80%).
- Rosso se alcuni core della CPU presentano un carico molto elevato (utilizzo superiore al 90%).
Innanzitutto, alcune nozioni introduttive sull'utilizzo di base di BQN.
Scopri le affinità dei core della CPU: I/O e worker
Nel BQN, i processi critici vengono eseguiti con la massima priorità nei core della CPU loro assegnati. Questo fenomeno è noto come “affinità dei core”. A due processi vengono assegnati dei core della CPU:
- Processi I/O: sono responsabili delle operazioni di lettura e scrittura dei pacchetti di traffico in entrata e in uscita dalle porte dell'interfaccia di rete.
- Worker: sono i processi del piano dati responsabili dell'elaborazione dei pacchetti (ottimizzazione TCP, ACM, vari limiti di shaping, ispezione DPI, ecc.).
I restanti processi BQN vengono eseguiti su qualsiasi core disponibile, ma nel caso in cui ne sia stato designato uno specifico, lo scheduler può preemptare il processo a bassa priorità per eseguire quello ad alta priorità. Se il server dispone di un numero sufficiente di core CPU, alcuni vengono lasciati liberi in modo da poter essere dedicati ai processi a bassa priorità.
Per visualizzare l'affinità dei core della CPU sul tuo server, esegui questo comando:
In questo esempio, il server dispone di 10 core. Sette core sono assegnati ai processi ad alta priorità: sei per l’esecuzione dei processi worker e uno per l’esecuzione dei processi I/O. Tre core rimangono non assegnati, pronti per l’esecuzione di processi a bassa priorità. L’assegnazione specifica dei core dipenderà dal numero di core della CPU, dal numero di wires dalla velocità di tali wires. Il BQN cercherà di effettuare l’assegnazione più ottimale in base a tali variabili. Nell’esempio, è presente una wire una capacità di throughput wire 10 Gbps.
Il campo "affinity" indica i core assegnati. Nell'esempio, l'IO si trova sul core numero 3, dove 0 corrisponde al primo core (0x8 = 1000), e gestisce il traffico di entrambe le interfacce del wire. I worker si trovano sui core dal 4 al 9 (0x3F0 = 1111110000). I core da 0 a 2 non sono assegnati (core per uso generico).
Le istanze dei processi di lavoro sono numerate a partire da uno. Nell'esempio, l'istanza di lavoro n. 1 si trova sul core 4 e l'istanza di lavoro n. 6 sul core 9.
È possibile visualizzare l'istanza del worker che gestisce un determinato abbonato consultando la sezione " Dettagli aggiuntivi " nella dashboard dell'abbonato.
Scopri quali core sono sovraccarichi
Vai su Statistiche->Sistema->CPU e individua i core della CPU con un carico superiore all'80%. Controlla i dati delle ultime 24 ore, poiché il picco di carico potrebbe essersi verificato in passato.
Determinare se i core della CPU interessati sono I/O o worker.
A volte i picchi di carico della CPU sono di breve durata e non risultano visibili nelle statistiche di sistema, poiché tali statistiche riportano una media calcolata su intervalli di 5 minuti. Vai su Amministrazione->Log->Sistema.
Aumenta il numero di righe (ad esempio 1000) e imposta l'espressione regolare positiva per filtrare "cpu". In questo modo dovrebbero essere visualizzati gli allarmi relativi alla CPU generati e, cosa ancora più importante, una voce di log che indica quale specifico core della CPU è interessato. Nell'esempio seguente, il codice 6 entra in stato di allarme alto a causa di un utilizzo del 94%:
Nel nostro esempio, Core 6 è un worker.
Elevato carico sui core della CPU dei lavoratori
La causa più comune è uno squilibrio nel traffico. BQN utilizza gli indirizzi IP degli utenti per distribuire il traffico tra i worker disponibili. Se alcuni indirizzi IP concentrano una quantità eccessiva di traffico, i worker che li gestiscono potrebbero risultare sovraccarichi.
Vai su Statistiche->Abbonati->Top per tempo per vedere come è distribuito il traffico tra gli abbonati con l'utilizzo maggiore. Verifica se i primi della classifica concentrano una quantità di traffico molto superiore rispetto agli altri.
Per verificare, clicca con il tasto destro sugli indirizzi IP con il maggior utilizzo per accedere alla dashboard dell'abbonato e controllare il numero dell'istanza nella sezione " Dettagli aggiuntivi". Ad esempio, nell'esempio che stiamo seguendo, se il core di lavoro è il numero 6, l'istanza prevista è la 3. L'istanza deve corrispondere a quella riportata nei log di sistema.
Se non si riscontra alcun squilibrio nel traffico, il problema potrebbe essere causato da livelli di traffico elevati in generale. In tal caso, il core di lavoro con carico elevato cambierà di volta in volta. Vai su Statistiche->Throughput->Panoramica e verifica se i picchi di traffico corrispondono ai picchi dei core di lavoro.
Potrebbe essere necessario un aggiornamento dell'hardware. Contattare l'assistenza Bequant .
Nel frattempo, il BQN dispone di meccanismi interni per mitigare l'elevato carico sui core dei worker, cercando di prevenire le perdite di traffico attraverso la riduzione della quantità di traffico ottimizzato.
Altre misure di mitigazione che puoi adottare in attesa dell'aggiornamento hardware:
- Abilita il bypass per gli indirizzi IP che causano il sovraccarico. Il traffico proveniente da tali indirizzi IP non verrà ottimizzato né limitato in termini di velocità, ma il carico sui core interessati dovrebbe ridursi, poiché nei worker non verrà eseguita alcuna elaborazione del traffico proveniente da tali indirizzi IP.
- Se si utilizza il NAT tra il BQN e gli utenti finali, aumentare il numero di indirizzi IP utilizzati dal NAT, in modo che il BQN possa distribuire il traffico su un numero maggiore di indirizzi.
Se il server BQN viene utilizzato solo per il TCPO e/o per i limiti di velocità per flusso, è possibile migliorare la distribuzione del carico della CPU abilitando lo steering per flusso. Lo steering per flusso distribuisce il carico di traffico tra i core della CPU per ogni singolo flusso, anziché seguire la distribuzione predefinita del traffico per abbonato. Ciò migliora il bilanciamento del carico della CPU, ma poiché il controllo per abbonato viene effettuato per singolo core, non consente il controllo a livello di abbonato, come ACM, velocità di politica o limiti di flusso per abbonato.
Elevato carico di I/O sui core della CPU
Un carico elevato dei core IO rappresenta un problema critico, poiché alcuni pacchetti non verranno inoltrati e, di conseguenza, andranno persi a causa dell'insufficiente capacità di elaborazione dei core.
Il problema è solitamente causato da livelli elevati di traffico. Accedere a Statistiche->Throughput->Panoramica perverificare che i picchi di traffico corrispondano ai picchi registrati nei core IO interessati.
Un'altra possibilità è che l'interfaccia di rete del server BQN non supporti la distribuzione del carico del traffico tra diversi processi IO. Ciò si verifica con il traffico PPPoE in alcuni modelli di schede di rete. Vedi Interfacce di rete supportate e Risoluzione dei problemi dell'XL710.
Un'altra possibile causa è un wire modalità pcap, che ne limita la capacità a circa 1 Gbps di throughput¹. Se si trattasse di un errore di configurazione e la scheda di rete fosse compatibile con Intel, andare su Configurazione->Interfacce-> Wires dati e impostare il wire modalità normale (DPDK).
Potrebbe essere necessario un aggiornamento dell'hardware. Contattare l'assistenza Bequant .
Nel frattempo, una possibile soluzione consiste nel modificare le affinità dei core della CPU, riassegnando i core di lavoro o quelli non assegnati ai processi di I/O. Il supporto tecnico di Bequant ti aiuterà in questo.
Elevato carico di memoria
Se l'icona "Memoria " nella Dashboard non è di colore verde, significa che alcuni processi stanno esaurendo la memoria.
Esistono due tipi di allarme, a seconda dei livelli di carico della memoria:
- Arancione se alcuni processi raggiungono un utilizzo elevato (oltre il 90%).
- Rosso se alcuni processi raggiungono un utilizzo molto elevato (oltre il 95%).
Scopri l'utilizzo della memoria
Vai su Statistiche->Sistema->Memoria e individua quale memoria presenta un utilizzo superiore alla soglia. Controlla i dati delle ultime 24 ore, poiché l'utilizzo elevato potrebbe essersi verificato in passato.
La memoria di sistema è suddivisa in tre sezioni:
- Pool DPDK: è la memoria di sistema riservata alla libreria DPDK e in cui vengono memorizzati i pacchetti di traffico. Nei server NUMA, ogni NUMA dispone di un proprio pool DPDK per memorizzare il traffico relativo alle schede di rete inserite in quel NUMA.
- Pool di memoria (mpool): è la memoria di sistema utilizzata dai processi di lavoro per memorizzare le informazioni relative ai flussi, agli abbonati e ai metadati del traffico.
- Resta della memoria di sistema (20% del totale): viene utilizzata dal resto del sistema, ad esempio dal gestore delle API che interagisce con i sistemi di fatturazione esterni, per attività di gestione, ecc.
Una delle cause più comuni di un elevato utilizzo della memoria è un traffico troppo intenso. Verifica se i picchi riportati in Statistiche->Traffico->Panoramica corrispondono ai picchi presenti in Statistiche->Sistema->Memoria.
A volte i picchi di utilizzo della memoria sono di breve durata e non risultano visibili nelle statistiche di sistema, poiché tali statistiche riportano una media calcolata su intervalli di 5 minuti. Vai su Amministrazione->Log->Sistema.
Aumenta il numero di righe (ad esempio 1000 righe) e imposta l'espressione regolare positiva per filtrare "memory". In questo modo dovrebbero essere visualizzati gli allarmi relativi alla memoria generati
Una voce di log che indica che il pool DPDK sta registrando un utilizzo elevato si presenta come segue (in questo esempio, il pool DPDK ha un utilizzo del 92%):
Il pool DPDK è condiviso tra tutti i worker e, pertanto, il fatto che l'allarme sia stato generato mentre l'istanza 2 del worker stava effettuando una richiesta non significa che sia l'istanza 3 la responsabile dell'elevato utilizzo.
Una voce di log che indica che l'mpool sta registrando un utilizzo elevato si presenta come segue (in questo esempio, l'utilizzo dell'mpool è pari al 96%):
mpool viene suddiviso in parti uguali tra tutti i worker, ciascuno dei quali dispone di un proprio subpool; pertanto, l'istanza del worker in cui viene generato l'allarme è quella responsabile dell'elevato utilizzo (nell'esempio, l'istanza del worker 3).
Potrebbe essere necessario un aggiornamento dell'hardware. Contattare l'assistenza Bequant .
Nel frattempo, il BQN dispone di meccanismi interni per mitigare l'elevato utilizzo di memoria, cercando di prevenire le perdite di traffico attraverso la riduzione della quantità di traffico ottimizzato.
Elevato utilizzo del pool DPDK
Ciò può essere causato da una configurazione NUMA errata: nei server NUMA, ci si aspetta che le schede di rete siano distribuite tra i due NUMA. Se tutte le schede di rete si trovano nello stesso NUMA, il pool DPDK dell'altro NUMA non verrà utilizzato, mentre il pool DPDK del NUMA che ospita tutte le schede di rete registrerà un utilizzo elevato.
Per risolvere il problema, è necessario riassegnare le schede di rete in modo che siano distribuite tra i due Numa del server. Il supporto tecnico di Bequant vi aiuterà in questo e, nel frattempo, anche a ottimizzare l'utilizzo del pool DPDK. Inoltre, è possibile deviare parte del traffico tramite la sezione Configurazione -> Impostazioni di ottimizzazione.
Elevato utilizzo di mpool
Se il problema riguarda solo alcune istanze worker, potrebbe essere causato da uno squilibrio nel traffico. BQN utilizza gli indirizzi IP degli abbonati per distribuire il traffico tra i worker disponibili. Se alcuni indirizzi IP concentrano una quantità eccessiva di traffico, i worker che li gestiscono potrebbero esaurire la memoria.
Vai su Statistiche->Abbonati->Top per tempo per vedere come è distribuito il traffico tra gli abbonati con l'utilizzo maggiore. Verifica se i primi della classifica concentrano molto più traffico rispetto agli altri.
Per verificare, clicca con il tasto destro sugli indirizzi IP con il maggior utilizzo per accedere alla dashboard dell'abbonato corrispondente e controlla il numero dell'istanza nella sezione " Dettagli aggiuntivi". Ad esempio, nell'esempio che stiamo seguendo, si tratterà dell'istanza 3. L'istanza deve corrispondere a quella riportata nei log di sistema.
Un elevato utilizzo di mpool può essere causato anche da un numero elevato di abbonati simultanei e/o da flussi di traffico intensi.
Questo problema richiederà un aggiornamento hardware. Nel frattempo, è possibile mettere in bypass gli indirizzi IP con traffico concentrato accedendo a Configurazione -> Impostazioni di ottimizzazione.
Elevato utilizzo della memoria di sistema
Ciò può essere causato da un elevato volume di traffico, da flussi simultanei di abbonati e/o di traffico e dallo scambio di dati di sincronizzazione con sistemi di fatturazione esterni.
La memoria verrà trasferita su disco, il che rallenterà notevolmente il server; pertanto, si consiglia di accedere a Configurazione -> Impostazioni di ottimizzazione e di abilitare il bypass di tutto il traffico durante l'aggiornamento della memoria.
Nessuna sincronizzazione RADIUS
Il RADIUS è configurato in Configurazione->RADIUS/REST/Fatturazione, ma non vengono visualizzate informazioni relative al RADIUS in Stato->Abbonati->Attributi abbonati: filtrando per " Assegnato da RADIUS " non viene visualizzato alcun abbonato.
Verifica della ricezione del traffico RADIUS
Per acquisire il traffico RADIUS, andare su Status->Interfaces->Link State, selezionare l'interfaccia di gestione (quella con la colonna MGT spuntata) e utilizzare come filtro “porta 1812 o porta 1813”:
Impostare il timeout di acquisizione su un periodo superiore all'intervallo di rendicontazione intermedio.
È inoltre possibile acquisire il traffico RADIUS tramite l'interfaccia a riga di comando (CLI). Connettersi tramite SSH:
Se non viene rilevato alcun traffico, i messaggi RADIUS non raggiungono il server BQN. . Vedi la sezione successiva.
Nessun messaggio RADIUS ricevuto
Se il firewall BQN è configurato (Configurazione->Interfacce->Firewall di gestione), è necessario aggiungere tutti gli indirizzi IP dei client RADIUS (in questo esempio, 10.10.10.10 e 10.10.10.11).
Se i messaggi RADIUS continuano a non essere ricevuti, è necessario verificare i restanti salti di traffico. Nel nostro esempio, i client RADIUS si trovano nella sottorete 10.10.10.0/24 e BQN nella sottorete 192.168.0.0/24. Verificare che esista una rotta valida tra le due sottoreti e che nessun firewall intermedio blocchi la porta UDP 1813 (contabilità RADIUS) e, se in modalità proxy RADIUS, la porta UDP 1812 (autenticazione RADIUS).
Controlla il registro di sistema
Se vengono ricevuti messaggi RADIUS, ma senza sincronizzazione RADIUS, controllare i log di sistema.
Vai su Amministrazione->Log->Sistema e utilizza l'espressione regolare “RADIUS”.
Se non viene individuata alcuna voce nel log di sistema, è possibile aumentarne il livello. Accedere al server BQN tramite SSH:
Attendi qualche istante e controlla nuovamente in Amministrazione->Log->Sistema utilizzando l'espressione regolare “RADIUS”.
Ad esempio, questa voce di log indica che l'indirizzo IP 10.10.10.10 è sconosciuto:
Vai su Configurazione->RADIUS/REST/Fatturazione->RADIUS e aggiungi l'indirizzo come client RADIUS valido.
Questa altra voce di log indica che la chiave segreta utilizzata dal client non corrisponde a quella presente nel BQN:
Accedere a Configurazione->RADIUS/REST/Fatturazione->RADIUS e verificare che la chiave segreta del client RADIUS sia corretta.
Abilita i log dell'API
Se vengono ricevuti messaggi RADIUS, ma senza sincronizzazione RADIUS, un'alternativa ai log di sistema sono i log API.
Accedi alla shell del server BQN tramite SSH:
E visualizza i log dell'API con il comando:
Un esempio di messaggio "Accounting Start" ricevuto correttamente e della corrispondente risposta inviata dal BQN al client RADIUS:
Il messaggio RADIUS associa la politica di tariffazione RA-30M/40M-60M/80M-50M/70M-2/3 all'indirizzo IP dell'abbonato 10.0.0.1.
Di seguito è riportato un esempio di messaggio "Accounting Start" ricevuto, che è stato elaborato e al quale è stata inviata una risposta "OK", ma che presenta un problema nel nome del tasso previsto dalla politica:
Non è stato possibile estrarre il nome della politica di limitazione dal messaggio RADIUS: policyName (n/a). In tal caso, consultare la sezione "Verifica dei parametri AVP".
Verifica i parametri AVP di RADIUS
Se vengono ricevuti e accettati messaggi RADIUS, ma il BQN non mostra alcun attributo proveniente da RADIUS, verificare nelle registrazioni del traffico RADIUS ricevuto che i messaggi contengano gli AVP previsti.
Inoltre, vai su Configurazione->RADIUS/REST/Fatturazione->RADIUS e verifica nella sezione "Selezione AVP " che l'AVP con la politica tariffaria sia presente nell'elenco (e quindi supportato da BQN) e che non venga ignorato. Ad esempio, se si utilizza l'AVP "Mikrotik-Rate-Limit":
Nessuna sincronizzazione REST
REST è configurato in Configurazione->RADIUS/REST/Fatturazione->REST, ma non vengono trovate informazioni relative a REST inStato->Abbonati->Attributi abbonati: filtrando per " Assegnato da REST " non viene visualizzato alcun abbonato.
Verifica della ricezione del traffico REST
Per acquisire il traffico REST, andare su Status->Interfaces->Link State, selezionare l'interfaccia di gestione (quella con la colonna MGT spuntata) e utilizzare come filtro “tcp e porta 3443”:
Invia alcune query REST all'indirizzo IP OAM di BQN.
È inoltre possibile acquisire il traffico REST tramite la CLI. Connettersi tramite SSH:
Se non viene rilevato alcun traffico, i messaggi REST non raggiungono il server BQN. Vedi la sezione successiva.
Nessun messaggio REST ricevuto
Se il firewall BQN è configurato (Configurazione->Interfacce->Firewall di gestione), è necessario aggiungere tutti gli indirizzi IP dei client REST (in questo esempio, 10.10.10.10 e 10.10.10.11).
Se i messaggi REST continuano a non essere ricevuti, è necessario verificare il resto dei salti di traffico. Nel nostro esempio, i client REST si trovano nella sottorete 10.10.10.0/24 e BQN nella sottorete 192.168.0.0/24. Verificare che esista una rotta valida tra le due sottoreti e che nessun firewall intermedio stia bloccando la porta TCP 3443.
Controlla il registro di sistema
Se vengono ricevuti messaggi REST, ma senza sincronizzazione REST, controllare i log di sistema.
Vai su Amministrazione->Log->Sistema e utilizza l'espressione regolare “REST|HTTP”.
Se non viene individuata alcuna voce nel log di sistema, è possibile aumentarne il livello. Accedere al server BQN tramite SSH:
Attendi qualche istante e controlla nuovamente in Amministrazione->Log->Sistema utilizzando l'espressione regolare “REST|HTTP”.
Ad esempio, questa voce di log indica che l'indirizzo IP 10.10.10.10i è sconosciuto:
Vai su Configurazione->RADIUS/REST/Fatturazione->REST e assicurati che l'indirizzo sia quello di un client REST valido.
Questa altra voce del registro indica che l'utente o la password dell'utente non sono corretti:
Vai su Configurazione->RADIUS/REST/Fatturazione->REST e verifica che l'utente e le password siano quelli utilizzati dal client REST.
Abilita i log dell'API
Se vengono ricevuti messaggi REST, ma senza sincronizzazione RADIUS, un'alternativa ai log di sistema sono i log dell'API.
Accedi alla shell del server BQN tramite SSH:
E visualizza i log dell'API con il comando:
Un esempio di query REST ricevuta correttamente e della risposta BQN:
Di seguito è riportato un esempio di query REST ricevuta con un URI sconosciuto (la query non è stata formulata correttamente):
Abilita le tracce API
Se abbiamo individuato un problema in una delle richieste, possiamo individuare quale di esse sia all'origine del problema attivando le tracce API. In questo modo verrà generato un file di traccia per ogni richiesta o risposta.
Accedi alla shell del server BQN tramite SSH:
Inoltre, BQN genererà le tracce delle ultime 5 richieste e risposte REST. Le tracce sono disponibili nella directory /opt/bqn/var/trace. Effettuare l'accesso tramite SSH:
La prima richiesta/risposta è corretta:
La seconda richiesta/risposta presenta un errore:
The POST request has a wrong body. Review the REST clientPOST request and compare it with the REST API reference manual. In this example,the POST body had a typo (double quotes after value missing): {"subscriberId": "myid}
Problema relativo al certificato REST
Se una richiesta all'API REST genera un errore relativo alla verifica del certificato, ad esempio:
Il motivo è che il certificato BQN è autofirmato e il client deve disabilitare la convalida del certificato. Ad esempio, utilizzando curl:
E utilizzando python:
Versione TLS di REST
BQN utilizza il protocollo TLS 1.2. Alcune nuove versioni di python rifiutano TLS 1.2 per impostazione predefinita. Per farlo accettare, utilizzare il seguente codice:
Un esempio completo è disponibile qui.
Nessuna sincronizzazione della fatturazione
Se il sistema di fatturazione è configurato e l'icona Fatturazione nella Dashboard è rossa, l'accesso al sistema di fatturazione non è possibile.
Cliccare sull'icona della fatturazione per accedere alla pagina dello stato di fatturazione:
In questo esempio, la sincronizzazione è avvenuta con successo alle 12:13:52, recuperando 1000 abbonati, ma successivamente c'è stato un tentativo fallito. È possibile forzare un tentativo di sincronizzazione premendo il pulsante Sincronizza ora.
Se il guasto persiste, procedere come segue:
- Verificare le credenziali di accesso al sistema di fatturazione: chiave API, nome utente/password, ecc. Queste credenziali devono essere registrate nel sistema di fatturazione.
- In alcuni sistemi di fatturazione (ad esempio Splynx), è necessario concedere l'accesso a specifiche chiamate API REST.
- In alcuni sistemi di fatturazione (ad esempio Azotel), è necessario autorizzare anche l'indirizzo IP di origine da cui si accede al sistema di fatturazione. Si tratta dell'indirizzo IP pubblico che raggiunge il sistema di fatturazione dall'indirizzo di gestione del BQN (lo stesso se il server BQN utilizza un indirizzo IP pubblico).
- Verificare che sia possibile determinare l'indirizzo IP del server di fatturazione. In caso contrario, il BQN visualizzerà 0.0.0.0 nel campo "Server" della sezione "Stato fatturazione". Ciò può essere dovuto a un nome server sconosciuto o al fatto che il BQN non abbia alcun server DNS configurato. Per configurare un server DNS, accedere alla pagina dell'interfaccia di gestione.
- Verificare che l'indirizzo IP di fatturazione sia raggiungibile dal server BQN:
Controlla il registro di sistema
Vai su Amministrazione->Log->Sistema e utilizza l'espressione regolare “billing”.
Se si verifica un problema nel collegarsi al server di fatturazione, verrà visualizzato un messaggio del tipo:
Se non viene individuata alcuna voce nel log di sistema, è possibile aumentarne il livello. Accesso al server BQN tramite SSH:
Attendi qualche istante e controlla nuovamente in Amministrazione->Log->Sistema utilizzando l'espressione regolare “billing”:
In questo primo esempio, una richiesta ha restituito un errore: il codice HTTP è 200, ma contiene il codice di errore REST RATE_LIMITED.
E se cerchi %ERR-EINVAL:
Il BQN lamenta di non riuscire a recuperare i “conti” dal sistema di fatturazione.
Questi due log indicano la causa principale: il problema si verifica perché la chiave API ha superato il limite di richieste consentito. La soluzione sarebbe quella di aumentare tale limite.
Un altro esempio di errore nella richiesta:
In questo caso, il sistema di fatturazione restituisce un codice HTTP 401 con il codice interno UNAUTHORIZED. Pertanto, la causa principale in questo altro esempio risiede nelle credenziali di accesso: o la chiave API o le credenziali complementari non sono corrette, oppure il BQN sta accedendo al sistema di fatturazione da un indirizzo IP non autorizzato.
Abilita i log dell'API
Se il server di fatturazione è raggiungibile ma la sincronizzazione non va a buon fine e non viene rilevata alcuna voce nel syslog, approfondire l'analisi abilitando i log dell'API. Accedere alla shell del server BQN tramite SSH:
E visualizza i log dell'API con il comando:
Un esempio di richiesta andata a buon fine (in questo caso, un POST per ottenere l'array “products”):
Ecco un esempio di richiesta non andata a buon fine (relativa a un tentativo di interrogare gli “account” di fatturazione):
Abilita le tracce API
Se abbiamo individuato un problema in una delle richieste, possiamo individuare quale di esse sia all'origine del problema attivando le tracce API. In questo modo verrà generato un file di traccia per ogni richiesta o risposta.
Accedi alla shell del server BQN tramite SSH:
Inoltre, il BQN genererà le tracce delle ultime 5 richieste e delle ultime 5 risposte tra il BQN e il sistema di fatturazione. Le tracce sono disponibili nella directory /opt/bqn/var/trace. Effettuare l'accesso tramite SSH.
Cerca una richiesta che riguardi gli “account”:
Una volta identificata la richiesta (0001 in questo esempio), controlla la risposta con lo stesso ID:
In questo caso, il problema si verifica perché la chiave API ha superato il limite di richieste consentito. La soluzione sarebbe quella di aumentare tale limite.
Interagisci direttamente con il server di fatturazione utilizzando curl
Se la causa del problema rimane sconosciuta, è possibile inviare una richiesta direttamente al sistema di fatturazione utilizzando il comando `curl` di Linux. È possibile farlo da un server diverso dal server BQN, a meno che il sistema di fatturazione non sia accessibile solo dal BQN. Questa operazione richiede una conoscenza approfondita del sistema di fatturazione e delle convenzioni relative alle richieste API. Ad esempio, per inviare una richiesta al sistema di fatturazione di Azotel:
Nessun server NTP sincronizzato
Se l'icona NTP è gialla, l'NTP non è configurato. Fare clic sull'icona per accedere alla pagina di configurazione.
Se i server NTP sono configurati ma il BQN non può sincronizzarsi con nessuno di essi, l'icona NTP nel dash sarà arancione:
Una variazione improvvisa dell'ora del sistema, dovuta alla mancanza di sincronizzazione NTP, può comportare brevi perdite di servizio mentre il sistema si adatta. Per evitare che ciò accada, è necessario che almeno un server NTP sia sempre sincronizzato.
È possibile controllare l'elenco dei server NTP configurati in Amministrazione->Data del sistema->Server NTP.
È necessario sincronizzare almeno un server NTP. Nell'esempio precedente, il server NTP 145.238.203.14 è stato scelto per la sincronizzazione dell'orologio (indicato dal simbolo * accanto all'indirizzo IP del server) ed è stato contattato 36 secondi fa (colonna WHEN).
Se non è disponibile un server NTP, il BQN mostrerà il messaggio di avviso NTP non sincronizzato, come nella finestra seguente:
To solve the issue, if you have a local NTP server, add it to the list clicking the <i class="fa-solid fa-ellipsis-vertical"></i> menu icon and selecting Add Server…
Se non si dispone di server NTP locali, assicurarsi che la porta UDP 123 sia aperta dall'IP di gestione del BQN verso Internet, anche nel firewall del BQN, se attivato.
Problemi del disco
Per controllare lo stato del disco di sistema, fare clic sull'icona DISK del dashboard:
L'icona del disco è arancione (stato di avviso) quando è libero meno del 15% della memoria del disco.
La scheda di rete Intel XL710 non raggiunge i 40 Gbps di traffico PPPoE
Una scheda di rete Intel XL710 che gestisce il traffico PPPoE può essere limitata a un throughput di 10 Gbps nonostante abbia negoziato un collegamento da 40 Gbps. Un possibile motivo è che la scheda non esegue il bilanciamento del carico del traffico PPPoE e i pacchetti vengono consegnati a un singolo processo, limitando il throughput massimo.
La funzionalità di distribuzione dei pacchetti nella scheda Intel è implementata da Intel Dynamic Device Personalization (DDP). Devono essere soddisfatte tre condizioni:
- Il pacchetto BQN bqnkernel deve essere R3.0.19 o successivo. Richiede un riavvio del sistema dopo l'installazione del pacchetto.
- La versione del firmware della scheda deve supportare il DDP con bilanciamento del carico PPPoE (vedere la sezione seguente).
- Il pacchetto BQN bqn deve essere R4.27 o successivo.
Aggiornamento firmware scheda di rete
La seguente procedura di aggiornamento del firmware funziona solo con le schede di rete Intel. Le schede di rete di produttori diversi da Intel che utilizzano un chipset Intel non possono essere aggiornate con questa procedura.
La distribuzione PPPoE richiede la versione 7.0 del firmware e la versione 1.1.6.1 del DDP (in teoria potrebbe funzionare anche la versione 6.01 del firmware, ma non è stato verificato in laboratorio).
La procedura seguente comporta l'interruzione del traffico e il riavvio del server, pertanto il server BQN deve essere tolto dal percorso del traffico.
Innanzitutto, per verificare la versione del firmware della scheda, le porte di interfaccia XL710 devono essere accessibili dal sistema operativo, ovvero non devono essere sotto il controllo DPDK. Pertanto, se una delle porte di interfaccia fa parte di un wire, deve essere impostata in modalità pcap. Nella GUI BQN, andare su Configuration->Interfaces->Data Wires (Configurazione-> Interfacce->Cavi dati ) e rimuovere i wires le porte di quella scheda di rete, quindi ricrearli con le porte in modalità pcap.
Una volta fatto ciò, le interfacce dovrebbero essere visibili ed è possibile ottenere la versione del firmware utilizzando il comando ethtool:
In questo esempio, la versione del firmware è 5.0 e la scheda necessita di un aggiornamento. Il resto della sezione descrive come effettuare tale operazione.
Per effettuare un aggiornamento del firmware, il server deve avviarsi in modo che il kernel del sistema operativo consenta tali modifiche. Eseguire un backup del file di configurazione di grub prima di modificarlo:
Nella prima voce del menu, aggiungi iomem=relaxed nella riga linuxboot . La riga sarà simile a questa:
Salvare il file e riavviare il server.
Scaricare lo strumento di aggiornamento Intel per la famiglia X700 sul proprio PC, decomprimerlo e trasferire il pacchetto Linux al server BQN. Esempio:
Andare sul server BQN per decomprimere il tarball ed eseguire lo strumento di aggiornamento:
Lo strumento vi guiderà attraverso il processo di aggiornamento del firmware per tutte le schede di rete X710 rilevate nel sistema.
Dopo aver completato l'aggiornamento del firmware, ripristinare i wires modalità normale (senza pcap). Nell'interfaccia grafica BQN, andare su Configurazione->Interfacce->Cavi dati e rimuovere i wires le porte di quella scheda di rete, quindi ricrearli con le porte in modalità normale (casella pcap non selezionata).
Rimuovere il parametro iomem=relaxed dal file di configurazione di grub e riavviare il sistema:
Verifica che la distribuzione del carico PPPoE sia abilitata
Una volta che il firmware di rete, i pacchetti bqnkernel e bqn sono nella versione corretta, la distribuzione del carico di traffico PPPoE dovrebbe essere abilitata per default in ogni porta di rete dell'XL710. Ad esempio:
Il comando show indica che è presente un profilo DDP (per PPPoE) e che la distribuzione del carico è abilitata.
Disabilitazione della distribuzione del carico PPPoE
Se ci sono problemi con la scheda di rete e il profilo DDP, è possibile disabilitare il DDP utilizzando il comando no ddp pppoe in tutte le porte della scheda di rete, seguito dal comando system interface ddp reset in una qualsiasi di tali interfacce. Ad esempio:
Il comando di sistema ddp reset scarica il profilo DDP senza necessità di riavviare il sistema. Si noti che è sufficiente applicarlo a una delle porte per ripristinare l'intera scheda di rete.
Se il problema persiste, mantenere il no ddp pppoe in tutte le porte della scheda di rete e riavviare il sistema.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.