Contents

Introdução

Seleção de plataforma de hardware/software

Considerações Sobre Escalabilidade E Desempenho

Número de pares BGP

Famílias de Endereços

Número De Grupos De Atualização

Complexidade de RPLs (políticas de rota)

Frequência De Atualizações

MSS de TCP e MTU de Interface/Caminho

NSR em roteadores RP duplos

Pares lentos

Nexthop trigger-delay

Exemplo de escala de RR de BGP multidimensional validada

Considerações do projeto

Monitorar KPIs (Key Performance Indicators, principais indicadores de desempenho) do BGP

Monitorar Encaminhador de Caminho de Dados

Monitore o DPA (Data Plane Agent) XRv9000

Monitor ASR9000Processador de rede (NP)

Monitorar LPTS

Monitorar SPP

Monitorar NetIO

Monitorar filas XIPC

Monitorar filas de entrada e saída do BGP

Monitorar taxas de mensagens BGP

Monitorar a utilização da CPU

Monitorar estatísticas de TCP

Monitorar Utilização de Memória

Monitorar o desempenho do processo BGP

Monitorar a convergência do BGP

Introdução

Este documento descreve os principais contribuidores para a escala máxima que um Border Gateway Protocol (BGP) Route-Refletors (RR) pode alcançar e orientação sobre o monitoramento de desempenho BGP RR.

Seleção de plataforma de hardware/software

Um BGP RR de alta escala normalmente não está no caminho de encaminhamento de pacotes que transportam serviços fornecidos por um Provedor de Serviços de Internet. Portanto, os requisitos de hardware para um BGP RR e roteadores que estão predominantemente encaminhando pacotes no caminho de dados são diferentes. Os roteadores padrão são construídos com um poderoso elemento de encaminhamento de caminho de dados e um elemento de caminho de controle comparativamente moderado. Um BGP RR executa todas as suas tarefas em um plano de controle.

Dentro da família de produtos Cisco IOS® XR, você pode escolher entre 3 tipos de plataformas HW/SW para uma função BGP RR:

Roteador Cisco IOS XR físico

Dispositivo Cisco IOS XRv 9000

Roteador Cisco IOS XRv 9000 (também conhecido como XRv9k)

- Capacidade do plano de controle moderada (geralmente entre 2 e 6 núcleos de CPU alocados para RP XR VM)

- Capacidade não utilizada do caminho de dados

- Alta capacidade de plano de controle (em dispositivos com base no Cisco UCS M5, 36 núcleos de CPU são dedicados a RP XR VM)

- Divisão igual entre capacidade de caminho de dados e caminho de controle.

- Imagem XRv9k executada em barebone para desempenho máximo

- Capacidade personalizável do plano de controle

- Divisão igual entre a potência do caminho de dados e do caminho de controle ao usar a imagem BGP RR.

- Uma camada adicional de virtualização afeta o desempenho.

A partir desta redação, o XRv9k Appliance é a escolha ideal de plataforma para BGP RR porque fornece a maior capacidade de plano de controle com desempenho máximo.

Considerações Sobre Escalabilidade E Desempenho

A escala suportada de entidades de plano de dados é relativamente fácil de expressar porque o desempenho do elemento de caminho de dados raramente depende da escala. Por exemplo, uma pesquisa de TCAM leva o mesmo tempo, independentemente do número de entradas de TCAM ativas.

A escala suportada de entidades de plano de controle é frequentemente muito mais complexa porque a escala e o desempenho estão interconectados. Considere um BGP RR com rotas de 1M. O trabalho que um processo BGP deve realizar para manter esta tabela BGP depende de:

1. Quantos peers BGP estão ativos?

2. Quais famílias de endereços estão ativas?

3. Como eles são distribuídos em grupos de atualização?

4. A complexidade das RPLs (Políticas de Rota)

5. Frequência de atualizações (atualizações recebidas e também enviadas - intervalo de anúncio).

6. MSS de TCP, MTU de Interface/Caminho - o ajuste ajudará no melhor desempenho

7. Se for RP duplo, o NSR está habilitado

8. Qualquer par lento conhecido, que não esteja em um grupo de atualização separado

9. valor de retardo de gatilho Nexthop

Número de pares BGP

O número de peers BGP é geralmente a primeira e, infelizmente, muitas vezes a única coisa que vem à mente quando se considera a escala BGP. Embora a escala de BGP suportada não possa ser representada sem mencionar o número de peers de BGP, não é o fator mais importante. Muitos outros aspectos são igualmente relevantes.

Famílias de Endereços

O tipo de família de endereços (AF) é um fator importante nas considerações de desempenho do BGP porque em implantações típicas afeta o tamanho de uma única rota. O número de rotas IPv4 que podem ser empacotadas em um único segmento TCP é significativamente maior que o número de rotas VPNv4. Portanto, para a mesma escala de alterações de tabela de BGP, um RR de BGP IPv4 tem menos trabalho a fazer em comparação a um RR de BGP VPNv4. Obviamente, em implantações onde um número significativo de comunidades é adicionado a cada rota, a diferença entre AFs se torna menos significativa, mas o tamanho de uma única rota é ainda maior e requer consideração.

Número De Grupos De Atualização

O processo BGP prepara uma única atualização para todos os membros do mesmo grupo de atualização. Em seguida, o processo TCP divide os dados de atualização em um número necessário de segmentos TCP (dependendo do TCP MSS) para cada membro do grupo de atualização. Você pode ver os grupos de atualização ativos e seus membros usando oshow bgp update-groupcomando. Você pode influenciar quais e quantos peers são membros de um grupo de atualização criando uma política de saída comum para um grupo de peers que você deseja que esteja no mesmo grupo de atualização. Uma única atualização enviada pelo BGP RR para um grande número de clientes BGP RR pode disparar uma rajada de TCP ACKs que pode ser descartada no componente Local Packet Transport Service (LPTS) dos roteadores Cisco IOS XR.

Complexidade de RPLs (políticas de rota)

A complexidade das políticas de rota usadas pelo BGP impacta o desempenho do processo BGP. Cada rota recebida ou enviada deve ser avaliada em relação à política de rota configurada. Uma política muito longa exige que muitos ciclos de CPU sejam gastos nessa ação. Uma política de rota que inclui uma expressão regular é especialmente pesada no processamento. Uma expressão regular ajuda a expressar a política de rota em um número menor de linhas, mas requer mais ciclos de CPU durante o processamento do que a política de rota equivalente que não usa expressão regular.

Frequência De Atualizações

A frequência das atualizações tem um efeito importante na escala de BGP. O número de atualizações é frequentemente difícil de prever. Você pode influenciar a frequência de atualizações usando o comando "advertisement-interval", que define o intervalo mínimo entre o envio de atualizações de roteamento BGP. O valor padrão para peers iBGP é 0 segundo e 30 para peers eBGP é 30 segundos.

MSS de TCP e MTU de Interface/Caminho

Dividir uma atualização em muitos segmentos TCP pode sobrecarregar bastante os recursos do processo TCP em um ambiente de alta escala e alta frequência de atualização. Um MTU de caminho maior e um TCP MSS maior são melhores para o desempenho do BGP e do TCP.

NSR em roteadores RP duplos

O NSR é um excelente recurso para redundância, mas tem um impacto no desempenho do BGP. Nos roteadores Cisco IOS XR, ambos os RPs estão recebendo simultaneamente todas as atualizações de BGP diretamente da NPU na placa de linha de entrada, o que significa que o RP Ativo não precisa gastar tempo replicando a atualização para o RP em standby. No entanto, cada atualização gerada pelo RP Ativo deve ser enviada para o RP em Espera e daí para o correspondente BGP. Isso permite que o RP em standby esteja sempre atualizado nos números de sequência e de confirmação, mas tem um impacto no desempenho geral do BGP. É por isso que é recomendado que um BGP RR seja um roteador de RP único.

Pares lentos

Um peer lento pode retardar as atualizações em relação a todos os membros do grupo de atualização porque o processo BGP deve manter a atualização em sua memória até que todos os peers a confirmem. Se você souber que alguns pares são muito mais lentos (por exemplo, roteadores em uma parte antiga da rede), separe-os antecipadamente em um grupo de atualização. Por padrão, o Cisco IOS XR relata um peer lento através de uma mensagem de syslog. Você pode criar peers lentos estáticos (que nunca compartilham o grupo de atualização com outros) ou ajustar o comportamento dinâmico do peer lento usando o comando de configuração BGPslow-peerno modo de configuração global ou por vizinho. Uma boa leitura a mais sobre isso pode ser encontrada em Troubleshoot Slow BGP Convergence Due to Suboptimal Route Policies on IOS-XR no portal Cisco xrdocs.io.

Nexthop trigger-delay

Se vários próximos saltos do BGP mudarem em um curto intervalo de tempo e o valor crítico de retardo de gatilho de próximo salto de zero for configurado em uma família de endereços (AF) com um número alto de rotas, um passo completo do AF deve ser executado em cada evento de mudança de próximo salto. Caminhos repetidos desse AF aumentam o tempo de convergência em famílias de endereços com valores críticos mais baixos de retardo de gatilho de próximo salto. Você pode ver os valores de trigger-delay do próximo salto executando o comando "show bgp all nexthops".

Exemplo de escala de RR de BGP multidimensional validada

Os resultados da escala multidimensional, especialmente para as características do plano de controle, são altamente dependentes do ambiente de teste específico. Os resultados do teste podem variar significativamente se alguns dos parâmetros forem alterados.

Parâmetro

Valor

Valor

Platform

Dispositivo XRv9k (baseado em UCS M5)

ASR9902

versão IOS XR

7.5.2 + SMU de guarda-chuva para ID de bug Cisco CSCwf09600 .

(Os componentes deste SMU de guarda-chuva estão integrados no Cisco IOS XR versão 7.9.2 e posterior)

7.11.2

Pares

eBGP de VPNv4: 2500

iBGP de VPNv4: 1700

iBGP de VPNv4: 2000

Rotas BGP

Por sessão: 200

Total: 400 k

Caminhos por rota: 1

Por sessão: 750

VPNv4: 1,36 M

VPNv6: 150 mil

IPv4: 950 k

IPv6: 200 mil

Total: ~2,6 milhões

Caminhos por rota: 1

Rotas IGP

10 k (ISIS)

10 k (ISIS)

Grupos de atualização do BGP

1

1

Temporizadores BGP

padrão

padrão

LPTS BGP-known policer rate

50,000

25,000

configuração tcp num-thread

16 16

16 16

BGP send-buffer-size

padrão

padrão

Resumo dos KPIs (Key Performance Indicators, principais indicadores de desempenho)

- Caso de teste com a maior taxa de pacotes de entrada e saída:

- Entrada: 49,4 kpps

- Saída: 95 kpps

- ==> quedas de LPTS (vigilante a 50kpps)

- ==> Não há quedas em clientes NetIO

- ==> Tamanho máximo da fila XIPC (BGP): 1362

- ==> Tamanho máximo da fila XIPC (TCP): 1248

- Caso de teste com a maior taxa de pacotes de entrada:

- Entrada: 16030 pkts/s

- Saída: 31 pacotes/s

- ==> Não há quedas nos clientes LPTS nem NetIO

- ==> Tamanho máximo da fila XIPC (BGP): 378

- ==> Tamanho máximo da fila XIPC (TCP): 1021

- Caso de teste com maior taxa de pacotes de saída:

- Entrada: 12172 pkts/s

- Saída: 23465 pkts/s

- ==> Não há quedas nos clientes LPTS nem NetIO

- ==> Tamanho máximo da fila XIPC (BGP): 109

- ==> Tamanho máximo da fila XIPC (TCP): 1518

Considerações do projeto

Há duas abordagens para o posicionamento do BGP RR na rede:

1. Projeto de RR de BGP centralizado/plano.

2. Projeto BGP RR distribuído/hierárquico.

Em um design centralizado/plano, todos os clientes BGP RR na rede estabelecem o peering BGP com um conjunto (geralmente um par) de dispositivos BGP RR que mantêm exatamente as mesmas informações. Essa abordagem é simples de implementar e funciona bem em redes de pequena a moderada escala. Qualquer alteração na tabela BGP é propagada rapidamente para todos os clientes BGP RR. À medida que o número de clientes BGP RR cresce, o design pode atingir um limite de escala quando o número de conexões TCP nos dispositivos BGP RR cresce na extensão em que seu desempenho é afetado.

Em um projeto distribuído/hierárquico, a rede é dividida em várias regiões. Todos os roteadores em uma região estabelecem peering BGP com um conjunto (geralmente um par) de dispositivos BGP RR que mantêm exatamente as mesmas informações. Esses dispositivos BGP RR atuam como clientes BGP RR para outro conjunto (geralmente um par) de dispositivos BGP RR. Essa abordagem de projeto permite uma fácil expansão da rede, mantendo o número de conexões TCP em cada BGP RR abaixo de um certo limite.

Outra consideração de design é adaptar o escopo dos destinatários de atualizações de BGP. Dependendo da distribuição de VRF entre clientes BGP RR, vale a pena considerar a distribuição de rota restrita RT. Se todos os clientes BGP RR tiverem interfaces no mesmo VRF, a Distribuição de Rota Restrita RT não traz muitos benefícios. No entanto, se os VRFs forem distribuídos de forma esparsa entre todos os clientes BGP RR, o uso da Distribuição de Rota Restrita RT reduz significativamenteƒ a carga no processo de bgp no BGP RR.

Monitorar KPIs (Key Performance Indicators, principais indicadores de desempenho) do BGP

O monitoramento dos KPIs (Key Performance Indicators, principais indicadores de desempenho) do BGP RR é importante para garantir a operação adequada da rede.

Uma alteração significativa na topologia de rede (por exemplo, um flap de enlace DWDM principal) pode disparar atualizações de roteamento que geram tráfego excessivo para e/ou do BGP RR. Tráfego significativo que atinge o BGP RR normalmente carrega:

1. Atualizações de pares BGP.

2. ACKs TCP gerados pelos peers BGP, em resposta a atualizações enviadas pelo BGP RR e vice-versa

Esta seção do documento explica o KPI que precisa ser monitorado em um BGP RR típico e também como saber quais dos dois tipos de tráfego BGP significativos estão causando alta taxa de tráfego de plano de controle.

O caminho dos pacotes BGP dentro do roteador pode ser descrito da seguinte maneira:

Punt

Controlador Ethernet -(pacote)-> encaminhador de caminho de dados -(pacote)-> LPTS -(pacote)-> SPP -(pacote) -> NetIO -(pacote)-> TCP -(mensagem)-> BGP

Injetar

BGP -(mensagem) -> TCP -(pacote) -> NetIO -(pacote) -> SPP -(pacote) -> encaminhador de caminho de dados -(pacote) -> controlador Ethernet

Os KPIs podem ser divididos em:

Fundamentos:

1. Encaminhador de caminho de dados

2. LPTS (configurações de vigilantes de punt de hardware, contadores de aceitação e contadores de queda)

3. SPP

4. NetIO

5. Filas IPC (NetIO <==> TCP <==> BGP)

6. Tamanhos BGP InQ/OutQ

Opcional:

1. utilização de CPU

2. Utilização de memória

3. estatísticas de TCP

4. desempenho do processo BGP

5. convergência de BGP

Monitorar Encaminhador de Caminho de Dados

No XRv9000, o encaminhador de caminho de dados é o DPA (Data Plane Agent), enquanto nas plataformas ASR9000 ele é o NP (Network Processor).

Monitore o DPA (Data Plane Agent) XRv9000

O comando útil para ver a carga e as estatísticas do DPA é:

show controllers dpa statistics global

Esse comando mostra todos os contadores diferentes de zero, que fornecem informações sobre o tipo e o número de pacotes lançados das interfaces de rede para a CPU RP, injetados da CPU RP para as interfaces de rede, e o número de pacotes descartados:

RP/0/RP0/CPU0:xrv9k-01#show controllers dpa statistics global

Index  Debug                                                           Count

----------------------------------------------------------------------------

350  TBPG L2 mailbox events                                              1

Index  Punt                                                            Count

----------------------------------------------------------------------------

1500  CDP                                                             46790

1503  ARP                                                               212

1611  IFIB                                                           595305

1776  LLDP                                                            94037

2001  IPv4 incomplete Tx adjacency                                        2

Index  Inject                                                          Count

----------------------------------------------------------------------------

744  CLNS multicast from fabric pre-route                           321250

749  IPv4 from fabric                                               273993

765  Inject to fabric                                               595245

766  Inject to port                                                 141033

Index  Drop                                                            Count

----------------------------------------------------------------------------

416  Egress UIDB in down state                                           1

474  IPv4 egress UIDB down                                               2

673  Pre-route PIT lookup missed                                         2

Monitore o processador de rede (NP) ASR9000

Comandos úteis para ver a carga e as estatísticas de cada NP no sistema são:

show controllers np load all

show controllers np counters all

NP no ASR9000 tem um rico conjunto de contadores que mostram o número, a taxa e o tipo de pacotes processados e descartados,.

RP/0/RSP0/CPU0:ASR9k-B#show controllers np load all

Node: 0/0/CPU0:

----------------------------------------------------------------

Load                Packet Rate

NP0:  0% utilization             937 pps

NP1:  0% utilization             538 pps

RP/0/RSP0/CPU0:ASR9k-B#

RP/0/RSP0/CPU0:ASR9k-B#show controllers np counters all

Node: 0/0/CPU0:

----------------------------------------------------------------

Show global stats counters for NP0, revision v4

Last clearing of counters for this NP: NEVER

Read 92 non-zero NP counters:

Offset  Counter                                               FrameValue   Rate (pps)

-------------------------------------------------------------------------------------

16  MDF_TX_LC_CPU                                             25475368          10

17  MDF_TX_WIRE                                              681957877         267

21  MDF_TX_FABRIC                                            683500690         267

33  PARSE_FAB_RECEIVE_CNT                                    681767730         267

37  PARSE_INTR_RECEIVE_CNT                                  1323024637         517

41  PARSE_INJ_RECEIVE_CNT                                     13949634           5

45  PARSE_ENET_RECEIVE_CNT                                   677655725         265

49  PARSE_TM_LOOP_RECEIVE_CNT                                 49331192          19

53  PARSE_TOP_LOOP_RECEIVE_CNT                                 1520846           1

109  RSV_DROP_EGR_UIDB_NO_MATCH                                      10           0

146  RSV_DROP_IPV4_RXADJ_DROP                                         1           0

164  RSV_DROP_ING_LAG_NO_MATCH                                        3           0

241  RSV_DROP_MPLS_LEAF_NO_MATCH                                   1312           0

<. . .>

Monitorar LPTS

Como um BGP RR padrão não está no caminho de encaminhamento, todos os pacotes recebidos na interface de rede são apontados para o plano de controle. O elemento de caminho de dados em um BGP RR executa um pequeno número de operações simples antes que os pacotes sejam direcionados para o plano de controle. Como é improvável que o elemento do caminho de dados seja um ponto de congestionamento, o único elemento na placa de linha que precisa de monitoramento são as estatísticas LPTS.

Observe que, no caso de XRv9k, as estatísticas de hardware mapeiam para o vPP

Comando:

show lpts pifib hardware police location <location> | inc "Node|flow_type|BGP"

Exemplo:

RP/0/RP0/CPU0:xrv9k-01#sh lpts pifib hardware police location 0/0/CPU0 | i "Node|flow_type|BGP"

Node 0/0/CPU0:

flow_type     priority sw_police_id hw_policer_addr Cur. Rate  burst static_avgrate avgrate_type AggrAccepts   AggrDrops     TOS Value

BGP-known     high     6            220             50000      1250  2500           Global       16401392      0             01234567

BGP-cfg-peer  medium   7            221             4000       1000  2000           Global       355976        1563          01234567

BGP-default   low      8            222             3000       750   1500           Global       5212380       0             01234567

RP/0/RP0/CPU0:xrv9k-01#

O que procurar:

Se for observado um salto significativo em AggDrops em relação ao tipo de fluxo conhecido por BGP, comece a procurar alterações na topologia da rede que acionaram essa rotatividade maciça no plano de controle.

Caminho de dados de telemetria:

Cisco-IOS-XR-lpts-pre-ifib-oper:lpts-pifib

Note: Os contadores de estatísticas LPTS podem ser apagados. Seu sistema de monitoramento deve levar em conta essa possibilidade.

Monitorar SPP

O SPP é a primeira entidade no processador de rotas ou na CPU da placa de linha que recebe o pacote enviado do NP ou do DPA através da estrutura interna e o último ponto no processamento do pacote de software antes de ser entregue à estrutura para injeção no NP ou no DPA.

Comandos relevantes para a monitoração do SPP:

show spp node-counters

show spp client

O  show spp node-counters  comando mostra a taxa de pacotes puncionados/injetados e é fácil de ler e entender. Para sessões BGP, os contadores relevantes estão sob client/punt  e client/inject  no RP ativo.

O show spp client  é mais rico em saída e fornece uma visão mais detalhada do número de pacotes enfileirados/descartados em relação aos clientes, bem como da marca d'água alta.

RP/0/RP0/CPU0:xrv9k-01#show spp node-counters

0/RP0/CPU0:

socket/rx

Punted packets:          595305

Punt bulk reads:               6

Punt non-bulk reads:          595293

Management packets:        74200158

Management bulk reads:         1775930

Management non-bulk reads:        70031734

-------------------------------

socket/tx

Injected packets:          595245

Management packets:       139939168

-------------------------------

xrv9k/classify

Forwarded to SPP clients:        74795463

-------------------------------

client/inject

Injected from client:       140534413

Non-bulk injects:       140534413

-------------------------------

client/punt

punted to client:        74795371

no client found - send to defa:              92

-------------------------------

0/0/CPU0:

<. . .>

RP/0/RP0/CPU0:xrv9k-01#show spp client

Sat Apr 20 17:11:40.725 UTC

0/RP0/CPU0:

Clients

=======

<. . .>

netio, JID 254 (pid 4591)

----------------------------------------------------------

Reconnect Pending: F, Exited: F, Keep Queues: F, Pakman Client: T

Quota Current: 0, Limit: 16384, Drops 0

Queues:

Key         Cur  Max      Enqueues   High Watermark (Timestamp)        Drops

0xffffffff    0   10             0    0 (22:13:52.195 Feb 21 24 UTC)       0

0x03000006    0 2048             0    0 (22:13:52.196 Feb 21 24 UTC)       0

0x03000007    0 3072        414881    1 (23:03:30.721 Feb 21 24 UTC)       0

0x03000008    0 1024             5    1 (13:41:28.389 Mar 13 24 UTC)       0

0x03000009    0 2048        180411    1 (23:03:31.565 Feb 21 24 UTC)       0

Monitorar NetIO

Enquanto o vigilante LPTS mostra apenas a contagem de pacotes aceitos ou descartados por um vigilante correspondente, no nível NetIO podemos ver a taxa de pacotes apontados para a CPU RP. Como em um BGP RR típico a grande maioria dos pacotes recebidos são pacotes BGP, a taxa NetIO geral indica muito bem a taxa de pacotes BGP recebidos.

Command:

show netio rates

Exemplo:

RP/0/RP0/CPU0:xrv9k-01#show netio rates

Netio packet rate for node 0/RP0/CPU0

-----------------------------------

Current rate       (updated 0 seconds ago):

Input:           7845 pkts/s

Output:         10570 pkts/s

Driver Output:  10598 pkts/s

1 minute rate     (updated 0 seconds ago):

Input:           7825 pkts/s

Output:         10542 pkts/s

Driver Output:  10569 pkts/s

5 minute rate     (updated 0 seconds ago):

Input:           7997 pkts/s

Output:         10677 pkts/s

Driver Output:  10704 pkts/s

RP/0/RP0/CPU0:xrv9k-01#

O que procurar:

- Se for observado um salto significativo na taxa de NetIO, comece a procurar alterações na topologia da rede que tenham disparado essa rotatividade maciça no plano de controle.

Caminho de dados de telemetria:

- não aplicável, pois a telemetria deve transmitir valores do contador, não taxas. O contador de aceitação do vigilante LPTS conhecido por BGP pode ser usado no coletor de telemetria para aproximar a taxa média de pacotes BGP recebidos de pares conhecidos.

Monitorar filas XIPC

No caminho de punt, os pacotes recebidos pelo NetIO do LPTS são passados para o TCP e o BGP. É importante monitorar estas filas:

1. Fila de alta prioridade TCP através da qual o NetIO entrega pacotes ao TCP

2. Fila de controle BGP

3. Fila de dados BGP

No caminho de injeção, os pacotes são criados pelo TCP e passados para o NetIO. É importante monitorar estas filas:

1. Fila XIPC OutputL

Comandos:

show netio clients

show processes bgp | i "Job Id"

show xipcq jid

show xipcq jid

queue-id

Examples:

NetIO para TCP, visão do ponto de vista NetIO:

RP/0/RP0/CPU0:xrv9k-01#show netio clients

<. . .>

Input              Punt         XIPC InputQ      XIPC PuntQ

ClientID         Drop/Total        Drop/Total      Cur/High/Max    Cur/High/Max

<. . .>

tcp               L 0/340774          0/0          L 0/10/12800       0/0/0

H 0/44774091                     H 0/784/12800

TCP para NetIO, visão do ponto de vista NetIO:

RP/0/RP0/CPU0:xrv9k-01#show netio clients

<. . .>

XIPC queues              Dropped/Queued    Cur/High/Max

------------------------------------------------------------

OutputL                  124860/9355257    0/14000/14000

NetIO para TCP, visualização do ponto de vista do processo TCP:

RP/0/RP0/CPU0:xrv9k-01#show processes tcp | i "Job Id"

Job Id: 430

RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 430

Mon Apr 17 16:16:11.315 CEST

Id              Name                   Size   Cur Size   Produced     Dropped     HWM

------ ------------------------------- ------  --------- ----------- ----------- --------

17 XIPC_xipcq_12_0_9854_6506_i...  60000      0    39010269           0       960

16 XIPC_xipcq_12_0_9854_6506_i...  24000      0    31518436           0      1364

15 XIPC_tcp_124                     3200      0           0           0         0

14 XIPC_tcp_125                     9600      0           0           0         0

13 XIPC_tcp_psb_0                  25600      0           0           0         0

10 XIPC_tcp_iq_9                  102400      0     9486010           0       312

12 XIPC_tcp_iq_8                  102400      0     8892274           0       280

9 XIPC_tcp_iq_5                  102400      0     8291392           0       289

11 XIPC_tcp_iq_7                  102400      0     9700123           0       319

8 XIPC_tcp_iq_6                  102400      0     9378703           0       332

7 XIPC_tcp_iq_3                  102400      0     7221706           0       261

6 XIPC_tcp_iq_4                  102400      0     9791070           0       308

4 XIPC_tcp_ctrl_iq_1               4266      0           0           0         0

5 XIPC_tcp_iq_2                  102400      0     9699027           0       295

3 XIPC_tcp_ctrl_iq_0               4266      0      209909           0         9

2 XIPC_tcp_i1                     12800      0    39460564           0       784

1 XIPC_tcp_i0                     12800      0      212540           0        10

TCP para BGP:

RP/0/RP0/CPU0:xrv9k-01#show processes bgp | i "Job Id"

Job Id: 1078

RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078

Mon Apr 17 16:09:33.046 CEST

Id              Name                   Size   Cur Size   Produced     Dropped     HWM

------ ------------------------------- ------  --------- ----------- ----------- --------

2 XIPC_xipcq_12_0_9854_6506_i...  60000      2    35546667           0     15034

1 XIPC_xipcq_12_0_9854_6506_i...  24000      0     1369029           0        50

RP/0/RP0/CPU0:xrv9k-01#

Fila de dados BGP:

RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 1

XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp:

Magic:              12344321

Version:            0

SHM Size:           192392

Owner PID:          9854

Owner JID:          1078

Queue ID:           1

Owner MQ handle:    483

User Context:       0x64

Interrupt Flag:     0

Sent-on-full Flag:  0

Max Queue Size:     24000

Queue Size:         0

Client Queue Size:  24000

High watermark:     50

Last Trigger Sent:  Mon Apr 17 16:11:10.009 CEST

MQ Send Errors:     0

Priority Queues:

Prio       Size      Drops      Total

---------- ---------- ---------- ----------

Unspec      24000          0          0

Normal      24000          0    1396159

Medium      24000          0          0

High      24000          0          0

Crucial      24000          0          0

RP/0/RP0/CPU0:xrv9k-01#

Fila de controle BGP:

RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 2

XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp:

Magic:              12344321

Version:            0

SHM Size:           480392

Owner PID:          9854

Owner JID:          1078

Queue ID:           2

Owner MQ handle:    485

User Context:       0x64

Interrupt Flag:     0

Sent-on-full Flag:  0

Max Queue Size:     60000

Queue Size:         0

Client Queue Size:  60000

High watermark:     15034

Last Trigger Sent:  Mon Apr 17 16:12:49.483 CEST

MQ Send Errors:     0

Priority Queues:

Prio       Size      Drops      Total

---------- ---------- ---------- ----------

Unspec      60000          0          0

Normal      60000          0   37313633

Medium      60000          0          0

High      60000          0          0

Crucial      60000          0          0

RP/0/RP0/CPU0:xrv9k-01#

O que procurar:

- não deve haver quedas nas filas relevantes

- em estatísticas de fila XIPC Marca d'água alta (HWM) não deve exceder 50% do tamanho da fila

Para melhor rastreamento da evolução do valor da marca d'água alta, você deve limpar o valor da marca d'água alta após cada leitura. Observe que isso não limpa apenas o contador HWM, mas também limpa todas as estatísticas da fila. O formato do comando para limpar as estatísticas da fila XIPC é:  clear xipcq statistics queue-name

Como o nome da fila geralmente inclui o ID do processo (PID), o nome da fila é alterado após a reinicialização do processo.

Alguns exemplos de comandos para limpar as estatísticas de filas relevantes:

clear xipcq statistics queue-name XIPC_tcp_i0

clear xipcq statistics queue-name XIPC_tcp_i1

clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp

clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp

Caminho da telemetria:

- Não há caminhos do sensor de telemetria para XIPC.

Monitorar filas de entrada e saída do BGP

O BGP mantém uma fila de entrada e saída para cada peer de BGP. Os dados ficam no InQ quando o TCP os passou para o BGP, mas o BGP ainda não os processou. Os dados ficam na OutQ enquanto o BGP espera no TCP para dividir os dados em pacotes e transmiti-los. O tamanho instantâneo do BGP InQ/OutQ fornece uma boa indicação de quão ocupado o processo BGP está.

Comando:

show bgp <AFI> <SAFI> summary

Exemplo:

RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary

Address Family: VPNv4 Unicast

-----------------------------

BGP router identifier 192.168.0.1, local AS number 65000

BGP generic scan interval 60 secs

BGP table state: Active

Table ID: 0x0

BGP main routing table version 2208096

BGP scan interval 60 secs

BGP is operating in STANDALONE mode.

Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer

Speaker         2208096    2208096    2208096    2208096     2208096     2208096

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd

10.0.0.2          0 65000     180  601022  2208096    0    0 02:56:18        100

10.0.0.3          0 65000     180  601022  2208096    0    0 02:56:18        100

10.0.0.4          0 65000     180  601022  2208096    0    0 02:56:21        100

10.0.0.5          0 65000     180  601022  2208096    0    0 02:56:21        100

10.0.0.6          0 65000     180  601022  2208096    0    0 02:56:18        100

O que procurar:

- O tamanho de InQ/OutQ deve ser zero quando a rede estiver estável. Ele muda rapidamente quando as atualizações são trocadas.

- O tamanho de InQ/OutQ não deve aumentar de forma monótona com o tempo.

Caminho da telemetria:

- Cisco-IOS-XR-ipv4-bgp-oper:bgp

Monitorar taxas de mensagens BGP

Alguns vizinhos BGP podem enviar atualizações ou retiradas continuamente se a topologia de rede estiver instável. O BGP RR deve então replicar essa alteração de tabela de roteamento milhares de vezes para todos os seus clientes RR. Portanto, é importante monitorar as taxas de mensagens recebidas de vizinhos, para rastrear fontes de instabilidade.

Comando:

show bgp <AFI> <SAFI> summary

Exemplo:

RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary

Address Family: VPNv4 Unicast

-----------------------------

BGP router identifier 192.168.0.1, local AS number 65000

BGP generic scan interval 60 secs

BGP table state: Active

Table ID: 0x0

BGP main routing table version 2208096

BGP scan interval 60 secs

BGP is operating in STANDALONE mode.

Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer

Speaker         2208096    2208096    2208096    2208096     2208096     2208096

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd

10.0.0.2          0 65000     180  601022  2208096    0    0 02:56:18        100

10.0.0.3          0 65000     180  601022  2208096    0    0 02:56:18        100

10.0.0.4          0 65000     180  601022  2208096    0    0 02:56:21        100

10.0.0.5          0 65000     180  601022  2208096    0    0 02:56:21        100

10.0.0.6          0 65000     180  601022  2208096    0    0 02:56:18        100

As filas de clientes RR têm aproximadamente a mesma quantidade de MsgSent, mas alguns vizinhos podem ter um número de MsgRcvd maior que outros. Você deve capturar vários instantâneos desse comando para avaliar a taxa de mensagens.

Depois de identificar os peers ofensivos, você pode passar por outros comandos como  show bgp neighbor

detail

and  show bgp neighbor

performance-statistics

ou  show bgp recent-prefixes  para tentar entender quais prefixos estão oscilando e se são sempre os mesmos ou diferentes.

Note: Os contadores MsgRcvd e MsgSent são por vizinho, mas não por família de endereços. Assim, ao executar um comando como  show bgp all all summary , você verá os mesmos contadores por vizinho nas seções para as várias famílias de endereços. Eles não representam o número de mensagens recebidas/enviadas de/para esse vizinho para essa família de endereços, mas entre famílias de endereços.

Monitorar a utilização da CPU

A utilização da CPU deve ser monitorada em todos os roteadores, mas em um roteador com um alto número de núcleos de CPU dedicados ao plano de controle, algumas leituras podem não ser intuitivas. Em um BGP RR com um alto número de núcleos de CPU dedicados ao processador de roteamento (RP), como no caso do dispositivo XRv9k, threads ativos são executados em diferentes núcleos de CPU, enquanto um número de núcleos de CPU permanece ocioso. Como consequência, alguns núcleos de CPU podem estar muito ocupados, mas a utilização geral de CPU calculada em todos os núcleos de CPU permanece moderada.

Portanto, para o monitoramento adequado da utilização dos núcleos da CPU via CLI, use o  show processes cpu thread  comando.

Monitorar estatísticas de TCP

O Cisco IOS® mantém estatísticas detalhadas sobre cada sessão TCP. O comando CLI  show tcp brief  exibe a lista de todas as sessões TCP existentes. Nesta saída de resumo, para cada sessão TCP você pode ver estas informações:

- PCB: identificador exclusivo de sessão TCP.

- VRF-ID: a ID do VRF em que a sessão existe.

- Para ver o nome VRF correspondente, execute este comando:

- show cef vrf all summary | utility egrep "^VRF:|Vrfid" | utility egrep -B1

- Recv-Q: tamanho instantâneo da fila de recebimento. A fila de recebimento contém os pacotes recebidos do NetIO. O processo tcp extrai os dados de um pacote e os envia ao aplicativo correspondente.

- Enviar-Q: tamanho instantâneo da fila de envio. A fila de envio armazena os dados recebidos de um aplicativo. O processo tcp divide os dados em segmentos TCP (ditados pelo tamanho máximo negociado do segmento - TCP MSS), encapsula cada segmento em um cabeçalho da camada 3 da família de endereços correspondente (IPv4 ou IPv6) e envia o pacote para NetIO.

- Endereço local: endereço IPv4 ou IPv6 local associado ao soquete TCP. As sessões TCP no estado LISTEN são normalmente vinculadas a "qualquer" endereço IP, que é representado como "0.0.0.0" ou "::" no caso de IPv4 ou IPv6, respectivamente.

- Endereço Externo: endereço IPv4 ou IPv6 remoto associado ao soquete TCP. As sessões TCP no estado LISTEN são normalmente vinculadas a "qualquer" endereço IP, que é representado como "0.0.0.0" ou "::" no caso de IPv4 ou IPv6, respectivamente.

- Estado: Estado da sessão TCP. Os possíveis estados da sessão TCP são: OUÇA, SINSENT, SYNRCVD, ESTAB, LASTACK, FECHAMENTO, CLOSEWAIT, FINWAIT1, FINWAIT2, TIMEWAIT, FECHADO.

Como o número de porta BGP bem conhecido é 179, você pode limitar as sessões TCP exibidas àquelas que estão associadas à aplicação BGP.

Exemplo:

RP/0/RSP0/CPU0:ASR9k-B#show tcp brief | include "PCB|:179 "

PCB             VRF-ID     Recv-Q Send-Q Local Address          Foreign Address        State

0x00007ff7d403bde0 0x60000000      0      0  :::179                 :::0                   LISTEN

0x00007ff7d403b020 0x60000002      0      0  :::179                 :::0                   LISTEN

0x00007ff7d403d130 0x60000000      0      0  192.168.0.4:50144      192.168.0.5:179        ESTAB

0x00007ff7a4025650 0x60000000      0      0  0.0.0.0:179            0.0.0.0:0              LISTEN

0x00007ff7a4024a50 0x60000002      0      0  0.0.0.0:179            0.0.0.0:0              LISTEN

Você pode usar o valor PCB exibido para obter as estatísticas de uma sessão TCP específica. Comandos CLI que fornecem informações sobre as estatísticas do processo TCP:

Global:

show tcp statistics clients location <active_RP>

show tcp statistics summary location <active_RP>

Por PCB:

show tcp brief | i ":179"

show tcp detail pcb <pcb> location 0/RP0/CPU0

show tcp statistics pcb <pcb> location <active_RP>

Os comandos de estatísticas TCP globais mostram a integridade geral das sessões TCP. Além das estatísticas de pacote de dados (entrada/saída), você pode ver, por exemplo, se há pacotes com erros de checksum, pacotes malformados, pacotes descartados devido a erros de autenticação, pacotes fora de ordem, pacotes com dados após a janela, o que dá uma indicação do comportamento dos pares TCP.

Nos comandos per-PCB, você pode ver parâmetros importantes de uma sessão TCP, como MSS, tempo máximo de ida e volta, etc.

Os contadores relevantes na saída doshow tcp detail pcbcomando são:

- Temporizador de Retrans. Inicia: indica quantas vezes o temporizador de retransmissão foi iniciado.

- Ativações do temporizador de retrans: indica quantas vezes o temporizador de retransmissão se esgotou, disparando uma retransmissão do segmento TCP.

- Tamanho atual da fila de envio em bytes: bytes não confirmados do par.

- Tamanho da fila de recebimento atual em bytes/pacotes: bytes/pacotes ainda a serem lidos pelo aplicativo (BGP).

- bytes mal ordenados: bytes enfileirados na fila de salvamento devido a um buraco na janela de recebimento de TCP.

RP/0/RSP0/CPU0:ASR9k-B#show tcp detail pcb 0x4a4400e4

==============================================================

Connection state is ESTAB, I/O status: 0, socket status: 0

Established at Sat Apr 20 18:26:26 2024

PCB 0x4a4400e4, SO 0x4a42c0ac, TCPCB 0x4a43b708, vrfid 0x60000000,

Pak Prio: Normal, TOS: 64, TTL: 255, Hash index: 402

Local host: 10.10.10.229, Local port: 179 (Local App PID: 856311)

Foreign host: 10.10.10.254, Foreign port: 46980

(Local App PID/instance/SPL_APP_ID: 856311/0/0)

Current send queue size in bytes: 0 (max 16384)

Current receive queue size in bytes: 0 (max 65535)  mis-ordered: 0 bytes

Current receive queue size in packets: 0 (max 60)

Timer          Starts    Wakeups         Next(msec)

Retrans          2795          0                0

SendWnd          1341          0                0

TimeWait            0          0                0

AckHold           274          2                0

KeepAlive         333          1           299983

PmtuAger            0          0                0

GiveUp              0          0                0

Throttle            0          0                0

FirstSyn            0          0                0

iss: 2030796738  snduna: 2034498828  sndnxt: 2034498828

sndmax: 2034498828  sndwnd: 3291        sndcwnd: 4200

irs: 285455091   rcvnxt: 285455710   rcvwnd: 64917   rcvadv: 285520627

SRTT: 162 ms, RTTO: 415 ms, RTV: 253 ms, KRTT: 0 ms

minRTT: 0 ms, maxRTT: 247 ms

ACK hold time: 200 ms, Keepalive time: 300 sec, SYN waittime: 30 sec

Giveup time: 0 ms, Retransmission retries: 0, Retransmit forever: FALSE

Connect retries remaining: 0, connect retry interval: 0 secs

<...>

RP/0/RSP0/CPU0:ASR9k-B#

Monitorar Utilização de Memória

A tabela de rotas BGP é armazenada na memória heap do processo BGP. A tabela de roteamento é armazenada na memória heap do processo RIB.

Comandos úteis para o monitoramento da memória de heap:

show memory summary

show memory summary detail

show memory-top-consumers

show memory heap summary all

Caminho do sensor de telemetria:

Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/detail

A FIB armazena entradas de encaminhamento no espaço de memória compartilhada.

Comandos úteis para o monitoramento de memória compartilhada:

show memory summary

show memory summary detail

show shmwin summary

Monitorar o desempenho do processo BGP

Comando útil que fornece dados internos sobre o desempenho do processo BGP:

show bgp process performance-statistics

show bgp process performance-statistics detail

Monitorar a convergência do BGP

Outro comando útil é aquele que mostra o status geral da convergência de BGP:show bgp convergence

Quando a rede estiver estável, você verá algo como isto:

RP/0/RP0/CPU0:ASR9k-B#show bgp convergence

Mon Dec 18 13:55:47.976 UTC

Converged.

All received routes in RIB, all neighbors updated.

All neighbors have empty write queues.

RP/0/RP0/CPU0:ASR9k-B#