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.
Alguns equipamentos baseados no Comware 7 como Roteadores MSR, HSR e Switches HP, permitem a configuração das suas portas no modo L2 (bridge) e L3 (route). Nesse video explicamos a diferença de cada um dos modos, como também a configuração de Sub-interfaces, interfaces VLAN e Route-Aggregation.
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
As ACL (Access Control List) são utilizadas para classificar tráfego para os mais diversos fins, como por exemplo, políticas de filtro de pacotes, QoS e PBR.
Uma ACL pode classificar um tráfego baseando-se no fluxo de dados que entram ou saem de uma interface (porta física, interface VLAN, VLAN, etc).
Na maioria dos casos uma ACL é utilizada para determinar se um pacote será permitido ou descartado em uma interface com as ações PERMIT ou DENY.
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 !
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
As ACL (Access Control List) são utilizadas para classificar tráfego para os mais diversos fins, como por exemplo, políticas de filtro de pacotes, QoS e PBR.
Uma ACL pode classificar um tráfego baseando-se no fluxo de dados que entram ou saem de uma interface (porta física, interface VLAN, VLAN, etc).
Na maioria dos casos uma ACL é utilizada para determinar se um pacote será permitido ou descartado em uma porta com as ações PERMIT ou DENY.
Essas ações são seguidas das definições DO QUE se deve permitir (PERMIT) ou negar (DENY). Estas, basicamente, são as principais opções:
ANY (tudo) [IP do host/rede] [subrede no formato wildcard] [protocolo]
Imaginando de maneira prática, os Roteadores e Switches também podem utilizar como referência para classificação de tráfego as informações de cabeçalho de camada 2 (como endereço MAC), camada 3 (campos de cabeçalho IP) e camada 4 ( portas TCP e UDP).
Para uma ACL é possível adicionar diversas regras. A leitura das regras pelo equipamento é efetuada linha por linha, de cima para baixo; e após a condição ser encontrada (match) o restante das regras não serão mais verificadas. A ordem para satisfazer uma condição, é lida na ordem em que as regras são configuradas.
O blog do CCNA faz o seguinte comentário para a utilização de uma ACL para filtro de pacotes (lembrando que uma ACL pode incluir diversas regras):
A regra básica diz que somente UMA ACL pode ser aplicada em uma mesma interface e direção, em um determinado router (ou switch). Ou seja, em uma mesma interface você até pode ter mais de uma ACL, desde que em sentidos opostos. Os sentidos possíveis são ilustrados no diagrama abaixo.
(IN) entrante —–> ROUTER ——> sainte (OUT)
Tipos de ACL
Os equipamentos baseados no Comware permitem três tipos de ACL:
Camada 2: Especificam regras baseadas em endereços MAC de origem, destino, VLAN e tipos de protocolo Ethernet.
Camada 3(básica): Especificam regras baseadas em endereços IP e rede de origem.
Camada 3 (Avançada): Especificam regras baseadas em protocolos de camada 3, redes de origem e destino; e portas de origem e destino.
Definindo a ACL
A definição do template para a configuração das Listas de Acesso é baseado pelos números,que a identificam:
ACL Básica: número 2000 a 2999
ACL Avançada: número de 3000 a 3999
ACL de camada 2: número de 4000 a 4999
ACL Básica
Baseia-se no endereço de rede de origem para filtrar ou permitir o tráfego.
Imaginando que você deseja filtrar quais máquinas podem efetuar efetuar Read and Write via SNMP em um Switch…
acl number 2100
! Criando a ACL 2100
rule permit source 172.31.1.100 0.0.0.0
! Criando a primeira regra na ACL 2000 permitindo a rede 172.31.1.100
! com 32 bits (máscara de host para somente uma máquina gerenciar o Switch via SNMP)
quit
snmp-agent community write comutadores acl 2100
! Vinculando a ACL 2100 na communty SNMP RW “comutadores”
A regra acima irá permitir o acesso SNMP somente ao host 172.31.1.100, o restante da rede terá o acesso negado para coleta SNMP nesse equipamento.
Obs: Apesar do exemplo acima ser bem simples, uma ACL básica também pode ser configurada para filtrar pacotes que entram ou saem do Roteador com a política baseada na rede de origem.
ACL Avançada
A diferença entre uma ACL básica e avançada é a forma de relacionamento com as informações no cabeçalho IP. A ACL avançada utiliza os campos de endereço IP de origem e destino, porta e número de protocolo diferenciando pacotes como TCP e UDP.
Alguns parâmetros especiais poderão ser utilizados na construção de uma ACL avançada:
Endereço IP de origem
Endereço IP de destino
Porta de origem
Porta de destino
Tipo de pacote ICMP
Parâmetro SYN do TCP
Valor IP Precedence
Valor DSCP
Valor TOS
Fragmentos
Abaixo segue o exemplo de uma ACL avançada criada e aplicada em uma interface do Roteador HP 6600 para filtro de pacotes na entrada da interface Giga3/2/1
firewall enable slot 3
! Habilitando o filtro de pacotes no slot3 do roteador
firewall default deny slot 3
! Habilitando uma regra de deny implícito após a configuração manual da última regra da ACL
acl number 3030 name INTERNET-INBOUND
! Criando a ACL 3030 e atribuíndo o nome de "INTERNET-INBOUND"
rule 10 permit icmp destination 200.200.200.0 0.0.0.255
! permindo os pacotes com o ip dentro do range 200.200.200.0/24 no cabeçalho de destino com wildcard
rule deny ip source 10.0.0.0 0.255.255.255
rule deny ip source 172.16.0.0 0.15.255.255
rule deny ip source 192.168.0.0 0.0.255.255
rule deny ip source 127.0.0.0 0.255.255.255
! negando qualquer pacote com ip de origem dentro do range da RFC 1918
rule 60 deny ip source 0.0.0.0 0.255.255.255
! negando qualquer pacote com ip de origem como 0.0.0.0
rule 9999 permit ip
! permitindo qualquer endereço IP de origem e destino
quit
#
acl number 3040 name INTERNET-OUTBOUND
rule deny ip source 10.0.0.0 0.255.255.255
rule deny ip source 172.16.0.0 0.15.255.255
rule deny ip source 192.168.0.0 0.0.255.255
rule deny ip destination 224.0.0.0 15.255.255.255
rule deny ip source 224.0.0.0 15.255.255.255
#
interface GigabitEthernet3/2/1
port link-mode route
firewall packet-filter name INTERNET-INBOUND inbound
firewall packet-filter name INTERNET-OUTBOUND outbound
! Aplicando a ACL para filtro na entrada e saída de pacotes
ip address 123.123.123.218 255.255.255.252
#
Segue um segundo exemplo de ACL avançada mas dessa vez em Switches do modelo 4800
acl number 3000
! Criando a ACL 3000
rule permit ip source 172.31.1.0 0.0.0.255 destination 192.168.1.0 0.0.0.255
! Criando a primeira regra na ACL 3000 permitindo a rede 172.31.1.0 com 24 bits (máscara
/24) efetuar comunicação IP com a rede 192.168.1.0/24
rule deny ip source any
! Criando a segunda regra na ACL 3000 negando qualquer rede de origem
quit
#
interface vlan 2
ip address 192.168
packet-filter 3000 inbound
!Aplicando a ACL 2000 para filtro na interface VLAN.
Obs: Para aplicarmos uma ACL em Portas físicas ou interface VLAN de um Switch é utilizado o comando packet-filter, já para roteadores, comando poderá ser incrementando com a sintaxe “firewall packet-filter….”
A regra acima irá permitir a comunicação IP, da rede 172.31.1.0/24 para a rede 192.168.1.0/24, o restante do tráfego terá o acesso negado.
Se precisarmos utilizar outros parâmetros para match da ACL podermos utilizar o caracter ? após o permit ou deny. Parâmetros como TCP, UDP, ICMP e etc poderão também ser utilizados
O exemplo abaixo exemplifica a utilização de parâmetros de portas TCP para criarmos a regra, como por exemplo permitir o acesso somente a serviços que realmente serão utilizados.
O restante do tráfego será negado, provendo maior segurança e escalabilidade pela utlilização de diversas VLANs.
As ACL que utilizam parâmetros da camada de enlace do modelo de referencia OSI, poderão ser utilizadas para filtrar baseando-se em campos como ID da VLAN, mascara de endereços MAC (os primeiros bits são reservados para endereço dos fabricantes) , tipos de Protocolos,etc.
Obs: a configuração e o tipo de ACL disponivel em cada equipamento pode sofrer pequenas variações ou limitações na configuração. Sempre faça um teste antes de aplicar a ACL em um ambiente de produção.
COMUTADORES 