sdwan cisco vipitela ambiente di laboratorio, config e test use-case: filtering network – route leaking – FW insertion – Hub&Spoke

12.07 2023 | by massimiliano

---

sdwan 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: