Resumo

  • A RFC 1513 estendeu o RMON às redes Token Ring. dropEvents contava ocasiões em que a sonda descartava pacotes por falta de recursos, não o número exato de quadros descartados.
  • Relatórios de erro brando podiam usar entrega assegurada e aparecer duas vezes para uma sonda promíscua. Estação relatora, vizinho a montante, ordem do anel e intervalo de amostragem integravam a evidência.
  • Valor monitorado, estimativa de perda, atribuição de causa, autorização de controle e resultado eram recibos distintos. O RMON-2 posterior nomeou à parte contadores exatos de quadros descartados.

A precisão tinha um objeto menor

A RFC 1271 colocou funções de monitoramento em uma sonda remota e organizou estatísticas, histórico, hosts, matrizes, filtros, captura e eventos. Parte das vistas de enlace, porém, era específica de Ethernet. Em setembro de 1993, a RFC 1513 acrescentou o necessário para IEEE 802.5 Token Ring, inclusive grupos de estação, ordem, configuração e source routing.

Uma definição curta estabeleceu o limite. tokenRingMLStatsDropEvents aumentava quando a sonda descartava pacotes por falta de recursos. O texto dizia expressamente que o valor não era necessariamente o número de pacotes descartados; era apenas quantas vezes a condição fora detectada.

Um evento podia ocultar um quadro ou uma rajada. Dois eventos podiam durar tempos diferentes. A sonda conhecia a frequência com que percebia sua própria insuficiência, mas não recuperava, por esse contador, a quantidade de objetos que não conseguiu processar.

O número era exato. A pergunta “quantos quadros?” é que excedia seu contrato.

O observador também podia saturar

RMON economizava transporte ao resumir localmente. Essa economia dependia de CPU, memória, buffers e tabelas finitos. Quando a sonda saturava, dropEvents registrava uma falha de visibilidade, não necessariamente uma falha do anel.

A semântica reaparecia em estatísticas MAC, visão promíscua e intervalos históricos. Para comparar leituras, eram necessários interface, data source, control row, owner, status, época de ativação e janela de amostragem. Reinício, recriação da linha, wrap de contador ou troca de entrada podiam juntar experimentos diferentes numa série enganosa.

A RFC 4502 depois definiu objetos DroppedFrames e os descreveu como o número exato de quadros abandonados pela coleta, ao contrário de dropEvents. Não corrigiu um contador desonesto; criou uma medida diferente para uma afirmação diferente.

A entrega confiável podia duplicar o fato

A RFC 1513 alertou que pacotes de relatório de erro brando podiam ser enviados com entrega assegurada. Uma sonda em modo promíscuo, portanto, podia contar alguns erros duas vezes.

Garantir a chegada do relatório não garante que cada chegada represente um evento novo. Para decidir, eram necessários estação relatora, tipo, horário, ponto de captura e regra de deduplicação. O RFC prova que a duplicação era possível; não prova erro real de produto ou rede identificada.

O inverso também vale. Um zero não prova ausência de falha se o observador perdeu capacidade, a população do contador excluía certos quadros ou a época mudou.

A tabela organizava suspeitas, não culpados

As regras de contagem usavam a topologia do anel. Address Copied errors incrementavam o vizinho a montante mais próximo da estação relatora. Erros de linha e burst incrementavam relator e vizinho. Erros internos e de abort ficavam com a relatora.

Isso ajudava a organizar a investigação, mas não estabelecia causa física. Uma estação podia aparecer porque falou, porque era vizinha ou porque a regra escolheu sua entrada. O Ring Station Order Group mostrava a ordem das estações e ajudava a localizar o vizinho, mas seu retrato não provava topologia imutável no instante do erro nem entrega de tráfego.

Uma tela que cola um nome a um número vermelho pode transformar convenção contábil em veredicto. A especificação mantinha separados relator, vizinho, destino do contador e causa.

Escrever no MIB não era ter mandato

O Ring Station Configuration Group permitia remover uma estação ou baixar configuração. Mas o documento dizia que o access level do objeto descrevia apenas se ler ou escrever fazia sentido protocolar; era independente da política administrativa de autorização.

Um objeto read-write não outorgava poder. Um aumento de dropEvents, uma atribuição a vizinho ou um relatório duplicável também não autorizavam remoção automática. A ação exigia outro encadeamento: identidade, autorização, alvo, ordem prévia, comando, resposta, configuração resultante e efeito observado.

As estatísticas de source routing eram igualmente parciais, pois dependiam de informação opcional nas tramas. Classificar o que foi visto num anel não provava caminho ponta a ponta.

O alcance das fontes

O registro do RFC Editor e o Datatracker demonstram publicação, autoria, linhagem e status. As RFCs 1271, 1757, 2021, 2819, 3577 e 4502 documentam a família RMON.

Não demonstram implantação, perda, pane, defeito de fornecedor ou reparo específico. Historic não é relatório de incidente. A posterior depreciação de certos complementos Token Ring do RMON-2 por falta de implementações interoperáveis suficientes também não prova falha operacional da RFC 1513.

Running-Code Primacy pede execução e efeito observáveis. Minimum Initial Specification mantém mínimo o significado comum e expõe decisões locais. On Reality Layers impede que o símbolo herde a autoridade da realidade representada.

Quarenta e duas detecções podiam ser verdade. Quarenta e dois quadros, falhas ou mandatos de remoção exigiam provas que aquele contador nunca prometeu oferecer.

Fontes

  1. RFC 1513 — informações
  2. RFC 1513 — texto
  3. RFC 1513 — Datatracker
  4. RFC 1271 — informações
  5. RFC 1271 — texto
  6. RFC 1757 — informações
  7. RFC 1757 — texto
  8. RFC 2021 — informações
  9. RFC 2021 — texto
  10. RFC 2819 — informações
  11. RFC 2819 — texto
  12. RFC 3577 — informações
  13. RFC 3577 — texto
  14. RFC 4502 — informações
  15. RFC 4502 — texto
  16. Running-Code Primacy
  17. Minimum Initial Specification
  18. On Reality Layers