No script abaixo demonstramos a configuração de PPP Multilink com LFI nos equipamentos baseados no Comware:
Comware: Script para configuração de PPP com LFI
Roteador HSR / MSR
Comware : Como incluir novas regras em uma ACL?
A configuração abaixo exibe a criação da ACL 2000 (baseada somente na Origem) e o vinculo dessa ACL na user-interface vty 0 4 que é responsável pelas conexões TELNET e SSH.
acl number 2000 rule 0 permit source 172.31.1.0 0.0.0.255 rule 5 deny # user-interface vty 0 4 acl 2000 inbound
Para visualizar as regras:
[4800G-acl-basic-2000]display acl 2000 Basic ACL 2000, named -none-, 2 rules, ACL's step is 5 rule 0 permit source 172.31.1.0 0.0.0.255 rule 5 deny
Por default se as regras não forem numeradas, elas serão marcadas de 5 em 5.
A tradução da regra para a ACL 2000 permite a rede 172.31.1.0/24 na regra zero (rule 0 )e a negação de qualquer rede na regra 5; se a primeira condição não for satisfeita.
Se precisassemos incluir mais 4 redes poderíamos efetuar da seguinte maneira:
[4800G]acl number 2000 [4800G-acl-basic-2000]rule 1 permit source 192.168.1.0 0.0.0.255 [4800G-acl-basic-2000]rule 2 permit source 192.168.2.0 0.0.0.255 [4800G-acl-basic-2000]rule 3 permit source 192.168.3.0 0.0.0.255 [4800G-acl-basic-2000]rule 4 permit source 192.168.4.0 0.0.0.255
Para visualizar as regras:
[4800G-acl-basic-2000]display this # acl number 2000 rule 0 permit source 172.31.1.0 0.0.0.255 rule 1 permit source 192.168.1.0 0.0.0.255 rule 2 permit source 192.168.2.0 0.0.0.255 rule 3 permit source 192.168.3.0 0.0.0.255 rule 4 permit source 192.168.4.0 0.0.0.255 rule 5 deny #
Mas se precisassemos incluir mais regras entre a rule 4 e a rule 5 ?
O Comando step dentro da ACL permite aumentarmos o espaçamento entre as regras, como no exemplo abaixo:
[4800G-acl-basic-2000]step 7 [4800G-acl-basic-2000]display this # acl number 2000 step 7 rule 0 permit source 172.31.1.0 0.0.0.255 rule 7 permit source 192.168.1.0 0.0.0.255 rule 14 permit source 192.168.2.0 0.0.0.255 rule 21 permit source 192.168.3.0 0.0.0.255 rule 28 permit source 192.168.4.0 0.0.0.255 rule 35 deny #
Dessa forma poderíamos incluir diversas regras entre a rule 28 e 35.
Para reordenar, só precisaremos digitar step 1:
[4800G-acl-basic-2000]step 1 [4800G-acl-basic-2000]display this # acl number 2000 step 1 rule 0 permit source 172.31.1.0 0.0.0.255 rule 1 permit source 192.168.1.0 0.0.0.255 rule 2 permit source 192.168.2.0 0.0.0.255 rule 3 permit source 192.168.3.0 0.0.0.255 rule 4 permit source 192.168.4.0 0.0.0.255 rule 5 deny #
Obs: a dica é válida para ACL’s Básicas, Avançadas e Regras de Camada 2.
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
A 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 7: Scripts TCL e Python
Uma novidade bem legal da versão 7 do Comware (Sistema Operacional de Switches e Roteadores HP) é o suporte para scripts TCL e Python.
Um grupo de HPN criou um repositório dos scripts no GITHUB https://github.com/networkingdvi/HPN-Scripting#hpn-scripting
O repositório é totalmente free e para ter contato com a galera, acesse: http://abouthpnetworking.com/2014/06/22/hpn-scripting-on-github/
abração
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: OSPF – Comando Silent-Interface ( Passive Interface)
Durante as configurações do processo OSPF para Switches, Servidores ou Roteadores, algumas redes precisam ser declaradas no OSPF, mas isso não significa que elas (precisarão) formar adjacência com outros Roteadores – ao inserirmos uma rede com o comando network o equipamento começará a trocar mensagens OSPF por aquela interface.
O fato da interface gerar mensagens pelo protocolo OSPF a deixa vunerável ao aprendizado de mensagens de outros equipamentos que podem por consequência inserir redes por engano ou de forma maliciosa (perdendo assim o controle sobre o Roteamento da rede).
Nesse caso poderemos deixar as interfaces Físicas e VLANs em modo silencioso, sem gerar mensagens do protocolo para a LAN.
O comando silent-interface (em Switches e Roteadores 3Com/H3C/HP ) seguido do numero da interface VLAN ou Interface física, permitirá ao Switch/Roteador não gerar mensagens LSA.
ospf 100 silent-interface Vlan-interface1 ! Configurando a interface VLAN 1 em modo silent area 0.0.0.0 network 192.168.1.2 0.0.0.0 network 172.31.0.1 0.0.0.0 ! As melhores práticas sugerem configurarmos todas as interfaces ! como silent ( passive) e habilitarmos somente as VLANs/Interfaces ! de adjacência com o comando undo silent-interface + Interface silent-interface all ! Configurando todas as Interfaces VLAN como silent undo silent-interface Vlan-interface 2 ! Removendo a interterface VLAN 2 do silent
Dúvidas? Deixe um comentário!
Abraços a todos!
Comware7: Configuração básica para BGP
As configurações do BGP via CLI para os equipamentos baseados no Comware 7 diferem um pouco em relação aos Switches e Roteadores baseados no Comware 5.
Basicamente para o Comware 7, uma vez dentro do processo BGP, basta habilitar o ‘peering’ com o roteador vizinho normalmente, mas a grande diferença está no anuncio de prefixos, pois uma vez que você necessite anunciar prefixos IPv4 ou IPv6, será necessário entrar no address-family, ativar o peering e aplicar o comando network, import (redistribute) etc.
Para ficar mais fácil, veja o exemplo abaixo o peering eBGP entre o Roteador R1 (AS 100) e R4 (AS 400):
<R1> display current-configuration configuration bgp
bgp 100
peer 10.0.0.2 as-number 400
#
address-family ipv4 unicast
network 192.168.1.0 255.255.255.0
peer 10.0.0.2 enable
<R4> display current-configuration configuration bgp
bgp 400
peer 10.0.0.1 as-number 100
#
address-family ipv4 unicast
network 192.168.2.0 255.255.255.0
peer 10.0.0.1 enable
O ponto mais importante dessa configuração é definir o IPv4 unicast address family e ativar o peer. Perceba que as redes deverão ser anunciadas dentro do address family correto.
Para validar o peering:
<R1>display bgp peer ipv4 unicast BGP local router ID: 192.168.1.1 Local AS number: 100 Total number of peers: 1 Peers in established state: 1 * - Dynamically created peer Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State 10.0.0.2 400 125 118 0 2 01:47:39 Established
IPv6
O mesmo vale se o peering e/ou prefixos for para endereços IPV6
<R4>display current-configuration configuration bgp # bgp 400 peer 2001:DB8:14::1 as-number 100 # address-family ipv6 unicast network 2001:DB8:4:: 64 network 2001:DB8:44:: 64 peer 2001:DB8:14::1 enable
Para validar o peering BGP com endereço IPv6:
<R4>display bgp peer ipv6 unicast BGP local router ID: 192.168.44.4 Local AS number: 400 Total number of peers: 1 Peers in established state: 1 * - Dynamically created peer Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State 2001:DB8:14::1 100 60 60 0 2 00:47:40 Established
Para validar a tabela BGP basta preencher conforme o output abaixo: IPv4, IPv6, vpnv4, vpnv6, etc..
<R4>display bgp routing-table ? dampened Display dampened BGP routes flap-info Display BGP route flap information ipv4 Specify the IPv4 address Family ipv6 Specify the IPv6 address Family vpnv4 Specify the VPNv4 address family vpnv6 Specify the VPNv6 address family
Até logo.
Comware: Configurando o atributo MED em anúncios de prefixos BGP via route-policy
O propósito do atributo MED (ou MULTI_EXIT_DISC) é permitir que rotadores em um determinado AS digam a roteadores em outro AS a preferência de caminho para determinado prefixo. Apesar de conseguir manipular o “custo” de decisão do melhor caminho em outro AS, o MED não está no topo das escolhas de prioridades do protocolo, mas em diversos casos é muito eficiente.
Apesar de eu já ter utilizado o parâmetro algumas vezes, sempre me esqueço do comando correto e não consigo encontrar nos “Configure Guide” da vida em cenários com a aplicação do MED dentro de uma route policy. Uma das coisas mais legais de ter um blog é poder salvar assuntos que no futuro também facilitarão minha vida. 🙂
Voltando ao assunto… há a possibilidade de configurar o atributo MED direto no processo BGP (já para a versão7 do Comware a configuração deverá ser feita dentro do address-family).
Entretando, para configurar o MED dentro de uma route-policy o comando correto para atribuir um valor para o BGP Multi-Exit Discriminator é apply cost [valor MED].
route-policy SET_MED permit node 10 if-match ip address prefix-list abc apply cost 1000
Seleção de rotas BGP antes do atributo MED
Segue abaixo a lista com a ordem para escolha da melhor rota na tabela BGP antes do atributo MED:
- Seleciona a rota com maior preferred_value (similar ao weight da Cisco).
- Seleciona a rota com maior Local_Pref.
- Seleciona a rota originada pelo roteador local.
- Seleciona a rota com menor AS-Path.
- Seleciona a rota baseado na prioridade de origem.
- Seleciona a rota com o menor MED.
- …
Obs: Caso as opções de melhor preferência estejam com os mesmos atributos, o MED será a sexta opção para desempate.
Exemplo de Configuração
No cenário acima o roteador RB anuncia o prefixo 192.168.11.0/24 com o atributo MED com valor 10 e o roteador RC também anuncia o prefixo 192.168.11.0/24 mas com o atributo MED como 20.
Os Roteadores do AS 64500 comparam o menor MED e caso não exista melhor parâmetro para seleção, o atributo MED será escolhido para encaminhar o tráfego ao roteador (vence o menor valor MED).
Configuração do Roteador RB (com o Comware7)
#
ip prefix-list rede_192 index 5 permit 192.168.11.0 24
#
route-policy SET_MED_10 permit node 10
if-match ip address prefix-list rede_192
apply cost 10
#
bgp 64507
peer 192.168.12.2 as-number 64500
#
address-family ipv4 unicast
peer 192.168.12.2 enable
peer 192.168.12.2 route-policy SET_MED_10 export
#
Os roteadores do ASN 64500 terão em sua tabela BGP o seguinte cenário:
[RE]display bgp routing-table ipv4
Total number of routes: 5
BGP local router ID is 192.168.3.3
Status codes: * - valid, > - best, d - dampened, h - history,
s - suppressed, S - stale, i - internal, e – external
Origin: i - IGP, e - EGP, ? - incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
* >i 192.168.1.0 192.168.12.1 0 100 0 64507i
* e 192.168.13.1 0 0 64507
>i 192.168.2.0 192.168.2.2 0 100 0 i
* >i 192.168.11.0 192.168.12.1 10 100 0 64507i
* e 192.168.34.1 20 0 64507i
Veja que a rota “best” em nosso cenário é o prefixo com menor valor do atributo MED.
Até logo!
Referências
CCIE Routing and Switching Certification Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue
Comware: Configurando o atributo Preferred_value (weight) em anúncios de prefixos BGP via route-policy
O atributo BGP Preferred_value permite ao roteador examinar internamente as atualizações BGP decidir a rota preferêncial.
O atributo não é encaminhado nas mensagens BGP e possui apenas função local em um roteador. Para aqueles que estão acostumados a configuração do protocolo BGP em roteadores Cisco com IOS, a funcionalidade é idêntica a configuração BGP weight, que é proprietária.
O Preferred_value é eficiente quando há a necessidade de manipular um destino na saída de um AS, em meio múltiplas rotas.
Vence a rota com maior valor do Preferred_value e é possível configurar valores entre 0 e 65535.
Por padrão os prefixos aprendidos via eBGP possuem o valor como 0 e o Preferred_Value é o parâmetro preferencial para escolha da melhor rota.
Seleção de rotas BGP
Segue abaixo a lista com a ordem para escolha da melhor rota na tabela BGP:
- Seleciona a rota com maior preferred_value (similar ao weight da Cisco).
- Seleciona a rota com maior Local_Pref.
- Seleciona a rota originada pelo roteador local.
- Seleciona a rota com menor AS-Path.
- ….
Exemplo de Configuração
No exemplo abaixo iremos manipular o roteamento do AS 64507 para o prefixo 2001:db8:3::/64 anunciado pelo AS 64500, para o roteador RA escolher o caminho via RC (next-hop 2001:db8:13::3). O exemplo de configuração é o mesmo para os prefixos IPv4.
Script de configuração de um roteador MSR com o Comware 7
ipv6 prefix-list abc index 10 permit 2001:DB8:3:: 64 ! Configurando a prefix-list da rede 2001:db8::3/64 # route-policy SET_PV permit node 10 if-match ipv6 address prefix-list abc apply preferred-value 200 ! Criando a route-map para aplicar o Preferred_value 200 a prefix-list abc # bgp 64507 peer 2001:DB8:12::2 as-number 64500 peer 2001:DB8:13::3 as-number 64500 # address-family ipv6 unicast network 2001:DB8:1:: 64 peer 2001:DB8:12::2 enable peer 2001:DB8:13::3 enable peer 2001:DB8:13::3 route-policy SET_PV import ! Aplicando a route-policy SET_PV para os prefixos aprendidos pelo peer #
Verificando a tabela de roteamento
[RA]display bgp routing-table ipv6
Total number of routes: 3
BGP local router ID is 192.168.11.1
Status codes: * - valid, > - best, d - dampened, h - history,
s - suppressed, S - stale, i - internal, e – external
Origin: i - IGP, e - EGP, ? - incomplete
* >e Network : 2001:DB8:2:: PrefixLen : 64
NextHop : 2001:DB8:12::2 LocPrf :
PrefVal : 0 OutLabel : NULL
MED : 0
Path/Ogn: 64500i
* >e Network : 2001:DB8:3:: PrefixLen : 64
NextHop : 2001:DB8:13::3 LocPrf :
PrefVal : 200 OutLabel : NULL
MED : 0
Path/Ogn: 64500i
* e Network : 2001:DB8:3:: PrefixLen : 64
NextHop : 2001:DB8:12::2 LocPrf :
PrefVal : 0 OutLabel : NULL
MED :
Path/Ogn: 64500i
Veja que a rota “best” para o prefixo 2001:db8:3::/64 está com o Preferred_value como 200.
Até logo
Comware 7 – Autenticação de TACACS com Tac_plus
Galera, durante a criação de um laboratório para testes de autenticação com TACACS de Roteadores MSR com Comware7, utilizamos o Debian com o tac_plus como Servidor.
Segue abaixo os scripts utilizados:
#
# tacacs configuration file
# Pierre-Yves Maunier – 20060713
# /etc/tac_plus.conf
# set the key
key = labcomutadores
accounting file = /var/log/tac_plus.acct
# users accounts
user = student1 {
login = cleartext "normal"
enable = cleartext "enable"
name = "Usuario Teste"
service = exec {
roles="network-admin"
}
}
user = student2 {
login = cleartext "normal"
enable = cleartext "enable"
name = "Usuario Teste"
service = exec {
roles="network-operator"
}
}
Configuração do Roteador MSR HP
wtacacs scheme tac primary authentication 192.168.1.10 primary authorization 192.168.1.10 primary accounting 192.168.1.10 ! endereço do servidor TACACS key authentication simple labcomutadores key authorization simple labcomutadores key accounting simple labcomutadores user-name-format without-domain # domain tac.com.br authentication login hwtacacs-scheme tac local authorization login hwtacacs-scheme tac local accounting login hwtacacs-scheme tac local # domain default enable tac.com.br # user-interface vty 0 4 authentication-mode scheme
Até logo
COMUTADORES 