Recurso mLRE no roteador IOS-XE

Introduction

Este documento descreve o recurso Multicast Leaf Recycle Elimination (mLRE) no roteador IOS-XE.

Problema

Se os hosts estão conectados em várias interfaces e solicitam tráfego multicast em um roteador. O roteador precisa fazer uma cópia do tráfego multicast e deve enviá-lo em todas as interfaces que solicitam o tráfego multicast desse grupo multicast específico. Se os pacotes forem processados em série, o que significa um pacote após o outro, ele ajuda o roteador a melhorar o desempenho. No entanto, isso cria um atraso injusto em nós diferentes devido à sua natureza. Esse processamento serial de tráfego multicast é chamado de LRE nos roteadores multicast e é, por padrão, ativado nos roteadores que dependem de sua versão e modelo do IOS.

Mesmo que o processamento de pacotes em série cause uma diferença de 4 a 12 microssegundos entre os pacotes processados adjacentemente.
Ela pode criar um atraso significativo em ambientes críticos de tempo, como a empresa Trading, se houver um grande número de nós leaf que solicitam tráfego multicast.

Esta imagem mostra a topologia para entender melhor isso.

Como você pode ver, temos 4 hosts conectados ao LHR e eles estão solicitando tráfego para o grupo multicast 239.1.1.1.

Se o packet tracer é executado no LHR, então se vê que o pacote recebido da origem é consumido silenciosamente pelo LHR e então ele criou 4 pacotes semelhantes e os encaminhou a cada interface conectada ao 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 os detalhes dos pacotes capturados forem abertos, você poderá ver a hora de início e de término de cada pacote.

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 as horas de início e término das saídas mencionadas anteriormente forem comparadas, percebe-se que o processamento do pacote está acontecendo em série.

  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 o tempo de parada do pacote 1 (02:43:56.203804) e do pacote 4 (02:43:56.203821) for comparado, você poderá ver que há uma diferença de tempo de 17 microssegundos.
Em algumas organizações críticas, esse atraso pode não ser aceitável e, portanto, precisa ser reduzido.

Solução

Para evitar esse atraso de tempo, desative o recurso LRE no roteador.

Se o recurso LRE estiver desabilitado, o processamento de pacotes para a interface diferente para a replicação de tráfego multicast é independente um do outro e é processado em paralelo.

Para desabilitar o recurso mLRE, use este comando: outer(config)# platform multicast off