O modelo de roteamento clássico de ADC é inadequado para redes multi-tenant.
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.
Nossa abordagem
O TR7 retira o roteamento de uma tabela global — cada zona de rede vive em sua própria Route Table independente.
Isolamento de Route Table do TR7
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.
Roteamento estático e dinâmico juntos
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.
Roteamento baseado em política
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.
Monitor de gateway e failover automático
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.
Capacidades
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.
Roteamento independente por Route Table
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.
Route Health Injection — o endereço é anunciado apenas enquanto o serviço está saudável
O endereço do serviço é anunciado em BGP ou OSPF apenas enquanto os serviços por trás passam as suas verificações de saúde, e é retirado em segundos quando deixam de passar. Os routers a montante deixam de enviar tráfego para um local que não o consegue servir, sem que ninguém abra um ticket. Só anuncia o nó que realmente detém o endereço — é isso que impede que uma comutação de cluster se torne um buraco negro de encaminhamento. O BFD baixa a deteção de falha para menos de um segundo.
Gerenciamento de rotas estáticas
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.
Suporte a gateway-on-link
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.
Infraestrutura de protocolo de roteamento dinâmico
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. O encaminhamento dinâmico é indicado por família de endereços, porque são dois protocolos e não um: o OSPFv2 leva IPv4 e o OSPFv3 leva IPv6, por isso uma rede dual-stack não fica sem encaminhamento a meio da sua migração para IPv6.
Vizinhos em formulários; a configuração em bruto e a consola continuam suas
Os vizinhos BGP e as áreas OSPF definem-se na interface sob a forma de formulários — endereço do router, números de AS, autenticação, uma caixa BFD que baixa a deteção de falha para menos de um segundo e um interruptor «anunciar este endereço» que liga o Route Health Injection — e a TR7 gera a partir deles a configuração de encaminhamento. O trabalho profundo de protocolo não fica fechado: um campo de configuração em bruto é acrescentado ao que a TR7 gera e nunca é sobrescrito, e a consola de protocolo permanece para ler estado e depurar na linguagem do protocolo.
Roteamento baseado em política
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.
Monitor de gateway
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.
Failover de gateway padrão
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.
Distribuição de carga por próximo salto (NHLD)
O tráfego de saída é distribuído por vários gateways superiores, com acompanhamento de integridade por enlace. Um enlace com falha é retirado em segundos, e a marcação de conexões mantém um fluxo estabelecido no enlace em que começou, de modo que o tráfego de retorno permanece simétrico e os dispositivos com estado à frente nunca veem metade de uma conversa. Esta é a resposta multi-WAN para sites com dois ou mais provedores de internet.
Delta route sync
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.
Suporte a rotas IPv4 e IPv6
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.
DNS e gerenciamento de hosts por 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.
Comportamento de rota com reconhecimento de cluster
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.
Fluxo de serviço cross-Route-Table via vService
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.
Roteamento híbrido estático + dinâmico
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.
Profundidade operacional
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.
Modelo de entrada de rota
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.
Ordenação de aplicação
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.
Limites do monitor de gateway
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.
Ciclo de vida de roteamento dinâmico
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.
Lógica de rollback em falhas de rota
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.
Relacionamento entre Route Table e Firewall
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.
Relacionamento entre Route Table e vService
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.
Definições de vizinhos e áreas sob o mesmo controlo de alterações
As definições de vizinhos e áreas passam pelo mesmo fluxo de validar-e-aplicar do resto da configuração, e cada alteração fica no registo de auditoria com o respetivo autor. O que os formulários não exprimem — filtragem detalhada, route-maps, afinação do protocolo — vai para o campo de configuração em bruto: fica guardado com o objeto e é preservado sempre que a configuração é regerada. As equipas que preferem a consola de protocolo continuam a trabalhar exatamente como antes.
vDevices — equipamentos virtuais ao nível do hardware dentro de um chassis
Uma Route Table isola o encaminhamento. Um vDevice vai mais longe e isola o equipamento inteiro: cada um possui as suas interfaces, a sua firewall, as suas tabelas de rotas, o seu próprio conjunto de proteção L4 DDoS e o seu próprio DNS, e os vDevices são atribuídos por utilizador. Uma tempestade DDoS contra um vDevice é contida por conceção e não por afinação, o que torna um único chassis utilizável como vários equipamentos independentes.
Quando usar
Roteamento multi-tenant em MSP
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.
Trânsito DMZ para backend interno
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.
WAN redundante e roteamento baseado em fonte
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.
Integração BGP com o data center
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.
Adicionar o ADC a uma área OSPF
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.
Failover de gateway padrão
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.
Perguntas frequentes
Dois tenants usando o mesmo bloco de IP podem rodar no mesmo appliance TR7?
Rotas estáticas e dinâmicas podem coexistir na mesma Route Table?
A configuração de BGP e OSPF é feita diretamente pela interface?
Como o monitoramento de gateway funciona e quando o failover é acionado?
Um vService pode encaminhar tráfego para um backend em uma Route Table diferente da que escuta?
O isolamento de Route Table requer uma licença adicional?
O tráfego de saída pode ser distribuído por duas linhas de internet ao mesmo tempo?
Roteamento independente por tenant — gerenciado de um único console
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.