sexta-feira, 24 de fevereiro de 2017

VXLAN - Virtual Extensible LAN

Expansão dos Datacenters:

Devido a expansão e mobilidade dos Datacenters, surgiu a necessidade de estender as VLANs através ou além dos DCs, utilizando assim os recursos mais eficientes, considerando VMs que poderão estar alocadas em inumeras localizações físicas distintas, atribuíndo para estas VMs a habilidade de mover-se entre diferentes localizações sob-demanda.

Devido esses cenários fez-se necessário a implantação de tecnologias de sobreposição (overlay). Essa tecnologia tornou-se muito popular devido às suas capacidades de conectividade no espaço lógico a partir da infra-estrutura de rede física.

A rede física tornou-se efetivamente um backplane usado para transportar o tráfego de overlay .

A sobreposição de rede virtual é uma forma de virtualização de rede que cria uma camada virtual de  rede em cima de uma infra-estrutura de rede física.

As técnicas de sobreposição(overlay) ou encapsulamento essencialmente servem para criar uma topologia virtual (ou link virtual) em cima de uma topologia física, adicionando outra camada de encapsulamento para o tráfego original.

Na sobreposição das redes virtuais com produtos como NSX (VMware) trabalham com o encapsulamento de tráfego sendo executado pelo Edge da rede, que na maioria das vezes é o switch virtual que reside no hipervisor dos hosts.

O efeito de dissociação ajuda a resolver muitos dos desafios que os DC tradicionais estão enfrentando hoje em dia tais como:
  • Implementação ágil e rápida de aplicativos: 
    • O design tradicional de redes representa um gargalo de rollout da nova aplicação no ritmo que as empresas estão exigindo. O tempo necessário para provisionar a rede e Infra-estrutura em apoio de um novo aplicativo muitas vezes é contado em dias, se não semanas.
  • Mobilidade de carga de trabalho: 
    • A virtualização computacional permite a mobilidade de cargas de trabalho virtuais em diferentes servidores físicos conectado à rede do data center. Em projetos tradicionais de datacenters, isso requer estender os domínios L2 (VLANs) em toda a infra-estrutura de rede do data center, afetando a escalabilidade global e potencialmente comprometendo a resiliência geral do projeto.
  • Multi-tenancy de grande escala: 
    • O uso de VLANs como um meio de criar redes isoladas limita a 4094 o máximo de tenants que podem ser suportados. Esse número, embora possa parecer grande para implantações corporativas típicas, está se tornando um grave gargalo para a maioria dos provedores de nuvem.
Existem diferentes protocolos de encapsulamento que estão disponíveis para a sobreposição virtual, como VXLAN, STT e NVGRE. As diferenças tecnológicas são pequenas entre os três protocolos e a escolha de qual protocolo deverá ser utilizado para a implementação dependerá do produto que será adotado para a solução.

A solução Virtual Extensible LAN (VXLAN) tornou-se a tecnologia de sobreposição padrão, e utilizada por vários fornecedores. VXLAN foi desenvolvido pela VMware em conjunto com Arista, Broadcom, Cisco, Citrix, Red Hat e outros.

Implantando VXLAN disponibiliza a construção de redes lógicas que proporcionam adjacência L2 entre cargas de trabalho, sem o problema e escalabilidade encontradas com as tecnologias tradicionais da camada 2.

VXLAN: (Virtual Extensive LAN)


VXLAN é uma tecnologia de Ethernet sobre IP, no qual o frame original é encapsulado em um pacote UDP e entregue sobre uma rede de transporte, esta tecnologia prove a habilidade de estender a rede layer 2  através dos limites da rede layer 3 e utilizam a capacidade através de clusters.

Figura 1:;Vxlan Encapsulation
    Encapsular o quadro Ethernet original em um pacote UDP aumenta o tamanho do pacote IP. Por esta razão, o aumento da MTU para um mínimo de 1600 bytes é recomendado para todas as interfaces na infra-estrutura física que irá transportar o quadro. O MTU para os uplinks VDS dos hosts ESXi o encapsulamento VXLAN é aumentado automaticamente quando preparando o host para o VXLAN (a partir da interface de usuário do Gerenciador NSX).

    Recursos da  VXLAN:
    • Permite criar uma rede lógica para as VMs através de diferentes redes.
    • O MTU requirido é o minimo de 1600 bytes para suportar IPv4 e IPv6
    • O tráfego é encapsulado e exposto para o cabeçalho VXLAN pelo Virtual Tunnel end Point (VTEP).
    • Expande o numero de segmentos lógicos de 4094 para mais de 16 milhões;
    • ID da VXLAN é conhecido como VNI (VXLAN network identifier);
    • Aparece transparente para as VMs;
    • Adiciona 50 bytes ao frame original;
    • Vxlan utiliza o protocolo UDP e a porta 8742;
    Observação: A infra-estrutura de rede física deve ser configurada para suportar pelo menos 1550 bytes de MTU.
    • Benefícios:
      • É escalável mutitenance atraves do DC;
      • Fornece habilidade para configurar redes L2 sobre a infraestrutura L3;
      • Os Switches Lógicos atravessam pelos de hosts físicos e switches de rede;
    O modo de agregação recomendado para o tráfego VXLAN para hosts ESXi é o LACP. Fornece a utilização suficiente de ambos os links e redução do tempo de fail-over. Ele oferece a simplicidade de configuração VTEP e solução de problemas.

    VXLAN consiste dos seguintes componentes:

    VTEP: VXLAN Tunnel end Point 
    • Os VTEPs são responsáveis por encapsular e des-encapsular o tráfego de redes VXLAN. Cada host tem um ou dois VTEPs. Eles são atribuídos uma porta VMkernel que se conecta a uma VLAN específica que a sobreposição (VXLAN) irá operar.
    • Por que ter mais de um VTEP em um host? Uma razão é o equilíbrio de carga do seu tráfego VXLAN sobre vários pNICs.
    • Seu host deve ter no mínimo dois uplinks, e eles podem ser conectados ao mesmo switch ou dividir entre switches, LACP pode estar em uso ou não, e todos estes determinam como você vai configurar a sua Política de Teaming.
    • O VTEP pode tanto ser implementado como um módulo de software em um Switch Virtual, em um Servidor ou em um Switch Top-of-Rack (ToR). Uma interface VTEP é vinculada a um endereço IP único e pode ser considerada equivalente a uma interface loopback.
      • Os VTEPs são responsáveis pela encapsulação e descapsulação de cabeçalhos VXLAN;
      • VTEP é uma interface VMKernel que encapsula o frame Ethernet original com o cabeçalho VXLAN;
      • A função do VTEP é encapsular o tráfego da VM dentro de um IP header para enviar através de uma rede IP;
      • NSX oferece  funcionalidade Hardware VTEP com vários parceiros;
      • Hardware VTEP em contexto com VMware NSX referencia switches fisicas ou roteadores com capacidade de VXLAN;
      • É uma entidade que encapsula o frame ethernet em um VXLAN Frame ou expoe um VXLAN frame e encaminha o Frame Etherne
      • É o VMkernel interface que serve como  um endpoint para encapsular o trafego ou expor o trafego VXLAN;
      • Não suporta fragmentação;
      • Usando VTEP o VXLAN aumenta a escalabilidade de componentes de rede;
      • Cada rede VXLAN é uma rede logica isolada;
      • Transporte Zone define o membro ou VTEPS de cada VXLAN overlay pode incluir ESXi hosts de diferentes VMware vSphere Clusters;
      • Um único cluster pode ser parte de múltiplos transport zones;
    Controlador de Plataforma de Virtualização de Rede (NVP):
    • NVP Controller é o controlador de rede para gerenciar componentes da nuvem. 
    • O protocolo OVSDB é o protocolo usado para comunicação entre VTEPs e o controlador. 
    • As funções de nível superior do NVP são:
      • Fornecer uma GUI para criar gateways de serviços.
      • Gerencie os VTEPs .
      • Vincula a porta ea VLAN;
      • Instalar túneis VTEP;
      • Distribuir os VTEPs para MAC vinculativo a todos os VTEPs relevantes;
      • Fornecer uma interface para a orquestração em nuvem no gerenciamento de data centers em nuvem.
    VXLAN GATEWAYS:
    • Uma das maneiras de permitir a conexão entre VXLAN e uma VLAN tradicional é através de um equipamento (virtual ou não) chamado de VXLAN Gateway.
    • Os Gateways VXLAN atuam como os VTEPs que encapsulam e desencapsulam cabeçalhos VXLAN.
      • Os papéis e responsabilidades do Gateway são:
      • Conecta-se ao cliente NVP com base na configuração do usuário;
      • Anuncia as portas voltadas para o sul do VXLAN para o cliente NVP;
      • Cria redes lógicas baseadas em mensagens do NVP;
      • Cria túneis para VTEPs com base em mensagens do NVP;
      • Vincula a porta e a VLAN a redes lógicas baseadas em mensagens do NVP;
      • Vincula MACs ao VTEP e à rede lógica baseada em mensagens do NVP;
      • Anuncia MACs aprendidos em portas compatíveis com VXLAN voltadas para o sul para o cliente NVP.
    VXLAN Frame Walk
    • VM1 envia o quadro(frame) l2 para o VTEP local
    • VTEP adiciona o VXLAN, UDP e IP header
    • Transporte fisico encaminha como um pacote IP regular
    • Destination Hypervisor VTEP de-encapsulates Frame
    • L2 Frame encaminha para a VM2
    VXLAN LIF:
    • VLXAN  LIFs é um tipo de conexão ascendente mais comum. O Roteamento Lógico funciona com segmentos de chave lógica VXLAN. O primeiro encaminhamento de salto é tratado no host e o tráfego é roteado para a VXLAN correspondente. Se necessário, ele é encapsulado para seguir através da rede de transporte para chegar ao destino em outro host.
    • Uma instância designada não é necessária no caso de VXLAN LIFs. O próximo roteador de salto é geralmente uma VM dentro da zona de transporte - como um Gateway de Serviços de Borda NSX. Recomenda-se que o roteamento lógico distribuído alavanque VXLAN LIFs, pois eles funcionam melhor com esse recurso. Um VXLAN LIF pode abrangir todos os VDS na zona de transporte.
    • Há três casos de uso nos quais as interfaces LIF podem ser configuradas. Existem três configurações de interface LIF internas para uplink:
      • VXLAN para VXLAN
      • VXLAN para VLAN
      • VLAN para VLAN
    VLAN LIF
    • Nem todas as redes exigem ou têm conectividade VXLAN em todos os lugares. O DLR pode ter um uplink que se conecta a grupos de portas VLAN. O primeiro hop de roteamento é tratado no host, em seguida, roteados em um segmento VLAN. Deve haver uma ID de VLAN associada ao dvPortGroup.
    •  A VLAN 0 não é suportada. VLAN LIFs requerem uma instância designada.
    • VLAN LIF geralmente introduzem algumas limitações de projeto em uma rede. Uma consideração de design de um PortGroup por switch distribuído virtual pode limitar este tipo de ligação ascendente e só pode haver um VDS. A mesma VLAN deve abranger todos os hosts no VDS. Isso não se dimensiona à medida que a Virtualização de Rede procura reduzir o consumo de VLANs.
    VXLAN Overlay Tunnel:
    • Quando VMs em diferentes hosts comunicam, um VXLAN overlay é estabelecido entre VTEP em ambos os hosts;
    Figura 2: Vxlan Overlay

    VTEP Proxy:
    • É um VTEP que encaminha o tráfego VXLAN do segmento local para outro VTEP em um segmento remoto. É usado em Unicast Tunnel End Point (UTEP) e multicast Tunnel End Poit (MTEP);
    VXLAN Number Identifier:
    • O range de VNI começa em 5000 e varia até 16,7 milhões. Atualmente, há um limite de 10.000 VNIs devido à limitação vCenter de 10.000 dvPortGroups.
    • VNI é 24-bit number que é adicionado ao quadro VXLAN;
    • VNI único segmento que identifica  para qual quadro ethernet pertence;
    • Múltiplos VNIs podem existir no mesmo trasporte zone;
    • NSX for vSphere inicia com VNI 5000;
    VXLAN Protocol:
    • Configura limites de overlay em transporte entre os hosts ESXi.
    Transport Zone:
    • Por padrão, o Modo de Replicação do switch lógico é determinado pelo modo configurado na Zona de Transporte;
    • Todos os clusters da mesma transporte zone compartilham a mesma VNI;
    • Um ou mais vDS podem ser parte do mesmo transporte zone.
    • Um transporte Zone pode conter múltiplos clusters e um cluster pode ser parte de múltiplos transport zones;
    Figura 3: Transport Zone
    Range dos Segmentos de rede / VNI (VXLAN NUMBER IDENTIFIER):
    • O intervalo do pool dos IDs dos segmentos são configurado durante a e preparação do cluster de host. 
    • Os IDs VNI são alocados a partir deste pool e um ID é alocado por Chave Lógica.
    • O pool ID começa em 5000.
    • Se você fez um intervalo de exemplo de 5000-5999 você poderia provisionar 1000 switches lógicos dentro do intervalo.

    Modos de replicação

    Quando duas VMs conectadas a diferentes hosts ESXi precisam se comunicar diretamente, o tráfego unicast VXLAN-encapsulated é trocado entre o VTEP e o endereço IP associados aos seus hipervisores associados. O Tráfego originado por uma VM também pode precisar ser enviado para todas as outras VMs pertencentes ao mesmo switch lógico. As instâncias específicas deste tipo de tráfego L2 incluem transmissão,Unicast e multicast. Estes tipos de tráfego multi-destino refere-se ao uso do acrônimo BUM (Broadcast, Unknown Unicast, Multicast).

    Em cada um desses cenários, o tráfego originado por um determinado host ESXi deve ser replicado para o controle remoto múltiplo.

    O NSX suporta três modos de replicação diferentes para habilitar a comunicação multi-destino em VXLAN com suporte a switches lógicos:
    1. Multicast
    2. Unicast 
    3. Híbrido
    Por padrão, um switch lógico herda sua replicação em modo de Zona de Transporte, embora este comportamento possa ser substituído ao Nível do switch lógico.
    A compreensão do conceito de "segmento VTEP" é importante para discussão dos modos de replicação.


    MODO MULTICAST:

    Requer IGMP para a topologia de camada 2 e multicasting routing para a topologia de camada 3.
    Multicast é visto frequentemente em cenários de upgrade de VMware vCloud Networking e Security
    Quando o modo de replicação Multicast é escolhido para um determinado switch Lógico, o NSX depende da capacidade de multicast L2 / L3 nativa da rede física para garantir que o tráfego multidestino encapsulado em VXLAN seja enviado a todos os VTEPs. O modo de multicast é o processo para tratar o tráfego BUM especificado pelo projecto IETF do VXLAN e não alavanca nenhum dos melhoramentos introduzidos pelo NSX com a introdução dos clusters do controlador. Esse comportamento não alavanca o desacoplamento de redes físicas e lógicas, uma vez que a comunicação no espaço lógico é baseada na configuração de multicast necessária na infra-estrutura de rede física.

    Neste modo, um endereço IP multicast deve ser associado a cada segmento VXLAN L2 definido. A capacidade de multicast L2 é usada para replicar o tráfego para todos os VTEPs no segmento local (ou seja, endereços IP VTEP que fazem parte da mesma sub-rede IP). Além disso, o IGMP snooping deve ser configurado nos switches físicos para otimizar a entrega de tráfego multicast L2. Para garantir que o tráfego multicast também seja entregue aos VTEPs em uma sub-rede diferente do VTEP de origem, o administrador de rede deve configurar o PIM e ativar o roteamento multicast L3.


    Figura 4: Mulicast Mode

    O segmento VXLAN 5001 está associado ao grupo multicast 239.1.1.1. Quando a primeira VM está conectada ao switch lógico, o hipervisor ESXi que hospeda a VM gera uma mensagem de junção IGMP para notificar a infra-estrutura física que está interessada em receber tráfego multicast enviado para esse grupo específico.
    Como resultado das junções IGMP enviadas pelo ESXi1-ESXi-3, o estado multicast é armazenado na rede física para garantir a entrega de quadros multicast enviados para o destino 239.1.1.1. Neste exemplo, o ESXi-4 não envia a junção IGMP porque não hospeda nenhum receptor ativo (isto é, VMs conectadas ao segmento VXLAN 5001).

    Figura 5: Multicast Mode

    Processo de comunição da Vxlan em modo Multicast
    1. VM1 gera um quadro BUM.
    2. ESXi-1 VXLAN - encapsula o quadro original. O endereço IP de destino no cabeçalho IP externo é definido como 239.1.1.1 e o pacote multicast é enviado para a rede física. Nesse caso, o ESXi-1 atua como uma fonte para o fluxo multicast 239.1.1.1.
    3. O comutador L2 que recebe a estrutura multicast e executa replicação. Onde IGMP snooping está configurado no switch, ele será capaz de replicar o quadro para as interfaces relevantes conectar a ESXi-2 e ao roteador L3. Se o IGMP snooping não estiver ativado ou suportado, o switch L2 trata o quadro como um pacote de broadcast L2 e o replica para todas as interfaces pertencentes à mesma VLAN da porta onde o pacote foi recebido.
    4. O roteador L3 executa a replicação multicast L3 e envia o pacote para a sub-rede de transporte B.
    5. O parâmetro L2 comporta-se de forma semelhante ao que foi discutido no passo 3 e replica o enquadramento.
    6. ESXi-2 e ESXI-3 decapsulate os pacotes recebidos VXLAN, expondo os quadros Ethernet originais que são entregues a VM2 e VM3.

    Ao configurar o modo multicast, deve ser feito aconsideração sobre como realizar o mapeamento entre segmentos VXLAN e grupos multicast.


    MODO UNICAST:

    Todo o trafego é replicado pelo VTEP;
    No mesmo segmento o trafego é replicado pelo VTEP de origem;
    Em um segmento de VXLAN remoto o NSX controller instace seleciona o proxy VTEP.

    O modo unicast representa a abordagem oposta do modo multicast, em que a dissociação de redes lógicas e físicas é totalmente alcançada. No modo unicast, os hosts ESXi no domínio NSX são divididos em grupos separados (isto é, segmentos VTEP) com base na sub-rede IP das interfaces VTEP. Um host ESXi em cada segmento VTEP é selecionado para desempenhar o papel de Unicast Tunnel End Point (UTEP). O UTEP é responsável pela replicação de tráfego de destino múltiplo recebido de hypervisors ESXi que hospedam VMs em diferentes segmentos VTEP. Ele distribui esse tráfego para todos os hosts ESXi dentro de seu próprio segmento (isto é, hosts cujos VTEPs pertencem à mesma sub-rede da interface VTEP do UTEP).
    Para otimizar o comportamento de replicação, cada UTEP somente replicará o tráfego para hosts ESXi em um segmento local que tenha pelo menos uma VM ativamente conectada à rede lógica onde o tráfego de destino múltiplo é destinado. Da mesma forma, o tráfego só será enviado pelo ESXi de origem para os UTEP remotos se houver pelo menos uma VM ativa conectada a um host ESXi nesse segmento remoto.

    Figura 6: Unicast Mode


    Processo de comunição da Vxlan em modo Unicast
    1. VM1 gera um quadro BUM para ser enviada para cada VM conectada ao Switch Lógico 5001. Nesse caso, não há necessidade de especificar um grupo multicast associado a este segmento VXLAN.
    2. ESXi 1 referencia a sua tabela VTEP local. Esta tabela é preenchida com a informação recebida através da comunicação do plano de controle com os nós do controlador. A verificação valida a necessidade de replicar o pacote para o outro VTEP pertencente ao segmento local, ESXi2, bem como para a parte UTEP de segmentos remotos, ESXi3. A cópia unicast enviada para o UTEP tem um bit específico definido no cabeçalho VXLAN - o "REPLICATE_LOCALLY" bit - como uma indicação para o UTEP que este quadro é proveniente de um segmento VTEP remoto e pode precisar ser replicado localmente.
    3. O UTEP recebe o quadro, faz referência à tabela VTEP local e o replica a todos os hosts ESXi que fazem parte do segmento VTEP local com pelo menos uma VM conectada ao VXLAN 5001. Neste exemplo, isso é simplesmente ESXi-4 

    O modo de replicação em modo unicast não requer configuração explícita na rede física para permitir a distribuição de tráfego VXLAN de destino múltiplo. Este modo pode ser usado para ambientes de pequeno a médio porte onde o tráfego BUM não é alto e NSX é implantado em uma topologia L2 onde todos os VTEPs estão na mesma sub-rede. O modo Unicast também se adapta bem às topologias L3 onde os limites UTEP podem ser claramente identificados (por exemplo, cada rack L3 tem sua própria sub-rede VTEP). A carga crescente da replicação BUM é gerenciada espalhando a carga entre todos os hosts participantes.


    MODO HYBRIDO:

    É uma replicação local que e descarregada na rede física e faz replicação remota através de unicast;

    Hybrid mode usa IGMP layer 2 multicast para descarregar a replicação local para a rede física;

    Replicação remota usa proxies unicast, assim multicast routing não é necessário

    O modo híbrido oferece simplicidade operacional semelhante ao modo unicast - a configuração de roteamento de multicast IP não é necessária na rede física - enquanto aproveita a capacidade de multicast L2 de switches físicos.
    No modo híbrido, o [M] TEP usa L2 [M] ulticast para replicar os quadros BUM localmente, enquanto o [U] TEP alavanca quadros [U] nicast.

    Figura 7 : Hybrid Mode
    Processo de comunição da Vxlan em modo Hibrido:
    1. VM1 gera um quadro BUM que deve ser replicado para todas as VMs que fazem parte da VXLAN 5001. O grupo multicast 239.1.1.1 deve ser associado ao segmento VXLAN, uma vez que o encapsulamento multicast é realizado para a replicação de tráfego local.
    2. ESXi1 encapsula o quadro em um pacote multicast endereçado ao grupo 239.1.1.1. A configuração de multicast de Camada 2 na rede física é alavancada para garantir que a estrutura VXLAN seja entregue a todos os VTEPs no segmento VTEP local. No modo híbrido, os hosts ESXi enviam uma junção IGMP quando há VMs locais interessadas em receber tráfego de destino múltiplo. Como o PIM não é necessário, é altamente recomendável definir um querler IGMP por VLAN para garantir a entrega multicast L2 bem-sucedida e evitar o comportamento não determinístico. Quando o IGMP snooping está ativado, mas não há nenhuma definição de quermer IGMP, alguns switches Ethernet vão recorrer à inundação do tráfego multicast na VLAN, enquanto outros irão soltá-lo. Consulte a documentação fornecida pelo fornecedor de sua preferência.
    3. Ao mesmo tempo ESXi-1 olha para a tabela VTEP local e determina a necessidade de replicar o pacote para a parte MTEP de segmentos remotos, neste caso ESXi3. A cópia unicast é enviada para o MTEP com o bit correspondente definido no cabeçalho VXLAN como uma indicação para o MTEP que este quadro é proveniente de um segmento VTEP remoto e precisa ser reinjectado localmente na rede.
    4. O MTEP cria um pacote multicast e envia para a rede física onde será replicado pela infra-estrutura de comutação L2 local.
    O modo híbrido permite a implantação do NSX em grandes topologias L2, ajudando a multicast de escala na camada 2 com a simplicidade de unicast. Ele também permite a escala em topologias L3 leafspine sem exigir que o PIM encaminhe multicast (estrutura BUM) além dos limites ToR da camada 3 enquanto ainda permite a replicação multicast em switch físico.
    Para a replicação de camada 2 BUM. Em suma, o modo híbrido aborda o requisito para a replicação BUM no design em grande escala, independentemente da topologia de underlay.

    Segmentação

    VXLAN suporta a segmentação para criar várias redes virtuais diferentes. Esta capacidade de segmentação é projetada na especificação VXLAN com VXLAN ID no cabeçalho VXLAN. O campo é chamado VXLAN Network Identifier ou VNID ou VNI e tem 24 bits de comprimento. Daí, teoricamente, fornece mais de 16 milhões de identificações únicas.

    Na prática, o VNI é usado para criar uma camada de camada 2 lógica nas topologias de rede virtualizadas. Se a VLAN é usada para criar a camada lógica 2 (domínio broadcast) na rede "tradicional", a VNI é usada para criar a camada 2 da rede lógica (domínio broadcast) na rede de sobreposição virtual. Um ou vários VNIs que estão inter-conectados formam uma topologia de rede virtual. Cada topologia de rede virtual pode ser usada para suportar aplicativos para uma unidade de negócios, departamento ou inquilino em um ambiente em nuvem.

    NSX - Load Balancing

    Tendências de balanceamento de carga:

    Existem uma nova tendência para os balanceadores de carga, passando de balanceamento por ambiente para balanceamento por aplicação isso tudo devido o aumento considerável no número de aplicações dentro do Datacenter.

    Outra tendência é o modelo scale-out, considerando a implementação de mais balanceadores no ambiente.

    NSX Edge - Load Balancing:

    O balanceador de carga do NSX Edge permite que o tráfego de rede siga vários caminhos para um destino específico.

    Permite a distribuição de pedidos de serviços de entrada de forma uniforme entre vários servidores de tal forma que a distribuição de carga sendo transparente para os usuários. O balanceamento de carga ajuda assim a alcançar a utilização ideal dos recursos e throughput, minimizando o tempo de resposta e evitando a sobrecarga.

    O NSX Edge fornece balanceamento de carga até a camada 7.

    Os serviços de balanceamento de carga nativamente oferecidos pelo NSX Edge atendem às necessidades da maioria das implantações de aplicativos. Isso ocorre porque o NSX Edge fornece um grande conjunto de funcionalidades:
    • Suporte a todos os aplicativos TCP, incluindo, mas não limitado a, LDAP, FTP, HTTP, HTTPS
    • Suporte UDP aplicação a partir de NSX SW lançamento 6.1.
    Algoritmos de distribuição de balanceamento de carga múltiplos disponíveis: 
      • ROUND_ROBIN
        • Cada servidor é usado por sua vez de acordo com o peso atribuído a ele. Este é o algoritmo mais suave e mais justo quando o tempo de processamento do servidor permanece igualmente distribuído.
      • LEAST_CONN
        • Distribui solicitações de clientes para vários servidores com base no número de conexões já existentes no servidor. Novas conexões são enviadas para o servidor com o menor número de conexões.
      • IP_HASH
        • Seleciona um servidor com base em um hash do endereço IP de origem e destino de cada pacote.
      • URI
        • A parte esquerda do URI (antes do ponto de interrogação) é hash e dividido pelo peso total dos servidores em execução. O resultado indica qual servidor receberá a solicitação. Isso garante que um URI é sempre direcionado para o mesmo servidor, desde que nenhum servidor sai ou desce
    • Verificações de integridade: 
      • TCP
      • HTTP
      • HTTPS
      • incluindo inspeção de conteúdo
    • Persistência:
      • IP de origem
      • MSRDP
      • cookie 
      • ssl session-id
    • Acoplamento da conexão: conexões e conexões máximas / seg.
    • L7, incluindo, mas não limitado a, bloco de URL, reescrita de URL, reescrita de conteúdo
    • Otimização através do suporte de descarga SSL
    Obs.: A plataforma NSX também pode integrar serviços de balanceamento de carga oferecidos por fornecedores terceirizados;

    Escalabilidade:

    Em termos de escalabilidade e números de throughput, os serviços de balanceamento de carga NSX oferecidos por cada NSX Edge individual podem escalar até (melhor cenário):
    • Throughput: 9.2 Gbps
    • Conexões simultâneas: 1 milhão
    • Novas conexões por segundo: 131k
    • Obs.: Load Balance suporta no máximo 64 Virtual IPs;
    Se o balanceador de carga é configurado modo de alta disponibilidade (HA) e se o Load Balancer principal tiver uma falha, o Load Balancer secundário NSX assume a função de primário. Os fluxos existentes precisarão ter suas conexões restabelecidas.

    Licenciamento:

    A licença não esta associada ao número de NSX Edge, esta associado ao Host ou seja etas associado diretamente a quantidade de sockets/CPU


    NSX Edge oferece suporte para dois tipos de configuração de Load Balancing:

    One-arm mode e Inline mode.

    One-arm mode: (chamado modo proxy): Consiste em implantar um NSX Edge diretamente conectado à rede lógica que fornece serviços de balanceamento de carga para.


    1. O cliente externo envia tráfego para o endereço IP virtual (VIP) exposto pelo balanceador de carga.
    2. O balanceador de carga executa duas traduções de endereço nos pacotes originais recebidos do cliente: NAT de destino (D-NAT) para substituir o VIP pelo endereço IP de um dos servidores implantados no farm de servidores e NAT de origem (S-NAT) para substituir o endereço IP do cliente pelo endereço IP identificando o balanceador de carga propriamente dito. S-NAT é obrigado a forçar através do LB o tráfego de retorno do farm de servidores para o cliente.
    3. O servidor no farm de servidores responde enviando o tráfego para o LB (por causa da função S-NAT discutida anteriormente).
    • O LB executa novamente um serviço NAT de Origem e Destino para enviar tráfego para o cliente externo aproveitando seu VIP como endereço IP de origem.

    A vantagem deste modelo é que é mais simples de implementar e flexível, pois permite a implantação de serviços LB (appliances NSX Edge) diretamente nos segmentos lógicos onde eles são necessários sem exigir qualquer modificação no NSX Edge centralizado, fornecendo comunicação de roteamento para a rede física . No lado negativo, essa opção requer o provisionamento de mais instâncias do NSX Edge e impõe a implantação do NAT de origem que não permite que os servidores do DC tenham visibilidade no endereço IP do cliente original.

    O LB pode inserir o endereço IP original do cliente no cabeçalho HTTP antes de executar S-NAT (uma função chamada "Inserir Encaminhamento X-Para cabeçalho HTTP"). Isso fornece a visibilidade dos servidores no endereço IP do cliente, mas é obviamente limitado ao tráfego HTTP.


    Inline mode: (chamado modo transparente) exige, em vez disso, implantar o NSX Edge inline no tráfego destinado ao farm de servidores.


    1. O cliente externo envia tráfego para o endereço IP virtual (VIP) exposto pelo balanceador de carga.
    2. O balanceador de carga (centralizado NSX Edge) executa apenas NAT de destino (D-NAT) para substituir o VIP pelo endereço IP de um dos servidores implantados no farm de servidores.
    3. O servidor no farm de servidores responde ao endereço IP do cliente original e o tráfego é recebido novamente pelo LB, uma vez que é implantado inline (e geralmente como o gateway padrão para o farm de servidores).
    4. O LB executa Source NAT para enviar tráfego para o cliente externo alavancando seu VIP como endereço IP de origem.

    Esse modelo de implantação também é bastante simples e permite que os servidores tenham total visibilidade do endereço IP do cliente original. Ao mesmo tempo, é menos flexível do ponto de vista do projeto, pois geralmente força o uso do LB como gateway padrão para os segmentos lógicos em que os farms de servidores são implantados e isso implica que apenas o roteamento centralizado (e não distribuído) deve ser adotado para aqueles Segmentos. Também é importante notar que neste caso o LB é outro serviço lógico adicionado ao NSX Edge já fornecendo serviços de roteamento entre as redes lógica e física. Como conseqüência, é recomendável aumentar o fator de forma do NSX Edge para X-Large antes de habilitar serviços de balanceamento de carga.

    Comandos via CLI:

    Check LB engine status (L4/L7)

    • # show service loadbalancer

    Check LB objects statistics (vips, pools, members)

    • # show service loadbalancer virtual [vip-name]
    • # show service loadbalancer pool [poo-name]

    Check Service Monitor status (OK, WARNING, CRITICAL)

    • # show service loadbalancer monitor

    Check system log message

    • # show log

    Check LB session table

    • # show service loadbalancer session

    Check LB L7 sticky-table status

    • # show service loadbalancer table

    5-Tuple Firewall

    N-tuple

    Um dos principais desafios no datacenter moderno é melhorar constantemente a implementação de segurança global. Nos firewalls tradicionais, estamos construindo nossas regras de política baseadas no famoso 5-tuple (IP de Origem, Porta de Origem, IP de Destino, Porta de Destino, Protocolo) para corresponder a um fluxo específico

    Foi interessante para a primeira geração de firewalls statefull, mas a centralidade não é suficiente para alcançar uma melhor segurança em ambientes de rápida dinâmica, onde diferentes usuários de diferentes papéis precisam acessar nossos aplicativos residem dentro do datacenter.

    N-tuple é uma coleção de atributos. E, no caso de firewalls, esses atributos são usados ​​para definir requisitos de acesso. N é um suporte de lugar que representa o número de atributos na lista.

    Por exemplo, um 5-tuple "firewall permitir regra" pode incluir:

    1. Endereço IP de origem
    2. Porta de origem (normalmente: qualquer)
    3. Endereço IP de destino
    4. Porta de destino (80 ou 443)
    5. Protocolo de destino (tipicamente TCP)


    Assim, se o pacote que está sendo inspecionado tem todos os atributos corretos, o firewall permitirá que ele passe.

    Uma regra de firewall de primeira geração emprega uma coleção de 5 atributos ou 5-tuplas. Isso é suficiente para realizar inspeção de porta e protocolo com status, tradução de endereços de rede e tecnologia de rede privada virtual.

    Um conjunto de regras de 5-tuplas não é suficiente para NGFWs. Os firewalls NG de próxima geração precisam de atributos adicionais, como tipo de aplicativo e identidade de usuário, para funcionar como anunciado. Para entender o porquê, considere a analogia da porta 80, uma última vez.

    quinta-feira, 23 de fevereiro de 2017

    Cisco Embedded Event Manager (EEM)

    O Embedded Event Manager (EEM)  ou Gerenciador de eventos incorporados


    É uma abordagem distribuída e personalizada para a detecção e recuperação de eventos oferecida diretamente em um dispositivo Cisco IOS. O EEM oferece a capacidade de monitorar eventos e tomar ações informativas, corretivas ou qualquer ação EEM desejada quando os eventos monitorados ocorrem ou quando um limite é atingido. 
    Uma política EEM é uma entidade que define um evento e as ações a serem tomadas quando esse evento ocorre.

    Existem dois tipos de políticas de EEM: um applet ou um script.
    1. Um applet é uma forma simples de política que é definida dentro da configuração do CLI. 
    2. Um script é uma forma de diretiva que é escrita em Tool Command Language (Tcl).
    Um applet EEM é um método conciso para definir critérios de triagem de eventos e as ações a serem tomadas quando esse evento ocorre. No modo de configuração do applet, três tipos de instruções de configuração são suportados. Os comandos de evento são usados para especificar os critérios de evento para acionar o applet a ser executado, os comandos de ação são usados para especificar uma ação a ser executada quando o applet EEM é disparado eo comando set é usado para definir o valor de uma variável de applet EEM . Atualmente, somente a variável _exit_status é suportada para o comando set.

    CLI Event Detector

    O Detector de eventos CLI exibe comandos de interface de linha de comando (CLI) para uma através de uma expressão regular. Quando uma correspondência é encontrada, um evento é publicado. A lógica de correspondência é executada no comando CLI totalmente expandido após o comando ser analisado com êxito e antes de ser executado.

    O detector de eventos CLI suporta três modos de publicação:
    • Publicação síncrona de eventos CLI - O comando CLI não é executado até que a política EEM seja encerrada e a política EEM possa controlar se o comando é executado. A variável de leitura / gravação, _exit_status, permite que você defina o status de saída na saída de diretiva para diretivas disparadas de eventos síncronos. 
      • Se _exit_status for 0, o comando será ignorado, 
      • Se _exit_status for 1, o comando será executado.
    • Publicação assíncrona de eventos CLI - O evento CLI é publicado e, em seguida, o comando CLI é executado.
    • Publicação assíncrona de eventos CLI com comando ignorando - O evento CLI é publicado, mas o comando CLI não é executado.

    Counter Event Detector - Detector de Eventos Contador

    O detector de contador de eventos publica um evento quando um contador nomeado cruza um limite especificado.
    Há dois ou mais participantes que afetam processamento de contador. 
    1. O detector de contador pode modificar o contador, e um ou mais assinantes definem os critérios que fazem com que o evento seja publicado. 
    2. Após a publicação de um evento de contador, a lógica de monitoração do contador pode ser reinicializada para iniciar o monitoramento imediato do contador ou pode ser redefinida quando um segundo limite - chamado de valor de saída - é cruzado.

    Custom CLI Event Detector - Detector de Eventos CLI personalizado

    O detector de eventos CLI personalizado publica um evento para adicionar e aprimorar a sintaxe do comando CLI existente. Quando os caracteres do analisador especial Tab,? (Ponto de interrogação) e Enter, o analisador envia a entrada para o detector de eventos CLI personalizado para processamento. O detector de eventos CLI personalizado compara esta entrada com as cadeias registradas para determinar se este é um comando CLI novo ou aprimorado. Em cima de um fósforo o detetor feito sob encomenda do evento de CLI faz exame de ações apropriadas, tais como indicar a ajuda para o comando se? É inserido, exibindo todo o comando se Tab for inserido, ou executando o comando se Enter foi inserido. Se uma correspondência não ocorrer, o analisador recupera o controle e processa as informações como de costume.

    Enhanced Object Tracking Event Detector 

    O detector de eventos de rastreamento de objeto avançado (EOT) publica um evento quando o status de um objeto rastreado é alterado. O rastreamento de objetos foi introduzido pela primeira vez no HSRP (Hot Standby Router Protocol) como um simples mecanismo de rastreamento que permitia rastrear apenas o estado do protocolo de linha de interface. Se o estado do protocolo de linha da interface caísse, a prioridade HSRP do roteador foi reduzida, permitindo que outro roteador HSRP com prioridade mais alta se tornasse ativo.

    O rastreamento de objetos foi aprimorado para fornecer uma separação completa entre os objetos a serem rastreados ea ação a ser tomada por um cliente quando um objeto rastreado muda. Assim, vários clientes como HSRP, VRRP ou GLBP podem registrar seu interesse com o processo de rastreamento, rastrear o mesmo objeto e cada um tomar ações diferentes quando o objeto muda. Cada objeto controlado é identificado por um número exclusivo que é especificado na interface de linha de comando de controle (CLI). Os processos cliente usam esse número para rastrear um objeto específico. O processo de rastreamento periodicamente examina os objetos rastreados e anota qualquer alteração de valor. As alterações no objeto rastreado são comunicadas aos processos cliente interessados, imediatamente ou após um atraso especificado. Os valores de objeto são relatados como para cima ou para baixo.

    O acompanhamento avançado de objetos agora está integrado ao EEM para permitir que o EEM relate uma mudança de status de um objeto rastreado e permita o acompanhamento avançado de objetos para rastrear objetos EEM. Um novo tipo de objeto de rastreamento - um objeto stub - é criado. O objeto stub pode ser manipulado usando os comandos CLI existentes que já permitem que objetos controlados sejam manipulados.

    GOLD Event Detector

    O detector de eventos GOLD publica um evento quando um evento de falha GOLD é detectado em um cartão especificado e subcard.

    Interface Counter Event Detector

    O detector de eventos de contador de interface publica um evento quando um contador de interface genérico Cisco IOS para uma interface especificada cruza um limite definido. Um limite pode ser especificado como um valor absoluto ou um valor incremental. Se o valor incremental for definido como 50, por exemplo, um evento seria publicado quando o contador de interface aumenta em 50.

    Depois de um evento de contador de interface ter sido publicado, a lógica de monitoramento do contador de interface é redefinida usando dois métodos.

    • O contador de interface é redefinido quando um segundo limite - chamado de valor de saída - é cruzado ou quando ocorre um período de tempo decorrido.
    Environment Variable


    • _interface_is_increment = A value to indicate whether the current interface counter value is an absolute value (0) or an increment value (1).
    • _interface_name = The name of the interface to be monitored.
    • _interface_parameter = The name of the interface counter to be monitored.
    • _interface_value = A value with which the current interface counter value is compared

    O exemplo a seguir mostra como uma diretiva chamada EventInterface é acionada toda vez que o contador receive_throttle para a interface Fast Ethernet 0/0 é incrementado em 5. O intervalo de polling para verificar o contador é especificado para ser executado uma vez a cada 90 segundos.

    event manager applet EventInterface
     event interface name FastEthernet0/0 parameter receive_throttle entry-op ge entry-val 5
     entry-val-is-increment true poll-interval 90
     action 1.0 syslog msg "Applet EventInterface"




    IP SLA Event Detector

    O detector de eventos IP SLA publica um evento quando uma reação SLA IP é acionada.

    NetFlow Event Detector

    O detector de eventos NetFlow publica um evento quando um evento NetFlow é disparado.

    None Event Detector

    O detector de nenhum evento publica um evento quando o comando de CLI do gerenciador de eventos Cisco IOS executa uma diretiva de EEM. O EEM agende e executa políticas com base em uma especificação de evento contida na própria política. Uma política de EEM deve ser identificada e registrada para ser permitida para ser executada manualmente antes que o comando de execução do gerenciador de eventos seja executado.

    OIR Event Detector

    O detector de eventos de inserção e remoção on-line (OIR) publica um evento quando ocorre um dos seguintes eventos de inserção ou remoção de hardware:

    • Um cartão é removido.
    • Um cartão é inserido.

    Route Processors (RPs), cartões de linha ou cartões de características podem ser monitorados para eventos OIR.

    Resource Event Detector

    O detector de eventos de recurso publica um evento quando o Gerenciador de Recursos Incorporado (ERM) relata um evento para a diretiva especificada. A infra-estrutura de ERM controla o esgotamento de recursos e as dependências de recursos entre processos e dentro de um sistema para lidar com várias condições de erro. As condições de erro são tratadas fornecendo uma partilha equitativa de recursos entre várias aplicações. O framework ERM fornece um mecanismo de comunicação para entidades de recursos e permite a comunicação entre essas entidades de recursos de vários locais. A estrutura ERM também ajuda na depuração de CPU e problemas relacionados à memória. O ERM monitora o uso de recursos do sistema para entender melhor as necessidades de escalabilidade, permitindo que você configure valores de limite para recursos, como a CPU, os buffers e a memória. O detector de eventos ERM é o método preferido para monitorar recursos no software Cisco IOS, mas o detector de eventos ERM não é suportado em imagens de Software Modularity. Para obter mais detalhes sobre o ERM, vá para o módulo "Embedded Resource Manager"

    RF Event Detector

    O detector de eventos de estrutura de redundância (RF) publica um evento quando ocorrem um ou mais eventos de RF durante a sincronização em um sistema de processador de rota dupla (RP). O detector de eventos de RF também pode detectar um evento quando um sistema RP duplo alterna continuamente de um RP para outro RP (referido como situação de ping-pong).

    RPC Event Detector

    O detector de eventos de chamada de procedimento remoto (RPC) fornece a capacidade de invocar políticas de EEM de fora do roteador por meio de uma conexão criptografada usando o Secure Shell (SSH). O detector de eventos RPC usa a codificação de dados SOAP (Simple Object Access Protocol) para trocar mensagens baseadas em XML. Esse detector de eventos pode ser usado para executar políticas EEM e, em seguida, receber saída em uma resposta SOAP XML-formatado.

    Routing Event Detector

    O detector de eventos de roteamento publica um evento quando uma entrada de rota muda na Routing Information Base (RIB).

    SNMP Event Detector

    O detector de eventos SNMP permite que um objeto MIB SNMP padrão seja monitorado e um evento a ser gerado quando o objeto coincide com valores especificados ou cruza limites especificados.

    SNMP Notification Event Detector

    O detector de eventos de notificação SNMP fornece a capacidade de interceptar SNMP trap e informar as mensagens entrando ou saindo do roteador. Um evento de notificação SNMP é gerado quando uma mensagem SNMP de captura ou de entrada de entrada ou de saída corresponde a valores especificados ou cruza limites especificados. O detector de eventos SNMP pode esperar e interceptar as traps SNMP de saída e informa.

    SNMP Object Event Detector

    O detector de evento de trap de objeto do SNMP (Simple Network Management Protocol) fornece uma extensão para substituir o valor quando um trap SNMP com o ID de objeto SNMP especificado (OID) for encontrado em uma interface ou endereço específico.

    Syslog Event Detector

    O detector de eventos syslog permite a triagem de mensagens syslog para uma correspondência de padrão de expressão regular. As mensagens selecionadas podem ser mais qualificadas, exigindo que um número específico de ocorrências seja registrado dentro de um tempo especificado. Uma correspondência em um critério de evento especificado aciona uma ação de política configurada.

    System Manager Event Detector

    O detector de eventos do gerenciador de sistema gera eventos para o início do processo de Cisco IOS Software Modularity, parada normal ou anormal e reinício de eventos. Os eventos gerados pelo gerenciador de sistema permitem que as políticas alterem o comportamento padrão do reinício do processo.

    Timer Event Detector

    O detector de eventos do temporizador publica eventos para os seguintes quatro tipos diferentes de temporizadores:

    1. Um temporizador de tempo absoluto do dia publica um evento quando ocorre uma data e hora absolutas especificadas.
    2. Um temporizador de contagem decrescente publica um evento quando um contador de tempo contagem decrescente para zero.
    3. Um temporizador de vigilância publica um evento quando um temporizador conta para baixo para zero e, em seguida, o temporizador automaticamente restabelece a si próprio para o seu valor inicial e começa a contagem regressiva novamente.
    4. Um temporizador CRON publica um evento utilizando uma especificação CRON padrão UNIX para indicar quando o evento deve ser publicado. Um temporizador CRON nunca publica eventos mais do que uma vez por minuto.

    Embedded Event Manager Actions


    As ações corretivas baseadas em CLI que são tomadas quando detectores de eventos relatam eventos permitem um poderoso mecanismo de gerenciamento de eventos no dispositivo. Algumas ações do EEM estão disponíveis em cada versão do Cisco IOS, mas a maioria das ações do EEM foi introduzida em uma versão específica. Para obter detalhes sobre qual ação do EEM é suportada em cada versão do Cisco IOS, consulte o conceito EEM Actions Available pelo Cisco IOS Release na seção "Redação de políticas do Embedded Event Manager usando o CLI do IOS Cisco" ou os módulos "Writing Embedded Event Manager Policies Using Tcl" .

    A EEM apoia as seguintes ações:

    • Executando um comando da interface de linha de comando do Cisco IOS (CLI).
    • Gerando um evento CNS para processamento upstream por dispositivos Cisco CNS.
    • Definir ou modificar um contador nomeado.
    • Mudando para um processador secundário em uma configuração de hardware totalmente redundante.
    • Solicitando informações do sistema quando ocorre um evento.
    • Enviando um e-mail curto.
    • Executando manualmente uma política de EEM.
    • Publicando um evento específico do aplicativo.
    • Recarregar o software Cisco IOS.
    • Gerando uma armadilha SNMP.
    • Gerando mensagens syslog priorizadas.
    • Lendo o estado de um objeto rastreado.
    • Definindo o estado de um objeto rastreado.

    Os comandos de CLI da ação EEM contêm um rótulo de ação EEM que é um identificador exclusivo que pode ser qualquer valor de seqüência de caracteres. As ações são classificadas e executadas em seqüência alfanumérica ascendente (lexicográfica) usando o rótulo como a chave de classificação. Se você estiver usando números como rótulos, esteja ciente de que a classificação alfanumérica classificará 10.0 depois de 1.0, mas antes de 2.0, e nessa situação, recomendamos que você use números como 01.0, 02.0 e assim por diante ou use uma letra inicial seguida por números .

    Embedded Event Manager Environment Variables

    O EEM permite que variáveis ​​de ambiente sejam usadas em políticas de EEM. O Tool Command Language (Tcl) permite definir variáveis ​​globais conhecidas por todos os procedimentos dentro de um script Tcl. O EEM permite que as variáveis ​​de ambiente sejam definidas usando um comando CLI, o comando de ambiente do gerenciador de eventos, para uso dentro de uma diretiva de EEM. Todas as variáveis ​​de ambiente EEM são automaticamente atribuídas a variáveis ​​globais Tcl antes que um script Tcl seja executado.

    Existem três tipos diferentes de variáveis ​​de ambiente associadas ao Embedded Event Manager:

    • Definido pelo usuário - Definido por você se você criar uma variável de ambiente em uma diretiva que você escreveu.
    • Definido pela Cisco - Definido pela Cisco para uma política de amostra específica.
    • Cisco built-in (disponível em applets EEM) - Definido pela Cisco e pode ser somente leitura ou leitura / gravação. As variáveis ​​somente leitura são definidas pelo sistema antes que um applet comece a ser executado. A única variável de leitura / gravação, _exit_status, permite que você defina o status de saída na saída de diretiva para diretivas disparadas de eventos síncronos.

    Embedded Event Manager Policy Creation

    O EEM é um processo orientado por políticas no qual o mecanismo de política EEM recebe notificações quando falhas e outros eventos ocorrem no sistema de software Cisco IOS. As diretivas do Embedded Event Manager implementam a recuperação com base no estado atual do sistema e nas ações especificadas na política para um determinado evento. As ações de recuperação são acionadas quando a diretiva é executada.

    Embora existam alguns comandos EEM CLI de configuração e show, o EEM é implementado através da criação de políticas. Uma política EEM é uma entidade que define um evento e as ações a serem tomadas quando esse evento ocorre. Existem dois tipos de políticas de EEM: um applet ou um script. Um applet é uma forma simples de política que é definida dentro da configuração do CLI. Um script é uma forma de política que está escrito em Tcl.

    A criação de uma política de EEM envolve:

    1. Selecionando o evento para o qual a diretiva é executada.
    2. Definir as opções do detector de eventos associadas ao log e responder ao evento.
    3. Definindo as variáveis ​​de ambiente, se necessário.
    4. Escolhendo as ações a serem realizadas quando o evento ocorre.
    5. Há duas maneiras de criar uma política de EEM. O primeiro método é escrever applets usando comandos CLI, eo segundo método é escrever scripts Tcl. A Cisco fornece aprimoramentos para o Tcl na forma de extensões de comando Tcl que facilitam o desenvolvimento de políticas de EEM. Scripts são definidos fora do dispositivo de rede usando um editor ASCII. O script é então copiado para o dispositivo de rede e registrado com o EEM. Quando uma diretiva é registrada no Embedded Event Manager, o software examina a diretiva e registra-a para ser executada quando o evento especificado ocorre. As políticas podem ser canceladas ou suspensas. Ambos os tipos de políticas podem ser usados ​​para implementar o EEM na sua rede.


    Pré-requisitos para Redação de Diretivas de EEM Usando o Cisco IOS CLI


    • Se o comando action cns-event for usado, o acesso a um gateway de eventos do Cisco Networking Services (CNS) deve ser configurado.
    • Se o comando de força de ação for usado, um processador secundário deve ser configurado no dispositivo.
    • Se o comando snmp-trap de ação for usado, o comando snmp-server enable traps event-manager deve ser habilitado para permitir que traps SNMP sejam enviados do dispositivo Cisco IOS para o servidor SNMP. Outros comandos snmp-server relevantes também devem ser configurados; Para obter detalhes, consulte a página de comando action snmp-trap.

    How to Write EEM Policies Using the Cisco IOS CLI




    Fonte:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/eem/configuration/12-4t/eem-12-4t-book/eem-overview.html