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).
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
Neste vídeo, aprofundamos os conhecimentos em configuração de switches 3Com/HP, apresentando os comandos para configurar e gerenciar protocolos como DHCP relay, IGMP, IGMP Snooping, NTP, RADIUS, sflow, SSH, Syslog e Telnet.
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:
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
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.
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).
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 !
A agregação de diversas interfaces Ethernet (portas físicas) para a utilização de uma única porta lógica com o intuito de prover redundância e aumento de banda é uma atividade muito comum em redes de médio e grande porte . No vídeo abaixo, fazemos uma breve descrição sobre a configuração para Link-Aggregation.
Há diversas situações em que o Eng. de Rede necessita administrar uma rede (ou alguns velhos Switches), em cenários que não possui a senha para acesso console, telnet ou SSH do equipamento.
Nesse video mostramos algumas saídas utilizando o boot menu para o acesso à administração do Switch ou Roteador.
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):
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 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
A agregação de diversas interfaces Ethernet (portas físicas) para a utilização de uma única porta lógica com o intuito de prover redundância e aumento de banda é uma atividade muito comum em redes de médio e grande porte .
Infelizmente o nome atribuído pelos fabricantes não segue um padrão, mas por outro lado todos possuem as mesmas funções citadas anteriormente:Etherchannel, Port-channel, Link-Aggregation, Bridge-Aggregation, Trunk [ nome dado antigamente para agregação de portas.(Não confundam com a utilização de interface Trunk atribuída pelos Switches Cisco e 3Com. Os Switches Procurve ainda utilizam essa terminologia) ] e etc.
Existem algumas formas de estabelecer a agregação de portas, como por exemplo:
– Manual : sem a certificação do meio por protocolos auxiliares – PAgP : Protocolo disponível em equipamentos Cisco – LACP : Protocolo padrão IEEE, disponível quase todos Switches gerenciáveis.
Modos de formação de um Etherchannel em Switches Cisco
Cisco(config-if)# channel-group 1 mode ?
active Enable LACP unconditionally
auto Enable PAgP only if a PAgP device is detected
desirable Enable PAgP unconditionally
on Enable Etherchannel only
passive Enable LACP only if a LACP device is detected
No Script abaixo mostraremos a configuraçaõ de Link Aggregation/Etherchannel entre um Switch Cisco IOS e um Switch HP baseado no Comware:
Switch Comware
#
interface Bridge-aggregation 1
link-aggregation mode dynamic
! Estabelecendo a conexão do Link-Aggregation utilizando o protocolo LACP
#
interface gigabitEthernet 1/0/1
port link-aggregation group 1
! Atribuindo a porta para negociar a agregação via protocolo LACP
#
interface gigabitEthernet 1/0/2
port link-aggregation group 1
! Atribuindo a porta para negociar a agregação via protocolo LACP
Switch Cisco IOS
!
interface port-channel 1
!
interface gigabitEthernet 1/10
channel-group 1 mode active
! Estabelecendo a conexão do Etherchannel utilizando o protocolo LACP
!
interface gigabitEthernet 1/11
channel-group 1 mode active
! Estabelecendo a conexão do Etherchannel utilizando o protocolo LACP
!
Comandos Show e Display
Switch Comware
[HPN]display link aggregation verbose
Aggregation Interface: Bridge-Aggregation1
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, 3822-d6a2-5c00
Local:
Port Status Priority Oper-Key Flag
----------------------------------------------------
GE1/0/1 S 32768 8 {ACDEF}
GE1/0/2 S 32768 8 {ACDEF}
Remote:
Actor Partner Priority Oper-Key SystemID Flag
------------------------------------------------------------
GE1/0/1 516 32768 45 0x8000, 4055-39d4-8e13 {ACDEF}
GE1/0/2 517 32768 45 0x8000, 4055-39d4-8e13 {ACDEF}
Switch Cisco IOS
Cisco#show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s – suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 2
Number of aggregators: 2
Group Port-channel Protocol Ports
------+-------------+-----------+--------------------------
1 Po1(SU) LACP Gi1/10(P) Gi1/11(P)
Não esqueça!!!
Sempre quando for necessario a alteração de VLANs das portas do Link Aggregation/Etherchannel faça a alteração somente na interface virtual ( port channel/ bridge-aggregation), que a configuração será replicada para as interfaces físicas. Mantenha a consistência de VLANs nas 2 pontas do Link Aggregation/Etherchannel.
Use velocidades de portas idênticas como: interfaces 1Gb com interfaces 1G e interfaces 10Gb com interfaces 10Gb e assim por diante…
A Pagina support.hpe.com permite ao administrador de rede acesso aos documentos oficiais para auxilio de configurações, comandos de referência, release notes e mais. Incluído produtos antigos da 3Com, H3C e outros.
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].
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).
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
COMUTADORES 
