Layer 2

Note prima dell'utilizzo

Oplon Global Distributed Gateway ADC layer 2 è lo funzionalità di bilanciamento a layer 2 che permette di bilanciare connessioni effettuando il DNAT dell'indirizzo IP sorgente.

Per poter utilizzare la funzionalità OPLON ADC layer 2 è necessario utilizzare la release Oplon 9.9.0 o superiore. Se provenienti da release inferiore a 9.9.0 è necessario eseguire l'update a nuova release con l'utility messa a disposizione sul sito OPLON (vedere manuale LBL_GDG_InstallUpdate) ed eseguire l'update del sistema operativo attraverso connessione Internet.

Gestione pacchetti TCP e UDP layer 2

Oplon ADC layer 2 utilizza il sistema di accodamento di routing dei pacchetti del kernel che si impostano attraverso i comandi iptables per essere poi elaborati da LBL.

Si utilizzano per ogni flusso due code, la prima che riceve i pacchetti dal client attraverso una interfaccia di rete, la seconda riceve i pacchetti di risposta provenienti dagli endpoint attraverso un'altra interfaccia di rete.

Nell'esempio di seguito, due proxy ricevono traffico dall'interno del datacenter in bilanciamento layer 2 e ritornano i pacchetti verso le rispettive interfacce verso il sistema ADC.

image1

Le richieste che provengono dai client verso l'interfaccia enp0s10 escono dall'interfaccia enp0s11 con lo stesso IP del client modificato dall'ADC. Una volta elaborati dai proxy i pacchetti di risposta vengono instradati verso l'ADC che provvede a rimodulare i pacchetti per consegnare la risposta ai client che ne hanno fatto richiesta.

Le porte di richiesta del client e del server possono essere differenti, anch'esse verranno modificate dall'ADC durante lo scambio.

Per creare le code a Layer 2 si deve agire a 2 livelli:

1) Generazione delle code di ingresso e uscita a livello stack IP

2) Impostazione dell'utilizzo delle code da parte dell'ADC per il trattamento dei pacchetti

Creazione code stack IP

Per gestire i pacchetti a layer 2 ed il loro instradamento, Oplon ADC utilizza il gestore di code realizzato con iptables.

Per ogni flusso logico Oplon ADC utilizza 2 code, la prima associata all'interfaccia di comunicazione con i client, la seconda associata con l'interfaccia di comunicazione verso i servizi. Le code vengono numerate per essere poi utilizzate da Oplon ADC.

Oplon ADC può gestire innumerevoli flussi associati a innumerevoli code simultaneamente.

Nello schema di seguito si prende ad esempio l'utilizzo della componente a Layer 2 per poter bilanciare e mettere in alta affidabilità due proxy. La coda 0 è associata alla scheda di rete verso i client, la coda 1 è associata alla scheda di rete verso i proxy.

image2

Per eseguire il setup delle code eseguire da root i seguenti comandi.

Per TCP/IP

# iptables -t mangle -A PREROUTING -i enp0s10 -p tcp -s 192.168.43.0/24
-j NFQUEUE --queue-num 0
# iptables -t mangle -A FORWARD -i enp0s17 -p tcp -s 192.168.31.0/24 -j
NFQUEUE --queue-num 1

Per UDP/IP

# iptables -t mangle -A PREROUTING -i enp0s10 -p udp -s 192.168.43.0/24
-j NFQUEUE --queue-num 2
# iptables -t mangle -A FORWARD -i enp0s17 -p udp -s 192.168.31.0/24 -j
NFQUEUE --queue-num 3

Per verificare a basso livello il flusso dei pacchetti utilizzare su due terminali i seguenti comandi applicati alle due code. I comandi visualizzano i flussi dei pacchetti con la loro direzione:

Flusso dati interfaccia verso i client

# tcpdump -i enp0s10 port 80 or port 8080 or port 3128

Flusso dati interfaccia verso i servizi

# tcpdump -i enp0s17 port 8080 or port 80 or port 3128

Un'altra operazione da effettuare è impostare lo stack socket ad eseguire il forwarding dei pacchetti.

# sysctl net.ipv4.ip_forward=1

Per verificare la lista delle code assegnate eseguire:

# iptables -t mangle --L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
NFQUEUE tcp -- 192.168.43.0/24 anywhere NFQUEUE num 0

Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
NFQUEUE tcp -- 192.168.31.0/24 anywhere NFQUEUE num 1

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Per verificare l'attività sulle single code eseguire:

# cat /proc/net/netfilter/nfnetlink_queue
0 25214 0 2 65531 0 0 97 1
1 2691274501 0 2 65531 0 0 120 1

a- queue number

b- peer portid: good chance it is process ID of software listening to the queue

c- queue total: current number of packets waiting in the queue

d- copy mode: 0 and 1 only message only provide meta data. If 2 message provide a part of packet of size copy range.

e- copy range: length of packet data to put in message

f- queue dropped: number of packets dropped because queue was full

g- user dropped: number of packets dropped because netlink message could not be sent to userspace. If this counter is not zero, try to increase netlink buffer size. On the application side, you will see gap in packet id if netlink message are lost.

h- id sequence: packet id of last packet

i- 1

Associazione della coda di pacchetti al routing ADC

Oplon ADC esegue il forwarding dei pacchetti in DNAT mantenendo nel contempo la sessione. Per associare le code all'elaborazione DNAT o DANT_UDP ad opera dell'ADC è sufficiente utilizzare dei template già presenti nelle distribuzioni.

Template: DNAT e DNAT_UDP

Dopo il login andare in: ADC Settings > ADCs > Selezionare i listeners dei templates

image3

Con la lista dei listener template andare in search DNAT

image4

Il search DNAT o DNAT_UDP evidenzia il listener template di associazione code Layer 2.

image6

Eseguire copia del listener template sul modulo, in questo caso A10_LBLGoPlatform:

image7

Ritornando in ADC Settings > ADCs il risultato è il seguente:

image8

Ripetere l'operazione anche per il gruppo di endpoint:

image26

Su search digitare DNAT o DNAT_UDP:

image9

Una volta digitato DNAT or DNAT_UDP copiare l'endpoint grouping template sul modulo, in questo caso A10_LBLGoPlatform:

image10

Copia dell'endpoint grouping sul modulo:

image11

Tornando alla visualizzazione ADC Settings > ADCs la situazione è la seguente:

image12

Salvare le impostazioni effettuate fino ad ora:

image27

Eseguire il salvataggio delle impostazioni proposte:

image13

Indicare il motivo del salvataggio:

image14

Una volta copiato i template Layer 2 sul modulo, associare le code al listener:

ADC Settings > ADCs > Edit del modulo:

image15

Espandere il pannello Listeners e premere il pulsante See details:

image16

Il listener presenterà le seguenti carattristiche: osiLayer impostato a 2; layer2QueueIn impostata a 0 e layerQueueOut impostata a 1. In questo caso non vi sarà necessità di modificare le code in quanto le abbiamo precedentemente generate rispettivamente a 0 e 1.

image17

Si noti anche che l'indicazione dell'indirizzo del listener è a 0.0.0.0 e la porta è a 80. Questi valori non vengono presi in considerazione in quanto sono le code che effettuano la creazione della coda in un determinato NIC con determinati filtri. OPLON ADC provvederà comunque in maniera trasparente ad eseguire eventuali port rewriting nel caso i pacchetti dovessero avere delle porte differenti tra i pacchetti ricevuti ed i pacchetti inoltrati verso i servizi.

Il trattamento dell'instradamento verso gli endpoint è perfettamente simili al trattamento del layer 4. Saranno indicati gli indirizzi e le porte a cui rispondono i servizi:

IPORTANTE: Se la porta dell'endpoint è minore o uguale a 0, il motore di forwarding esegue il port forwardig riportando sul pacchetto la stessa porta di ingresso. Non è necessario impostare port forwarding sul listener, verrà eseguito in automatico.

ADC Settings > ADCs > Edit sul modulo interessato > Espansione del pannello Endpoints Grouping > See details

image18

Entrare nel dettaglio del dominio (che in questo caso è vuoto):

image19

Modificare, aggiungere o togliere gli endpoit. In questo caso abbiamo due endpoint che rispondono alla porta 8080.

image20

È Molto importante assegnare dei nomi associativi agli endpoit perché questi ci serviranno per eseguire gli healthcheck e disabilitare il routing in caso di irraggiungibilità di uno o più servizi.

image21

Se il modulo è in stato di running eseguire il reinit.

image22

Impostazione health check dei servizi

Il sistema a layer 2 è in grado di ridirottare le richieste sui servizi superstiti in base alla loro vitalità. Per poter verificare la vitalità dei servizi impostare gli healthcheck attraverso il modulo: Reliability tools > Services Check > Edit

image23

Dopo la selezione del modulo impostare gli health check sui servizi assegnando i nomi associativi:

image24

Salvare ed eseguire i reinit indicati:

image25

Setup routing lato servizi (Linux)

Affinché i servizi instradino correttamente i pacchetti provenienti dall'ADC è necessario eseguire il setup del routing nei rispettivi sistemi che contengono i servizi.

Si dovrà forzare, con gli strumenti messi a disposizione dei singoli produttori del sistema operativo o dei prodotti, i pacchetti a ritornare nel NIC di provenienza. Di seguito l'esempio non esaustivo dell'argomento ma utile per poterlo poi interpretare ed adattare nelle singole installazioni:

Impostazione di due tabelle mnemoniche "1 rt_dnatnet" e "2 rt_internet":

vi /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0   unspec
#
# local
#
#1  inr.ruhep
1   rt_dnatnet
2   rt_internet

Impostare da utente root il routing dei pacchetti provenienti dall'ADC e come gateway impostare l'ADC stesso:

# ip route add 192.168.31.0/24 dev enp0s17 src 192.168.31.11 table rt_dnatnet
# ip route add default via 192.168.31.1 dev enp0s17 tab rt_dnatnet
# ip rule add tab rt_dnatnet from 192.168.31.11

Per verificare il traffico a basso livello e le direzioni dei pacchetti eseguire il seguente comando:

# tcpdump -i enp0s17 port 80 or port 8080 or port 3128

Supporti e template

A titolo di template, è possibile trovare una serie di script Linux di impostazione del routing sia a livello ADC sia a livello di servizio in:

(LBL_HOME)/legacyBin/Linux/ProxyDNAT

+---CentOSNetConfProxy
|   +---System000
|   |       CentOS_Simmetric.sh
|   |       CentOS_SimmetricInternet.sh
|   |       CentOS_SimmetricView.sh
|   |       ifcfg-BACKEND
|   |       ifcfg-DNATNET
|   |       ifcfg-INTERNET_DHCP
|   |       ifcfg-WIRELESS
|   |       README.txt
|   |
|   \---System001
|           CentOS_Simmetric.sh
|           CentOS_SimmetricInternet.sh
|           CentOS_SimmetricView.sh
|           ifcfg-BACKEND
|           ifcfg-DNATNET
|           ifcfg-INTERNET_DHCP
|           ifcfg-WIRELESS
|           README.txt
|
\---NetConfVAPP
        CentOS_NFQUEUE.sh
        CentOS_NFQUEUEView0.sh
        CentOS_NFQUEUEView1.sh
        CentOS_NFQUEUEView2.sh
        CentOS_NFQUEUEView3.sh

Rendere persistenti le regole di routing

ATTENZIONE: è necessario che le regole di routing e le impostazioni delle code siano rese persistenti e che al riavvio delle singole VAPP o ai singoli sistemi operativi che erogano i servizi siano impostate automaticamente e verificate