Bilanciamento del carico BGP in entrata dallo stesso router ISP

Ho due router BGP per DIA con un problema con un provider in quanto i due collegamenti a questo provider arrivano sullo stesso router SP. I miei trasferimenti Ethernet tramite due collegamenti MetroE separati da un altro fornitore per conto del mio fornitore principale in quanto l'unico fornitore disponeva già di fibra ottica. Se qualcuno potesse anche chiarire la terminologia dell'ISP quando un fornitore trasporta servizi per un altro, lo apprezzerei. I due circuiti terminano L3 con lo stesso router SP, quindi i miei due router eseguono il peer con lo stesso router provider. Mi viene assegnato lo spazio PA da questo SP.

Non ho problemi con il bilanciamento del carico in uscita (o la condivisione del carico, come immagino sarebbe tecnicamente più accurato). In uscita, faccio ECLB al firewall che seleziona uno dei due router edge basato su un hash srcip / dstip .

Questo particolare corriere - dimentica il corriere che sta solo fornendo il trasporto - non sta bilanciando il carico in entrata del traffico dal loro unico router attraverso i due collegamenti ai miei due router, e questa è la direzione in cui potremmo usare il BW combinato 5x50Mb che abbiamo contratta. L'SP vede percorsi uguali per noi per la stessa rete pubblicizzata ed essenzialmente solo il primo percorso che imparano è quello che diventa il percorso migliore.

Ho elencato quello che sto prendendo in considerazione tra le mie opzioni di seguito per ottenere traffico su entrambi i circuiti e vorrei sapere cosa gli esperti qui ritengono sia il migliore, in particolare se hai familiarità con i tipici SP SOP . Dato che ho un contratto, modificare il contratto in questo momento non è un'opzione per farlo ricostruire in qualche altro modo.

Consentire maximum-paths 2nella rete SP risolve questo problema, ma questo vale per tutti i loro clienti BGP sullo stesso router che non credo consentiranno. Almeno un'opzione che funzionerà prevede percorsi statici, ma non è quello che preferirei.

Di seguito sono elencate le opzioni che ho considerato nel mio ordine di preferenza.

1. Consenti BGPmaximum-paths 2 sul router SP (influisce su tutti i clienti BGP ospitati lì), pertanto / 24 viene utilizzato quando pubblicizzato su entrambi i circuiti

2. Dividi il mio / 24 a metà e pubblicizza / 25 separati su ogni link insieme al / 24. L'SP ha recentemente affermato che una comunità non documentata potrebbe essere utilizzata per accettare prefissi> / 24. Ciò richiede la manipolazione del NAT sul mio firewall per utilizzare gli indirizzi globali in entrambi / 25 poiché la maggior parte del traffico è ora destinata a noi su pochi indirizzi in basso / 25.

3. SP route statiche a / 24 per forzare il bilanciamento del carico con / BGP / 24 (route mobile).

4. SP statico si dirige verso / 25s per forzare ECLB con prefisso BGP / 24 (in RIB, ma non utilizzato a meno di un errore di / 25s).

Penso che pubblicizzare gli / 25 in BGP sia l'opzione migliore che ho scoperto solo di recente è possibile con la comunità SP non documentata, ma ci sono altre opzioni che non ho preso in considerazione o preoccupazioni riguardo ai pacchetti fuori servizio con alcune di queste scelte ?

Questo è una sorta di problema di bilanciamento del carico inverso che la maggior parte delle persone chiede a BGP.

Chiederei "percorsi massimi" (di solito è chiamato ECMP in standard e documenti, non in ECLB). E se ECMP non è di avviamento, ricorrere al piano / 25.

Altri acronimi che non sono riuscito a capire immediatamente sono DIA (accesso a Internet dedicato?) E SOP (procedura operativa standard?). Non sono sicuro che si tratti di acronimi davvero così universali che dovrebbero essere usati in stackexchange senza almeno un hovertext per risolverli.

Parlando di terminologia hai già detto che il trasporto è quello a cui quel tipo di servizio viene comunemente chiamato. A volte la gente si riferirà anche ad esso come un "tether".

Hai un'altra opzione per spostare l'interfaccia dalla tua parte sullo stesso router e quindi impostare il multihop eBGP *** tra te e il tuo provider. Sì, perdi ridondanza dalla tua parte, ma dalla parte opposta andrà comunque allo stesso router, quindi è un po 'un punto controverso. Questo elimina anche la necessità per il provider di fare multipath eBGP, nel caso in cui non siano disposti a farlo con te (ma ho scoperto che in generale la maggior parte dei provider sta bene attivando questo, se non è già acceso) .

Se ciò non sembra plausibile, l'annuncio di due / 25 è probabilmente la tua scommessa migliore, a meno che ovviamente il tuo provider non sia disposto ad accendere maximum-paths(di nuovo, supponendo che non lo abbiano già fatto).

*** Eseguire il bilanciamento del carico con il multihop eBGP nel proprio scenario comporterà quanto segue:

1. Sposta la seconda connessione ISP su un router dalla tua parte.
2. Sia tu che il provider configurate update-source Loopback0su ciascuna delle vostre sessioni - non dovete usare Lo0 se non lo volete, purché concordiate su quale indirizzo instradare staticamente.
3. Configura route statiche 2x / 32 verso i loopback reciproci tramite le interfacce connesse (o gli IP dell'hop successivo): ecco come funziona il bilanciamento del carico, in quanto è semplicemente ECMP.
4. Configurare ebgp-multihop 2le sessioni degli altri (si desidera mantenere questo numero il più piccolo possibile per evitare il dirottamento della sessione TCP).

Voilà, bilanciamento del carico. Ciò si ridimensiona anche per interfaccia, poiché l'aggiunta di una nuova porta comporterà l'aggiunta di un'altra interfaccia e una route statica.

La soluzione ottimale qui è BGP ECMP tramite maximum-paths 2- tuttavia, dirò che "accettare percorsi> / 24" che richiedono un tag di comunità suona come una stupidità epica - supponendo che tu sia un loro cliente, dovrebbero accettare qualunque cosa tu dia loro numero massimo di prefissi e semplicemente filtrare in uscita in base agli accordi che hanno con gli altri peer. uno degli upstream che ho messo su una barca simile per quanto riguarda il fatto di non fare ECMP, mi aspetto sempre di poter annunciare qualsiasi dimensione di prefisso che desidero a un fornitore di transito e farglielo usare.

Quindi, dato che non sembrano terribilmente competenti, per bilanciare il traffico, non ritirare il prefisso / 24 - invece, lascialo essere e assicurati che i tuoi / 25 percorsi siano etichettati con NO_EXPORT in aggiunta a qualunque sia il presunto fornitore richiede che il / 25s non fuoriesca accidentalmente dal proprio AS (non che sia probabile che vada molto lontano se lo fa).

Un'ultima nota: assicurati che questa "comunità non documentata" non sia in realtà una comunità blackhole, perché sarebbe ... sai, male .