Se estiver usando um computador Windows com uma conexão de rede sem fio, você poderá usar o comando Netsh para gerenciar suas configurações de rede cabeada e sem fio.
Com o netsh é possível visualizar as configurações wi-fi, solucionar problemas e configurar praticamente todos os adaptadores de rede em um computador local ou remoto utilizando esse comando.
Neste tutorial, mostraremos como usar a ferramenta de linha de comando Netsh WLAN para gerenciar conexões sem fio no Windows e descobrir a senha de SSIDs cadastrados, capabilities e mais.
O protocolo OSPF permite a todos roteadores em uma área a visão completa da topologia. O protocolo possibilita assim a decisão do caminho mais curto baseado no custo que é atribuído a cada interface, com o algoritmo Dijkstra. O custo de uma rota é a soma do custos de todas as interfaces de saída para um destino. Por padrão, os roteadores calculam o custo OSPF baseado na fórmula Cost =Reference bandwidth value / Link bandwidth.
Caso o valor da “largura de banda de referência” não seja configurado os roteadores usarão o valor de 100Mb para cálculo. Por exemplo, se a interface for 10Mb, calcularemos 100Mb dividido por 10Mb, então o custo da interface será 10. Já os valores fracionados, serão arredondados para valor inteiro mais próximo e toda velocidade maior que 100Mb será atribuido o custo 1.
Veja no exemplo abaixo:
O custo do Roteador R1 para os Roteadores vizinho é 1.
O mesmo para a interface loopback de R2 (o comware não adiciona o custo para as interfaces loopback)
Se por algum motive houver a necessidade de manipulação do roteamento para a interface Ge0/0/3(Roteador R3) basta aumentar o custo do OSPF na interface Ge0/0/2 para que a interface Ge0/0/3 tenha o menor custo para a rede 2.2.2.2.
Interface GigabitEthernet0/0/2
ospf cost 20
! Alterando o custo da interface para 20
Caso seja necessário alterar a referência para largura de banda utilize o seguinte comando em um roteador HP Comware.
O “bandwidth- reference 100” é o default para 100Mb, onde 100Mb na topologia tem o custo = 1 .
Assim, para ter links 1G com o custo = 1 , o “auto-cost…” deve ser configurado como 1000. Se a referência for links 10G , “auto-cost…” seria 10000 , para 100G, seria 100000 .
Obs: Lembre-se de sempre manter o bandwidth- reference consistente em todos os roteadores para evitar comportamentos inesperados no roteamento.
O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de túneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.
O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como GRE não criptografa as informações que são transmitidas através do túnel, podemos utilizar o GRE em conjunto com IPsec para garantir a integridade das informações.
Abaixo podemos observar a representação de encapsulamento de um pacote IP pelo GRE e a inclusão de um novo cabeçalho.
O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.
Agora você deve estar se perguntando. Em quais situações podemos usar o GRE ? Veja o cenário:
Você em um dia normal como analista de redes e seu gerente de TI te informa que sua empresa acaba de adquirir uma nova filial e eles precisam ter acesso a alguns servidores que estão na rede local do ambiente que você administra. Depois de concluir todo processo de contratação do link e a conectividade com a filial estar finalizada, seu gerente de TI lhe informa que na nova filial utilizará OSPF para declarar as redes locais.
Agora você pensa: como podemos configurar o OSPF nesses roteadores se eles não estão diretamente conectados? Como administrar o processo de roteamento via uma rede gerenciada pela Operadora como por exemplo, com MPLS, que não está emulando um Lan-to-Lan ? É ai que entra o Túnel GRE.
Configuração
Antes de criar o tunnel, certifique-se que a origem e o destino mapeados na Interface Tunnel estejam acessíveis via roteamento. No nosso exemplo, usaremos a Loopback.
Como os roteadores simularão uma conexão ponto-a-ponto, eles irão trocar informações de roteamento através do túnel como se estivessem diretamente conectados.
Por padrão o Comware habilita o protocolo GRE em túneis sem a necessidade de configuração adicional. Caso você precise utilizar uma Interface Tunnel para alguma outra função, segue abaixo algumas possibilidades:
Considerações para a utilização de Tunnel em Switches HP baseados no Comware
A utilização de interface Tunnel em Switches HP baseados no Comware pode ser um pouco mais complicada que em roteadores. Antes de utilizarmos o processo acima é necessário criar uma configuração de “Service Loopback” (em alguns modelos de Switches), vincular à uma porta não utilizada (vazia) e também vincular o serviço ao Tunnel. Segue abaixo os passos:
• Crie um “tunnel-type service loopback group’.
• Adicione uma porta não utilizada ao “Service loopback group”.
# Criando o “Service-loopback” group 1 e especificando o tipo como tunnel.
[SwitchA] service-loopback group 1 type tunnel
# Vinculando a porta Giga 1/0/3 para o “Service-loopback” group 1.
#Desabilite o STP e o LLDP da interface.
[SwitchA] interface GigabitEthernet 1/0/3
[SwitchA-GigabitEthernet1/0/3] undo stp enable
[SwitchA-GigabitEthernet1/0/3] undo lldp enable
[SwitchA-GigabitEthernet1/0/3] port service-loopback group 1
[SwitchA-GigabitEthernet1/0/3] quit
# Aplique o “Service-loopback” group 1 à interface tunnel.
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] service-loopback-group 1
[SwitchA-Tunnel0] quit
# O tunnel ficará up mesmo que a outra ponta não esteja configurada
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.
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 .
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)
Há alguns posts atrás comentamos sobre a diferença da Distância Administrativa para as rotas aprendidas dinâmicamente em Switches e Roteadores dos fabricantes Cisco e HPN (H3C/3Com) e a atenção que deve ser dada em ambientes com Protocolos de Roteamento que possuem Switches e Roteadores de ambos fabricantes
A Distância Administrativa possui apenas função local e não é compartilhada pelo protocolo de roteamento.
Como por exemplo, em um Roteador utilizando o OSPF (como IGP) e o BGP para aprender as “rotas externas”, se uma mesma rota fosse aprendida via OSPF e BGP, o comportamento para escolha do melhor caminho seria diferente em Rotadores Cisco (a distancia administrativa para o OSPF é 110 e o eBGP é 20) e HPN ( o OSPF é 10 e o eBGP é 255). Lembrando que para prefixos iguais aprendido por diferentes protocolos o Roteador escolhe a rota com menor distância administrativa.
Uma coisa bacana do Comware é poder alterar o valor da distância administrativa baseado no processo de Roteamento, por exemplo, se tivermos 2 processos OSPF rodando no Router/Switch é possível alterar a distancia administrativa em um dos processos sem afetar o outro ( muito útil quando se utiliza VRFs [ vpn-instance] em um mesmo roteador) .
Para redes que utilizam MP-BGP, tambem é possível alterar a distância administrativa no address-family do cliente.
Veja o exemplo abaixo para a tabela de roteamento Global (eBGP e iBGP com a distância adminstrativa em 255) e a tabela de roteamento da vpn-instance cliente-A (com o eBGP como 7 e o iBGP como 100).
Para configurar a distancia administrativa dentro processo BGP ou dentro do processo “ipv4-family vpn-instance [nome da vrf]” no BGP use a sintaxe:
[Router-bgp]preference ?
INTEGER<1-255> External preference
!Distancia administrativa para rotas aprendidas via eBGP
[Router-bgp]preference 7 ?
INTEGER<1-255> Internal preference
!Distancia administrativa para rotas aprendidas via iBGP
[Router-bgp]preference 7 100 ?
INTEGER<1-255> Local preference
!Distancia administrativa para rotas aprendidas via iBGP (locais)
[Router-bgp]preference 7 100 9
Para o OSPF utilize o commando preference para alterar a distância administrativa de rotas OSPF e OSPF ASE:
[Router-ospf-1]preference ?
INTEGER<1-255> Preference value
ase AS external link states
[Router-ospf-1]preference ase ?
INTEGER<1-255> Preference value
Segue abaixo mais um post cedido pelo Paulo Roque. A dica é bastante útil para cenários com utilização de VRFs [(vpn-instance) que permitem a segmentação da tabela de roteamento de um Switch/Roteador] e que após a finalização dos testes ou remoção da configuração de um cliente, precisa ser removida da configuração do dispositivo…
Srs,
É possível apagar toda a config (IPs, rotas, address-family e VRRP) referente a uma vpn-instance no HPN com apenas um comando. Basta apagar a própria VRF. Pode ser útil na hora de elaborar o back-out (plano de volta) para remover as configurações. Isto também vale para o IOS (Cisco). Veja o exemplo.
O Andre Nunes encaminhou um e-mail muito bacana para acesso aos Config Guide do Roteador Serie A8800 da HP / H3C. O Material foi criado pelo próprio fabricante possui bastante coisa interessante mas infelizmente está inglês…
Pessoal,
Não sei se todos vocês chegaram a verificar no site da H3C, mas tem alguns guias com os comandos dos HPN.
Existe alguns guides de acordo com o tipo de configuração. No link abaixo podem ser os feitos download em .pdf:
A tabela de roteamento dos Switches L3 e Roteadores, insere os destinos aprendidos manualmente (rotas estáticas ou redes diretamente conectadas) ou dinamicamente (aprendidos via protocolo de roteamento dinâmico).
Para os casos de uma destino ser aprendido de diferentes formas, como por exemplo, o prefixo 192.168.1.0/24 ser aprendido via RIP e OSPF, o Roteador dará preferência para a rota com Distância Administrativa de menor valor, no caso, o destino aprendido via OSPF terá preferência pelo valor 10 em detrimento do protocolo RIP com o valor 100 (nesse exemplo a rota eo gateway da rede que será inserido na tabela de roteamento será o aprendido via OSPF).Perceba que as rotas diretamente conectadas possuem a prioridade 0 (zero) e serão roteadas internamente pelo dispositivo.
A Distância Administrativa possui apenas função local e não é compartilhada pelo protocolo de roteamento. Um detalhe importante a ser percebido é a diferença com os valores atribuídos para a distancia administrativa para Roteadores Cisco. Em todo caso para evitar problemas em cenários com mais de 1 protocolo de roteamento, altere a métrica em um dos dois dispositivos.
