correspondências padrão de classe controlam o tráfego?

16

Estou vendo um problema com o BFD em um link que está sendo policiado egresso, onde aparece durante os períodos em que o vigilante é atingido no máximo. Os pacotes BFD não estão chegando ao outro lado. Eu estou querendo saber se os hellos do BFD estão sujeitos ao vigilante ou se caem fora dele. Se eles estão sujeitos a um policial, é tão simples quanto adicionar uma correspondência ao DSCP CS6 e dar prioridade a ele? Abaixo está a configuração:

interface GigabitEthernet1/1
 service-policy output 500meg
end

Router-1#sh policy-map 500meg
  Policy Map 500meg
    Class class-default
     police cir 500000000 bc 31250000 be 31250000
       conform-action transmit
       exceed-action drop
       violate-action drop

— Lama
fonte

1

Qual modelo da Cisco você está usando?

— quer

@MikePennington 7606 w / WS-X6724-SFP

— Mud

3

Sua lógica está correta (para esta plataforma, não para todas as plataformas). Eu daria apenas capacidade dedicada ao CS6, se eu garantisse o que está no CS6 e o que não está. Se eu não garantir isso, você prefere usar o ACL para corresponder especificamente ao BFD. Dito isto, o 7600 não é uma plataforma muito boa para temporizadores agressivos de BFD. Eu evitaria mais agressivo que o intervalo de 1s, 3 multiplicador.

— ytti 6/09/13

Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.

— Ron Maupin

2

@Mud, você tem a resposta da sua pergunta espalhada por vários comentários, então estou apenas consolidando-a aqui em uma única resposta.

Nos 7600s / 6500s, você pode filtrar o BFD (tráfego do plano de controle) no nível da interface, como qualquer outro tráfego (tráfego de trânsito que passa pelo dispositivo).

Quando você aplica uma ACL a uma porta na placa de linha, ela é aplicada a todo o tráfego nessa interface. O tráfego que precisa ser processado pelo RSP ou DFCs, se você estiver usando, precisa ser direcionado para lá, que é após o processamento da ACL.

Como regra geral, incluí recentemente o tráfego do plano de controle nas políticas de QoS, como as seguintes em que "classe NC" corresponde apenas ao CS6 e CS7:

policy-map QoS-Example
 class NC
  bandwidth percent 2
 !
 class REALTIME
  police rate percent 10
   conform-action transmit
   exceed-action drop
  !
  priority level 1
 !
 class 1
  bandwidth percent 22
 !
 class 2
  bandwidth percent 24
 !
 class 3
  bandwidth percent 12
 ....... and so on

Se você escrever uma política CoPP para os seus 7600s / 6500s, precisará escrever ACLs que correspondam a todos os tipos relevantes de tráfego do plano de controle. Portanto, você também pode corresponder o tráfego BFD, correspondendo o tráfego de / para a porta UDP 3784 (e bloqueie-o ainda mais para o IP da interface, se possível).

Como o @ytti disse, você precisa ter cuidado com os cronômetros BFD em sua configuração, se você não tiver DFCs, seu BFD em execução na energia RSP / CPU. Nesse caso, você também pode querer ajustar o comando global "process-max-time" e o agendamento do processo "planejador alocar xxx xxx".

O mínimo recomendado pela Cisco é que, bfd interval 100 min_rx 100 multiplier 3em algumas caixas de produção sem DFCs, estou executando o bfd interval 500 min_rx 500 multiplier 3que está bom, acho que nas caixas com DFCs às quais não tenho acesso no momento, estou executando o mesmo.

Você pode ver essas referências para obter mais informações, que abrangem o ajuste BFD e as ACLs para o tráfego do plano de controle (CoPP e ACLs de interface) e também alguns ajustes do plano de controle que geralmente são boas práticas, além do comportamento de QoS com o tráfego do plano de controle:

http://www.cisco.com/c/en/us/td/docs/routers/7600/troubleshoot/guide/7600_Trouble_Shooting.pdf

http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/12-2SR/configuration/guide/swcg/dos.html

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html

— jwbensley
fonte

1

Devido à natureza crítica do pacote de controle BFD, ele não passa pelo mapa de políticas de QoS de saída na saída e é colocado diretamente na fila de saída. Confirmado com TAC.

— Subeh
fonte

-1

De acordo com este documento da Cisco "Os usuários não podem, por exemplo, filtrar ou aplicar a Qualidade de Serviço (QoS) ao pacote BFD transmitido". Então, suponho que esses pacotes recebam o sinalizador PAK_PRIORITY .

— Marco Marzetti
fonte

2

PAK_PRIORITY é usado para encaminhamento acelerado dentro do roteador / chassi. Não é uma marcação externa. O BFD é um plano de dados e precisa ser marcado / enfileirado manualmente para oferecer um melhor tratamento.

— Daniel Dib #

@Daniel está certo. Esqueci de mencionar que PAK_PRIORITY é um sinalizador interno e seu comportamento depende do sistema. No C7600, esses pacotes sinalizados são marcados automaticamente com CoS6 e protegidos por qualquer tipo de queda de QoS. Portanto, mesmo se você puder apostar que os pacotes serão entregues, se você quiser um comportamento de encaminhamento acelerado, defina uma fila dedicada.

— Marco Marzetti

@MarcoMarzetti Então, para meu próprio esclarecimento: o documento da Cisco está se referindo aos pacotes BFD de entrada que não podem ser QoS e ainda estão sujeitos a um policial de saída?

— Mud

@Mud PAK_PRIORITY é uma coisa interna (ou seja, não está marcada). "O software Cisco IOS também possui um mecanismo interno para conceder prioridade interna a datagramas de controle importantes à medida que são processados no roteador. Esse mecanismo é chamado PAK_PRIORITY".

— Ryan Foley