Siamo un fornitore di servizi gestiti che gestisce una rete di piccole dimensioni in un unico datacenter a Sydney. Di recente abbiamo implementato un nuovo stato interstatale POP a Melbourne (entrambi si trovano sulla costa orientale dell'Australia) e per la prima volta devo affrontare le sfide del mondo reale in termini di ingegneria del traffico. La mia speranza è che qui possa ottenere qualche consiglio su come ottenere un certo livello di controllo sui miei percorsi iBGP.
Probabilmente pubblicherò alcune domande correlate, ma in questo caso sono particolarmente preoccupato per l'ingegneria del traffico interno. Sto trovando sorprendentemente difficile capire come ottenere iBGP per prendere decisioni di routing ottimali.
L'obiettivo principale per me è che è necessario trovare un modo per dare ad iBGP un concetto di confine e distanza per POP. Quindi posso distinguere tra un POP che si trova nella stessa città, vs uno che è interstatale, rispetto a uno che è la costa est contro ovest. Quindi ottimizzare il routing inbound / outbound in base a questo.
So che ci saranno molti scenari caso per caso, ma spero di poter sviluppare una strategia di routing iBGP che funzioni forse l'80% delle volte e il resto dovrei occuparmi di casi limite speciali nel config.
Contesto
- Abbiamo appena acquistato 4x ASR 1001-X per fungere da dispositivi periferici in ciascun POP (2x per POP ma a causa delle limitazioni dell'hardware di commutazione, per ora mi sto solo concentrando sulla distribuzione di 1 dispositivo edge a Melbourne)
- Utilizziamo anche Juniper per cambiare hardware. EX4500 come i nostri "core switch" ed EX4200s al livello di accesso.
- Ora abbiamo 2 provider di transito. Ci colleghiamo solo a ciascun provider in uno stato ciascuno.
- AS 1000 è un aggregatore e utilizza AS 4000 come uno dei suoi flussi principali a Sydney.
- Questo rappresenta un po 'una sfida poiché tutti i percorsi ricevuti da AS 1000 sono generalmente più lunghi di 1 di quelli che otteniamo da AS 4000.
- Sto usando Ansible per generare configurazioni IOS usando i modelli Jinja2. Quindi non è un problema generare molta logica per route map peer iBGP per fare le cose.
I miei obiettivi
In sostanza, voglio essere in grado di ottenere un routing ottimale tra i POP mentre li distribuiamo. Ma in questo momento non sono in grado di raggiungere alcun livello di controllo su come iBGP sta scegliendo i suoi percorsi.
Il mio disegno attuale
- Al momento ho 2 ASR1K che fungono da router perimetrali con tavoli completi a Sydney e uno a Melbourne.
- Entrambi i POP utilizzano provider di transito diversi.
- Abbiamo un circuito punto a punto tra i due POP che è terminato su entrambi i lati dai dispositivi periferici sulle interfacce secondarie dot1q.
- Eseguiamo OSPF su questo collegamento tra tutti i dispositivi periferici e il costo del collegamento viene aumentato, quindi questo è il percorso OSPF con la preferenza più bassa.
- Abbiamo una singola area OSPF 0 su entrambi i POP.
- I dispositivi edge sono più un core / edge convergenti: i nostri switch core non fanno molto L3 in quanto non possono gestire un tavolo completo.
- In ciascun POP gli ASR1K fungono da riflettori del percorso per gli altri dispositivi BGP in quel POP: firewall, switch core, LNS e così via.
- Ognuno ha il proprio ID cluster - non per POP. Sto cercando di cambiarlo in per-POP.
- Ogni ASR1K genera una route predefinita per i client route-reflector su BGP.
- Tutti gli ASR1K sono in una rete iBGP.
- Tutti i transiti hanno lo stesso pref locale in tutti i siti.
Esempio di routing subottimale
- Se ho i miei transiti Melbourne e Sydney online, il routing in uscita funziona bene. Il traffico di Sydney esce da Sydney e Melbourne esce da Melbourne.
- Il problema è che semplicemente disabilitando l'amministratore del mio transito principale di Sydney, il mio transito di Melbourne è ora automaticamente preferito. Invece del mio passaggio secondario a Sydney tramite il router BDR02 a Sydney.
- Quindi finisco spesso con uno scenario in cui il traffico rimbalzerà su Melbourne per il nostro backhaul, usciremo a Melbourne e poi torneremo a Sydney. Il percorso che stava subendo <1ms ora è di circa 30 ms.
A peggiorare le cose, in questo particolare scenario non riesco a capire perché Melbourne sia preferita.
- Il peso è identico
- Il pref locale è identico
- AS Path ha la stessa lunghezza
- Nessuno dei due percorsi è auto originato.
- Entrambi hanno IGP come origine.
- Entrambi hanno una metrica (MED?) Pari a 0.
- Entrambi sono percorsi iBGP dal punto di vista di questo router.
- Metrica IGP Avrei pensato che fosse correlato al costo del collegamento OSPF poiché stiamo usando OSPF come nostro IGP.
- Ho confermato che la larghezza di banda di riferimento 100G è impostata su tutti i dispositivi OSPF.
EDIT: 30/01: Penso di sbagliarmi su come viene calcolato il costo IGP e forse sono attualmente gli stessi? Tutte le mie rotte OSPF sono di tipo E2. Se i costi IGP sono gli stessi, allora suppongo abbia senso la migliore selezione del percorso sulla base di RID, che in questo caso il RID del MDR BDR sarebbe inferiore a SYD.
Ho impostato il costo del collegamento OSPF tra Sydney su 15.000 molto più alto del valore predefinito. Ho calcolato che funzioni in modo affidabile con la nostra larghezza di banda di riferimento di 100 Gbps.
In termini di costi del collegamento OSPF: si tratta delle preferenze OSPF di ciascun hop successivo delle rotte BGP:
bdr-01-syd#sh ip route x.x.201.73 (AS 4000 next hop)
Routing entry for x.x.201.72/30
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 15000
Last update from x.x.13.51 on Port-channel1.1125, 14:57:17 ago
Routing Descriptor Blocks:
* x.x.13.51, from x.x.13.66, 14:57:17 ago, via Port-channel1.1125
Route metric is 20, traffic share count is 1
bdr-01-syd#
bdr-01-syd#sh ip route x.x.31.5 (AS 1000 next hop)
Routing entry for x.x.31.4/30
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 5
Last update from x.x.216.67 on Port-channel1.36, 1d00h ago
Routing Descriptor Blocks:
* x.x.216.67, from x.x.216.163, 1d12h ago, via Port-channel1.36
Route metric is 20, traffic share count is 1
bdr-01-syd#
x.x.201.73 is the next hop to 139.130.4.4 via the Melbourne path.
x.x.13.51 is the other end of the inter-state Point to Point. x.x.13.66 is BDR-01-MEL.
x.x.31.5 is the next hop to 139.130.4.4 via the Secondary Sydney transit in the same POP as the primary transit - via BDR-02-SYD.
x.x.216.67 is the local OSPF VLAN for the Sydney POP that both BDR01 and BDR02 are in.
x.x.216.163 is the BDR-02-SYD router.
In termini di queste scelte OSPF, vedo che viene raccolta la "metrica diretta" OSPF più corta. Avrei pensato che BGP avrebbe dovuto scegliere il percorso di Sydney basandosi su questo.
Da questa traccia puoi vedere che saliamo immediatamente a Melbourne via Backhaul perché il primo hop è 13ms: (139.130.4.4 è trasmesso e ha percorsi in entrambi gli stati).
bdr-01-syd#traceroute 139.130.4.4
Type escape sequence to abort.
Tracing the route to 139.130.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 x.x.13.51 13 msec 13 msec 13 msec
2 x.x.201.73 14 msec 14 msec 14 msec
3 x.x.196.54 [AS 4000] [MPLS: Label 25049 Exp 0] 14 msec 14 msec 14 msec
4 x.x.196.51 [AS 4000] 14 msec 14 msec 14 msec
5 139.130.110.29 [AS 1221] 14 msec 15 msec 14 msec
6 203.50.11.113 [AS 1221] 16 msec 14 msec 16 msec
7 139.130.4.4 [AS 1221] 13 msec 14 msec 14 msec
bdr-01-syd#
bdr-01-syd#sh ip route 139.130.4.4
Routing entry for 139.130.0.0/16
Known via "bgp 5000", distance 200, metric 0
Tag 4000, type internal
Last update from x.x.201.73 06:06:14 ago
Routing Descriptor Blocks:
* x.x.201.73, from x.x.13.66, 06:06:14 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 4000
MPLS label: none
bdr-01-syd#
bdr-01-syd#sh ip bgp regexp ^1000 1221$
BGP table version is 11307146, local router ID is x.x.216.161
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
...
* i 139.130.0.0 x.x.31.5 0 100 0 1000 1221 i
...
Versus the path via AS 4000:
bdr-01-syd#sh ip bgp regexp ^4000 1221$
*>i 138.130.0.0 x.x.201.73 0 100 0 4000 1221 i
bdr-01-syd#
In questa uscita sia il transito secondario di Sydney è un percorso valido, sia il transito di Melbourne. Melbourne è stata scelta come la migliore.
bdr-01-syd#sh ip bgp 139.130.4.4
BGP routing table entry for 139.130.0.0/16, version 10794227
Paths: (2 available, best #2, table default)
Advertised to update-groups:
66
Refresh Epoch 1
1000 1221, (received & used)
x.x.31.5 (metric 20) from x.x.216.163 (x.x.216.163)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 1000:65110 5000:1000 5000:1001 5000:1002
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
4000 1221, (received & used)
x.x.201.73 (metric 20) from x.x.13.66 (x.x.13.66)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 4000:5307 4000:6100 4000:53073 5000:1000 5000:1030 5000:1031
rx pathid: 0, tx pathid: 0x0
bdr-01-syd#
Quello che ho provato
Ho provato ad aggiungere un costo di collegamento OSPF di 15.000 che ho calcolato come una cifra sicura sulla base della mia larghezza di banda di riferimento di 100 Gbps, essendo sempre il costo OSPF meno preferito. Pensavo che questo sarebbe considerato un "costo IGP", eppure BGP preferisce ancora il percorso di Melbourne per qualche motivo.
Dopo che questo non sembrava avere alcun impatto, il mio piano principale era quello di utilizzare AS PATH prepagando su iBGP. Il piano era che avrei avuto gruppi di pari per POP. E nel mio modello desidero designare quanti anteprime fare, in base alla distanza dei due POP. Pensavo che questo sarebbe stato un tipo di obiettivo abbastanza comune.
Per esempio:
- 0 antepone se intra-POP
- 1 anteporre se POP nello stato
- 2 antepone se POP interstatale
- 3 antepone se costa est-ovest POP
Ho pensato che avrebbe funzionato abbastanza perfettamente, sarebbe stata una soluzione piuttosto elegante ed è esattamente il tipo di soluzione che spero di ottenere. Ho scritto i config in un paio d'ore e distribuito. Ma mi sono grattato la testa fino a quando mi sono reso conto che iBGP non supporta il prepending del percorso AS.
- https://routerjockey.com/2011/02/28/bgp-essentials-the-art-of-path-manipulation/
- https://lists.gt.net/nsp/juniper/3870
- http://blog.ipspace.net/2008/02/bgp-essentials-as-path-prepending.html
Anche se riuscissi a farlo funzionare, sembra che non sarebbe mai una soluzione supportata.
Quello che sto considerando
- L'ultimo link @ ipspace.net menziona che potresti usare pref pref locale in quanto persiste all'interno di un AS. Ma ho già mappato una politica di pref locale per preferire le rotte dei clienti a valle, IXes, il solito ... Sembra che usare localpref per questo non si mescolerebbe bene. E Ivan non lo suggerisce!
- Ho preso in considerazione l'utilizzo delle Confederazioni BGP, ma questo sembra un sacco di lavoro extra per la nostra piccola rete. E ho anche letto che non aggiunge comunque i salti di percorso AS tra AS confederati. Quindi probabilmente finirei nello stesso posto.
- Vorrei prendere in considerazione l'utilizzo di MPLS (penso MPLS TE?) Ma sono molto ecologico quando si tratta di MPLS e ho già molte sfide da affrontare. Quindi vorrei evitare la complessità aggiunta, a meno che non sia una buona soluzione al mio problema.
Aggiungerò ulteriori dettagli domani. Per ora, ecco un diagramma che illustra la nostra configurazione attuale.
