Resumo

  • A RFC 2358 acrescentou conformidade e erros de símbolo para 100 Mb/s sem fragmentar a identidade Ethernet, ligando as estatísticas do meio ao índice geral da interface.
  • Cada contador provava um evento definido, não a sua causa; capacidade, velocidade, duplex, época, instrumento e resultado do reparo permaneciam comprovantes independentes.

Uma tela de gerência pode ser perigosa justamente quando parece precisa. Em 1998, um valor que subia a cada segundo dava ao operador a sensação de estar vendo o problema em tempo real. A RFC 2358 tornou essa visão mais rica para a Fast Ethernet, mas suas definições também mostram por que um número rigoroso ainda pode sustentar uma conclusão errada.

Publicada em junho na trilha de padrões, a especificação substituiu a RFC 1650 e incluiu informações úteis para interfaces de 100 Mb/s. Ela se reconhecia como uma etapa da evolução. A RFC 2665 a substituiu em 1999 com gigabit e full duplex; a RFC 3635 levou a família a 10 Gb/s. Portanto, a RFC 2358 deve ser lida no seu momento: a MIB aprendendo a acompanhar a primeira grande multiplicação de velocidade da Ethernet.

A continuidade começou no tipo. Interfaces Ethernet deveriam usar ethernetCsmacd(6) independentemente da velocidade, em vez de se dividir em fastEther(62) ou fastEtherFX(69). A taxa operacional ficava em ifSpeed; o meio e o duplex, em ifMauType na MIB MAU 802.3. O sistema preservava uma identidade e deixava as propriedades variáveis em registros próprios.

Essa separação corrigia uma conta intuitiva. Uma linha de 100 Mb/s em full duplex continuava declarando 100 Mb/s, não 200. O duplex não era deduzido do volume. A RFC exigia a MIB MAU porque, sem ela, a aplicação não tinha uma forma padronizada de saber o modo. Velocidade conhecida e duplex desconhecido podiam coexistir.

Capacidade também não significava estado atual. Uma interface capaz de 100 Mb/s tinha de implementar ether100MbsCompliance mesmo quando operava em velocidade inferior. Contadores exclusivos do modo mais rápido poderiam permanecer parados. A conformidade dizia o que o agente precisava expor, não qual velocidade fora negociada nem se o serviço estava saudável.

dot3StatsIndex apontava para a mesma interface que o ifIndex de igual valor. Assim, pacotes e octetos genéricos podiam ser combinados com colisões e erros próprios da Ethernet. Mas a junção era parte da prova. Se uma reinicialização mudasse os índices e o inventário ficasse antigo, valores corretos seriam atribuídos à porta errada.

O objeto novo mais característico era dot3StatsSymbolErrors. Ele avançava quando um símbolo de dados inválido aparecia durante uma portadora válida, no máximo uma vez por evento de portadora. Vários símbolos ruins no mesmo evento não viravam vários incrementos. Logo, uma diferença de um não era um bit ruim, uma trama ruim ou uma interrupção percebida pelo cliente.

As colisões também tinham unidades cuidadosas. Uma colisão tardia surgia depois de 512 tempos de bit; a 10 Mb/s, 51,2 microssegundos. Colisões excessivas contavam quadros cuja transmissão fracassara por colisões demais. Transmissões adiadas esperavam o meio livre na primeira tentativa e não incluíam quadros que colidiram. O histograma opcional agrupava quadros pelo número exato de colisões.

Esses limites davam comparabilidade, não autoria. Colisões tardias podem combinar com topologia fora dos limites ou incompatibilidade de duplex. Erros de FCS, alinhamento e símbolo podem acompanhar cabo, ruído, óptica, silício ou driver. A MIB não escolhia o culpado. Era preciso confrontar os dois lados, a configuração, o meio e o efeito da intervenção.

dot3StatsInternalMacTransmitErrors deixava a incerteza explícita. O objeto reunia falhas internas que não haviam sido contadas como colisão tardia, colisão excessiva ou erro de detecção de portadora, e seu sentido exato dependia da implementação. O rótulo delimitava um resto; não entregava uma causa universal.

dot3StatsEtherChipSet identificava o chip que reunia estatísticas e indicações de erro, permitindo considerar anomalias conhecidas. Isso era procedência do instrumento. Saber quem mediu não provava que o medidor causara a falha.

Até a soma dos erros exigia cautela. Uma trama recebida que satisfazia várias condições era registrada apenas segundo o estado entregue pelo serviço MAC ao seu usuário. As colunas mostravam o resultado de uma classificação, não todas as características físicas presentes simultaneamente.

O tempo completava o registro. Como os objetos eram Counter32, uma diferença precisava de intervalo e época de descontinuidade. Reinício, reset ou remapeamento tornavam a subtração enganosa. Valor, interface, instrumento e época precisavam viajar juntos.

Testes ativos não eliminavam a investigação. Loopback e TDR apareciam numa ifTestTable já desaconselhada; eram opcionais e muitos chips não os suportavam. O resultado de TDR dependia de objeto do fabricante. Iniciar, concluir, obter, interpretar, localizar e confirmar o reparo eram recibos diferentes.

Por fim, somente leitura não significava informação pública. A MIB não oferecia objetos de escrita ou criação, mas o chipset podia revelar o fornecedor do equipamento. SNMPv1 sozinho era inseguro; IPsec não definia qual pessoa dentro da rede protegida podia executar GET. A RFC recomendava segurança por usuário e controle por visão do SNMPv3.

O encadeamento correto, portanto, era: equipamento, porta, índices, época, velocidade, capacidade, meio, duplex, incrementos classificados, chip, observação do par, hipótese, mudança e verificação. A verdade de uma etapa não preenchia a seguinte.