Portas compartilhadas RJ45/SFP 17-20 do FortiGate 101F apagam depois de um upgrade do FortiOS
Rodamos um par de FortiGate 101F para um escritório de 40 pessoas, nada exótico. port17 carrega um uplink SFP para o switch core, port19 é um trecho RJ45 até a sala de servidores, as duas dentro do bloco compartilhado RJ45/SFP (portas 17-20). Na janela de manutenção do mês passado subimos o par para o FortiOS 7.4.4, e desde então esse bloco está morto.
- FortiGate 101F, e um FortiGate 100F no segundo site se comportando igual
- port17: módulo SFP 1G para um switch de acesso empilhado
- port19: RJ45 para uma porta de switch 1G
- FortiOS 7.4.4, atualizado a partir de uma build 7.2
As portas 1-16 estão bem, só as compartilhadas caíram. O que me chamou atenção é que as opções de velocidade na GUI não parecem mais o que eram antes do upgrade, e a config em execução agora tem isto:
config system interface
edit "port17"
set speed 1000full
next
endNinguém aqui digitou isso. Toda porta nessa caixa estava em auto antes do upgrade.
Já tentei:
- reencaixei o SFP e troquei por um sabidamente bom, sem mudança
- movi a outra ponta para uma porta de switch diferente
- reboot frio do firewall, a config sobrevive como acima
É esperado que o bloco compartilhado RJ45/SFP do 100F/101F perca o auto durante um upgrade, ou nossa config foi bagunçada em algum lugar? E qual é o jeito certo de reverter isso?
Comments 5
Sua config não foi bagunçada por ninguém no escritório, foi o upgrade. No 100F e no 101F, o upgrade silenciosamente estampa um 1000full fixo nas portas compartilhadas RJ45/SFP onde antes era auto, sem perguntar se o par aguenta essa taxa. Dependendo da outra ponta você acaba com uma porta que linka na velocidade errada, ou uma que nunca linka, que é exatamente por que 17-20 estão apagadas enquanto as portas dedicadas ficam intocadas. A Fortinet tem isso registrado como o known issue 989629, documentado nas release notes da 7.2.9; as branches afetadas são v7.2.8 em diante, v7.4.2 em diante e v7.6.0 em diante.
Devolva a velocidade à mão, porta por porta:
Na v7.2.8 e da v7.4.2 até a v7.4.4 o auto puro não é oferecido na lista, que é exatamente por que a GUI parece diferente para você, então use 1000auto nelas. Na v7.2.9, v7.4.5, v7.6.0 em diante a opção normal está de volta e você quer:
Repita para port18 até port20 se estiverem em uso. E para a próxima janela: confira antes se nada do seu caminho de gerenciamento cai nas portas 17-20, senão a caixa volta com sua porta de acesso forçada em 1000full e você vai ter que ir até o site para consertar pelo console.
De qual build você realmente veio? "uma build 7.2" cobre um território enorme, e o que você tem que digitar para corrigir isso muda entre as branches. A outra coisa que vale saber é se as outras pontas oferecem autonegociação ou estão fixadas também: um par que só autonegocia vai ficar parado sem fazer nada contra uma porta travada numa taxa fixa.
Uma coisa para resolver antes de mudar qualquer coisa: seu caminho de gerenciamento passa por alguma das portas 17-20? Se passar, faça a próxima mudança pelo console, não pela rede.
Vale acrescentar o ponto geral para quem chegar aqui com uma porta compartilhada se comportando mal: na maioria das caixas o par é mesmo exclusivo. A NETGEAR chama isso de dual personality no GS716T-200, onde cada uma das duas gaiolas SFP é emparelhada com uma das portas de cobre finais, e só uma metade desse par pode estar ativa por vez, então encaixar um módulo tira silenciosamente o RJ-45 correspondente de serviço. Toda porta desse modelo é gigabit de qualquer forma, então o uplink óptico compra uma rota de cabo, não banda.
Mesma ideia no bloco do FortiGate, então confirme qual metade da port17 você está realmente olhando. Um módulo na gaiola mais um cordão no lado de cobre da mesma porta é um gol contra clássico, e parece muito um problema de velocidade visto pela CLI.
Fabricante diferente, mesmo tipo de dor de cabeça. EX4200 com um módulo de uplink EX-UM-2X4SFP: xe-0/1/0 rodava 10G numa boa, xe-0/1/1 nem conseguia ser adicionada a uma VLAN e não passava tráfego nenhum. As duas portas funcionavam em 1G, o SFP+ aparecia completo no show chassis hardware, troquei módulos, tentei um EX-UM-2X4SFP reserva e fiz um factory reset antes de alguém me dizer o que aquele módulo realmente é.
Nada estava com defeito. Aquele módulo aceita SFP+ só em duas das gaiolas dele, as numeradas 0 e 2 no hardware; o outro par carrega óptica 1G e nada mais rápido que isso. Então as interfaces 10G que você acaba tendo são xe-0/1/0 mais xe-0/1/2, e a xe-0/1/1, aquela com que eu estava brigando, nunca ia rodar em 10G não importa o que eu colocasse nela. Movi a óptica uma gaiola ao lado, configurei xe-0/1/2, resolvido. Com gaiolas de modo misto, leia o que o bloco suporta antes de fazer RMA de qualquer coisa.
Cuidado com o ângulo da exclusividade do combo, ele não explica esse caso. As portas funcionavam antes do upgrade, só o bloco compartilhado quebrou depois, e tem uma linha de speed na config que ninguém digitou. Isso é a reescrita, não prioridade de gaiola.
O erro oposto também queima gente, porém. Uma vez passei uma semana em switches D-Link DES-1210-52 conectados por fibra a um OSNOVO NS-SW-8GX2G: indicação de link nas portas ópticas, nenhuma LAN, nenhuma internet, enquanto os mesmos switches funcionavam bem encadeados por cobre, e uma atualização de firmware não mudou nada. A porta combo foi a principal suspeita por dias. A falha real estava na outra ponta: as portas do OSNOVO que carregavam aqueles módulos SFP estavam mortas internamente, queimadas, com as ópticas sentadas nelas perfeitamente saudáveis.
Então depois que a config local estiver certa, coloque um módulo sabidamente bom numa porta sabidamente boa do outro lado antes de concluir qualquer coisa sobre a sua própria caixa.