MSR
Comware: Rota estática flutuante (floating static route)
Uma rota estática flutuante é uma rota estática com uma distância administrativa maior do que a estabelecida por padrão em Switches e Roteadores. Por exemplo, no Comware da HP as rotas estáticas possuem distância administrativa com o valor 60 e o protocolo OSPF com as rotas externas com o valor 150, nesse caso pelo fato da menor distância administrativa ser escolhida quando duas rotas idênticas são aprendidas de maneiras distintas pelo roteador, o equipamento escolherá o processo com menor AD ( administative distance/ distancia administrativa).
Como exemplo, poderíamos imaginar um roteador com 2 links, em um deles a rota 192.168.1.0/24 pode ser aprendida via rotas externas OSPF e nesse caso precisaremos encaminhar o tráfego para esse link como principal. Já como backup configuraríamos a rota estática 192.168.1.0/24 com a distância administrativa com o valor 250 apontando para o next-hop do segundo link.
Quando o primeiro link apresentar problemas, o processo OSPF perceberá a falha e removerá a rota 192.168.1.0/24 aprendida dinamicamente e começará a utilizar a rota estática (não utilizada anteriormente) com o mesmo endereço 192.168.1.0/24 configurada para encaminhar os pacotes para o segundo link.
Quando o OSPF voltar a funcionar com o restabelecimento do primeiro link, a rota estática deixará de ser utilizada, voltando para o encaminhamento de pacotes pela rota aprendida dinamicamente.
[Comware] ip route-static 192.168.1.0 255.255.255.0 172.17.1.2 preference 250
Obs: Lembre-se que a rota estática só entrará na tabela de roteamento se a interface correspondente ao próximo salto (next-hop) estiver UP.
Caso tenham alguma dúvida sobre o assunto, deixem um comentário.
http://pt.wikipedia.org/wiki/Dist%C3%A2ncia_administrativa
http://www.rotadefault.com.br/rota-estatica-flutuante-floating-static-route/
Abração a todos
Roteadores MSR’s: Script de GRE sobre VPN IPsec
HP Network Simulator – o simulador de equipamentos de rede HP baseado no Comware 7
Recentemente a HP liberou uma nova versão do simulador para testes de comandos e features em equipamentos HP/ H3C /3Com ( baseados no Comware). O software é chamado de Simware ou HP Network Simulator .
A notícia é muito bem vinda e aguardada há um bom tempo por aqueles que administram esses equipamentos.
O simulador baseia-se a versão 7 do Comware (a maioria dos comandos é muito similar a versão 5 do Sistema Operacional).
Segue o link para download, dentro dele há as instruções para instalação e configuração da topologia (em inglês):
http://h17007.www1.hp.com/ca/en/networking/products/simulator/index.aspx#.Ve12dRFViko
https://support.hpe.com/hpesc/public/home/driverHome?sp4ts.oid=7107839
Obs: Um detalhe importante é a necessidade do Virtual Box para o funcionamento do Simulador, caso você encontre algum problema na instalação, utilize a versão 4.3.2 http://download.virtualbox.org/virtualbox/4.3.2/
Apesar da ferramenta trabalhar no modo GUI, a montagem da topologia deverá ser feita via texto em um arquivo de configuração (também explicado no manual do software).
Curtam, compartilhem e façam comentários. É um bom momento para comemorarmos. 🙂
Se o link estiver quebrado, deixe um comentário.
Um grande abraço
Resumo: BGP – Router Reflector em Roteadores HP
O algoritmo do BGP não permite que rotas aprendidas via iBGP sejam anunciadas para roteadores vizinhos. Lembrando que uma rota aprendida via eBGP deve ser ensinada para um vizinho iBGP, mas uma rota aprendida via iBGP não deve ser anunciada para roteadores vizinhos.
Quando BGP foi projetado originalmente, não havia nenhuma provisão para a prevenção de loop dentro de um Sistema Autônomo (AS ou ASN). Em vez disso, a regra de prefixos iBGP proíbe o anuncio de rotas aprendidas via iBGP para outro peer BGP interno.
Esta é a razão principal pela qual a inteligência do BGP necessita de conexões full mesh entre roteadores iBGP, isto é, todos roteadores devem estar conectados entre si. Mas a topologia iBGP com full mesh, traz problemas de escalabilidade na configuração, uma vez que o número de sessões para troca de tráfego irá ser N (N-1) / 2, onde N é o número de roteadores internos BGP
Perceba no diagrama abaixo que o prefixo aprendido por R3 via iBGP não é encaminhado para o roteador R4 devido a regra de prefixos aprendidos via iBGP citado acima.
Utilizando Roteadores Refletores (Router Reflectors ou RRs) em uma topologia iBGP, permitirá ao protocolo BGP quebrar a regra de proibição ao ensinar rotas aprendidas via iBGP para vizinhos internos.
Os roteadores configurados como Router Reflector dividem os seus vizinhos iBGP em duas classes: clientes e não-clientes.
As rotas aprendidas por roteadores iBGP clientes serão anunciadas para roteadores clientes e não-clientes. No, entanto as rotas aprendidas a partir de não-clientes serão anunciadas apenas para clientes.
Perceba no diagrama abaixo o prefixo anunciado para o Roteador R4 pelo Roteador R3 configurado como RR.
A configuração do Router Reflector só é necessária no roteador RR “servidor”, nenhuma configuração é necessária nos equipamentos clientes. Segue abaixo a configuração de R3.
! Configuração R3 ! bgp 234 peer 2.2.2.2 as-number 234 peer 2.2.2.2 description R2 peer 2.2.2.2 reflect-client peer 2.2.2.2 connect-interface LoopBack1 !
Cluster_List e Originator_ID
A configuração de Route Reflector é geralmente a atribuída a ambientes bem complexos. O BGP utiliza-se de alguns mecanismos para prevenção de loops como Cluster List e Originator ID:
– Cluster ID: O RR adiciona seu cluster ID ao encaminhar o update. Quando recebe um update BGP que contem o seu próprio Cluster ID os prefixos recebidos são descartados, evitando assim o gerar loop de roteamento pelos anuncios entre clusters.
– Originator ID: Uma lista de clusters (cluster-list) é uma seqüência de cluster-IDs que a rota atravessou. Quando um RR reflete uma rota de seus clientes para non-clients fora do cluster, ele adiciona o cluster-id local no final da cluster-list. Usando este atributo, um RR pode identificar se uma informação de roteamento fez um loop e voltou ao mesmo cluster que a originou (por alguma falha de configuração). Se o cluster-id local é encontrado na cluster-list, o anúncio da rota será descartado.
Conforme diagrama abaixo, segue um exemplo do output com a lista do Cluster list:
[R1]display bgp routing-table 55.55.55.0
BGP local router ID : 1.1.1.1
Local AS number : 234
Paths: 1 available, 1 best
BGP routing table entry information of 55.55.55.0/24:
RR-client route.
From : 4.4.4.4 (4.4.4.4)
Relay Nexthop : 192.168.45.5
Original nexthop: 2.2.2.2
AS-path : 5
Origin : igp
Attribute value : MED 0, localpref 100, pref-val 0, pre 255
State : valid, internal,
Originator : 2.2.2.2
Cluster list : 0.0.0.2, 0.0.0.1
Segue abaixo a configuração de R3 e R4 (lembrando que nenhuma configuração BGP adicional é necessária para o Roteador cliente Router Reflector
# ! Configuração R3 router bgp 234 bgp cluster-id 1 neighbor 2.2.2.2 remote-as 234 neighbor 2.2.2.2 description R2 neighbor 2.2.2.2 update-source Loopback1 neighbor 2.2.2.2 route-reflector-client ! neighbor 4.4.4.4 remote-as 234 neighbor 4.4.4.4 description R4 neighbor 4.4.4.4 update-source Loopback1 ! # ! Configuração R4 router bgp 234 bgp cluster-id 2 neighbor 1.1.1.1 remote-as 234 neighbor 1.1.1.1 description R1 neighbor 1.1.1.1 update-source Loopback1 neighbor 1.1.1.1 route-reflector-client ! neighbor 3.3.3.3 remote-as 234 neighbor 3.3.3.3 description R3 neighbor 3.3.3.3 update-source Loopback1 !
Até logo
Referências
http://blog.ipexpert.com/2012/02/20/understanding-bgp-originator-id-and-cluster-id/#top
http://www.rnp.br/newsgen/0109/bgp4_dicas2.html#ng-6
http://www.rotadefault.com.br/teste-mesa-para-router-reflectors/
http://www.rotadefault.com.br/resumo-bgp-router-reflectors/
CCIE Routing and Switching Certification Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue
Roteamento entre VRFs com MP-BGP em Roteadores HP / H3C
A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.
Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.
A configuração de VRFs é bem simples e há um artigo aqui do blog que pode ser consultado no link [http://www.comutadores.com.br/vrf-em-switches-e-roteadores-hpn-vpn-instance/].
Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá… 😉
Habilitando o import e export das VRFs
Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)
RD – Route Distinguisher
Como explicado anteriormente, as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .
O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.
O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.
[R1-vpn-instance-Cliente_A]route-distinguisher ? STRING ASN:nn or IP_address:nn VPN Route Distinguisher ! ! Configurando a VRF para os clientes A B e C ip vpn-instance Cliente_A route-distinguisher 65000:1 ! ip vpn-instance Cliente_B route-distinguisher 65000:2 ! ip vpn-instance Cliente_C route-distinguisher 65000:3
Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.
RT – Route-Target ou VPN-target
Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.
O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos).
Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.
! ! ip vpn-instance Cliente_A route-distinguisher 65000:1 vpn-target 65000:1 export-extcommunity vpn-target 65000:1 import-extcommunity vpn-target 65000:2 import-extcommunity ! ip vpn-instance Cliente_B route-distinguisher 65000:2 vpn-target 65000:2 export-extcommunity vpn-target 65000:2 import-extcommunity vpn-target 65000:1 import-extcommunity ! ip vpn-instance Cliente_C route-distinguisher 65000:3 vpn-target 65000:3 export-extcommunity vpn-target 65000:3 import-extcommunity !
Segue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.
! ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface Loopback1 ip binding vpn-instance Cliente_A ip address 1.1.1.1 255.255.255.0 ! interface Loopback2 ip binding vpn-instance Cliente_B ip address 2.2.2.2 255.255.255.0 ! interface Loopback3 ip binding vpn-instance Cliente_C ip address 3.3.3.3 255.255.255.0 ! # bgp 6500 undo synchronization # ipv4-family vpn-instance Cliente_A import-route direct # ipv4-family vpn-instance Cliente_B import-route direct # ipv4-family vpn-instance Cliente_C import-route direct # !
Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs(vpn-instances) e o teste de ICMP
[R1]display ip routing-table vpn-instance Cliente_A Routing Tables: Cliente_A Destinations : 4 Routes : 4 Destination/Mask Proto Pre Cost NextHop Interface 1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0 2.2.2.2/32 BGP 130 0 127.0.0.1 InLoop0 127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0 127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0 [R1]ping -vpn-instance Cliente_A 2.2.2.2 PING 2.2.2.2: 56 data bytes, press CTRL_C to break Reply from 2.2.2.2: bytes=56 Sequence=1 ttl=255 time=4 ms Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=255 time=10 ms Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=255 time=10 ms Reply from 2.2.2.2: bytes=56 Sequence=4 ttl=255 time=5 ms Reply from 2.2.2.2: bytes=56 Sequence=5 ttl=255 time=4 ms --- 2.2.2.2 ping statistics --- 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 4/5/10 ms
Segue abaixo a configuração completa do R1
Para dúvidas em sugestões deixe um comentário. Até logo 😉
Introdução ao PPPoE e Configuração Básica em Roteadores MSR (HPN/H3C)
O PPP over Ethernet (RFC 2516) é uma especificação que permite a conexão de hosts à Rede do Provedor para acesso a Internet, providenciando conexões ponto-a-ponto, utilizando a Pilha do protocolo PPP sobre o protocolo Ethernet.
O protocolo PPP trabalha com a tecnologia Ethernet para ligar a placa de rede dos usuários ao modem. Desta forma é possível agregarmos a autenticação para a conexão e aquisição de um endereço IP fixo ou dinâmico à máquina do usuário.
Modems DSL são essencialmente simples Bridges Ethernet para conexão com Multiplexadores de Acesso (DSLAMs) da Operadora, oferecendo um túnel PPP sobre Ethernet.
PPPoE em Roteadores MSR
Existem diversas maneiras para a configuração em Roteadores MSR como clientes PPPoE. No exemplo abaixo efetuaremos a configuração básica para simulação do Roteador R1 como cliente PPPoE e R2 como um servidor PPPoE para autenticação utilizando PAP e o fornecimento de endereços por DHCP.
R1: # interface Dialer1 ! Criando a Interface Dialer0 link-protocol ppp ! Habilitando o protocolo PPP ppp pap local-user diego password simple 12345 ! Configurando a autenticação com pap ! usuario "diego" com a senha "12345" ip address ppp-negotiate ! Configurando a negociação IP dinâmica dialer user diego dialer-group 1 dialer bundle 1 ! Configurando o dialer-group 1 e o dialer bundle 1 # interface Ethernet0/1/0 port link-mode route pppoe-client dial-bundle-number 1 ! Vinculando o dialer bundle na interface e0/1/0 # ip route-static 0.0.0.0 0.0.0.0 Dialer1 ! Configurando a rota estática para o Dialer1 #
Comandos Display e Debug
<R1>display pppoe-client session summary PPPoE Client Session: ID Bundle Dialer Intf RemMAC LocMAC State 1 1 1 Eth0/1/0 000fea031100 000feb030f00 PPPUP <R1>display ip interface brief *down: administratively down (s): spoofing Interface Physical Protocol IP Address Description Dialer1 up up 192.168.1.3 Dialer1 I... Ethernet0/1/0 up up unassigned Ethernet0...
! O commando display pppoe-client session mostrará as conexões PPPoE ativas no Roteador incluindo o endereço MAC da outra ponta.
<R1> debugging pppoe-client packet *Sep 25 11:15:31:359 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client OUT Discovery packet (PADI), Len = 30 *Sep 25 11:15:31:374 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client IN Discovery packet (PADO), Len = 49 *Sep 25 11:15:31:390 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client OUT Discovery packet (PADR), Len = 49 %Sep 25 11:15:31:405 2013 SW1 IFNET/3/LINK_UPDOWN: Dialer1:0 link status is UP. *Sep 25 11:15:31:405 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client IN Discovery packet (PADS), Len = 49, Session ID = 1%Sep 25 11:15:33:605 2013 SW1 IFNET/5/LINEPROTO_UPDOWN: Line protocol on the interface Dialer1:0 is UP. %Sep 25 11:15:33:621 2013 SW1 IFNET/5/PROTOCOL_UPDOWN: Protocol PPP IPCP on theinterface Dialer1:0 is UP. %Sep 25 11:15:33:636 2013 SW1 PPPOEC/6/PPPOEC_LOG_ON: PPPoE user diego logged on successfully.
O Debug acima é bastante interessante para entendermos as mensagens de negociação PPPoE .
Durante iniciação da negociação PPPoE o host encaminha uma mensagem PADI (PPPoE Active Discovery Initiation )em Broadcast, quando o Servidor PPPoE ou Concentrador de acesso recebe essa mensagem, ela é respondida com uma mensagem PADO (The PPPoE Active Discovery Offer) contendo informações do Servidor.
Muito similiar as solicitações DHCP, o host poderá receber mais de uma mensagem PADO ( de diversos concentradores). O host responde na seqüência com uma mensagem PADR (PPPoE Active Discovery Request ) em unicast para o Servidor PPPoE escolhido. Se a mensagem PADR for valida, é encaminhada para o host uma mensagem PADS (PPPoE Active Discovery Session-confirmation) para iniciar a sessão PPP.
Obs: Se desejado o fim da sessão PPP é gerado uma mensagem PADT (PPPoE Active Discovery Terminate).
Mais…
Segue abaixo a configuração do Roteador R2, responsável por aceitar e autenticar a conexão de R1.
# local-user diego password simple 12345 service-type ppp ! Configurando o usuario e senha para autenticação # interface Ethernet0/0/0 port link-mode route pppoe-server bind Virtual-Template 1 ! Vinculando a interface virtual-template 1 # interface Virtual-Template1 ppp authentication-mode pap remote address 192.168.1.3 ip address 192.168.1.1 255.255.255.0 ! Habilitando o serviço de autenticação PAP na interface Virtual-Template 1 ! incluindo o IP remoto (nesse caso, poderia ser configurado um servidor DHCP)
Referencias:
http://tools.ietf.org/html/rfc2516
http://babarata.blogspot.com/2010/03/inicio.html
http://fengnet.com/book/VPNs%20Illustrated%20Tunnels%20%20VPNsand%20IPsec/ch04lev1sec3.html
http://blog.ine.com/2010/03/18/bba-group-and-dialer-profiles-with-pppoe/
http://www.rotadefault.com.br/2013/06/26/introducao-ao-pppoe-e-configuracao-basica-em-roteadores-cisco/
Laboratório para configuração simples de MPLS L3VPN
Alterando a distância administrativa para as rotas estáticas para Switches e Roteadores baseados no Comware.
Eu já escrevi alguns post sobre a atenção que deve ser dada para a integração entre Switches e Roteadores 3Com, H3C e HPN quando há a necessidade de compartilhar o roteamento dinâmico.
Como no exemplo abaixo, podemos ver que por padrão, toda rota estática é atribuída com o valor 60 para a distância administrativa. De forma didática, faço a comparação nas duas saídas do comando “display ip routing-table” da escolha da tabela de Roteamento pela rota aprendida com a menor distância adminstrativa (no primeiro quadro via rota estática e no segundo exemplo via OSPF).
[HPN] ip route-static 192.168.10.0 255.255.255.0 192.168.12.2
[HPN]
[HPN] display ip routing-table
Routing Tables: Public
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.10.0/24 Static 60 0 192.168.12.2 Eth0/0/0
192.168.12.0/30 Direct 0 0 192.168.12.1 Eth0/0/0
192.168.12.1/32 Direct 0 0 127.0.0.1 InLoop0
Com a rota aprendida dinâmicamente via OSPF (e a estática ainda configurada), percebam que o roteador insere apenas a rota com a menor distância administrativa (valor 10 para o OSPF).
[HPN]display ip routing-table
Routing Tables: Public
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.10.0/24 OSPF 10 2 192.168.12.2 Eth0/0/0
192.168.12.0/30 Direct 0 0 192.168.12.1 Eth0/0/0
192.168.12.1/32 Direct 0 0 127.0.0.1 InLoop0
Apesar da rota aprendida dinâmicamente “tomar” o lugar da rota estática e possuir o mesmo next-hop (no caso 192.168.12.2, interface Eth0/0/0), em redes mais complexas, o roteamento poderia escolher um caminho menos desejado pelo administrador de rede, visto que em equipamentos de outros fabricantes as rotas estáticas são atribuídas com a distâncias administrativa 1 ( e isso pode passar desapercebido ).
O comando “ip route-static default-preference 1” ajuda aqueles que estão acostumados a trabalhar com ambos roteamento dinâmico e estático, permitindo que as novas rotas configuradas possuam a distância adminstrativa 1 (nesse caso, melhor que todos os protocolos de Roteamento Dinâmico).
[HPN] ip route-static default-preference 1
Caso você prefira escolher manualmente o peso que cada rota terá, basta adicionar o “preference” no final de cada rota.
[HPN] ip route-static 192.168.20.0 255.255.255.0 192.168.12.2 preference ? INTEGER Preference value range
Abração
ACL para Gerenciamento Telnet, SSH, SNMP …
A aplicação de ACL para limitar as redes que poderão efetuar o gerenciamento do Switch e/ou Roteador é uma técnica bastante utilizada para restringir quais redes ou hosts de origem terão a permissão para gerenciar o equipamento via Telnet, SSH ou SNMP
Imaginando uma empresa com diversas sub redes, permitiremos no cenário abaixo o acesso ao Switch apenas da sub rede 172.31.1.0/24 (lembrando que a mascara para listas de acesso [ACL] são no formato de mascara curinga [wildcard mask])
acl number 2000
rule 0 permit source 172.31.1.0 0.0.0.255
rule 5 deny
#
user-interface vty 0 4
acl 2000 inbound
! Vinculando a ACL 2000 ao VTY
# snmp-agent community read 123abc acl 2000 snmp-agent community write aaa111 acl 2000 ! Vinculando a ACL 2000 às comunidades SNMP "123abc" e "aaa111"
Caso a interface de gerenciamento esteja dentro de uma VRF, ou a origem do acesso inicie de uma vpn-instance (VRF), a ACL deverá fazer referência a isso:
[H3C-acl-basic-2000]rule 1 permit source 172.31.1.0 0.0.0.255 vpn-instance ?
STRING<1-31> VPN-Instance name
Dúvidas? Deixe um comentário…
Até logo!