Come segnalare una modifica multihoming VPLS a un dispositivo L2 CE

Abbiamo la seguente configurazione:

Due router MX si collegano allo stesso sito L2. La protezione / ridondanza del loop viene eseguita tramite il multihoming VPLS . All'altra estremità ci sono due interruttori (ad esempio EX4200).

Quando il collegamento blu fallisce, i due switch e il resto dell'infrastruttura L2 devono sapere che il traffico deve ora passare attraverso il link giallo (e di conseguenza tramite lo switch EX sulla destra).

Il problema è che la mac-table gialla viene riempita solo quando c'è traffico proveniente dal VPLS attraverso il link giallo. Se non viene ricevuto traffico da un determinato indirizzo MAC, il traffico per quell'indirizzo verrà comunque inviato sul collegamento blu e nessuno sa che quel collegamento è ora interrotto (tranne forse l'interruttore EX sulla sinistra se il collegamento fallisce fisicamente).

Non riesco a trovare una buona soluzione per risolvere questo problema.

Alcuni approcci:

1. È possibile ridurre in qualche modo l'impatto non eseguendo il portfast del collegamento blu / giallo in modo che spanning-tree possa inviare una modifica della topologia quando l'interfaccia scende / su. Quando l'interfaccia non si abbassa fisicamente, sei sfortunato. D'altra parte, la soluzione spanning-tree ti morderà quando la porta si riapre. VPLS porterà il sito online ma la porta deve passare attraverso le fasi di apprendimento STP prima di inoltrare il traffico.

2. È possibile impilare i due interruttori. Ciò risolverà il problema per il resto dell'infrastruttura L2 poiché inviano sempre allo stesso switch (stack). Tuttavia, lo stack deve sapere quando passare all'altra interfaccia di uplink con l'istanza VPLS attiva.

3. Quando si esegue la manutenzione pianificata (e se si dispone di uno stack), è possibile disattivare manualmente il collegamento primario per passare al collegamento secondario. Quindi è possibile ridurre la preferenza del sito per il collegamento disattivato sul router in modo che il sito ora attivo diventi il ​​nuovo primario. Stessa cosa quando si torna indietro. Non è l'ideale e non funziona per interruzioni impreviste.

Ogni input su come risolverlo è apprezzato. (Aspettare EVPN / TRILL non conta.;))

1. Disabilita Portfast sulle porte PE rivolte (su CE)
2. Abilita RSTP attraverso la rete CE
3. Favorire il "collegamento blu" con il costo dell'interfaccia

Risolvendo questo nella mia testa credo che dovrebbe reagire come segue:

Quando il collegamento blu si interrompe, CE interromperà l'invio / la ricezione di BPDU dall'interfaccia blu. Il timer ciao RSTP predefinito è 2 secondi. Aspetta tre hellos mancanti prima di chiamare quel link "morto". Una volta persi tre hellos (6 secondi), ripristinerà l'albero STP e invecchierà gli indirizzi MAC.

Questa è fondamentalmente l'opzione 1 che hai dichiarato sopra, tranne il modo in cui ho letto i commenti e il tuo post originale sembra che tu voglia che PE partecipi a STP. Sto suggerendo di consentire al cliente di costruire il proprio albero tra tutti i CE.

La rete dovrebbe funzionare senza problemi e la rete client seguirà l'esempio pochi secondi dopo.

Sembra troppo semplice per essere la risposta ... ma è quello che posso vedere in base alla tua scrittura.

Che tipo di budget per la convergenza stai cercando?

Se abbandonassi l'idea di utilizzare la prevenzione loop VPLS ed eseguissi siteID univoco, potresti tornare a STP. Si verificherebbe la perdita di collegamento tramite BPDU anche in assenza di errori di vivacità dell'hardware.

Quindi è possibile ottimizzare il budget di convergenza in base a TCN / tempo di inoltro (timeout MAC, dopo che TCN è stato visto) o con un "tempo di invecchiamento mac" più elevato.
Il rovescio della medaglia è che avrai un unicast più sconosciuto nella rete, che puoi aggirare assicurandoti che il timeout ARP sia inferiore o uguale a TCN / forward-time

Probabilmente non conosco la risposta che stai cercando, ma se c'è un proiettile d'argento qui, mi manca. Non penso che trill o la bozza EVPN ti aiuterebbero in questo scenario, se il tuo VPLS o EVPN fosse end-to-end direttamente alla porta host, quindi risolverebbe questo problema. Ma sostituire semplicemente VPLS in EVPN nel core e mantenere la LAN disconnessa su entrambi i lati, fornirebbe lo stesso problema.

Attenendosi alle opzioni fornite, seguirò personalmente il n. 1 del tuo elenco, ma non userei le ST comuni. Preferirei usare RST (o MST se è necessario bilanciare il carico delle VLAN tra i collegamenti) in quanto consente una transizione veloce / più fluida quando un collegamento sale o scende.

Questo risolve entrambe le preoccupazioni che hai per questo approccio:

1. "L'interfaccia non si abbassa fisicamente": ogni dispositivo che esegue RST genera BPDU (anziché solo inoltro) e vengono utilizzati come keep live. La mancata ricezione di BPDU comporterà l'invecchiamento delle informazioni.
2. "Necessità di passare attraverso le fasi di apprendimento STP prima di inoltrare il traffico" - RST è in grado di confermare attivamente che una porta può passare in sicurezza allo stato di inoltro senza attendere i timer.

Vorrei anche prendere in considerazione l'idea di fare il secondo posto in quanto semplifica la gestione dei dispositivi.

Forse uno script di eventi potrebbe essere creato sull'MX "non riuscito" per rimuovere il collegamento? Se esiste un tipo di trasporto illuminato, potrebbe non funzionare.

Nella maggior parte delle applicazioni su cui ho lavorato in questo modo, abbiamo avuto un traffico bidirezionale, in modo tale che i MAC di rimozione che dovrebbero spostarsi arrivino alla fine tramite la porta di backup, e la vecchia voce FIB venga sfrattata e la nuova porta installata.

Se il tuo sito L2 servito da questi EX invia solo traffico, l'unica cosa che potrei pensare di fare sarebbe ridurre il tempo di invecchiamento del Mac-Table a un importo accettabile.