Función mLRE en el router IOS-XE

Introducción

Este documento describe la función Eliminación del reciclaje de hoja multidifusión (mLRE) en el router IOS-XE.

Problema

Si los hosts están conectados en varias interfaces y solicitan tráfico multicast en un router. El router tiene que hacer una copia del tráfico multicast y debe enviarla en todas las interfaces que solicitan el tráfico multicast de ese grupo multicast en particular. Si los paquetes se procesan en serie, lo que significa un paquete tras otro, entonces ayuda al router a mejorar el rendimiento. Sin embargo, crea un retraso injusto en diferentes nodos debido a su naturaleza. Este procesamiento serial del tráfico multicast se denomina LRE en los routers multicast y de forma predeterminada se habilita en los routers que dependen de su versión y modelo de IOS.

A pesar de que el procesamiento de paquetes causa seriamente una diferencia de 4-12 microsegundos entre los paquetes procesados adyacentes.
Podría crear un retraso significativo en entornos de tiempo crítico como la empresa de comercio si hay un gran número de nodos de hoja que solicitan tráfico multidifusión.

Esta imagen muestra la topología para entenderlo mejor.

Como puede ver, tenemos 4 hosts conectados al LHR y están solicitando tráfico para el grupo multicast 239.1.1.1.

Si packet tracer se ejecuta en LHR, se ve que el paquete recibido del origen es consumido silenciosamente por LHR y luego creó 4 paquetes similares y los reenvió a cada interfaz conectada al 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 

Si se abren los detalles de los paquetes capturados, puede ver la hora de inicio y la hora de finalización de cada paquete.

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) 

Si se compara la hora de inicio y de finalización de las salidas mencionadas anteriormente, se entiende que el procesamiento de paquetes se está realizando en serie.

  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) 

Si se compara el tiempo de detención del paquete 1 (02:43:56.203804) y el paquete 4 (02:43:56.203821), puede ver que hay una diferencia de tiempo de 17 microsegundos.
En algunas organizaciones en las que el tiempo es vital, este retraso puede no ser aceptable y, por lo tanto, debe reducirse.

Solución

Para evitar este retardo de tiempo, inhabilite la función LRE en el router.

Si se inhabilita la función LRE, el procesamiento de paquetes para la interfaz diferente para la replicación del tráfico multicast es independiente entre sí y se procesa de manera paralela.

Para inhabilitar la función mLRE, utilice este comando: outer(config)# platform multicast lre off