Categoria: IOS

Testando a comunicação com Radius/Tacacs Server

A partir da CLI – Command Line Interface, de roteadore, switches e access-points Cisco, podemos testar a comunicação com o servidor Radius e/ou Tacacs.

Esta funcionalidade nos permite verificar o status do servidor antes de aplicarmos a configuração de aaa, por exemplo.

Para isso basta, no modo de configuração privilegiado, e com o servidor já cadastrado, usar o comando test aaa group.

Testando a autenticação de dentro de um roteador

BrainGW01#
BrainGW01#test aaa group tacacs+ admin cisco123 new-code
Sending password
User successfully authenticated

USER ATTRIBUTES

username             "admin"
reply-message        "Password: "
BrainGW01#

Se usarmos um usuário com a senha errada veremos a resposta abaixo.

BrainGW01#
BrainGW01#test aaa group tacacs+ admin cisco1 new-code
Sending password
User rejected

BrainGW01#

Esta funcionalidade foi introduzida na versão 12.2(28)SB, e a partir da versão 12.2(4)T recebeu algumas melhorias, como a possibilidade de criar um profile para associar ao teste.

Mais informações neste link.

Até a próxima.

Hora certa nos logs

Por , 03/11/2011 15:42

Sempre é bom deixar os equipamentos configurados para gerar logs. Isso facilita muito na hora do throubleshooting. Mas também é importante que os logs sejam gerados com o horário correto.

Para isso, primeiro precisamos configurar o clock do equipamento. Você pode usar um NTP ou configurar o horário localmente.

Configurando o horário localmente em um switch Cisco 2960

BrainSW01#clock set 16:15:00 3 nov 2011
BrainSW01#conf t
BrainSW01(config)#clock timezone GMT -3
BrainSW01(config)#end
BrainSW01#

Com esta configuração o equipamento utilizará o horário local (atenção para o horário de verão, nesta época temos que alterar para GMT -2).

Você pode verificar se o horário está correto com o comando show clock.

Com o horário certo, basta configurar o timestamps do log para que seja utilizado o horário local. Por padrão esta funcionalidade vem desabilitada.

Configurando o timestamps

BrainSW01#conf t
BrainSW01(config)#service timestamps log datetime localtime

Com esta configuração os logs serão gerados e marcados com o horário do equipamento.

teste#conf t
teste(config)#hostname BrainSW01
BrainSW01(config)#end
BrainSW01#
.Nov  3 16:24:17: %SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.10.10.3)
BrainSW01#

Os mesmos comandos são utilizados para configurar o horário nos logs de roteadores.

Mais informações sobre System Message Logging neste link.

Até a próxima.

Multicast sobre GRE

O GRE é sem dúvida um protocolo de muita utilidade. Com ele podemos criar túneis (já falamos disso aqui) onde o tráfego é encapsulado.

Este encapsulamento resolve muitos problemas, pois podemos “dar um bypass” em redes que não permitem o tráfego de alguns protocolos.

Imagine um ambiente onde matriz e filais estão conectadas através de uma MPLS/Frame que não permite o tráfego de multicast. Eis que a matriz resolve divulgar vídeos institucionais para todas as localidades via multcast.

O GRE pode resolver este problema, e este documento mostra um passo-a-passo para isto.

gre_multicast

Basicamente precisamos habilitar o roteamento multicast, criar o túnel e configurar as rotas.

Configuração para RT01, roteador próximo ao Multicast Source.

ip multicast routing
ip pim bidir-enable

interface loopback 0
description IP de Origem do GRE
ip add 2.2.2.1 255.255.255.255

interface tunnel0
description GRE
ip address 192.168.1.1 255.255.255.252
tunnel source loopback0
tunnel destination 4.4.4.1
ip pim sparse-dense-mode

interface f0/0
description LAN
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode

ip route 0.0.0.0 0.0.0.0 200.0.0.1
ip route 10.2.2.0 255.255.255.0 192.168.1.2
ip route 4.4.4.1 255.255.255.255 192.168.1.2

Configuração para RT02, roteador próximo ao Multicast Receiver.

ip multicast routing
ip pim bidir-enable

interface loopback 0
description IP de Origem do GRE
ip add 4.4.4.1 255.255.255.255

interface tunnel0
description GRE
ip address 192.168.1.2 255.255.255.252
tunnel source loopback0
tunnel destination 2.2.2.1
ip pim sparse-dense-mode

interface f0/0
description LAN
ip address 10.2.2.1 255.255.255.0
ip pim sparse-dense-mode

ip route 0.0.0.0 0.0.0.0 189.0.0.1
ip route 10.1.1.0 255.255.255.0 192.168.1.1
ip route 2.2.2.1 255.255.255.255 192.168.1.1

ip mroute 10.1.1.0 255.255.255.0 tunnel0
ip mroute 2.2.2.1 255.255.255.255 tunnel0

Observe no exemplo acima que não há nenhuma configuração específica na interface WAN, e para o endereço multicast que o Multicast Source usará.

Até a próxima.

Servidor radius no roteador

Por , 17/10/2011 14:56

Você sabia que é possível criar um servidor radius em um roteador? Os IOSs mais novos, a partir da versão 12.3(11)T, possuem esta funcionalidade.

Claro que não recomendo a utilização do roteador como um servidor para autenticação em larga escala, mas é um funcionalidade legal, que pode ajudar nos nossos laboratórios.

E a configuração é bem simples.

Radius Server Local

Client (R2): A configuração do radius client é a mesma de quando usamos um servidor radius normal (ACS, IAS, FreeRadius…).

! Habilite o aaa
aaa new-model
! Configure para a autenticação usar Radius
aaa authentication login TESTE group radius
! Especifique o IP e key do servidor Radius (R1)
radius-server host 10.123.45.1 auth-port 1812 acct-port 1646 key cisco
! Na line configure o método de autenticação criado
line vty 0 4
login authentication TESTE

Server (R1): No roteador que será o Radius Server basta habilitar o serviço, cadastrar o NAS, sua chave e um usuário e senha.

! Habilite o radius-server no roteador
radius-server local
! Cadastre o ip do Radius Client e a senha
nas 10.123.45.79 key 0 cisco
! Crie um usuário e senha para acesso ao roteador R2 (client)
user teste password teste

Pronto! Basta dar um telnet no R2, informar o usuário e senha (teste/teste) criados no R1 e acessar o equipamento.

Até a próxima.

Carregando o IOS de um servidor TFTP

Normalmente o software (IOS) dos roteadores Cisco ficam armazenados na memória flash. Mas em alguns casos pode ser necessário ou recomendado, deixar o IOS em um TFTP Server.

Armazenando o software em um servidor TFTP você ganha espaço na flash, e garante que em caso de falha desta memória, o equipamento ainda consiga iniciar normalmente. Quando você tem vários equipamentos, também pode garantir que todos vão utilizar o mesmo software.

Por outro lado, uma desvantagem de armazenar o IOS no TFTP, é o tempo que o equipamento levará para inicializar. Como ele terá que fazer o download, o tempo será maior.

Para não ter problemas,  você precisa garantir que o TFTP vai estar funcionando e acessível a partir dos roteadores, quando eles forem inicializar.

O processo o boot

Antes de vermos a configuração para utilizar um IOS a partir do servidor TFTP, vamos entender o processo de boot do roteador.

1) Imediatamente após ser ligado o roteador verifica como o hardware está. Para isso ele realiza o POST – Power On Self Test, que fica armazenado na ROM;

2) Depois roda o bootstrap, software também armazenado na ROM. O bootstrap é o responsável por procurar e carregar o IOS, que pode estar na própria ROM (pode ser uma versão limitada), na flash ou em um TFTP Server. Para isso ele verifica o “Configuration Register Value”, na NVRAM;

3) O IOS é carregado e procura por um arquivo de configuração válido, armazenado na NVRAM (startup-config), ou também no TFTP. Se encontrar, o arquivo é carregado para a DRAM como running-config. Se não encontrar o roteador inicia “zerado”.

Configurando o roteador para usar o TFTP Server

Considerando que o roteador não possui um IOS na flash, vamos entrar em modo rommon e configurar as variáveis para que ele possa encontrar o IOS no TFTP.

IOS_TFTP

Ligue o roteador e quando ele começar a bootar pressione ctrl+break, para entrar no modo rommon

! Definina o IP do roteador (interface F0/0, por padrão)

rommon 1 > IP_ADDRESS=192.168.1.1

! Máscara da interface

rommon 2> IP_SUBNET_MASK=255.255.255.0

! Default-gateway para o roteador

rommon 3 > DEFAULT_GATEWAY=192.168.1.30

! Informe o IP do TFTP Server

rommon 4 > TFTP_SERVER=192.168.1.30

! Coloque o nome do IOS

rommon 5 > TFTP_FILE=c2801-advsecurityk9-mz.124-21.bin

! Reinicie o roteador 

rommon 6> tftpdnld –r

Observações sobre o ROMMON:

  • O –r faz com que o roteador carregue o IOS, mas não salve ele na flash;
  • É possível mudar a interface padrão com o comando FE_PORT=1;
  • O gateway só será usado se o TFTP Server estiver em outra rede, mas é obrigatória sua configuração (DEFAULT_GATEWAY), mesmo se estiver se estiver na mesma rede;
  • Para verificar se a configuração está correta correta basta digitar o comando set.

Depois que o roteador inicializar, no modo de configuração global, utilize o comando boot system para especificar o local onde está o IOS.

Definindo de onde o IOS deve ser carregado

boot system tftp://192.168.1.30/c2801-advsecurityk9-mz.124-21.bin

Até a próxima.

Tema Brainwork 0.2(beta)