Funzione LRE sul router IOS-XE

Introduzione

Questo documento descrive la funzione Multicast Leaf Recycle Elimination (mLRE) sul router IOS-XE.

Problema

Se gli host sono connessi su più interfacce e richiedono il traffico multicast su un router. Il router deve creare una copia del traffico multicast e deve inviarla su tutte le interfacce che richiedono il traffico multicast di quel particolare gruppo multicast. Se i pacchetti vengono elaborati in modo seriale, ossia uno dopo l'altro, aiuta il router a migliorare le prestazioni. Tuttavia, crea un ingiusto ritardo in diversi nodi a causa della sua natura. Questa elaborazione seriale del traffico multicast viene chiamata LRE nei router multicast e, per impostazione predefinita, è abilitata sui router che dipendono dalla versione e dal modello del sistema operativo IOS in uso.

Anche se l'elaborazione seriale dei pacchetti causa una differenza di 4-12 microsecondi tra due pacchetti elaborati in modo adiacente.
Potrebbe creare un ritardo significativo in ambienti critici in termini di tempo come la Trading Company se ci sono un gran numero di nodi foglia che richiedono traffico multicast.

Questa immagine mostra la topologia per comprendere meglio questa condizione.

Come si può vedere, abbiamo 4 host collegati all'LHR che stanno richiedendo il traffico per il gruppo multicast 239.1.1.1.

Se il tracciatore dei pacchetti viene eseguito su LHR, il pacchetto ricevuto dall'origine viene automaticamente utilizzato da LHR, quindi vengono creati 4 pacchetti simili e inoltrati a ciascuna interfaccia connessa all'host.

LHR#show platform packet-trace summary 
Pkt   Input             Output            State  Reason
0     Gi2               <none>            CONS   Packet Consumed Silently     <<< recieved packet from sender
1     Gi2               Gi6               FWD                                 <<< first replicated packet sent to int gig6
2     Gi2               Gi5               FWD                                 <<< first replicated packet sent to int gig5
3     Gi2               Gi4               FWD                                 <<< first replicated packet sent to int gig4
4     Gi2               Gi3               FWD                                 <<< first replicated packet sent to int gig3 

Se si aprono i dettagli dei pacchetti acquisiti, è possibile visualizzare l'ora di inizio e l'ora di fine di ciascun pacchetto.

LHR#show platform packet-trace packet 0
Packet: 0           CBUG ID: 85
Summary
  Input     : GigabitEthernet2
  Output    : <none>
  State     : CONS Packet Consumed Silently
  Timestamp
    Start   : 37067929596524 ns (05/27/2020 02:43:56.203649 UTC)
    Stop    : 37067929669545 ns (05/27/2020 02:43:56.203722 UTC)
	
LHR#show platform packet-trace packet 1
Packet: 1           CBUG ID: 85
Summary
  Input     : GigabitEthernet2
  Output    : GigabitEthernet6
  State     : FWD 
  Timestamp
    Start   : 37067929722925 ns (05/27/2020 02:43:56.203776 UTC)
    Stop    : 37067929750941 ns (05/27/2020 02:43:56.203804 UTC)

LHR#show platform packet-trace packet 2
Packet: 2           CBUG ID: 85
Summary
  Input     : GigabitEthernet2
  Output    : GigabitEthernet5
  State     : FWD 
  Timestamp
    Start   : 37067929752437 ns (05/27/2020 02:43:56.203805 UTC)
    Stop    : 37067929759667 ns (05/27/2020 02:43:56.203812 UTC)

LHR#show platform packet-trace packet 3
Packet: 3           CBUG ID: 85
Summary
  Input     : GigabitEthernet2
  Output    : GigabitEthernet4
  State     : FWD 
  Timestamp
    Start   : 37067929760929 ns (05/27/2020 02:43:56.203814 UTC)
    Stop    : 37067929766997 ns (05/27/2020 02:43:56.203820 UTC)

LHR#show platform packet-trace packet 4
Packet: 4           CBUG ID: 85
Summary
  Input     : GigabitEthernet2
  Output    : GigabitEthernet3
  State     : FWD 
  Timestamp
    Start   : 37067929768236 ns (05/27/2020 02:43:56.203821 UTC)
    Stop    : 37067929774283 ns (05/27/2020 02:43:56.203827 UTC) 

Se si confrontano l'ora di inizio e di fine delle uscite menzionate in precedenza, l'elaborazione del pacchetto procede in modo seriale.

  Start   : 37067929722925 ns (05/27/2020 02:43:56.203776 UTC)  << packet1
    Stop    : 37067929750941 ns (05/27/2020 02:43:56.203804 UTC)
    Start   : 37067929752437 ns (05/27/2020 02:43:56.203805 UTC)  << packet 2
    Stop    : 37067929759667 ns (05/27/2020 02:43:56.203812 UTC)
    Start   : 37067929760929 ns (05/27/2020 02:43:56.203814 UTC)  << packet 3
    Stop    : 37067929766997 ns (05/27/2020 02:43:56.203820 UTC)
    Start   : 37067929768236 ns (05/27/2020 02:43:56.203821 UTC)  << packet 4
    Stop    : 37067929774283 ns (05/27/2020 02:43:56.203827 UTC) 

Se si confronta l'ora di arresto del pacchetto 1 (02:43:56.203804) e del pacchetto 4 (02:43:56.203821), si osserverà una differenza di tempo di 17 microsecondi.
In alcune organizzazioni con problemi di tempo questo ritardo potrebbe non essere accettabile e deve quindi essere ridotto.

Soluzione

Per evitare questo ritardo, disabilitare la funzione LRE sul router.

Se la funzione LRE è disabilitata, l'elaborazione dei pacchetti per la diversa interfaccia di replica del traffico multicast è indipendente l'una dall'altra e viene elaborata in parallelo.

Per disabilitare la funzione mLRE, usare questo comando: outer(config)# platform multicast lre off