Asynchronous Transfer Mode (ATM) : Classe de serviço IP à ATM

Quais bytes são contados pelo IP para enfileiramento de ATM CoS?

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento fornece a informação para ajudá-lo a determinar que bytes são contados pelo IP ao enfileiramento do Asynchronous Transfer Mode (ATM).

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

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

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Determine o valor para a instrução de largura de banda em uma política de serviços de QoS

P.. Eu preciso de determinar o valor para a instrução de largura de banda em minha política de serviços de QoS. Em Circuitos virtuais permanentes (PVCs) de ATM, como esse valor é medido? Conta os 53 bytes inteiros das células ATM?

R. Os comandos bandwidth and priority configurados em uma política de serviços para permitir o Class-Based Weighted Fair Queueing (CBWFQ) e o low latency queueing (LLQ), respectivamente, usam um valor dos kbps que conte os mesmos bytes de carga adicionais contados pela saída do comando show interface. Especificamente, o sistema de enfileiramento da camada 3 conta estes:

Campo de carga adicional Duração Contado em show policy-map interface
Logical Link Control / Subnetwork Access Protocol (LLC/SNAP) 8 (por pacote) Sim
Trailer AAL5 (ATM Adaptation Layer 5) 4 Não O reboque AAL5 e a verificação de redundância cíclica (CRC) são adicionados no Segmentation And Reassembly (SAR), e daqui nunca explicados nos IO. Os 4 bytes que é contado são bytes de encapsulamento internos do virtual circuit (VC).
Preenchendo para tornar a última célula um múltiplo par de 48 bytes. Variável Não
Cabeçalhos de célula ATM 5 (por célula) Não

Esta seção mostra-lhe como usar os contadores no comando show policy-map interface output a fim determinar que bytes de carga adicionais são contados pelo sistema de enfileiramento da camada 3.

Tradicionalmente, os dispositivos Cisco usam estas definições de bytes AAL5PDU e de bytes da célula ATM:

  • ATM_cell_byte = roundup(aal5_pdu/48)*53

  • aal5_pdu_byte = ip_size + snap(8)+aal5_ovh(8) = ether_size - 2

Neste teste, os pacotes dos 50 pés (pps) da virulência IP 60-byte ao PVC 0/3 são transmitidos por segundo, que é configurado para o encapsulamento AAL5SNAP:

r1#show policy-map interface 
   ATM5/0.33: VC 0/33 - 
    Service-policy output: llq (1265) 

      Class-map: p5 (match-all) (1267/4) 
        14349 packets, 1033128 bytes 
        30 second offered rate 28000 bps, drop rate 0 bps 
        Match: ip precedence 5  (1271) 
        Weighted Fair Queueing 
          Strict Priority 
          Output Queue: Conversation 136 
          Bandwidth 40 (kbps) Burst 1000 (Bytes) 
          (pkts matched/bytes matched) 0/0 
          (total drops/bytes drops) 0/0

1033128 bytes / 14349 pacotes = 72 bytes por pacote

8 (cabeçalho SNAP) + 60 IP paylod + 4 (4 primeiros bytes do trailer AAL5) = 72

Após o teste, o comando show policy-map int exibe 14349 pacotes e 1033128 bytes. Esses valores contam o número de pacotes que correspondem aos critérios da classe. O pkts matched/bytes combinados avalia incrementos somente quando o VC é congestionado ou quando o pacote é comutado por processo. Todos os pacotes comutados por processamento são enviados ao motor de enfileiramento da camada 3.

Confirme que o comando show interface atm conta os mesmos bytes de carga adicionais. Neste teste, cinco sibilos de 100 bytes são enviados:

7500-1#ping 192.168.66.70 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 192.168.66.70, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms 
7500-1#

A saída do comando show interface atm exibe cinco pacotes de entrada e 540 bytes. O acréscimo 40 bytes acima dos 500 bytes da virulência IP vem deste:

  • 40 bytes/5 pacotes = 8 bytes de overhead por pacote

  • 8 bytes do encabeçamento LLC/SNAP

7500-b#show interface atm 4/1/0 
ATM4/1/0 is up, line protocol is up 
  Hardware is cyBus ATM 
  Internet address is 192.168.66.70/30 
  MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 80 usec, 
  rely 255/255, load 1/255 
  NSAP address: BC.CDEF01234567890ABCDEF012.345678901334.13 
  Encapsulation ATM, loopback not set, keepalive not supported 
  Encapsulation(s): AAL5, PVC mode 
  2048 maximum active VCs, 1024 VCs per VP, 1 current VCCs 
  VC idle disconnect time: 300 seconds 
  Last input 00:00:03, output 00:00:03, output hang never 
  Last clearing of "show interface" counters 00:00:21 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 1 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     5 packets input, 560 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     5 packets output, 560 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 0 output buffers swapped out

Este é um teste feito sobre uma interface Ethernet, que envie 100 pacotes de 74 bytes:

louve(TGN:OFF,Et3/0:2/2)#show pack 
Ethernet Packet:  74 bytes 
      Dest Addr: 0050.73d1.6938,   Source Addr: 0010.2feb.b854 
      Protocol: 0x0800 

IP    Version: 0x4,  HdrLen: 0x5,  TOS: 0x00 
      Length: 60,   ID: 0x0000,   Flags-Offset: 0x0000 
      TTL: 60,   Protocol: 1 (ICMP),   Checksum: 0x74B8 (OK) 
      Source: 0.0.0.0,     Dest: 5.5.5.5 

ICMP  Type: 0,   Code: 0  (Echo Reply) 
      Checksum: 0x0EFF (OK) 
      Identifier: 0000,  Sequence: 0000 
Echo Data: 
    0 : 0001 0203 0405 0607 0809 0A0B 0C0D 0E0F 1011 1213  .................... 
   20 : 1415 1617 1819 1A1B 1C1D 1E1F                      ............

Ambos os comandos show policy-map interface e show interface ethernet contaram 740 bytes.

few#show policy-map interface ethernet 2/2 
 Ethernet2/2 
  Service-policy output: a-test 

    Class-map: icmp (match-all) 
      10 packets, 740 bytes 

few#show interface ethernet 2/2 
     10 packets output, 740 bytes, 0 underruns(0/0/0)

Virulência IP 60 + 2 * 6 (endereço MAC de origem e de destino) + 2 (tipo de protocolo) = 74

Deste cálculo, você pode ver que o Ethernet CRC não está incluído nas saídas da relação ou do comando show policy-map da mostra. Importante, ambos os valores são consistentes dentro mesmo se o CRC é incluído.

Finalmente, estão aqui os bytes contados em uma interface serial que use o encapsulamento de Controle de Link de Dados de Alto Nível (HDLC). Neste teste, cinco pacotes de 100 bytes são transmitidos:

r3#show policy interface 
  Serial4/2:0 
    Service-policy output: test 

      Class-map: icmp (match-all) 
        5 packets, 520 bytes

Estão aqui as definições de quadros de Cisco HDLC:

/image/gif/paws/10420/bytes_counted.gif

  • bandeira — comece ou fim do quadro = do 0x7E

  • endereço — campo do tipo de frame:

    • 0x0F — Frame de unicast

    • 0x80 — Frame de transmissão

    • 0x40 — Quadro acolchoado

    • 0x20 — Quadro comprimido

  • protocolo — Tipo de Ethernet dos dados encapsulados, tais como 0x0800 para o IP

A saída do comando show policy interface para o teste de série indica 520 bytes. Os quatro bytes adicionais pelo quadro não incluem os indicadores de frame do começo e do término. Em lugar de, os bytes incluem os campos do endereço, do controle e do protocolo. Importante, os bytes não incluem a sequência de verificação de frame (FCS).

Conclusão

É importante compreender que há uma diferença no número de octetos contados pelo sistema de enfileiramento da camada 3 e o número de octetos que são usados realmente por um pacote uma vez ele alcança a camada física. A largura de banda real usada pelo pacote 64-bytes é muito maior em uma interface ATM do que em uma interface Ethernet. Especificamente, o CBWFQ e o LLQ não esclarecem estes dois grupos de despesas gerais específicos de ATM:

  • Acolchoar — Faz à última pilha de um pacote um mesmo múltiplo de 48 bytes. Este preenchimento é incluído pelo SAR assim que o pacote alcança a camada ATM.

  • cabeçalho de célula ATM 5-byte

Ou seja a avaliação CBWFQ e LLQ 64 bytes em 64 bytes, mas o pacote realmente ocupa 106 bytes e usa duas pilhas no ATM e nas camadas física. Em todas as relações, as bandeiras e um CRC estão igualmente atuais, mas não são incluídos pelo sistema de enfileiramento da camada 3.

A identificação de bug Cisco CSCdt85156 (clientes registrados somente) é um pedido da característica contar o CRC. Discute que toda a camada fixa e predizível 2 aérea, como um CRC, deve ser incluída na instrução de prioridade para fazer esta configuração tão exata e próxima como possível ao que está consumido realmente por um fluxo quando bate o fio físico.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 10420