Wireless Aruba – Modo de encaminhamento para os Access Points

Quando uma estação encaminha seus quadros para um Ponto de Acesso, existem diversas maneiras para o AP processar e encaminhar os dados, tudo dependendo de como o Access Point é configurado. 

Um Access Point configurado como IAP não necessita de uma Controller, pois todos os AP que estão na mesma sub rede irão formar um Cluster Virtual e operam independente da Controladora física.

Já os Pontos de acesso gerenciado por uma Controladora, devem ter seu tráfego permitido na rede (caso haja restrições de tráfego na rede).

O modo de encaminhamento (forwarding mode) define como os dados enviados pelo usuário são encaminhados pelo AP e podem ser classificados como:

  • GRE/tunnel
  • Bridge
  • Decrypt-tunnel
  • Split-Tunnel

Alguns termos nesse texto são utilizados com o mesmo significado:

Controladora = Controller = Mobility Controller

Quadros = Frames

Access Point = AP = Ponto de Acesso

GRE/Tunnel

Esse modo utiliza um Tunnel GRE para encaminhar os dados do Access Point para a Mobility Controller. Quando um cliente envia um dado para um SSID (em um AP) que é configurado para utilizar o forwarding mode como tunnel mode, o AP encapsula o quadro 802.11 dentro de um frame 802.3 e encaminha o quadro para a Controladora Aruba.

Nesse processo nem todos os frames são tunelados e encaminhados a controladora, os quadros 802.11 para autenticação e resposta de associação são gerados diretamente no AP.

Para o tráfego que é encapsulado e enviado a controladora, a Mobility Controller removerá o encapsulamento no recebimento, aplicará regras de firewall ao tráfego do usuário e encaminhará o tráfego como solicitado.

Um Access Point Aruba configurado como Campus (CAP), todo tráfego de controle é comunicado com a controladora utilizando o protocolo PAPI, que não é criptografado. Caso haja a necessidade de criptografar a comunicação PAPI é sugerido a utilização juntamente com o CPsec (Control Plane Security) que criptografa a comunicação PAPI com IPsec.

Já os APs configurados como Remote (RAP), a comunicação deverá utilizar um túnel VPN L2TP/IPsec.

Com o modo túnel, todo tráfego é enviado para a Controller que é responsável por prover a visibilidade das configurações e trafego dos usuários de forma centralizada, facilitando a configuração das redes WLAN.

Bridge

O mode bridge permite ao Access Point (não a Controladora) processar os quadros, de forma similar aos APs individuais processam as informações. O AP irá responder qualquer requisição de autenticação e associação com as respostas referentes ao processo, removendo a criptografia dos frames recebidos  e criptografando os quadros de saída para a estação.

 O modo bridge também pode ser configurado em APs configurados como CAP e RAP, mas a sua comunicação com a Mobility Controller deverá ser criptografada com CPsec (CAP) e túnel L2TP/IPsec para RAP.

A Aruba não recomenda esse modo em razão do firewall stateful não ser aplicado.

Decrypt-Tunnel

Este método possui similaridade com o modo tunnel, entretanto os quadros enviados pelo cliente têm a sua criptografia removida e encaminhada dessa forma para a Controladora, encapsulando apenas o quadro 802.11 em um quadro 802.3.

Uma imagem contendo captura de tela

Descrição gerada automaticamente

Esse cenário pode ser utilizado para propósitos de segurança para inspeção e monitoração do tráfego por outras ferramentas ou diminuir o processamento ocorrido no processo de criptografia.

O modo decrypt só pode ser utilizado com RAP e CAP. Todo trafego de sinalização entre a controladora e o ponto de acesso deve ser criptografada com CPsec(CAP) ou L2TP/IPsec (RAP).

O modo decrypt deve ter uma atenção especial em cenários com RAP, pois o tráfego do usuário não é criptografado pelo RAP, criando um risco de segurança para o tráfego sobre a rede pública (Internet).

Split Tunnel

O modo split tunnel é disponível nos RAPs, e é também conhecido com policy-based forwarding.  Quando um RAP constrói um tunnel L2TP/IPsec com a Controladora, não é recomendável encaminhar todo tráfego de usuário pela Internet para a Mobility Controller, por isso é possível criar regras de encaminhamento de firewall para processar o tráfego wireless diretamente no RAP. Essas regras podem permitir o tráfego dos usuários serem encaminhado localmente ou para a Controladora, de acordo com as necessidades, como por exemplo, o trafego HTTP/HTTPS sair diretamente para a Internet.

Referências

Aruba Certified Design Professional_ Official Certification Study Guide ( HPE6-A47)

Westcott, David. – Understanding ArubaOS

Resumo HP EVI

O EVI é uma tecnologia Overlay para transporte de tráfego L2, configurado em Switches e Roteadores HP. A tecnologia é baseada no protocolo IP para interconexão entre Data Centers. O EVI encapsula o tráfego Ethernet utilizando túneis GRE entre cada nó. O EVI utiliza MAC-over-GRE-over-IP para entrega de quadros Ethernet. Os pacotes GRE/IP são roteados sobre a conexão WAN entre os DCs.

encapsulamento-evi

Pelo fato do EVI utilizar o padrão GRE, o tráfego poderá ser encaminhado por qualquer infraestrutura IP para estender domínios de broadcast.

Quando um endereço MAC é aprendido, o nó EVI daquele Data Center anuncia o endereço via IS-IS para os sites remotos. Os sites remotos mapeiam o endereço MAC para o link no qual ele foi aprendido.

evi-logica

Terminologia EVI

Edge device – Switch ou Roteador em um Data Center que prove o serviço EVI, aprendizado local de endereço MAC, adjacência IS-IS com os dispositivos remotos e também o anuncio dos endereços MAC locais para seus os pares remotos.

EVI network ID –  identificador único dos edge devices. Cada edge device pode assinar múltiplos IDs para ambientes multi-tenants. O network ID certifica que o aprendizado de endereços MAC continua separado e privado.

Extended VLAN – são as VLANs que você decide estender com o EVI.

EVI Neighbor Discovery Protocol (ENDP) – prove o registro do serviço do endereço IP e é utilizado entre sites conectados via tuneis GRE. O ENDP pode definir a função de cliente e servidor para os nós EVI.

EVI Process

O processo de uma rede EVI pode ser descrito em três fases: descoberta de vizinhos, anuncio de endereços MAC e encaminhamento de dados.

A descoberta de vizinhos ENDP ocorre nos edge devices que registram seus endereços IP com o servidor ENDP. Cada ENDP consulta o servidor para aprendizado e tuneis GRE são formados automaticamente entre os edge devices.

Uma vez que a rede é totalmente estabelecida, o encaminhamento de dados pode ocorrer. O tráfego local é recebido e os endereços de destino remotos são encontrados na tabela MAC do EVI.

Configurando o EVI Neighbor Discovery (ENDP)

O servidor ENDP pode ser habilitado em qualquer EVI edge device e para fins de redundância. Dois ENDP servers podem ser configurados em cada network ID.

ENDP Server

evi neighbor-discovery server enable
*evi neighbor-discovery client enable x.x.x.x

* caso haja redundância de NDPServer

ENDP client

evi neighbor-discovery client enable x.x.x.x

Configurando o EVI Site-ID

Cada site deve conter um unico Site ID. dispositivos no mesmo site devem ser configurados com o mesmo site ID

[Site1-Switch] evi site-id 1 

[Site2-Switch] evi site-id 2

Configurando  a interface EVI (transporte para a rede IP)

vlan 4001
#
interface vlan 4001
ip add 10.1.0.1 24
#
interface giga 3/0/1
port access vlan 4001
evi enable

A interface de transito deve ser configurado no edge device, na porta diretamente conectada à rede IP de transporte.

Configurando a interface Tunnel

[Site1-Switch] interface tunnel 1 mode evi
[Site1-Switch-Tunnel1] source 10.1.0.1

Cada rede EVI requer uma interface Tunnel única.

O ID da interface Tunnel também fará referência ao processo EVI IS-IS Process ID. Uma vez que a interface tunnel1 é criada um processo EVI IS-IS 1 será criado.

Configurando o EVI network ID

[Site1-Switch-Tunnel1] evi network-id 101

O tunnel EVI deve ser mapeado com um EVI Network ID. O range valido é um número entre 1 e 16777215

Configurando as VLANs estendidas

[Site1-Switch-Tunnel1]  evi extended-vlan 100 to 199

O mapeamento de extensão de VLANs deve ser feito dentro da interface Tunnel e não na interface de transporte.

Exemplo de Configuração

No exemplo abaixo faremos a extensão das VLANs 2 até 10 entre os Datacenters DC 1 e DC4 utilizando o EVI para transporte L2 dos quadros Ethernet sobre uma infraestrutura IP. O OSPF será o protocolo para anuncio das rotas diretamente conectadas incluindo loopbacks.

O Roteador R1 será o ENDP Server enquanto R4 será o ENDP client.

evi-fisica

 R1

#
interface LoopBack1
ip address 192.168.1.1 255.255.255.255
ospf 1 area 0.0.0.0
#
interface GigabitEthernet2/0
port link-mode route
ip address 192.168.14.1 255.255.255.248
ospf 1 area 0.0.0.0
evi enable
#
interface GigabitEthernet3/0
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 to 10
#
interface Tunnel1 mode evi
ip address 10.1.14.1 255.255.255.248
evi extend-vlan 2 to 10
source 192.168.1.1
keepalive 20 2
evi network-id 1
evi neighbor-discovery server enable
#
evi site-id 1
#

R4

#
interface LoopBack1
ip address 192.168.4.4 255.255.255.255
ospf 1 area 0.0.0.0
#
interface GigabitEthernet1/0
port link-mode route
ip address 192.168.14.4 255.255.255.248
ospf 1 area 0.0.0.0
evi enable
#
interface GigabitEthernet3/0
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 to 10
#
interface Tunnel1 mode evi
ip address 10.1.14.4 255.255.255.248
evi extend-vlan 2 to 10
source 192.168.4.4
keepalive 20 2
evi network-id 1
evi neighbor-discovery client enable 192.168.1.1
#
evi site-id 4

Comandos display

<R1> display  evi isis lsdb
                Link state database information for EVI IS-IS(1)
LSP ID                 Seq num     Checksum  Holdtime  Length    Overload
---------------------------------------------------------------------------
cc3e.5f81.9f7b.00-00   0x00000021  0x84e2    1137      100       0
cc3e.5f81.a1f9.00-00*  0x00000022  0xddc3    964       100       0
cc3e.5f81.a1f9.02-00*  0x0000000b  0xec7f    734       54        0
Flags: *-Self LSP, +-Self LSP(Extended)
<R1> display  evi isis peer
Process ID: 1
System ID: cc3e.5f81.9f7b
Link interface: EVI-Link0
Circuit ID: cc3e.5f81.a1f9.02
State: Up
Site ID: 4
Hold time: 20s
Neighbour DED priority: 64
Uptime: 02:23:05

<R1> display  evi neighbor-discovery server member
Interface: Tunnel1    Network ID: 1    Vpn-instance: [No Vrf]
IP Address: 192.168.1.1
Client Address  System ID         Expire    Created Time
192.168.1.1     cc3e-5f81-a1f9    73        2016/10/21 10:48:08
192.168.4.4     cc3e-5f81-9f7b    69        2016/10/21 10:48:10

[R1]display mac-address
MAC Address      VLAN ID    State            Port/NickName            Aging
cc3e-5f81-3333   2          Learned          GE1/0                    Y
cc3e-5f81-eeee   9          Learned          GE1/0                    Y

[R1]display  evi mac-address interface Tunnel 1
MAC Address          VLAN ID   Port
cc3e-5f81-ffff       9         EVI-Link0
cc3e-5f81-2222       2         EVI-Link0

Referências

https://www.hpe.com/h20195/v2/GetPDF.aspx/4AA5-6737ENW.pdf

https://cjaiwenwenblog.wordpress.com/2016/02/04/how-to-configure-hp-evi-ethernet-virtual-interconnect/

Building HP FlexFabric Data Centers-Rev. 14.41

Comware 7 – Configurando o GRE

O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de tuneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.

O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como o GRE não faz a criptografia, o GRE pode trabalhar em conjunto com IPsec para garantir a integridade das informações quando necessário.

Abaixo podemos observar a representação do encapsulamento de um pacote IP pelo GRE como também a inclusão de um novo cabeçalho.

GRE header

O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.

Segue abaixo um exemplo de configuração de um túnel GRE para Roteadores com o Comware 7, fechando a adjacência OSPF entre 2 roteadores separados por uma rede MPLS. Nos testes usamos o roteador HP VSR1000.

comware 7 GRE

Tabela de Rotas e tracert do Roteador R2

[R2]disp ip routing-table | inc O
192.168.1.0/24     O_INTRA 10  1563        192.168.13.1    Tun0

<R2>tracert 192.168.13.1
traceroute to 192.168.13.1 (192.168.13.1), 30 hops at most, 52 bytes each packet, press CTRL_C to break
 1  192.168.23.2 (192.168.23.2)  0.488 ms  0.523 ms  1.668 ms
 2  192.168.13.1 (192.168.13.1)  0.962 ms  5.463 ms  0.881 ms

<R2>tracert 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops at most, 52 bytes each packet, press CTRL_C to break
 1  192.168.1.1 (192.168.1.1)  1.116 ms  2.588 ms  1.731 ms

Referências

http://www.comutadores.com.br/roteadores-hp-6600-protocolo-de-tunelamento-gre/

http://www.rotadefault.com.br/protocolo-de-tunelamento-gre/

Roteadores HP 6600 – MPLS L2VPN com Martini através de um Túnel GRE

O script abaixo permite a extensão de um domínio de Broadcast através de uma rede IP utilizando o protocolo MPLS sobre um Túnel GRE sem a utilização de BGP em um roteador HP 6600.

Utilizei o cenário durante uma demanda para a extensão de um domínio de Broadcast entre 2 Data Centers Pares em quem o link dedicado para o Serviços de Computação em Nuvem sofreu atraso. O sincronismo dos Serviços  utilizando a camada de enlace (camada 2 do modelo OSI) foi estabelecido com a solução abaixo, visto que haviam restrições para configurar o mesmo serviço com MP-BGP por políticas de roteamento.

A solução permite o trânsito de quadros tagueados com 802.1q.

Obs: Antes de estabelecer o túnel GRE, certifique que as interfaces Loopback estejam acessíveis via Roteamento.

MPLS L2VPN Martini atraves de GRE

Espero ter sido útil. 🙂

Roteadores HP 6600 – Protocolo de Tunelamento GRE

O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de túneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.

O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como GRE não criptografa as informações que são transmitidas através do túnel, podemos utilizar o GRE em conjunto com IPsec para garantir a integridade das informações.

Abaixo podemos observar a representação de encapsulamento  de um pacote IP pelo GRE e a  inclusão de um novo cabeçalho.

GRE header

O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado  poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.

Agora você deve estar se perguntando. Em quais situações podemos usar o GRE ? Veja  o cenário:

GRE HPN cenario

Você em um dia normal como analista de redes e seu gerente de TI te informa que  sua   empresa acaba de adquirir uma nova filial e eles precisam ter acesso a alguns servidores que   estão na rede local do ambiente que você administra.  Depois de concluir todo processo de contratação do link e a conectividade com a filial estar finalizada, seu gerente de TI lhe informa   que na nova filial utilizará OSPF para declarar as redes locais.

Agora você pensa: como podemos configurar o OSPF nesses roteadores se eles não estão diretamente conectados? Como administrar o processo de roteamento via uma rede gerenciada pela Operadora como por exemplo, com MPLS,  que não está emulando um Lan-to-Lan ? É ai que entra o Túnel GRE.

Configuração

Antes de criar o tunnel, certifique-se que a origem e o destino mapeados na Interface Tunnel estejam acessíveis via roteamento. No nosso exemplo, usaremos  a Loopback.

Como os roteadores simularão uma conexão ponto-a-ponto, eles irão trocar informações  de  roteamento através do túnel como se estivessem diretamente conectados.

GRE HPN configuração v2

Por padrão o Comware habilita o protocolo GRE em túneis sem a necessidade de configuração adicional. Caso você precise utilizar uma Interface Tunnel para alguma outra função, segue abaixo algumas possibilidades:

 

[RA-Tunnel10]tunnel-protocol ?
  dvpn       Dynamic Virtual Private Network
  gre        Generic Routing Encapsulation
  ipsec      IPsec tunnel encapsulation
  ipv4-ipv4  tunnel mode ipv4 over ipv4
  ipv4-ipv6  tunnel mode ipv4 over ipv6
  ipv6-ipv4  tunnel mode ipv6 over(to) ipv4
  ipv6-ipv6  tunnel mode ipv6 over ipv6
  mpls       Multiprotocol Label Switching

Considerações para a utilização de Tunnel em Switches HP baseados no Comware

A utilização de interface Tunnel em Switches HP baseados no Comware pode ser um pouco mais complicada que em roteadores. Antes de utilizarmos o processo acima  é necessário criar uma configuração de “Service Loopback” (em alguns modelos de Switches), vincular à uma porta não utilizada (vazia) e também vincular o serviço ao Tunnel. Segue abaixo os passos:

• Crie um “tunnel-type service loopback group’.

• Adicione uma porta não utilizada ao “Service loopback group”.

# Criando o “Service-loopback” group 1 e especificando o tipo como tunnel.
[SwitchA] service-loopback group 1 type tunnel

# Vinculando a porta Giga 1/0/3 para o “Service-loopback” group 1. 
#Desabilite o STP e o LLDP da interface.
[SwitchA] interface GigabitEthernet 1/0/3
[SwitchA-GigabitEthernet1/0/3] undo stp enable
[SwitchA-GigabitEthernet1/0/3] undo lldp enable
[SwitchA-GigabitEthernet1/0/3] port service-loopback group 1
[SwitchA-GigabitEthernet1/0/3] quit

# Aplique  o “Service-loopback” group 1 à interface tunnel.
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] service-loopback-group 1
[SwitchA-Tunnel0] quit
# O tunnel ficará up mesmo que a outra ponta não esteja configurada

Até a próxima 

Referência

http://www.rotadefault.com.br/protocolo-de-tunelamento-gre/