sdwan cisco vipitela ambiente di laboratorio, config e test use-case: filtering network – route leaking – FW insertion – Hub&Spoke
12.07 2023 | by massimilianosdwan cisco vipitela ambiente di laboratorio e test use-case: filtering network – route leaking – FW insertion – Hub&Spoke Architettura […]
https://www.ingegnerianetworking.com/wp-content/uploads/2023/07/sdwan1-41a.png
sdwan cisco vipitela ambiente di laboratorio e test use-case: filtering network – route leaking – FW insertion – Hub&Spoke
Architettura fisica di lab:
Architettura logica di lab:
Public Internet Network: 91.101.7.0/24
MPLS Private Network: 172.16.20.0/24
Il piano di indirizzamento per i link WAN (public-internet) e MPLS (mpls) è il seguente:
Cloud Network (Orchestrator, CP and Manage): 10.10.1.0/24 con gateway .254
Gli indirizzi come System IP node assegnati sono indicati in tabella
Le reti LAN assegnate ai rispettivi Siti sono:
Topologia Laboratorio vMANAGE SETUP:
Topologia Laboratorio Configurazione Controller:
Nota: la configurazione VPN 0 viene indicata di seguito con i tunnel-interface
Topologia Laboratorio BGP Cloud Internet, MPLS e Border-Router:
CREAZIONE CERTIFICATI:
Da una VM Linux (oppure dal proprio PC via WSL) procedere con la creazione del certificato:
openssl genrsa –out CA.key 2048
openssl req –new –x509 –days 365 –key CA.key –out CA.crt
COPIA CERTIFICATO To CONTROLLER:
Copiare il certificato dalla propria macchina (VM/PC) ai Controllers tramite protocollo SCP (basato su SSH):
scp CA.crt admin@192.168.2.101:
scp CA.crt admin@192.168.2.102:
scp CA.crt admin@192.168.2.103:
COPIA CERTIFICATO To vEDGE:
scp CA.crt admin@192.168.2.104:
scp CA.crt admin@192.168.2.105:
scp CA.crt admin@192.168.2.106:
scp CA.crt admin@192.168.2.107:
scp CA.crt admin@192.168.2.112:
INSTALLAZIONE CERTIFICATO To CONTROLLER
Collegarsi in SSH ai Controllers (tutti e tre) ed entrare con vshell per verificare il certificato copiato come nella slide precedente, sia realmente presente.
vshell
ls
Se presente, uscire dalla vshell e procedere con l’installazione tramite il comando:
request root-cert-chain install /home/admin/CA.crt
Successivamente accedere al vMANAGE con il seguente indirizzo URL per la sincronizzazione della RootCA
https://<vmanage_ip_address>/dataservice/system/device/sync/rootcertchain>
INSTALLAZIONE CERTIFICATO To vEDGE
Se presente, uscire dalla vshell e procedere con l’installazione tramite il comando:
request root-cert-chain install /home/admin/CA.crt
Upload File SerialFile.vipitela
Questo file è un file che deve essere aggiornato tramite il proprio Smart Account Cisco dal portale License.
vMANAGE Menu: Configuration > Devices > WAN Edge List
Dopo aver effettuato l’upload, la lista di vEDGE appare:
ONBOARDING CONTROLLER
vMANAGE basic configuration
Accedere al vMANAGE tramite GUI usando le credenziali precedentemente configurate:
Menu: Administration > Settings
- Organization Name: <organization-name>
- vBOND address: 10.10.1.21
Successivamente, nella sessione “Controller Certificate Authorization” modificare il valore, da “Cisco” a “Enterprise Root Certificate”, andando a selezionare, tramite l’opzione “Select a File”, il file CA.crt precedentemente creato e copiato all’interno di ogni Controller.
Si aprirà un pop-up del TUO PC, assicurati di avere il file salvato in locale; in alternativa, collegarsi in SSH su uno dei controller e tramite comandi linux copiare il contenuto del file “CA.crt” (da dentro la vshell usare il comando “cat”).
vBOND basic configuration
Per importare il vBOND recarsi in:
vMANAGE Menu: Configuration > Devices > Controllers > Add Controller
Inserire i dati richiesti, senza selezionare «Generate CSR», questo lo genereremo dopo in modo autonomo
Successivamente possiamo creare il CSR per ogni singolo device: procediamo a generare il CSR per il vBOND
vMANAGE Menu: Configuration > Certificates > Controllers > Add Controller
Scarichiamolo e rinomiamo con vBond.csr
Ora tramite PC, andiamo a creare il certificato per il device usando la chiave ed il certificato precedentemente creati
openssl x509 –req –in vBond.csr –CA CA.crt –Cakey CA.key –Cacreateserial –out vBond.crt –days 2000 –sha256
Per concludere
vMANAGE Menu: Configuration > Certificates > Controllers > Add Controller
Ed installiamo il certificato del vBond
Verifica che in Configuration > Devices > Controllers, nella colonna «certificate status» il valore sia = Installed
vSMART basic configuration
Per importare il vSMART recarsi in:
vMANAGE Menu: Configuration > Devices > Controllers > Add Controller
Inserire i dati richiesti, senza selezionare «Generate CSR», questo lo genereremo dopo in modo autonomo
Successivamente
vMANAGE Menu: Configuration > Certificates > Controller
Procediamo a generare il CSR per il vSMART; lo scarichiamo e lo rinomiamo in vSmart.csr
openssl x509 –req –in vSmart.csr –CA CA.crt –Cakey CA.key –Cacreateserial –out vBond.crt –days 2000 –sha256
Verifica che in Configuration > Devices > Controllers, nella colonna «certificate status» il valore sia = Installed
vMANAGE basic configuration
Per il vMANAGE non dobbiamo eseguire le operazioni viste in precedenza svolte per gli altri due Controllers.
E’ necessario solo generare il CSR e caricare il certificato firmato
vMANAGE Menu: Configuration > Certificate > Controllers
Inserire i dati richiesti, senza selezionare «Generate CSR», questo lo genereremo dopo in modo autonomo
Generiamo il CSR per il vMANAGE, lo scarichiamo e lo rinomiamo in vManage.csr
openssl x509 –req –in vManage.csr –CA CA.crt –Cakey CA.key –Cacreateserial –out vBond.crt –days 2000 –sha256
Ed infine, verifica che in Configuration > Devices > Controllers, nella colonna «certificate status» il valore sia = Installed
ONBOARDING vEDGE
Per l’Onboarding dei vEDGE, dobbiamo ottenere i seguenti parametri:
- UUID
- OTP
Per ottenerli, dalla lista dei vEDGE:
vMANAGE Menu: Configuration > Devices > WAN Edge List
Generando la configurazione «Cloud-Init» verrà visualizzato un documento con all’interno molteplici valori, tra cui UUID ed OTP
- UUDI
path: /etc/viptela/uuid
content: 4917838e-3d3c-XXXX-XXXX-cf15e8f63c33 [XXXX messe volutamente]
- OTP
path: /etc/viptela/otp
content: 52782472d0ecXXXXXXXX4c2705689a14 [XXXX messe volutamente]
Una volta copiati questi valori, accediamo in SSH ai vEDGE ed applichiamo il seguente comando:
request vedge-cloud activate chassis-number <UUID> token <OTP>
Che si trasforma in
request vedge-cloud activate chassis-number 4917838e-3d3c-XXXX-XXXX-cf15e8f63c33 token 52782472d0ecXXXXXXXX4c2705689a14
VERIFICA della effettiva riuscita dell’onboarding Controller ed Edge
Nella home del vMANAGE verificare la visibilità dei Controllers
Dal Menu: Configuration > Devices > Controllers
Verificare che tutti i Controllers siano nello stato di «Sync» e che il System-IP sia visibile:
VERIFICA CONTROLLER CONNECTION tramite CLI
vMANAGE
vSMART
vBOND
Configurazione VPN 0 TUNNELS
VERIFICA CONTROL-PLANE from vSMART
Dalla CLI del vSMART possiamo verificare le connessioni stabilite (UP) attraverso i seguenti parametri:
VERIFICA CONTROL-PLANE from vSMART protocol OMP
Dalla CLI del vSMART possiamo i Peers attivi (UP) per il protocollo OMP attraverso i seguenti parametri:
VERIFICA CONTROL-PLANE from vEDGE (example from vEDGE site-40)
Dalla CLI del vEDGE (Site40_vEdge1) possiamo verificare le connessioni stabilite (UP) attraverso i seguenti parametri:
VERIFICA DATA-PLANE from vEDGE (example from vEDGE site-40)
TEST USE-CASE 1: FILTERING NETWORK using CENTRALIZED POLICY
Lo scopo di questo use-case è quello di creare una centralized policy di network filtering per una determinata prefix e quindi stabilire una azione di deny verso il resto del Branch Office (altri site):
- La prefix soggetta al filtraggio è la loopback0 del Site40 con indirizzo 10.255.255.41/32
- Policy Name: Site40_Loopback0_deny-BRANCH
- Direction: out
- Site List Name: Branch
Policy Name: Site40_Loopback0_deny-BRANCH à PREVIEW (questa sintassi NETCONF viene pushata all’interno del vSMART)
La possibilità di definire la centralized policy passa attarverso la definizione di Lists e successivamente da Topology
Menu: Configuration > Policies > Custom Options > Lists > Prefix > + New Prefix List
Menu: Configuration > Policies > Custom Options > Topology > Add Topology > Custom Control (Route & TLOC) > Sequence Type > Route
Verifica PRIMA della abilitazione della policy:
Verifica dallo switch interno al Site10-Core (Site 10) prima della abilitazione della policy:
Verifica dallo switch interno al Site20-Core (Site 20) prima della abilitazione della policy:
Verifica dal Site10-vEdge1 (Site 10) e Site20-vEDge (Dite 20) DOPO abilitazione della policy:
TEST USE-CASE 2: ROUTE-LEAKING between VPN using CENTRALIZED POLICY
Lo scopo di questo use-case è quello di consentire una comunicazione tra VPN differenti (nel nostro caso la VPN 1 e la VPN 2)
- VPN 1 riguarda le prefix presenti in ciascuna VPN 1 presente in tutti i Branch Office
- VPN 2 riguarda la prefix 172.16.33.0/24 presente solo nel Site 30
Netconf Policy:
Al momento senza la policy abilitata abbiamo la condizione che le routes della VPN 2 non sono viste e quindi presenti nelle tabelle di routing omp per i vEdge e tabelle di routes per gli switch di Core dei siti 10, 20 e 40.
Con l’abilitazione della centralized policy (vedi true nella tabella)
Con l’abilitazione della centralized policy abbiamo questo risultato:
TEST USE-CASE 3: FW INSERTION Service Chaining using CENTRALIZED POLICY
Questo use-case è stato impostato come una sorta di PBR dove il traffico da una sorgente ad una destinazione deve passare attraverso il firewall del laboratorio
Questo use-case può essere testato, come prima, verificando il path (traceroute) che i client del site 10 e 20 percorrono prima dell’abilitazione della centralized policy eppoi con essa abilitata.
Netconf Policy:
Senza la policy applicata il percorso dal Site10_Client_MPLS (172.16.1.2) e diretto al Site20_Client_MPLS (172.16.2.2)
Con la policy applicata il percorso dal Site10_Client_MPLS (172.16.1.2) e diretto al Site20_Client_MPLS (172.16.2.2)
Con la policy applicata il percorso dal Site20_Client_MPLS (172.16.2.2) e diretto al Site10_Client_MPLS (172.16.1.2) > direzione opposta alla precedente
TEST USE-CASE 4: HUB & SPOKE using CENTRALIZED POLICY
Questo use-case è rivolto ad una architettura di tipo Hub&Spoke, sopratutto in reti di grandi dimensioni dove avere una topologia full-mesh 1:1 Overlay Tunnel tra tutte le sedi può essere particolarmente oneroso in termini di carico di lavoro e gestione del troubleshooting.
In questo caso avere una topologia dove i branch-office (Spoke) hanno sessioni solo verso la sede Hub (DataCenter vEDGE1 con indirizzo 10.150.1.141) potrebbe essere migliore e questo può essere applicato attraverso una centralized policy.
Netconf Policy:
La verifica viene eseguita attraverso il vEDGE2 (Site10_vEdge1) a livello di dataplane, dove SENZA la policy applicata abbiamo questo risultato:
La verifica viene eseguita attraverso il vEDGE2 (Site10_vEdge1) a livello di dataplane, dove CON la policy applicata abbiamo questo risultato: