Em produtos ADC clássicos, o gerenciamento de rotas normalmente se baseia em uma única tabela global. Isso é suficiente para implantações pequenas, mas rapidamente atinge seus limites em cenários multi-tenant, multi-departamento, MSP, rede governamental, separação de DMZ/rede interna ou migração de data center.
O primeiro problema é a sobreposição de IP. Diferentes clientes, departamentos ou ambientes podem usar os mesmos blocos de IP privado. Ter dois tenants separados usando 10.0.0.0/8 é muito comum no mundo real. Uma única tabela de rotas global não consegue separar essas duas redes de forma limpa no mesmo appliance.
O segundo problema é a divisão entre roteamento estático e dinâmico em dispositivos separados. Se um roteador aprende rotas via BGP/OSPF enquanto o ADC consulta sua própria tabela estática, metade da decisão de tráfego fica em um dispositivo e a outra metade em outro. Isso prolonga significativamente o debugging — se o ADC está encaminhando corretamente, se o roteador aprendeu a rota certa e de onde vem o caminho de retorno devem ser investigados separadamente.
O terceiro problema é a dependência do gateway padrão. Um gateway pode aparecer fisicamente ativo enquanto é incapaz de alcançar o upstream. A configuração clássica não detecta isso; o tráfego continua sendo enviado para um gateway que parece saudável, mas está na verdade inacessível.
O quarto problema é a necessidade de roteamento baseado em fonte ou em política. Algum tráfego deve sair via WAN1, algum via um túnel VPN, algum tráfego de tenant via um link MPLS dedicado, e alguns serviços via a saída de internet. Se um ADC gerencia isso apenas com uma tabela de rotas global, o operador é forçado a depender de CLI, scripts ou um roteador externo.
O TR7 ADC coloca o modelo de Route Table no núcleo do ADC: cada tenant e zona de rede toma suas próprias decisões de roteamento; rotas estáticas, rotas dinâmicas, monitoramento de gateway e fluxos de serviço são todos gerenciados de um único console.
O TR7 retira o roteamento de uma tabela global — cada zona de rede vive em sua própria Route Table independente.
No TR7, uma Route Table não é meramente uma lista de rotas. É um contexto de rede separado que determina de qual interface o tráfego chega, para qual gateway é encaminhado, por quais regras de segurança passa e qual backend alcança. Esse modelo permite que múltiplas zonas de rede independentes rodem no mesmo appliance, cada uma com seu próprio plano de IP, gateway, rotas estáticas e comportamento de roteamento dinâmico.
Rotas estáticas podem ser definidas pela interface do TR7 selecionando a rede de destino, gateway, interface e métrica. Em implantações mais avançadas, protocolos de roteamento dinâmico como BGP, OSPF, RIP e IS-IS também podem rodar no mesmo contexto de Route Table. O tráfego de gerenciamento pode ser fixado via rotas estáticas enquanto o tráfego de produção segue caminhos aprendidos dinamicamente — ambos dentro do mesmo appliance, o mesmo modelo de governança e a mesma visão operacional.
O TR7 suporta o direcionamento de tráfego não apenas por IP de destino, mas também por sinais de política. Um fluxo de vService específico pode ir para uma WAN redundante, o tráfego de um tenant específico pode ser direcionado para um link dedicado, e um fluxo marcado pode ser colocado em uma route table diferente. Isso é particularmente valioso para WAN redundante, saída de internet ativo/ativo, separação de link por tenant, seleção de rota por serviço e cenários de trânsito inline.
O TR7 pode rastrear se um gateway padrão é genuinamente acessível. Após um número configurado de verificações com falha, o gateway é marcado como não saudável e uma rota alternativa ou gateway alternativo pode ser ativado. Isso é crítico para detectar o cenário de gateway ativo mas upstream inativo. O tráfego nunca é enviado no escuro — o TR7 decide com base na acessibilidade real.
O modelo de Route Table do TR7 reúne todas as capacidades de roteamento necessárias para implantações multi-tenant e topologias de rede complexas.
Cada Route Table do TR7 toma suas próprias decisões de roteamento. Os mesmos blocos de IP podem ser usados em diferentes Route Tables sem conflito. Isso fornece o isolamento fundamental necessário para ambientes MSP, SaaS, governo, financeiro e multi-cliente.
Os operadores definem a rede de destino, gateway, métrica e interface diretamente pela interface. As rotas estáticas são usadas principalmente para redes de gerenciamento, links dedicados, caminhos redundantes, separação DMZ/rede interna e segmentos de backend específicos.
Em algumas configurações de WAN ou ponto a ponto, o IP do gateway pode não aparecer dentro da mesma sub-rede. O TR7 suporta o comportamento gateway-on-link para tais conexões, reduzindo a necessidade de etapas manuais adicionais em links de WAN dedicada, túnel ou provedor de serviço.
O TR7 fornece uma infraestrutura capaz de executar protocolos de roteamento dinâmico para equipes de rede avançadas. BGP, OSPF, RIP, IS-IS e protocolos similares podem ser usados no contexto de Route Table. Isso torna o ADC um participante ativo de roteamento no data center ou rede de tenant, em vez de um dispositivo passivo que entende apenas rotas estáticas.
Um console dedicado vinculado à Route Table está disponível para gerenciamento avançado de comandos e protocolos no lado de roteamento dinâmico. Definições de vizinhos, inspeção de rotas, estado de protocolo e depuração detalhada são realizados por usuários avançados por meio desta interface. A infraestrutura de roteamento central e o acesso ao console estão presentes; um editor de GUI totalmente baseado em formulários para todo o gerenciamento de vizinhos BGP/OSPF é uma área separada do roadmap.
O TR7 permite que tráfego específico seja colocado em comportamento de roteamento diferente. Isso é usado para seleção de rota por serviço, por tenant ou por fluxo marcado. O tráfego de gerenciamento pode sair por um gateway estático enquanto o tráfego de produção segue rotas dinâmicas; o tráfego de tenant específico pode ser colocado em um link VPN enquanto o tráfego de VIP específico é direcionado para uma WAN redundante.
O gateway padrão é verificado em intervalos regulares. Quando as falhas excedem o limite configurado, a rota é marcada como não saudável. Um gateway alternativo ou rota alternativa pode então ser ativado. Essa capacidade examina a acessibilidade real do gateway, não apenas o estado do link.
Quando o gateway primário falha, pode ser feita uma transição para um gateway secundário. Isso é usado para redundância de saída de internet, failover de WAN, backup de MPLS, backup de VPN e cenários de gateway intra-data-center redundante.
O TR7 não reproduz toda a estrutura de roteamento a cada mudança. Rotas adicionadas, editadas e excluídas são diferenciadas e apenas as rotas alteradas são aplicadas. Essa abordagem reduz o risco em sistemas em produção e permite que as mudanças entrem em vigor mais rapidamente.
O TR7 pode gerenciar estruturas de rotas IPv4 e IPv6 separadamente. Em ambientes dual-stack, ambas as famílias de IP operam juntas sob o mesmo modelo de Route Table.
Cada Route Table pode ter suas próprias configurações de resolução de nomes. Isso é útil para DNS por tenant, resolvers internos privados, ambientes de teste isolados e diferentes cenários de domínio interno.
Em cenários de cluster HA, qual dispositivo mantém o VIP ativo é importante para a aplicação de rota. O TR7 gerencia a aplicação de rota de acordo com a lógica de dispositivo ativo em alinhamento com o método de transição de VIP em uso: apenas VRRP, verificação de link TR7, verificação de gateway TR7 e verificação de link e gateway TR7.
Um vService pode escutar em uma Route Table e encaminhar tráfego para backends residindo em uma Route Table diferente. Exemplo: o tráfego de internet de entrada é recebido na Route Table da DMZ e encaminhado de forma controlada para o backend na Route Table interna. O mesmo appliance se torna um ponto de trânsito controlado entre zonas de rede.
As rotas de gerenciamento podem ser mantidas fixas enquanto o tráfego de produção flui ao longo de rotas aprendidas dinamicamente. Os valores de métrica definem a prioridade. O operador bloqueia caminhos críticos como estáticos e delega segmentos de rede variáveis a protocolos dinâmicos.
O modelo de Route Table vai além da criação de regras — também abrange ordenação de aplicação, limites do monitor de gateway, ciclo de vida de roteamento dinâmico e tratamento de falhas.
Cada rota é definida pelos seguintes campos principais: rede de destino, gateway, interface, métrica, comportamento gateway-on-link e a Route Table associada. Essa estrutura é suficiente tanto para rotas estáticas simples quanto para cenários complexos de multi-gateway.
A aplicação de rota depende do estado de interface e IP. O TR7 aplica primeiro as mudanças de interface e IP, depois ativa as mudanças de rota. Essa ordenação elimina uma classe de erros onde uma rota está presente, mas a interface ainda não está pronta.
O monitor de gateway verifica em intervalos definidos. Após um número de falhas consecutivas, o gateway é considerado não saudável; após um número de sucessos consecutivos, é considerado saudável novamente. Essa abordagem de rise/fall evita que flutuações transitórias acionem flaps de rota.
A infraestrutura de roteamento dinâmico roda dentro do contexto de Route Table. Os serviços de protocolo relevantes são iniciados, os arquivos de configuração são gerados, o console de protocolo é preparado e o processo de aprendizado de rotas é vinculado à Route Table relevante.
Se uma rota não puder ser aplicada, o TR7 avalia a falha de forma isolada. Rotas aplicadas com sucesso são preservadas e o erro para a rota problemática é apresentado. Isso evita que uma única rota inválida corrompa toda a estrutura de roteamento.
O isolamento de Route Table ganha pleno significado quando combinado com isolamento de firewall. As rotas de um tenant nunca se misturam com as regras de firewall de outro tenant. O tráfego não apenas atravessa a Route Table correta — também passa pela política de segurança correta.
Um IP de frontend de vService pode escutar dentro de uma Route Table específica. O lado do backend pode ser alcançado por uma Route Table diferente. Isso transforma o ADC de um dispositivo que simplesmente encaminha o tráfego de entrada para um backend próximo em um gateway de serviço controlado entre zonas de rede.
O motor de roteamento dinâmico e o acesso ao console estão disponíveis. No entanto, gerenciar todos os vizinhos, filtros, listas de prefixo e route maps inteiramente por meio de uma GUI baseada em formulários é uma área separada do roadmap. Equipes de rede avançadas realizam o gerenciamento detalhado por meio do console de protocolo.
Um MSP executa muitos clientes no mesmo appliance TR7. O Cliente A e o Cliente B usam os mesmos blocos de IP. Cada cliente é isolado em sua própria Route Table do TR7; rotas, DNS, regras de firewall e fluxos de serviço nunca conflitam.
O tráfego de internet é recebido na Route Table da DMZ. Depois que o TR7 aplica o WAAP e as políticas de acesso, o tráfego é encaminhado para o backend na Route Table interna. O plano de IP do backend nunca é exposto ao mundo externo.
Alguns serviços saem pela WAN primária, alguns tenants pela WAN redundante, e alguns serviços de gerenciamento por um link dedicado. O roteamento baseado em política do TR7 seleciona um caminho diferente para cada classe de tráfego.
O TR7 pode aprender rotas dinamicamente de roteadores de borda. Quando novos segmentos de rede são adicionados, as rotas estáticas não precisam mais ser escritas manualmente. A equipe de rede anuncia as rotas e o TR7 usa os caminhos atuais na Route Table relevante.
Se a rede interna existente executa OSPF, o TR7 pode ingressar nessa topologia dentro da Route Table relevante. As redes de serviço internas são aprendidas automaticamente e o gerenciamento de rotas é centralizado.
O gateway primário torna-se inacessível. O monitor de gateway detecta a falha e o tráfego é movido para o gateway alternativo. O operador não precisa fazer mudanças manuais de rota.
Blocos de IP sobrepostos, roteamento dinâmico estático + BGP/OSPF e monitoramento de gateway. Vamos percorrer uma configuração ao vivo na sua própria topologia de rede.