Comware: STP edged-port + BPDU-protection

A feature edged-port permite a interface saltar os estados Listening e Learning do Spanning-Tree Protocol (STP), colocando as portas imediatamente em estado Forwarding (Encaminhamento). A configuração do stp edged-port enableforça a interface a ignorar os estados de convergência do STP, incluíndo as mensagens de notificação de mudança na topologia (mensagens TCN ).

A utilização da feature edged-port com a configuração do comando stp bpdu-protection, protege as portas configuradas como edged-port de receberem BPDUs. Ao receber um BPDU a porta entrará em shutdown.

Comware: DHCP Relay Agent

A funcionalidade DHCP Relay permite ao Switch L3/Roteador encaminhar as mensagens DHCP em broadcast para determinado servidor além do dominio de broadcast do host, 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 ocorrem em broadcast, o roteador configurado com a feature DHCP Relay encaminhará as mensagens ao Servidor DHCP em Unicast.

O servidor DHCP entregará ao cliente o escopo correto baseado na interface IP de origem ( inserida na mensagem DHCP). Para o administrador do servidor DHCP bastará apenas criar os escopos no servidor.

Configurando IGMP Snooping em Switches Aruba CX

O IGMP Snooping é um mecanismo que permite aos switches multicamada aprenderem quais portas estão conectadas a hosts multicast. Ao utilizar essa informação, o switch pode direcionar o tráfego multicast apenas para as portas onde os hosts estão conectados, evitando a inundação desnecessária da rede.

Passos para configurar o IGMP Snooping em Aruba CX:

  1. Habilitar IGMP Snooping:

No nível da VLAN:

interface Vlan10

ip igmp snooping enable

Globalmente:

(Observação): A configuração global geralmente não é recomendada, pois pode afetar todas as VLANs.

ip igmp snooping enable

  1. Configurar a versão IGMP:

IGMPv2 ou IGMPv3:

interface Vlan10

ip igmp snooping version 3

  1. Configurar grupos multicast estáticos (opcional):

Para permitir ou bloquear grupos específicos:

ip igmp snooping static group 224.0.1.1

ip igmp snooping static group 239.192.1.1 block

  1. Configurar filtros de acesso (opcional):

Para aplicar filtros de acesso aos grupos multicast:

ip igmp snooping apply access-list ACL_name

Opções adicionais:

  • fast-leave: Acelera a remoção de hosts multicast da tabela de snooping.
  • fast-learn: Acelera a adição de hosts multicast à tabela de snooping.
  • querier: Configura um switch como querier para enviar mensagens IGMP querier.
  • blocked: Impede que o switch aprenda sobre hosts multicast em uma VLAN específica.

Exemplo de configuração completa:

interface Vlan10

 ip address 10.0.10.1 255.255.255.0

 ip igmp snooping enable

 ip igmp snooping version 3

 ip igmp snooping fast-leave

Dicas adicionais:

  • Verifique a configuração: Use comandos como show ip igmp snooping para verificar a configuração de IGMP Snooping.

Comware 7: Captura de pacotes

 Roque nos enviou mais uma dica interessante para os Switches HP 5800. O modelo permite a captura de pacotes no formato .pcap salvando o arquivo na memória Flash, de forma que depois copiado via TFTP para um servidor  como o  Wireshark por exemplo, o tráfego coletado poderá ser analisado.

Conforme o comando display abaixo é possível validar algumas possibilidades  (comandos de um HP 5800AF-48G com a versão do Comware 5.20.106)

<Switch>packet capture ?
acl          Specify the ACL
buffer       Packet capture buffer
buffer-size  Specify the capture buffer size
length       Specify the maximum size of entry in the buffer
mode         Specify capture mode
schedule     Schedule the capture at a specific time
start        Start to capture immediately
stop         Pause capture

Abaixo, fiz uma tradução livre do procedimento de configuração do “Configure Guide” do Switch HP 5800 em uma rede IPv4.

1. Ativando a função de captura de pacotes no Switch:
Crie a ACL 2000 permitindo pacotes com a origem 192.168.1.0/24

<Switch> system-view
[Switch] acl number 2000
[Switch-acl-basic-2000] rule permit source 192.168.1.0 0.0.0.255
[Switch-acl-basic-2000] quit
[Switch] quit

Configure o Switch para capturar pacotes baseando-sw na ACL 2000 e então inicie a captura dos pacotes.

<Switch> packet capture start acl 2000

Vizualize o status da captura dos pacotes

<Switch> display packet capture status
Current status : In process
Mode : Linear
Buffer size : 2097152 (bytes)
Buffer used : 1880 (bytes)
Max capture length : 68 (bytes)
ACL information : Basic or advanced IPv4 ACL 2000
Schedule datetime: Unspecified
Upper limit of duration : Unspecified (seconds)
Duration : 13 (seconds)
Upper limit of packets : Unspecified
Packets count : 10
The output shows that packet capture is ongoing.

2. Salvando o resultado da captura de pacotes:
Pare a captura de pacotes.

<Switch> packet capture stop
Salvando o conteúdo do buffer na memoria flash com o nome test.pcap
<Switch> packet capture buffer save test.pcap
Visualize os arquivos da memória Flash.
<Switch> dir
Directory of flash:/
0 -rw- 1860 Sep 21 2012 12:52:58 test.pcap
1 drw- - Apr 26 2012 12:00:38 seclog
2 -rw- 10479398 Apr 26 2012 12:26:39 logfile.log

Libere os recursos do sistema após finalizar a captura de pacotes

<Switch> undo packet capture

Copie o arquivo test.pcap via servidor FTP ou TFTP e analise os pacotes através de softwares como o Wireshark.

Comware 7: IRFv2 – dúvidas na configuração do irf-port

Esses dias durante a implantação de  Switches Comware em 2 diferentes Datacenters, configurei o IRF dos Switches de duas maneiras diferentes, mas ambas utilizando 4 portas 10Gb:

No Datacenter A a configuração de IRF entre os Switches foi executada com duas irf-port em cada Switch enquanto no Datacenter B a configuração de IRF foi executada com apenas uma irf-port por Switch.

Datacenter A:

irf-port 1/1
port group interface Ten-GigabitEthernet1/0/1
port group interface Ten-GigabitEthernet1/0/2
#      
irf-port 1/2
port group interface Ten-GigabitEthernet1/0/3
port group interface Ten-GigabitEthernet1/0/4
#
irf-port 2/1
port group interface Ten-GigabitEthernet2/0/3
port group interface Ten-GigabitEthernet2/0/4
#
irf-port 2/2
port group interface Ten-GigabitEthernet2/0/1
port group interface Ten-GigabitEthernet2/0/2
#
[5900-DC-A]display irf link 
Member 1
IRF Port    Interface                       Status
1            Ten-GigabitEthernet1/0/1        UP    
             Ten-GigabitEthernet1/0/2        UP    
2            Ten-GigabitEthernet1/0/3        UP    
             Ten-GigabitEthernet1/0/4        UP   
Member 2
IRF Port    Interface                       Status
1            Ten-GigabitEthernet2/0/3        UP   
             Ten-GigabitEthernet2/0/4        UP 
2            Ten-GigabitEthernet2/0/1        UP    
             Ten-GigabitEthernet2/0/2        UP    

Datacenter B:

irf-port 1/2
port group interface Ten-GigabitEthernet1/0/1
port group interface Ten-GigabitEthernet1/0/2
port group interface Ten-GigabitEthernet1/0/3
port group interface Ten-GigabitEthernet1/0/4
#
irf-port 2/1
port group interface Ten-GigabitEthernet2/0/1
port group interface Ten-GigabitEthernet2/0/2
port group interface Ten-GigabitEthernet2/0/3
port group interface Ten-GigabitEthernet2/0/4
#
[5900-DC-B]display irf link
Member 1
IRF Port    Interface                       Status
1           disable                         -
2           Ten-GigabitEthernet1/0/1         UP    
             Ten-GigabitEthernet1/0/2        UP    
             Ten-GigabitEthernet1/0/3        UP    
             Ten-GigabitEthernet1/0/4        UP   
Member 2
IRF Port    Interface                       Status
1           Ten-GigabitEthernet2/0/1         UP
             Ten-GigabitEthernet2/0/2        UP    
             Ten-GigabitEthernet2/0/3        UP   
             Ten-GigabitEthernet2/0/4        UP
 2           disable                         --    

Encaminhamos as seguintes questões para o time de HPN:

–          Qual a diferença na prática entre os 2 cenários?

–          Qual dos dois seria o mais recomendado?

Recebemos a seguinte recomendação:

De fato esta pergunta é muito comum, pois como criamos duas portas virtuais IRF (x/1 e x/2), sempre existe esta dúvida no caso de implementação de um par de switches. Bem, para um par de switches, não existe diferença lógica das duas implementações e também não existe benefícios de uma ou de outra, como o exemplo abaixo destas configurações:

A diferença realmente ocorre quando você precisa configurar três ou quatro unidades, pois neste caso você precisa criar uma topologia em anel, conforme o desenho, e isso requer a configuração das portas 1 e 2 devidamente conectadas:

Contudo, novamente, para um par de switches não tem diferença.

My cents

Comware: Port mirroring – Espelhamento de porta

O espelhamento de porta é uma técnica que permite que o Switch efetuar a cópia dos pacotes de uma porta para outra porta.

Essa técnica é bastante utilizada quando precisamos analisar o comportamento da rede, como por exemplo, para identificação de vírus, acessos “estranhos”, comportamento de aplicações, serviços, etc.

Comware7 – Roteamento Multicast: PIM Dense-mode

A principal função de qualquer protocolo de roteamento dinâmico é auxiliar os roteadores no processo de encaminhamento dos pacotes com a utilização do melhor caminho para um determinado destino. As informações inseridas na tabela de roteamento incluem principalmente: a rede de destino, a forma de aprendizado da rota e o próximo salto, para endereços de rede unicast.

Entretanto quando um roteador recebe um pacote com endereço IPv4 multicast, ele não consegue encaminhar o pacote utilizando a tabela de roteamento IPv4 unicast pois os endereços multicast não são inseridos na tabela.

Os roteadores podem encaminhar os pacotes multicast somente através dos protocolos de roteamento como o multicast dense-mode sparse-mode, que se utilizam da tabela de roteamento unicast para encaminhamento do trafego.

Nesse artigo abordaremos o processo dense-mode para encaminhamento de tráfego IPv4 multicast.

Dense-mode

Os protocolos de roteamento multicast dense-mode assumem que um grupo multicast será solicitado em cada sub rede por ao menos um receptor (receiver). O design do dense-mode instrui o roteador para encaminhar o tráfego multicast em todas interfaces configuradas com dense-mode. Há algumas exceções para prevenção de loop, como validar se o endereço de origem do pacote, possui uma rota no roteador para interface que recebeu aquele pacote (RPF) e então nesse caso ele enviaria uma cópia do trafego multicast para todas as interfaces exceto aquela que o pacote foi recebido. 

Os roteadores com dense-mode entendem que todas as sub rede desejam receber uma cópia do tráfego multicast, exceto quando outros roteadores (downstream) não desejam receber o tráfego para aquele grupo ou quando um host diretamente conectado não deseja juntar-se ao grupo multicast. Quando essas condições são encontradas, os roteadores enviam mensagens de poda (prune message) para cessar o tráfego naquele segmento.

Falando do  RPF

Os protocolos de roteamento multicast usam a verificação de encaminhamento inverso (RPF – Reverse Path Forwarding) para garantir a entrega fluxo multicast criando entradas de roteamento multicast com base nas rotas unicast existentes ou rotas multicast estáticas. A verificação de RPF também ajuda a evitar loops de dados. Um fluxo multicast de entrada não será aceito ou encaminhado a menos que o fluxo seja recebido em uma interface de saída para a rota unicast no cabeçalho de origem do pacote.

No exemplo abaixo, o Roteador R4, irá apenas aceitar e encaminhar o fluxo multicast gerado pelo Multicast Sender 10.1.1.1 para o receiver, se recebido pela interface G0/0.

Falando um pouco mais do PIM  Dense-mode…

O protocolo de roteamento multicast PIM (Protocol Independent MulticastDense-mode, define uma serie de mensagens e regras para a comunicação eficiente de pacotes multicast; ele atua de forma independente do protocolo de roteamento IPv4 unicast, mas utilizando a tabela de roteamento unicastpara validação RPF. O protocolo PIM simplesmente confia na tabela de roteamento unicast.

O PIM estabelece relacionamento com seus vizinhos utilizando mensagens Hello que são enviadas a cada 30 segundos utilizando o protocolo IP 103 e o endereço 224.0.0.13 (All-PIM-Routers), o holdtimer geralmente é três vezes o tempo do hello. Caso o roteador não receba a mensagem hello durante o holdtime, ele considera a perda de adjacência com o vizinho.

Source-Based Distribution Tree

Quando um roteador PIM-DM recebe um pacote multicast, ele primeiro executa uma validação RPF. Uma vez que a validação confirmada, o roteador encaminha uma cópia do pacote multicast para todos os roteadores vizinhos com PIM-DM, exceto aquele que ele recebeu o pacote. Cada roteador PIM-DM repete todo o processo e inunda a rede com o trafego do grupo multicast, até o ultimo roteador da topologia – que não possui roteadores vizinhos abaixo (downstream).

Todo esse processo é chamado source-based distribution tree, shortest path tree (SPT) ou source tree. O tree (arvore) define o caminho entre source que origina o trafego multicast e o receiver, que recebe uma cópia do trafego multicast. O source é considerado a raiz e as sub redes como galhos e folhas das arvores.

O PIM-DM pode ter diferentes “arvores de distribuição” para cada combinação da origem do grupo multicast, pois o SPT irá se basear na origem e localização dos hosts de cada grupo multicast. A notação (S,G) refere-se a cada particular SPT, onde S é o endereço IP de origem  e G é o endereço do grupo multicast, como por exemplo (192.168.1.10,226.1.1.1).

Fazendo a poda – Prune message

Quando uma sub rede não precisa de uma cópia do trafego multicast o PIM-DM define um processo para os roteadores remover suas interfaces do SPT utilizando as mensagens PIM Prune.

A mensagem PIM Prune é enviada por um roteador a um segundo roteador para remover o link em que a poda é recebida para um particular (S,G) SPT.

Em razão do PIM-DM querer encaminhar o trafego para todas as interfaces (com o PIM configurado), após 3 minutos de receber uma mensagem de poda, ele retorna o encaminhamento de trafego multicast naquela interface. Caso o roteador que enviou a mensagem Prune não queira continuar recebendo o trafego multicast, ele enviara novamente a mensagem de poda. O processo de encaminhamento e poda ocorre periodicamente. As ramificações (sub-redes) podadas reiniciam o encaminhamento multicast quando o estado de poda expira e, em seguida, os dados são inundados novamente nesses segmentos de rede e, em seguida, os ramos são cortados novamente…

Graft

Quando um receptor em um segmento podado anteriormente se une a um grupo multicast, uma opção é esperar que os links podados, expirem. Entretanto, para reduzir a latência do join a um grupo multicast, O PIM-DM usa um mecanismo chamado graft para retomar o encaminhamento de dados para esse segmento, sem esperar que o tempo do prune expire.

Uma vez que o roteador envie a mensagem graft para um vizinho, que havia enviando uma mensagem prune anteriormente, o roteador irá encaminhar a porta para o estado de encaminhamento para determinado (S,G) SPT.

Assert

O mecanismo de assert desliga os fluxos de multicast duplicados para a mesma rede, onde mais de um roteador multicast encaminha o trafego para a LAN, ao eleger um encaminhador multicast exclusivo na rede local. Seguindo seguinte processo:

1. O roteador anuncia a menor distancia administrativa do protocolo de roteamento utilizado para aprender a melhor rota.

2. Se houver empate, o roteador escolhido terá a menor métrica para a origem

3. Se houver um novo empate, o roteador escolhido será o que tiver o maior endereço IP na interface local.

Exemplo de Configuração do PIM DM

No cenário abaixo, uma máquina da rede 192.168.2.0/24 deseja receber o fluxo multicast com o endereço 239.1.1.1. O Sw2 está configurando com OSPF e PIM o estabelecimento do roteamento Unicast e Multicast da rede.

Configuração de Sw2

#
vlan 2
vlan 12
#
interface Vlan-interface2
 ip address 192.168.2.1 255.255.255.0
 igmp enable
! Habilitando a interface para troca de mensagens IGMP
#
interface Vlan-interface12
 ip address 192.168.12.2 255.255.255.0
 pim dm
! Habilitando o PIM DM para Roteamento Multicast com o R1 
#
ospf 10
 area 0.0.0.0
  network 192.168.2.0 0.0.0.255
  network 192.168.12.0 0.0.0.255
! Configurando o OSPF para o Roteamento Unicast
#

Configuração de R1 (Roteador MSR)

multicast routing
#
interface GigabitEthernet 0/0
 ip address 192.168.1.0 255.255.255.0
 pim dm
#
interface GigabitEthernet 0/1
 ip address 192.168.12.1 255.255.255.0
 pim dm
#
ospf 10
 area 0.0.0.0
  network 192.168.1.0 0.0.0.255
  network 192.168.12.0 0.0.0.255
#

Comandos display

[Sw2]display pim neighbor
 Total Number of Neighbors = 1

 Neighbor        Interface           Uptime   Expires  DR-Priority Mode
 192.168.12.1    Vlan12              00:48:12 00:01:15 1           P
[Sw2]

[Sw2]display pim routing-table
 Total 0 (*, G) entry; 1 (S, G) entry
 (192.168.1.99, 239.1.1.1)
     Protocol: pim-dm, Flag:
     UpTime: 00:44:52
     Upstream interface: Vlan-interface12
         Upstream neighbor: 192.168.12.1
         RPF prime neighbor: 192.168.12.1
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlan-interface2
             Protocol: static, UpTime: 00:44:52, Expires: -
[Sw2]

Referências

HP 5920 & 5900 Switch Series – IP Multicast Configuration Guide

Comware: Comando “logging synchronous”

Para aqueles que estão acostumados com o comando “logging synchronous” no IOS existe a opção “info-center synchronous” para o Comware

 [4800G]info-center synchronous
% Info-center synchronous output is on

Segue o output com o comando habilitado:

[4800G]interface GigabitEthernet 1/0/
%Apr 26 09:25:32:201 2000 4800G IFNET/4/LINK UPDOWN:
GigabitEthernet1/0/2: link status is DOWN
[4800G]interface GigabitEthernet 1/0/

Segue o output com o commando desabiiltado (percebam o comando “em digitação” fica oculto e assim comprometendo a configuração, tornando suceptível a erros:

[4800G]interface GigabitEthernet 1/0/
%Apr 26 10:42:36:371 2000 4800G IFNET/4/LINK UPDOWN:
GigabitEthernet1/0/2: link status is UP

Abraços a todos

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

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