SDWAN: provisioning Centralized Policy configuration vMANAGE controller: loopback filtering – vpn1/vpn2 leaking – service chaining (fw insert.) – Hub & Spoke

Home » Blog » SDN » SDWAN » SDWAN: provisioning Centralized Policy configuration vMANAGE controller: loopback filtering – vpn1/vpn2 leaking – service chaining (fw insert.) – Hub & Spoke

SDWAN: provisioning Centralized Policy configuration vMANAGE controller: loopback filtering – vpn1/vpn2 leaking – service chaining (fw insert.) – Hub & Spoke

23.02 2024 | by massimiliano

Architettura di riferimento logica Architettura di riferimento fisica Centralized Policy: Site40_Loopback0_deny-BRANCH STEP-1 Menu: Configuration > Policies > Custom Options > […]



    Architettura di riferimento logica

    Architettura di riferimento fisica

    Centralized Policy: Site40_Loopback0_deny-BRANCH

    STEP-1

    Menu: Configuration > Policies > Custom Options > Lists

    A sinistra scegliere Prefix e configurare le Prefix Subnet di interesse (in questo caso: vEdge41_Loopback0)

    STEP-2

    Menu: Configuration > Policies > Custom Options > Lists

    A sinistra scegliere Site e configurare le Site di interesse (in questo caso la lista è il Branch)

    STEP-3

    Menu: Configuration > Policies > Custom Options > Topology > Add Topology > Custom Control (Route & TLOC)

    Creare la Topology in Custom Control (Route & TLOC)

    STEP-4

    Menu: Configuration > Policies > Custom Options > Topology > Add Topology > Custom Control (Route & TLOC) > Sequence Type > Route > Sequence Rule >

    • Name: Site40_Loopback0_deny-BRANCH
    • Description: Deny Site40 vEDge Loopback0 to all the branch

    • Match Condition –> Prefix List: vEdge41_Loopback0
    • Actions: Reject

    Sequence Type > Add Control Policy > Route  per accettare tutto il resto tranne la loopback del Site40 selezionata dobbiamo cambiare l’azione di default da reject ad accept

    • Default Action: Accept

    STEP-5

    Menu: Configuration > Policies > Add Policy > Next (in blue) > Create Groups of Interest > Add Topology > Import Existing Topology

    Select a Policy

    Successivamente click Next (in blue), skip, skip, ed arrivi alla sezione Apply Policies to Sites and VPNs

    Save Policy

    STEP-6

    Menu: Configuration > Policies > Custom Options > Topology > Add Topology > + New Site List > Sequence Type > Route > Sequence Rule

    • Inbound Site List
    • Outbound Site List  # nel nostro caso sono tutti i branch site (site 10, 20, 30)
    • Direction: out  
    • Site List: Branch # (vedi nella sezione Lists > Site delle Custom Option precedentemente configurato)

    Nota:

    la direzione di inbound ed outboud deve essere considerata dal punto di vista del vSMART (del Control Plane) e pertanto poiché tutti i nodi parlano con il vSMART in modo centralizzato, la negazione (oppure il filtering) della loopback del Site 40 segue il percorso di inbound verso il vSMART e di outbound verso gli altri Site del dominio SDWAN.

    L’ultimo passaggio è quello di Save Policy e di attivare la policy attraverso l’Activate (flag = true)

    STEP-7

    A questo punto vMANAGE eseguirà il push verso il vSMART utilizzando il protocollo NETCONF

    Verifica use-case 1: Loopback Filtering

    Verifica dal Site10-vEdge1 (Site 10) prima della abilitazione della policy:

    Verifica dal Site10-vEdge1 (Site 10) dopo  abilitazione della policy:

    Centralized Policy: VPN1_VPN2_Leaking

    STEP-1

    Menu: Configuration > Policies > Custom Options > Lists

    In questo use-case dobbiamo creare due oggetti Lists definiti in VPN:

    • Name: VPN1

    Entries: 1

    • Name: VPN2

    Entries: 2

    Una Prefix definita come ALL_PREFIX: 0.0.0.0/32 le

    STEP-2

    Menu: Configuration > Policies > Custom Options > Topology > Add Topology > Custom Control (Route & TLOC)

    Name: VPN1_VPN2_Leaking

    Description: Leaking between VPN1 and VPN2 VPNs

    • Match Condition 1 –> VPN1
    • Actions: Accept
    • Export to: VPN2
    • Match Condition 2 –> VPN 2
    • Action: Accept
    • Export to: VPN1

    Menu: Configuration > Policies > Custom Options > Topology  > Add Topology  > Sequence Type > Route > Sequence Rule

    Ora è possibile selezionare il + Sequence Type > + Sequence Rule per applicare la Policy Application

    Outbound Site List  à nel nostro caso sono tutti i branch site (site 10, 20, 30)

    Direction: in

    • Site List –> Site_ALL

    STEP-3

    Ora è possibile tornare al MENU: Configuration > Policies > Add Policy

    • Creare il Groups of Interests (ma non abbiamo nulla in questione) e pertanto possiamo click su Next (in blue)
    • Add Topology  > Import Existing Topology
    • Import

    STEP-4

    Ora possiamo salvare la policy «Save Policy» e l’ultimo passaggio è quello di attivare la policy con l’Activate

    vMANAGE eseguirà il push verso il vSMART utilizzando il protocollo NETCONF

    Verifica use-case 2: route leaking between VPN

    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

    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 (flag = true)

    Centralized Policy: Service Chaining: FW_Insertion

    STEP-1

    Configurazione Service Chaining

    vMANAGE Menu: Configuration > Templates > Feature Template > VPN > FT_VPN-1_hub_standard

    • Service: FW
    • IP address: 8.8.8.8

    STEP-2

    vMANAGE Menu: Configuration > Policies > Custom Options > Lists > VPN

    Andiamo a definire la VPN che utilizza la Service:

    • VPN: VPN 1

    vMANAGE Menu: Configuration > Policies > Custom Options > Lists > Site

    e successivamente la lista dei Site che andranno ad utilizzare la Service

    • Branch: Site 10, 20, 30

    STEP-3

    vMANAGE Menu: Configuration > Policies > Custom Options > Topology > Add Topology > Add Topology > Custom Control (Route & TLOC)

    Impostiamo i seguenti parametri:

    Name: FW_Insertion

    Description: From Site40 (HQ) insert FW

    From + Sequence Type > + Sequence Rule > Route

    Match Condition:

    • VPN List: VPN1
    • Site List: Branch

    Action: Accept

    Service:

    • Type: Firewall
    • VPN: 1

    STEP-4

    From + Sequence Type > + Sequence Rule > Route

    Cambiare l’azione di default da reject ad Accept:

    STEP-5

    Ora possiamo andare a salvare la policy «Save Control Policy»

    Successivamente andiamo sul Menu: Configuration > Policies > Add Policy > Next > Add Topology > Import Existing Topology

    E nel Policy Type «Custom Control (Route & TLOC) selezionare la policy interessata: FW_Insertion

    STEP-6

    Torniamo al Menu: Configuration > Policies > Edit Policy > Policy Application

    e con il + New Site List andiamo ad impostare:

    • Direction: out
    • Site List: Branch

    STEP-7

    Infine possiamo salvare con il «Save Policy» e Attivare la policy con Activate

    Verifica use-case 3: service chaining (FW insertion)

    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.

    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

    Centralized Policy: HUB & SPOKE

    STEP-1

    vMANAGE Menu: Configuration > Policies > Custom Options > Lists > VPN

    Andiamo a definire la VPN interessate all’impiego della policy:

    • VPN: VPN_ALL

    Entries: 1, 2

    vMANAGE Menu: Configuration > Policies > Custom Options > Lists > Site

    successivamente la lista dei Site che utilizza la policy con ruolo di Hub

    • HQ: Site 40

    vMANAGE Menu: Configuration > Policies > Custom Options > Lists > Prefix

    Le prefix interessate all’impiego di questa policy (praticamente tutte le subnets)

    • RFC-1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/26

    STEP-2

    vMANAGE Menu: Configuration > Policies > Custom Options > Topology > Hub-and-Spoke

    Name: Hub-andSpoke

    Description: Hub-and-Spoke

    • VPN List: VPN1
    • Add Hub Site: HQ
    • Add Spoke Sites: Branch

    STEP-3

    vMANAGE Menu: Configuration > Policies > Edit Policy > Add Topology > Import Existing Topology > Hub and Spoke

    • Policy: Hub-and Spoke

    La policy è stata creata e per concludere basta andare ad attivarla con Activate

    Verifica use-case 4: Hub & Spoke

    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.

    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:

    Torna in alto