Isso é legal! Não é novidade mas boa parte dos switches Cisco (2960-G-S-X, 3560G-E-X, 3750-G-E-X, 6500, Nexus 7K, Sup7E/X4548, entre outros) tem um TDR – Time-Domain Reflectometer embutido. Esta funcionalidade nos permite testar o cabo de rede que está conectado na interface do switch. Para testar um cabo basta usar o comando test cable-diagnostics tdr interface X/X e na sequência o comando show cable-diagnostics tdr interface X/X para ver o resultado. Exemplo: Testando o cabo da interface G1/0/1 No output acima podemos ver que: A interface testada (G1/0/1) está usando 1 Gbps; O cabo conectado nesta interface é “reto”. Observe que as colunas Local Pair e Remote Pair não tem pares trocados; O cabo conectado mede aproximadamente 13 metros (com margem de erro de 4 metros); Todos os 4 pares estão funcionando perfeitamente. Outros status possíveis seriam: O ideal é que todos os pares tenham resultado “Normal”, mas note que no caso de cabos 100 Mbps, basta os pares A e B estarem “normal” para o cabo funcionar. A funcionalidade é bem interessante, mas cuidado: nas primeiras verões, ao realizar o teste, havia interrupção do tráfego (interface down/up). Outras informações sobre o TDR “embutido”: Switches que suportam a funcionalidade precisam rodar IOS 12.2 ou mais novo; Até a versão 12.2(46)SE havia interrupção no tráfego; O teste pode interromper o fornecimento de energia através do cabo (PoE) – nos testes que fiz não aconteceu; Nas primeiras verões de IOS com a funcionalidade, o teste pode levar de 5 a 7 segundos para ser executado; O TDR funciona em interfaces 10/100/1000BaseTX; Não mude a configuração da porta durante o teste; O ideal é rodar o teste algumas vezes para ter resultados mais precisos; A intenção é identificar se existe um problema, não qual é o problema; Você deve usar um TDR “dedicado” para diagnósticos exatos; Se o teste for efetuado em uma interface com Auto-MDIX, o resultado pode ser inválido. Mais informações sobre o TDR no 2960X no Management Command Reference. Até a próxima.
VMware NSX: Configurando Logical Switches e Distributed Logical Routers
Segue um vídeo-tutorial-demonstração, onde são criados dois switches virtuais (Logical Switch) e um roteador (Distributed Logical Router). Os switches fazem a segmentação layer 2, utilizando VXLAN, e o roteador é utilizado para fazer o roteamento entre estas redes, e também para fazer a comunicação entre o mundo virtual e o mundo físico (usando OSPF). Abaixo a topologia utilizada. Até a próxima.
Conceitos do VMware NSX
O VMware NSX é uma plataforma de virtualização de redes que segue o mesmo modelo já usado para a virtualização de servidores. Com a virtualização de servidores, uma camada de abstração de software (hypervisor) reproduz os atributos de um servidor físico (CPU, RAM, disco, NIC) em software. Da mesma forma, na virtualização de rede, o equivalente funcional de um hypervisor reproduz o conjunto de serviços de rede (switching, roteamento, firewall, QoS e balanceamento de carga) em software. Como resultado, estes serviços podem ser criados e fornecidos rapidamente, sem a necessidade de alterações no mundo físico. O NSX é uma solução incrível para data centers e provedores de nuvem, mas mesmo ambientes mais simples podem tirar proveito desta solução (ainda que no início possa parecer confuso). Componentes do NSX O NSX possui uma arquitetura onde o plano de gerência, controle e dados são separados, com componentes específicos para cada função. Management Plane: O NSX Manager é o responsável pelo management plane na solução NSX. O NSX Manager é fornecido como um appliance virtual (instalável em VMware ESX), e fornece a interface para o gerenciamento da solução. Também permite integrações através de APIs. Ele é registrado ao vCenter no modelo um-para-um (um NSX Manager é registrado a um vCenter), e a configuração da rede virtual é feita por meio do dele (integrado ao vCenter). Podemos fazer uma analogia do NSX Manager com o Cisco Prime Infrasctrucuture. Control Plane: O NSX Controller é o sistema de gestão para as funções de switching e roteamento (Control Plane). De forma centralizada, mantém informações sobre todos os hosts, VXLANs e roteadores distribuídos. É como um módulo supervisor em chassi, e o tráfego não passa por ele. Pode trabalhar nos modos Unicast, Multicast e Hibrido, e para termos alta disponibilidade e escala, o NXS Controller dever ser instalado em um cluster de três nós. O cluster tem funções de API provider, Persistence server, Switch manager, Logical manager e Directory server. Para cada uma destas funções temos um master controller no cluster. Em caso de falha o cluster elege outro master controller para a função afetada. Data Plane: O plano de dados (onde o tráfego passa de fato) consiste do NSX vSwitch, que se baseia no vSphere Distributed Switch (VDS) com componentes adicionais para habilitar serviços (ESG e DLR, veja abaixo). NSX kernel module, userspace agents, configuration files, e install scripts são empacotados em VIBs e rodam no kernel da hypervisor para fornecer serviços como VXLAN bridging, distributed routing e logical firewall. Consumption Plataform: O NSX pode ser “consumido” diretamente do NSX Manager, mas também é possível fazer integrações com outras plataformas de gerência, através de REST APIs, permitindo a automação de procedimentos e a criação de portais customizado para os administradores/operadores/clientes. NSX Edge O NSX Edge é o elemento virtual de rede. Podemos criar um NSX Edge do tipo Edge Service Gateway (ESG) ou Distribuited Logical Router (DLR). Usamos o ESG para prover serviços como firewall, NAT, DHCP, VPN e load-balancing. Ele é uma máquina virtual com até 10 interfaces (uplink e internal). Já o DLR é utilizado para prover roteamento leste-oeste distribuído. Com o DLR máquinas virtuais que estão no mesmo host mas em redes diferentes, podem se comunicar sem precisar ir até um roteador tradicional, por exemplo. Um DLR pode ter 8 interfaces uplinks e mil interfaces internas. O control plane do DLR é fornecido pelo DLR virtual appliance (VM de controle). Esta VM suporta os protocolos de roteamento dinâmicos (BGP e OSPF), troca de updates de roteamento e se comunica com o NSX Manager e o cluster NSX Controller. Para alta disponibilidade podemos ter um par de DLR (duas máquinas virtuais funcionando no modo ativo-standby). Já o data plane fica por conta do DLR Kernel Module (VIBs), que é instalados nos hosts ESXs que fazem parte do domínio NSX. Os módulos do kernel são similares às line cards de um chassis modular e têm uma RIB – Routing Information Base (também conhecida como tabela de roteamento) que é recebida do controller cluster. As funções de route e ARP lookup são executadas nos módulos kernels, que são equipados com interfaces lógicas (chamadas LIFS) que proveem ligação com os diferentes switches lógicos. Cada LIF tem um endereço IP que representa o gateway padrão para o segmento L2 lógico a qual ela está conectada e um endereço vMAC. O endereço IP é único para cada LIF, enquanto o mesmo vMAC é atribuído a todas as LIFS definidas. Mais informações nos links abaixo: – VMware NSX 6.2 – Indroduction to VMware NSX Até a próxima.
Gerando gráfico no Splunk–Hosts com mais conexões bloqueadas
Alguns posts atrás falamos como configurar o Splunk para ser um Syslog Server. Agora, no vídeo abaixo, podemos ver um exemplo do que podemos fazer com o Splunk. Até a próxima.
DHCP Relay em switches Nexus
A funcionalidade DHCP Relay é muito utilizada, já que é normal termos uma (ou mais) VLAN para usuários e uma (ou mais ) VLAN para servidores. Também é comum o switch core ser o gateway destas VLANs, e ser o responsável por encaminhar as requisições DHCP de uma rede para outra. Já falamos sobre isso aqui no blog, considerando o uso de switches Catalyst. Porém, como sabemos, os switches Nexus usam o NX-OS, e alguns comandos são diferentes do IOS tradicional. Diferente dos switches Catalyst (onde usamos o comando ip helper-address), no Nexus utilizamos o comando ip dhcp relay address. Mas não é só isso. Configurando DHCP Relay no Cisco Nexus Abaixo está a topologia usada neste exemplo, com as configurações do DHCP Client e DHCP Server para referência. Configuração do NEXUS, que será responsável por encaminhar as requisições DHCP da VLAN 192 para o servidor DHCP que está em outra rede (VLAN10): !Configure Hostname do equipamento Hostname NEXUS !Habilite as features necessárias feature interface-vlanfeature dhcp !Crie as VLANs e as interfaces VLANs vlan 10,192!interface Vlan10 no shutdown ip address 10.1.1.2/24 !Na interface VLAN que é gateway da rede de usuários (que receberá as requisições DHCP), habilite o DHCP Relay interface Vlan192 no shutdown ip address 192.168.1.1/24 ip dhcp relay address 10.1.1.1 ! Configure as interfaces físicas nas respectivas VLANs interface Ethernet2/1 switchport switchport access vlan 10 no shutdown!interface Ethernet2/2 switchport switchport access vlan 192 no shutdown Por trás das cortinas Não são só os comandos que são diferentes. Quando habilitamos o ip helper-address em um equipamento com IOS, todos os pacotes broadcasts UDP com as portas de destino abaixo são encaminhadas para o IP especificado. TIME, port 37 TACACS, port 49 DNS, port 53 BOOTP/DHCP Server, port 67 BOOTP/DHCP Client, port 68 TFTP, port 69 NetBIOS name service, port 137 NetBIOS datagram service, port 138 No NX-OS (Nexus) o comando ip dhcp relay encaminha apenas os pacotes broadcasts UDP com destino à portas 67 e 68. Se se objetivo é fazer o relay DHCP tudo bem, isso já é suficiente. Mas se por algum motivo você precisa encaminhar outras requisições (DNS, TFTP, TIME,…) é necessário usar o comando ip forward-protocol udp. Com este comando os seguintes pacotes serão encaminhados: Trivial File Transfer Protocol (TFTP) (port 69) Time service (port 37) NetBIOS Name Server (port 137) NetBIOS Datagram Server (port 138) TACACS service (port 49) IEN-116 Name Service (port 42) Domain Naming System (port 53) Se precisar fazer o relay de algo diferente disso basta usar o comando ip forward-protocol udp XX (especificando a porta no lugar do XX). Isto tanto nos switches Nexus quanto nos Catalysts. Referência: Configurando DHCP no NX-OS. Até a próxima.
CCNAv3 – Prova 200-125
A essa altura todos já devem ter visto, mas vamos lá… A Cisco anunciou no último dia 17 uma atualização no ICND1, ICND2 e CCNA Routing & Switching. A primeira mudança percebida são os números das provas: ICND1 v3.0: 100-105 ICND2 v3.0: 200-105 CCNA v3.0: 200-125 Evidentemente também temos mudanças nos conteúdos. O OSPF foi movido do ICND1 para o ICND2. Dual Stack e Cisco Express Forwarding (CEF) foram removidos. Da mesma forma Frame-Relay, tecnologias Serial WAN, VRRP e GLBP também não fazem mais parte da certificação. Em contrapartida serão exigidos conhecimentos nas seguintes áreas: Noção de componentes de infraestrutura (Firewalls, Access Points e Wireless Controllers) Arquitetura tradicional (3 camadas) e arquitetura colapsada (2 camadas) IPv6 Stateless Address Auto Configuration (SLAAC) IPv6 Anycast LLDP RIPv2 para IPv4 Noção de DNS e DHCP Entendimento de Syslog Backup e restore de configuração, licenciamento IOS e configuração de Time zones Dual home e Single home Intelligent WAN Conhecimento básico de external BGP VPN (DMVPN, Site-to-Site VPN e Client VPN) Conceitos de Cloud e NFV (Network Function Virtualization) Conceitos de SDN e APIC-EM Entendimento de QoS Os novos tópicos juntam-se aos tópicos já conhecidos e estarão distribuídos em 7 áreas, que representam de 10% à 23% da pontuação da prova. A prova 200-120 (CCNAv2) ainda poderá ser feita até o próximo dia 20 de agosto. Veja todas as informações sobre o novo CCNA na página da Cisco Learning Network. Até a próxima.
