È possibile influenzare in remoto BGP localpref?

17

Un collega sta tentando di implementare il multihoming Internet attivo / passivo. Il progetto prevede l'invio di comunità (elencate di seguito) al provider passivo per ridurre la preferenza locale negli AS remoti per le rotte pubblicizzate. La documentazione afferma ripetutamente che le comunità sono destinate all'uso da parte dei clienti e che non siamo clienti di questi fornitori. Penso che dare a Internet in generale la possibilità di modificare le preferenze locali sia un enorme rischio per la sicurezza. Ciò avrebbe una probabilità di una palla di neve all'inferno di funzionare davvero?

1273:70     cable and wireless plc local pref 70
2828:1507   xo local pref 70
3356:70     level3 local pref 70
3549:100    global crossing local pref 100
4323:80     twtelecom local pref 80
1299:50     teliasonera local pref 50

bgp

— Dennis Olvany
fonte

1

'Onestep' è il provider di backup stesso? Se è così, allora sicuramente quelli dovrebbero funzionare bene quando pubblicizzati su "onestep" e secondo me è preferibile progettare piuttosto che anteporre. Altrimenti sono inutili, anche se i tuoi percorsi li superavano, è improbabile che funzionino dai loro pari. Il tuo vicino diretto non fornisce un elenco comparabile?

— ytti,

One Step non è il nostro fornitore. Da quello che raccolgo, One Step non è affatto un fornitore. Il vicino diretto può avere un tale elenco. Dovrò fare qualche ricerca.

— Dennis Olvany,

2

OneStep è una società di consulenza che raggruppa le guide della comunità di tutti gli NSP.

— generalnetworkerror

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, alla ricerca di una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

15

È improbabile (ma non impossibile) per le comunità che tagghi sui tuoi percorsi propagarsi oltre il tuo monte. La maggior parte dei fornitori eliminerà le comunità prima di rileggere le rotte verso l'alto / il basso.

Se si desidera influenzare più AS remoti in questo modo, è necessario utilizzare il prepending AS_PATH. Prepara 2-3 volte al tuo provider di backup / passivo, quindi la maggior parte / tutto il traffico scorrerà lungo il tuo percorso attivo fino a quando non fallisce. Quindi il traffico dovrebbe spostarsi sul percorso passivo una volta che il percorso fallito viene ritirato.

— Justin Seabrook-Rocha
fonte

4

Se il cliente A ha transito dal provider P1 e P2 e antepone a P2. Quindi un altro cliente B di P2 può local_pref rotte ricevute da P2 (forse è più economico), vale a dire che l'anticipo non garantisce che tutto il traffico cambierà e non esiste alcun modo reale per garantirlo in BGP, a parte estrarre il percorso da non preferito o perdite più specifiche per il partner preferito, nessuna delle quali può essere raccomandata.

— ytti,

2

Corretta! Così l'eterna lotta dell'ingegneria del traffico, come influenzare una rete con cui non hai relazioni. Probabilmente avrei dovuto dire "più" invece di "tutto", ma anteporre e più specifiche sono davvero le uniche due opzioni che possono davvero influire in questo caso.

— Justin Seabrook-Rocha,

3

Come diceva ytti, i trucchi AS_PATH sono nella migliore delle ipotesi un suggerimento. Alla fine della giornata, vinceranno le preferenze dell'amministratore locale. Se voglio che il traffico verso una rete specifica attraversi un collegamento specifico, lo farà ; non c'è niente che Internet possa fare per cambiare la mia configurazione di routing.

— Ricky Beam,

6

Il provider dovrebbe disporre di un filtro in entrata per garantire che queste community siano accettate solo dai clienti. In caso contrario, questo è il problema dei provider.

Alcuni provider Tier1 accettano questo tipo di comunità da qualsiasi luogo. Questo si basa su RFC 1998: http://tools.ietf.org/html/rfc1998.html

— mellowd
fonte

Il consenso sembra chiaro. Sembra quasi impossibile influenzare le preferenze locali degli AS remoti.

— Dennis Olvany,

5

Il meglio che di solito puoi fare è cercare le community con il tuo provider che ti consentano di indicare i premi per peer del tuo provider. Ciò presuppone che il proprio provider disponga di tali comunità e abbia le relazioni di peering affinché ciò funzioni. Preparare i propri annunci al proprio pari non avrebbe alcuna variazione a monte del proprio provider. Sebbene questo metodo non modifichi localpref un AS rimosso dal proprio provider, ha un impatto simile nel rendere meno desiderabile quel percorso. C'è un'eccezione all'influenza di localpref a monte che descriverò in fondo, anche se probabilmente è un caso limite.

Alcuni provider come XO [AS2828] ti consentono di pubblicizzare i tuoi prefissi in modo tale che il tuo provider annunci i tuoi percorsi con anteprime specifiche per alcuni loro colleghi.

Ad esempio, XO accetta:

2828:1108antepone una volta per AT&T
2828:1207antepone due volte per
2828:1303Level3 anticipa tre volte per Sprint

Su Savvis, la community è quella 3561:30151che antepone una volta a AT&T.

Questi provider di solito dispongono di community per indicare le community ben note di NO_EXPORT o NO_ADVERTISE a colleghi specifici.

Un provider di livello 2 che conosco, InterNAP, è in grado di influenzare localpref a monte perché acquistano transito, quindi sono clienti del livello 1. Hanno comunità che è possibile utilizzare laddove tentano di tradurle in specifiche comunità di livello 1 per le pubblicità a monte che impostano localpref su valori peer, mid o high. Vedi http://www.onesc.net/communities/as6993/Internap-Customer-Guide-1.3.pdf .

Riferimenti di esempio:
XO community che modificano le comunicazioni dei clienti a determinati peer su AS2828 Border Savvis Prepend
Attributi comunità

Non ho alcuna affiliazione con i provider utilizzati negli esempi diversi dall'esperienza diretta come cliente.

— generalnetworkerror
fonte