Categoria: IOS

Renomeando policy-map e class-map

A Modular Policy Framework (MPF) é uma estrutura que cada vez mais vai ganhando espaço na configuração do IOS, e é utilizada entre outras, para configuração de QoS.

Ela é formada basicamente por class-maps e policy-maps.

Agora a parte interessante: é possível mudar o nome de um class-map ou de um policy-map sem ter que remover e inserir novamente os comandos.

Dentro do class-map e policy-map temos a opção rename, que permite trocar o nome e automaticamente mudar todas as referencias ele.

Exemplo: Mudando o nome do policy-map.

!Politica existente, chamada POLICY2
policy-map POLICY2
class CLASS_NOME
    police 64000

! Politica aplicada à interface F0/0

c2801-lab#sh run int f0/0

interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.0
ip nat outside
ip virtual-reassembly
  service-policy input POLICY2

! Mudando o nome para POLITICA1

c2801-lab#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
c2801-lab(config)#policy-map POLICY2
c2801-lab(config-pmap)#rename POLITICA1
c2801-lab(config-pmap)#end

! Verificando o policy-map com o nome alterado
c2801-lab#sh run policy-map
policy-map POLITICA1
class CLASS_NOME
    police 64000

c2801-lab#sh run int f0/0
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.0
ip nat outside
ip virtual-reassembly
  service-policy input POLITICA1
end

c2801-lab#

O mesmo se aplica ao class-map.

Até a próxima.

Compartilhe:
  • Print
  • Twitter
  • del.icio.us
  • Google Bookmarks
  • Live
  • email
  • RSS
  • Facebook
  • Technorati
  • MySpace
  • Digg
  • LinkedIn
  • MSN Reporter
  • Netvibes
  • Yahoo! Bookmarks
  • PDF

CiscoPedia – Guia de comandos Cisco

Por André Ortega, 07/07/2010 08:50

Navegando dia desses encontrei um programa em formato de arquivo de ajuda (.chm)com comandos do Cisco IOS. O CiscoPedia, como é chamado, trás uma grande quantidade de comandos, ilustrando a sintaxe, descrevendo os possíveis argumentos e até exemplos de configurações.

Acredito que muita gente já conheça, mas pra mim é novidade, apesar dele não ser novo. A versão 3.0, que foi a que encontrei, é de 2003.

O programa ele é da própria Cisco, com comandos utilizados no Networking Academy, segundo descrição da página inicial.

CiscoPedia

Pesquisei mais, mas não encontrei quase nada a respeito do Ciscopedia… Existe versão mais recente? Por que não atualizaram mais?

Apesar de estar desatualizado (já que é de 2003), gostei da idéia. É muito bom ter um guia de consultas rápidas.

Download do Ciscopedia aqui.

Até a próxima.

Compartilhe:
  • Print
  • Twitter
  • del.icio.us
  • Google Bookmarks
  • Live
  • email
  • RSS
  • Facebook
  • Technorati
  • MySpace
  • Digg
  • LinkedIn
  • MSN Reporter
  • Netvibes
  • Yahoo! Bookmarks
  • PDF

VLAN no Roteador – Router on a Stick

Com sabemos, para que hosts em redes diferentes se comuniquem é preciso um dispositivo layer 3, para fazer o roteamento. Assim podemos ter um roteador com uma interface em cada rede, como ilustrado abaixo, por exemplo.

Topologia comum

Porém nem sempre é viável dispor de duas interfaces de um roteador para este fim, já que interface é um recurso findável (e até custoso).

Para evitar este desperdício, com roteadores Cisco podemos usar uma topologia chamada Router on a Stick, com a utilização de apenas uma interface do roteador, e com a configuração de VLANs (sub-interfaces).

Neste caso temos a topologia como mostrado abaixo (e que é abordada no CCNA).

 Router on a Stick

A interface FastEthernet 0/0 foi dividida em duas sub-interfaces (F0/0.10 e F0/0.20), sendo que cada uma pertence a uma rede diferente (VLAN).

Na configuração do switch nenhuma novidade. As portas ondes estão os usuários e outros equipamentos devem ser configuradas como acesso. Já a porta onde está o roteador deve ser configurada como trunk.

conf t
! Crie as duas VLANs
vlan 10
  exit
vlan 20
  exit
! Configure a interface onde está o roteador como trunk
interface FastEthernet0/1
  switchport trunk encapsulation dot1q
  switchport mode trunk
  exit
! Coloque as interfaces de acesso nas respectivas VLANs
interface FastEthernet0/9
  switchport mode access
  switchport access vlan 20
  exit
interface FastEthernet0/10
  switchport mode access
  switchport access vlan 10
  exit
exit
copy run start

 

Já no roteador temos que criar as sub-interfaces e identificar as VLANs.

conf t
! Na interface física nenhuma configuração
interface fastethernet 0/0
  no ip address
! Crie a primeira sub-interface, coloque o IP e especifique a VLAN
interface FastEthernet 0/0.10
  ip address 192.168.10.1 255.255.255.0
  encapsulation dot1q 10
! Repita o processo para a segunda interface
interface FastEthernet 0/0.20
  ip address 192.168.20.1 255.255.255.0
  encapsulation dot1q 20

Com esta configuração, basta apontar as sub-interfaces como gateways das redes 192.168.10.0 e 192.168.20.0 para que haja comunicação entre elas.

Considerações:

  • Esta configuração é simples, útil e abordada no CCNA;
  • Cuidado para não inverter a sub-interface e o endereçamento IP na hora da configuração;
  • A identificação da sub-interface (0.0/10) e a identificação da VLAN (10) não tem nenhuma relação, mas normalmente mantém-se o mesmo número para facilitar;
  • A interface do roteador deve ser no mínimo FastEthernet, já que ela deve ser capaz de enviar e receber tráfego simultaneamente;

Até a próxima.

Compartilhe:
  • Print
  • Twitter
  • del.icio.us
  • Google Bookmarks
  • Live
  • email
  • RSS
  • Facebook
  • Technorati
  • MySpace
  • Digg
  • LinkedIn
  • MSN Reporter
  • Netvibes
  • Yahoo! Bookmarks
  • PDF

Políticas de controle de banda – Catalyst 3750

Por Rafael Leão, 27/05/2010 14:09

Este post traz uma configuração fácil de ser realizada em switches Cisco, para limitação de banda, em tráfego um switch Cisco Catalyst 3750, através de Policy-Maps.

Através de parâmetros configurados na Modular QoS CLI, selecionamos um determinado tráfego, e lhe aplicamos ações, baseadas nas políticas configuradas para ele. A limitação de banda pode ocorrer de duas formas: shaping ou policing.

Shaping vs. Policing

Antes de qualquer coisa, é importante sabermos a diferença entre estes dois métodos.

- Traffic Shapping retém pacotes que excedem a banda configurada para um buffer (queueing) e gradativamente vai os transmitindo, sem que o mesmo não sejam dropados; porém este buffer demanda de memória, e é sempre aplicada em sentido outbound.

- Traffic Policing propaga bursts (limites) quando o fluxo de pacotes atinge a banda máxima, no qual ações como dropar ou remarcar os pacotes é efetuada. Não há buffer, e a aplicação da política é em sentido inbound.

Mais informações aqui*. Agora, mão na massa!!!

* É necessário CCO para visualizar este documento.

Configurando Traffic Policing

Apenas 4 etapas são necessárias para alcançarmos nosso objetivo:

1. Habilitar QoS

Como esta configuração trata-se de parâmetros QoS, é necessário habilitar este recurso globalmente no switch:

mls qos

2. Classificar o tráfego

Definimos qual tráfego passará pelas políticas de banda. Primeiro criamos uma ACL:

access-list 111 permit ip any any

Depois definimos um class-map, ao qual a ACL será vinculada.

class-map match-all 8MB
match access-group 111

3. Criar o policy-map

O policy-map irá aplicar as políticas ao tráfego classificado anteriormente no class-map. O policy-map será nomeado Policy8MB.

policy-map Policy8MB

Agora entrando no modo de configuração de policy-map, iremos selecionar um class-map, e aplicaremos as respectivas ações. Neste caso, estaremos limitando a banda a 8Mbps o tráfego definido pelo class-map 8MB.

class 8MB
police 8000000 8192 exceed-action drop

Para entendermos melhor, os comandos acima, o parâmetro 8000000 significa a largura de banda medido em bits, e o ‘exceeded-action drop’, significa que os pacotes que ultrapassarem a banda de 8Mbps, serão simplesmente dropados.

4. Ativar a política

Por final, ativamos a política na interface, lembrando que é sempre ao tráfego inbound.

interface FastEthernet1/0/23
service-policy input Policy8MB

Está feito. Agora vou apresentar alguns testes que fiz, com as ferramentas Iperf – gerador de tráfego, NetMeter – medidor de banda de adaptador de rede, e o próprio MS-DOS.

Neste lab, temos duas máquinas windows conectadas a um switch 3750, em portas FastEthernet, somente com as configurações acima aplicadas. O host 10.1.0.11 está conectado à interface Fa1/0/23, e o 10.1.0.12, à Fa1/0/24.

Observe na primeira imagem, o output feito no Iperf do lado client.

 

Talvez para aqueles que não estão familiarizados com essa ferramenta, fique um pouco confusa a interpretação dos logs acima… mas eu vou tentar deixar o mais claro possível!

No primeiro comando, o Iperf client (10.1.0.11) está configurado para gerar 200Mbps de tráfego para o servidor 10.1.0.12. Como pode-se ver no output acima, a ferramenta consegue gerar 68,1 Mbps, sendo a taxa de transmissão REAL entre os dois foi de 64,4 Mbps.

Após isto, foram aplicados os comandos no switch, e o mesmo teste foi feito entre os dois. O client conseguiu novamente produzir 68,1Mbps, porém, a taxa real entre os dois foi de 6,7Mbps, segundo o reporte do servidor.

Com tráfego normal, o servidor reportou banda de 64Mbps, e após a regra, 6,7Mpbs, conforme o log acima.

Agora, vejamos o gráfico da placa de rede do client, gerado pelo NetMeter.

Bom é isso… espero ter ajudado. Qualquer dúvida mandem comentários!! Abraços e até mais…

Compartilhe:
  • Print
  • Twitter
  • del.icio.us
  • Google Bookmarks
  • Live
  • email
  • RSS
  • Facebook
  • Technorati
  • MySpace
  • Digg
  • LinkedIn
  • MSN Reporter
  • Netvibes
  • Yahoo! Bookmarks
  • PDF

Quem mexeu na configuração?

Quem mexeu no roteador? Ou, quais foram os últimos comandos utilizados?

Quem não tem um servidor de accounting, como o ACS, pode usar uma funcionalidade chamada Configuration Change Notification and Logging, inclusa no próprio IOS (a partir da versão 12.3(4)T) para identificar quem anda fazendo alterações no equipamento e quais configurações estão sendo feitas.

Esta funcionalidade (que não é assim um ACS) permite o acompanhamento das alterações na configuração, identificando sessão, usuário e comando utilizado entre outros.

Observação: apenas os comando completos e com sucesso são logados.

Além de armazenar as mudanças também podemos configurar para que as alterações sejam enviadas para o processo de syslog do roteador, que passará a enviar para o syslog server (desde que configurado, claro).

Configuração do Configuration Change Notification and Logging

! Entre no modo de configuração global
BrainGW01#conf t
! Entre no modo archive
BrainGW01(config)#archive
! Agora entre no log config
BrainGW01(config-archive)#log config
! Habilite o logging
BrainGW01(config-archive-log-cfg)#logging enable
! Defina quantidade de entradas (valores 1 a 1000, 100 é o padrão) – opcional
BrainGW01(config-archive-log-cfg)#logging size 200
! Configure para que as senhas sejam omitidas – opcional
BrainGW01(config-archive-log-cfg)#hidekeys
! Envia as mudanças para o syslog – opcional
BrainGW01(config-archive-log-cfg)#notify syslog
BrainGW01(config-archive-log-cfg)#end
BrainGW01#

Após habilitar o archive log, os comando passarão a ser gravados, e ara verificar os logs gerados utilize o comando show archive log config all.

BrainGW01#show archive log config all
idx   sess           user@line      Logged command
1     1         andreo@vty0     |  logging enable
2     1         andreo@vty0     |  hidekeys
3     6         andreo@vty0     |hostname teste
4     7         andreo@vty0     |hostname BrainGW01

Também podemos usar os seguintes comandos, para mais informações:

  • show archive log config number [end-number]
  • show archive log config all provisioning
  • show archive log config statistics

Outra informações na página da Cisco, e até a próxima.

Compartilhe:
  • Print
  • Twitter
  • del.icio.us
  • Google Bookmarks
  • Live
  • email
  • RSS
  • Facebook
  • Technorati
  • MySpace
  • Digg
  • LinkedIn
  • MSN Reporter
  • Netvibes
  • Yahoo! Bookmarks
  • PDF

Tema Brainwork 0.2(beta)