Resumo

  • RFC 1286 definiu objetos gerenciados para bridges baseadas no rascunho IEEE 802.1d e optou por uma instrumentação pequena, útil e não redundante, sem sobrecarregar partes críticas da implementação.
  • Uma bridge port tem uma interface associada em dot1dBasePortIfIndex, mas diversas portas podem compartilhar a mesma interface e seu número não precisa coincidir com ifIndex. Os contadores cobrem somente protocolos bridgeados; a FDB diz onde uma fonte foi vista, ou que existe informação de encaminhamento sem porta aprendida.

O MIB descrevia uma função escolhida, não o mundo ao redor dela

O texto de RFC 1286 é antigo, mas a sua disciplina de escopo continua moderna. Ele não tentou espremer uma planta inteira de rede em SNMP. Ao explicar os critérios de seleção, parte de um conjunto pequeno de objetos essenciais, pede que sejam úteis para falhas ou configuração, limita seu número e exclui objetos redundantes, derivados ou sem utilidade. Também pede que se evite instrumentar pesadamente seções críticas.

Esse desenho atribui uma tarefa precisa a cada variável. A variável é uma superfície de gestão compartilhada: algo que implementações podem expor e operadores podem consultar de forma comparável. Ela não é um inventário exaustivo de cabos, uma declaração de quem usa o equipamento ou uma narrativa de tudo o que atravessou uma interface. A ausência de observação não é negação da realidade; a presença da observação não estende, por si só, o que foi observado.

A associação de porta e interface tinha direção e limites

No modelo, uma interface do grupo interfaces de MIB-II é considerada ligada a uma subnetwork — no sentido usado pelo RFC, que não deve ser confundido automaticamente com uma sub-rede IP. A bridge, por sua vez, tem portas. Cada porta fica associada a uma interface, e dot1dBasePortIfIndex informa a instância ifIndex dessa interface.

Contudo, a associação não apaga a diferença entre os dois objetos. RFC 1286 estabelece que uma mesma interface pode se associar a mais de uma porta. Seu exemplo é eloquente: vários circuitos virtuais X.25 numa só interface podem aparecer como portas diferentes. Cada porta recebe um número único, mas o número da porta não mantém relação obrigatória com o número da interface. A coincidência de dois números em um equipamento simples não é uma promessa do modelo.

Isso impede conclusões aparentemente inocentes. A porta não se torna automaticamente um conector físico; a interface não se torna automaticamente exclusiva daquela porta; e o administrador não ganha, apenas pelo índice, uma lista completa de todas as funções da entidade. O MIB oferece uma ponte entre duas superfícies de descrição. Não autoriza a substituição de uma pela outra.

O contador de bridge preservava seu próprio denominador

A limitação fica ainda mais explícita nos contadores. O RFC admite que uma entidade execute outros trabalhos nas mesmas interfaces. Pode, por exemplo, rotear datagramas IP e fazer bridge de outros protocolos. Nesse arranjo, somente os últimos integram a função de bridge. Portanto, o Bridge MIB — inclusive seus contadores — aplica-se aos dados enviados ou recebidos para protocolos bridgeados, e não necessariamente a todos os dados enviados ou recebidos pela interface.

O número de uma porta de bridge é, assim, uma medida funcional. Pode sustentar uma análise de tráfego submetido ao bridge. Não pode, sem uma fonte adicional, representar a carga completa do enlace, o total do ifIndex, o volume de uma aplicação ou a inexistência de tráfego fora da função. Quando o relatório muda o denominador sem dizê-lo, ele cria uma afirmação maior do que o instrumento produziu.

A FDB distinguia aprender, envelhecer e administrar

No banco de dados de encaminhamento de bridge transparente, dot1dTpFdbAddress é um MAC unicast para o qual a bridge possui informação de encaminhamento ou filtragem. dot1dTpFdbPort é zero ou a porta em que foi vista uma trama com aquele endereço como fonte. O zero não é uma lacuna: pode haver informação estática de encaminhamento ou filtragem sem um número de porta aprendido.

O estado completa a leitura. Há other, invalid, learned, self e mgmt. Uma entrada inválida pode ter sido aprendida e envelhecido, embora ainda não tenha sido removida. Uma entrada aprendida usa o valor de porta aprendido; uma entrada própria representa um endereço da bridge; uma entrada de gestão se liga a uma instância de endereço estático. O registro, portanto, informa como a bridge trata uma informação, e não tudo o que essa informação poderia significar fora dela.

Ver uma fonte numa porta não prova quem controla o MAC, onde o dispositivo está agora, se continua conectado, se um quadro chegou ao destino ou se uma operação foi autorizada. Uma linha envelhecida que ainda aparece é especialmente instrutiva: retenção no banco de dados não é contemporaneidade no cabo.

Endereço único era referência de protocolo, não evidência de controle

dot1dBaseBridgeAddress é o endereço MAC usado quando é preciso referir a bridge de forma única. O RFC recomenda, mas não exige, a menor MAC numérica dentre as portas. Com a prioridade de spanning tree, ela forma o BridgeIdentifier do protocolo.

Essa referência resolve uma necessidade de coordenação. Ela não prova proprietário, identidade administrativa, presença física, topologia convergida ou êxito de encaminhamento. A contribuição histórica de RFC 1286 está em fazer com que o objeto correto responda à pergunta correta, sem usar a comodidade de um identificador para alegar autoridade sobre fatos que ele não observa.

Fontes e limites da evidência

Este artigo utiliza RFC 1286 — Definitions of Managed Objects for Bridges. A fonte sustenta o escopo do Bridge MIB de 1991, a relação porta/interface, o domínio dos contadores, o endereço único de bridge e os estados da FDB. Ela não prova uma bridge, interface, porta, MAC, host, proprietário, topologia, autorização, entrega, tráfego total ou implantação atual.