O espelhamento de VLANs é uma técnica que permite que o Switch efetue a cópia dos pacotes de uma VLAN para uma porta do Switch.
Essa técnica é bastante utilizada quando precisamos analisar o comportamento de alguma rede como por exemplo, para identificação de vírus, acessos “estranhos”, etc.
No cenário abaixo efetuaremos a cópia do tráfego da vlan 99 do Switch para o Servidor de Análise. A comunicação da VLAN 99 com qualquer host ou servidor da rede não será afetada pois o Switch direcionará apenas a cópia do tráfego!
Configuração
# vlan 99 # traffic classifier TRAFEGO operator and if-match any ! Criando a política para dar match no tráfego, nesse caso, qualquer tráfego (any) ! ( é possível inclusive vincular uma ACL para filtrar o tráfego) # traffic behavior ESPELHAR mirror-to interface Ethernet1/0/7 ! Criando o behavior para o espelhamento [para a interface Ethernet1/0/7] # qos policy ESPELHAMENTO classifier TRAFEGO behavior ESPELHAR ! Vinculando o tráfego com o comportamento na policy # qos vlan-policy ESPELHAMENTO vlan 99 inbound ! Vinculando a policy para a vlan 99 #
No servidor de coleta poderíamos utilizar os Softwares TCPDump, Wireshark, etc para monitorar o tráfego.
Há diversas situações em que o Eng. de Rede necessita administrar uma rede (ou alguns velhos Switches), em cenários que não possui a senha para acesso console, telnet ou SSH do equipamento.
Nesse video mostramos algumas saídas utilizando o boot menu para o acesso à administração do Switch ou Roteador.
As ACL (Access Control List) são utilizadas para classificar tráfego para os mais diversos fins, como por exemplo, políticas de filtro de pacotes, QoS e PBR.
Uma ACL pode classificar um tráfego baseando-se no fluxo de dados que entram ou saem de uma interface (porta física, interface VLAN, VLAN, etc).
Na maioria dos casos uma ACL é utilizada para determinar se um pacote será permitido ou descartado em uma porta com as ações PERMIT ou DENY.
Essas ações são seguidas das definições DO QUE se deve permitir (PERMIT) ou negar (DENY). Estas, basicamente, são as principais opções:
ANY (tudo) [IP do host/rede] [subrede no formato wildcard] [protocolo]
Imaginando de maneira prática, os Roteadores e Switches também podem utilizar como referência para classificação de tráfego as informações de cabeçalho de camada 2 (como endereço MAC), camada 3 (campos de cabeçalho IP) e camada 4 ( portas TCP e UDP).
Para uma ACL é possível adicionar diversas regras. A leitura das regras pelo equipamento é efetuada linha por linha, de cima para baixo; e após a condição ser encontrada (match) o restante das regras não serão mais verificadas. A ordem para satisfazer uma condição, é lida na ordem em que as regras são configuradas.
O blog do CCNA faz o seguinte comentário para a utilização de uma ACL para filtro de pacotes (lembrando que uma ACL pode incluir diversas regras):
A regra básica diz que somente UMA ACL pode ser aplicada em uma mesma interface e direção, em um determinado router (ou switch). Ou seja, em uma mesma interface você até pode ter mais de uma ACL, desde que em sentidos opostos. Os sentidos possíveis são ilustrados no diagrama abaixo.
(IN) entrante —–> ROUTER ——> sainte (OUT)
Tipos de ACL
Os equipamentos baseados no Comware permitem três tipos de ACL:
Camada 2: Especificam regras baseadas em endereços MAC de origem, destino, VLAN e tipos de protocolo Ethernet.
Camada 3(básica): Especificam regras baseadas em endereços IP e rede de origem.
Camada 3 (Avançada): Especificam regras baseadas em protocolos de camada 3, redes de origem e destino; e portas de origem e destino.
Definindo a ACL
A definição do template para a configuração das Listas de Acesso é baseado pelos números,que a identificam:
ACL Básica: número 2000 a 2999
ACL Avançada: número de 3000 a 3999
ACL de camada 2: número de 4000 a 4999
ACL Básica
Baseia-se no endereço de rede de origem para filtrar ou permitir o tráfego.
Imaginando que você deseja filtrar quais máquinas podem efetuar efetuar Read and Write via SNMP em um Switch…
acl number 2100
! Criando a ACL 2100
rule permit source 172.31.1.100 0.0.0.0
! Criando a primeira regra na ACL 2000 permitindo a rede 172.31.1.100
! com 32 bits (máscara de host para somente uma máquina gerenciar o Switch via SNMP)
quit
snmp-agent community write comutadores acl 2100
! Vinculando a ACL 2100 na communty SNMP RW “comutadores”
A regra acima irá permitir o acesso SNMP somente ao host 172.31.1.100, o restante da rede terá o acesso negado para coleta SNMP nesse equipamento.
Obs: Apesar do exemplo acima ser bem simples, uma ACL básica também pode ser configurada para filtrar pacotes que entram ou saem do Roteador com a política baseada na rede de origem.
ACL Avançada
A diferença entre uma ACL básica e avançada é a forma de relacionamento com as informações no cabeçalho IP. A ACL avançada utiliza os campos de endereço IP de origem e destino, porta e número de protocolo diferenciando pacotes como TCP e UDP.
Alguns parâmetros especiais poderão ser utilizados na construção de uma ACL avançada:
Endereço IP de origem
Endereço IP de destino
Porta de origem
Porta de destino
Tipo de pacote ICMP
Parâmetro SYN do TCP
Valor IP Precedence
Valor DSCP
Valor TOS
Fragmentos
Abaixo segue o exemplo de uma ACL avançada criada e aplicada em uma interface do Roteador HP 6600 para filtro de pacotes na entrada da interface Giga3/2/1
firewall enable slot 3
! Habilitando o filtro de pacotes no slot3 do roteador
firewall default deny slot 3
! Habilitando uma regra de deny implícito após a configuração manual da última regra da ACL
acl number 3030 name INTERNET-INBOUND
! Criando a ACL 3030 e atribuíndo o nome de "INTERNET-INBOUND"
rule 10 permit icmp destination 200.200.200.0 0.0.0.255
! permindo os pacotes com o ip dentro do range 200.200.200.0/24 no cabeçalho de destino com wildcard
rule deny ip source 10.0.0.0 0.255.255.255
rule deny ip source 172.16.0.0 0.15.255.255
rule deny ip source 192.168.0.0 0.0.255.255
rule deny ip source 127.0.0.0 0.255.255.255
! negando qualquer pacote com ip de origem dentro do range da RFC 1918
rule 60 deny ip source 0.0.0.0 0.255.255.255
! negando qualquer pacote com ip de origem como 0.0.0.0
rule 9999 permit ip
! permitindo qualquer endereço IP de origem e destino
quit
#
acl number 3040 name INTERNET-OUTBOUND
rule deny ip source 10.0.0.0 0.255.255.255
rule deny ip source 172.16.0.0 0.15.255.255
rule deny ip source 192.168.0.0 0.0.255.255
rule deny ip destination 224.0.0.0 15.255.255.255
rule deny ip source 224.0.0.0 15.255.255.255
#
interface GigabitEthernet3/2/1
port link-mode route
firewall packet-filter name INTERNET-INBOUND inbound
firewall packet-filter name INTERNET-OUTBOUND outbound
! Aplicando a ACL para filtro na entrada e saída de pacotes
ip address 123.123.123.218 255.255.255.252
#
Segue um segundo exemplo de ACL avançada mas dessa vez em Switches do modelo 4800
acl number 3000
! Criando a ACL 3000
rule permit ip source 172.31.1.0 0.0.0.255 destination 192.168.1.0 0.0.0.255
! Criando a primeira regra na ACL 3000 permitindo a rede 172.31.1.0 com 24 bits (máscara
/24) efetuar comunicação IP com a rede 192.168.1.0/24
rule deny ip source any
! Criando a segunda regra na ACL 3000 negando qualquer rede de origem
quit
#
interface vlan 2
ip address 192.168
packet-filter 3000 inbound
!Aplicando a ACL 2000 para filtro na interface VLAN.
Obs: Para aplicarmos uma ACL em Portas físicas ou interface VLAN de um Switch é utilizado o comando packet-filter, já para roteadores, comando poderá ser incrementando com a sintaxe “firewall packet-filter….”
A regra acima irá permitir a comunicação IP, da rede 172.31.1.0/24 para a rede 192.168.1.0/24, o restante do tráfego terá o acesso negado.
Se precisarmos utilizar outros parâmetros para match da ACL podermos utilizar o caracter ? após o permit ou deny. Parâmetros como TCP, UDP, ICMP e etc poderão também ser utilizados
O exemplo abaixo exemplifica a utilização de parâmetros de portas TCP para criarmos a regra, como por exemplo permitir o acesso somente a serviços que realmente serão utilizados.
O restante do tráfego será negado, provendo maior segurança e escalabilidade pela utlilização de diversas VLANs.
As ACL que utilizam parâmetros da camada de enlace do modelo de referencia OSI, poderão ser utilizadas para filtrar baseando-se em campos como ID da VLAN, mascara de endereços MAC (os primeiros bits são reservados para endereço dos fabricantes) , tipos de Protocolos,etc.
Obs: a configuração e o tipo de ACL disponivel em cada equipamento pode sofrer pequenas variações ou limitações na configuração. Sempre faça um teste antes de aplicar a ACL em um ambiente de produção.
A agregação de diversas interfaces Ethernet (portas físicas) para a utilização de uma única porta lógica com o intuito de prover redundância e aumento de banda é uma atividade muito comum em redes de médio e grande porte .
Infelizmente o nome atribuído pelos fabricantes não segue um padrão, mas por outro lado todos possuem as mesmas funções citadas anteriormente:Etherchannel, Port-channel, Link-Aggregation, Bridge-Aggregation, Trunk [ nome dado antigamente para agregação de portas.(Não confundam com a utilização de interface Trunk atribuída pelos Switches Cisco e 3Com. Os Switches Procurve ainda utilizam essa terminologia) ] e etc.
Existem algumas formas de estabelecer a agregação de portas, como por exemplo:
– Manual : sem a certificação do meio por protocolos auxiliares – PAgP : Protocolo disponível em equipamentos Cisco – LACP : Protocolo padrão IEEE, disponível quase todos Switches gerenciáveis.
Modos de formação de um Etherchannel em Switches Cisco
Cisco(config-if)# channel-group 1 mode ?
active Enable LACP unconditionally
auto Enable PAgP only if a PAgP device is detected
desirable Enable PAgP unconditionally
on Enable Etherchannel only
passive Enable LACP only if a LACP device is detected
No Script abaixo mostraremos a configuraçaõ de Link Aggregation/Etherchannel entre um Switch Cisco IOS e um Switch HP baseado no Comware:
Switch Comware
#
interface Bridge-aggregation 1
link-aggregation mode dynamic
! Estabelecendo a conexão do Link-Aggregation utilizando o protocolo LACP
#
interface gigabitEthernet 1/0/1
port link-aggregation group 1
! Atribuindo a porta para negociar a agregação via protocolo LACP
#
interface gigabitEthernet 1/0/2
port link-aggregation group 1
! Atribuindo a porta para negociar a agregação via protocolo LACP
Switch Cisco IOS
!
interface port-channel 1
!
interface gigabitEthernet 1/10
channel-group 1 mode active
! Estabelecendo a conexão do Etherchannel utilizando o protocolo LACP
!
interface gigabitEthernet 1/11
channel-group 1 mode active
! Estabelecendo a conexão do Etherchannel utilizando o protocolo LACP
!
Comandos Show e Display
Switch Comware
[HPN]display link aggregation verbose
Aggregation Interface: Bridge-Aggregation1
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, 3822-d6a2-5c00
Local:
Port Status Priority Oper-Key Flag
----------------------------------------------------
GE1/0/1 S 32768 8 {ACDEF}
GE1/0/2 S 32768 8 {ACDEF}
Remote:
Actor Partner Priority Oper-Key SystemID Flag
------------------------------------------------------------
GE1/0/1 516 32768 45 0x8000, 4055-39d4-8e13 {ACDEF}
GE1/0/2 517 32768 45 0x8000, 4055-39d4-8e13 {ACDEF}
Switch Cisco IOS
Cisco#show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s – suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 2
Number of aggregators: 2
Group Port-channel Protocol Ports
------+-------------+-----------+--------------------------
1 Po1(SU) LACP Gi1/10(P) Gi1/11(P)
Não esqueça!!!
Sempre quando for necessario a alteração de VLANs das portas do Link Aggregation/Etherchannel faça a alteração somente na interface virtual ( port channel/ bridge-aggregation), que a configuração será replicada para as interfaces físicas. Mantenha a consistência de VLANs nas 2 pontas do Link Aggregation/Etherchannel.
Use velocidades de portas idênticas como: interfaces 1Gb com interfaces 1G e interfaces 10Gb com interfaces 10Gb e assim por diante…
A configuração de hierarchical CAR permite agregar inúmeras políticas de “limitação de banda” e compartilhar sobre uma única “grande” banda.
Dependendo do modo de configuração, a limitação de banda dos perfis (traffic classifier + traffic behavior) de “QoS” flutuará até atingir o limite do hierarchical CAR.
Imaginando que no cenário abaixo um Cliente quer limitar a banda de HTTP em 128Kbps e o “restante do tráfego” em 64Kbps. Como a banda contratada foi de 256Kbps, o trafego HTTP poderá usar 192Kbps caso o “restante do tráfego” esteja em 64kbps; ou o “restante do tráfego” poderá utilizar 128Kbps caso o HTTP não passe de 128Kbps.
Configuração
vlan 3
#
qos car CLIENTE-A hierarchy cir 256
! Configurando o hierarchy CAR como 256kbps
#
acl number 3001 name MATCH_WWW
rule 0 permit tcp destination-port eq www
! Selecionando o tráfego HTTP como destino
#
traffic classifier MATCH_HTTP operator and
if-match acl name MATCH_WWW
! Classificação do tráfego da ACL MATCH_WWW
!
traffic classifier MATCH_ANY operator and
if-match any
! Classificação para qualquer tipo de tráfego
#
traffic behavior 128kbps-BW
car cir 128 hierarchy-car CLIENTE-A mode or
! Comportamento para limitar a banda em 128Kbps vinculado ao hierarchy-car
traffic behavior 64kbps-BW
car cir 64 hierarchy-car CLIENTE-A mode or
! Comportamento para limitar a banda em 64Kbps vinculado ao hierarchy-car
#
qos policy BW-CLIENTE-A
classifier MATCH_WWW behavior 128kbps-BW
classifier MATCH_ANY behavior 64kbps-BW
! Criando Policy para vincular os classifier + behavior
#
interface GigabitEthernet1/0/15
port link-mode bridge
port access vlan 3
qos apply policy BW-CLIENTE-A inbound
qos apply policy BW-CLIENTE-A outbound
! Aplicando a Policy à interface no sentido de entrada e saída
Para a verificação da banda e scripts utilizados use os comandos display qos car name [nome do hierchical car] ou display qos policy interface [nome da interface] [ inbound | outbound ]
Modos AND e OR
Por padrão, o hierarchical CAR funciona no modo OR no qual um fluxo pode passar o limite aplicado a ele desde que não ultrapasse o limite do hierarchical CAR. Como, por exemplo, o cenário dado nesse post.
Já o modo AND o fluxo não pode passar o limite aplicado e a soma dos 2 não pode passar o limite total do hierarchical CAR. Por exemplo, 2 fluxos configurados com 128Kbps e o hierarchical CAR configurado com 192kbps. Cada fluxo individualmente não poderá passar da banda total contratada (192Kbps) e caso haja banda disponível e o total de cada fluxo será de 128Kbps (se houver banda disponível).
Segue abaixo uma dica bacana enviada pelo Paulo Roque… Alguns Switches HPNs suportam uma funcionalidade de back-out que permite retornar a configuração ao um estado anterior com um único comando. Basta salvar a configuração antes de iniciar o processo de mudança da configuração e em necessidade de retorno da configuração anterior por problemas de feature, planejamento e etc, basta retornar para a última configuração salva 😉
A vantagem é que minimiza erros em caso de problemas durante uma janela de mudança…
Compatilho abaixo o script (comentado) para a autenticação de usuários em uma base remota para administração de um Roteador MSR 30-16. Os testes serviram para validar um Servidor ACS da Cisco para autenticação via TACACS em um Roteador HP. A diferença deste teste para as outras configurações é a utilização do TACACS dentro de uma vpn-instance (VRF).
Configuração
#
ip vpn-instance test
route-distinguisher 1:1
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
! Criando a VRF “test”
#
super password level 3 simple s3nhasup3r
super authentication-mode scheme
#
telnet server enable
#
hwtacacs scheme acs
! Criando o esquema TACACS com o nome acs
primary authentication 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para autenticação
primary authorization 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para autorização
primary accounting 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para contabilidade
nas-ip 172.16.1.1
!Endereço de IP do Switch cadastrado no ACS
key authentication teste123
! Chave para autenticação com o servidor ACS com a senha"teste123"
key authorization teste123key accounting teste123user-name-format without-domain
! Encaminhamento do usuário sem o formato @dominio
#
domain acsauthentication login hwtacacs-scheme acs local
!Configurando a autenticação com TACACS e em caso de falha, a autenticação será local.
authorization login hwtacacs-scheme acs localaccounting login hwtacacs-scheme acs localauthentication default hwtacacs-scheme acs localauthorization default hwtacacs-scheme acsaccounting default hwtacacs-scheme acsauthentication super hwtacacs-scheme acsaccounting command hwtacacs-scheme acs
#
domain default enable acs
! Habilitando o dominio acs como default para auetnticação
#
interface Ethernet0/0
port link-mode route
ip binding vpn-instance test
172.16.1.1 255.255.255.0
#
user-interface vty 0 4
authentication-mode scheme
#
obs: Sugerimos que durante os testes, não configure o authentication-mode scheme no acesso via Console, para em caso de falha nos testes, você não fique trancado do lado de fora do Switch.
A autenticação do “super-usuário” via TACACS também está inclusa no script.
A utilização de Shapping e Policy em modelos de QoS permite o controle do tráfego utilizado em cima de uma banda disponível , mas finita. Ambos são mecanismos de medição e controle para diferentes classes, para atribuição de políticas ou acordos de níveis de serviço.
O modelo de traffic Shapping buferiza o tráfego que é excedente de acordo com as politicas estabelecidas/contratadas; já o modelo de Policing descarta o tráfego que é excedente ou remarca o campo do pacote IP para cair em uma classe de serviço menos prioritária.
Para conseguir efetuar a medição do tráfego, um modelo bastante utilizado pelo mercado é o CIR/ PIR ( CIR – Committted Information Rate, e PIR – Peak Information Rate).
A função do CIR é garantir a banda (ou taxa de dados) contratada; e a função do PIR é a banda máxima (ou pico de dados) que possa ser utilizado no link. Geralmente este modelo é oferecido na venda de serviços para terceiros.
O modelo CIR/PIR possui três modelos de interválos para tráfego de entrada onde cada um é associado a uma cor. O tráfego dentro do CIR é colorido como verde , o tráfego entre o CIR e o PIR como amarelo e o tráfego acima do limite do PIR é colorido como vermelho, descritos na RFC 2698.
Uma vez estabelecido os limites de serviço, por exemplo, um serviço de 1024Kbps contratado como CIR e o PIR como 2048Kbps , o trafego dentro do CIR terá a garantia de banda de 1Mb, já o tráfego dentro do PIR não terá a garantia de encaminhamento ou talvez cobrado o “Mega” adicional de pacotes e bytes transferidos na faixa entre o CIR e o PIR; para o trafego acima de 2Mb, será categorizado como vermelho, e provavelmente será configurado uma politica de descarte de pacotes.
Segue abaixo um exemplo de configuração utilizando o CIR/PIR com Policy em um Switch HPN 5800 para controle de banda:
Configuração em um Switch HPN 5800
vlan 15
name cliente-x
#
traffic classifier cliente-x operator and
if-match any
! Classifier dando match em todo o tráfego
#
traffic behavior cliente-x
car cir 1024 pir 2048 green pass red discard yellow pass
! Configurando o CIR o PIR e permitindo o trafego green, yellow e descartando o red
accounting byte
! Contabilizando o tráfego no formato bytes
#
qos policy CLIENTE-X-BW-CONTROL
classifier cliente-x behavior cliente-x
#
qos vlan-policy CLIENTE-X-BW-CONTROL vlan 15 inbound
! Configurando a Policy à VLAN 15 para controle do tráfego do cliente
#
Comandos Display
<5800>display qos vlan-policy vlan 15
Vlan 15
Direction: Inbound
Classifier: cliente-x
Matched : 0(Packets)
Operator: AND
Rule(s) : If-match any
Behavior: cliente-x
Committed Access Rate:
CIR 1024 (kbps), CBS 64000 (byte), EBS 0 (byte), PIR 2048 (kbps)
Green Action: pass
Red Action: discard
Yellow Action: pass
Green : 34555(Packets) 89891278(Bytes)
Yellow: 2(Packets) 2048(Bytes)
Red : 0(Packets) 0(Bytes)
Accounting Enable:
4967306 (Packets)
Conforme dito anteriormente, é possível remarcar os pacotes que estão como yellow e red para valores DSCP com prioridade menor…
[5800-behavior-cliente-x]remark ?
atm-clp Remark ATM CLP
bfi Remark BFI ID
customer-vlan-id Remark Customer VLAN ID
dot1p Remark IEEE 802.1p COS
drop-precedence Remark drop precedence
dscp Remark DSCP (DiffServ CodePoint)
forwarding-class Remark forwarding class
fr-de Remark fr-de
green Specify type of remark for green packets
ip-precedence Remark IP precedence
local-precedence Remark local precedence
mpls-exp Remark MPLS EXP
qos-local-id Specify QoS local ID feature
red Specify type of remark for red packets
yellow Specify type of remark for yellow packets
[5800-behavior-cliente-x]remark red ?
atm-clp Remark ATM CLP
dot1p Remark IEEE 802.1p COS
dscp Remark DSCP (DiffServ CodePoint)
fr-de Remark fr-de
ip-precedence Remark IP precedence
local-precedence Remark local precedence
mpls-exp Remark MPLS EXP
Com a coleta SNMP habilitada no Switch é possível contabilizar os bytes tráfegados em um servidor de coleta para venda de serviços on-demand, como internet por exemplo.
Obs: Para aqueles que estão acostumados com equipamentos Cisco, os dispositivos poderão trabalhar o modelo CIR/PIR da seguinte forma: – Menor ou igual ao CIR é chamado de “conform” – Acima do CIR e Menor ou igual ao PIR é chamado de “exceed” – Acima do PIR “violate”
Até a proxima! 😉
Referências: QoS-Enabled Networks: Tools and Foudations – Miguel Barreiros e Peter Lundqvist – John Wiley & Sons
Cisco ONT – Offical Certification Guide –Amir Ranjbar – CiscoPress
A funcionalidade DHCP Snooping permite a proteção da rede contra Servidores DHCP não autorizados e sua configuração é bastante simples. O comando dhcp-snooping configurado globalmente, faz o Switch filtrar todas as mensagens DHCP Offer e DHCP Ack encaminhadas pelo falso Servidor DHCP. A configuração restringe todas as portas do Switch como untrusted (não confiável).
Para o funcionamento do ‘Servidor DHCP válido’ deveremos configurar a porta do Servidor DHCP como trusted (confiável), incluíndo as portas de uplink.
O Kleber Coelho, enviou a dica abaixo na qual ele precisou mexer em uma configuração sensível no Switch HP 7510 que poderia gerar a perda da gerencia do equipamento.
Inicialmente ele salvou a configuração atual do Switch. Após isso, agendou o reboot para 10 minutos (em caso de perda da gerencia, o Switch reiniciaria e voltaria a ultima configuração salva), aplicou a configuração e após o sucesso dos comandos aplicados, ele cancelou o reboot.
A configuração do schedule reboot deverá ser feita no modo “user-view”
Segue o email do Kleber:
Diego, boa tarde, tudo bem?
Recentemente precisei bloquear da divulgação do OSPF um IP de gerência local em um HP-A7510. Se for útil para você colocar no blog, sinta-se à vontade!
# salvando a configuração atual
save force
# gatilho de reboot para garantir a recuperação,
# caso dê algo errado e perca o acesso
schedule reboot delay 10
# criar ACL com redes bloqueadas
system
acl number 2500 name Remove_BOGON_OSPF
# rule deny source <IP> <Wildcard>
rule deny source 192.168.255.0 0.0.0.255
rule permit
# aplicar ACL na instancia OSPF
ospf 1
filter-policy 2500 export
# Se der algo errado e perder acesso,
# basta esperar o equipamento reiniciar em 10 minutos.
# Se tudo der certo, salve e remova o agendamento de reboot.
save force
quit
quit
undo schedule reboot
COMUTADORES 
