Redes de Longa Distância

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Continuidade e protecção de activos digitais; Diagnóstico, desempenho e disponibilidade.

Objectivos

• Calcular o tempo de indisponibilidade admitido por uma percentagem de disponibilidade num contrato.
• Identificar o que um contrato de ligação (acordo de nível de serviço) deve conter e como se verifica.
• Demonstrar porque uma rota de reserva baseada só no estado da interface não detecta uma falha «silenciosa», e aplicar uma verificação activa do próximo salto.

Percentagens que se traduzem em horas

Um contrato de 99,5 % de disponibilidade mensal admite 0,5 % de um mês sem serviço: em 30 dias (720 horas) são 3,6 horas. 99,9 % admite cerca de 43 minutos; 99,99 %, cerca de 4 minutos. Antes de assinar, pergunta-se: como mede o operador, em que período (mês, ano), se as manutenções programadas contam, qual o tempo de reposição, que compensação existe e como se abre uma avaria (contacto, horário, número de registo).

A instituição deve medir por si própria (monitoria da ligação, módulo 11) para poder comparar com o relatório do operador. Sem medição própria, o contrato é difícil de fazer cumprir.

Redundância que detecta a falha certa

No módulo 3 a rota de reserva entrava quando a interface principal ficava em baixo. Na WAN é frequente o contrário: a interface local continua «em cima» (o equipamento do operador responde ao nível físico), mas o tráfego não passa mais à frente. Nesse caso a rota principal continua activa e o tráfego perde-se.

Soluções: um protocolo de encaminhamento dinâmico com temporizadores (OSPF, módulo 3), a detecção bidireccional BFD (RFC 5880, suportada pelo FRRouting e por muitos fabricantes) ou, em ambientes simples, uma verificação activa que testa o próximo salto e muda a rota. A redundância real exige também caminhos independentes: duas ligações do mesmo operador pela mesma vala podem falhar juntas. O plano de contingência (NIST SP 800-34) regista o que fazer e quem avisar quando a reserva entra.

Caso fictício

A DPE (fictícia) contratou uma ligação principal de 99,5 % mensais e uma reserva de outro operador (ligação 10.255.4.0/30: r1 = 10.255.4.1, r2 = 10.255.4.2). Numa segunda-feira a delegação ficou 2 horas sem sistema, apesar da reserva: o equipamento do operador principal continuava ligado, mas não encaminhava tráfego.

Prática guiada em rede isolada

Rede de prática fictícia, criada dentro de um computador de prática com o script base (módulo 1, lição 1). Nunca use estes passos na rede de produção nem contra endereços reais. As saídas mostradas são exemplos didácticos, não resultados de uma execução.

Topologia (descrição em texto)

• pc-adm (10.10.10.10) — ligado a r1 pela VLAN 10.
• srv (10.10.20.53) — ligado a r1 pela VLAN 20.
• r1 (encaminhador da sede) — ligado a pc-adm, srv, r2 e isp.
• r2 (encaminhador da delegação) — ligado a r1 e a pc-del (10.20.10.10).
• isp (operador simulado) — ligado a r1 e ao servidor externo 198.51.100.10 (endereço dentro de isp).
• Novo: ligação de reserva r1-r2b / r2b-r1 com 10.255.4.1/30 (r1) e 10.255.4.2/30 (r2).
• Falha silenciosa simulada com tc netem loss 100% em r2-r1: a interface fica UP, mas nada passa.

Passos

1. Pré-verificação: as interfaces novas não existem.

   sudo ip -n r1 link show r1-r2b 2>/dev/null && echo 'r1-r2b JA EXISTE: parar'
   sudo ip -n r2 link show r2b-r1 2>/dev/null && echo 'r2b-r1 JA EXISTE: parar'
   echo verificado

   Saída de exemplo (didáctica):

   verificado

2. Crie a ligação de reserva e as rotas de reserva com métrica maior.

   sudo ip link add r1-r2b type veth peer name r2b-r1; sudo ip link set r1-r2b netns r1; sudo ip link set r2b-r1 netns r2
   sudo ip -n r1 addr add 10.255.4.1/30 dev r1-r2b; sudo ip -n r2 addr add 10.255.4.2/30 dev r2b-r1
   sudo ip -n r1 link set r1-r2b up; sudo ip -n r2 link set r2b-r1 up
   sudo ip -n r1 route add 10.20.10.0/24 via 10.255.4.2 metric 200
   sudo ip -n r2 route add 10.10.0.0/16 via 10.255.4.1 metric 200
   sudo ip -n r1 route show 10.20.10.0/24

   Saída de exemplo (didáctica):

   10.20.10.0/24 via 10.255.0.2 dev r1-r2
   10.20.10.0/24 via 10.255.4.2 dev r1-r2b metric 200

3. Provoque a falha silenciosa na principal e observe que a rota não muda.

   sudo ip netns exec r2 tc qdisc add dev r2-r1 root netem loss 100%
   sudo ip -n r2 link show r2-r1 | grep -o 'state [A-Z]*'
   sudo ip netns exec pc-del ping -c 3 -W 1 10.10.20.53
   sudo ip -n r2 route get 10.10.20.53

   Saída de exemplo (didáctica):

   state UP
   3 packets transmitted, 0 received, 100% packet loss
   10.10.20.53 via 10.255.0.1 dev r2-r1 ...

4. Crie o script de verificação activa (didáctico: corre na máquina de prática e muda as rotas das duas pontas). Guarde-o como /tmp/m9-verificar.sh.

   sudo tee /tmp/m9-verificar.sh <<'EOF'
   #!/bin/sh
   # Testa o próximo salto da ligação principal a partir de r2; se falhar 3 vezes, usa a reserva.
   if ip netns exec r2 ping -c 3 -W 1 -q 10.255.0.1 >/dev/null; then
     ip -n r1 route replace 10.20.10.0/24 via 10.255.0.2 metric 0
     ip -n r2 route replace 10.10.0.0/16 via 10.255.0.1 metric 0
     echo "$(date -Is) principal OK"
   else
     ip -n r1 route del 10.20.10.0/24 via 10.255.0.2 2>/dev/null
     ip -n r2 route del 10.10.0.0/16 via 10.255.0.1 2>/dev/null
     echo "$(date -Is) principal FALHOU: reserva em uso"
   fi
   EOF
   sudo sh /tmp/m9-verificar.sh
   sudo ip netns exec pc-del ping -c 3 10.10.20.53

   Saída de exemplo (didáctica):

   2026-09-28T10:15:03+02:00 principal FALHOU: reserva em uso
   3 packets transmitted, 3 received, 0% packet loss

5. Reponha a principal e confirme o regresso.

   sudo ip netns exec r2 tc qdisc del dev r2-r1 root
   sudo sh /tmp/m9-verificar.sh
   sudo ip -n r2 route get 10.10.20.53

   Saída de exemplo (didáctica):

   2026-09-28T10:17:40+02:00 principal OK
   10.10.20.53 via 10.255.0.1 dev r2-r1 ...

Critérios de sucesso

• A dupla mostra que, com a falha silenciosa, a interface fica UP e a rota principal não muda sozinha.
• Depois do script, o tráfego passa pela reserva; ao repor, volta à principal.
• A dupla calcula as horas admitidas pelo contrato e indica se as 2 horas do caso o violam num mês sem outras falhas.
• A dupla nomeia a solução de produção (BFD ou OSPF com temporizadores) e porque o script é só didáctico.

Como desfazer (reversão)

• sudo ip netns exec r2 tc qdisc del dev r2-r1 root 2>/dev/null
• sudo ip -n r1 route replace 10.20.10.0/24 via 10.255.0.2; sudo ip -n r2 route replace 10.10.0.0/16 via 10.255.0.1
• sudo ip -n r1 link del r1-r2b (apaga também r2b-r1 e as rotas de reserva)
• sudo rm -f /tmp/m9-verificar.sh
• Verificar: sudo ip -n r1 route show 10.20.10.0/24 mostra só a rota via 10.255.0.2.

Alternativa em papel: tarefas e respostas esperadas

Calcule o tempo admitido por mês (30 dias) para 99,5 %, 99,9 % e 99,99 %.

720 h × 0,005 = 3,6 h (3 h 36 min); 720 h × 0,001 = 0,72 h (43,2 min); 720 h × 0,0001 = 0,072 h (cerca de 4,3 min).

As 2 horas do caso violam o contrato de 99,5 % mensais, se não houve outras falhas?

Não: 2 h é menos do que as 3,6 h admitidas. Mesmo assim, é um incidente a registar, e a reserva devia ter entrado — é uma falha do desenho, não do contrato.

Com as saídas de exemplo do passo 3, explique porque a reserva não entrou.

A interface r2-r1 continua «state UP» e a rota principal continua a mais preferida (métrica 0); o sistema não sabe que o tráfego se perde mais à frente. É preciso verificação activa (BFD, OSPF ou teste do próximo salto).

Liste cinco pontos a exigir no contrato de ligação.

Disponibilidade e período de medição; se as manutenções contam; tempo máximo de reposição; forma e horário de abertura de avaria; compensação por incumprimento; relatório mensal do operador.

Verifique o que aprendeu

Questão 1

Porque a rota de reserva não entrou na falha do caso?

1. Porque a métrica da reserva era baixa
2. Porque a interface principal continuava UP e nada verificava se o tráfego passava
3. Porque o operador de reserva estava em baixo
4. Porque faltava NAT

Questão 2

Duas ligações do mesmo operador, pelo mesmo cabo até ao edifício, são redundância suficiente?

1. Sim, porque são duas
2. Não necessariamente: partilham pontos de falha (cabo, central, operador)
3. Sim, se tiverem VPN
4. Sim, se forem de fibra

Em leitura fácil

• 99,5 % por mês quer dizer até 3 horas e meia sem serviço.
• Meça a ligação você mesmo, para comparar com o operador.
• Às vezes o cabo parece ligado, mas nada passa.
• Por isso a reserva precisa de testar se o caminho funciona.

Fontes

• IETF RFC 5880 — Bidirectional Forwarding Detection (https://www.rfc-editor.org/rfc/rfc5880)
• FRRouting — documentação oficial (zebra, staticd, ospfd, vrrpd, vtysh) (https://docs.frrouting.org/)
• Linux iproute2 — páginas de manual ip(8), ip-netns(8), bridge(8), tc(8) (https://man7.org/linux/man-pages/man8/ip.8.html)
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide (https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)