Um dos problemas mais difíceis em redes corporativas é gerenciar diferentes domínios de rede no mesmo dispositivo com segurança e sem conflitos de endereço. Em ambientes MSP, governo, finanças, saúde e multi-tenant, cada tenant pode trazer seu próprio plano de IP. Reutilizar o mesmo bloco CIDR em diferentes clientes é comum.
A separação de rota clássica geralmente isola apenas a tabela de roteamento. O isolamento verdadeiro, no entanto, requer mais do que rotas — interfaces, ARP, firewall, socket e comportamento de conexão devem ser todos separados. Sem isso, o `10.0.0.5` do Tenant A e o `10.0.0.5` do Tenant B tornam-se operacionalmente e do ponto de vista de segurança arriscados no mesmo dispositivo.
Um segundo problema surge quando os serviços devem permanecer em diferentes domínios de rede. Um VIP deve escutar no lado da DMZ, o backend deve permanecer na rede interna, o tráfego de gerenciamento deve ser confinado à sua própria route table, ou redes antigas e novas devem coexistir durante a migração. Forçar a fusão desses domínios quebra a segmentação de segurança e a ordem operacional.
A abordagem correta é isolar cada domínio de rede dentro de sua própria route table e fornecer cruzamento controlado no nível do vService. Um vService deve ser capaz de escutar em múltiplas route tables e encaminhar tráfego para backends em route tables diferentes.
O Roteamento Cross-NS do TR7 atende a essa necessidade: cria domínios de rede isolados em um único dispositivo, separa planos de IP sobrepostos e transforma o vService em uma ponte de tráfego controlada entre route tables.
O TR7 implementa uma arquitetura de múltiplos domínios de rede por meio de isolamento de route table, roteamento cross-domain, gerenciamento de processo por tabela e ciclo de vida gerenciado pela interface.
Cada route table tem seu próprio roteamento, interfaces, ARP, firewall e namespace de socket. Tenants, zonas de serviço ou ambientes de teste podem, portanto, rodar no mesmo dispositivo sem interferir entre si.
Um único vService pode escutar VIPs em múltiplas route tables e encaminhar tráfego para backends em route tables diferentes. Isso permite a transferência controlada de serviços sem achatar a rede.
O TR7 pode executar um processo separado de monitoramento e gerenciamento de rede para cada route table. Estado do link, endereços IP, rotas, estatísticas e saúde do serviço são coletados independentemente para cada domínio de rede.
Os operadores podem criar, excluir, nomear e configurar DNS e configurações de hosts para route tables. A qual route table uma interface pertence também pode ser alterada no console de gerenciamento.
A Arquitetura Multi-Namespace torna diferentes domínios de rede gerenciáveis em um único ADC — do isolamento de tenant ao roteamento cross-service.
Uma route table do TR7 não é apenas uma lista separada de rotas. Interface, ARP, firewall, socket e comportamento de conexão operam todos de forma independente dentro do domínio. O comportamento de rede de um tenant não pode contaminar o de outro. As equipes de operações gerenciam múltiplos domínios de rede no mesmo dispositivo de forma mais segura e legível.
Em ambientes multi-tenant, diferentes clientes podem usar os mesmos blocos de IP privado. As route tables do TR7 mantêm esses planos de endereço sobrepostos em domínios de rede separados. O `10.0.0.5` do Tenant A e o `10.0.0.5` do Tenant B podem coexistir no mesmo dispositivo com significados distintos. Isso confere às arquiteturas MSP e de nuvem soberana flexibilidade substancial de plano de IP.
O frontend do vService não está limitado a um único domínio de rede. O mesmo serviço pode escutar em diferentes VIPs nas route tables de produção, DMZ, gerenciamento ou tenant. Uma política ou seleção de backend diferente pode se aplicar dependendo de qual route table o cliente chega. Esse modelo simplifica cenários de publicação multi-rede sem duplicar instâncias de serviço.
O TR7 pode receber tráfego chegando em uma route table e encaminhá-lo para um backend em uma route table diferente. O VIP pode permanecer na DMZ enquanto o backend fica na rede interna; a rede de tenant pode permanecer separada enquanto a rede de serviço compartilhado fica em sua própria route table. Apenas fluxos de serviço permitidos passam pelo TR7 — as redes nunca são fundidas. A segmentação é preservada enquanto o acesso à aplicação é simplificado.
A qual route table uma interface física ou virtual pertence pode ser gerenciada pelo TR7. Isso é prático durante migração, movimentação de tenants ou transições de teste para produção. O impacto nas rotas, IPs e serviços ao mover uma interface deve ser avaliado na totalidade. As equipes de operações não precisam tratar domínios de rede como estruturas estáticas e imovíveis.
Um par V-ETH(peer) pode ser usado para criar uma conexão virtual controlada entre duas route tables diferentes. Isso é valioso quando apenas caminhos de tráfego específicos e definidos precisam cruzar entre domínios que de outra forma seriam totalmente isolados. Aplicável a testes, migração, compartilhamento de serviços e acesso a serviços compartilhados de tenant. A conexão ainda é governada pelas políticas e regras de firewall do TR7.
Cada route table pode operar com suas próprias configurações de DNS e hosts. O mesmo hostname pode resolver para um IP diferente em diferentes route tables de tenant, ou um ambiente de teste pode usar resolução de nomes diferente da produção. Essa separação reduz conflitos de hostname em ambientes multi-tenant e cenários de migração. Os operadores gerenciam o comportamento de DNS no nível de domínio de rede, não globalmente.
Cada route table dinâmica pode executar seu próprio processo de roteamento. O comportamento de roteamento dinâmico BGP, OSPF ou similar pode ser isolado por tenant ou domínio de rede. Uma mudança de rota no domínio de um tenant não afeta o plano de roteamento de outro tenant. Isso é uma vantagem significativa de segurança e operacional em arquiteturas MSP e enterprise multi-região.
O TR7 pode aplicar gerenciamento de firewall separado para cada route table. Regras, ipsets e permissões de tráfego operam dentro do domínio de rede relevante. Uma porta aberta ou permissão concedida para um tenant não é automaticamente propagada para os serviços de outro tenant. As equipes de segurança podem definir o escopo de política com mais precisão.
Estatísticas de link, IP, rota e tráfego podem ser coletadas separadamente para cada route table. As equipes de operações podem ver qual link, IP ou rota está causando um problema em qual domínio de rede de forma isolada. Essa visibilidade reduz o tempo de resolução de problemas em ambientes multi-domínio. Ambientes rodando em um único dispositivo são monitorados em visões claramente separadas.
Uma verificação de saúde pode verificar não apenas se o backend está ativo, mas também se ele é acessível a partir da route table relevante. Uma verificação emitida do domínio de rede frontend para um backend em uma route table diferente percorre o caminho de tráfego real — validando rota, ARP e travessia de firewall, não apenas a disponibilidade do serviço. Isso entrega confiança operacional crítica em configurações de roteamento cross-network.
O comportamento multi-route-table é uma parte nativa da arquitetura de rede do TR7. Os operadores não precisam provisionar um dispositivo virtual separado por tenant. Isolamento, roteamento e handoff de serviço no mesmo ADC permanecem todos dentro de um único plano de gerenciamento. Isso reduz tanto o consumo de recursos quanto a complexidade operacional.
A arquitetura multi-route-table é operada com gerenciamento completo de ciclo de vida, migração de interfaces, recuperação de processos, DNS/hosts por tabela e coordenação de estado cross-domain.
Quando um operador cria uma nova route table, o TR7 prepara um contexto de execução separado para esse domínio de rede. Esse domínio carrega seu próprio comportamento de interface, rota e firewall. Os campos de nome e descrição ajudam as equipes de operações a distinguir tenants ou zonas de serviço entre si.
Excluir uma route table que ainda tem interfaces atribuídas a ela é tratado como inseguro. O comportamento padrão bloqueia a exclusão até que as interfaces sejam migradas. Se necessário, as interfaces podem ser devolvidas primeiro ao domínio padrão, tornando a exclusão controlada e explícita.
Se o processo de monitoramento e gerenciamento executando para uma route table terminar inesperadamente, ele pode ser reiniciado automaticamente. Isso preserva a continuidade do comportamento de monitoramento multi-domínio. As equipes de operações não perdem permanentemente a visibilidade de um domínio de rede por causa de uma única falha de processo.
Quando uma interface é movida de uma route table para outra, o impacto em IPs, rotas, serviços e regras de firewall deve ser avaliado em conjunto. A operação é poderosa para fins de migração, mas deve ser planejada em ambientes de produção. O TR7 torna esse comportamento visível na interface, reduzindo o risco de movimentações não intencionais.
Mensagens baseadas em eventos podem ser estabelecidas entre o processo de gerenciamento principal e cada processo de route table. Estado do link, estado de IP, informações GTM e sinais de serviço são entregues separadamente a cada domínio de rede. Isso fornece coordenação controlada entre o gerenciamento global e os domínios de rede isolados.
Um valor de índice pode ser atribuído a cada route table. Esse índice é usado para derivar portas de roteamento dinâmico, deslocamentos de ID de roteador virtual e identificadores de processo auxiliar por serviço. Conflitos de porta e identidade em múltiplos domínios de rede são assim reduzidos.
Um MSP pode executar múltiplos clientes que usam todos o bloco de endereço `10.0.0.0/8` em um único TR7 ADC, cada um em sua própria route table. Cada tenant permanece isolado em seu próprio domínio de rede sem nenhum conflito de IP.
As organizações podem manter o VIP escutando na route table da DMZ enquanto o backend permanece na route table interna. O TR7 transporta apenas o tráfego de serviço permitido entre os dois domínios — sem fundi-los.
Quando um serviço está sendo movido de uma rede de tenant antiga para uma nova route table, o tráfego do vService pode ser redirecionado de forma controlada. O plano de IP e o acesso ao serviço são gerenciados juntos ao longo da migração.
Uma route table de teste pode rodar com configurações semelhantes à produção, mas não tem acesso direto ao tráfego de produção. A equipe de operações pode testar serviços específicos por meio de roteamento cross-route-table quando necessário, preservando o isolamento.
Planos de IP sobrepostos, roteamento DMZ-para-rede-interna e arquitetura de route table multi-tenant. Vamos percorrer uma configuração ao vivo no seu próprio ambiente.