IOS on Cisco Redes

Ansible – Configuração via CSV File – Parte 1

Thu, 08 Mar 2018 00:00:00 +0000

Olá Pessoal,

Dando sequência as nossas publicações sobre Ansible, e como já comentei com vocês que estou pegando alguns exemplos que de fato são situações que nós Engenheiros de Rede acaba vivenciado para executar esse tipo de trabalho em nosso dia a dia, ou seja, venho com a pergunta. Vocês já receberam aquele Excel ( .csv ), para de fato fazer algumas alterações em seus equipamentos?

Se sim, acredito que você está no caminho correto, pois hoje, venho com mais um exemplo que vamos fazer as preparações para tratar nossos dados e posteriormente criar nossos arquivos de configuração que serão aplicados em nossos equipamentos Cisco ( IOS ).

Vale lembrar, para que seja efetivo nossa Automação precisamos ter um inventário consolidado, onde as informações relacionadas ao nossos equipamentos devem ser coerentes para futuro crescimento de nossa infra-estrutura. Se você ainda não acompanhou os posts anteriores, recomenda-se ler esses tópicos sobre Ansible.

Como vocês podem observar vamos tratar nossos dados via um arquivo ( .csv ), que de alguma forma são valores/informações populadas através de outras fontes ( ferramentas, pessoas, etc ). Em nosso exemplo, estou colocando diversas informações que a principio vocês possam não entender, mas no decorrer de nossos posts isso fará sentido para o entendimento correto e as opções que podemos criar em nossa automação.

inventory_hostname,DHCP,dhcp_exclude1_start,dhcp_exclude1_end,dhcp_network,dhcp_netmask,dhcp_gateway,new_hostname,id_loopback,ip_loopback,mask_loopback
R1,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R1_floor1,10,10.10.10.1,255.255.255.255
R2,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R2_floor1,10,10.10.10.1,255.255.255.255
R3,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R3_floor1,10,10.10.10.1,255.255.255.255
R4,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R4_floor1,10,10.10.10.1,255.255.255.255
R31,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R31_floor1,10,10.10.10.1,255.255.255.255
R32,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R32_floor1,10,10.10.10.1,255.255.255.255
R5,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R5_floor1,10,10.10.10.1,255.255.255.255
R6,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R6_floor1,10,10.10.10.1,255.255.255.255

Como vocês podem observar isso são exemplos e vocês podem adaptar conforme sua necessidade e as solicitações que são exigidas pelas diferentes áreas de sua empresa. Todo o desenvolvimento de nossa automação também é muito co-relacionada com a estrutura de pastas e arquivos que vamos utilizar dentro do Ansible, portanto segue a estrutura que estou utilizando para esse exemplo.

Uma outra informação diferente dos exemplos citados em nossos posts sobre Ansible, é que estou criando como fictício todos esses roteadores em nosso arquivo de inventário ( ./hosts ), para que nosso exemplo seja mais robusto e obviamente no final de nosso exemplo irei demonstrar como aplicar as configurações. Segue meu inventário criado para esse exemplo:

[routers-client]
R1 ansible_host=192.168.0.22
R2 ansible_host=192.168.0.23
R31 ansible_host=192.168.0.24
R5 ansible_host=192.168.0.25
R6 ansible_host=192.168.0.26

Tendo como base essas informações vamos trabalhar com um módulo que Ansible oferece que é de executar um “ lookup ” dentro de um arquivo ( .csv ). Para que nosso código seja mais estruturado minha playbook principal irá chamar minha “ role ” definida como ( ./lookup_csv_info.yaml ).

---
- name: JINJA AND CSVFILE
  hosts: all
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: LOOKUP IN CSV FILE
    include_role:
      name: lookup_csv_info
    when: ./excel/test.csv is defined

Talvez vocês devem estar se perguntando o porque utilizar “ roles ” dentro desse código? De fato a funcionalidade role é muito utilizada no sentido de trazer mais dinamismo, funcionalidade e flexibilidade para seu código, pois eles podem se tornar difíceis de gerenciar e difíceis de manter com um único arquivo. As roles permitem que você crie playbooks mínimas que, em seguida, busque uma estrutura de diretório para determinar as etapas de configurações reais que precisam executar, bem como proceder para as próximas roles se anterior foi executada/validada da forma correta.

Seguindo essa linha de raciocínio, demostro agora a playbook específica que irá pesquisar todas as informações dentro de nosso arquivo ( .csv ). Ressalto, que em nosso arquivo temos mais informações do que de fato existem ( hostnames ) nosso arquivo de ( ./hosts ), ou seja, estamos pesquisando em nossa planilha se existem elementos que coincidem com nosso inventário.

---
- name: GET VARIABLES FROM CSVFILE
  set_fact:
    vars_dict:
        DHCP: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=1 delimiter=,') }}"
        dhcp_exclude1_start: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=2 delimiter=,') }}"
        dhcp_exclude1_end: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=3 delimiter=,') }}"
        dhcp_network: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=4 delimiter=,') }}"
        dhcp_netmask: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=5 delimiter=,') }}"
        dhcp_gateway: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=6 delimiter=,') }}"
        new_hostname: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=7 delimiter=,') }}"
        id_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=8 delimiter=,') }}"
        ip_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=9 delimiter=,') }}"
        mask_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=10 delimiter=,') }}"
  with_items: "{{ inventory_hostname }}"

Para que possamos ver que as informações estão sendo capturadas vamos colocar uma task contendo debug de uma variável para observar o comportamento. Essa variável em nosso caso é ” var_dict ” onde se tem todo o ” dicionário ” com os valores populados de cada elemento. Para adicionar essa validação foi inserido o comando:

  - debug: var={{'vars_dict'}}

Desta forma temos esse output e a confirmação que os dados estão sendo populados corretamente.

Acredito que vocês observaram que temos todos os elementos que foram lidos/capturados baseado em cada coluna de nosso arquivo ( .csv ) comparado ao nosso inventário em uma única “ task “. Porquê?

Isso está relacionado justamente com ” loops ” que podemos criar dentro de nossas “ tasks “, fazendo com que ele faça a mesma tarefa diversas vezes baseado no requisito que estamos utilizando. Para nosso exemplo estou usando a variável “ {{ inventory_hostname }} “, justamente para que ela pesquise no arquivo todos os roteadores expostos no arquivo ( ./hosts ). Essa função pode ser observada através do ” with_items: “.

Espero que vocês tenham gostado e no próximo post vou detalhar como trabalhar com esse dados.

Abs,
Rodrigo

Comandos Básicos Cisco – Resumo Vídeo Aulas

Sat, 19 Nov 2016 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar com voces nossa playlist no youtube, onde inicio as explicações sobre os comandos básicos para Cisco.

Vale a pena conferir e entender um pouco mais sobre a CLI. Compartilhe nosso canal!!

Subscribe to my channel

Aula 1 - Comandos Básico - Cisco

Aula 2 - Comandos Básico - Cisco

Aula 3 - Comandos Básico - CLI Cisco

Aula 4 - Comandos Básicos - Estrutura IOS

Abs,
Rodrigo

Protocolo OSPF – parte 7

Thu, 19 Jul 2012 00:00:00 +0000

Olá Caros,

Conforme nossa menção no post anterior, vamos hoje falar sobre a sumarização de rotas no OSPF.

Sumarização de rotas consiste na consolidação de múltiplas rotas em um único anúncio. Em uma rede OSPF, esta tarefa normalmente é realizada por um router de borda ( ABR ). Ainda que a sumarização possa ser configurada entre quaisquer duas áreas, a boa prática rege que a sumarização deve ocorrer preferencialmente no sentido do backbone ( Area 0 ). Desta forma, o backbone recebe todas as rotas agregadas e, por sua vez, pode anuncia-las sumarizadas para outras áreas.

Em uma rede OSPF, existem basicamente 2 tipos de sumarização:

Inter-area route summarization = Executado no ABR, cria os LSAs Tipo 3 e 4 e adverte os router IDs do ASBR, ou seja, a sumarização é aplicada as rotas internas do AS, na qual as rotas externas aprendidas via redistribuição não serão consideradas. Segue um exemplo onde teremos essa comunicação:

Para efetuar a configuração no roteador devemos sempre validar se as redes são contíguas e que o range escolhido para efetuar essa sumarização esteja dentro do escopo de suas redes, pois você pode efetuar loop na rede ou efetuar alguma assimetria dependendo de seu design. Segue o comando para efetuar a sumarização:

R2(config)#router ospf 100

R2(config-router)#area 1 range 192.168.10.0 255.255.254.0

Depois dessa configuração o roteador irá criar uma rota apontando para a Null0.

External route summarization= É totalmente específico para as rotas externas, inseridas na rede OSPF via redistribuição, ou seja, essas redes são redistribuídas através do ASBR, para qual irá fazer a troca de um protocolo não OSPF. Gostaria de reforçar que a sumarização deve ser contígua para que não tenhamos problemas de redes sobrepostas. Segue abaixo um exemplo:

Neste caso iremos ter o roteador R3 redistribuindo as redes RIP para a área OSPF, portanto neste roteador podemos fazer uma sumarização de todas as redes que será inserida dentro do OSPF, facilitando dessa forma a tabela de roteamento que iremos ter na tabela de roteamento. Para isso podemos executar dessa forma a sumarização:

R3(config)#router ospf 100

R3(config-router)#summary-address 60.60.60.0 255.255.255.0

Depois dessa configuração o roteador irá criar uma rota apontando para a Null0.

Dessa forma concluímos o processo de sumarização que pode ser executado no protocolo OSPF. Espero que tenham gostado e iremos ter nosso último post de OSPF mencionando sobre métricas ( cálculos ).

Aguardo comentários!!!

Abs,

Rodrigo

QoS – Enfileiramento – Parte 3

Mon, 05 Dec 2011 00:00:00 +0000

Olá pessoal,

Conforme nosso último post, no qual foi mencionado sobre a marcação de pacotes dentro do cabeçalho IP ( ToS ), portanto hoje iremos trazer mais informações sobre QoS, mencionando sobre o método de filas que o equipamento utiliza para encaminhar seus pacotes.

Quando foi explicado sobre a marcação de pacotes e propriamente mencionado sobre as categorias de filas, ou seja, todo esse trabalho exerce uma funcionalidade para que no momento de recebimento desse pacote os equipamentos ( roteadores/swiches ) possam interpretar essa marcação ( preferência ) do pacote, sobre determinadas características em um plano de hardware queueing e software queueing.

Para um melhor entendimento segue um fluxograma de como funciona o tratamento de pacotes:

Para o propósito de hardware queueing:

Esse é o tipo de enfileiramento conhecido como TxQ (fila de transmissão), no qual ele usa o hardware e SEMPRE usa o mecanismo FIFO (First In First Out) e apenas quando essa fila fica cheia o software queueing será acionado. Nesta categoria estamos referenciando-se ao Tx Ring/ TX queue, fazendo dessa forma o enfileiramento quando a fila está cheia, e por sua vez o IOS habilita “queue” nesta interface.

Aqui podemos fazer uma analogia de como os pacotes chegam para uma determinada interface física de um equipamento. 😉

Quando tratamos do assunto de software queueing, teremos 6 categorias para classificar essas informações:

PQ – Priority Queue = Possui 4 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada. Vantagens: Fornece prioridade restrita para um tráfego na classe. Desvantagem: pode sofrer de um fênomeno chamado: starvation (morte por insuficiência de alimentação).
CQ – Custom Queue = Possui 16 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada.Vantagens: garante banda para aplicações menos críticas. Desvantagem: precisa criar uma política dentro da interface.
WFQ – Weighted Fair Queueing = Enfileiramento justo baseado em peso, ele atua de forma justa eliminando o fenômeno stavartion, ou seja, o primeiro da coluna de cada fila é expedido para o DEQUEUE e todos os pacotes da segunda coluna são expedidos e assim sucessivamente. Desvantagem: ideal para links até 2MBps, caso contrário muitos ciclos de CPU serão executados e não possui uma fila única de prioridade.
CBWFQ – Class-Based Weighted Fair Queue = Possui 64 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada. Vantagem: recordista do número de classes, suporta até 64 para realizar controle de banda. Desvantagem: sem fila exclusiva de prioridade.
**LLQ – Low Latency Queue =**Conhecido por PQCBWFQ, devido a possuir uma fila PQ e um grupo em CBWFQ. Infelizmente isso é uma “sopa de letrinhas” 😀 Vantagens: ótimo para arquitetura AVVID da Cisco, excelente para aplicações real-time, garante banda e propicia a menor latência, não apenas para portas UDP/RTP mas qualquer outro tipo de porta. O seu único problema diz respeito a sua classificação não ser feita de modo automatizado, havendo a necessidade de configuração. Esse é o nosso método mais utilizado, porém se as classes não estiverem bem ajustadas conforme a realidade, podemos ter alguns problemas, que daí para frente teremos que realizar alguns troubleshootings!
IP RTP Priority = Conhecido por PQWFQ, por ser composto por uma fila PQ e o grupo de WFQ.Vantagens: ótimo para arquitetura AVVID da Cisco, garante banda e propicia a menor latência, não apenas para portas.

Abaixo segue uma tabela comparativa com as filas mais usuais que encontramos no nosso dia-a-dia:

Por padrão o FIFO é habilitado nas interfaces com a bandwidth acima de 2mbps e também por padrão o WFQ é habilitado nas interfaces com a bandwidth abaixo de 2Mbps

Baseado nessas informações temos mais um conceito que é obtido em nossas vídeo aulas, para qual tratamos de métodos para evitar o congestionamento. Na Cisco nós trabalhamos com três métodos, no qual chamamos de Tail DROP, WRED ( Weighted Randon Early Drop ) e CBWRED. Não vamos entrar muito em detalhes para não ficar extenso nosso post, mas podemos explicar rapidamente cada método:

Tail DROP = Descarte de pacotes baseado em hardware e software quando a fila está cheia, ou seja, novos pacotes que chegam na interface são dropados.
WRED = Característica do IOS utilizada para previnir que uma fila seja preenchida pela capacidade descartar o tráfego mais agressivamente quando a fila começa a se preencher. O descarte é feito baseado na prioridade de marcação, onde os pacotes de menor prioriodade terão maior chances de serem descartados. Dentro dessa características podemos chamar de ( minimum threshold, maximum threshold e mark probability denominator).

\
**CBWRED =**Mesma funcionalidade do WRED, porém podemos utilizar baseado por classe.

Como demos uma prévia sobre o conceito segue os comandos que podemos utilizar para fazer esse tipo de configuração.

Router(config-if)# class-map c1
Router(config-cmap)# match access-group 101
Router(config-if)# policy-map p1
Router(config-pmap)# class c1
Router(config-pmap-c)# bandwidth 48
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 8 24 40
Router(config-if)# service-policy output p1

Espero que vocês tenham gostado e aguardo comentários. 😛

Fonte:
Cisco Page – WRED
Cisco Page – Avoidance