Comware: Laboratório para configuração de VRRP no HP Network Simulator

Galera, montei um laboratório de VRRP no Simulador HP para o Comware 7 com o objetivo de validar a sintaxe dos comandos, além de testar o protocolo conforme cenário abaixo..

Para aqueles que não conhecem o VRRP, o protocolo 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 ou ativo/ativo. O padrão do protocolo é o ativo(Master)/backup.

Segue a configuração do VRRP nos Roteadores R1 e R2 além da configuração do Switch.

# Switch
vlan 2
#
interface GigabitEthernet1/0/2
port link-mode bridge
port access vlan 2
#
interface GigabitEthernet1/0/3
port link-mode bridge
port access vlan 2
#
Roteador - R1
interface GigabitEthernet 0/0/2
port link-mode route
ip add 192.168.1.2 255.255.255.0
vrrp vrid 1 virtual-ip 192.168.1.1
vrrp vrid 1 priority 110

Roteador - R2
interface GigabitEthernet 0/0/2
port link-mode route
ip add 192.168.1.3 255.255.255.0
vrrp vrid 1 virtual-ip 192.168.1.1

Os comandos display vrrp e display vrrp verbose executados nos roteadores exibem valiosas informações sobre o status do VRRP.

Os comandos são identicos para a versão 5 do Comware.

Até logo.

Comware: Rota estática flutuante (floating static route)

Uma rota estática flutuante é uma rota estática com uma distância administrativa maior do que a estabelecida por padrão em Switches e Roteadores. Por exemplo, no Comware da HP as rotas estáticas possuem distância administrativa com o valor 60 e o protocolo OSPF com as rotas externas com o valor 150, nesse caso pelo fato da menor distância administrativa ser escolhida quando duas rotas idênticas são aprendidas de maneiras distintas pelo roteador, o equipamento escolherá o processo com menor AD ( administative distance/ distancia administrativa).

Como exemplo, poderíamos imaginar um roteador com 2 links, em um deles a rota 192.168.1.0/24 pode ser aprendida via rotas externas OSPF e nesse caso precisaremos encaminhar o tráfego para esse link como principal. Já como backup configuraríamos a rota estática 192.168.1.0/24 com a distância administrativa com o valor 250 apontando para o next-hop do segundo link.

Quando o primeiro link apresentar problemas, o processo OSPF perceberá a falha e removerá a rota 192.168.1.0/24 aprendida dinamicamente e começará a utilizar a rota estática (não utilizada anteriormente) com o mesmo endereço 192.168.1.0/24 configurada para encaminhar os pacotes para o segundo link.

Quando o OSPF voltar a funcionar com o restabelecimento do primeiro link, a rota estática deixará de ser utilizada, voltando para o encaminhamento de pacotes pela rota aprendida dinamicamente.

[Comware]  ip route-static 192.168.1.0 255.255.255.0 172.17.1.2 preference 250

Obs: Lembre-se que a rota estática só entrará na tabela de roteamento se a interface correspondente ao próximo salto (next-hop) estiver UP.

Caso tenham alguma dúvida sobre o assunto, deixem um comentário.

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

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.

Comware: Custo OSPF

O protocolo OSPF permite a todos roteadores em uma área a visão completa da topologia. O protocolo possibilita assim a decisão do caminho mais curto baseado no custo que é atribuído a cada interface, com o algoritmo Dijkstra. O custo de uma rota é a soma do custos de todas as interfaces de saída para um destino. Por padrão, os roteadores calculam o custo OSPF baseado na fórmula Cost =Reference bandwidth value / Link bandwidth.

Caso o valor da “largura de banda de referência” não seja configurado os roteadores usarão o valor de 100Mb para cálculo. Por exemplo, se a interface for 10Mb, calcularemos 100Mb dividido por 10Mb, então o custo da interface será 10. Já os valores fracionados, serão arredondados para valor inteiro mais próximo e toda velocidade maior que 100Mb será atribuido o custo 1.

Veja no exemplo abaixo:

O custo do Roteador R1 para os Roteadores vizinho é 1.

O mesmo para a interface loopback de R2 (o comware não adiciona o custo para as interfaces loopback)

O mesmo para a interface loopback de R2 (o comware não adiciona o custo para as interfaces loopback)

Caso seja necessário alterar a referência para largura de banda utilize o seguinte comando em um roteador HP Comware.

O “bandwidth- reference 100” é o default para 100Mb, onde 100Mb na topologia tem o custo = 1 .

Assim, para ter links 1G com o custo = 1 , o “auto-cost…” deve ser configurado como 1000. Se a referência for links 10G , “auto-cost…” seria 10000 , para 100G, seria 100000 .

Obs: Lembre-se de sempre manter o bandwidth- reference consistente em todos os roteadores para evitar comportamentos inesperados no roteamento.

Até logo

Comware: Route leaking – roteamento estático entre VRFs

A tradução literal para route leaking seria “vazamento de rotas” e esse tipo de configuração permite que determinadas configurações que isolam o roteamento de cada tabela de rotas, como a utilização de VRFs por exemplo, troquem roteamento entre as VRFs (vpn-instance).

Em posts anteriores, publicamos um artigo sobre o roteamento entre VRFs utizando MP-BGP em Switches e Roteadores HP baseados no Comware, mas nesse exemplo, a função é apenas permitir o roteamento entre as vpn-instances para algumas rotas.

Durante a configuração do “route leaking” lembre-se de planejar a configuração de rotas sempre pensando no tráfego bidirecional, isto é, configurando tambem as rotas de retorno.

O Overlapping de subredes nas VRFs pode também ser utilizado, mas requerem configurações de NAT inter-VRF ( ou inter-VPN instance NAT) que somente são suportados em roteadores.

Restrições

As rotas estáticas precisam do endereço do next-hop e há limitação para rotas diretamente conectadas no roteamento inter-VRF.

Para o roteamentro entre VLANs nas VRFs, utilize o MP-BGP.

Somente os roteadores  suportam a configuração de NAT para esse cenário (para os equipamentos baseados no Comware).

Configuração

No exemplo abaixo, o roteador possui duas VRF (vermelha e azul) que necessitam acessar 1 uma rede da outra VRF (lembrando que a utilização de VRFs permite o isolamento das tabelas de roteamento).

#
 ip route-static vpn-instance vermelho 192.168.3.0 24 vpn-instance azul 192.168.23.3
 ip route-static vpn-instance azul 192.168.1.0 24 vpn-instance vermelho 192.168.12.1
#

Obs: lembre-se que o roteamento de retorno tem que estar configurado nos roteadores R1 e R2 do exemplo.

Outra coisa bacana é que também é possível configurar o roteamento de uma VRF para a tabela global de um roteador.

Alterando a distancia administrativa para os protocolos de Roteamento em Switches e Roteadores baseados no Comware

Há alguns posts atrás comentamos sobre a diferença da Distância Administrativa para as rotas aprendidas dinamicamente em Switches e Roteadores dos fabricantes Cisco e HP/H3C/3Com/Intelbras e a atenção que deve ser dada em ambientes com Protocolos de Roteamento que possuem Switches e Roteadores  de ambos fabricantes.

A Distância Administrativa possui apenas função local e não é compartilhada pelo protocolo de roteamento.

Como por exemplo, em um Roteador utilizando o OSPF (como IGP) e o BGP para aprender as “rotas externas”, se uma mesma rota fosse aprendida via OSPF e BGP, o comportamento para escolha do melhor caminho seria diferente em Rotadores Cisco (a distancia administrativa para o OSPF é 110 e o  eBGP é 20) e HPN ( o OSPF é 10 e o eBGP é 255). Lembrando que para prefixos iguais aprendido por diferentes protocolos o Roteador escolhe a rota com menor distância administrativa.

Uma coisa bacana do Comware é poder alterar o valor da distância administrativa  baseado no processo de Roteamento, por exemplo, se tivermos 2 processos OSPF rodando no Router/Switch é possível alterar a distancia administrativa em um dos processos sem afetar o outro ( muito útil quando se utiliza VRFs [ vpn-instance] em um mesmo roteador) .

Para redes que utilizam MP-BGP, tambem é possível alterar a distância administrativa no address-family do cliente.

Veja o exemplo abaixo para a tabela de roteamento Global (eBGP e iBGP com a distância adminstrativa em 255) e a tabela de roteamento da vpn-instance cliente-A (com o eBGP como 7 e o iBGP como 100).

<Router>display ip routing-table
Routing Tables: Public
Destinations : 18177     Routes : 18177

Destination/Mask    Proto  Pre  Cost         NextHop         Interface
0.0.0.0/0           BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.9.0/24      BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.10.0/24     BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.11.0/24     BGP    255  0            10.180.226.197  GE3/1/6.100
<saída omitida>

<Router>display ip routing-table vpn-instance cliente-A
Routing Tables: cliente-A
Destinations : 1789      Routes : 1789
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
1.1.1.1/32          BGP    7    0            192.168.176.217  GE9/1/7
2.2.2.0/29          BGP    7    0            192.168.176.217  GE9/1/7
192.168.80.0/30     BGP    100  0            192.168.229.193  NULL0
10.1.1.1/32         BGP    7    0            192.168.176.217  GE9/1/7
<saída omitida>

Para configurar a distancia administrativa dentro processo BGP ou dentro do processo “ipv4-family vpn-instance [nome da vrf]” no BGP use a sintaxe:

[Router-bgp]preference ?
INTEGER<1-255>  External preference
!Distancia administrativa para rotas aprendidas via eBGP

[Router-bgp]preference 7 ?
INTEGER<1-255>  Internal preference
!Distancia administrativa para rotas aprendidas via iBGP

[Router-bgp]preference 7 100 ?
INTEGER<1-255>  Local preference
!Distancia administrativa para rotas aprendidas via iBGP (locais)

[Router-bgp]preference 7 100 9 

Para o OSPF  utilize o commando preference para alterar a distância administrativa de rotas OSPF e OSPF ASE:

[Router-ospf-1]preference ?
INTEGER<1-255>  Preference value
ase             AS external link states

[Router-ospf-1]preference ase ?
INTEGER<1-255>  Preference value

Até logo!

Comware7: IP Source Guard

A funcionalidade IP Source Guard (IPSG) configurada em Switches impede ataques spoofing na LAN utilizando uma tabela com registros de endereços da rede para comparar os pacotes legítimos. A feature descarta pacotes que não correspondem à tabela de endereços legítimos.

As consultas efetuadas com os endereços legítimos podem conter:

• IP-interface.
• MAC-interface.
• IP-MAC-interface.
• IP-VLAN-interface.
• MAC-VLAN-interface.
• IP-MAC-VLAN-interface.

Os registros consultados pelo IP Source Guard podem ser estáticos ou dinâmicos. Por exemplo, se um host falsifica o endereço IP ou MAC de um host para ataques MITM ou DoS, a feature identificará o frame falsificado e o descartará.

As entradas (bindings) de IPSG estáticas são adequados para cenários onde existem poucos hosts em uma LAN e seus endereços IP são configurados manualmente. Por exemplo, você pode configurar em uma interface que se conecta a um servidor. Esse registro permite que a interface receba pacotes apenas do servidor.

Os registros IPSG estático em uma interface implementam as seguintes funções:

• Filtrar pacotes IPv4 ou IPv6 de entrada na interface.

• Cooperar com a detecção de ataques ARP no IPv4 para verificação de validade do usuário.

Ligações IPSG estáticas são específicas da interface. Uma ligação IPSG estática vincula o endereço IP, MAC, VLAN ou qualquer combinação dos itens na visualização da interface.

Configuração estática

[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] ip verify source ip-address mac-address
[DeviceB-GigabitEthernet1/0/1] ip source binding mac-address 0001-0203-0407
[DeviceB-GigabitEthernet1/0/1] quit
#
[DeviceB] interface gigabitethernet 1/0/2
[DeviceB-GigabitEthernet1/0/2] ip verify source ip-address mac-address
[DeviceB-GigabitEthernet1/0/2] ip source binding ip-address 192.168.0.1 mac-address 0001-0203-0406
[DeviceB-GigabitEthernet1/0/2] quit
# 

Output

[DeviceB] display ip source binding static
Total entries found: 2
IP Address  MAC Address    Interface    VLAN Type
192.168.0.1 0001-0203-0406 GE1/0/2       N/A Static
N/A         0001-0203-0407 GE1/0/1       N/A Static

IPSG com DHCP Snooping

feature DHCP Snooping permite a proteção da rede contra Servidores DHCP não autorizados. O comando dhcp-snooping configurado globalmente, faz o Switch filtrar as mensagens DHCP Offer e DHCP Ack, encaminhadas pelo falso Servidor DHCP. A configuração atribui para todas as portas do Switch como untrusted (não confiável) – sendo necessário a configuração manual do servidor DHCP como trust (confiável).

Uma vez em funcionamento o DHCP Snooping popula uma tabela que contém o endereço IP liberado pelo servidor DHCP com o endereço MAC do host e essa tabela pode ser utilizada pelo IPSG para proteção de ataques spoofing.

As consultas IPSG que forem baseadas no serviço DHCP são adequadas para cenários em que os hosts da rede local obtêm o endereço IP através do DHCP. O IPSG com DHCP Snooping fará apenas a leitura dos endereços fornecidos via DHCP da tabela dhcp-snooping.

Configurando o IPSG com DHCP Snooping

[Device] dhcp snooping enable
#
[Device] interface gigabitethernet 1/0/2
[Device-GigabitEthernet1/0/2] dhcp snooping trust
[Device-GigabitEthernet1/0/2] quit
# 
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] ip verify source ip-address mac-address
# Enable recording of client information in DHCP snooping entries on GigabitEthernet 1/0/1.
[Device-GigabitEthernet1/0/1] dhcp snooping binding record
[Device-GigabitEthernet1/0/1] quit

Output

[Device] display ip source binding dhcp-snooping
Total entries found: 1
IP Address MAC Address Interface VLAN Type
192.168.0.1 0001-0203-0406 GE1/0/1 1 DHCP snooping

Referência

HPE FlexNetwork MSR Router Series – Comware 7 Security Configuration Guide

Comware – Roteamento seletivo entre VRFs com export-map

A utilização de VRFs (Virtual Routing and Forwarding ou vpn-instance na linguagem HP) 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.

Como nós explicamos anteriormente no post http://www.comutadores.com.br/roteamento-entre-vrfs-com-mp-bgp-em-roteadores-hp-h3c/ o rotemento entre VRFs (quando necessário) pode ser efetuado com a manipulação do  route-targets (RT) com o processo MP-BGP ativo no Roteador.

Há também cenários em que é necessário a troca seletiva de prefixos de rede entre as tabelas de roteamento virtuais, escolhendo quais redes devem ser exportardas ou não entre as VRFs. Lembrando que os valores vpn-target (route-target) trabalham com as Extended community do BGP para troca de prefixos entre VRFs,  é possível manipular o processo via route-policy (route-map), configurando a “comunidade estendida” para o prefixo e utilizando o comando export dentro da VRF.

Relembrando…

No diagrama abaixo há 2 VRFs já configuradas (com o processo MP-BGP ativo) e com seus respectivos prefixos.

Como os valores para import/export das VRFs não são os mesmos, não há roteamento entre as VRFs (cada VRF tem o seu roteamento isolado).

 comutadores.com.br
# Roteamento Seletivo entre VRFs (1º exemplo)
!
ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]display ip routing-table vpn-instance Client_A
Routing Tables: Client_A
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.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0

[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
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
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0

No exemplo abaixo, caso manipulassemos o import/export, teríamos as 2 tabelas de roteamento compartilhadas…


# comutadores.com.br
# Roteamento Seletivo entre VRFs (2º exemplo)
!
#
ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 65000:2 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 65000:1 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]display ip routing-table vpn-instance Client_A
Routing Tables: Client_A
Destinations : 8 Routes : 8

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
172.16.1.0/24 BGP 130 0 0.0.0.0 NULL0
172.16.2.0/24 BGP 130 0 0.0.0.0 NULL0
172.16.3.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0

[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
Destinations : 8 Routes : 8

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
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0
192.168.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.2.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.3.0/24 BGP 130 0 0.0.0.0 NULL0

Mas imaginem que a VRF Client_B, por questões de segurança no roteamento, não precissasse ensinar os prefixos 172.16.2.0/24 e 172.16.3.0/24 para a VRF Client_A mas somente o prefixo 172.16.1.0/24…. Nesse caso precisaríamos configurar o roteamento seletivo para que a VRF Client_A aprenda somente os prefixos necessários.

Ja a VRF Client_A exportará todos os prefixos sem filtros para a Client_B

Utilizaremos no exemplo o valor da Extended Community 65000:12 para exportar o prefixo 172.16.1.0/24.

ip ip-prefix Client_B_prefixo index 5 permit 172.16.1.0 24
! Selecionando o prefixo via prefix-list
!
route-policy Client_B_export permit node 10
if-match ip-prefix Client_B_prefixo
apply extcommunity rt 65000:12 additive
#
! Configurando a community estendida via Route-map
!
ip vpn-instance Client_B
export route-policy Client_B_export
quit
! Configurando o export seletivo de prefixo
end
!

#
ip ip-prefix Client_B index 5 permit 172.16.1.0 24
#
route-policy Client_B permit node 10
if-match ip-prefix Client_B
apply extcommunity rt 65000:12 additive
#

ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 65000:12 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
export route-policy Client_B
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 65000:1 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]disp ip routing-table vpn-instance Client_A
Routing Tables: Client_A
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
172.16.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0

[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
Destinations : 8 Routes : 8

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
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0
192.168.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.2.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.3.0/24 BGP 130 0 0.0.0.0 NULL0

Obs: O mesmo controle pode ser feito para os prefixos de entrada, utilizando o “import map”

Dúvidas , deixe um comentário

Comware: DHCP Relay Agent

A feature DHCP Relay permite ao Switch L3 ou Roteador encaminhar as mensagens DHCP em broadcast em unicast para determinado servidor, possibilitando assim utilização de um único servidor DHCP para toda a LAN.

Devido ao fato das solicitações de endereço IP ao servidor DHCP ocorrerem em broadcast, o Switch L3/Roteador configurado com a feature DHCP Relay encaminhará as mensagens ao Servidor DHCP em Unicast ( que está em uma VLAN diferente do host) .

O servidor DHCP entregará ao cliente o escopo correto baseado na interface IP de origem (alterada e inserida no cabeçalho DHCP).

Para o administrador do servidor DHCP bastará apenas criar os escopos no servidor.

Configurando o DHCP Relay

<SwitchA>system-view
[SwitchA] dhcp enable
! Ativando o DHCP
[SwitchA] dhcp relay server-group 1 ip 10.1.1.1
! Adicionando o servidor DHCP 10.1.1.1 dentro do grupo 1.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 10.1.1.254 255.255.255.0
[SwitchA-Vlan-interface2] quit
[SwitchA] interface vlan-interface 40
[SwitchA-Vlan-interface40] ip address 10.2.2.254 255.255.255.0
[SwitchA-Vlan-interface40] dhcp select relay
!Ativando o DHCP relay agent na VLAN-interface 40
[SwitchA-Vlan-interface40] dhcp relay server-select 1
! Correlacionando a VLAN-interface 40 para o grupo DHCP 1

Obs: as configurações de DHCP Relay podem variar dependendo do modelo do Switch. A configuração acima foi executada em um Switch HP modelo 4800.