High-Availability between two different datacenter with EBGP-IBGP-OSPF design

21.02 2024 | by massimiliano

Architettura High-Availability EBGP-IBGP-OSPF Tre livelli: E’ requisito avere flussi di traffico bidirezionale in modo simmetrico tale che IP-sorgente/IP-destinazione transitano per […]

Architettura High-Availability EBGP-IBGP-OSPF

Tre livelli:

Egress Layer si occupa di stabilire sessioni External-BGP con il Services Provider; questo stesso livello permette la redistribuzione delle prefix IP ricevute via EBGP in global-routing table

Al fine di garantire una redistribuzione delle prefix ricevute da ISP e quelle annunciate dal datacenter viene stabilito un full-mesh peering I-BGP tra i suddetti router di egress in GRT ed in vrf di BackEnd (DCRZ e DCBO) mediante indirizzi di loopback; ogni nodo I-BGP prevede la funzionalità di NHS (Next-Hop Self) permettendo di presentare se stesso come next-hop per la prefix annunciata senza il bisogno di dover annunciare l’external next-hop EBGP che di default viene trasmesso.

Security Access Layer prevede una coppia di (FirePower-Cisco con modulo ASA in modalità active-standby; essendo un next-hop L3 routed stabilisce un routing statico di reachability attraverso le due interfacce outside (verso ISP) ed inside (verso datacenter) e definisce policies di security al fine di permettere i corretti flussi di traffico

Ingress Layer si occupa del collegamento lato interno Backbone datacenter; i router di egress in vrf di backEnd sono immersi nel backbone OSPF rispettivamente in area 8 per RZ ed area 16 per BO; le coppie di ABR permettono la redistribuzione delle routes tra datacenter mediante il protocollo OSPF con routes intra-area (stesso datacenter) ed inter-area (inter datacenters)
Una mutua redistribuzione è creata tra i due protocollo BGP ed OSPF

E’ requisito avere flussi di traffico bidirezionale in modo simmetrico tale che IP-sorgente/IP-destinazione transitano per le rispettive catene di accesso colocate negli Internet-Data-Center (IDC) di RZ e BO.

Il traffico outbound (traffico uscente dall’AS datacenter) è gestito attraverso Local-Preference.

Il traffico inbound (traffico entrante in AS datacenter) è gestito via AS-Path-Prepend.

In questo posto si indica in modo parametrico gli annunci che, dal punto di vista datacenters, vengono ricevuti ed annunciati attraverso la sua architettura di rete

Con A, B, sono definite IP Prefix ricevute da ISP

Con W, Z, S, T, sono definite IP Prefix annunciate dai datacenters

Le Prefix interne marcate come W e Z sono appartenenti all’area OSPF di RZ e pertanto soggette a flussi di traffico transitanti per la catena di integrazione con ISP di RZ;

Le Prefix interne marcate come S e T sono invece appartenenti all’area OSPF di BO e pertanto soggette a flussi di traffico transitante per la catena di integrazione con ISP di BO

Tutte le suddette Prefix interne sono annunciate da ciascun router di egress datacenter ai rispettivi PE del Services Provider per essere poi conosciute da ISP; tali Prefix sono soggette a politiche di traffico inbound.

Le Prefix esterne marcate come A, B, sono appartenenti ad ISP e sono ricevute via External-BGP dalle due coppie di routers PE che il Services Provider metterà a disposizione in ridondanza verso i router di egress datacenter, i quali attraverso il settaggio di Local Preference avranno per ciascuna catena di RZ e BO il punto di uscita dall’AS dei datacenter

Il requisito di simmetria di traffico bidirezionale IP-sorgente/IP-destinazione transitante per i rispettivi IDC di Rozzano e Bologna, compreso una totale affidabilità di fault-tolerance e Business Continuity è gestito attraverso la definizione di AS-private uno per ciascuna zona di competenza ed una connettività di tipo full-mesh E-BGP di tipo point-to-point tra i PE del Services Provider ed i router di egress datacenter

La logica di gestione del traffico inbound è gestita via as-path prepend assegnando in modo opportuno alle IP Prefix di RZ e BO valori per i quali il Services Provider possa scegliere correttamente come far entrare il traffico relativamente alla zona di competenza su un totale di n° 8 links.

Le prefix W, Z aventi come next-hop IGP la catena di RZ avranno un valore di as-path migliore rispetto a quello configurato attraverso la catena di Bologna e questo obbliga i PE del service provider a preferire per il traffico di ritorno verso i datacenter i seguenti path sulla logica indicata in figura sopra.

IDC-RZ

PE1 to R1 con as-path prepend di default (AS-64512)
PE2 to R1 con as-path prepend: 1x AS-64512
PE1 to R2 con as-path prepend: 2x AS-64512
PE2 to R2 con as-path prepend: 3x AS-64512

IDC-BO

PE3 to R3-Egress con as-path prepend: 4x AS-64513
PE4 to R3-Egress con as-path prepend: 5x AS-64513
PE3 to R4-Egress con as-path prepend: 6x AS-64513
PE4 to R4-Egress con as-path prepend: 7x AS-64513

Le prefix S e T aventi come next-hop IGP la catena di BO avranno un valore di as-path migliore rispetto a quello configurato attraverso la catena di RZ e questo obbliga i PE del Service Provider a preferire per il traffico di ritorno verso i datacenter i seguenti path sulla logica indicata in figura sopra:

IDC-BO

PE3 to R3 con as-path prepend di default (AS-64513)
PE4 to R3 con as-path prepend: 1x AS-64513
PE3 to R4 con as-path prepend: 2x AS-64513
PE4 to R4 con as-path prepend: 3x AS-64513

IDC-RZ

PE1 to R1 con as-path prepend: 4x AS-64512
PE2 to R1 con as-path prepend: 5x AS-64512
PE1 to R2 con as-path prepend: 6x AS-64512
PE2 to R2 con as-path prepend: 7x AS-64512

L’utilizzo dell’attributo Local-Preference per la gestione del traffico outbound stabilisce una preferenza secondo questa logica (per le prefix A,B):

FROM IDC-RZ

1° link EBGP: R1 to PE1 con LP = 200
2° link EBGP: R1 to PE2 con LP = 180
3° link EBGP: R2 to PE1 con LP = 160
4° link EBGP R2: to PE2 con LP = 140

FROM IDC-BO

1° link EBGP: R3 to PE3 con LP = 200
2° link EBGP: R3 to PE4 con LP = 180
3° link EBGP: R3 to PE3 con LP = 160
4° link EBGP: R4 to PE4 con LP = 140

NOTA per la parte di set distance 210 per le aree ospf datacenter:

Come sopra illustrato i routers di egress stabiliscono sessioni IBGP tra la global-routing-table (address-family ipv4) attraverso la quale gestisce le Prefix ISP e la tabella di routing in VRF di backEnd datacenter, dove gestisce le Prefix interne (address-family ipv4 vrf) mantenendo conformi le rispettive RIB.

Pertanto via router bgp le prefix ISP ricevute dalle sessioni external-bgp vengono automaticamente propagate via internal-bgp e redistribuite sotto OSPF process 1 in vrf di backend (DCRZ e DCBO)

router ospf 1 vrf < vrf_name >

router-id < Lo11 >

redistribute bgp < as > subnets route-map BGP-TO-OSPF

distance ospf intra-area 210 inter-area 210 external 210

menzione viene fatta per la distanza amministrativa sotto il processo ospf settata a 210, affinchè siano preferite sempre le networks apprese via I-BGP con DA = 200 (le routes from ISP) rispetto alle stesse routes ISP annunciate via OSPF dal sito datacenters opposto con una DA = 210.

Sotto router bgp address-family vpnv4 è necessario propagare le routes OSPF datacenter verso i router di egress in global-routing table:

router bgp < as >

router-id < Lo10 >

address-family ipv4 vrf < vrf_name >

bgp router-id < Lo11 >

redistribute ospf 1 route-map OSPF-TO-BGP

route-map BGP-TO-OSPF permit 10

match ip address prefix-list BGP-TO-OSPF

set metric-type type-1

route-map BGP-TO-OSPF deny 10000

E’ necessario redistribuire le prefix BGP in OSPF con metrica external-1 (anziché come external-2 quale di default sono annunciate) per mantenere le stesse condizioni di metrica/costo OSPF impostato all’interno del backbone datacenter, che preferisce come path IGP il datacenter opposto

Inoltre l’annuncio delle prefix ISP all’interno del backbone datacenter è redistribuito con una diversa metrica tra il DC di Rozzano che per politiche di routing interno è sempre preferito al DC di Bologna, il quale redistribuisce le stesse prefix ISP con metrica superiore

Esempio:

route-map BGP-TO-OSPF permit 10

match ip address prefix-list BGP-TO-OSPF

set metric 20 (from Egress di BO)

set metric 10 (from Egress di RZ)