bgp project per definizione politiche di traffico inbound and outbound tra 2x data-center + 1x backbone- ospf-internal-backdoor

04.12 2019 | by massimiliano

---

Il presente documento mette in evidenza le scelte di progetto per la gestione di traffico inbound ed outbound via BGP […]

https://www.ingegnerianetworking.com/wp-content/uploads/2019/12/bgp-partner-ea9.png

Il presente documento mette in evidenza le scelte di progetto per la gestione di traffico inbound ed outbound via BGP tra due data center  geograficamente distanti collegati via backbone ospf ed un partner integrato attraverso un services provider.

Le scelte di progetto sono evidenziate attraverso i diagrammi di rete.

 

1) Il requisito principale della soluzione è quello di avere flussi di traffico bidirezionale simmetrico tra il partner ed i rispettivi data center:

 

 

 

 2) L’architettura da me disegnata per ciascun data center prevede la seguente soluzione:

 

• – un livello di egress tra il DC ed il services provider con n° 4 links logici EBGP su un’unica rete di transito /29;
• – un livello intermedio di sicurezza di rete attraverso un cluster ASA su cui viene stabilito un routing statico sia per l’outside che l’inside; il cluster firewall quindi ha delle static-route sia per la raggiungibilità delle prefix partner che quelle internal, più gli indirizzi di loopback su cui i router di egress stabiliscono le sessioni IBGP tra loro
• – un livello di ingress con una vrf di backend (i router fisici sono sempre gli stessi) e sessioni IBGP tra i router definiti di egress con una tabella di routing globale (grt) ed i router di backend con una tabella di routing in vrf;
•    

 

 

 

3) Per soddisfare il requisito principale di flussi di traffico bidirezionale simmetrico, la soluzione è stata quella di creare due distinti autonomous-system per data center e definire le politiche di traffico inbound con l’attributo as-path ed outbound con l’attributo local-preference (LP) attraverso un complessivo di n° 8 link EBGP (4 link per DCs):

 

 

 

 

 

Entrambi i data center annunciano sia le prefix di RM che di MI per alta affidabilità in caso di fault e/o disaster-recovery; il backbone OSPF internal tra i due data center svolge un ruolo di backdoor link permettendo la raggiungibilità delle prefix tra i due poli.

 

 

4) esempi di configurazione per gli attributi BGP indicati nel diagramma sopra:

 

 

Gestione traffico inbound via as-path prepend:

 

configurate sia nel DC-MI che nel DC-RM:

 

ip prefix-list MILANO seq 10 permit < prefix_s >    

ip prefix-list ROMA seq 10 permit < prefix_w >     

!

DC-RM:

route-map prefix-dc-link_1-prepend permit 10

match ip address ROMA

!

route-map prefix-dc-link_1-prepend permit 20

match ip address MILANO 

set as-path prepend X X X X 

!

route-map prefix-dc-link_2-prepend permit 10

match ip address ROMA

set as-path prepend X

!

route-map prefix-dc-link_2-prepend permit 20

match ip address MILANO 

set as-path prepend X X X X X

!

route-map prefix-dc-link_3-prepend permit 10

match ip address ROMA

set as-path prepend X X

!

route-map prefix-dc-link_3-prepend permit 20

match ip address MILANO 

set as-path prepend X X X X X X

!

route-map prefix-dc-link_4-prepend permit 10

match ip address ROMA

set as-path prepend X X X

!

route-map prefix-dc-link_4-prepend permit 20

match ip address MILANO 

set as-path prepend X X X X X X X

!

 

DC-MI:

route-map prefix-dc-link_1-prepend permit 10

match ip address MILANO

!

route-map prefix-dc-link_1-prepend permit 20

match ip address ROMA 

set as-path prepend Y Y Y Y  

!

route-map prefix-dc-link_2-prepend permit 10

match ip address MILANO

set as-path prepend Y

!

route-map prefix-dc-link_2-prepend permit 20

match ip address ROMA 

set as-path prepend Y Y Y Y Y 

!

route-map prefix-dc-link_3-prepend permit 10

match ip address MILANO

set as-path prepend Y Y 

!

route-map prefix-dc-link_3-prepend permit 20

match ip address ROMA 

set as-path prepend Y Y Y Y Y Y

!

route-map prefix-dc-link_4-prepend permit 10

match ip address MILANO

set as-path prepend Y Y Y 

!

route-map prefix-dc-link_4-prepend permit 20

match ip address ROMA 

set as-path prepend Y Y Y Y Y Y Y 

!

 

Gestione traffico outbound via local-preference:

 

# DC-RM – DC-MI:

 

ip prefix-list partner seq 10 permit < prefix-partner-a >

ip prefix-list partner seq 20 permit < prefix-partner-b >

!

route-map partner-link_1-LP permit 10

match ip address prefix-list partner

set local-preference 150

!

route-map partner-link_2-LP permit 10

match ip address prefix-list partner

set local-preference 130

!

route-map partner-link_3-LP permit 10

match ip address prefix-list partner

set local-preference 110

!

route-map partner-link_4-LP permit 10

match ip address prefix-list partner

set local-preference 90

!

 

Applicazione delle route-map sui peering ebgp:

 

# DC-RM – DC-MI ( per MI il comando è router bgp y )

 

router bgp x

router-id < router-id >

neighbor < peer-SP-link1 > remote-as < as-sp >

neighbor < peer-SP-link1 > route-map prefix-dc-link_1-prepend out      # from EGR-1: traffico inbound

neighbor < peer-SP-link2 > route-map prefix-dc-link_2 prepend out      # from EGR-1: traffico inbound

neighbor < peer-SP-link1 > route-map partner-link_1-LP in                   # from EGR-1: traffico outbound

neighbor < peer-SP-link2 > route-map partner-link_2-LP in                   # from EGR-1: traffico outbound

!

neighbor < peer-SP-link3 > route-map prefix-dc-link_3-prepend out      # from EGR-2: traffico inbound

neighbor < peer-SP-link4 > route-map prefix-dc-link_4-prepend out      # from EGR-2: traffico inbound

neighbor < peer-SP-link3 > route-map partner-link_3-LP out                 # from EGR-2: traffico outbound

neighbor < peer-SP-link4 > route-map partner-link_4-LP out                 # from EGR-2: traffico outbound

 

 

 

4) logiche di redistribuzione BGP con OSPF config example:

 

 

 

router ospf 100 vrf backend

router-id < loopback 11 >

capability vrf-lite

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

distance 210

 

NOTA: la distanza amministrativa configurata sotto il processo OSPF è settata a 210 affinche siano sempre preferiti gli annunci appresi via IBGP (DA = 200) rispetto alle stesse prefix redistribuite via OSPF (DA = 110) dal data center remoto 

 

router bgp x

address-family ipv4 vrf backend

router-id < loopback 11 >

redistribuite ospf 100 route-map OSPF-TO-BGP

 

 

Definizione prefix-list e route-map:

 

ip prefix-list BGP-TO-OSPF permit 10 permit < prefix-partner-a >

ip prefix-list BGP-TO-OSPF permit 20 permit < prefix-partner-b >

!

ip prefix-list OSPF-TO-BGP permit 10 permit < prefix-internal-s >

ip prefix-list OSPF-TO-BGP permit 10 permit < prefix-internal-w >

 

route-map BGP-TO-OSPF permit 10

match ip address BGP-TO-OSPF

set metric 10

set metric-type type-1

!

route-map BGP-TO-OSPF deny 10000

!

!

route-map OSPF-TO-BGP permit 10

match ip address OSPF-TO-BGP 

!

route-map OSPF-TO-BGP deny 1000

 

 

 

 5) lato service provider si rende necessario applicare un SOO (Site of Origine) allineato su entrambi i POP di peering EBGP di RM e MI secondo lo schema seguente: