Blog Archives

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://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/psi/swdDetails/?swItem=nw_130365_1&ac.admitted=1403627434906.876444892.199480143

ou em

http://h17007.www1.hp.com/us/en/networking/products/simulator/index.aspx#.U_U1b_ldXrR

HP Network Simulator

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.

iBGP rule HP

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.

iBGP rule and RR HP

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:

Router Reflector cluster id HP

[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.

VRFs Comware

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
!

Inter VRF Routing

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 ;)

Dicionário de Comandos BGP: Comware vs Cisco

Pessoal, segue abaixo a lista de alguns comandos para BGP quando há a necessidade de traduzir de Cisco IOS para HP Comware.

Comware                                                      Cisco IOS
------------                                                 --------------
bgp xxxxx                                                   router bgp xxxxx
router-id x.x.x.x                                           bgp router-id x.x.x.x 
preference 200 200 200 (valor recomendado, não é default)   distance 20 200 200 (default)
undo synchronization                                        no synchronization (not default)
v5: recomendado (não é default)
v7: default
undo summary automatic (default)                            no auto-summary (not default)
log-peer-change                                             bgp log-neighbor-changes
graceful-restart                                            bgp graceful-restart
bgp graceful-restart restart-time 120 (default)             bgp graceful-restart stalepath-time 360 (default)
balance n (default=1)                                       maximum-path (dependente do contexto, default=1)
v5: global BGP config
v7: in ipv4 address family
maximum-path n (n=numero de rotas paralelas)                 maximum-path ibgp m 
ebgp-interface-sensitive (default)                           bgp fast-external-fallover (default)
network x.x.x.x y.y.y.y                                      network x.x.x.x mask y.y.y.y
aggregate x.x.x.x y.y.y.y                                    aggregate-addresss x.x.x.x y.y.y.y
aggregate x.x.x.x y.y.y.y detail-suppressed                  aggregate-addresss x.x.x.x y.y.y.y summary-only
import-route static [route-policy name]                      redistribute static [route-map name]
import-route direct [route-policy name]                      redistribute connected [route-map name]
import-route ospf process_id [route-policy name]             redistribute ospf process_id [route-map name]
default-information originate                                 
reflector cluster-id x.x.x.x                                 bgp cluster-id x.x.x.x
dampening                                                    bgp dampening
peer x.x.x.x as-number AS-number                             neighbor x.x.x.x remote-as AS-number
peer x.x.x.x description blabla                              neighbor x.x.x.x description blabla
peer x.x.x.x connect-interface LoopBack0                     neighbor x.x.x.x update-source Loopback0
peer x.x.x.x next-hop-local                                  neighbor x.x.x.x next-hop-self
peer x.x.x.x advertise-community                             neighbor x.x.x.x send-community
peer x.x.x.x password simple|cipher string                   neighbor x.x.x.x password 7 string
(default)                                                    neighbor x.x.x.x version 4 (no negotiation)
peer x.x.x.x ebgp-max-hop                                    neighbor x.x.x.x ebgp-multihop hop_count
peer x.x.x.x preferred-value default_prefval                 neighbor x.x.x.x weight default_weight
peer x.x.x.x default-route-advertise route-policy name       neighbor x.x.x.x default-originate route-map name
peer x.x.x.x timer keepalive keepalive hold holdtime         neighbor x.x.x.x timers keepalive holdtime minholdtime
peer x.x.x.x route-policy name import | export               neighbor x.x.x.x route-map name in | out
peer x.x.x.x public-as-only                                  neighbor x.x.x.x remove-private-as
peer x.x.x.x fake-as AS-number                               neighbor x.x.x.x local-as no-prepend AS-number replace-as
peer x.x.x.x substitute-as                                  
peer x.x.x.x allow-as-loop AS_occurances                     neighbor x.x.x.x allowas-in AS_occurances  
peer x.x.x.x route-limit prefix_number % reconnect restart_interval 
                                              neighbor x.x.x.x maximum-prefix prefix_number % restart restart_interval
peer x.x.x.x reflect-client                                  neighbor x.x.x.x route-reflector-client
peer x.x.x.x ignore                                          neighbor x.x.x.x shutdown
group group_name internal | external                         neighbor group_name peer-group
peer x.x.x.x group group_name                                neighbor x.x.x.x peer-group group_name

compare-different-as-med                                     bgp always-compare-med
bestroute compare-med                                        bgp deterministic-med
bestroute as-path-neglect                                    bgp bestpath as-path ignore

undo default ipv4-unicast                                    no bgp default ipv4-unicast
(Default)                                                    bgp suppress-inactive
peer x.x.x.x capability-advertise orf ip-prefix both         neighbor x.x.x.x capability orf prefix-list both
peer x.x.x.x capability-advertise route-refresh (default)    neighbor x.x.x.x soft-reconfiguration inbound
peer x.x.x.x bfd                                             neighbor x.x.x.x fall-over bfd
peer x.x.x.x route-update-interval timer                     neighbor x.x.x.x advertisement-interval seconds
(iBGP default=5s, eBGP default=30s)                          iBGP default=0s, eBGP (na VRF) default=0s, eBGP default=0s)
peer x.x.x.x next-hop-local                                  neighbor x.x.x.x next-hop-self
peer x.x.x.x capability-advertise orf ip-prefix both         neighbor x.x.x.x capability orf prefix-list both
Deve ser usado no vpnv4 address-family.                      Deve ser usado no vpnv4 address-family.
peer x.x.x.x advertise-ext-community                         neighbor x.x.x.x send-community extended | both
undo peer x.x.x.x enable                                     no neighbor x.x.x.x activate

Verificando a troca de prefixos												
display bgp routing-table peer x.x.x.x received-routes      show ip bgp neighbors x.x.x.x received-routes
display bgp routing-table peer x.x.x.x advertised-routes    show ip bgp neighbors x.x.x.x advertised-routes

MPBGP
display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x received-routes
show ip bgp vpnv4 vrf vrf-instance-name neighbors x.x.x.x received-routes
display bgp vpnv4 all routing-table peer x.x.x.x received-routes
v5
show ip bgp vpnv4 all neighbors x.x.x.x received-routes

display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x advertised-routes
show ip bgp neighbors x.x.x.x advertised-routes
display bgp vpnv4 all routing-table peer x.x.x.x advertised-routes
show ip bgp

Comandos comparativos para Troubleshooting, Reset e Refresh do BGP : Comware v5 x IOS Cisco

Segue uma lista para rápida comparação de comandos para troubleshooting, reset e refresh para o processo BGP comparando os comandos entre equipamentos 3Com,H3C e HP baseados no Comware e Cisco IOS.

Troubleshooting

Comware                                           IOS

display ip routing-table                          show ip route
display ip routing-table x.x.x.x                  show ip route x.x.x.x
display ip routing-table x.x.x.x longer-match     show ip route x.x.x.x longer-prefixes
display ip routing-table protocol bgp             show ip route bgp
display bgp routing-table                         show ip bgp
display bgp routing-table x.x.x.x                 show ip bgp x.x.x.x
display bgp routing peer                          show ip bgp summary
display bgp routing regular-expression AS-number  show ip bgp regexp AS-number

Reset e Refresh

Comware                                           IOS

reset bgp x.x.x.x            (modo user-view)     clear ip bgp x.x.x.x
refresh bgp x.x.x.x import   (modo user-view)     clear ip bgp x.x.x.x in
                                                  clear ip bgp x.x.x.x soft in

refresh bgp x.x.x.x export                        clear ip bgp x.x.x.x out
                                                  clear ip bgp x.x.x.x soft out

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.

pppoe-topology

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.

PPPoE MSR
Configuração

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 .

pppoe-messages

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

Comware MPLS L3VPN Lab

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!

Roteador MSR 30 –16: Configurando TACACS em uma VPN-Instance (VRF)

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 HPN. 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 teste123
key accounting teste123
user-name-format without-domain
! Encaminhamento do usuário sem o formato @dominio
#
domain acs
authentication 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 local
accounting login hwtacacs-scheme acs local
authentication default hwtacacs-scheme acs local
authorization default hwtacacs-scheme acs
accounting default hwtacacs-scheme acs
authentication super hwtacacs-scheme acs
accounting 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.

Abração