Vídeo: VRF (VPN-Instance)

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

Obrigado!

Perguntas e Respostas: VRF x VPN-instance

Galera, segue abaixo um pequeno resumo sobre a nomenclatura utilizada nas documentações Cisco x HP sobre o assunto VRF. Acredito que possa ajudar de forma rápida a entender alguns conceitos:

VRF: Virtual Routing and Forwarding
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. Utilizado em cenários MPLS L3VPN com MP-BGP.

PeR-VRF

VRF Lite
A mesma funcionalidade que a VRF para criação de tabelas de roteamento independentes, mas nomeado para cenários sem MPLS L3VPN. Chamado também de Multi-VRF.

PeR-VRF-lite

VPN-Instance
Termo utilizado nas documentações HP para VRF no Comware.

MCE (Multi CE)
Termo utilizado nas documentações HP para VRF-Lite.

 

Dúvidas e colocações, deixe um comentário.

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

VRF static Route leaking - Comware

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

Referências

VRFs em Switches e Roteadores baseados no Comware
http://www.comutadores.com.br/vrf-em-switches-e-roteadores-hpn-vpn-instance/

Roteamento entre VRF
http://www.comutadores.com.br/roteamento-entre-vrfs-com-mp-bgp-em-roteadores-hp-h3c/

Building HP FlexFabric Data Centers student guide – Rev. 14.41

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). Configuração do 1º exemplo

VRFs prefixes

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

inter VRFs prefixes

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
!

inter VRFs prefixes exportmap

A configuração dos 3º cenário pode ser encontrada aqui

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

Dúvidas , deixe um comentario

Referência: http://www.rotadefault.com.br/roteamento-seletivo-entre-vrfs-com-export-map/

Roteamento entre VRFs com MP-BGP em Roteadores HP / H3C

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.

VRFs Comware

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.

A configuração de VRFs é bem simples e há um artigo aqui do blog que pode ser consultado no link [http://www.comutadores.com.br/vrf-em-switches-e-roteadores-hpn-vpn-instance/].

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.

 

!
!
ip vpn-instance Cliente_A
 route-distinguisher 65000:1
 vpn-target 65000:1 export-extcommunity
 vpn-target 65000:1 import-extcommunity
 vpn-target 65000:2 import-extcommunity 
!
ip vpn-instance Cliente_B
 route-distinguisher 65000:2
 vpn-target 65000:2 export-extcommunity
 vpn-target 65000:2 import-extcommunity
 vpn-target 65000:1 import-extcommunity  
!
ip vpn-instance Cliente_C
 route-distinguisher 65000:3
 vpn-target 65000:3 export-extcommunity
 vpn-target 65000:3 import-extcommunity
!

Inter VRF Routing

Segue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.

!
!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 ip binding vpn-instance Cliente_A
 ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
 ip binding vpn-instance Cliente_B
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip binding vpn-instance Cliente_C
 ip address 3.3.3.3 255.255.255.0
!
#
bgp 6500
 undo synchronization
#
 ipv4-family vpn-instance Cliente_A
  import-route direct
#
 ipv4-family vpn-instance Cliente_B
  import-route direct
#
 ipv4-family vpn-instance Cliente_C
  import-route direct
#
!

Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs(vpn-instances) e o teste de ICMP

[R1]display ip routing-table vpn-instance Cliente_A
Routing Tables: Cliente_A
        Destinations : 4        Routes : 4
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
1.1.1.1/32          Direct 0    0            127.0.0.1       InLoop0
2.2.2.2/32          BGP    130  0            127.0.0.1       InLoop0
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

[R1]ping -vpn-instance Cliente_A 2.2.2.2
  PING 2.2.2.2: 56  data bytes, press CTRL_C to break
    Reply from 2.2.2.2: bytes=56 Sequence=1 ttl=255 time=4 ms
    Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=255 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=255 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=4 ttl=255 time=5 ms
    Reply from 2.2.2.2: bytes=56 Sequence=5 ttl=255 time=4 ms
 --- 2.2.2.2 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 4/5/10 ms

Segue abaixo a configuração completa do R1

Para dúvidas em sugestões deixe um comentário. Até logo 😉

VRF em Switches e Roteadores HPN – (VPN-Instance)

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]).

VRF Comware

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 HPN a configuração do RD é obrigatória na criação da VRF! 😉

Utilizando sub-interfaces nos Rotadores HP MSR’s, 8800 e 6600

A utilização de sub-interfaces em Roteadores permite a multiplexação/divisão de um único link físico em múltiplos links lógicos.

Como exemplo nos cenários abaixo, o Roteador poderá atuar tanto como Gateway para roteamento entre as VLANs X e Y no cenário A para casos em que o Roteador possua possua poucas portas disponíveis, por exemplo; como também em casos para rotear pacotes sem que as redes X e Y tenham acesso uma a outra com a utilização de VRFs , chamadas de VPN-Instance nos Roteadores HPN ( para o cenário B).

Subinterfaces no MSR

Para configurar uam sub-interface em um Roteador 8800, utilize o “.”(ponto) + o id da VLAN após o numero indicativo da porta em uma interface no modo routed.

[Roteador]interface Ten-GigabitEthernet 2/1/1.?

#

Segue um exemplo da configuração para o cenário A

interface Ten-GigabitEthernet 2/1/1.30
description VLAN_X
ip adress 192.168.20.1 255.255.255.0
quit
#
interface Ten-GigabitEthernet 2/1/1.31
description VLAN_Y
ip adress 192.168.30.1 255.255.255.0
quit
#

Em alguns modelos de Roteadores como a Serie 6600 será necessário configurar o VLAN ID, com a configuração do vlan-type dot1q vid [id da vlan] dentro da sub-interface, isto em razão do SO do Roteador não entender que é explicito o ID da VLAN no número da sub-interface. Roteadores Cisco funcionam da mesma forma.

interface Ten-GigabitEthernet 2/1/1.30
description VLAN_X
ip adress 192.168.20.1 255.255.255.0
vlan-type dot1q vid 30
quit
#
interface Ten-GigabitEthernet 2/1/1.31
description VLAN_Y
ip adress 192.168.30.1 255.255.255.0
vlan-type dot1q vid 31
quit
#

… então como as sub-interfaces estão diretamente conectadas, as rotas são adicionadas à tabela de roteamento, o equipamento fará  o roteamento de pacotes.

Já para o segundo cenário, a mesma configuração é válida, bastando apenas configurar a sub-interface com a configuração da vpn-instance antes de configurar o endereço IP.

#Criando a VRF para o cliente X
ip vpn-instance clientex
 route-distinguisher 65000:1
 vpn-target 65000:1 export-extcommunity
 vpn-target 65000:1 import-extcommunity
#
#Criando a VRF para o cliente Y
ip vpn-instance clientey
 route-distinguisher 65000:2
 vpn-target 65000:2 export-extcommunity
 vpn-target 65000:2 import-extcommunity
#
interface Ten-GigabitEthernet 2/1/1.30
description 
ip binding vpn-instance clientex
ip adress 192.168.20.1 255.255.255.0
quit
#
interface Ten-GigabitEthernet 2/1/1.31
description VLAN_Y
ip binding vpn-instance clientey
ip adress 192.168.30.1 255.255.255.0
quit
#
# as configurações do compartimento WAN de cada VRF foram omitidas
#

 obs: Uma rede não será roteada para outra a menos que estejam na mesma VRF.

Já para a configuração do Switch basta apenas configurar a interface como trunk permitindo as vlans correspondente. Se o Roteador for da Serie 6600 a configuração vlan-type dot1q vid … também será necessária (para o segundo cenário).

Um grande abraço e a Paz! 🙂

Alterando a distancia administrativa para os protocolos de Roteamento em Switches e Roteadores HPN (Comware)

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

http://www.comutadores.com.br/distancia-administrativa-em-switches-l3-e-roteadores-h3c3comhp-serie-a/

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!

Roteador MSR 30 –16: Configurando TACACS em uma VPN-Instance (VRF)

Compatilho abaixo o script (comentado) para a autenticação de usuários em uma base remota para administração de um Roteador MSR 30-16. Os testes serviram para validar um Servidor ACS da Cisco para autenticação via TACACS em um Roteador HPN. A diferença deste teste para as outras configurações é a utilização do TACACS dentro de uma vpn-instance (VRF).


Configuração
#
ip vpn-instance test
 route-distinguisher 1:1
 vpn-target 1:1 export-extcommunity
 vpn-target 1:1 import-extcommunity
! Criando a VRF “test”
#
super password level 3 simple s3nhasup3r
super authentication-mode scheme
#
telnet server enable
#
hwtacacs scheme acs
! Criando o esquema TACACS com o nome acs
primary authentication 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para autenticação
primary authorization 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para autorização
primary accounting 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para contabilidade
nas-ip 172.16.1.1
!Endereço de IP do Switch cadastrado no ACS
key authentication teste123
! Chave para autenticação com o servidor ACS  com a senha"teste123"
key authorization teste123
key accounting teste123
user-name-format without-domain
! Encaminhamento do usuário sem o formato @dominio
#
domain acs
authentication login hwtacacs-scheme acs local
!Configurando a autenticação com TACACS e em caso de falha, a autenticação será local.
authorization login hwtacacs-scheme acs local
accounting login hwtacacs-scheme acs local
authentication default hwtacacs-scheme acs local
authorization default hwtacacs-scheme acs
accounting default hwtacacs-scheme acs
authentication super hwtacacs-scheme acs
accounting command hwtacacs-scheme acs
#
domain default enable acs
! Habilitando o dominio acs como default para auetnticação
#
interface Ethernet0/0
 port link-mode route
 ip binding vpn-instance test
 172.16.1.1 255.255.255.0
#
user-interface vty 0 4
authentication-mode scheme
#

obs: Sugerimos que durante os testes, não configure o authentication-mode scheme no acesso via Console, para em caso de falha nos testes, você não fique trancado do lado de fora do Switch.

A autenticação do “super-usuário” via TACACS também está inclusa no script.

Abração