03/07/2018

XenServer - Multiplas Vlans por Interface

     Em alguns casos o número de Vlans utilizadas pode ser maior do que a quantidade de interfaces de rede disponíveis, tanto por razões de capacidade física como definições de utilização das NICs existentes.
     Para auxiliar em casos como este, é possível realizar a criação de interfaces virtuais adicionais, ligadas a uma interface física, onde cada uma das novas interfaces atende a demanda de uma Vlan em específico.
     No entanto, como requisito adicional para esta configuração, são necessárias também configurações na porta do switch com a qual a NIC está conectada, a qual deve estar configurada como tronco, ou trunk
     Embora este requisito seja uma coniguração simples e bem similar, ela pode váriar de acordo com o equipamento utilizado e dessa forma não pode ser abordada na sua totalidade

Configuração do XenServer

Passo 1: Acessar a aba Networking do servidor que se deseja configurar, e clicar em Add Network.

Passo 2: Na janela seguinte, manter selecionada a opção External Network;


Passo 3: Definir um nome para a interface;

Passo 4: Selecionar a interface física a qual a interface virtual está relacionada e definir a Vlan correspondente;


Passo 5: Conferir se a aplicação foi realizada.

19/06/2018

XenServer - Arquivos de log

     Provavelmente não seja nenhuma novidade falar que os logs do XenServer são armazenados no diretório /var/logs, pois é onde realmente se espera encontra lós.
     No entanto, o que diferencia são os aquivos presentes neste diretório e a sua finalidade. Em um sistema operacional linux os logs seriam encontrados em /var/logs alguns arquivos como:
  • auth.log:armazena logs de autenticação;
  • boot.log: informações relacionadas à inicialização;
  • cron: armazena todas as mensagens relacionadas a Crond (tarefas cron) ;
  • daemon: registros pertinentes aos daemons em execução no servidor; 
  • dmesg: mensagens relacionadas aos drivers de dispositivo;
  • faillog: contém informações sobre todas as tentativas de login falhas;
  • mail.log: armazena todos os logs relacionados aos servidores de e-mail
  • kern.log: armazena logs do Kernel e dados de aviso.
  • syslog: mensagens gerais;
    Já no XenServer, alguns desdes diretórios não estão presentes, ao mesmo passo que outros arquivos não encontrados em servidores linux, são exibidos no XenServer. Dentre eles os principais são:
  • audit.log:  informações detalhadas sobre as RBCA-roles (role-based access control) ou controle de acesso baseado em funções;
  • installer: diretório com registros do processo de instalação;
  • secure: registro das conexões realizadas ao XenServer, variando entre XenCenter e acessos via ssh;
  • SMLog: arquivo com registros das ações relacionadas ao armazenamento, tais como montagem, conexões e verificações do status das conexões; 
  • xensource.log: arquivo  com o registros dos eventos realizados pelo conjunto de ferramentas utilizado para gerenciamento do XenServer, denominado XAPI. Devido ao seu nível de detalhamento é um pouco mais complicado de ser analisado.
      Outros destinos dos logs também poder ser observados na imagens abaixo, que lista o conteúdo do diretório /var/log.

Referências 

24/05/2018

Switch virtual interface (SVI)

     Geralmente, switches gerenciáveis permitem a criação de interfaces virtuais criadas no software para fornecer um meio de acesso via rede usando IPv4/6, denominadas de SVI, as quais se comportam como interfaces físicas, possindo inclusive um endereço MAC.
     Em geral, cada switch é fornecido com um SVI padrão definida como interface vlan 1, sendo necessário realizar a configuração de rede para permitir acesso remoto.

Configuração SVI

     A sequência de comandos a seguir foi executa da em um switch Catalyst da Cisco e habilita administrativamente e atribui um endereço IP a interface Vlan 1, tornando possível assim o acesso via rede
switch(config)#interface vlan 1
switch(config-if)#ip address 192.168.1.10 255.255.254.0
switch(config-if)#no shutdown
%LINK-5-CHANGED: Interface Vlan1, changed state to up
switch(config-if)#
     Assim como aplicada a Vlan 1, interfaces virtuais podem ser criadas para outras Vlans que estejam presentes no equipamento, sendo necessário também a criação da Vlan, pois a criação da interface para uma Vlan não existente não realiza a criação da Vlan de forma automática.
     Essas configurações permitem que o equipamento seja encontrado na rede através de um endereço IP, sendo necessário configurações adicionais para que seja realizado um acesso remoto, tal como a definição do gateway, configurações de uplink entre switches, configurações de Vlan entre outros. 
   

Teste de configuração

     Dentre os vários testes que podem ser realizados para verificar o funcionamento da configuração aplicada, um deles que não necessita de gateway, por estar na mesma rede, consiste em:
  1. configurar um computador na mesma rede
  2. conectar em uma porta do switch que esteja em modo access e na vlan 1
    • OBS: caso tenha configurado a interface virtual em outra Vlan, a porta access deve estar na Vlan na qual foi configurado o IP.
  3. utilizar o comando ping para testar.

Referências

  • https://www.grandmetric.com/knowledge-base/design_and_configure/how-to-create-svi-interface-cisco/ 
  • https://www.ppgia.pucpr.br/~jamhour/Download/pub/RSS/old/VLANs.pdf

02/05/2018

XenServer - Adicionando template do Ubuntu 18.04 LTS

     Um template é um modelo partir do qual se pode provisionar rapidamente uma nova VM. Mais detalhadamente, consiste em um arquivo com todas as informações de uma VM, tais como CPU, memória, tamanho do disco e recursos de rede. Em outras palavras, um template consiste em uma VM encapsulada com todas as suas informações.
      O Xen já disponibiliza templantes a serem escolhidos no momento da criação de uma nova VMs, os quais, além de conterem as definições básicas, auxiliam na definição de como ocorrerá a virtualização, se totalmente virtualizado o se paravirtualizada, dentre outros. Ademais, eles também não contam com sistema operacional instalado. 
     Já os templates criados a partir de VMs configuradas, possuem a vantagem de serem totalmente configurados, de acordo com quem realizou a preparação da sua VM de origem.
     Este post aborda o primeiro tipo de template, que é necessário ser criado geralmente quando ocorrem lançamento de novas versões de SOs que somente serão incluídas nas próximas versões do XenServer, tal como o Ubuntu Server 18.04 LTS, no XenServer 7.2.

Passo a passo:

1. Obter o UUID do template da versão anterior.
UUID=`xe template-list name-label="Ubuntu Xenial Xerus 16.04" params=uuid --minimal`
2. Clonar o template da versão anterior para um novo template, já com o nome da nova versão
NEW_UUID=`xe vm-clone uuid=$UUID new-name-label="Ubuntu Bionic Beaver 18.04"`
3. Setar como um template default
xe template-param-set uuid=$NEW_UUID other-config:default_template=true

Referências

  • https://tecadmin.net/add-ubuntu-16-04-lts-template-on-xenserver/ 
  • https://www.techhapa.com/2016/08/adding-ubuntu-1604-lts-template-in.html
  • http://ports.marllus.com/2016/02/17/entendendo-templates-xenserver-6-5/

24/04/2018

XenServer - Níveis de usuáros


     O XS (XenServer) apresenta por padrão cinco (5) Roles (níveis de usuários), denominados Pool Admin, Pool Operator, VM Power Admin, VM Admin, VM Operator ou Read-Only.  Estas roles são, com um conjunto de permissões que possibilitam garantir acesso total ou restringir  acessos mais específicos a cada usuário, conforme descrito a seguir.

  • Pool Admin: maior nível de acesso, permitindo controle total a todas as funções e configurações do XS, incluindo o acesso a console do host, tendo permissão para executar comandos como root.
  • Pool Operators: permite a execução de ações no nível do pool, como configurações de storage, gerenciamento de patches e a criação de resource pool. Também permite a configuração de Hight Availability, Workload Balancing, não tendo acesso a ações como inclusão de usuários e acesso console.
  • VM Power Admin: os usuários pertencentes a esta role tem permissão para gerenciar máquinas virtuais, templates, snapshots, recurso de Dynamic Memory Control e definição de Home Server.
  • VM Admin: permite o gerenciamento de VMs e templates sem acesso ao Dynamic Memory, snapshots e definição do Home Server.
  • VM Operators: possuem permissão para gerenciar uma VM em questão, realizando algumas atividades básicas, não sendo possível alterar as propriedades daPolls máquinas virtuais, como memória e CPU.
  • Read-Only: grupos associados a essa role terão acesso total somente leitura, não sendo permitido nenhuma modificação em todo o ambiente.
     É importante ressaltar que a inclusão de um usuário em uma role, permite que ele execute as funcionalidades a partir do XenCenter, sendo necessário a existência de um usuário na VM para que seja realizado o acesso ao SO.

Referências

  • https://docs.citrix.com/en-us/xencenter/6-5/xs-xc-users/xs-xc-rbac-roles.html
  • https://www.safaribooksonline.com/library/view/citrix-xenserver-60/9781849686167/ch02s04.html
  • https://www.packtpub.com/mapt/book/virtualization_and_cloud/9781849686167/2/ch02lvl1sec20/roles-and-permissions
  • https://cleristononline.wordpress.com/2015/02/19/testando-os-niveis-de-acesso/

18/04/2018

Mensagens de Log nos switches CISCO

     Os registros de logs podem ser usados para notificação de falhas, análise forense e auditoria de segurança. As mensagens de logs dos equipamentos Cisco podem ser tratadas de 5 maneiras diferentes, gerando registros de log:
  • do terminal: similar ao do console, mas mostra mensagens de log nas linhas VTY. Não é habilitado por padrão.
  • de console:  por padrão, todas as mensagens de log são enviadas para sua porta console. Portanto somente os usuários que estão fisicamente conectados à porta console pode ver essas mensagens.
  • de buffer: tipo de log que usa a memoria RAM para o armazenamento das mensagens de log. O buffer tem um limite fixo para garantir que o log não irá esgotar memória valiosa do sistema, deletando mensagens antigas do buffer assim como novas mensagens vão entrando.
  • do servidor Syslog: as mensagens de log podem ser encaminhadas para um servidor externo para o armazenamento.
  • de trap SNMP: mensagens de log podem ser enviadas para servidores SNMP através da configuração de traps.

Níveis de informação

     O tratamento das mensagens de log é realizado através da definição do nível de informação das mensagens, sendo dividida em 7 níveis, onde a definição de um nível faz com que todas as mensagens dos níveis inferiores sejam também enviadas.

Formatação dos logs

     O formato dos logs pode variar de acordo com o modelo do equipamento, mas nos switches da linha Catalyst 2960, são exibidos conforme exemplo:

     Alguns exemplos de configuração para registro de logs que poderiam ser aplicados são:
  • logging on: habilita o log para todos os destinos;
  • logging console 3: define o nível de informação das mensagens exibidas quando realizado acesso via console, fazendo com que sejam exibidas somente mensagens de status de erro ou de maior importância;
  • logging trap 7: define o nível de informação das mensagens armazenadas no buffer e enviadas para algum servidor Syslog, caso exista.
  • logging buffered 100000: definir o tamanho do buffer de log para ser armazenado no switch. O nível dos logs é definido com o parâmetro trap;
  • service sequence-numbers: habilita números sequenciais nos logs;  
  • service timestamps log datetime localtime: define o horário do log para o mesmo horário do equipamento, que por sua vez já foi configurado para ser sincronizado via NTP; 
  • show logging: não é uma configuração mas serve para exibe o buffer local com os eventos de log;
     A aplicação em um switch é meramente a transposição dos comandos em negrito para o console
switch(config)# logging on
switch(config)# logging console 3
switch(config)# logging trap 7
switch(config)# logging buffered 100000
switch(config)# service sequence-numbers
switch(config)# service timestamps log datetime localtime
switch(config)# end
switch# show logging
    Uma configuração de log adicional por ser obtida com o comando archive que habilita o log das alterações realizadas pela linha de comando, salvando informações da sessão, tais como login e comando realizado.
switch(config)# archive
switch(config-archive)# log config
switch(config-archive-log-cfg)# logging enable
switch(config-archive-log-cfg)# logging size 500
switch(config-archive-log-cfg)# end
switch#
     O comando show archive log config all é utilizado para exibir os logs das alterações realizadas, informando mais especificamente os comandos executados, os usuários e a linha de console utilizada para tal.
switch# show archive log config all
idx   sess           user@line      logged command
    1    20          admin@console  |logging on
    2    20          admin@console  |logging console 3
    3    20          admin@console  |logging trap 7
    4    20          admin@console  |logging buffered 100000
    5    20          admin@console  |service sequence-numbers
    6    20          admin@console  |service timestamps log datetime localtime
    7    20          admin@console  |archive
    8    20          admin@console  | log config
    9    20          admin@console  |  logging enable
   10    20          admin@console  |  logging size 500
switch#

Referências

11/04/2018

Contas de usuários em switches gerenciáveis

     A autenticação em dispositivos Cisco, assim como nos demais sistemas operacionais e determinadas aplicações, pode ser realizada através de uma consulta a base de usuários locais ou a uma base de usuários remota, através do protocolos AAA (Autenticação, Autorização e Auditoria), RADIUS e TACACS (Terminal Access Controller Access-Control System). 
     Embora a utilização de uma base de dados centralizada seja mais indicada, também consiste em um recurso mais complexo e não elimina a necessidade de usuários locais, cujas configurações e detalhes são descritos a seguir.
     Usuários locais podem ser criados com o comando username e as palavras chaves desejadas, tais como:
  • privilege [1-15]: define o nível de privilégios do usuário criado
  • passwd: define uma senha em texto puro
  • secret: define uma senha criptografada, não podendo ser utilizado em conjunto com a opção passwd
     A criação do usuário admin exemplificada a seguir, define o nível de privilégio 15 para o usuário, com uma senha em texto puro, ou seja, caso as configurações sejam visualizadas, a senha será exibida no console.
switch(config): username admin privilege 15 passwd senhateste
     Uma das alternativas para criptografar as senhas em texto puro é habilitar a criptografia de senhas com o comando service seguido da palavra chave encryption-password, que criptografa todas as senhas criadas em texto puro.
switch(config): secret encryption-passwd
     Diferentemente da maioria dos comandos, a execução do no service encryption-passwd não não retira a criptografia das senhas. 
     Uma segunda opção, que pode ser utilizada em conjunto com a anterior, consiste em criar um usuário com a opção secret. a qual criptografa a senha digitada.

Complementos

     A criação de um usuário por si só não garante a segurança no acesso ao sistema, sendo necessário configurações adicionais, definindo os tipos de acesso nas linhas vty e console. Para utilizar o usuário local, é necessário acessar as linhas vty e definir a utilização da base de dados local para autorização de acesso.
switch(config-line)# line console 0
switch(config-line)# login local
switch(config-line)# line vty 0 15
switch(config-line)# login local
switch(config-line)#
     Uma configuração adicional que possibilita maior segurança no acesso aos equipamentos é a definição de uma senha para acesso ao nivel EXEC, definida com o comando  enable secret/passwd [senha] que exige a inclusão da senha para habilitar o modo exec usuário, sendo que a definição de senhas em texto puro e criptografadas segue a mesma lógica já explicada.
switch(config-line)# enable passwd senhaTextoPuro
..........
switch(config-line)# enable secret senhaSeraCriptografada

09/04/2018

Comandos Gerais para gerenciamento de switches

1. hostname: comando utilizado para alterar o nome do dispositivo, que por padrão é definido como switch. Ex:
switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# hostname filial01_sw111filial01_sw111(config)#
filial01_sw111(config)# no hostname
switch(config)#
2. ip domain-name: domain-name é uma das palavras-chave disponíveis para o comando ip, a qual define um nome de domínio padrão que o IOS Cisco utilizará para completar nomes de host não qualificados (nomes sem um domínio), sendo também necessário para habilitar a criação de chave rsa, que por sua vez permite a configuração do acesso ssh.
switch# crypto key generate rsa
% Please define a domain-name first.
switch# ip domain-name inst.unipampa.edu.br
switch(config)#
3. ip name-server: name-server é a palavra chave utilizada pelo comando ip para definir o servidor DNS do dispositivos, sendo permitidos até um máximo de seis endereços. Podem ser adicionados individualmente ou todos em uma mesma linha, mas no momento de verificar a configuração eles são exibidos um abaixo do outro.
switch(config)# ip name-server 8.8.8.8 4.4.4.4
switch(config)# end
…………..
switch(config)# ip name-server 10.18.0.3
switch(config)# ip name-server 10.12.0.3

4. ip domain-lookup: quando o domain-lookup está habilitado o equipamento tenta resolver qualquer texto que não seja comando para um IP, bloqueando o acesso por alguns segundos. Para desativar esta resolução basta negar o comando, executando no ip domain-lookup.
switch(config)# no ip domain-lookup
5. ntp: comando utilizado para definir o servidor a ser utilizado para sincronização de data e hora nos eventos onde seja necessário, podendo ser atribuído o endereço IP ou a url, desde que a resolução de nomes esteja configurada.
switch(config)# ntp server 10.18.0.3 prefer
6. clock: comando utilizado para definir o fuso horário com o parâmetro timezone  e também o horário de verão, com o parâmetro summer-time;
switch# sh clock14:50:33.617 UTC Wed Aug 10 2016
switch# conf t
switch(config)#clock timezone BR -3 0
switchconfig)#clock summer-time BRV recurring 3 Sun Oct 0:00 3 Sun Feb 0:00
O summer-time foi criado com o nome BRV de forma recorrente (recurring), iniciando no terceiro (3) Domingo (Sun) de Outubro (Oct) as 00:00h (0:00) e terminando no terceiro (3) domingo (Sun) de Fevereiro (Fev) as 00:00h (0:00).

7. snmp-server: comando utilizado em conjunto com outros parâmetros, para definir informações adicionais de monitoramento a serem repassadas.
switch(config)# snmp-server communit rede_empresa_abc RO
switch(config)# snmp-server location Predio 3 – Piso 2
switch(config)# snmp-server contact ti@empresaabc.com.br
8. Salvar alterações: os switches apresentam dois arquivos de configuração, o arquivo running-config, onde são armazenadas as configurações em execução, e o arquivo startup-config, onde são armazenadas as configurações de inicialização.
     Quaisquer modificações realizadas são salvas no running-config e podem ser perdidas se não forem salvas, pois ao reiniciar um switch, o mesmo carrega as informações existentes no startup-config.
     Os comandos abaixo permitem que as informações sejam salvas no arquivo de inicialização, com a diferença de que o segundo comando, embora mais sucinto, não exige confirmação.
switch#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
switch#wr
Building configuration...
[OK]
switch#
     O caminho contrário também pode ser realizado, copiando as configurações do arquivo de inicialização, para o arquivo em execução, restaurando assim as configurações originais da inicialização e removendo quaisquer configurações realizadas e não salvas, ressaltando que as configurações  entram em funcionamento no ato da execução do comando.

26/03/2018

Estrutura dos comandos nos switches CISCO

     O IOS utiliza uma estrutura padrão de comandos, além de várias formas de ajuda disponíveis, como ajuda contextual, verificação de sintaxe de comando e teclas de acesso e atalhos. As principais definições são: 
  1. Comandos:  
    • não são case sensitive, ou seja, não diferenciam maiúsculas de minúsculas; 
    • podem exigir um ou mais argumentos e um subconjunto de palavras-chave que fornecem funcionalidades adicionais; 
    • são executados somente em modos apropriados; 
    • a sintaxe do comando fornece o padrão ou o formato que deve ser usado ao inserir um comando. 
  2. Palavras-chave: 
    • descrevem parâmetros específicos de um comando; 
    • são pré-definidas; 
  3.  Argumentos: diferentemente de uma palavra-chave não são pré-definidos, podendo ser ips, urls, arquivos, etc. 
  4. Sintaxe geral: 
    • # <comando> <palavra(s)-chave> [argumento]
  5. Exemplo de comando:  show running-config
    •  show: comando usado para exibir informações sobre o dispositivo 
    • running-config: uma das palavras-chave que podem ser usadas para definir qual resultado específico deve ser exibido.

 Ajuda contextual (?)

     Fornece uma lista de comandos e os argumentos associados a esses comandos dentro do contexto do modo atual. Ex:
  • obter uma lista de comandos ou palavras chaves disponíveis no modo atual; 
  • verificar se o IOS suporta um comando qualquer em um modo específico;  
  • exibir uma lista de comandos ou palavras-chave nesse contexto, iniciadas com os caracteres inseridos; 
  • determinar quais opções, palavras-chave ou argumentos são correspondentes a um comando específico.

 Referências


22/03/2018

Interfaces físicas de um switche gerenciável

     As portas ou interfaces físicas dos switches possuem uma denominação que varia de acordo com as características de cada equipamento, em geral definindo em um formato TIPO[A]/B/C, onde TIPO é o tipo da porta, A e a identificação do switch (quando empilhável) , B módulo e C a porta do equipamento. Ex: 
  • FastEthernet0/1: porta 1, do tipo FastEhernet (100 Mbits/s), localizada no módulo 0 (zero); 
  • GigabitEthernet0/1: porta 1, do tipo GigabitEhernet (1000 Mbits/s), localizada no módulo 0 (zero);
    • as portas dos exemplos 1 e 2 possuem a mesma numeração, mas são de tipos diferentes; 
  • GigabitEthernet1/0/1: porta 1, do tipo GigabitEhernet (1000 Mbits/s), localizada no módulo 0 (zero) do switch 1. Situação mais comum encontrada nos modelos 2960 instalados atualmente; 
  • GigabitEthernet2/0/1: porta 1, do tipo GigabitEhernet (1000 Mbits/s), localizada no módulo 0 (zero) do switch 2. Nesse caso existem dois switches sendo utilizados como steck (pilha), acessíveis e gerenciáveis como sendo um só; 
  • GigabitEthernet1/1/1: porta 1, do tipo GigabitEhernet (1000 Mbits/s), localizada no módulo 1 (um) do switch 1. Porta existente em um módulo adicional inserido no switch, tal como os módulos para conexão de fibra, conforme mostrado na figura a seguir.

Referências

21/03/2018

Navegação entre os modos de operação em switches gerenciáveis

     De modo geral, o primeiro acesso ao um switch se dá no modo EXEC usuário e os comandos enable e disable são utilizados para alterar a CLI entre o modo EXEC usuário e o modo EXEC privilegiado, respectivamente. A figura  a seguir demonstra esses comandos, bem como outros acessos.
05_navegacao_niveis.png
Navegação entre os modos de operação de um switch cisco 2960.
  1. ao modo de configuração global, a partir do modo EXEC privilegiado, com o comando configure terminal;
  2. ao modo de configuração de interface, a partir do modo de configuração global, com o comando interface gigabitEthernet 1/0/1 (porta 1 do switch);
  3. o retorno ao modo anterior, com o comando exit, retornando do modo de configuração de interface, para o modo de configuração global;
  4. ao modo de configuração de linha, a partir do modo de configuração global, com o comando line console 0;
  5. o retorno ao modo EXEC privilegiado a partir de um módulo de configuração mais específico, com o comando end;
  6.  erro de acesso ao tentar acessar o modo de configuração de interface a partir do modo EXEC privilegiado.


20/03/2018

Modos de operação em switches gerenciaveis

     A navegação através da CLI, em switches e roteadores da Cisco, bem como em equipamentos de outros fabricantes, é baseada em uma estrutura hierárquica dos modos do IOS, onde cada modo possui um prompt distinto, utilizado para determinadas tarefas com um conjunto específico de comandos disponíveis somente para aquele modo. 
     Em uma ordem hierárquica dos mais básicos até os mais especializados, os principais modos são o de execução do usuário (EXEC usuário) e execução privilegiado (EXEC privilegiado) e os modos de configuração global e específica. 
  • Modo EXEC usuário: primeiro modo encontrado no acesso via CLI em um dispositivo. Por ser o nível mais básico da estrutura hierárquica, executa somente comandos básicos e permite acessar o modo EXEC privilegiado, não permitindo realizar configurações. Representação : switch>;
  • Modo EXEC privilegiado: também não realiza configurações, somente comandos de verificação, no entanto mais avançados. Permite passar para o modo de configuração global. Representação: switch#;
  • Modo de Configuração Global : também denominado de modo de configuração primário, permite alterar as configurações globais do dispositivo e acessar as configurações específicas. Seu acesso é realizado somente a partir do modo EXEC Privilegiado, com o comando configure terminal. Representação: switch(config)#;
  • Modos Específicos de Configuração: são acessíveis a partir do modo de configuração global e se destinam a realizar configurações específicas do dispositivo, tais como configurações das interfaces, VLANs, ACLs e etc. Dessa forma, o acesso a cada modo varia de acordo com a configuração a ser realizada.
     A figura a seguir demonstra a estrutura hierárquica descrita. 
 04_niveis_ios.png
 
     O comando exit pode ser utilizado para retornar sempre ao modo anterior e também para se deslogar do switch. O comando end, permite retornar diretamente ao modo EXEC privilegiado, a partir de qualquer modo de configuração, mas não possibilita se deslogar do dispositivo.

17/03/2018

Acesso console via windows em switches gerenciáveis

Requisitos

Para configurar o acesso via console a partir do SO Windows é necessário:
    • cabo padrão cisco RJ45 – SERIAL (RS 232) ou cabo USB - USB Mini ,o que for compatível com as entradas disponíveis computador a ser utilizado
    • emulador de terminal. Ex:Putty

    Conexão Console Serial

    Configurações para acesso serial.
    1. Estabeleça a conexão física entre o computador e o switch.

    2. Acesse o putty em ''Connection > Serial'', e execute as seguintes configurações:
      Serial line to connect to: COM1
      Speed: 9600
      Data bits: 8
      Stop bits:1
      Parity: None
      Flow control: Nome
    3. Retorne ao menu ''Section'', selecione a opção ''Serial'' e clique em ''Open''.

    4.  Será exibida a tela de conexão do putty, tecle ''Enter'' e informe os dados de acesso.

    5. Caso não tenha ocorrido nenhum erro na configuração, será exibido o console do switch.

    Conexão Console USB

    1. Faça o download dos drivers da Cisco para Windows na página da cisco.

    2. Instale os drivers conforme versão do sistema operacional e reinicie a máquina.

    3. Conecte os equipamentos com cabo USB<>USB Mini.

    3. No gerenciador de dispositivos verifique a porta COM atribuída a USB.
    Gerenciador de dispositivos e porta console atribuída.

    4. Configure o Putty para acesso via COM identificada no passo anterior.
    Configuração do putty com a porta console atribuida.

    Referências

    • http://labcisco.blogspot.com.br/2016/01/conexao-terminal-em-dispositivos-cisco.html
    • https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/10600-9.html
    • https://blog.joaoorvalho.com/utilizar-putty-terminal-para-configurar-routersswitch-cisco-windows/ 
    • https://software.cisco.com/download/home/282979305/type/282855122/release/3.1

    13/03/2018

    Acesso console via linux em switches gerenciáveis

    Requisitos

    Para configurar o acesso via console a partir do SO Linux é necessário:
    • cabo padrão cisco RJ45 – SERIAL (RS 232) ou cabo USB - USB Mini ,o que for compatível com as entradas disponíveis computador a ser utilizado
    • emulador de terminal. Ex: Minicom.

    Conexão console USB

    1. Estabeleça a conexão física entre o computador e o switch.

    2. Como usuário root, acessar as configurações do emulador com comando ''minicom -s''

    3. Acessar item: ''Configuração da porta serial'', utilizando as setas do teclado para navegação.

    4. Escolher opção ''A - Dispositivo serial'', pressionando  a tecla ''A'' e alterar para /dev/ttyUSB0 e pressionar ''Enter''. O dispositivo serial pode sofrer alterações no caminho e pode ser localizado com o uso do comando dmesg.

    5. Escolher opção ''E - BPS/Paridade/Bits'', pressionando a tecla ''E'' e na nova janela, escolher a opção ''C'' e pressionar ''Enter'', retornando ao menu anterior.


    6. Alterar para ''Não'', as opções ''F - Controle de Fluxo por Hardware'' e ''G - Controle de Fluxo por Software'', pressionando respectivamente as teclas ''F'' e ''G''.

    7. Pressionar ''Enter'' para retornar ao menu inicial e navegar até a opção ''Salvar configuração como dfl'' e pressionar ''Enter''.

    8. A opção ''Sair'' encerra a configuração e abre o emulador acessando o console. A opção ''Sair do Minicom'' retorna para o terminal.

    9. Após configurado, para acessar o dispositivo via console, basta executar o comando ''minicom'' como root.

    10. Para sair do minicom, pressionar CTRL+A+X;

    Conexão console Serial

    Difere da configuração anterior onde definir-se o dispositivo serial, que deve ser alterado em geral para "/dev/ttyACM0".

    Referências

    • http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/10600-9.html
    • http://labcisco.blogspot.com.br/2016/01/conexao-terminal-em-dispositivos-cisco.html

    10/03/2018

    Acesso a dispositivos de rede

         O acesso a dispositivos de rede pode ser em geral realizado via CLI (Command Line Interface) ou GUI (Graphical User Interface) sendo a utilização de um ou ambos os métodos de acesso uma característica que varia de acordo com o equipamento e fabricante.

    Gerenciamento via GUI

         O gerenciamento através de uma GUI pode em geral ser realizado através de uma interface web ou de ferramentas disponibilizadas pelo fabricante. A gerência via navegador é a forma mais frequentemente disponibilizada devido principalmente a sua facilidade de uso, independente de dispositivo. Ex: antenas para comunicação ponto a ponto (Nano), switches Cisco e D-Link.

    Gerenciamento via CLI

         O gerenciamento via CLI é realizado através de um console acessível de diversas formas, tais como telnet, SSH ou porta AUX, permitindo que seja acessível e realizável de qualquer SO, visto que os sistemas que não possuem um terminal nativo, podem se utilizar de emuladores de terminal tais como como Putty ou Tera Term.
    • Acesso via Console: realizado através das portas de gerenciamento fornece um canal dedicado e direto, indicado para fins de configuração inicial do dispositivo ou solução de problemas, permitindo que seja realizado acesso mesmo sem serviço de rede configurado. 
    • Telnet e SSH: são utilizados para acessar a CLI através de uma conexão remota via rede, sendo necessário a configuração de uma interface virtual no equipamentos.
    • AUX: é realizado via conexão dial-up de telefone com um modem conectado à porta auxiliar (AUX) de um roteador, ou seja, exige somente uma linha telefônica.
         A figuras a seguir demonstram as portas de acesso console de um roteador e alguns modelos de cabos utilizados para esse acesso:
    Exemplos de portas para acesso console
    Exemplos de cabos utilizados para acesso console

         As formas de configura o acesso console de acordo com o sistema operacional utilizados, são descritas em:

    28/02/2018

    Sistema operacional dos dispositivos de rede

         O Sistema Operacional em roteadores residenciais é geralmente chamado de firmware, nomenclatura também utilizada para SOs de rede ou IOS (Internetworking Operating System), cuja finalidade é fornecer uma interface para execução de comandos e administração de equipamentos, sendo que seus detalhes operacionais variam de acordo com o dispositivo.

    Tipos de memória 

         Antes de entender o funcionamento do IOS, é importante relembrar os tipos de memória existentes para entender sua aplicação na arquitetura do IOS.
    • ROM: read-only memory é um tipo somente leitura que após gravada não pode ser alterada. Geralmente vem integradas aos circuitos eletrônicos.
    • Flash: é uma memória não volátil, ou seja, que não perde seus dados quando o equipamento é desligada. Esse tipo de memória que pode ser eletricamente apagada e reprogramada com um programa específico.
    • NVRAM: Non-Volatile Random Access Memory é um tipo de memória que não perde seus dados mesmo sem a alimentação de energia e pode ser mais facilmente reescrita que a memória flash, mas também possui uma menor capacidade de armazenamento em geral.
    • DRAM: Dynamic random-access memory é uma memória volátil de alto desempenho e acesso rápido, podendo ser encontrada com diversas capacidades.

    Inicialização do dispositivo

         A figura a seguir demonstra uma arquitetura genéria do sistema operacional de um dispositivo de rede.
         De forma genérica, o funcionamento de um dispositivo de rede se incia com o carregamento do conteúdo armazenado na memória ROM, um conjunto de ferramentas de inicialização chamado de bootstrap, composto pelo bootloader (inicializador), o POST que realiza um diagnostico inicial do hardware e uma versão minimalista do sistema.
         Na sequência, a imagem comprimida do IOS que está armazenada na memória Flash, é carregada na memória DRAM para execução do sistema. Juntamente com a inicialização do sistema, o arquivo de configuração do equipamento, chamado de startup-config em alguns dispositivos, é copiado da NVRAM para a DRAM, onde é armazenado como arquivo de execução ou running-config.

    14/02/2018

    Tipos de switches de rede

         Os switches são dispositivos de rede que permitem a ampliação e comunicação entre equipamentos de rede, realizando a transmissão dos dados somente entre os equipamentos envolvidos.
         Este equipamentos pode ser classificados e divididos em duas principais categorias e posteriormente subdivididos em:
    1. Switch Modular ou Switch Ethernet de Configuração Modular
    2. Switch Fixo ou Switch Ethernet de Configuração Fixa
      • não gerenciável
      • gerenciável

     

    Switch Modular

         São equipamentos mais robustos utilizados em grandes centros para distribuição de rede ou em grandes Data Centers. Este tipo de dispositivo permite a inclusão de módulos adicionais não somente para expansão de portas mas também para aplicações específicas como firewall, analisadores de rede e melhorias de hardware como fontes de alimentação e bandejas de ventilação.
         Alguns exemplos são equipamentos da linha Catalyst 9600 e Nexus 7000 da Cisco ou da linha C9https://canofre.blogspot.com/2018/02/tipos-de-switches-de-rede.html000 da Dell.

    Switches modulares Catalyst 9600 e Dell C9000
    Switches modulares Catalyst 9600 e Dell C9000

     

    Switch Fixo

         São equipamentos que possuem um número fixo de portas e normalmente não permitem expansão, tais como equipamentos Cisco Catalyst 2960 series, Dell N1500 series. 
         Em alguns casos, estes switches podem ser confundidos com modulares devido a possibilidade inclusão de módulos de expansão para portas SFP - Small Form-factor Pluggable, ou uma fonte adicional, tal como os Catalyst 3750 da Cisco. 
         Neste caso são módulos específicos que podem ser adicionados a um equipamento específico o que vem a ser diferente das bandejas de expansão para switches modulares.
    Switches gerenciáveis Dell N1500 e Catalyst 2960
    Switches gerenciáveis Dell N1500 e Catalyst 2960

     

     a)Switches não gerenciáveis

         Estes equipamentos são os mais simples no quesito de utilização, basicamente são dispositivos plug and play, que permitem ampliar o número de conexões sem a possibilidade de uma gerência mais detalhada, como priorização de tráfego para voz ou segmentação de rede.
         São também os equipamentos mais atrativos financeiramente, justamente por serem menos robustos, o que leva a um menor custo de fabricação e utilização.
         No entanto, não quer dizer que sejam inferiores com relação a quantidade de equipamentos suportados, pois podem ser encontrados dispositivos não gerenciáveis com suporte a um tráfego maior do que dispositivos gerenciáveis, e a um custo menor também. A escolha por este equipamento vai depender da demanda a ser atendida e das características da rede.

     

    b)Switches gerenciáveis

         São equipamentos mais robustos que permitem uma série de configurações e opções para administração da rede, tais como:
    • Priorização de tráfego através de Quality of Service - QoS;
    • Monitoramento via Simple Network Management Protocol - SNMP;
    • Segmentação de redes virtuais (VLANs);
    • Protocolos de autenticação e atribuição dinâmica de VLANs (802.1x);
    • Registro de eventos possibilitando análise de logs em vários níveis;
         De forma adicional, outras funcionalidades e até mesmo variações na no abrangência das mesmas, podem ser encontradas entre os diversos modelos e fabricantes. Essa variação entre equipamentos com maior e menor robustez leva as vezes a uma terceira categoria intermediárias entre os gerenciáveis e os não gerenciáveis, denominada switches inteligentes, tal como os small bussines da Cisco.
         Do meu ponto de vista, os switches inteligentes, não deixam de ser gerenciáveis somente pelo fato de não suportarem a mesma quantidade de VLANs, ou não realizarem a atribuição dinâmica de VLANs nas portas, dentre outras variações, apenas possuem uma configuração menos robusta.
         Também é importante frisar que esta categoria de equipamentos (gerenciáveis e inteligentes) necessita de uma configuração prévia para entrar em funcionamento, a qual pode variar de acordo com o fabricante e/ou modelos de um mesmo fabricante.

     

    Switches L2 e L3

         A classificação L2 e L3 faz referência a camada de atuação do equipamento no modelo OSI - Open System Interconnection.
    • L2 - Layer 2 : Camada 2 - Enlace de dados
    • L3 - Layer 3 : Camada 3 - Rede
         Na camada 2 do modelo OSI, a comunicação ocorre pela identificação do endereço físico do dispositivo, o MAC - Media Access Control. Dessa forma, os equipamentos do tipo L2, se comunicam somente com base em endereços MAC, propagando a comunicação em broadcast para todas as redes lógicas nele conectadas, não permitindo o roteamento de redes ou sub-redes.
         Na camada 3, a comunicação ocorre pelo endereço lógico, e dessa forma, equipamentos do tipo L3 tem a capacidade identificar redes e sub-redes (endereço IP e máscara), interconectando-as e realizando o roteamento entre as mesmas.
          A camada de atuação do equipamento não está diretamente relacionada com a capacidade de gerenciamento ou não do dispositivo. Embora switches não gerenciáveis sejam sempre do tipo L2, equipamentos gerenciáveis pode ser do tipo L2 ou L3.

    Referências 

       

    06/02/2018

    Nomenclatura da linha Catalyst da CISCO

         A nomenclatura adotada nos switches da linha Catalyst, segue um padrão dividido em 4 partes distintas, separadas por um travessão (-), que definem:
    1. tipo de equipamento: sigla WS (Workgroup Switch) que define um switch. Alguns outros equipamento da Cisco também seguem essa nomenclatura, utilizando por exemplo: AP, para definir Access Ponit e CP para definir Telefones VoIP;
    2. linha, modelo e série: C2960X : linha Catalyst (C), modelo 2960, série X;
    3. especificações em geral, tais como: 
      • número de portas (12/24/48), excluindo-se as portas para uplink via fibra;
      • se o equipamento é POE (P) ou não POE (T) e para switches com mais de 24 portas, a potência fornecida, 740W(FP) ou 320W(LP)
      • a quantidade de portas SFP disponíveis, 4 SFP (S), 2 SFP+ (D), 4 SFP+ (Q), sendoSFP 1G e SFP+ 10G
    4. conjunto de características do IOS, que pode não estar presente, sendo divididos em Lan Base (L) e Lan Lite (S), diferindo em número máximo de VLANs ativas, velocidade de banda e encaminhamento de trafego.
    5. Exemplo
    nomenclatura_cisco_exemplo1.png

    Modelos

    nomenclatura_cisco_exemplo2.png 

    Referências

    • https://supportforums.cisco.com/t5/lan-switching-and-routing/cisco-model-naming-convention/td-p/1275158

    01/02/2018

    SSH - no matching key exchange method found

         Esse erro - alerta - aviso, é exibido devido a utilização de algoritmos de criptografia mais antigos em uso no servidor que se deseja conectar. O melhor mesmo seria corrigir essa situação no servidor, mas caso não seja possível, a configuração abaixo resolve o problema.
         Da página do projeto oficial do Open SSH, de onde está solução foi retirada, a tradução dada pelo google para o primeiro parágrafo que explica a situação, é a seguinte:

    OpenSSH implementa todos os algoritmos criptográficos necessários para compatibilidade com os padrões compatíveis de implementações SSH, mas uma vez que alguns dos algoritmos mais antigos tornaram-se fracos, nem todos eles são ativadas por padrão. Esta página descreve o que fazer quando o OpenSSH se recusa a conectar-se com algum servidor que suporta apenas algoritmos legados.

    Para corrigir esse "problema", é necessário incluir o endereço que utiliza um algoritmo mais antigo e também o algoritmo utilizado, no arquivo ~/.ssh/config, tal como o exemplo a seguir, onde cada par de linhas define servidor e algoritmo utilizado:
    # Usa o algoritmo +ssh-dss para o meuservidor.com.br
    Host meuservidor.com.br
          KeyAlgorithms +ssh-dss
    #
    # Usa o algoritmo +diffie-hellman-group1-sha1 para meuservidor2.com.br
    Host meuservidor2.com.br
         KexAlgorithms +diffie-hellman-group1-sha1
    #
    # Usa o algoritmo +diffie-hellman-group1-sha1 para toda rede 192.168.*.*
    Host 192.168.*.*
          KexAlgorithms +diffie-hellman-group1-sha1

    Referências

    • https://www.openssh.com/legacy.html
    • http://blog.ffelix.eti.br/ssh-no-matching-key-exchange-method-found-their-offer-diffie-hellman-group1-sha1/