Olá ifurtado,
Estou quase concluindo parte do que eu preciso fazer para que o meu ambiente monitorado esteja pronto e operacional de fato. Infelizmente acabei empacando num item que já mais tinha percebido nos equipamentos switches da cisco, mas acredito que com toda a sua expertise poderá me ajudar.
Antes de tudo, deixa explicar o cenário atual...
Houve a necessidade de monitorar em tempo real, o estado operacional de cada uma das interfaces em modo trunk dos quase 200 switches que gerencio no meu ambiente. O design da nossa rede baseia-se no modelo Hierárquico, onde na camada de Distribuição, agrego os dados recebidos dos switches da camada de acesso, aumentando drasticamente a disponibilidade por meio de implementação de redundância simples.
Com isso, os switches da minha camada de acesso são conectados a dois switches L3 da camada de distribuição diferentes para assegurar uma redundância de caminho. Caso haja falha no switch da camada de Distribuição, o switch da camada de acesso pode comutar para o outro switch L3 da camada de Distribuição.
Então, visando inibir a ocorrência de uma situação inesperada onde por uma falha de camada 1 por exemplo, a interface de redundância possa vir a deixar de funcionar, e só descobrir que isso aconteceu apenas no ato sinistro, isso estou trabalhando num template dentro do zabbix que monitore da seguinte forma:
1º) Através do OID 1.3.6.1.4.1.9.9.46.1.6.1.1.14.X, configurei o recurso de Descoberta via SNMP de modo que consigo obter automaticamente o modo configurado de cada uma das interfaces dos switches da camada de acesso[Mode Trunk(1) ou Mode Access(2)]. JÁ ESTÁ FUNCIONANDO.
2º) Em seguida configurei um outro item de Descoberta via SNMP de modo que consigo obter o estado operacional de cada uma das interfaces do Switch [Se está UP(1) ou Down(2)]. JÁ ESTÁ FUNCIONANDO.
Resultado:
3º) Por fim, com o objetivo de montar a lógica seguinte "Caso a interface esteja operando no modo Trunk(1) .E. Estado Operacional seja Down(2), então o servidor considera tal evento como um Desastre e dispara um SMS/E-mail para o Administrador", a partir disso criei um protótipo de trigger, que irá constantemente realizar a análise deste evento. NÃO É EXECUTADO.
Vamos ao problema:
O item 3º não está sendo executado, pois percebeu-se que apesar da lógica e estar corretamente configurada, a Interface operando em modo trunk, sempre que tem seu estado operacional como down (por que o cabo de rede foi desconectado, por exemplo) o seu Modo muda automaticamente para Access(2), com isso, a lógica descrita no item 3º a cima, nunca é verdadeira e por isso o evento de "Desastre" nunca é chamado.
Segue a baixo o printscreen dos dois cenários, sendo o da esquerda com a aplicação de "Interface Mode" -> "Interface Trunk GigabitEthernet0/1" -> coluna, "Ultimo Valor" como MODE TRUNK(1) e a Aplicação "Operational Status Interface" -> "Operational status of Interface GigabitEthernet0/1" -> Coluna, "Ultimo Valor" como UP(1).
No cenário da direita, pode-se verificar que que a aplicação "Interface Mode"->"Interface Trunk GigabitEthernet0/1"->Coluna, "Ultimo Valor" como MODE ACCESS(2). E a aplicação "Operational Status Interface"-> "Operational status of Interface GigabitEthernet0/1"-> Coluna, "Ultimo Valor" como Down(2).
Caso a qualidade da imagem não fique boa, estou enviando em anexo o power point.
Com isso ifurtado,
Já procurei porém tem pouquíssimo template com novas aplicações na internet e quase nenhum voltado pra essa necessidade em específico em monitorar a interface trunk quando up ou down.
Mas acredito que o problema possa estar no OID que estou utilizando, talvez. Mas estranho o fato de após a interface ficar down, seu modo simplesmente mudar pra access. Bom, vou ficando por aqui, mas qq coisa, deixa no comentário que irei companhar também.
Abraços.
Sucesso.
Olá Jorenilson,
Realmente o status reportado pelo SNMP indica que a porta não está entroncando, o que em tese seria natural haja vista que o circuito físico foi derrubado.
No entanto, o output do comando "show interface xyz switchport" indica que a referida porta está administrativamente determinada como "Trunk".
Ou seja, em linhas gerais, a porta está administrativamente definida como Trunk mas operacionalmente como estado desconhecido, justamente por conta da derrubada do circuito, e, com isso, a porta fica incapaz de entroncar.
Note que o status reportado é derivado a partir dos valores reportados pelo vlanTrunkPortDynamicState e ifOperStatus, sendo que ambos constituirão o estado "trunking"ou não da referida porta. Não saberia informar no momento se isto poderia ser considerado como uma situação absolutamente normal ou se algo poderia ser feito neste caso.
Todavia, certifique-se de confirmar conosco a versão do seu Cisco IOS Software e se a referida porta está configurada também com o comando "switchport nonegotiate".
Aproveite a oportunidade para fazer debugs antes e após a derrubada do link, com o comando debug sw-vlan vtp
Eu precisarei destas e possivelmente de outras informações para rastrear este caso mais detalhadamente.
Abs
Leonardo Furtado
Olá @Jorenilson Santos tudo bem?
Se você gostou das respostas do @lfurtado e se elas foram úteis, por favor, não deixe de avaliar a resposta por meio da estrelinha que está abaixo da resposta.
A sua opinião é muito importante para que os especialistas continuem ajudando na comunidade.
Muito obrigada.
