Ha senso distribuire OSPF su Metro Ethernet?

Quando ho bisogno di connettere un numero di filiali tra loro per un cliente, in genere consiglio una VPN MPLS tramite un operatore fidato. Il CE in ogni sito parla BGP con il suo PE a monte e ogni sito è numerato con il proprio ASN privato. Questo è molto conveniente per noi poiché BGP fornisce una miriade di strumenti di ingegneria del traffico e le nostre adiacenze sono limitate a n + 1 per n siti (il +1 è il nostro ambiente di colore).

Ultimamente, tuttavia, ho notato un crescente interesse dei clienti per le soluzioni Metro Ethernet. Molti dei nostri clienti hanno filiali all'interno di un'area metropolitana comune e le quotazioni MetroE arrivano a diverse centinaia di dollari (USD) in meno rispetto al servizio MPLS per circuiti con le stesse velocità. Anche se questo è interessante, non sono sicuro di come stabilire il routing su una backbone di livello due evitando di trasformare una topologia mesh in hub e raggio.

BGP richiederebbe una rete completa di adiacenze tra i siti delle filiali per mantenere la connettività della rete, che ovviamente non è auspicabile dal punto di vista della scalabilità. L'altra opzione è quella di distribuire un IGP, vale a dire OSPF, e avere tutti i siti adiacenti alla WAN. Vorrei considerare ogni sito come una propria area, che sembra eccessivo, ma voglio preservare la capacità di riassumere i percorsi pubblicizzati da ciascun sito e questo può essere fatto solo ai confini dell'area.

ha senso? Ci sono avvertimenti a cui prestare attenzione quando si distribuisce OSPF in questo modo (ad esempio, dovrei considerare la disabilitazione dell'inondazione LSA)? O c'è un'altra soluzione che ho trascurato?

Questa è una domanda complessa, poiché i due diversi prodotti sono molto diversi. Un circuito MPLS L3VPN è intrinsecamente una mesh completa tra tutte le posizioni che partecipano, mentre una connessione MetroE è generalmente un collegamento punto a punto tra due siti specifici.

Nella mia esperienza, un circuito MetroE è un percorso fornito direttamente, senza servizi di protezione, a meno che non sia contrattato con un percorso di protezione. Ciò significa che il fallimento di un'interfaccia o di un router lungo il percorso specifico comporterebbe l'interruzione del traffico tra i due siti direttamente collegati dal servizio MetroE. MPLS L3VPN risolverà i problemi di interfaccia / routing per mantenere una mesh completa tra i siti. Questo generalmente spiega la differenza di prezzo tra i due.

Non c'è niente di sbagliato nel costruire i propri servizi su una piattaforma MetroE: devi solo lavorare con i requisiti dei clienti per determinare quale tipo di routing è appropriato. Se stai lavorando con una piccola rete di uffici, OSPF / IS-IS / EIGRP potrebbe essere un modo meraviglioso per scambiare informazioni di routing tra i siti collegati direttamente che hai creato. Se sei più un NSP / ISP / * SP, separare l'infrastruttura e le rotte dei clienti tra IGP ed EGP diventa molto più importante man mano che si scala.

Come ingegnere ISP, utilizziamo ampiamente i collegamenti MetroE ed EWAN per costruire la nostra spina dorsale e utilizziamo la nostra conoscenza dei collegamenti fisici per progettare il nostro ambiente iBGP / eBGP. In molti casi, utilizziamo i riflettori del percorso e i riflettori a doppio percorso (route-reflector-client su entrambi i lati del peering) per ridurre il conteggio dei peer iBGP. Tuttavia, a meno che tu non abbia a che fare con più di 6 router in un POP, iBGP si adatta abbastanza bene.

In breve, se è per un singolo client, che non offre servizi di rete ai propri clienti, attenersi a un IGP. Se la connettività esterna deve essere condivisa tra i siti, con failover / ridondanza / ecc., Esaminare attentamente i percorsi fisici che si hanno e progettare l'eBGP / iBGP per riflettere ciò. Inutile avere un router in una posizione remota con solo 1 collegamento all'esterno del sito per peer iBGP con tutti gli altri router nell'AS: utilizzare un riflettore a doppia route.

Passare da un L3VPN gestito (quello che presumo tu intendessi con "VPN MPLS") a un L2VPN è un bel passo avanti in quanto puoi eseguire protocolli non IP e ottenere il controllo totale dei protocolli di routing e delle piattaforme di routing che definiscono il tuo routing topologia.

Supponendo di posizionare un solo indirizzo MAC Ethernet sul lato CPE di ciascuno dei tuoi siti, è molto più semplice per l'apparecchiatura del provider apprendere e inoltrare 1 indirizzo MAC per sito, piuttosto che apprendere e instradare potenzialmente molte sottoreti per sito.

Per quanto riguarda il protocollo, questa è una domanda un po 'complicata a cui rispondere senza molte più informazioni, poiché la scelta migliore dipende dal traffico e dai piani di crescita.

Questo è solo un grande cliente che ha bisogno di connettività interna e Internet o vende anche connettività? Supponendo che sia tutto interno, quindi dovrai solo distribuire un IGP e magari eseguire un eBGP per annunciare i percorsi.

Se non hai molti siti o prefissi interni, un protocollo di stato dei collegamenti come OSPF o IS-IS ha più senso, poiché converge rapidamente e può creare rapidamente la FIB dal RIB se ci sono solo alcuni prefissi .

Se avrai molti siti o molti prefissi, questo inizierà a tassare le tue piattaforme di routing, poiché ognuna deve elaborare ciascuna. Questo è qualcosa che inizia a richiedere n ² volte. Se ci sono siti che vanno su e giù spesso, questo cambiamento nello stato dei collegamenti può anche iniziare a tassare il pool di router.

Se hai molti siti, molti siti tozzi (un percorso "a monte", nessun altro router a valle) o un sacco di churn di rotta, dovrai esaminare altri protocolli o topologie.

In un caso del genere, consiglierei di usare BGP con alcuni catarifrangenti. In questo modo, è possibile eseguire il provisioning di 2+ catarifrangenti per percorsi pesanti in cui i raggi annunciano e per i quali gli altri raggi possono prendere una tabella di instradamento. In questo modo, puoi distribuire CPE leggeri nei tuoi numerosi siti a raggi che si collegano, annunciano il loro spazio e ottengono una tabella interna o un percorso predefinito verso un router che lo fa.

Approssimativamente, suggerirei alcune scale e attrezzature (e ipotizzando un throughput sub-Gigabit):

• 1 - 20 raggi - OSPFv3 tra tutti i siti. Juniper SRX240 o simile per tutti i siti.
• 20 - 100 raggi - iBGP con catarifrangenti. Juniper SRX240 nei raggi, Juniper MX5 / 10/40/80 per la riflessione del percorso (o Debian Linux / BIRD).
• 100 - 500 raggi: inizia a suddividerli in diverse reti L2, AS o aree

Solo per aggiungere due bit comunemente trascurati alla discussione BGP:

• Se si esegue iBGP, in genere è necessario un altro protocollo di routing per stabilire la connettività tra i successivi hop di BGP. Dal punto di vista del design, iBGP è più uno strumento di scalabilità che un protocollo di routing;
• Se esegui eBGP, non hai bisogno di una mesh completa di sessioni BGP per flussi di traffico end-to-end ottimali; L'elaborazione dell'hop successivo BGP risolve bene questi problemi.

Vedi http://blog.ioshints.info/2011/08/bgp-next-hop-processing.html per maggiori dettagli

Potresti benissimo eseguire OSPF (o altri IGP) su un servizio Metro-Ethernet multipunto e dovrebbe funzionare molto bene.

Ci potrebbero essere motivi per continuare a eseguire BGP, tuttavia ... anche se sarebbero gli stessi argomenti del motivo per cui potresti voler eseguire BGP anche nella tua rete.

Non devi necessariamente mettere tutti i tuoi altoparlanti BGP nello stesso AS su una rete "broadcast" del genere. Pensalo come una sorta di IXP interno gestito dalle telecomunicazioni in cui i tuoi AS privati ​​possono interconnettersi tra loro tramite una mesh di livello 2. Non dovresti nemmeno necessariamente mantenere una mesh completa di peer BGP poiché gli aggiornamenti BGP possono contenere un hop successivo nel suo messaggio di aggiornamento che non è lo stesso da cui proviene la sessione peer.

Quindi, ad esempio, se hai una mesh di livello 2 con router A, B e C su di essa e hai peer BGP tra A e B e tra B e C, quando C ottiene aggiornamenti per le rotte originate da A, lo farà avere A come hop successivo, anche se sono stati appresi durante la sessione di peering con B. Ovviamente si vorrebbe un peering di route maggiore rispetto a un solo hub e raggio, quindi non si dipende dal singolo hub, ma si non ho bisogno di una maglia piena in alcun modo.

Avrai comunque tutti i vantaggi della politica di routing eseguendo BGP se lo fai in questo modo ... e anche, come ha detto un altro intervistato, può usare lo stesso spazio numerico AS privato e potrebbe persino connettersi con L3VPN esistente in modo che il tuo modello e i meccanismi di supporto non devono cambiare.

Detto questo, ho un paio di collegamenti metro-E (punto a punto nel mio caso) che eseguo OSPF e iBGP e funziona perfettamente.

Che dire di una configurazione route-server con "razze" come client rs dell'hub / router principale?

Anche se i peer bgp sarebbero come una topologia hub & speak, tutti i raggi dovrebbero essere in grado di inviare il traffico direttamente a tutti gli altri.

È anche possibile riutilizzare gli stessi numeri AS privati ​​di quelli utilizzati con il provider MPLS per facilitare la migrazione da un servizio a un altro.

Consiglio vivamente di leggere e prendere una decisione in merito a topologie OSPF alternative come iniziare come NBMA anziché standard. Presto ti renderai conto che non è possibile selezionare correttamente OSPF tra due percorsi che vanno allo stesso router / sito all'interno della stessa Ethernet della metropolitana, a causa del modo in cui il costo viene calcolato tramite l'interfaccia in uscita, i collegamenti WAN principali e di backup appariranno uguali costo in OSPF standard. Tuttavia, se si sceglie di utilizzare NBMA, ad esempio, è possibile definire manualmente i costi vicini, ma ora è necessario definire manualmente la mesh / adiacenze.

Qualunque cosa tu faccia, PERCORSI SU DI NO NON RIPETUTO NON UNISCITI A LAYER 2, in seguito chiederai solo problemi, se hai bisogno di interconnettività di livello 2, usa OTV o altra funzione di livello 2 su livello 3.

Scoprirai rapidamente che imparerai molto di più su OSPF (e avrai bisogno di sapere molto di più) rispetto a un semplice provider MPLS-VPN in cui il core WAN ti è nascosto.

OSPF su metroE funziona bene ma dovrai assicurarti che si adatti alle tue esigenze e che tu architetti di conseguenza. Un avvertimento che non ho visto menzionato è quello di assicurarti di sapere quale MTU supporta il tuo provider. Ho visto un calo di MTU su un collegamento metroE durante la manutenzione di un provider che non ha generato il vicino OSPF. Probabilmente è solo un problema perché non supportano davvero i jumbo frame ma lo hanno fatto solo per noi :) Essere gentili a volte non paga.