How-to : Instradare tra un server CSA virtualizzato e un'installazione HOS virtualizzata

2015-03-10

How-to : Instradare tra un server CSA virtualizzato e un'installazione HOS virtualizzata

Machine-translated — the English original is authoritative.

Probabilmente molti di voi, esperti di networking, non comprenderanno la necessità di un post del genere. Essendo io nuovo sia di OpenStack che del networking, questo processo non mi era chiaro.

Il diagramma seguente illustra la configurazione che stavo utilizzando: su un laptop Windows 7 stavo eseguendo VMware Workstation 10 e, all'interno di questo, avevo una VM Cloud Service Automation (CSA) autocontenuta. La rete di questa VM era in bridge con l'interfaccia del mio laptop, consentendo alla VM di ricevere un indirizzo DHCP sulla mia rete locale 192.168.1.0/24. Il secondo sistema che stavo utilizzando era un DL360G7 con Ubuntu 14.04 come sistema operativo host, anch'esso collegato alla rete 192.168.1.0/24. Questo DL360G7 ospitava un'installazione virtuale di Helion OpenStack v1.1 [il processo di installazione può essere trovato in questo post precedente].

CSA_HOS_Networking

Passaggio 1

Ovviamente, deve esistere un instradamento sul server host Windows 2k8 di CSA verso gli endpoint API del servizio HOS che desidero utilizzare, i quali si trovano su una rete 192.0.2.0/24. Questo non esiste di default, come si può vedere esaminando la tabella di instradamento dell'host di seguito.

netstat -rn

CSABeforeRouteAdd
Un rapido ping dal server CSA a uno degli host HOS conferma inoltre il problema di instradamento.

ping 192.0.2.2 /t

CSAPingBeforeRouteADD
La rete 192.0.2.0/24 è virtualizzata sul DL360G7 e può essere accessibile in remoto solo attraverso l'interfaccia fisica sul DL360G7, che ha un indirizzo IP di 192.168.1.13. Questo è chiamato indirizzo gateway.

Apri una finestra del prompt dei comandi sul server CSA: Start -> Esegui -> cmd
Inserisci un instradamento verso la rete HOS utilizzando il seguente comando:

route add -p 192.0.2.0 mask 255.255.255.0 192.168.1.13

Gli instradamenti di rete sull'host CSA dovrebbero ora apparire qualcosa del genere (siamo interessati solo alla nuova aggiunta di 192.0.2.0 – è probabile che sul tuo sistema ci siano molte altre rotte).

netstat -rn

CSAAfterRouteAdd
Ora, quando esegui il ping a un server sulla rete 192.0.2.0/24, dovresti vedere una risposta dal server host DL360G7. Non farti prendere dal panico! – Sì, non sta ancora funzionando, ma almeno puoi vedere che l'host corretto sta ora rispondendo alla tua richiesta.

ping 192.0.2.2 /t

CSAPingFailFollowingRouteAdd
Ora è il momento di spostarsi sul server host Ubuntu DL360G7. Lascia in esecuzione il ping sul server host CSA [usa l'opzione /t].

Passaggio 2

Se osserviamo l'interfaccia host ora sul server host HOS DL360G7, possiamo vedere che la richiesta di ping sta arrivando, tuttavia non sta ricevendo una risposta.

tcpdump -ni em1 icmp

SeedHostReceivesPingbutNoResponse
Le tabelle di instradamento sul server Ubuntu indicano dove cercare il prossimo.

netstat -rn

DL360G7Routes
Tutto il traffico per la rete 192.0.2.0/24 viene instradato attraverso l'interfaccia virbr0.
Esamina l'output su questa interfaccia virbr0 per vedere cosa sta succedendo al traffico.

tcpdump -c 10 -ni virbr0

tcpdumpFailVibr0
Non ci sono segni di alcuna richiesta di ping dall'host CSA 192.168.1.12 che arriva fino a questo punto.
Quindi il problema è tra l'interfaccia em1 e l'interfaccia virtuale virbr0 – cosa c'è tra queste interfacce? Iptables! noto anche come firewall dell'host.
Una rapida occhiata agli iptables sull'host Ubuntu DL360G7 rivela l'ultimo ostacolo nella ricerca di un instradamento tra i sistemi – filtri che rifiutano il traffico esterno.

iptables-save

IPTABLES_REJECT_RULE_for_Virbr0
L'eliminazione di questi due filtri dovrebbe consentire a tutto il traffico di instradarsi tra i due host.

iptables -t filter -D FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable

FirstRuleChangeonIPTABLES

iptables -t filter -D FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable

SecondRuleChange_Success
Ora il ping sta ricevendo una risposta dal server di destinazione. Diamo anche un'occhiata al traffico sull'interfaccia virbr0 – dovremmo ora vedere il pacchetto di risposta ICMP.

tcpdump -ni virbr0

tcpdumpSuccessVibr0
Ora c'è piena connettività tra la VM CSA ospitata sul laptop e Helion OpenStack ospitato sul server DL360G7. Prossimo compito – iniziare a usare CSA per orchestrare HOS….

52.650156
-2.883185

Originally published on allthingscloud.eu (2015-03-10).

← All posts