Seja o primeiro a comentar

Por André Ortega, 26/01/2012 14:12

Os switches são equipamentos inteligentes, e que possuem grande capacidade de encaminhamento de frames. Para isso duas tabelas são usadas: CAM e TCAM.

Quando os frames chegam em uma interface de um switch, eles são colocados na fila de entrada (ingress queue) desta porta. Depois, quando o switch decide por qual porta este frame deverá ser enviado, ele é colocado na fila de saída (egress queue), da porta escolhida.

Se o switch não conhecer o MAC address de destino, o frame é enviado para a fila de saída de todas as portas (menos aquela por onde o frame foi recebido), e então é feito o flooding.

As duas tabelas são usadas para escolher por onde o frame deverá ser enviado, se poderá ser enviado e como.

CAM – Content Addressable Memory: A tabela CAM, também chamada de MAC Address Table ou Layer 2 Fowarding Table, armazena os MAC address aprendidos pelo switch. O switch usa a informação do campo MAC Address Source dos frames que recebe, para preencher esta tabela.

Por padrão, um MAC aprendido dinamicamente fica na tabela CAM por 300 segundos após a uma atividade registrada. Este tempo é conhecido como aging timer, e podemos alterá-lo. Também é possível criar uma entrada estática.

Criando uma entrada estática na tabela CAM

BrainSW05(config)# mac address-table static 0012.1122.3355 vlan 10 interface fa0/5

Aumentando o Aging timer para 400 segundos, na VLAN 10

BrainSW05(config)# mac address-table aging-time 400 vlan 10

Apagando da Tabela CAM um MAC aprendido dinamicamente

BrainSW05(config)# clear mac address-table dynamic 0012.da8e.c496

A tabela CAM fica armazenada na memória RAM, o que torna sua consulta rápida.

É importante lembrar que a tabela CAM é finita, e se não houver espaço para cadastrar os novos MAC dos frames que o switch recebe, ele passará a fazer o floding sempre que chegar um frame destinado ao endereço MAC não gravado.

Use o comando show mac address-table count para ver quanto espaço ainda tem na Tabela CAM.

TCAM – Ternary Content Addressable Memory: A tabela TCAM é usada para armazenar access-lists baseadas em MAC Address e access-lists usadas na configuração de QoS. Em switches camada 3, access-lists baseadas em endereços IPs e portas também ficam na TCAM.

Assim como a CAM, a TCAM fica armazenada na memória RAM, porém ela é mais complexa, e um switch pode ter mais de uma TCAM (uma para o tráfego que entra, outra para o tráfego que sai, outra para QoS,…).

Ela conta com os campos Valor, Máscara e Resultado, não pode ser configurada, mas em alguns switches podemos especificar o tamanho que ela terá, otimizando-a para uma funcionalidade específica.

Mudando o tamanho / otimizando a TCAM

BrainSW05(config)#sdm prefer ?
  default                    Default bias
  dual-ipv4-and-ipv6  Support both IPv4 and IPv6
  lanbase-routing      Lanbase routing
  qos                        QoS bias

Até a próxima.

Seja o primeiro a comentar

Por André Ortega, 17/11/2011 12:53

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.

(2) Comentários

Por André Ortega, 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.

Seja o primeiro a comentar

Por André Ortega, 25/10/2011 16:24

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.

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.

(2) Comentários

Por André Ortega, 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.

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.