VLAN – Trunk utilizando 802.1q (dot1q)

A utilização de VLAN (Virtual Local Area Network) permite que uma rede física seja dividida em várias redes lógicas dentro de um Switch. A partir da utilização de VLANs, uma estação não é capaz de comunicar-se com estações que não são pertencentes a mesma VLAN (para isto, é necessário a utilização de uma sub-rede por VLAN e que o tráfego passe primeiro por um roteador para chegar a outra rede [ou utilizando um Switch Multicamada para efetuar o Roteamento]).

Se não utilizássemos uma interface como Trunk e precisássemos passar o tráfego da VLAN para o outro Switch, seria necessário a passagem de um cabo de cada VLAN para o outro dispositivo, como no exemplo abaixo.

Como a maioria dos Switches possui entre 24 e 48 portas a solução ficaria inviável, inutilizando a maioria das portas para conexões entre os dispositivos.

O protocolo IEEE 802.1q permite utilizarmos apenas um cabo na comunicação entre os Switches, marcando cada Frame (quadro) com o ID de cada VLAN.

A marcação efetuada (chamada de TAG) adiciona aos quadros Ethernet 4 bytes no frame original e calculam um novo valor de checagem de erro para o campo FCS.

Dos valores contidos dentro do campo TAG o número da VLAN é adicionado ao campo VLAN id permitindo a identificação da VLAN entre os Switches.

Uma observação relevante é a utilização do campo Priority (também dentro da TAG) para função de QoS em camada 2 para Ethernet, chamado de 802.1p ou CoS (Class of Services), permitindo a diferenciação de classes de serviços por Switches sem a necessidade de leitura do campo IP.

Já a comunicação entre computadores no mesmo Switch que pertencem a mesma VLAN não são “tagueadas” (untagged). Muitas placas de rede para PC’s e impressoras não são compatíveis com o protocolo 802.1Q e ao receberem um frame tagged, não compreenderão o TAG de VLAN e descartarão a informação.
Os Switches que recebem na sua interface Trunk um frame com TAG, irão remover o campo e entregar o quadro ao destino sem a marcação.

A regra é bem simples para a maioria dos casos (salvo exceções):

  • Para comunicação entre Switches, configure as interfaces como Trunk ( Tagged)
  • Para comunicação entre Switches e hosts, servidores, impressoras; configure as interfaces como Access (untagged) com o ID da VLAN

Configuração

Para a maioria dos Switches Cisco IOS, configure as portas como trunk da seguinte maneira (desde que as VLANs  já tenham sido criadas no Switch ou aprendidas via VTP):

interface GigabitEthernet 1/0/x
! acesso a interface GigabitEthernet
port link-type trunk
! configuração da interface como trunk (frames encaminhados como tagged)
port trunk permit vlan all
! configuração da porta permitindo todas as VLANs no trunk

Um detalhe importante a ser percebido é  sintaxe switchport trunk encapsulation dot1q . Apesar do protocolo 802.1q não encapsular o quadro Ethernet, a sintaxe Cisco solicita a configuração do protocolo via o comando   .  Suponho que a sintaxe deva ter surgido quando a Cisco apostava na utilização de interfaces Trunk utilizando o protocolo ISL  que efetivamente encapsulava o quadro Ethernet.

Portas de acesso:

interface GigabitEthernet 1/0/x
! acesso a interface GigabitEthernet
port link-type access
! configuração da interface como acesso (frames encaminhados como untagged)
port access vlan 2
! configuração da porta na vlan 2

Obs: Por default os frames da VLAN 1 não são encaminhados com TAG dentro do Trunk.

Abraços a todos!!!

Iniciando os testes de APIs Meraki com DevNet Sandbox

O Cisco Meraki é um conjunto de soluções de rede gerenciadas pela internet que permite uma única fonte de gerenciamento sobre locais, infraestrutura e dispositivos. Componentes incluem uma solução completa de TI gerenciada por nuvem para atendimento as soluções de wireless, switching, segurança, gerenciamento de dispositivos móveis (MDM) e comunicações, integrando o hardware, software e a nuvem.

Há cinco maneiras pelas quais uma aplicação pode estender as funcionalidades da plataforma Meraki:

  • A Dashboard API, que fornece um serviço RESTful para provisionamento, gerenciamento e monitoramento de dispositivos.
  • Alertas de webhook, um serviço que permite atualizações em tempo real da saúde e configuração da rede.
  • A API de localização, um método HTTP POST configurado no Meraki Dashboard que fornece informações de localização do cliente (GPS, X/Y) com base no posicionamento do mapa do Meraki Access Point (AP) e na intensidade do sinal do cliente.
  • O External Captive Portal (EXCAP), que permite que uma organização crie modelos de engajamento personalizados para dispositivos que aproveitam seu ambiente WiFi.
  • MV Sense, que oferece chamadas de API REST e fluxo de dados em tempo real para aproveitamento das câmeras MV12

O ambiente “Meraki DevNet Always On Read Only Sandbox” fornece um ambiente de desenvolvimento para validar e testar o ‘Cisco Meraki Dashboard’, Dashboard API, integração do Captive Portal, MV Sense, Webhook Alerts e Location Scanning.

Todas as chamadas de API são muito bem documentadas usando a especificação OpenAPI (Swagger interface). Há ótimo trabalho disponibilizando tudo como um Documento Postman, um recurso muito útil no desenvolvimento de uma API.

Postman é uma ferramenta de desenvolvimento de API baseada no modelo web/cliente, perfeita para simular chamadas e explorar como funcionam determinadas APIs. A plataforma da Meraki está atualmente na sua API versão 1.x .

Qual o uso das APIs?
Existem muitos casos de uso para essas APIs, atendendo a requisitos de escalabilidade ​​para os administradores e automatização para as redes Meraki. Os casos de uso comuns são:

  • Provisionamento em massa (usando a API do painel)
  • Monitoramento avançado (usando MV Sense e APIs MR)
  • Automação de rede (usando chamadas MS)
  • Integrações na nuvem (integrar Meraki com dispositivos de terceiros — com Cisco Umbrella, por exemplo)

Cisco Sandbox

O ambiente Cisco DevNet Sandbox permite que engenheiros, desenvolvedores, administradores de rede, arquitetos ou qualquer pessoa que queira desenvolver e testar as APIs, controladores, equipamentos de rede, suíte de colaboração e muito mais da ferramentas da Cisco, possa fazê-lo gratuitamente!

https://developer.cisco.com/site/sandbox

Ambiente Meraki

Nesse post faremos um laboratório utilizando a infraestrutura Meraki (Meraki Always On).

Faça login, no dashboard com as credenciais fornecidas, acesse o ambiente “DevNet Sandbox”

Certifique se o use o uso de API está ativo “Enable access to the Cisco Meraki Dashboard”. Logado no painel vá para: Organization -> Settings -> Dashboard API Access, marque a caixa:

Gere uma API key para aquela conta. Cada conta poderá ter até 2 API Keys.

Clique no seu Perfil (canto superior direito): My Profile -> API Access -> Clique em “Generate API Key” copie e armazene em local seguro.

Postman

Depois de seguir os passos acima, você pode começar a fazer chamadas de API para seu dashboard e dispositivos usando o Postman ou seus scripts Python.

Se você precisar de ajuda com o Postman, incluindo como importar a API Postman Meraki, confira: https://developer.cisco.com/meraki/build/meraki-postman-collection-getting-started/  com poucos cliques é possível instalar a Coleção “Meraki Dashboard API – v1”

Vamos fazer nossa primeira chamada de API e definir o escopo da nossa documentação da API, pois existem algumas maneiras de fazer isso:

  • Você pode acessá-lo através do Meraki Dashboard: Clique em Help -> API Docs.
  • Importe o documento de API mais recente do Postman para sua conta do Postman.

Após importar para sua conta você poderá ver quantas chamadas de API estão disponíveis e como ela está organizada, confira abaixo:

Escolha um request que você possa preencher facilmente com as informações que já possui (por enquanto só temos a chave da API, portanto precisamos de uma solicitação que exija apenas o valor da Chave da API), por exemplo, poderíamos listar todas as Organizações disponíveis no Chave de API que estamos usando, depois de inserir os campos obrigatórios no cabeçalho da API:

baseURL: https://api.meraki.com/api/v1

apiKey: ae829149e162f8dd0535ca5f0b98e96f1d3adc29 (a API key gerada )

1º Passo, crie um ambiente. Clique no ícone do olho na parte superior direita e  “Add” para criar um novo ambiente.

2º Defina as variáveis. Adicione as informações baseURL e keyAPI

3º Execute o teste para coletar o ID do ambiente “DevNet Sandbox” dentro de “Organization” do ambiente Meraki.

Armado com essas informações, podemos começar a criar scripts e integrar nosso ambiente Meraki com outras ferramentas/plataformas.

Uma vez que coletamos a informação do ID da Organização, podemos atualizar as variáveis e coletar as informações de rede.

Por exemplo, podemos coletar o ID das redes.

Uma vez que coletamos a informação do ID da Rede, podemos atualizar as variáveis e coletar as informações de rede.

Por exemplo, podemos coletar as informações detalhadas dos equipamentos de rede, como endereço IP, serial, geolocalização, modelo, etc.

Coletar os SSIDs da rede:

Visualizando o mesmo SSID no ambiente Meraki:

Com o método PUT podemos alterar ou inserir nos parâmetros para a os SSIDs da Rede.

Referências

Andre Camillo: https://andrecamillo.medium.com/getting-started-with-meraki-apis-7633a822a9da

Charles Judd: https://www.youtube.com/watch?v=86uq_Imi-L0

Meraki API V1: https://developer.cisco.com/meraki/api-v1/

Postman, API development tool: https://www.postman.com/

Meraki API V1 Postman Documentation (import from here):  https://documenter.getpostman.com/view/897512/SzYXYfmJ

Getting started with Postman: https://developer.cisco.com/meraki/build/meraki-postman-collection-getting-started/

https://documenter.getpostman.com/view/897512/SzYXYfmJ#intro

DHCP Snooping

A feature DHCP Snooping permite a proteção da rede contra Servidores DHCP não autorizados.

Com o DHCP Snooping configurado, o Switch inspeciona as mensagens DHCP entre uma máquina cliente e servidor com a troca das mensagens: DHCP Discover, DHCP Offer, DHCP Request e o DHCP Ack, como o desenho abaixo:

O comando “ip dhcp snooping” configurado globalmente habilita o serviço no Switch.

Com o serviço habilitado, informe explicitamente qual VLAN deverá filtrar as mensagens DHCP Offer e DHCP Ack ; com o comando “ip dhcp snooping vlan vlan-range”.

ip dhcp snooping
! Habilitando o processo globalmente
ip dhcp snooping vlan 20
! Habilitando o dhcp snooping na vlan 20

Os comandos listados restringirão todas as portas do Switch na VLAN 20 como untrusted (não confiável). Filtrando todas as mensagens de oferta do serviço DHCP (a solicitação de serviço DHCP pela máquina cliente não sofrerá nenhuma restrição).

Para o funcionamento do “Servidor DHCP válido” deveremos configurar a porta do Servidor como trusted (confiável) , incluíndo as portas de UpLink.
No Exemplo, configuraremos o dhcp-snooping no Switch com a porta GigabitEthernet 1/8 conectada ao servidor DHCP válido como trust.

Configuração

Switch#conf t
Switch(config)#interface GigabitEthernet1/8
Switch(config-if)#ip dhcp snooping trust

Visualisando

O DHCP-Snooping constrói uma tabela que contém o endereço IP liberado pelo servidor DHCP vinculado ao endereço MAC.

Switch# show ip dhcp snooping binding
MacAddress   IpAddress      Lease(sec) Type  VLAN  Interface
00:FF:16:89:E6:88 192.168.20.2 86250   dhcp-snooping  10  Gi1/12

Switch# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
20
DHCP snooping is configured on the following Interfaces:
Insertion of option 82 is enabled
   circuit-id format: vlan-mod-port
    remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Interface                    Trusted     Rate limit (pps)
------------------------     -------     ----------------
GigabitEthernet 1/8          yes         unlimited
GigabitEthernet 1/12         no          unlimited

Dúvidas e sugestões, deixe um comentário! ;)

Referências
https://supportforums.cisco.com/pt/blog/153731

Ambiente de Lab Gratuito – Cisco Devnet Sandbox

O ambiente Cisco DevNet Sandbox permite que engenheiros, desenvolvedores, administradores de rede, arquitetos ou qualquer pessoa que queira desenvolver e testar as APIs, controladores, equipamentos de rede, suíte de colaboração e muito mais da ferramentas da Cisco, possa fazê-lo gratuitamente!

Cisco DevNet Sandbox
https://developer.cisco.com/site/sandbox/

Outros Links
Meraki API V1: https://developer.cisco.com/meraki/api-v1/
Postman, API development tool: https://www.postman.com/
Meraki API V1 Postman Documentation (import from here): https://documenter.getpostman.com/view/897512/SzYXYfmJ
Getting started with Postman: https://developer.cisco.com/meraki/build/meraki-postman-collection-getting-started/
https://documenter.getpostman.com/view/897512/SzYXYfmJ#intro

Como escolher um transceiver para o seu switch, controladora e roteador Cisco?

A página https://tmgmatrix.cisco.com/ auxilia os administradores de rede e parceiros a identificar quais são os transceivers compatíveis para cada equipamento Cisco. O site possui um mecanismo de busca que auxilia a pesquisa por tipo de transceiver, Part Number, modulo ou dispositivo de rede.

Uma vez identificado os transceivers compatíveis a página ainda oferece mais detalhes para cada um dos tipos de transceivers como padrões, distâncias, compatibilidade com DOM, IOS, se o transceiver é EoS/EoL e assim por diante.

Configuração de rota estática IPv6

Durante o recebimento de pacotes para acessar outras Redes externa a LAN para comunicação entre máquinas IPv6, o roteador efetuará uma consulta na sua tabela de roteamento IPv6 para verificar se existe alguma rota para o destino. Se a rota existir o pacote será encaminhado, senão, o pacote será descartado.

A maior parte dos parâmetros de configuração de rotas estáticas em IPv6 são idênticos ao IPv4. Como por exemplo, rota estática padrão, sumarizada e flutuante.

Abaixo a sintaxe de um roteador Cisco IOS:

Router(config)# ipv6 route rede/prefixo [próximo-salto]

O next-hop (ou próximo salto) pode ser identificado por um endereço IPv6, interface de saída ou ambos.

É possível verificar a tabela de roteamento IPv6 com o comando show ipv6 route.

A rota “ipv6 route ::0 0 [próximo-salto]” é uma “rota padrão” e corresponde a qualquer prefixo IPv6 (utilizado quando uma rota específica não é encontrada na tabela de roteamento).

Exemplo de Configuração

Antes de iniciar a configuração de rotas estáticas IPv6, habilite o encaminhamento de pacotes  IPv6 configurando ipv6 unicast-routing no modo de configuração global.

Endereço do next-hop como link-local

Caso haja a necessidade de configurar o endereço de next-hop como endereço IPv6 link-local, é necessário configurar a interface de saída, como no exemplo abaixo:

Router(config)#ipv6 route 2001:DB8:222::/64 FastEthernet0/0 FE80::C802:71FF:FEFC:

Testes

Para validar as rotas configuradas resumimos alguns comandos abaixo:

Router# ping ipv6 [endereço do host em IPv6]
!Testes de Ping

Router# traceroute [endereço do host em IPv6]
!Testes de tracerout

Router# show ipv6 route
!Verificar tabela de roteamento IPv6

Router# show ipv6  interface [interface com endereço IPv6 no roteador]
! Verifique todos os endereços IPv6 da interface ( global, link-local, etc)

Até logo.

Rota estática flutuante (floating static route)

Uma rota estática flutuante é uma rota com uma distância administrativa maior do que a estabelecida por padrão em Switches e Roteadores. Por exemplo, no IOS da Cisco as rotas estáticas possuem distância administrativa com o valor 1 e o protocolo OSPF com o valor 110, nesse caso pelo fato da menor distância administrativa ser escolhida quando duas rotas idênticas (com a mesma “rede” e “máscara de rede”) são aprendidas de maneiras distintas pelo roteador, o dispositivo escolherá o processo com menor AD ( administative distance/ distancia administrativa).

Como exemplo, poderíamos imaginar um roteador com 2 links, em um deles a rota 192.168.1.0/24 pode ser aprendida via OSPF e nesse caso precisaremos encaminhar o tráfego para esse link como principal. Já como backup configuraríamos a rota estática 192.168.1.0/24 com a distância administrativa com o valor 250 apontando para o next-hop do segundo link.

Quando o primeiro link apresentar problemas, o processo OSPF perceberá a falha e removerá a rota 192.168.1.0/24 aprendida dinamicamente e começará a utilizar a rota estática (não utilizada anteriormente) com o mesmo endereço 192.168.1.0/24 configurada para encaminhar os pacotes para o segundo link.

Quando o OSPF voltar a funcionar com o restabelecimento do primeiro link (incluindo novamente a rota 192.168.1.0/24 de maneira dinâmica), a rota estática deixará de ser utilizada.

Rt(config)# ip route 192.168.1.0 255.255.255.0 172.17.1.2 250

Obs: Lembre-se que a rota estática só entrará na tabela de roteamento se a interface correspondente ao próximo salto (next-hop) estiver UP.

Caso tenham alguma dúvida sobre o assunto, deixe um comentário.

http://pt.wikipedia.org/wiki/Dist%C3%A2ncia_administrativa