Qualidade de Serviço (QoS) : Marcação de pacotes QoS

Manual de referência para a implementação de criptografia e QoS

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (19 Dezembro 2015) | Feedback


Índice


Introdução

Como os VPNs crescem para incluir tráfego de dados, voz e vídeo, os diferentes tipos de tráfego precisam ser manipulados diferentemente na rede. A qualidade de serviço (QoS) e as características de gerenciamento de largura de banda permitem que um VPN opere em alta qualidade de transmissão para aplicações sensíveis ao tempo, tais como voz e vídeo. Cada pacote é etiquetado para identificar a prioridade e a sensibilidade ao tempo de seu payload e o tráfego é classificado e roteado conforme a sua prioridade de entrega. As soluções de VPN Cisco são compatíveis com uma ampla gama de características de QoS.

Este documento é projetado servir como uma referência única para os usuários que configuram a criptografia e as características de QoS do½ do¿Â do Cisco IOSï na mesmo rede ou conjunto de roteador. Você verá configurações básicas para as políticas de QoS de entrada e de saída na presença de túneis do IP Security (IPSec) e de Generic Routing Encapsulation (GRE). Este documento ajuda a compreender as tarefas de configuração. Igualmente fornece a informação em limitações e em problemas conhecidos, para assegurar o desempenho ótimo e a implementação bem sucedida de serviços do IP aprimorado usando roteadores Cisco.

Pré-requisitos

Requisitos

Os leitores deste documento devem estar cientes destes tópicos:

  • Tecnologia IPSec

Para mais documento exaustivo no IPsec, refira uma introdução à criptografia do protocolo de segurança IP (IPSEC).

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Protocolos IPSec

Uma discussão detalhada dos protocolos IPSec é além do alcance deste documento. Contudo, uma vista geral é fornecida nesta seção. Veja a seção da “informação relacionada” deste documento para uns recursos IPSec mais adicionais.

O IPsec define um modelo da autenticação e da criptografia da camada de rede. Consiste em uma troca da chave de criptografia para construir uma conexão segura, e a autenticação e os protocolos de codificação que os dois pares negociem e usem então durante todo a vida da conexão criptografada.

O Internet Security Association and Key Management Protocol (ISAKMP) negocia a política de criptografia e fornece uma estrutura comum para gerar as chaves compartilhadas por ipsec peer. O resultado das negociações de ISAKMP é uma associação de segurança (SA). Este exemplo de saída do comando show crypto isakmp policy ilustra os parâmetros usados durante a negociação de um SA:

P5R0#show crypto isakmp policy 
Protection suite of priority 100 
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys). 
        hash algorithm:         Secure Hash Standard 
        authentication method:  Pre-Shared Key 
        
!--- Supports pre-shared keys or a public/private 

		
!--- key mechanism such as RSA.
 
        Diffie-Hellman group:   #1 (768 bit) 
        lifetime:               86400 seconds, no volume limit 
        
!--- Lifetime can be based on time or on the  number of transmitted bytes.
 
Default protection suite 
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys). 
        hash algorithm:         Secure Hash Standard 
        authentication method:  Rivest-Shamir-Adleman Signature 
        Diffie-Hellman group:   #1 (768 bit) 
        lifetime:               86400 seconds, no volume limit

As negociações de ISAKMP conduzem a uma conexão criptografada (e ao SA) através de que os pares negociam parâmetros IPSec adicionais. Isso inclui os protocolos reais usados para proteger os datagramas IP. Especificamente, os dois peeres de encripção negociam os parâmetros nesta tabela.

Parâmetro Opções
Grupo do protocolo IPSec
  • Authentication Header (AH)
  • Encapsulating Security Payload (ESP)
Para a maioria de aplicativos, o AH ou o ESP são suficiente.
Modo
  • Modo de túnel – Insira um novo cabeçalho IP de encapsulamento enquanto retém e criptografa o cabeçalho IP original.
  • Modo de transporte - Retém o cabeçalho IP original, mas altera o campo do protocolo para um valor de 51 ou 50 para refletir o cabeçalho AH ou ESP, respectivamente.
Durante a fase de negociação, o ISAKMP automaticamente "recua" para modo de túnel caso o modo de transporte seja desejado, mas não possa ser estabelecido.

Nota:  O RFC 2401leavingcisco.com usa os termos “exteriores” ou “encapsulando” o encabeçamento para descrever o cabeçalho IP novo com modo de túnel e o encabeçamento “interno” para descrever o cabeçalho de IP original. Texto extraído do RFC: “O endereço de origem e o endereço de destino exteriores do cabeçalho IP identificam “os valores-limite” do túnel (o encapsulator e o decapsulator). Os endereços de origem e de destino do cabeçalho IP interno identificam o remetente e o destinatário originais do datagrama (sob a perspectiva desse túnel), respectivamente. Estes termos são utilizados no restante deste documento.

Transform Set
  • AH para a autenticação somente.
  • ESP para a autenticação e a criptografia.

A saída do comando show crypto ipsec sa address ilustra IPsec SA, cada qual é identificado por um Security Parameter Index (SPI). Por exemplo, a conexão identificada com um SPI de 0x21A85375 (564679541) usa o algoritmo do MD5-HMAC para o AH e o DES para ESP.

P5R0#show crypto ipsec sa address 
dest address: 10.1.1.1 

!--- Address of the IPSec peer.
 
   protocol: AH 
      spi: 0x93B90183(2478375299) 
        transform: ah-md5-hmac , 
        in use settings ={Tunnel, } 
        slot: 0, conn id: 2808, flow_id: 405, crypto map: testibm 
        sa timing: remaining key lifetime (k/sec): (4607901/1654) 
        replay detection support: Y 
      spi: 0x21A85375(564679541) 
        transform: ah-md5-hmac , 
        
!--- AH  uses the MD5-HMAC algorithm.
 
        in use settings ={Transport, } 
        slot: 0, conn id: 2812, flow_id: 407, crypto map: testibm 
        sa timing: remaining key lifetime (k/sec): (4607915/1604) 
        replay detection support: Y 

   protocol: ESP 
      spi: 0xDFF0FEC3(3757113027) 
        transform: esp-des , 
        in use settings ={Tunnel, } 
        slot: 0, conn id: 2810, flow_id: 405, crypto map: testibm 
        sa timing: remaining key lifetime (k/sec): (4607901/1654) 
        IV size: 8 bytes 
        replay detection support: Y 
      spi: 0xDB00B862(3674257506) 
        transform: esp-des , 
        
!--- ESP  uses DES.
 
        in use settings ={Transport, } 
        
!--- Transport mode accepted for this flow.
 
        slot: 0, conn id: 2814, flow_id: 407, crypto map: testibm 
        sa timing: remaining key lifetime (k/sec): (4607914/1568) 
        IV size: 8 bytes 
        replay detection support: Y

AH e ESP

Como referido na tabela acima, o AH e o ESP podem ser usados independentemente ou junto. Contudo, porque a maioria de aplicativos somente um é suficiente. Para both of these protocolos, o IPsec não define os algoritmos de segurança específicos para usar-se. Em lugar de, fornece um framework aberto para executar algoritmos padrão do setor.

O AH fornece a integridade sólida e a autenticação para datagramas IP usando os algoritmos de hash SHA ou MD5. Igualmente fornece a não-repudiação. O cabeçalho AH tem pelo 12 bytes e é exemplificado no gráfico abaixo. A IANA (Autoridade responsável pela atribuição de números na Internet) atribuiu o número de protocolo 51 ao AH. Assim, na presença de um cabeçalho AH com os modos de túnel e de transporte, o cabeçalho IP usa o valor 51 no campo protocolo.

Este gráfico mostra o formato de um pacote com um IPSec AH. Com modo de túnel, o valor de byte do Tipo de serviço (ToS) é copiado automaticamente do cabeçalho de IP original ao cabeçalho de túnel. Consulte a seção Classificar pacotes neste documento para obter mais informações.

http://www.cisco.com/c/dam/en/us/support/docs/quality-of-service-qos/qos-packet-marking/18667-crypto-qos-01.gif

O ESP consiste em um cabeçalho não criptografado seguido por dados criptografados e por um reboque cifrado. O ESP fornece a criptografia e a autenticação. Como com AH, o ESP apoia os algoritmos de hash SHA e MD5 para a autenticação. Apoia o DES e o 3DES como protocolos de codificação. O cabeçalho de ESP é pelo menos 8 bytes e é ilustrado neste gráfico. O IANA atribuiu o número de protocolo 50 ao ESP. Assim, na presença (somente) de um cabeçalho de ESP com modo de túnel e modo de transporte, o cabeçalho IP usa um valor dos 50 pés no campo do protocolo.

Este gráfico mostra o formato de um pacote com um cabeçalho IPSec ESP e um reboque. Com o modo túnel, o valor de byte ToS é copiado automaticamente a partir do cabeçalho IP original para o túnel do cabeçalho. Consulte a seção Classificar pacotes neste documento para obter mais informações.

http://www.cisco.com/c/dam/en/us/support/docs/quality-of-service-qos/qos-packet-marking/18667-crypto-qos-02.gif

Utilize túneis GRE com IPSec

O IPsec não apoia o Multicast ou o tráfego não-IP, tal como as trocas de pacote Internetwork IPX (IPA) e o APPLETALK. O fato de que o IPsec não apoia o Multicast significa que não pode levar a informação do protocolo de roteamento que é Multicast como EIGRP (224.0.0.10) e OSPF (224.0.0.5 e 224.0.0.6). O GRE é usado para encapsular o tráfego multicast. Depois, isto pode ser criptografado pelo IPSec, de maneira que o tráfego de Routing Protocol possa fluir por um VPN. Para uma configuração de exemplo do IPsec e do GRE, refira configurar um túnel GRE sobre o IPsec com OSPF.

O encabeçamento do túnel GRE introduz um segundo nível do encapsulamento. Se você não usa somente túneis GRE e nenhum IPsec, refira a Opção Qualidade de Serviço em interfaces do túnel GRE. Esta figura ilustra o pacote encapsulado com cabeçalhos IPSec, GRE e IP original:

http://www.cisco.com/c/dam/en/us/support/docs/quality-of-service-qos/qos-packet-marking/18667-crypto-qos-03.gif

Classifique pacotes

A classificação define o processo de combinar uns ou vários campos na camada 2,3 de um pacote, ou 4 encabeçamentos e então colocação desse pacote em um grupo ou em uma classe de tráfego. Com a ajuda da classificação do pacote, você pode particionar o tráfego de rede em diversos níveis de prioridade ou classes de serviço.

Ao configurar o IPSec com GRE, a abordagem de classificação mais simples é combinar os valores de precedência do IP ou do DSCP. O Cisco IOS Software Release 11.3T introduziu o apoio para o IPsec e junto com ele a característica da preservação de byte de ToS. Com esse recurso, o roteador copia automaticamente o valor do cabeçalho de ToS do pacote de IP original para o cabeçalho de encapsulamento de IP quando é usado IPSec em modo de túnel.

A versão 5.1 e mais recente do Cisco PIX Firewall e a versão 3.5 e mais recente do VPN 3000 series concentrator apoiam o copi do byte ToS. Seção 5.1.2, “construção de cabeçalho para o modo de túnel,” no RFC 2401leavingcisco.com encarrega de copiar os bit ToS IP.

A preservação de bytes de ToS também se aplica a AH. Igualmente note que o ESP no modo de transporte retém o cabeçalho de IP original, e o valor original ToS é transmitido mesmo sem preservação de byte de ToS.

Se os pacotes chegam no roteador sem uma Precedência IP do grupo ou valores DSCP, você pode marcar baseado na classe para observar os cabeçalhos de pacote de informação antes da criptografia ou do encapsulamento. Quando os pacotes alcançam a interface de saída, a política emissora de QoS pode então combinar e atuar nos valores observados.

Quando se configura uma política de QoS com base em precedência de IP, duas políticas são aplicadas.

Tipo de política Ações de política Local da política
Entrada Marque a Precedência IP no cabeçalho de IP original. Interface de ingresso
Saída Oferece garantias mínimas de largura de banda às classes de tráfego diferenciadas pela precedência IP. Interface de saída

Esta tabela mostra uma configuração para uma política de QoS baseada na Precedência IP:

QoS TOS-baseado
Política de entrada
access-list 150 permit tcp any any eq www
access-list 150 permit tcp any eq www any
access-list 151 permit tcp any any eq telnet
access-list 151 permit tcp any eq telnet any 
!
class-map match-any ingress-web
  match access-group 150
class-map match-any ingress-telnet
  match access-group 151
!
policy-map setToS
  class ingress-web
   set ip precedence 1
  class ingress-telnet
   set ip precedence 2
!
interface ethernet 0/0
  service-policy in setToS
Política de saída
class-map match-any egress-web
  match ip precedence 1
class-map match-any egress-telnet
  match ip precedence 2
!
policy-map useToS
  class egress-web
    bandwidth percent 25
  class egress-telnet
    bandwidth percent 15
!
interface serial 1/0
  bandwidth 512
  service-policy out useToS
  crypto-map TEST

Embora não mostrado, você pode igualmente aplicar o Weighted Random Early Detection (WRED) a cada classe como um mecanismo alternativo de queda à queda traseira.

O valor de precedência de IP comentado é transportado pela rede. Sendo assim, certifique-se de implementar políticas consistentes por meio do domínio QoS para evitar classificação e desempenho inesperados.

Alternadamente, você pode querer classificar o tráfego baseado em valores diferentes da Precedência IP ou do DSCP. Por exemplo, você pode querer classificar os pacotes baseados no fluxo IP ou mergulhar a informação 3, tal como o endereço IP de origem e de destino. Para fazer isso, você deve usar o recurso QoS para VPNs. Esta característica é permitida com o comando qos pre-classify e está disponível para o Roteadores VPN Cisco série 7100 e os Cisco 7200 Series Router desde o Cisco IOS Software Release 12.1(5)T e para 2600 e 3600 Series Router desde o Cisco IOS Software Release 12.2(2)T. Refira configurar o QoS for Virtual Private Networks.

O mecanismo de pré-qualificação qos permite que os Cisco routers façam uma cópia do cabeçalho IP interno e executem uma classificação QoS antes da criptografia, com base nos campos do cabeçalho IP interno. Sem esta característica, o Engine de classificação vê um único fluxo somente cifrado e escavado um túnel desde que todos os pacotes que transversal através do mesmo túnel tenha o mesmo cabeçalho de túnel e receba o mesmo tratamento no caso da congestão.

Se sua política de classificação combina com o byte ToS, você não precisa de usar o comando qos pre-classify desde que o valor ToS é copiado ao cabeçalho externo à revelia. Uma política de QoS simples pode ser criada para classificar o tráfego de acordo com as classes baseadas em precedência de IP. Contudo, para diferenciar o tráfego dentro de uma classe e para separá-lo em filas com base no fluxo múltiplas, o comando qos pre-classify é exigido.

Nota: A cópia do byte ToS é feita pelo mecanismo de tunelamento e não pelo comando qos pre-classify.

É possível aplicar o comando qos pre-classify a vários pontos da configuração, conforme ilustrado aqui.

  • GRE somente - Configurar o comando qos pre-classify na interface de túnel.

    interface Tunnel0
      ip address 1.1.1.1 255.255.255.252
      qos pre-classify
      tunnel source 12.2.2.8
      tunnel destination 12.2.2.6
    !
    interface serial 0/0
      ip address 12.2.2.8 255.255.255.0
      fair-queue
  • IPsec somente - Configurar o comando qos pre-classify sob o crypto map.

    crypto map TEST 10 ipsec-isakmp
      set peer 5.5.5.5
      set transform-set SET
      match address Test
      qos pre-classify
    !
    interface serial 0/0
      ip address 5.5.5.4 255.255.255.0
      crypto map TEST
      random-detect
      random-detect flow
  • IPsec e GRE - Configurar o comando qos pre-classify na interface de túnel e sob o crypto map.

    crypto map TEST 10 ipsec-isakmp
      set peer 12.2.2.6
      set transform-set SET
      match address Test
      qos pre-classify
    !
    interface Tunnel0
      ip address 1.1.1.1 255.255.255.252
      qos pre-classify
      tunnel source 12.2.2.8
      tunnel destination 12.2.2.6
      crypto map TEST
    !
    interface serial 0/0
      ip address 12.2.2.8 255.255.255.0
      service-policy out matchPORTnumbers
      crypto map TEST

Termine estas etapas para configurar a pré-classificação de QoS com IPsec e GRE.

  1. Configurar um crypto map e especifique o comando qos pre-classify no modo da configuração de mapa.

    crypto map cryptomap_gre1 10 ipsec-isakmp
    	set peer 172.32.241.9
    	set transform-set transf_GRE1_transport
    	match address 130
    	qos pre-classify
  2. Use o comando show crypto map confirmar sua configuração.

    2621vpn1#show crypto map
    Crypto Map: "cryptomap_gre1" idb: Loopback0 local address: 172.31.247.1
    Crypto Map "cryptomap_gre1" 10 ipsec-isakmp
            Description: Crypto map on GRE1 tunnel mode transport - 10.240.252.0->3/30
            Peer = 172.32.241.9
            Extended IP access list 130
                access-list 130 permit gre host 172.31.247.1 host 172.32.241.9
            Current peer: 172.32.241.9
            Security association lifetime: 4608000 kilobytes/3600 seconds
            PFS (Y/N): N
            Transform sets={ transf_GRE1_transport, }
            QOS pre-classification
  3. Defina uma interface do túnel GRE e aplique os comandos crypto map e qos pre-classify.

    interface Tunnel0
    ip address 10.240.252.1 255.255.255.252
    qos pre-classify
    tunnel source Loopback0
    tunnel destination 172.32.241.9
    crypto map cryptomap_gre1
  4. Use o comando show interface tunnel 0 confirmar que a pré-classificação de QoS está permitida.

    2621vpn1#show interface tunnel 0
    Tunnel0 is up, line protocol is up
      Hardware is Tunnel
      Description: VPN resilience test - 1st GRE tunnel Interface mode transport - 10.240.252.0->3/3
      Internet address is 10.240.252.1/30
      Tunnel source 172.31.247.1 (Loopback0), destination 172.32.241.9
      Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
      Checksumming of packets disabled,  fast tunneling enabled
      Last input 00:00:04, output 00:00:04, output hang never
      Last clearing of "show interface" counters 00:00:51
      Queueing strategy: fifo (QOS pre-classification)
      Output queue 0/0, 0 drops; input queue 0/75, 0 drops

A saída acima ilustra que a interface de túnel continua a utilizar first in, first out (FIFO), conforme a estratégia de enfileiramento, mesmo com a pré-classificação de QoS e o enfileiramento simulado ativados. Isto é ilustrado no show command output (resultado do comando show) com a linha estratégia de fila: fifo (PRE-classificação QoS). o GRE e os túneis de IPsec exigem o enfileiramento de FIFO desde que um dispositivo de destino deixa cair os pacotes de IPsec que chegam fora de serviço.

Em um ambiente VPN, você pode aplicar uma política de serviços de QoS à interface de túnel ou à interface física subjacente. A decisão sobre a necessidade de se configurar o comando qos pre-classify depende de qual cabeçalho e quais valores de cabeçalho serão utilizados para classificação.

  • Se você quer classificar os pacotes baseados no cabeçalho interno, aplique a política à interface de túnel sem o comando qos pre-classify.

  • Se você quer classificar os pacotes baseados no cabeçalho externo, aplique a política à interface física sem o comando qos pre-classify.

  • Se você quer classificar os pacotes baseados no cabeçalho interno e aplicar a política à interface física desde que a interface física pode ser um ponto de congestão, aplique a política a uma interface física e permita o comando qos pre-classify.

Em maio 2002, Cisco recomenda o aplicativo de uma política hierárquica à interface física em um ambiente VPN. Refira a política de tráfego como um exemplo da política de QoS (políticas de tráfego hierárquicas). Nesta configuração, a política de parentes inclui uma classe pelo túnel para classificar ou combinar em todo o tráfego que pertence a esse túnel e usa o comando shape limitar a saída do túnel. A classificação dos fluxos dentro do túnel é aplicada com a ajuda de uma política infantil e pode ser baseada no cabeçalho IP interno com o comando qos pre-classify ou no cabeçalho IP exterior sem o comando qos pre-classify. Assegure-se de que o valor de largura de banda especificada no comando shape de cada um das políticas de parentes para os túneis não faça oversubscribe a taxa da relação.

Estão aqui as etapas a esta configuração.

  1. Crie as classes da política infantil. Por exemplo, escolha combinar no DSCP particular ou nos valores de precedência IP se aqueles valores são ajustados já nos fluxos de tráfego.

    class-map ef 
      match ip dscp ef 
    class-map af 
      match ip dscp af31
  2. Crie o mapa da política infantil. Especifique as classes utilizadas na etapa 1. Aplique ações de QoS nessas classes. Os exemplos de tais ações incluem a especificação das filas de prioridade com o comando priority ou a especificação de uma garantia de largura de banda mínima com o comando bandwidth.

    policy-map QoS 
      class ef 
        priority percent a% 
      class af 
        bandwidth percent b%
  3. Crie as classes da política de parentes. Use o comando access-list para especificar ACLs que classificam todo o tráfego de um túnel específico combinando os endereços da fonte do túnel e do IP de destino. Em seguida, crie um mapa de classes e use o comando match access-group para referenciar o ACL.

    class-map class-tunnel1 
      match access-group 101 
    class-map class-tunnel2 
      match access-group 102 
    class-map class-tunnel3 
      match access-group 103
  4. Crie o mapa da política de parentes. Especifique as classes que você usou em etapa 3. aplica o comando shape a cada classe limitar a saída de todo o tráfego que vem da interface de túnel.

    policy-map main 
      class class-tunnel1 
        shape average x1 bps 
        service-policy QoS 
      class class-tunnel2 
        shape average x2 bps 
        service-policy QoS 
      class class-tunnel3 
        shape average x3 bps 
        service-policy QoS 
      class class-default 
        shape average x4 bps
  5. Aplique o mapa da política de parentes à interface física com a ajuda do comando service-policy.

    interface serial 1/0 
      service-policy out main

Nota: Se seu aplicativo exige a pré-classificação de QoS em um IPsec ou o IPsec com ambiente de GRE, permita o comando qos pre-classify no crypto map. Os critérios de correspondência da classe principal devem ser o mesmo grupo de acesso que é utilizado pelo mapa de criptografia. No exemplo, os critérios de verificação de repetição de dados para class-tunnel1 usam o mesmo grupo de acesso que o crypto map, que você anexa à interface física ou à interface do túnel GRE. Cisco apoia a criptografia com base no software e a criptografia baseada em hardware, igualmente conhecidas como aceleradores de criptografia. Esta tabela lista os aceleradores de hardware de criptografia da Cisco e o suporte para pré-classificação:

Plataforma Hardware de criptografia Suporte à Pré-Classificação QoS
Cisco 1700 Series VPN de velocidade com fio por meio da criptografia de hardware. O Cisco IOS Software Release 12.2T apoia o Low Latency Queuing (LLQ) antes de cripto.
Cisco e Series A série Cisco 2600 suporta um slot AIM (módulo de integração avançado). O Cisco 3660 suporta dois slots AIM.
  • AIM-VPN/BP (desempenho de base)
  • AIM-VPN/EP (desempenho aprimorado)
  • AIM-VPN/MP (desempenho meados de)
  • Desempenho AIM-VPN/High (HP)
Módulo de rede privada virtual de roteador de multiserviço modular do aplicativo do equipamento da premissa do cliente do Cisco 7200 Series Router primeiro para os pacotes do roteador VPN 2600 e 3600 Cisco do Cisco e Series
Disponível, até à data do Cisco IOS Software Release 12.2(2)T.
Cisco e Series O SA-VAM é o módulo de aceleração da VPN. Instala em um slot de adaptador de porta no Cisco ou Series e instala no entalhe do módulo de serviço no Cisco 7100 Series. O Cisco IOS Software Release 12.2T apoia o LLQ antes da característica cripto.
Cisco e Series SA-ISA(=) e SA-ISM(=) são o Adaptador de Serviço Integrado e o Módulo de Serviço Integrado, respectivamente. Disponível no Cisco IOS Software Release 12.2, no 12.2T, no 12.1E, e no 12.0(5)XE.

O comportamento de mudanças de políticas de QoS na presença da criptografia de hardware quando você alterar o trajeto de switching dos pacotes dentro do roteador. Com criptografia de hardware, o CPU reorienta um pacote ao módulo de criptografia antes que esteja enfileirado na interface externa. Portanto, em um ambiente IPSec com GRE e criptografia de hardware, há dois pontos potenciais de congestionamento:

  • Fila de criptografia — Apoios FIFO somente. Quando você usa ou o hardware ou criptografia de software, pacotes sensíveis a retardo, tais como a Voz sobre córregos do Real-Time Transport Protocol (RTP) IP (VoIP), você pode encontrar alguma latência na única fila de FIFO do processo do encapsulamento. Esta latência aumenta enquanto os pacotes sensíveis a retardo chegam quando a fila já guarda uma grande quantidade de tráfego de dados. Para minimizar todo o impacto, selecione um Cisco Router Series com uma aceleração de hardware apropriadamente escalada da arquitetura e do uso. Se a crypto-engine não é congestionada, a seguir não levanta nenhum problema para ter um FIFO para a crypto-engine, a menos que o FIFO for demasiado pequeno absorver a intermitência de tráfego. Se você executa VoIP através da crypto-engine, você pode querer compreender a latência através do motor.

  • Fila de nível de interface — Apoia métodos de enfileiramento especiais. À revelia, uma interface de túnel é uma interface lógica com um parâmetro de largura de banda dos kbps 9. Este parâmetro de largura de banda é usado somente por protocolos de camada superior tais como o EIGRP e o OSPF. Não limita realmente a taxa de emissor ou a largura de banda de interface que o tráfego em túnel pode usar. Portanto, talvez você precise implementar a modelagem baseada em classe na interface de túnel para criar filas de congestionamento "artificial" ou filas de modelagem. O modelagem baseada em classe limita a taxa de emissor e condu-la a um estado congestionado na interface de túnel lógico. A interface de túnel começa a enfileirar os pacotes em excesso que são mantidos pelo modelador, e sua política de enfileiramento complexa se aplica aos pacotes em excesso.

O enfileiramento de FIFO dos apoios de crypto-engine do hardware somente. Portanto, se você aplicar uma política de serviço com LLQ na interface física de saída pela qual o tráfego de túnel é transmitido, verifique se o desempenho do processamento de IPSec é superior ao da interface de saída. Isso permite que o mecanismo de enfileiramento de prioridade da interface esteja operante e impede que o mecanismo crypto se torne um gargalo FIFO.

No Cisco IOS Software Release 12.1, a classificação comum foi introduzida para assegurar-se de que os pacotes combinassem a uma única classe em um mapa de política (refira o ordem de operação de Qualidade de Serviço para mais informação). Em um ambiente VPN, um resultado deste realce é que a classificação de fluxos de tráfego criptografado dentro de um túnel de IPsec falha, mesmo quando uma política de serviços especifica a harmonização na Precedência IP ou os valores DSCP no cabeçalho de túnel. Este problema foi solucionado no Cisco IOS Software Release 12.2(10) nos IDs de bug CSCdw90486 (somente para clientes registrados) e CSCdx08427 (somente para clientes registrados) da Cisco. Nos Cisco IOS Software Release que incluem as mudanças executaram devido a estes introduzem erros de funcionamento, o comportamento de classificação com criptografia de hardware e de software são agora consistentes.

Esta tabela descreve o comportamento de características MQC com e sem a pré-classificação de QoS após o reparo. Para as Plataformas que não apoiam pré-classificação nem não têm permitida pré-classificação, o comportamento de MQC no “nenhum preclassify” a coluna é esperado. Esta tabela utiliza novamente as mesmas definições usadas em todo este documento para cabeçalho interno e externo.

Pré-classificar Nenhum Preclassify
Aceleradores de criptografia de hardware e CEF
classificação comum interna externa
comandos configure e police interna externa
enfileiramento interna externa
WFQ baseado em fluxo interna externa
Aceleradores de criptografia de hardware e comutação do processo
classificação comum interna externa
comandos configure e police interno (1) externa
enfileiramento interna externa
WFQ baseado em fluxo interna externa
Criptografia de Software e CEF
classificação comum interna externa
comandos configure e police interna externa
enfileiramento interna externa
WFQ baseado em fluxo interna externa
Criptografia de software e switching de processo
classificação comum interna externa
comandos configure e police interno (1) externa
enfileiramento interna externa
WFQ baseado em fluxo interna externa

Nota: Embora os comandos set and police atuem em uma classe preclassified, a marcação do pacote ocorre somente no cabeçalho externo.

Configuração de exemplo

Esta configuração de exemplo ilustra os comandos para criar políticas de serviço de QoS para um IPSec com ambiente GRE.

  • Um túnel GRE conecta os ipsec peer, e os pacotes em túnel são cifrados com a ajuda do IPsec.

  • Crie uma política de entrada que aplique o Class-based Marking para ajustar a Precedência IP.

  • Crie uma política emissora que limite cada túnel criptografado a uma largura de banda máxima usando o modelagem baseada em classe e igualmente aplique garantias de largura de banda mínima através do Class-Based Weighted Fair Queuing (CBWFQ).

Política de entrada

Termine estas etapas para criar uma política de entrada que aplique o Class-based Marking.

  1. Permita o CEF com o comando ip cef. O CEF é exigido para o Class-based Marking. Refira quando é o CEF exigido para Qualidade de Serviço? para obter mais informações.

  2. Defina os critérios em que para classificar o tráfego em classes. Esta configuração define a classe "flow-hi" (fluxo alto) para o tráfego Telnet e a classe "flow-low" (fluxo baixo) para o tráfego ICMP.

  3. Defina um mapa de política e defina ações QoS às classes definidas.

  4. Aplique sua política à relação. Neste caso, é a subinterface serial.

Esta tabela mostra uma configuração para uma política de entrada do Class-based Marking.

Política de entrada do Class-based Marking
ip cef 

! 
class-map match-any flow-low 
 match protocol icmp  
! 
class-map match-any flow-hi 
  match protocol telnet 

! 
policy-map qos-in 
 class flow-hi  
  set ip precedence 4 
! 
class flow-low 
  set ip precedence 2 
! 
int s0/0.1 
 service-policy input qos-in 

  
router#show policy-map interface s0/0.1 

Serial0/0.1  

Service-policy input: qos-in) 

!--- Apply input policy named "qos-in."
 

     Class-map: flow-hi (match-any) 
      447 packets, 227851 bytes 
      30 second offered rate 5000 bps, drop rate 0 bps  

!--- Input rate for class named "flow-hi."
 

      Match: protocol telnet 
        447 packets, 227851 bytes 
        30 second rate 5000 bps 

!--- Input rate for class named "flow-hi."
 
      QoS Set 
        ip precedence 4 
          Packets marked 447  

!--- Number of packets marked.
  

   Class-map: flow-low (match-any 
      237 packets, 337898 bytes 
      30 second offered rate 21000 bps, drop rate 0 bps 
      Match: protocol icmp 
        237 packets, 337898 bytes 
        30 second rate 21000 bps 
      QoS Set 
        ip precedence 2 
          Packets marked 237  

    Class-map: class-default (match-any) 

!--- The default class is automatically defined.
 
      1 packets, 48 bytes 
      30 second offered rate 0 bps, drop rate 0 bps 
      Match: any

Política de saída

Esta configuração cria uma política de saída hierárquica, também conhecida como política aninhada. Consulte a seção Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example [&Exemplo de política de tráfego como uma política de QoS (políticas de tráfego hierárquicas)] para obter mais informações. A política "pai" aplica a modelagem baseada em classe para limitar a taxa de saída total da interface de túnel e a política "filho" aplica garantias mínimas de largura de banda, usando o CBWFQ para o excesso colocado em fila.

Estas são as etapas para esta configuração.

  1. Crie a política infantil.

    • Essa configuração define a classe "ipsec-hi" para o tráfego de Telnet remarcado e a classe "ipsec-low" para o tráfego de ICPM remarcado.

    • Esta configuração usa o mapa de política “IPsec-fluxo” para aplicar o CBWFQ ao telnet e ao tráfego ICMP usando o comando bandwidth.

  2. Crie a política de parentes. Essa configuração define a classe "ipsec" e molda o tráfego correspondente a 16 kbps.

  3. Aplique a política infantil dentro da política de parentes. Esta configuração aplica a política infantil "ipsec-flow" como uma ação de QoS dentro da política pai "qos-out". A ação de QoS é CBWFQ para os pacotes retidos e enfileirados pelo shaper.

  4. Aplique a política de parentes à relação. Neste caso, é a subinterface serial.

Esta tabela mostra uma configuração para que uma política emissora dê forma e aplique ao CBWFQ, com base nos valores observados.

Modelagem e Política de Saída de CBWFQ
class-map match-all ipsec-hi 
  match ip precedence 4  
class-map match-all ipsec-low 
  match ip precedence 2  
! 
policy-map ipsec-flow  
  class ipsec-hi 
   bandwidth 8  
  class ipsec-low 
   bandwidth 8 
! 
class-map match-all ipsec  
 match protocol gre 
!  
policy-map qos-out 
 class ipsec 
  shape average 16000 
   service-policy ipsec-flow 
! 
int fa0/0 
 service-policy output qos-out

!--- Apply the policy to the physical interface through
 

!--- which the tunnel traffic is transmitted.
 
router#show policy-map interface fast 0/0 
 FastEthernet0/0  

  Service-policy output: qos-out  

!--- "Parent" policy named "qos-out."
 

    Class-map: ipsec (match-all)  
      1422 packets, 1390125 bytes 
      30 second offered rate 38000 bps, drop rate 0 bps  

!--- Egress rate before shaping.


      Match: protocol gre  
      Traffic Shaping 

      Target  Byte   Sustain   Excess    Interval  Increment Adapt 
      Rate    Limit  bits/int  bits/int  (ms)      (bytes)   Active 
      16000   2000   8000      8000      500       1000      - 
  

      Queue  Packets   Bytes   Packets  Bytes     Shaping 
      Depth                     Delayed  Delayed   Active 
        69     641      611106  582      535364    yes  

  Service-policy : ipsec-flow  

!--- "Child" policy named "ipsec-flow." 


        Class-map: ipsec-hi (match-all)  
          788 packets, 464485 bytes 
          30 second offered rate 15000 bps, drop rate 0 bps 
          Match: ip precedence 4  
          Weighted Fair Queueing 
            Output Queue: Conversation 25  
            Bandwidth 8 (kbps) Max Threshold 64 (packets) 
            (pkts matched/bytes matched) 389/241922 
            (depth/total drops/no-buffer drops) 4/0/0 

        Class-map: ipsec-low (match-all)  
          634 packets, 925640 bytes 
          30 second offered rate 25000 bps, drop rate 0 bps 
          Match: ip precedence 2  
          Weighted Fair Queueing 
            Output Queue: Conversation 26  
            Bandwidth 8 (kbps) Max Threshold 64 (packets) 
            (pkts matched/bytes matched) 270/400140 
            (depth/total drops/no-buffer drops) 64/2/0 

        Class-map: class-default (match-any)  
          0 packets, 0 bytes 
          30 second offered rate 0 bps, drop rate 0 bps 
          Match: any  

       Class-map: class-default (match-any)  
         115 packets, 14827 bytes 
         30 second offered rate 0 bps, drop rate 0 bps 
         Match: any

Nota:  A política principal usa o comando match protocol gre command para especificar a combinação no valor do protocolo atribuído ao GRE no cabeçalho IP. Baseado na ordem da execução das características do Cisco IOS, os ACL e as características de QoS veem pacotes não criptografado. Assim, a configuração dos ACL que combinam no valor de protocolo AH ou ESP (51 e 50 pés, respectivamente) não trabalha (Bug da Cisco ID CSCdu63385 (clientes registrados somente) e CSCdv20737 (clientes registrados somente)). Essa restrição aplica-se à criptografia de hardware e software. Em casos raros, QoS apresenta pacote classificado baseados no cabeçalho IP alterado dos pacotes criptografado em um roteador configurado para o CEF switching. A razão é que os pacotes CEF realmente estavam sendo processo comutado quando o código e o CEF criptos errada não poderiam encontrar uma adjacência do CEF válido.

Nota: Se você usa o comando match protocol em um mapa da classe combinar em protocolos não-IP, tais como o IPX e o APPLETALK, e igualmente permite qos PRE-classifica para combinar em valores no cabeçalho interno, a classificação baseada no cabeçalho interno não trabalha.

Restrições e problemas relacionados

Esta seção discute os problemas conhecidos e as ações alternativas relativos ao aplicativo de cripto e de QoS no mesmo roteador.

QoS e proteção contra ataque de replay

Alguns grupos de transformação criptográfica oferecem proteção contra replay, que funciona quando um número de seqüência é aplicado ao cabeçalho de criptografia. Em uma interface congestionada com o fancy queuing, um pacote de prioridade baixa pode ser atrasado em uma fila e então chegar no roteador que decifra depois que a janela anti-resposta foi excedida. Neste caso, o dispositivo que recebe deixará cair o pacote. Além, se um pacote criptografado chega no destino fora da sequência por um determinado indicador (ajustado atualmente a 64 pacotes), o pacote é deixado cair. Cisco está atualmente na procura de métodos para superar estas limitações. Note que a proteção anti-replay não pode ser desabilitada destes transforma em qual é executada.

  • esp-sha-hmac

  • esp-md5-hmac

  • ah-md5-hmac

  • Ah-sha-hmac

Use o comando show crypto ipsec sa determinar se o apoio da anti-repetição está permitido para cada IPsec SA.

2611-ch5#show crypto ipsec sa
interface: Tunnel0
Crypto map tag: Test, local addr. 12.2.2.6
inbound esp sas:
spi: 0xDE92271(233382513)
transform: esp-des esp-sha-hmac ,
in use settings ={Transport, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: Test
sa timing: remaining key lifetime (k/sec): (4607996/99)
IV size: 8 bytes 
replay detection support: Y

NBAR

O NBAR não é configurável nas interfaces lógica onde a escavação de um túnel ou a criptografia são usadas. Não é apoiado igualmente em nenhuma interface física configurada com um crypto map. Por isso, não é possível usar o NBAR para classificar o tráfego com base em informações de pacote de camada mais elevada, como um URL ou nome de host de servidor de Web, para qualquer política de QoS onde GRE e/ou IPSec estejam sendo usados. Esta restrição resulta do número de bytes do cabeçalho de pacotes que o recurso de pré-classificação salva e faz referência. Especificamente, a pré-classificação de QoS chama um API nos IO antes que um pacote esteja encapsulado. Essa API obtém uma cópia das informações do cabeçalho do pacote original. Quando o pacote bate eventualmente a função de QoS da saída, QoS pode ser aplicado ao pacote baseado em alguma da informação salvar tal como a porta TCP ou o endereço IP de destino real.

Contabilidade dupla

Os contadores de classificação na saída do comando show policy-map interface podem exibir duas vezes o número de pacotes de túnel conhecidos criptografados em uma configuração com CEF, GRE e IPSec. Este exemplo ilustra essa condição.

router#show policy-map interface fa0/0 
  FastEthernet0/0 

   Service-policy output: qos-out 

     Class-map: ipsec (match-all) 
       44 packets, 8580 bytes 
       30 second offered rate 1000 bps, drop rate 0 bps 
       Match: protocol gre 
       Traffic Shaping 
         Target    Byte   Sustain   Excess    Interval  Increment Adapt 
         Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active 
         16000     2000   8000      8000      500       1000      - 

         Queue     Packets   Bytes     Packets   Bytes     Shaping 
         Depth                         Delayed   Delayed   Active 
         0         22        4796      0         0         no 

Essa condição resulta da classificação do pacote de saída, que ocorre no caminho de switching do CEF e novamente quando o processo de criptografia retira o pacote da fila. Este problema é resolvido nos estes o Bug da Cisco ID.

Além, quando os túneis GRE e o IPsec são configurados, um pacote é executado duas vezes com o processo de consulta CEF, uma vez após o encapsulamento de GRE e uma vez após o encapsulamento de IPSec. Como o pacote é transmitido somente após o encapsulamento do IPSec, ocorre falha no balanceamento de carga de CEF por pacote, de modo que os pacotes usam sempre a mesma interface.

Criptografia de software e Switching rápida/CEF

Quando usar criptografia de software, recurso pré-classificado QoS e CBWFQ, os pacotes comutados rápidos podem não estar classificados adequadamente. Este problema é considerado na saída do comando show policy-map interface:

3640-ch1#show policy-map interface 
 {snip} 
      Class-map: precedence (match-all) 
        5 packets, 520 bytes 
        
!--- Five packets matched the class.
 
        30 second offered rate 0 bps, drop rate 25000 bps 
        Match: ip precedence 5 
        Weighted Fair Queueing 
          Output Queue: Conversation 26 
          Bandwidth 10 (%) 
          Bandwidth 1 (kbps) Max Threshold 64 (packets) 
          (pkts matched/bytes matched) 11756/14350192 
          
!--- Many packets actually are  queued.
 
          (depth/total drops/no-buffer drops) 63/6359/0 

Como uma ação alternativa, use um módulo de criptografia de hardware, force o processo que comuta com o comando no ip route-cache cef, ou desabilite a pré-classificação de QoS. Isso faz o sistema de enfileiramento moderado ver um único fluxo criptografado na classe de padrão classe.

Esse problema é resolvido no bug Cisco ID CSCdw28771 (apenas clientes registrados).

Legado de filas de prioridade e pré-classificação de QoS

Os recursos de enfileiramento de prioridade legado de Cisco, que usam os comandos priority-list and priority-group, e a característica da pré-classificação de QoS não são apoiados junto. Em lugar de, implementar LLQ configurando um mapa de política com o comando priority do MQC.

Criptografia de hardware e QoS

Estas são questões solucionadas com criptografia de hardware e QoS.

  • Identificação de bug Cisco CSCdv25358 (clientes registrados somente) - Quando você usa o comando rate-limit executar o Policiamento de tráfego através da característica do Committed Access Rate (CAR) do legado Cisco, o comando qos pre-classify não trabalha quando a criptografia de hardware é usada igualmente. Essa combinação de recursos impede a criptografia. Como uma ação alternativa, class-based policing do implementar com a ajuda do comando police em um mapa de política configurado com a interface de linha do comando modular qos (CLI) (MQC). Os demais recursos de QoS (MQC ou não-MQC) não são afetados.

  • Identificação de bug Cisco CSCdw29595 (clientes registrados somente) - O desempenho do caminho de criptografia degrada quando o Cisco IOS Software Release 12.2(6.8) é usado com uma placa de criptografia do hardware. A perda em desempenho ocorre porque pacotes criptografados são comutados por processo em vez de serem comutados rapidamente. Esta condição ocorre quando o IPSec é aplicado às interfaces enquanto a placa de criptografia de hardware é usada. Não há solução.

  • Identificação de bug Cisco CSCdw30566 (clientes registrados somente) - Em um IPsec com ambiente de GRE, se você permite o CEF, conduz ao desempenho de encaminhamento reduzido desde que os pacotes são realmente comutados por processo. Esta circunstância resulta de como pacotes processados CEF depois que GRE-foram encapsulados. Como uma ação alternativa, desabilite o CEF, e permita que os pacotes sejam fast-switched.

Quando você usa aceleradores de criptografia, veja a seção dos pacotes da classificação deste documento e o exame das mudanças executadas no Bug da Cisco ID CSCdw90486 (clientes registrados somente) e CSCdx08427 (clientes registrados somente).


Informações Relacionadas


Document ID: 18667