A IA está transformando a forma como trabalhamos pode impulsionar nossa produtividade quando utilizada de forma eficaz. Nesse vídeo produzido pelo time HPE Networking são abordados os seguintes tópicos:
Aproveitar a IA como consultor e assistente para gerenciar, automatizar e solucionar problemas da sua rede;
Aplicar técnicas de engenharia de prompts para interações mais eficazes com IA;
Usar configurações baseadas em modelos para otimizar a implantação;
Realizar pesquisas rápidas e inteligentes em documentação técnica;
Solucionar problemas de rede simples e complexos com a assistência da IA;
Gerar scripts em Python dinamicamente com IA;
Comunicar-se com a IA por meio de chamadas REST API para automação avançada.
Eu já escrevi alguns post sobre a atenção que deve ser dada para a integração entre Switches e Roteadores baseados no Cowmare quando há a necessidade de compartilhar o roteamento dinâmico.
Como no exemplo abaixo, podemos ver que por padrão, toda rota estática é atribuída com o valor 60 para a distância administrativa. De forma didática, faço a comparação nas duas saídas do comando “display ip routing-table” da escolha da tabela de Roteamento pela rota aprendida com a menor distância adminstrativa (no primeiro quadro via rota estática e no segundo exemplo via OSPF).
[Switch] ip route-static 192.168.10.0 255.255.255.0 192.168.12.2 [Switch] [Switch] display ip routing-table Routing Tables: Public Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0 127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0 192.168.10.0/24 Static 60 0 192.168.12.2 Eth0/0/0 192.168.12.0/30 Direct 0 0 192.168.12.1 Eth0/0/0 192.168.12.1/32 Direct 0 0 127.0.0.1 InLoop0
Com a rota aprendida dinâmicamente via OSPF (e a estática ainda configurada), percebam que o roteador insere apenas a rota com a menor distância administrativa (valor 10 para o OSPF).
[Switch]display ip routing-table Routing Tables: Public Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0 127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0 192.168.10.0/24 OSPF 10 2 192.168.12.2 Eth0/0/0 192.168.12.0/30 Direct 0 0 192.168.12.1 Eth0/0/0 192.168.12.1/32 Direct 0 0 127.0.0.1 InLoop0
Apesar da rota aprendida dinâmicamente “tomar” o lugar da rota estática e possuir o mesmo next-hop (no caso 192.168.12.2, interface Eth0/0/0), em redes mais complexas, o roteamento poderia escolher um caminho menos desejado pelo administrador de rede, visto que em equipamentos de outros fabricantes as rotas estáticas são atribuídas com a distâncias administrativa 1 ( e isso pode passar desapercebido ).
O comando “ip route-static default-preference 1” ajuda aqueles que estão acostumados a trabalhar com ambos roteamento dinâmico e estático, permitindo que as novas rotas configuradas possuam a distância adminstrativa 1 (nesse caso, melhor que todos os protocolos de Roteamento Dinâmico).
[Switch] ip route-static default-preference 1
Caso você prefira escolher manualmente o peso que cada rota terá, basta adicionar o “preference” no final de cada rota.
[Switch] ip route-static 192.168.20.0 255.255.255.0 192.168.12.2 preference ? INTEGER Preference value range
Diferente da agregação de links com Brige-Aggregation (Link Aggregation ou EtherChannel), que opera na camada 2 (enlace de dados), o Route-Aggregation atua na camada 3 (rede). Ela permite combinar múltiplas interfaces físicas em uma única interface lógica, configurar endereço IP, limitar o dominio de broadcast na interface, aumentar a capacidade de transmissão e fornecer redundância em interfaces no modo routed.
Conceitos Chave:
Interface Route Aggregation: A interface virtual que representa o conjunto de interfaces físicas agregadas.
Interfaces Membro: As interfaces físicas que compõem o grupo de agregação.
Modos de Operação: Algoritmos que determinam como o tráfego é distribuído entre as interfaces membro.
Como Configurar Agregação de Rotas no Comware:
A configuração envolve os seguintes passos:
Crie a Interface Route Aggregation:
[Sysname] interface Route-Aggregation <número>
Substitua <número> por um identificador único para a interface.
Escolha o Modo de Operação (Recomendado):
hash: Distribui o tráfego usando um hash dos endereços IP de origem e destino, oferecendo um bom balanceamento de carga na maioria dos casos.
load-share: Distribui o tráfego de forma mais uniforme, independentemente dos endereços IP.
Diferenças entre Bridge Aggregation e Route Aggregation:
Característica
Bridge Aggregation
Route Aggregation
Camada de Operação
Camada 2
Camada 3
Tipo de Tráfego
Ethernet
IP
Endereçamento
Não necessário nas interfaces membro
Necessário na interface Route Aggregation
Função Principal
Largura de banda e redundância entre switches
Largura de banda e redundância entre roteadores
Observações Importantes:
As interfaces membro devem ter a mesma velocidade e configuração duplex.
A configuração deve ser consistente em ambos os lados da conexão.
Consulte a documentação específica do seu equipamento Comware para detalhes adicionais e configurações avançadas. Implementar a agregação de rotas pode melhorar significativamente o desempenho e a resiliência da sua rede.
No mundo conectado de hoje, onde dados, voz e vídeo convergem nas redes corporativas, a alta disponibilidade é crucial para o sucesso dos negócios. Uma rede local (LAN) bem projetada é a base para garantir essa disponibilidade. E uma das melhores maneiras de construir uma LAN robusta e eficiente é adotar um design hierárquico.
Por que um design hierárquico?
Imagine sua rede como um prédio com andares bem definidos. Cada andar tem uma função específica, o que facilita a organização e o gerenciamento. O design hierárquico funciona da mesma forma, dividindo a rede em camadas distintas. Isso traz diversas vantagens:
Gerenciamento Simplificado: Com uma estrutura organizada, fica mais fácil monitorar, configurar e manter a rede.
Escalabilidade: Expandir a rede se torna mais simples, pois novas camadas podem ser adicionadas conforme a necessidade, sem afetar a estrutura existente.
Troubleshooting Eficaz: A divisão em camadas facilita a identificação e resolução de problemas, agilizando o diagnóstico e minimizando o tempo de inatividade.
Um design hierárquico é a chave para uma LAN eficiente, escalável e fácil de gerenciar, garantindo a alta disponibilidade que sua empresa precisa.
Para o estabelecimento de uma adjacência no OSPF os Roteadores vizinhos devem se reconhecer para trocarem informações, encaminhando e recebendo mensagens Hello nas Interfaces participantes do OSPF; no endereço de Multicast 224.0.0.5.
Durante estabelecimento da Adjacência, serão trocadas informações dos Roteadores da Rede como a informação da área, prioridade dos Roteadores, etc. Após a sincronizarem as informações, os Roteadores da área terão a mesma visão da Topologia e rodarão o algoritmo SPF para escolha do melhor caminho para chegar ao Destino.
Os Roteadores (já) Adjacentes encaminharão mensagens Hellos ( verificação da disponibilidade), mensagens LSA com as atualizações da rede e mensagens a cada 30 minutos de refresh de cada LSA para certificar que os a tabela OSPF (LSDB) esteja sincronizada.
Durante a falha de um Link, a informação é inundada (flooded) para todos os Roteadores Adjacentes da Área.
Em ambientes Multiacesso como redes Ethernet, os Roteadores OSPF elegem um Roteador Designado (DR) para formar Adjacência e encaminhar os LSA’s somente para ele. O Roteador DR reencaminha os updates recebidos por um vizinho para os outros Roteadores na mesma LAN.
Há também a eleição de um Roteador Desingnado de Backup (BDR) para assumir em caso de falha do DR.
O método de eleição do DR e BDR é bastante efetivo e confiável para estabelecimento de Adjacências e mensagens trocadas para manutenção do OSPF, economizando assim recursos conforme o crescimento da Topologia.
Quando ocorre uma mudança na topologia o Roteador/Switch encaminha uma mensagem em Multicast para o endereço 224.0.0.6 que é destinada a todos Roteadores OSPF DR/BDR.
Após o recebimento do Update, o Roteador DR confirma o recebimento (LSAck) e reencaminha a mensagem para os demais roteadores da rede no endereço de Multicast 224.0.0.5; após o recebimento da atualização todos os roteadores deverão confirmar a mensagem ao Roteador Designado (LSAck), tornando o processo confiável.
Se algum Roteador estiver conectado à outras redes, o processo de flood é repetido!
Obs: O BDR não efetua nenhuma operação enquanto o DR estiver ativo!
Como é feita a eleição do DR e BDR?
Durante o processo de estabelecimento de Adjacência é verificado o campo Priority na troca de mensagens Hello. O Roteador com maior valor é eleito o DR e o Roteador com segundo maior valor é eleito o BDR ( em cada segmento).
O valor default da prioridade de todos os Roteador é 1, no caso de empate, é escolhido o valor do ID do Roteador para desempate. Vence quem tiver o maior valor!
Obs: Se a prioridade for configurada como 0, o dispositivo nunca será um DR ou BDR. Nesse caso ele será classificado com DROther ( não DR e não BDR)
Configurando O valor da prioridade deverá ser configurado na Interface VLAN ou física (Ethernet, GigabitEthernet, etc) dos Switches/Roteadores com o processo de OSPF ativo:
interface Vlan-interface1ip address 192.168.0.26 255.255.255.0ospf dr-priority 3!Configurando a Prioridade para eleição do DR/BDR com o valor 3
Porém….
A prioridade do DR e do BDR não é preemptiva, isto é, para manter a estabilidade da topologia se um dispositivo for eleito como DR e BDR, o mesmo não perderá esse direito até ocorrer algum problema no link ou no dispositivo eleito.
Conforme comando display abaixo em Switches Comware, o Switch configurado com a prioridade 3 perde a eleição (de tornar-se o DR) para dispositivo com a prioridade 4 ( pelo fato de ser inserido na topologia posteriormente a eleição do DR/BR).
[COMWARE]display ospf peer OSPF Process 100 with Router ID 192.168.0.5 Neighbor Brief Information
Area: 0.0.0.0 Router ID Address Pri Dead-Time Interface State
192.168.0.13 192.168.0.13 0 38 Vlan1 Full/DROther 192.168.0.14 192.168.0.14 1 31 Vlan1 Full/DROther 192.168.0.20 192.168.0.20 1 34 Vlan1 Full/DROther 192.168.0.21 192.168.0.21 4 30 Vlan1 Full/DR !Roteador DR com a prioridade 4 192.168.0.26 192.168.0.26 5 31 Vlan1 Full/DROther ! Roteador DROther com a prioridade 5 só será o DR na falha do DR e BDR 192.168.0.33 192.168.0.33 1 32 Vlan1 Full/BDR ! Roteador BDR com a prioridade 1 192.168.0.45 192.168.0.45 1 40 Vlan1 Full/DROther
O Switch com a Prioridade 5, irá tornar-se DR somente após falha no DR e no BDR.
Referencias:
Building Scalable Cisco Internetworks – Diane Teare/Catherine Paquet
A funcionalidade uRPF (Unicast Reverse Path Forwarding) protege a rede contra ataques do tipo spoofing. A técnica de spoofing é utilizada por atacantes que falsificam o endereço IP de origem do pacote para os mais diversos fins.
O uRPF pode impedir esses ataques de spoofing com o endereço de origem. Ele verifica se a interface que recebeu um pacote é a interface de saída na FIB, que corresponde ao endereço de origem do pacote. Caso contrário, a uRPF considera um ataque de falsificação e descarta o pacote.
Lembrando que por padrão, para o encaminhamento de pacotes, o roteador valida apenas o endereço de destino de um pacote IP.
Exemplo
Em um exemplo simples, é como se um roteador com uma interface com o endereço de LAN 192.168.1.0/24 receber um pacote com o endereço de origem 172.16.1.20. Esse endereço não faz parte da rede local.
Modos uRPF
O uRPF possui 2 modos distintos (strict e loose) que podem potencialmente ajudar a reduzir ataques com endereços IP falsificados.
Strict uRPF – Para passar a verificação estrita do uRPF, o endereço de origem de um pacote deve ser correspondente ao endereço de destino da interface de saída da FIB. Em alguns cenários (por exemplo, roteamento assimétrico), o Strict uRPF estrito pode descartar pacotes válidos. O Strict uRPF estrito é frequentemente implantado entre um PE e um CE.
[R2-GigabitEthernet1/0] ip urpf strict
Loose uRPF – Para passar a verificação Loose uRPF, o endereço de origem de um pacote deve corresponder o endereço de destino de uma entrada qualquer da FIB. O Loose uRPF pode evitar descartar pacotes válidos, mas pode deixar passar pacotes de um atacante. O Loose uRPF é frequentemente implementado entre ISPs, especialmente em roteamento assimétrico.
[R2-GigabitEthernet1/0] ip urpf loose
Rota Default
Caso o endereço seja apenas conhecido via rota default, o uRPF continuará bloqueando os endereços. Para permitir os endereços a partir da rota default use o comando “allow-default-route” após a configuração do modo strict ou do loose:
A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.
Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.
Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá…
Habilitando o import e export das VRFs
Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)
RD – Route Distinguisher
Como explicado anteriormente, as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .
O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.
O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.
[R1-vpn-instance-Cliente_A]route-distinguisher ?
STRING ASN:nn or IP_address:nn VPN Route Distinguisher
!
! Configurando a VRF para os clientes A B e C
ip vpn-instance Cliente_A
route-distinguisher 65000:1
!
ip vpn-instance Cliente_B
route-distinguisher 65000:2
!
ip vpn-instance Cliente_C
route-distinguisher 65000:3
Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.
RT – Route-Target ou VPN-target
Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.
O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos).
Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.
Em equipamentos de rede que utilizam o sistema operacional Comware, as portas são classificadas em dois tipos principais: bridge (ponte) e routed (roteada). Essa classificação é crucial para entender como esses dispositivos encaminham o tráfego de rede e como as diferentes interfaces interagem entre si.
O modo Bridge (port link-mode bridge) trabalha da mesma maneira que utilizamos em nossos Switches de acesso, com a configuração de VLAN e atribuição do gateway das estações para o Switch Core ou Roteador.
O modo Route (port link-mode route) permite a atribuição de endereço IP para porta física do Switch e não permite a atribuição de VLAN para aquela interface. A porta não encaminhará BPDU’s e ignorará as mensagens STP recebidas.
Configuração
#
interface GigabitEthernet4/0/1
port link-mode route
ip address 192.168.1.1 255.255.255.0
#
interface GigabitEthernet4/0/2
port link-mode bridge
port link-type access
port access vlan 2
#
O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de tuneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.
O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como o GRE não faz a criptografia, o GRE pode trabalhar em conjunto com IPsec para garantir a integridade das informações quando necessário.
Abaixo podemos observar a representação do encapsulamento de um pacote IP pelo GRE como também a inclusão de um novo cabeçalho.
O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.
Segue abaixo um exemplo de configuração de um túnel GRE para Roteadores com o Comware 7, fechando a adjacência OSPF entre 2 roteadores separados por uma rede MPLS. Nos testes usamos o roteador HP VSR1000.
Tabela de Rotas e tracert do Roteador R2
[R2]disp ip routing-table | inc O
192.168.1.0/24 O_INTRA 10 1563 192.168.13.1 Tun0
<R2>tracert 192.168.13.1
traceroute to 192.168.13.1 (192.168.13.1), 30 hops at most, 52 bytes each packet, press CTRL_C to break
1 192.168.23.2 (192.168.23.2) 0.488 ms 0.523 ms 1.668 ms
2 192.168.13.1 (192.168.13.1) 0.962 ms 5.463 ms 0.881 ms
<R2>tracert 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops at most, 52 bytes each packet, press CTRL_C to break
1 192.168.1.1 (192.168.1.1) 1.116 ms 2.588 ms 1.731 ms
O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de túneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.
O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como GRE não criptografa as informações que são transmitidas através do túnel, podemos utilizar o GRE em conjunto com IPsec para garantir a integridade das informações.
Abaixo podemos observar a representação de encapsulamento de um pacote IP pelo GRE e a inclusão de um novo cabeçalho.
O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.
Agora você deve estar se perguntando. Em quais situações podemos usar o GRE ? Veja o cenário:
Você em um dia normal como analista de redes e seu gerente de TI te informa que sua empresa acaba de adquirir uma nova filial e eles precisam ter acesso a alguns servidores que estão na rede local do ambiente que você administra. Depois de concluir todo processo de contratação do link e a conectividade com a filial estar finalizada, seu gerente de TI lhe informa que na nova filial utilizará OSPF para declarar as redes locais.
Agora você pensa: como podemos configurar o OSPF nesses roteadores se eles não estão diretamente conectados? Como administrar o processo de roteamento via uma rede gerenciada pela Operadora como por exemplo, com MPLS, que não está emulando um Lan-to-Lan ? É ai que entra o Túnel GRE.
Configuração
Antes de criar o tunnel, certifique-se que a origem e o destino mapeados na Interface Tunnel estejam acessíveis via roteamento. No nosso exemplo, usaremos a Loopback.
Como os roteadores simularão uma conexão ponto-a-ponto, eles irão trocar informações de roteamento através do túnel como se estivessem diretamente conectados.
Por padrão o Comware habilita o protocolo GRE em túneis sem a necessidade de configuração adicional. Caso você precise utilizar uma Interface Tunnel para alguma outra função, segue abaixo algumas possibilidades:
Considerações para a utilização de Tunnel em Switches HP baseados no Comware
A utilização de interface Tunnel em Switches HP baseados no Comware pode ser um pouco mais complicada que em roteadores. Antes de utilizarmos o processo acima é necessário criar uma configuração de “Service Loopback” (em alguns modelos de Switches), vincular à uma porta não utilizada (vazia) e também vincular o serviço ao Tunnel. Segue abaixo os passos:
• Crie um “tunnel-type service loopback group’.
• Adicione uma porta não utilizada ao “Service loopback group”.
# Criando o “Service-loopback” group 1 e especificando o tipo como tunnel.
[SwitchA] service-loopback group 1 type tunnel
# Vinculando a porta Giga 1/0/3 para o “Service-loopback” group 1.
#Desabilite o STP e o LLDP da interface.
[SwitchA] interface GigabitEthernet 1/0/3
[SwitchA-GigabitEthernet1/0/3] undo stp enable
[SwitchA-GigabitEthernet1/0/3] undo lldp enable
[SwitchA-GigabitEthernet1/0/3] port service-loopback group 1
[SwitchA-GigabitEthernet1/0/3] quit
# Aplique o “Service-loopback” group 1 à interface tunnel.
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] service-loopback-group 1
[SwitchA-Tunnel0] quit
# O tunnel ficará up mesmo que a outra ponta não esteja configurada
COMUTADORES 