Roteador HSR / MSR

Comware 7: Configurando o Route-Aggregation

Diego DiasLeave a comment

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:

  1. Crie a Interface Route Aggregation:
  2. [Sysname] interface Route-Aggregation <número>

Substitua <número> por um identificador único para a interface.

  1. 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.

Exemplos:

[Sysname-Route-Aggregation<número>] aggregation mode hash

ou

[Sysname-Route-Aggregation<número>] aggregation mode load-share

  1. Adicione as Interfaces Membro:

Em cada interface física a ser incluída na agregação:

[Sysname-GigabitEthernet<número>] port link-mode route

[Sysname-GigabitEthernet<número>] aggregation <número da Route-Aggregation>

port link-mode route configura a interface para operar na camada 3.

  1. Configure o Endereçamento IP na Interface Route Aggregation:

Atribua um endereço IP à interface lógica:

[Sysname-Route-Aggregation<número>] ip address <endereço IP> <máscara de sub-rede>

Exemplo Prático:

Agregando GigabitEthernet1/0/1 e GigabitEthernet1/0/2 na Route-Aggregation 1 usando o modo hash:

[Sysname] interface Route-Aggregation 1

[Sysname-Route-Aggregation1] aggregation mode hash

[Sysname-Route-Aggregation1] ip address 192.168.1.1 255.255.255.0

[Sysname] interface GigabitEthernet1/0/1

[Sysname-GigabitEthernet1/0/1] port link-mode route

[Sysname-GigabitEthernet1/0/1] aggregation 1

[Sysname] interface GigabitEthernet1/0/2

[Sysname-GigabitEthernet1/0/2] port link-mode route

[Sysname-GigabitEthernet1/0/2] aggregation 1

Dependendo da versão do Comware a configuração pode ser como o modelo abaixo

[Router]interface route-aggregation 1

link-aggregation mode dynamic

! Habilitando a formação do Route-Aggregation via LACP

ip address 192.168.1.1 255.255.255.0

! Atribuindo um endereço IP a Interface

quit

!

# Configurando as portas para participarem do Route-Aggregation

interface Gigabitethernet 3/0/1

port link-aggregation group 1

quit

interface Gigabitethernet 3/0/2

port link-aggregation group 1

quit

Verificação:

Use display route-aggregation <número> para monitorar o status da agregação.

Para visualizar se a agregação de portas foi executada corretamente, utilize o comando display link-aggregation summary

[Router] display link-aggregation summary

Aggregation Interface Type:

BAGG — Bridge-Aggregation, RAGG — Route-Aggregation

Aggregation Mode: S — Static, D — Dynamic

Loadsharing Type: Shar — Loadsharing, NonS — Non-Loadsharing

Actor System ID: 0x8000, 000f-e2ff-0001

AGG         AGG       Partner ID               Select Unselect   Share

Interface   Mode                               Ports  Ports      Type

———————————————————————

RAGG1       D         0x8000, 000f-e2ff-00aa   2      0          Shar

Diferenças entre Bridge Aggregation e Route Aggregation:

CaracterísticaBridge AggregationRoute Aggregation
Camada de OperaçãoCamada 2Camada 3
Tipo de TráfegoEthernetIP
EndereçamentoNão necessário nas interfaces membroNecessário na interface Route Aggregation
Função PrincipalLargura de banda e redundância entre switchesLargura 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.

Comware: OSPF – Roteador Designado (DR) e Roteador Designado de Backup (BDR)

Diego DiasLeave a comment

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-interface1
ip address 192.168.0.26 255.255.255.0
ospf 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

Duvidas? Deixe um comentário!

Um grande abraço

Comware7: uRPF

Diego DiasLeave a comment

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.

[R2-GigabitEthernet1/0] ip urpf ?
  loose   Don't check interface
  strict  Check interface
  • 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:

[R2-GigabitEthernet1/0]ip urpf strict allow-default-route

É possível validar o descarte de pacotes através do debug ip urpf

<R2> debug ip urpf
*Jan  2 12:21:11:074 2019 R2 URPF/7/debug_info:
uRPF  URPF-Discard: Packet from 10.12.0.27 via GigabitEthernet2/0
*Jan  2 12:21:11:074 2019 R2 URPF/7/debug_info:
uRPF  URPF-Discard: Packet from 10.12.0.27 via GigabitEthernet2/0

Até logo!

Comware 7 – Configurando o GRE

Diego DiasLeave a comment

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

Comware 5: Protocolo de Tunelamento GRE

Diego DiasLeave a comment

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:

[RA-Tunnel10]tunnel-protocol ?
  dvpn       Dynamic Virtual Private Network
  gre        Generic Routing Encapsulation
  ipsec      IPsec tunnel encapsulation
  ipv4-ipv4  tunnel mode ipv4 over ipv4
  ipv4-ipv6  tunnel mode ipv4 over ipv6
  ipv6-ipv4  tunnel mode ipv6 over(to) ipv4
  ipv6-ipv6  tunnel mode ipv6 over ipv6
  mpls       Multiprotocol Label Switching

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

Até a próxima

Comware 7: OSPF Virtual Link

Diego DiasLeave a comment

O desenho de uma rede OSPF requer que todas as áreas estejam diretamente conectadas à Area Backbone (Area 0 [zero]) e que os roteadores da Area 0 estejam sempre conectados com roteadores da mesma área.

Para conexão entre roteadores de diferentes áreas, o tráfego deve passar sempre pela Area 0.

Um virtual link é um link lógico que permite a conexão entre equipamentos da Area 0 que estão separados logicamente mas podem utilizar uma outra Area OSPF como trânsito, ou entre áreas não-Backbone que precisam utilizar outra área como transito:

O OSPF virtual link deve ser usado somente em casos específicos, conexões temporárias ou cenários de backup em caso de falha.

Configurando OSPF Virtual link

No exemplo abaixo, o virtual link servirá na conexão entre dois roteadores da Area 0 que estão separados por uma falha no link.

R1
#
ospf 1
  area 0.0.0.0
  network 192.168.1.0 0.0.0.255
  network 192.168.11.0 0.0.0.255
 area 0.0.0.1
  network 192.168.12.0 0.0.0.255
  vlink-peer 192.168.3.3
#
R3
#
ospf 1
 area 0.0.0.0
  network 192.168.3.0 0.0.0.255
  network 192.168.33.0 0.0.0.255
 area 0.0.0.1
  network 192.168.23.0 0.0.0.255
  vlink-peer 192.168.1.1
#

Comandos display

[R1]display  ospf vlink
         OSPF Process 1 with Router ID 192.168.1.1
                 Virtual Links
 Virtual-link Neighbor-ID  -> 192.168.3.3, Neighbor-State: Full
 Interface: 192.168.12.1 (GigabitEthernet0/0)
 Cost: 2  State: P-2-P  Type: Virtual
 Transit Area: 0.0.0.1
 Timers: Hello 10, Dead 40, Retransmit 5, Transmit Delay 1

#
 [R1]display ospf peer
         OSPF Process 1 with Router ID 192.168.1.1
               Neighbor Brief Information
 Area: 0.0.0.1
 Router ID       Address         Pri Dead-Time  State             Interface
 192.168.12.2    192.168.12.2    1   35         Full/DR           GE0/0
 Virtual link:
 Router ID       Address         Pri Dead-Time  State             Interface
 192.168.3.3     192.168.23.3    1   36         Full              GE0/0

Até breve

Comware 7: VRF (VPN-Instance)

Diego DiasLeave a comment

A utilização de VRF (Virtual Routing and Forwarding) permite a criação de tabelas de roteamentos virtuais em Switches e Roteadores, independentes da tabela de roteamento “normal”(geralmente chamada de tabela de roteamento global [Global Routing Table]).

Da mesma forma como a utilização de VLANs em Switches Ethernet permitem a divisão de dominios de broadcasts e mapeamentos da tabela MAC, a utilização de VRF permite a virtualização da tabela de roteamento. Nos Switches e Roteadores utilizando o Sistema Operacional Comware (3Com, H3C e HP) a feature é chamada de “vpn-instance“.

Comware: VRF (vpn-instance)

Diego DiasLeave a comment

A utilização de VRF (Virtual Routing and Forwarding) permite a criação de tabelas de roteamentos virtuais em Switches e Roteadores; independentes da tabela de roteamento “normal”(geralmente chamada de tabela de roteamento global [Global Routing Table]).

Da mesma forma como a utilização de VLANs em Switches Ethernet permitem a divisão de dominios de broadcasts e mapeamentos da tabela MAC, a utilização de VRF permite a virtualização da tabela de roteamento. Nos Switches e Roteadores utilizando o Sistema Operacional Comware (3Com, H3C e HPN) a feature é chamada de “vpn-instance“.

Apesar da tecnologia VRF ter a sua função vinculada às redes MPLS (por ser largamente utilizado em Provedores e Data Centers) há a possibilidade de criar tabelas de roteamento apenas para funções locais do Roteador, chamado de VRF-lite ou também Multi-VRF.

Você pode ser perguntar: “Mas por qual razão eu precisaria configurar outra tabela de roteamento em meu roteador?” Geralmente as empresas que prestam serviços de TI, monitoração de redes e serviços, “operadoras de links”, etc; precisam lidar com clientes que usam em sua maioria endereços da RFC1918 (endereços IPv4 privados) o que aumenta a probabilidade de mais de um cliente possuir endereços de rede IPv4 iguais (além do fator de segurança ) e a complexidade da divisão das redes usando NAT e ACL; a utilização de VRFs possibilita a independência das tabelas de roteamento, permitindo que uma tabela de rotas não possua roteamento com as outras (por padrão).

Segue abaixo o exemplo da configuração do cenário acima:

# Criando as VRFs (vpn-instance)
ip vpn-instance ABC
! criando a VRF chamada “ABC”
 route-distinguisher 1:1
! configurando o RD
#
ip vpn-instance XYZ
 route-distinguisher 2:2
#

Obs: a configuração do Route-distinguisher (RD) permite a extensão do endereço IPv4 para diferenciação, chamado de VPNv4. Os endereços VPNv4 são a combinação de endereços IPv4(32 bit) e o valor Route-distinguiser (64 bit).

# Com as VLANs criadas atribua a vpn-instance a interface VLAN
vlan 1
#
vlan 2 to 5
#
interface Vlan-interface2
 ip binding vpn-instance ABC
! vinculando a VRF à interface VLAN
 ip address 192.168.1.1 255.255.255.0
#
interface Vlan-interface3
 ip binding vpn-instance ABC
 ip address 192.168.2.1 255.255.255.0
#
interface Vlan-interface4
 ip binding vpn-instance XYZ
 ip address 192.168.1.1 255.255.255.0
#
interface Vlan-interface5
 ip binding vpn-instance XYZ
 ip address 192.168.2.1 255.255.255.0
#
#  A configuração poderá ser atribuída a Switches e Roteadores, 
#  inclusive em interfaces em modo Routed.

Validando as vpn-instance criadas…

  display ip vpn-instance
  Total VPN-Instances configured : 2
  VPN-Instance Name               RD                     Create time
  ABC                             1:1                    2013/10/20 18:35:42
  XYZ                             2:2                    2013/10/20 18:36:04

Verificando as tabelas de roteamento da VRF e a tabela de roteamento global.

[SW1]display ip routing-table
Routing Tables: Public
        Destinations : 2        Routes : 2
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
! Na tabela global há somente o endereço de loopback 127.0.0.1
!
[SW1]display ip routing-table vpn-instance ABC
Routing Tables: ABC
        Destinations : 6        Routes : 6
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.1.0/24      Direct 0    0            192.168.1.1     Vlan2
192.168.1.1/32      Direct 0    0            127.0.0.1       InLoop0
192.168.2.0/24      Direct 0    0            192.168.2.1     Vlan3
192.168.2.1/32      Direct 0    0            127.0.0.1       InLoop0
! Rotas da VRF ABC
!
[SW1]display  ip routing-table  vpn-instance XYZ
Routing Tables: XYZ
        Destinations : 6        Routes : 6

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.1.0/24      Direct 0    0            192.168.1.1     Vlan4
192.168.1.1/32      Direct 0    0            127.0.0.1       InLoop0
192.168.2.0/24      Direct 0    0            192.168.2.1     Vlan5
192.168.2.1/32      Direct 0    0            127.0.0.1       InLoop0
! Rotas da VRF XYZ

Além do Roteamento para as interfaces diretamente conectadas é possível tambem separa as rotas estaticas e protocolos de Roteamento em processos independente para cada vpn-instance

# Exemplo de configuração de rota estatica por VRF
ip route-static vpn-instance ABC 0.0.0.0 0.0.0.0  192.168.1.254
ip route-static vpn-instance XYZ 0.0.0.0 0.0.0.0  192.168.1.100
# Criação de processos individuais do OSPF por VRF
[SW1]ospf 10 vpn-instance ?
  STRING  VPN Routing/Forwarding Instance (VRF) Name

Dica : Sempre configure o endereço IP após atribuir uma vpn-instance à uma interface, pois o dispositivo irá remover a configuração IP da interface.

[Router-LoopBack0]ip binding vpn-instance TESTE
 All IP related configurations on this interface are removed!

Nos equipamentos baseados no Comware a configuração do RD é obrigatória na criação da VRF!

Comware 7 : Configurando PBR (Policy-Based Routing)

Diego DiasLeave a comment

A maneira como efetuamos o roteamento de pacotes baseado endereço de destino do cabeçalho IP  possui algumas restrições que não permitem o balanceamento de tráfego de maneira granular de acordo com perfis das aplicações, dessa forma todos os pacotes são roteados para o mesmo lugar sem levarmos em conta a rede de origem, protocolo, etc.

A utilização de PBR, policy-based routing, permite ao engenheiro de rede a habilidade de alterar o comportamento padrão de roteamento baseando-se em diferentes critérios ao invés de somente a rede de destino, incluindo o endereço de rede de origem, endereços TCP/UDP de origem e/ou destino, tamanho do pacote, pacotes classificados com fins de QoS, etc.

Mas por qual razão utilizaremos PBR ?

O PBR pode ser utilizado em diversos cenários, para os mais diversos fins. No exemplo abaixo a rede 192.168.1.0/24 acessa a rede 172.16.0.1 com uma rota default configurada para o Link A, imaginando que uma segunda demanda surge para que a rede de homologação 192.168.2.0/24 acesse assim a Internet pelo Link A mas já o acesso para rede 172.16.0.1, deva ocorrer preferivelmente pelo link B. Nesse caso o PBR entraria para corrigir essa questão (lembrando que na tabela de roteamento o acesso para rede 172.16.0.1 é apontado para o Link A, criaríamos uma exceção somente para a nova rede).

Segue exemplo da configuração:

#
acl number 2000
 rule 0 permit source 192.168.2.0 0.0.0.255
! ACL para match na rede 192.168.2.0
#
policy-based-route XYZ permit node 10
 if-match acl 2000
 apply next-hop 192.168.223.3
! PBR dando match na ACL 2000 e encaminhar o 
! tráfego para o next-hop do link B
#
#
interface GigabitEthernet0/0/3
 port link-mode route
 ip address 192.168.12.2 255.255.255.0
 ip policy-based-route XYZ
! Aplicando o PBR na interface Giga0/0/3
#

A implementação da PBR é bastante simples, ele é definido para ser configurado usando o processo policy-based routing que é muito similar a configuração de uma route-policy (route-map) . O tráfego a ser tratado pelo PBR será comparado (match) utilizando uma ACL e em seguida tem o novo destino ou parâmetros alterados usando um comando apply + atributo.

Se o pacote não corresponder à política de PBR ou se o encaminhamento baseado em PBR falhar, o dispositivo utilizará a tabela de roteamento para encaminhar os pacotes.

Outros parametros dentro do PBR

Entre os outros parametros do PBR está o output-interface, default-next-hop e o default-output-interface.

Output-interface: Esse comando permite atribuir a interface de saída do trafego ao invés do IP do next-hop.

Default-next-hop / default-output-interface:Se o processo de roteamento baseado na tabela de rotas falhar, o equipamento utilizará o default next hop ou default output interface definido no PBR para encaminhar os pacotes.

Ao utilizar qualquer combinação destes comandos dentro de um PBR os comandos são avaliados na seguinte ordem:

apply next-hop
apply output-interface
apply default-next-hop
apply default-output-interface

O PBR é uma ferramenta muito poderosa que pode ser usada para controlar os caminhos específicos de tráfego de rede, porém certifique-se de usar apenas PBR quando for necessário. Como muitas outras features oferecidas em qualquer tipo de roteador, elas são projetadas para um conjunto específico de circunstâncias, o mesmo e deve ser utilizado para esses fins para assim manter a eficiência.

Referências

http://blog.pluralsight.com/pbr-policy-based-routing

HP 5920 & 5900 Switch Series- Layer 3 – IP Routing – Configuration Guide

Comware 7: VRRP – Tracking baseado no estado de uma interface física

Diego DiasLeave a comment

O protocolo VRRP funciona para redundância de Gateway em uma rede, com o objetivo de 2 ou mais roteadores compartilharem o mesmo IP virtual no modo ativo/backup (por padrão).

Para os outros dispositivos da rede, o VRRP permite que o gateway seja visualizado como um único equipamento.

O VRRP é bastante simples em sua função básica: um Roteador é eleito o Master e é responsável pelo encaminhamento do tráfego da rede para os equipamentos que tem aquele o IP Virtual como gateway. O segundo roteador chamado de Backup apenas monitora os pacotes VRRP do barramento. Entretanto, quando o equipamento Master deixar de funcionar,  o equipamento Backup assume suas funções como Master.

Os equipamentos configurados com VRRP possuem a sua adminstração de forma individual (Plano de dados e controle separados) e por isso a configuração de rotas e outras features, deverão ser configurada individualmente.

Para um equipamento se eleger como Master é verificado a prioridade (por padrão é 100), vence o roteador que tiver a maior prioridade.

Caso não seja configurada a prioridade do grupo VRRP em um Roteador, o mesmo atribuirá o valor padrão (100) para o equipamento.

Se o endereço IP do Roteador for o mesmo do IP virtual, o equipamento será o MASTER.

Se o Roteador principal falhar, o novo Master será o Roteador Backup com maior prioridade.

VRRP Track

Há também cenários que o roteador Master do VRRP continua ativo, mas  não consegue encaminhar os pacotes devido a interface saída (como para a Internet por exemplo) cair. Podemos  então fazer o track para o processo VRRP monitorar algum objeto, que pode ser o estado da interface( UP ou down), pingar determinado site, teste de conexão telnet e etc; e dessa forma  reduzir a prioridade VRRP baseando-se em uma condição.

No exemplo abaixo, o script demonstrará a redução da prioridade do VRRP do Roteador Master (R2) de forma que quando o link de saída para o Roteador 1 cair, o Roteador Backup (R3) se tornará o Master.

Configuração do VRRP com track

Roteador R2 (Master VRRP)

 
#
track 1 interface GigabitEthernet0/0/3
! Configurando o track para interface Giga0/0/3
#
interface GigabitEthernet0/0/4
 ip address 192.168.32.2 255.255.255.0
 vrrp vrid 32 virtual-ip 192.168.32.1
! configurando o grupo VRRP 32 com o IP virtual
 vrrp vrid 32 priority 115
! configurando a prioridade do grupo 32 como 110
 vrrp vrid 32 track 1 reduced 20
! configurando o track 1 e em caso de falha, ele reduzirá a 
! prioridade do VRRP para 95
#

Roteador R3 (Backup VRRP)

#
interface GigabitEthernet0/0/4
 ip address 192.168.32.3 255.255.255.0
 vrrp vrid 32 virtual-ip 192.168.32.1
#

Validando o Roteador R2 que é o VRRP Master

[R2]display vrrp verbose
IPv4 Virtual Router Information:
 Running Mode      : Standard
 Total number of virtual routers : 1
   Interface GigabitEthernet0/0/4
     VRID           : 32                  Adver Timer  : 100
     Admin Status   : Up                  State        : Master
     Config Pri     : 115                 Running Pri  : 115
     Preempt Mode   : Yes                 Delay Time   : 0
     Auth Type      : None
     Virtual IP     : 192.168.32.1
     Virtual MAC    : 0000-5e00-0120
     Master IP      : 192.168.32.2
   VRRP Track Information:
     Track Object   : 1                   State : Positive   Pri Reduced : 20

Simulando uma falha…

Quando a interface Giga0/0/3 do Roteador R2 falha, o track do VRRP irá identificar a falha e assim reduzir a prioridade do VRRP do Roteador, tornando dessa forma o R3 como Master

! Log do Roteador R2 após a falha na interface Giga0/0/3
%Jul  7 14:37:35:605 2015 R2 VRRP4/6/VRRP_STATUS_CHANGE:
The status of IPv4 virtual router 32 (configured on GigabitEthernet0/0/4) changed from Master to Backup: VRRP packet received.

Output do Roteador R3 após a falha demonstrando a sua eleição como Master

[R3]display vrrp verbose
IPv4 Virtual Router Information:
 Running Mode      : Standard
 Total number of virtual routers : 1
   Interface GigabitEthernet0/0/4
     VRID           : 32                  Adver Timer  : 100
     Admin Status   : Up                  State        : Master
     Config Pri     : 100                 Running Pri  : 100
     Preempt Mode   : Yes                 Delay Time   : 0
     Auth Type      : None
     Virtual IP     : 192.168.32.1
     Virtual MAC    : 0000-5e00-0120
     Master IP      : 192.168.32.3

Por padrão a preempção é ativa nos Roteadores e dessa forma quando a interface Giga 0/0/3 do Roteador R2 voltar ao estado UP, o R2 voltará a ser o Master do VRRP.

Até logo galera.