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

Wireless Aruba – Rogue Containment (WIPS)

A configuração de WIPS com Rogue Containment permite ao Access Point atuar diretamente contra o serviço WiFi fornecido indevidamente. Uma vez que a funcionalidade tem como objetivo derrubar o serviço dos AP classificados como rogue, alguns tipos de contenção podem impactar redes vizinhas, protegendo nossa própria rede, mas atacando os SSIDs válidos de nossos vizinhos. Entender todo o processo de mitigação e responsabilidades do administrador são fundamentais para o correto funcionamento e implantação do serviço.

Um Rogue Access Point é um ponto de acesso wireless que foi instalado em uma rede sem autorização do administrador da rede local, podendo ter sido instalado por um usuário legítimo que desconheça as implicações desta conduta ou deliberadamente por alguém com o intuito de atacar a Rede sem Fio. Em qualquer caso, um rogue AP representa uma séria ameaça à segurança da rede.

Wireless Intrusion Protection (WIP)

As técnicas de contenção dos dispositivos wireless da Aruba podem mitigar o acesso aos pontos de acesso rogue no modo wired (cabeada) e wireless (sem fio).

O wired containment é executado através de ARP Poisoning, envenenando o default gateway do Rogue AP na rede cabeada. O ponto de acesso Aruba configurado como AP ou AM irá executar a contenção, mas eles necessitam estar na mesma VLAN que o rogue para sucesso no containment.

A contenção via Wireless pode ser executada de duas maneiras: deauth e tarpitting.

Deauth.

O AP Aruba irá enviar frames deauthentication, para o rogue AP e seus clientes. O cliente poderá iniciar a reconexão, então o AP Aruba enviará uma nova mensagem deauthentication, assim sucessivamente.


Tarpit

O AP Aruba irá enviar frames deauthentication para o rogue AP e seus clientes, quando o cliente tentarem a reconexão, o AP Aruba enviará uma respostacom dados falsos induzindo o cliente (STA) a conectar no AP Aruba, ao invés do rogue, mas sem oferecer os dados para navegação.

Tarpitting é o processo no qual um AP Aruba personifica um AP não autorizado, incentivando o cliente não autorizado se conectar ao AP Aruba (quando antes conectado a um rogue AP) e, em seguida, o Aruba AP ou AM (AP no modo monitor) não responderá aos clientes, o direcionando a um canal não utilizado. O STA indicará que está conectado à rede sem fio, mas não obterá um endereço IP nem será capaz de transmitir tráfego.

O tarpit pode ser configurado como Tarpit-non-valid-sta, para os clientes não válidos, ou tarpit-all-sta para todos clientes.

Radio

Os Radios nos Access Point Aruba, podem ser configurados em diferentes modos: AP mode, Air Monitor (AM) e Spectrum Monitor (SM), para análise de espectro.

Os APs no modo AM são sempre recomendados quando o contaiment é habilitado. Os APs (modo AP mode) podem executar a contenção, mas em casos que os rogue estiverem no mesmo canal que o Aruba. Os APs podem também mudar de canal para contenção do rogue, mas o encaminhamento do tráfego dos cliente sempre será priorizado (a funcionalidade “Rogue AP Aware” deve estar habilitada no ARM profile. Já os AMs alocam seus recursos para contenção de rogues. Existem muitas opções automáticas de contenção que vão além de ‘conter se o dispositivo for classificado como rogue’.

As opções mais seguras e comuns são “Protect Valid Stations” e “Protect SSID“. Qualquer estação (STA) que tenha sido autenticada na infraestrutura Aruba com criptografia será automaticamente classificada como válida. Quando isso acontecer, a rede Aruba não permitirá a estação conectar-se a qualquer outra rede se “Protect Valid Stations” estiver ativado.

O Protect SSID conterá automaticamente quaisquer APs não válidos que estão transmitindo os SSIDs da Controller.

Colocando em produção

Antes de colocar as funcionalidades de contenção em produção, execute os testes em ambiente de laboratório. Inicialmente catalogando, classificando e identificando os SSIDs identificados pelo WIDS.

 Uma vez identificada e classificada as redes, escolha habilitar o WIPS com o modo de contenção em um ambiente isolado e de laboratório. Analise os logs gerados e identifique o comportamento gerado pelos APs durante o envio dos frames de desconexão, clientes, APs e SSIDs listados durante todo esse processo de homologação.

Preocupe-se com os SSIDs anunciados pelos vizinhos e assim evitando não gerar um ataque de negação de serviço (DoS) a rede sem fio deles.

Na Mobility Master Aruba (managed networks), visualize essas informações em:

Dashboard > Security

Clicando em qualquer um dos eventos é possível analisar os logs.

Se possível, utilize use uma ferramenta para analisar os frames 802.11 enviados pela infraestrutura Aruba (com o modo de contenção ativo), como o wireshark e com uma interface usb wireless do notebook em modo monitor, por exemplo.

Filtros no Wireshark para visualizar deauthentication frames wlan.fc.type_subtype==0x0c

Filtros no Wireshark para visualizar disassociation frames wlan.fc.type_subtype==0x0A

Filtros no Wireshark para visualizar um endereço MAC especifico
eth.addr == ff:ff:ff:ff:ff:ff

Referências

https://www.arubanetworks.com/assets/tg/TG_WIP.pdf

https://en.wikipedia.org/wiki/Rogue_access_point

Kolokithas, Andreas. Hacking Wireless Networks – The ultimate hands-on guide,2015

Comware 7 – Configuração manual de túnel VXLAN

Esses dias navegando na web, encontrei um lab sobre VXLAN no blog http://www.nullzero.co.uk/lab-on-a-laptop/ utilizando o Roteador Virtual HP VSR 1000 na versão E0321. O post simula um cenário Spine/Leaf com a configuração manual de túneis VXLAN. Acredito que o mesmo cenário possa ser replicado em Switches físicos da HP que possuam foco em Datacenter.

O download do HP VSR pode ser feito aqui: https://h10145.www1.hpe.com/Downloads/SoftwareReleases.aspx?ProductNumber=JG811AAE&lang=en&cc=us&prodSeriesId=5443163

A instalação do HP VSR 1000 no VMWARE pode ser encontrado aqui: http://www.comutadores.com.br/instalando-o-hp-vsr1000-no-vmware-workstation/

Falando de VXLAN

O padrão VXLAN (Virtual eXtensible Local Area Network) trabalha em cima da limitação da quantidade de VLANs em um Data Center que é a de 4K VLANs. O Protocolo VXLAN emprega MAC sobre IP/UDP, e permite assim aumentar o número de domínios de Broadcast para 16 milhões.

vxlan-frame-550x104

Imagem  do site  http://blogs.cisco.com/datacenter/cisco-vxlan-innovations-overcoming-ip-multicast-challenges/

O VXLAN prove uma rede de camada 2 sobreposta em uma rede de camada 3. Cada rede sobreposta é chamada de segmento VXLAN e é identificada por um ID único de 24 bits chamado VNI – VXLAN Network Identifier ou VXLAN ID.  A identificação de um host é uma combinação do endereço MAC e o VNI.  Os hosts situados em VXLAN diferentes não podem comunicar entre si (sem a utilização de um roteador). O pacote original enviado por um host na camada 2 é encapsulado em um cabeçalho VXLAN que inclui o VNI associado ao segmento VXLAN que aquele host pertence.

Os equipamentos que transportam os tuneis VXLAN são chamados de VTEP (VXLAN tunnel endpoints).

dominio-de-broadcast-vxlan

 

Parte teórica da configuração no Comware

Os equipamentos HP com suporte ao VTEP utilizam VSIs e VXLAN tunnels para prover os serviços VXLAN.

  • O VSI é uma instancia virtual de comutação (virtual switching instance) que serve para criar o encaminhamento de quadros, utilizando diversos protocolos, incluindo o VXLAN. Os VSIs aprendem endereços MAC e encaminham quadros de forma independente sobre uma infraestrutura L3 emulando um cenário de switches diretamente conectados, mesmo que separadas por um backbone IP.
  • Um VXLAN tunnel é um túnel lógico, ponto-a-ponto entre VTEPs sobre a rede de transporte, rede IP por exemplo. Cada VXLAN tunnel pode encaminhar multiplos VXLANs, assim como uma interface trunk que transporta multiplas VLANs.

Configuração

vxlan-comware-lab

Em nosso cenário os equipamentos estão conectados conforme topologia spine/leaf utilizando interfaces no modo route com IPv4 e  OSPF como IGP para anuncio  das interfaces, incluindo interfaces loopback. Toda a configuração para criação do Tunnel e atribuição da VXLAN será efetuada nos equipamentos Leaf.

A configuração das interfaces de trânsito, loopback e OSPF foram omitidas na configuração abaixo.

Segue abaixo a configuração do VXLAN tunnel e o VXLAN Id 10000:

 

Configuração do LEAF 3
#
interface Tunnel1 mode vxlan
 source 10.1.1.3
 destination 10.1.1.4
! Criando a interface Tunnel 1 no modo VXLAN
#
 l2vpn enable
! Ativando o serviço L2VPN
#
vsi cliente_a
 vxlan 10000
  tunnel 1
! Criando a instancia VSI Cliente A, com o VXLAN ID 10000 atribuído ao tunnel1
#
interface GigabitEthernet4/0
 port link-mode route
 description host-A
 xconnect vsi cliente_a
! Atribuindo o VSI a interface 4/0 conectada a máquina host-A
#

#

Configuração do LEAF 4
#
interface Tunnel1 mode vxlan
 source 10.1.1.4
 destination 10.1.1.3
#
 l2vpn enable
#
vsi cliente_a
 vxlan 10000
  tunnel 1
#
interface GigabitEthernet4/0
 port link-mode route
 description host-B
 xconnect vsi cliente_a

Validando a configuração

 [VSR LEAF 3]display vxlan tunnel
Total number of VXLANs: 1
VXLAN ID: 10000, VSI name: cliente_a, Total tunnels: 1 (1 up, 0 down)
Tunnel name          Link ID    State  Type
Tunnel1              0x5000001  Up     Manual

[VSR LEAF 3]display l2vpn mac-address vsi cliente_a
MAC Address      State    VSI Name                        Link ID/Name  Aging
000c-290b-dcc5   Dynamic  cliente_a                       Tunnel1       Aging
000c-29c5-5e8a   Dynamic  cliente_a                       0             Aging
--- 2 mac address(es) found  ---

Segue a configuração completa dos equipamentos SPINE 1 SPINE 2 LEAF 3 LEAF 4

Até logo

Referencias

http://www.rotadefault.com.br/introducao-a-vxlan/

 

Comware 7: Alterando a ACL para o modo L3 em uma Interface VLAN.

A dica abaixo foi encontrada enquanto eu navegava no site http://abouthpnetworking.com/2015/02/09/comware7-routed-port-acl-packet-filter-applies-to-switched-traffic/

A configuração de uma ACL para o filtro de pacotes em uma interface VLAN em Switches com o Comware 7, mesmo que seja para fins de roteamento, poderá ter o comportamento de uma VACL (VLAN ACL), isto é, mesmo que o pacote não seja roteado entre VLANs (e o tráfego seja entre máquinas internas), o Switch validará o tráfego com a ACL e dependendo da construção das regras, o pacote poderá ser descartado indesejadamente.

Este comportamento poderá ser controlado com o comando “packet-filter filter route” dentro da interface VLAN. Isto permitirá que o administrador decida se o tráfego será filtrado somente para o tráfego roteado (L3) ou se deixará no modo default, que é o filtro do tráfego L2 + L3.

 

[HP] interface vlan 20
[HP-Vlan-interface20] packet-filter 3003 inbound
! Aplicando  a ACL avançada na interface VLAN
[HP-Vlan-interface20] packet-filter filter route
! Configurando a ACL para somente filtrar o tráfego roteado 
# Caso queira retornar para o modo routed+switched digite comando abaixo.
 [HP-Vlan-interface20] packet-filter filter all

Até logo.

Sumarização manual com BGP aggregate

Para o anuncio de redes no processo BGP, utilizamos o comando “network” ou a redistribuição de rotas com o comando “import“.

Há também a possibilidade de manualmente sumarizarmos as redes no anuncio de prefixos para os roteadores vizinhos.  O comando BGP aggregate permite a sumarização manual (diferente do comando auto-summary), baseando-se em qualquer prefixo da tabela BGP.

No exemplo abaixo os ASN 11 e 12 anunciam cada um 2 prefixos /24 para o ASN 22.

BGP Aggregation

Sem a sumarização de rotas a tabela BGP estaria da seguinte forma para o Roteador do ASN 33:

 

[RoteadorASN33]display bgp routing-table ipv4
 Total number of routes: 4

 BGP local router ID is 192.168.23.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
* >e 192.168.0.0        192.168.23.2                          0       22 11i
* >e 192.168.1.0        192.168.23.2                          0       22 11i
* >e 192.168.2.0        192.168.23.2                          0       22 12i
* >e 192.168.3.0        192.168.23.2                          0       22 12i

Criando as rotas agregadas

O comando aggregate irá criar as rotas sumarizadas manualmente, iniciando o valor do AS path, simplesmente criando um novo anuncio de prefixos sumarizados sem omitir o anuncio das rotas mais especificas.

No exemplo abaixo, sumarizamos os prefixos do ASN 11 em apenas um prefixo /23:

! Configuração BGP do Roteador do ASN 22 com Comware 7

bgp 22
 peer 192.168.23.3 as-number 33
 peer 192.168.112.1 as-number 11
 peer 192.168.212.1 as-number 12
 #
 address-family ipv4 unicast
  aggregate 192.168.0.0 255.255.254.0
  peer 192.168.23.3 enable
  peer 192.168.112.1 enable
  peer 192.168.212.1 enable
#

Analisando a tabela BGP do Roteador do ASN 33 temos o seguinte output:

! tabela BGP do Roteador do ASN 33 com Comware 7
[RoteadorASN33]display bgp  routing-table ipv4
 Total number of routes: 5
 BGP local router ID is 192.168.23.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

* >e 192.168.0.0/23     192.168.23.2                          0       22i
* >e 192.168.0.0        192.168.23.2                          0       22 11i
* >e 192.168.1.0        192.168.23.2                          0       22 11i
* >e 192.168.2.0        192.168.23.2                          0       22 12i
* >e 192.168.3.0        192.168.23.2                          0       22 12i

Se quisessemos omitir o anuncio dos prefixos mais especificos para os roteadores do ASN 33 acrescentariamos o comando detail-suppressed

  aggregate 192.168.0.0 255.255.254.0 detail-suppressed

Analisando novamente a tabela BGP do Roteador do ASN 33 temos o seguinte output (sem as rotas mais especificas do /23):

[RoteadorASN33]display bgp  routing-table ipv4
 Total number of routes: 3
 BGP local router ID is 192.168.23.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

* >e 192.168.0.0/23     192.168.23.2                          0       22i
* >e 192.168.2.0        192.168.23.2                          0       22 12i
* >e 192.168.3.0        192.168.23.2                          0       22 12i

Mantendo os ASN

Observem que a rota sumarizada pelo ASN 22, inclui apenas o seu próprio ASN no AS_PATH. Os ASN 11 e 12 também receberão a rota sumarizada pelo simples fato de seus ASes serem omitidas na sumarização. Esta ação introduz a possibilidade da criação de loop de roteamento em determinados cenários.

O parametro AS_PATH AS_SET resolve essa questão adicionando os ASes de origem. No exemplo abaixo estamos sumarizando também com um /22 para exemplificar a diferença do comando com as-set:

  aggregate 192.168.0.0 255.255.252.0 detail-suppressed as-set
  aggregate 192.168.0.0 255.255.254.0 detail-suppressed as-set

Essa configuração gera uma rota sumarizada contendo o conjunto de ASes, de 11 e 12 para a rede /22, e AS 11 para o /23, uma vez que o agregado contém rotas provenientes desses sistemas autônomos. No roteador do AS 33, podemos ver o caminho dos Ases na tabela BGP:

[RoteadorASN33]display bgp routing-table ipv4
 Total number of routes: 2
 BGP local router ID is 192.168.23.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
* >e 192.168.0.0/22     192.168.23.2                          0       22 {11 12}i
* >e 192.168.0.0/23     192.168.23.2                          0       22 11i

A seguinte lista resume as ações do comando aggregate para o anuncio de rotas sumarizadas:

  • as-set: Cria um sumario com os ASes.
  • attribute-policy route-policy-name: Permite aplicar atributos BGP na sumarização (exceto AS_PATH)
  • detail-suppressed: Somente anuncia a rota sumarizada
  • suppress-policy route-policy-name: Omite rotas especificas definidas na route-map. Permitindo que você deixe o anuncio apenas de algumas rotas mais especificas.
  • origin-policy route-policy-name: Seleciona apenas as rotas que satisfaçam a política de roteamento para sumarização.

 

Até logo

Referências

http://packetlife.net/blog/2008/sep/19/bgp-route-aggregation-part-1/

HP A8800 Configuration Guide – IP Routing

CCIE Routing and Switching CERTIFICATION Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue

 

Multitenant Device Context (MDC)

O Multitenant Device Context (MDC) é uma tecnologia que permite o particionamento de um dispositivo  em diversos equipamentos lógicos (Switches ou Roteadores HP baseado no Comware).

Cada MDC utilizará uma porção do hardware e os seus recursos, rodando os processos de forma independente dos outros MDCs. Uma simples ação de criar, iniciar, reiniciar ou deletar um MDC não afeta outros MDCs.

Da perspectiva do cliente, o MDC é um equipamento individual.

MDC 1

IRF e o MDC

A tecnologia IRF permite agregarmos 2 ou mais equipamentos em um único dispositivo lógico facilitando assim a administração dos equipamentos.

Já o MDC permite que diferentes clientes utilizem os recursos do equipamento de forma independente. Features como VLAN IDs, roteamento e protocolos  de gerenciamento atuam de forma isolada dentro do “contexto”. Gerando assim economia na venda de serviços, espaço em rack, energia eletrica, etc.

Para permitir a comunicação entre MDCs é necessário conectar um cabo entre os MDCs.

O gerenciamento dos MDCs que estão no mesmo equipamento é efetuado pelo MDC default (admin MDC). É possível logar  individualmente e diretamente nos MDCs com protocolos como SSH ou telnet.

Diferente de VRFs (vpn-instances) que apenas virtualizam a tabela de roteamento sobre uma única administração, o MDC permite a separação do gerenciamento e processos.

Arquitetura e Features MDC

Um MDC pode ser considerado um equipamento individual baseando-se no conceito de container para virtualização do SO(sistema operacional) Comware 7. Um container é uma forma de virtualização no nível do SO, um ambiente totalmente isolado, simulando um sistema independente no mesmo host.

Cada MDC é um equipamento lógico definido em um equipamento fisico. O equipamento físico pode ser um único Switch ou um par de Switches em IRF.

Cada MDC tem também o data plane isolado, permitindo que o ID das VLAN sejam definidos e repetidos em cada MDC mas funcionando de maneira independente. As portas são reservadas ao nivel de cada ASICs por MDC, já a CPU é compartilhada e concorre por recursos. A documentação diz que se um MDC necessita de recursos enquanto um segundo MDC está ocioso, o primeiro MDC pode alocar mais recursos de CPU.

MDC 2

 

A configuração do MDC só é possível até o momento em Switches modulares com o suporte ao Comware7. A quantidade de MDCs pode variar dependendo da capacidade computacional do Main Process Unit (MPU) do Switch Chassis.

Os Switches com a feature MDC tem um admin MDC (MDC número 1) que pode gerenciar todos os recursos de hardware dos outros MDCs, permitindo a criação e a remoção do MDC. O mesmo não pode ser removido.

Mesmo com a utilização de diversos MDCs em um device, apenas um kernel é inicializado e por isso os MDCs precisam executar a mesma versão de firmware. A documentação diz que o equipamento que suporta os MDCs é chamado de Admin MDC e é o MDC 1 e por padrão quando o kernel é iniciado, o MDC 1 é  o utilizado para administrar os outros MDCs.

Na definição de um MDC é possível a alocação de peso para de uso de CPU por MDC afim de priorizar MDCs especificos, é possível também definir a alocação de disco, uso de memória, grupos de processos restritos, etc. Para o MDC admin não há limitação de recursos.

Para a alocação de interfaces, é necessario a reserva por grupo de ASICs. Em um Switch modular cada modulo/cartão (LPUs) tem um ou mais ASICs. Quando um frame chega ao Switch funções como analise de VLANs, endereços MAC são executados pelos ASICs e um ASIC pode ter diversas interfaces físicas.

No exemplo abaixo, durante a alocação de apenas uma porta para o MDC2, o switch apresenta  a mensagem que a interface FortyGigE 1/1/0/1 participa do mesmo port-group que as interfaces listadas.

[Switch-mdc-2-mdc2]allocate interface FortyGigE 1/1/0/1
Configuration of the interfaces will be lost. Continue? [Y/N]:y
Group error: all interfaces of one group must be allocated to the same mdc.
FortyGigE1/1/0/1
Port list of group 5:
FortyGigE1/1/0/1 FortyGigE1/1/0/2
FortyGigE1/1/0/3 FortyGigE1/1/0/4
FortyGigE1/1/0/5 FortyGigE1/1/0/6
FortyGigE1/1/0/7 FortyGigE1/1/0/8

A tabela abaixo apresenta o grupo de portas de alguns módulos nos Switches 12500.

MDC 3

Configurando um MDC

  1. Defina o MDC com o ID e nome
  2. Configure a autorização de alocação da line card (LPU)
  3. Aloque as interfaces por grupo baseado no ASIC
  4. Inicie o MDC
  5. Acesse o MDC utilizando o comando switchto

 

[Switch] mdc clientex id 2
! criando o MDC clientec com o id 2
[Switch-mdc-2-clientex] location slot 2
!  autorizando o uso da LPU no slot 2
[Switch-mdc-2-clientex] allocate interface giga 2/0/1 to 2/0/48
! alocando as interfaces na LPU no slot 2
!
[Switch-mdc-2-clientex] mdc start
! iniciando o mdc
[Switch-mdc-2-clientex] quit
!
[Switch] switchto mdc clientex
! conectando no mdc clientex

Validando as portas reservadas por MDC no admin MDC

[Switch]display  mdc interface
 MDC Admin's interface(s):
  M-Ethernet0/0/0

 MDC clientex's interface(s):
  GigabitEthernet2/0/1                 GigabitEthernet2/0/2                 
  GigabitEthernet2/0/3                 GigabitEthernet2/0/4
  GigabitEthernet2/0/5                 GigabitEthernet2/0/6
  GigabitEthernet2/0/7                 GigabitEthernet2/0/8

!output omitido

Até logo

Referência

Building HP FlexFabric Data Centers student guide – HP Expert one – Rev14.41

Resumo: BGP – Router Reflector em Roteadores HP

O algoritmo do BGP não permite que rotas aprendidas via iBGP sejam anunciadas para roteadores vizinhos. Lembrando que uma rota aprendida via eBGP deve ser ensinada para um vizinho iBGP, mas uma rota aprendida via iBGP não deve ser anunciada para roteadores vizinhos.

Quando BGP foi projetado originalmente, não havia nenhuma provisão para a prevenção de loop dentro de um Sistema Autônomo (AS ou ASN). Em vez disso, a regra de prefixos iBGP proíbe o anuncio de rotas aprendidas via iBGP para outro peer BGP interno.

Esta é a razão principal pela qual a inteligência do  BGP necessita de conexões full mesh entre roteadores iBGP, isto é, todos roteadores devem estar conectados entre si. Mas a topologia iBGP com  full mesh, traz  problemas de escalabilidade na configuração, uma vez que o número de sessões para troca de tráfego irá ser N (N-1) / 2, onde N é o número de roteadores internos BGP

Perceba no diagrama abaixo que o prefixo aprendido por R3 via iBGP não é encaminhado para o roteador R4 devido a regra de prefixos aprendidos via iBGP citado acima.

iBGP rule HP

Utilizando Roteadores Refletores (Router Reflectors ou RRs) em uma topologia iBGP, permitirá ao protocolo BGP quebrar a regra de proibição ao ensinar rotas aprendidas via iBGP para vizinhos internos.

Os roteadores configurados como Router Reflector dividem os seus vizinhos iBGP em duas classes: clientes e não-clientes.

As rotas aprendidas por roteadores iBGP clientes serão anunciadas para roteadores clientes e não-clientes. No, entanto as rotas aprendidas a partir de não-clientes serão anunciadas apenas para clientes.

Perceba no diagrama abaixo o prefixo anunciado para o Roteador R4 pelo Roteador R3 configurado como RR.

iBGP rule and RR HP

A configuração do Router Reflector só é necessária no roteador RR “servidor”, nenhuma configuração é necessária nos equipamentos clientes. Segue abaixo a configuração de R3.

! Configuração R3
!
bgp 234
 peer 2.2.2.2 as-number 234
 peer 2.2.2.2 description R2
 peer 2.2.2.2 reflect-client
 peer 2.2.2.2 connect-interface LoopBack1
!

Cluster_List e Originator_ID

A configuração de Route Reflector é geralmente a atribuída a ambientes bem complexos. O BGP utiliza-se de alguns mecanismos para prevenção de loops como Cluster List e Originator ID:

– Cluster ID: O RR adiciona seu cluster ID ao encaminhar o update. Quando recebe um update BGP que contem o seu próprio Cluster ID os prefixos recebidos são descartados, evitando assim o gerar loop  de roteamento pelos anuncios entre clusters.

– Originator ID: Uma lista de clusters (cluster-list) é uma seqüência de cluster-IDs que a rota atravessou. Quando um RR reflete uma rota de seus clientes para non-clients fora do cluster, ele adiciona o cluster-id local no final da cluster-list. Usando este atributo, um RR pode identificar se uma informação de roteamento fez um loop e voltou ao mesmo cluster que a originou (por alguma falha de configuração). Se o cluster-id local é encontrado na cluster-list, o anúncio da rota será descartado.

Conforme diagrama abaixo, segue um exemplo do output com a lista do Cluster list:

Router Reflector cluster id HP

[R1]display bgp routing-table 55.55.55.0
 BGP local router ID : 1.1.1.1
 Local AS number : 234
 Paths:   1 available, 1 best
BGP routing table entry information of 55.55.55.0/24:
 RR-client route.
 From            : 4.4.4.4 (4.4.4.4)
 Relay Nexthop   : 192.168.45.5
 Original nexthop: 2.2.2.2
 AS-path          : 5
 Origin          : igp
 Attribute value : MED 0, localpref 100, pref-val 0, pre 255
 State           : valid, internal,
 Originator      : 2.2.2.2
 Cluster list    : 0.0.0.2, 0.0.0.1

Segue abaixo a configuração de R3 e R4 (lembrando que nenhuma configuração BGP adicional é necessária para o Roteador cliente Router Reflector

#
! Configuração R3
router bgp 234
 bgp cluster-id 1
 neighbor 2.2.2.2 remote-as 234
 neighbor 2.2.2.2 description R2
 neighbor 2.2.2.2 update-source Loopback1
 neighbor 2.2.2.2 route-reflector-client
!
 neighbor 4.4.4.4 remote-as 234
 neighbor 4.4.4.4 description R4
 neighbor 4.4.4.4 update-source Loopback1
!

#
! Configuração R4
router bgp 234
 bgp cluster-id 2
 neighbor 1.1.1.1 remote-as 234
 neighbor 1.1.1.1 description R1
 neighbor 1.1.1.1 update-source Loopback1
 neighbor 1.1.1.1 route-reflector-client
!
 neighbor 3.3.3.3 remote-as 234
 neighbor 3.3.3.3 description R3
 neighbor 3.3.3.3 update-source Loopback1
!

Até logo

Referências

http://blog.ipexpert.com/2012/02/20/understanding-bgp-originator-id-and-cluster-id/#top

http://www.rnp.br/newsgen/0109/bgp4_dicas2.html#ng-6

http://www.rotadefault.com.br/teste-mesa-para-router-reflectors/

http://www.rotadefault.com.br/resumo-bgp-router-reflectors/

CCIE Routing and Switching Certification Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue

Atualizando o Switch via TFTP com IPv6 em Switches HP 5120

Segue abaixo um script para atualização do Comware em um Switch HP 5120 utilizando o protocolo IPv6 como transporte. A atividade é bem simples (como em IPv4) e nos ajuda a desmistificar e nos encorajar a utilizar cada vez mais o “novo” serviço. O procedimento é o mesmo para a maioria dos Switches com o Sistema Operacional Comware (3com/H3C/HPN).

<Switch>system

[Switch] ipv6
[Switch] interface vlan 1
[Switch-Vlan-Interface-1]ipv6 address 2001:db8::2/64
[Switch-Vlan-Interface-1]quit
[Switch] quit

<Switch>
<Switch>tftp ipv6 2001:db8:1 put flash:/a5120ei-cmw520-r2208p01-s168.bin
! Fazendo backup da imagem antiga para o Servidor TFTP

<Switch>delete /unreserved a5120ei-cmw520-r2208p01-s168.bin
The contents cannot be restored!!! Delete flash:/a5120ei-cmw520-r2208p01-s168.bin?[Y/N]:y
! Devido a falta de espaçoo para manter a imagem nova e a velha nesse modelo de Switch, 
! iremos deletar a imagem mais antiga.
! O comando /unreserved deleta a imagem sem jogar na lixeira da memória flash

<Switch> tftp ipv6 2001:db8::1 get A5120EI-CMW520-R2220P02.bin
! Copiando a nova imagem para o Switch

<Switch>boot-loader file flash:/a5120ei-cmw520-r2220p02.bin slot all main
This command will set the boot file of the specified board. Continue? [Y/N]:y
! Configurando a nova imagem para "bootar" após o Switch reiniciar

<Switch>disp boot-loader
Slot 1
The current boot app is:  flash:/a5120ei-cmw520-r2208p01-s168.bin
The main boot app is:     flash:/a5120ei-cmw520-r2220p02.bin
The backup boot app is:   flash:/

<Switch>reboot
Start to check configuration with next startup configuration file, please wait.........DONE!
This command will reboot the device. Current configuration will be lost, save current configuration? [Y/N]:y
This command will reboot the device. Continue? [Y/N]:y
Reboot device by command.
! Reiniciando o Switch

<HP>display version
HP Comware Platform Software
Comware Software, Version 5.20.99, Release 2220P02
Copyright (c) 2010-2013 Hewlett-Packard Development Company, L.P.
HP A5120-48G EI Switch uptime is 0 week, 0 day, 0 hour, 2 minutes
! Validando o Upgrade

<HP>display boot-loader
Slot 1
The current boot app is:  flash:/a5120ei-cmw520-r2220p02.bin
The main boot app is:     flash:/a5120ei-cmw520-r2220p02.bin
The backup boot app is:

Pronto, imagem atualizada! 😉
O Software utilizado para copia da imagem foi o TFTPd64 by Ph. Jounin para Windows

 

Introdução ao PPPoE e Configuração Básica em Roteadores MSR (HPN/H3C)

O PPP over Ethernet (RFC 2516) é uma especificação que  permite a conexão de hosts à Rede do Provedor para acesso a Internet, providenciando conexões ponto-a-ponto, utilizando a Pilha do protocolo PPP sobre o protocolo Ethernet.

O protocolo PPP trabalha com a tecnologia Ethernet para ligar a placa de rede dos usuários ao modem.  Desta forma é possível agregarmos a autenticação para a conexão e aquisição de um endereço IP fixo ou dinâmico à máquina do usuário.

pppoe-topology

Modems DSL são essencialmente simples Bridges Ethernet para conexão com Multiplexadores de Acesso (DSLAMs) da Operadora, oferecendo um túnel PPP sobre Ethernet.

PPPoE em Roteadores MSR

Existem diversas maneiras para a configuração em Roteadores MSR como clientes PPPoE. No exemplo abaixo efetuaremos a configuração básica para simulação do Roteador R1 como cliente PPPoE e R2 como um servidor PPPoE para autenticação utilizando PAP e o fornecimento de endereços por DHCP.

PPPoE MSR
Configuração

R1:
#
interface Dialer1
! Criando a Interface Dialer0
 link-protocol ppp
! Habilitando o protocolo PPP
 ppp pap local-user diego password simple 12345
! Configurando a autenticação com pap
! usuario "diego" com a senha "12345"
 ip address ppp-negotiate
! Configurando a negociação IP dinâmica
 dialer user diego
 dialer-group 1
 dialer bundle 1
! Configurando o dialer-group 1 e o dialer bundle 1
#
interface Ethernet0/1/0
 port link-mode route
 pppoe-client dial-bundle-number 1
! Vinculando o dialer bundle na interface e0/1/0
#
 ip route-static 0.0.0.0 0.0.0.0 Dialer1
! Configurando a rota estática para o Dialer1
#

Comandos Display e Debug

<R1>display pppoe-client session  summary
PPPoE Client Session:
ID   Bundle  Dialer  Intf             RemMAC        LocMAC        State
1    1       1       Eth0/1/0         000fea031100  000feb030f00  PPPUP

<R1>display ip interface brief
*down: administratively down
(s): spoofing
Interface                     Physical Protocol IP Address      Description
Dialer1                       up       up       192.168.1.3     Dialer1 I...
Ethernet0/1/0                 up       up       unassigned      Ethernet0...

! O commando display  pppoe-client  session mostrará as conexões PPPoE ativas no Roteador incluindo o endereço MAC da outra ponta.

<R1> debugging  pppoe-client packet
*Sep 25 11:15:31:359 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client OUT Discovery packet (PADI), Len = 30
*Sep 25 11:15:31:374 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client IN Discovery packet (PADO), Len = 49
*Sep 25 11:15:31:390 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client OUT Discovery packet (PADR), Len = 49
%Sep 25 11:15:31:405 2013 SW1 IFNET/3/LINK_UPDOWN: Dialer1:0 link status is UP.
*Sep 25 11:15:31:405 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client IN
 Discovery packet (PADS), Len = 49, Session ID = 1%Sep 25 11:15:33:605 2013 SW1 IFNET/5/LINEPROTO_UPDOWN: Line protocol on the interface Dialer1:0 is UP.
%Sep 25 11:15:33:621 2013 SW1 IFNET/5/PROTOCOL_UPDOWN: Protocol PPP IPCP on theinterface Dialer1:0 is UP.
%Sep 25 11:15:33:636 2013 SW1 PPPOEC/6/PPPOEC_LOG_ON: PPPoE user diego logged on successfully.

O Debug acima é bastante interessante para entendermos as mensagens de negociação PPPoE .

pppoe-messages

Durante iniciação da negociação PPPoE o host encaminha uma mensagem PADI (PPPoE Active Discovery Initiation )em Broadcast, quando o Servidor PPPoE ou Concentrador de acesso recebe essa mensagem, ela é respondida com uma mensagem PADO (The PPPoE Active Discovery Offer) contendo informações do Servidor.

Muito similiar as solicitações DHCP, o host poderá receber mais de uma mensagem PADO ( de diversos concentradores). O host responde na seqüência com uma mensagem PADR (PPPoE Active Discovery Request  ) em unicast para o Servidor PPPoE  escolhido. Se a mensagem PADR for valida, é encaminhada para o host uma mensagem PADS (PPPoE Active Discovery Session-confirmation) para iniciar a sessão PPP.

Obs: Se  desejado  o fim da sessão PPP é gerado uma mensagem PADT (PPPoE Active Discovery Terminate).

Mais…

Segue abaixo a configuração do Roteador R2, responsável por aceitar e autenticar a conexão de R1.

#
local-user diego
 password simple 12345
 service-type ppp
! Configurando o usuario e senha para autenticação
#
interface Ethernet0/0/0
 port link-mode route
 pppoe-server bind Virtual-Template 1
! Vinculando a interface virtual-template 1 
#
interface Virtual-Template1
 ppp authentication-mode pap
 remote address 192.168.1.3
 ip address 192.168.1.1 255.255.255.0
! Habilitando o serviço de autenticação PAP na interface Virtual-Template 1
! incluindo o IP remoto (nesse caso, poderia ser configurado um servidor DHCP)

Referencias:

http://tools.ietf.org/html/rfc2516
http://babarata.blogspot.com/2010/03/inicio.html
http://fengnet.com/book/VPNs%20Illustrated%20Tunnels%20%20VPNsand%20IPsec/ch04lev1sec3.html
http://blog.ine.com/2010/03/18/bba-group-and-dialer-profiles-with-pppoe/
http://www.rotadefault.com.br/2013/06/26/introducao-ao-pppoe-e-configuracao-basica-em-roteadores-cisco/

Resumo sobre Border Gateway Protocol (BGP) – MASE Network Infrastructure – parte 1 de 2

Galera, esses dias participei de um treinamento para a certficação MASE Network Infrastructure voltado para a prova HP0-Y36.Fiz algumas anotações e conforme for organizando os “.txts” dos rascunhos, compartilharei aqui no blog para quem precisar da revisão para a prova. Espero que seja útil.

O Protocolo BGP é considerado o mais robusto Protocolo de  Roteamento para redes IP. Sua complexidade permite a conexão de múltiplos Sistemas Autônomos, chamados de AS (Autonomous systems), permitindo o roteamento dinâmico na Internet.

Um Sistema Autônomo é uma coleção de prefixos (rotas) sobre uma mesma política de roteamento e sobre o controle administrativo de uma mesma entidade (empresas, provedores de Internet [ISP’s]).

A Internet consiste em redes Comerciais conectadas por Provedores (ISP’s) como Telefônica,Embratel, Oi, CTBC e etc. Cada rede comercial ou Provedor deve ser identificado pelo Número do seu Sistema Autônomo (ASN) sobre controle do IANA .

O range disponível para o BGP é de 1 até 65635. Os ASN públicos disponíveis vão de 1 até 64511, já a utilização dentro de uma empresa do BGP, sem a comunicação com a Internet, poderá utilizar os valores de 64512 até 65535, chamados de uso privado.

A função primária de um sistema BGP é trocar informação de acesso à rede, inclusive informações sobre a lista das trajetórias dos ASes, com outros sistemas BGP. Esta informação pode ser usada para construir uma rede de conectividade dos ASes livre de loops de roteamento.

O BGP é considerado um Protocolo de Vetor de Distância avançado utilizando-se de vetores para contagem de saltos para cada destino. A contagem de saltos para o BGP é baseada em ASes.

  • O BGP é considerado um protocolo de roteamento externo usado para transmitir informações de roteamento entre ASes e como ponto de troca entre organizações.
  • Desenhado para grandes redes com necessidade complexas para políticas de roteamento.
  • O BGP roda sobre  TCP (porta 179) e requer a configuração manual  para conexão com o vizinho (peering).
  • BGP versão 4
  • Providencia uma série de atributos (métricas) para os prefixos anunciados, além de suportar CIDR. Também suporta diversas estratégias de filtro para o roteamento
  • Não gera informações periódicas de roteamento e sim atualizações engatilhadas (* triggered updates para os peers) além de mandar as atualizações em lote para os seus vizinhos  (* “batch” route updates).

Protocolos de roteamento interior (IGP) vs exterior (EGP)

  • Interior (RIP, OSPF, EIGRP, ISIS,etc)
    • descobrimento automático de vizinhos
    • os roteadores internos possuem informação completa da tabela de rotas
  • Exterior (BGP)
    •  os vizinhos são configurados estaticamente (não há um sub-processo como o Hello do OSPF para descoberta de vizinhos)
    • conexão com redes externas
    • demarcação clara de limites administrativos

Operação Geral

Roteadores BGP aprendem multiplos caminhos via BGP internos e externos.  Eles escolhem SOMENTE o melhor caminho e instala na tabela de roteamento IP. O Roteador BGP anuncia apenas as rotas que este utiliza (apesar da possibilidade de aprender sobre multiplos caminhos).

BGP peer

– A comunicação BGP entre roteadores é sobre uma conexão TCP.

– Roteadores são pares (peer) são classificados em:

  • … eBGP peer (external BGP)  se os roteadores estão em um Sistema Autonomo diferente
  • … iBGP peer (internal BGP)  se os roteadores estão em um  mesmo Sistema Autonomo.

– eBGP peer devem ter um link direto entre eles.

– iBGP peer não necessitam ter um link direto.

Obs: dentro de um AS os roteadores trocam roteamento interno via IGP, já os roteadores eBGP geralmente não trocam roteamento via IGP.

Configuração eBGP

Resumo BGP

As mensagens eBGP são encapsuladas no pacote IP com o TTL=1 por padrão. Caso seja necessário a conexão entre vizinhos eBGP por uma interface Loopback, o TTL deve ser alterado para 2: adicione o comando peer ebgpmax-hop 2

bgp 10
  peer <endereço da loopback do vizinho> as-number 20
  peer <endereço da loopback do vizinho> ebgp-max-hop 2
  peer <endereço da loopback do vizinho> connect-interface loopback0

Obs: Geralmente utilizado em cenários com redundância de Link. Certifique-se que o roteamento da interface Loopback do vizinho seja acessível pelos links redundantes.

Configuração iBGP

Devido ao fato de uma interface looopback estar sempre UP, ela é utilizada para configurar uma conexão TCP estável entre 2 vizinhos iBGP (geralmente a conexão é estabelecida via IGP).

Resumo iBGP

Observações

– Uma rota aprendida via iBGP não é ensinada para outros vizinhos iBGP como forma de prevenção de loop de roteamento

– Os roteadores iBGP de um AS devem formar uma conexão “full mesh” entre si ou utilizar outros mecanismos como Route Reflector e Confederation.

– Roteadores conectados via iBGP não necessitam estar diretamente conectado e sim acessivel via IGP (static, RIP, OSPF, etc.)

– Um Roteador iBGP não altera o next-hop de um prefixo aprendido via eBGP e que é ensinado na atualização para um vizinho iBGP. Certifique-se que o next-hop (endereço IP do próximo salto) seja acessível via IGP em todos roteadores do AS ou altere o next-hop para o vizinho das rotas aprendidas por eBGP com o comando “peer <endereço IP do peer iBGP> next-hop-local

Quando configurar um peer iBGP, lembre-se:

* Utilize o endereço da interface loopback do vizinho

* Utilize a sua interface loopback para conexão com o comando “connect interface
* Se o numero de vizinhos é grande, utilize a configuração de “groups

# Peer group Configuration
 bgp 10
 group as20 internal
 peer as20 as-number 20
 peer as20 connect-interface loopback0
 peer 192.1.254.2 group as20
 peer 192.1.254.3 group as20
 peer 192.1.254.4 group as20
 peer 192.1.254.5 group as20

Dica: O status correto para o “peering” entre 2 Roteadores iBGP e eBGP é Established

 Rotas BGP

Para uma rota ser anunciada no BGP, ela deve existir no Roteador (como estática, IGP, BGP)

1. redistribuição dinamica do IGP

– nem sempre a melhor opção
– requer configuração cuidadosas de filtragem de rotas
– caso um prefixo não esteja na tabela do IGP este deixa de ser anunciado
– mais utilizados em cenarios PE-CE

2. Redistribuição de rotas estáticas apontando para Null0 – mesmo que os prefixos estejam fora do IGP as redes são anunciadas

bgp 30
import-route static
quit
!
ip route 198.10.0.0 255.255.0.0 null 0

3. Comando network

– redes origininadas pelo roteador local
– rota deve existir no IGP

router bgp 30
network 192.168.0.0 255.255.0.0

Até logo! 🙂

No próximo post o resumo abordará algumas questões a manipulação e a escolha do melhor caminho para o BGP.