Nesse vídeo falamos sobre a configuração do serviço DHCP em Roteadores e Switches HP.
Dúvidas deixe um comentário!
Serviços IP
Vídeo: DHCP Relay Agent
A funcionalidade DHCP Relay permite ao Switch L3/Roteador encaminhar as mensagens DHCP em broadcast para determinado servidor além do dominio de broadcast do host, possibilitando assim utilização de um único servidor DHCP para toda a LAN.
Devido ao fato das solicitações de endereço IP ao servidor DHCP ocorrem em broadcast, o roteador configurado com a feature DHCP Relay encaminhará as mensagens ao Servidor DHCP em Unicast.
O servidor DHCP entregará ao cliente o escopo correto baseado na interface IP de origem ( inserida na mensagem DHCP). Para o administrador do servidor DHCP bastará apenas criar os escopos no servidor.
Vídeo: VRRP – Virtual Router Redundancy Protocol
O VRRP (Virtual Router Redundancy Protocol) permite a utilização de um endereço IP virtual em diferentes Switches/Roteadores. O funcionamento do VRRP é bem simples, dois ou mais dispositivos são configurados com o protocolo para troca de mensagens e então, o processo elege um equipamento MASTER e um ou mais como BACKUP.
Em caso de falha do Roteador VRRP Master o Roteador VRRP Backup assumirá rapidamente a função e o processo ocorrerá transparente para os usuários da rede.
Roteadores HP MSR: Exemplo de configuração de NAT estático
Switches 3Com 4500 – Exemplo de configuração com DHCP-Snooping
Autoconfiguração (Autodeploy) com DHCP no Comware
Esses dias pesquisando na web sobre protocolos de autoconfiguração para Roteadores HP achei dois artigos bem legais no site abouthpnetworking.com. O site é tão bacana que tenho as vezes vontade e traduzir todos os posts. 😛
A autoconfiguração (autodeploy) descrita nos 2 artigos do abouthpnetworking utilizará as configurações de fábrica do dispositivo que via DHCP irá procurar por um arquivo de configuração e tentar executa-lo.
Apesar dos textos estarem escritos em inglês vale a pena a consulta:
1 – utilizando as opções do DHCP para autoconfiguração com um servidor TFTP:
http://abouthpnetworking.com/2013/12/31/comware-config-autodeploy/
2- Autoconfiguração com scripts em Python para equipamentos baseados no comware 7
http://abouthpnetworking.com/2015/08/12/comware-7-autodeploy-supports-python-scripts/
Até logo
VRRP: Track baseado no estado de uma interface física
O protocolo VRRP funciona para redundância de Gateway em uma rede, com o objetivo de 2 ou mais roteadores compartilharem o mesmo IP virtual no modo ativo/backup (por padrão).
Para os outros dispositivos da rede, o VRRP permite que o gateway seja visualizado como um único equipamento.
O VRRP é bastante simples em sua função básica: um Roteador é eleito o Master e é responsável pelo encaminhamento do tráfego da rede para os equipamentos que tem aquele o IP Virtual como gateway. O segundo roteador chamado de Backup apenas monitora os pacotes VRRP do barramento. Entretanto, quando o equipamento Master deixar de funcionar, o equipamento Backup assume suas funções como Master.
Os equipamentos configurados com VRRP possuem a sua adminstração de forma individual (Plano de dados e controle separados) e por isso a configuração de rotas e outras features, deverão ser configurada individualmente.
Para um equipamento se eleger como Master é verificado a prioridade (por padrão é 100), vence o roteador que tiver a maior prioridade.
Caso não seja configurada a prioridade do grupo VRRP em um Roteador, o mesmo atribuirá o valor padrão (100) para o equipamento.
Se o endereço IP do Roteador for o mesmo do IP virtual, o equipamento será o MASTER.
Se o Roteador principal falhar, o novo Master será o Roteador Backup com maior prioridade.
VRRP Track
Há também cenários que o roteador Master do VRRP continua ativo, mas não consegue encaminhar os pacotes devido a interface saída (como para a Internet por exemplo) cair. Podemos então fazer o track para o processo VRRP monitorar algum objeto, que pode ser o estado da interface( UP ou down), pingar determinado site, teste de conexão telnet e etc; e dessa forma reduzir a prioridade VRRP baseando-se em uma condição.
No exemplo abaixo, o script demonstrará a redução da prioridade do VRRP do Roteador Master (R2) de forma que quando o link de saída para o Roteador 1 cair, o Roteador Backup (R3) se tornará o Master.
Configuração do VRRP com track
Roteador R2 (Master VRRP)
# track 1 interface GigabitEthernet0/0/3 ! Configurando o track para interface Giga0/0/3 # interface GigabitEthernet0/0/4 ip address 192.168.32.2 255.255.255.0 vrrp vrid 32 virtual-ip 192.168.32.1 ! configurando o grupo VRRP 32 com o IP virtual vrrp vrid 32 priority 115 ! configurando a prioridade do grupo 32 como 110 vrrp vrid 32 track 1 reduced 20 ! configurando o track 1 e em caso de falha, ele reduzirá a ! prioridade do VRRP para 95 #
Roteador R3 (Backup VRRP)
# interface GigabitEthernet0/0/4 ip address 192.168.32.3 255.255.255.0 vrrp vrid 32 virtual-ip 192.168.32.1 #
Validando o Roteador R2 que é o VRRP Master
[R2]display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface GigabitEthernet0/0/4
VRID : 32 Adver Timer : 100
Admin Status : Up State : Master
Config Pri : 115 Running Pri : 115
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 192.168.32.1
Virtual MAC : 0000-5e00-0120
Master IP : 192.168.32.2
VRRP Track Information:
Track Object : 1 State : Positive Pri Reduced : 20
Simulando uma falha…
Quando a interface Giga0/0/3 do Roteador R2 falha, o track do VRRP irá identificar a falha e assim reduzir a prioridade do VRRP do Roteador, tornando dessa forma o R3 como Master
! Log do Roteador R2 após a falha na interface Giga0/0/3 %Jul 7 14:37:35:605 2015 R2 VRRP4/6/VRRP_STATUS_CHANGE: The status of IPv4 virtual router 32 (configured on GigabitEthernet0/0/4) changed from Master to Backup: VRRP packet received.
Output do Roteador R3 após a falha demonstrando a sua eleição como Master
[R3]display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface GigabitEthernet0/0/4
VRID : 32 Adver Timer : 100
Admin Status : Up State : Master
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 192.168.32.1
Virtual MAC : 0000-5e00-0120
Master IP : 192.168.32.3
Por padrão a preempção é ativa nos Roteadores e dessa forma quando a interface Giga 0/0/3 do Roteador R2 voltar ao estado UP, o R2 voltará a ser o Master do VRRP.
Até logo galera.
Switches HPN 10500 – Configurando mapeamento estático multicast para NLB em Switches baseados no Comware
O protocolo NLB da Microsot (Network Load Balancing) tem como objetivo o balanceamento de tráfego entre um grupo de Servidores utilizando endereços MAC em multicast. Os clientes que acessam os serviços de um grupo de Servidores com NLB, enxergam o serviço de forma transparente.
Para trabalhar com NLB o Switch deve encaminhar o tráfego com destino ao serviço NLB para todos os servidores especificados no cluster NLB e cada servidor filtra o tráfego não desejado.
A cooperação entre o Switch e o protocolo NLB é muito importante e dessa forma é importante saber as maneiras que o protcolo NLB trabalha, que são os modos Unicast e Multicast:
Unicast
No modo unicast, NLB substitui o endereço MAC real de cada servidor no cluster para um endereço comum NLB MAC. Quando todos os servidores no cluster têm o mesmo endereço MAC, todos os pacotes enviados para esse endereço são enviados para todos os membros do cluster. No entanto, um problema com esta configuração é quando os servidores cluster NLB estão conectados ao mesmo switch, você não pode ter duas portas no switch com o registro do mesmo endereço MAC. O protocolo NLB resolve este problema mascarando o endereço MAC do cluster. O Switch olha para o endereço MAC de origem no cabeçalho do quadro Ethernet, a fim de saber quais os endereços MAC são associados com suas portas. O NLB cria um endereço MAC falso e atribui esse falso endereço MAC para cada servidor no cluster NLB. O NLB atribui a cada servidor NLB um endereço MAC falso diferente com base na identificação do membro.
Por exemplo, o endereço MAC do cluster NLB é o 00-bf-ac-10-00-01. O NLB no modo unicast leva o endereço MAC do cluster e, para cada membro do cluster, o NLB muda o segundo octeto do membro NLB. Por exemplo, o servidor 1 terá como falso endereço MAC 00-01-ac-10-00-01, o server com o ID 2 tem o falso endereço MAC 00-02-ac-10-00-01, assim por diante. Se um único endereço MAC está registrado em cada porta do switch, os pacotes não são entregues a todos os membros do cluster, em vez disso os pacotes são enviados para as portas de individuais com base no endereço MAC atribuído a essa porta. Para fazer os quadros serem entregues a todos os membros do cluster, o NLB registra um MAC diferente e utiliza nas mensagens ARP em broadcast. Quando o roteador envia uma solicitação ARP para o endereço MAC do endereço IP virtual, a resposta contém no cabeçalho ARP com o endereço MAC real do cluster NLB 00-bf-ac-10-00-01, como por exemplo citado acima e não o endereço MAC falso.
Os clientes então utilizam o endereço MAC no cabeçalho ARP, não o cabeçalho Ethernet para comunicar-se com o servidor. O switch usa o endereço MAC no cabeçalho Ethernet, não o cabeçalho ARP. A questão é quando um cliente envia um pacote para o cluster NLB com endereço MAC de destino como cluster de endereço MAC 00-bf-ac-10-00-01, o switch olha para a tabela MAC para o endereço MAC 00-bf-ac-10-00-01. Como não há porta registrada com o endereço do cluster NLB 00-bf-ac-10-00-01, o quadro é entregue a todas as portas. Isso força o Switch a encaminhar o quadro para toads as portas ocasionando flooding e atrapalhando o desempenho da rede.
Uma solução para mudar o comportamento de flooding é colocar um hub na frente dos membros do cluster NLB e, em seguida,um uplink do hub para uma porta do switch. Isso evita o problema de duas portas de switch registrando o mesmo endereço MAC. Quando o cliente envia pacotes para o endereço MAC do cluster NLB, os pacotes podem ir diretamente para a porta do switch conectado ao hub e, em seguida, para os membros do cluster NLB.
Multicast
Quando você usa o método de multicast, cada servidor do cluster mantém o endereço MAC original do da placa de rede. Além do endereço MAC original, é também atribuído um endereço MAC em multicast, que é compartilhado por todos os servidores de cluster. As requisições de entrada do cliente são enviadas para todos os servidores do cluster usando o endereço MAC em multicast.
No entanto, no modo multicast, a resposta ARP (ARP reply) enviada por um servidor do cluster em resposta a uma requisição ARP, mapeia o endereço IP unicast do cluster para endereços MAC em multicast. Tal mapeamento no ARP reply é rejeitado por alguns roteadores (ou Switch L3). Dessa forma os administradores devem adicionar uma entrada ARP estática no roteador para mapear o Endereço IP do cluster ao seu MAC Address.
Configurando NLB Multicast mode com o mapeamento estático para Comware
- Desabilite a função de validação do ARP.: undo arp check enable
Obs: configure nos Switches L3 e L2 (que os servidores do cluster estejam conectados). - Configure uma entrada estática para o ARP :. arp static ip-address mac-address vlan-id interface-type interface-number .
Obs: Para Switches com função L3 na topologia. - Configure uma entrada multicast MAC estática: mac-address multicast mac-address interface interface-list vlan vlan-id
Obs: dependendo do cenário, configure nos Switches L3 (porta para o trunk com o Switch de acesso) e L2 (porta para os servidores)
Resumo
Modo Unicast : O NLB atribui a cada membro de cluster um endereço MAC comum, que é o endereço MAC do cluster e muda o endereço MAC de origem de cada pacote enviado pelos servidores do cluster . Assim, o switch não pode adicionar o endereço MAC do cluster à sua tabela MAC . Dessa forma o endereço MAC é desconhecido e os pacotes destinados ao Cluster são encaminhados para todas as portas do Switch.
Modo Multicast : O NLB usa um endereço MAC multicast que é um endereço MAC virtual para as máquinas do Cluster.
Configuração
No configuration guide do Switch HPN 10500 há uma configuração mais simples sem o mapeamento da entrada ARP no Switch (o link do arquivo de configuração está nas referências abaixo).
O cluster NLB está na VLAN 10 enquanto os clientes estão na VLAN 20. O Switch fará o roteamento entre VLANs e o encaminhamento do tráfego NLB em modo multicast
Obs: iniciaremos a configuração com todas as portas configuradas nas respectivas VLANs e as máquinas utilizando o Switch como gateway
<Switch> system-view [Switch] interface vlan-interface 10 [Switch-Vlan-interface10] ip address 16.1.1.1 255.255.255.0 [Switch-Vlan-interface10] quit [Switch] [Switch] interface vlan-interface 20 [Switch-Vlan-interface20] ip address 10.0.0.1 255.255.255.0 [Switch-Vlan-interface20] quit # Desabilitando a validação ARP [Switch] undo arp check enable # Configurando a entrada MAC multicast estática [Switch] mac-address multicast 03bf-1001-0164 interface GigabitEthernet 4/0/2 GigabitEthernet 4/0/3 vlan 10
Referências
http://h10032.www1.hp.com/ctg/Manual/c03796252
Obs: Se vocês tiverem algum outro script ou experiência com esse tipo de cenário, por favor deixe um comentário 🙂
Se o link estiver quebrado, também deixe uma mensagem.
Switches HP 5800 – Resumo – DHCP Relay Agent
A feature DHCP Relay permite ao Switch L3 ou Roteador encaminhar as mensagens DHCP em broadcast em unicast para determinado servidor, possibilitando assim utilização de um único servidor DHCP para toda a LAN.
Devido ao fato das solicitações de endereço IP ao servidor DHCP ocorrerem em broadcast, o Switch L3/Roteador configurado com a feature DHCP Relay encaminhará as mensagens ao Servidor DHCP em Unicast ( que está em uma VLAN diferente do host) .
O servidor DHCP entregará ao cliente o escopo correto baseado na interface IP de origem (alterada e inserida no cabeçalho DHCP).
Para o administrador do servidor DHCP bastará apenas criar os escopos no servidor.
Configurando o DHCP Relay
<SwitchA>system-view
[SwitchA] dhcp enable
! Ativando o DHCP
[SwitchA] dhcp relay server-group 1 ip 10.1.1.1
! Adicionando o servidor DHCP 10.1.1.1 dentro do grupo 1.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 10.1.1.254 255.255.255.0
[SwitchA-Vlan-interface2] quit
[SwitchA] interface vlan-interface 40
[SwitchA-Vlan-interface40] ip address 10.2.2.254 255.255.255.0
[SwitchA-Vlan-interface40] dhcp select relay
!Ativando o DHCP relay agent na VLAN-interface 40
[SwitchA-Vlan-interface40] dhcp relay server-select 1
! Correlacionando a VLAN-interface 40 para o grupo DHCP 1
Obs: as configurações de DHCP Relay podem variar dependendo do modelo do Switch. A configuração acima foi executada em um Switch HP modelo 4800.
Até logo
Laboratório para configuração de VRRP no HP Network Simulator
Galera, montei um laboratório de VRRP no Simulador HP para o Comware 7 com o objetivo de validar a sintaxe dos comandos, além de testar o protocolo conforme cenário abaixo..
Para aqueles que não conhecem o VRRP, o protocolo funciona para redundância de Gateway em uma rede, com o objetivo de 2 ou mais roteadores compartilharem o mesmo IP virtual no modo ativo/backup ou ativo/ativo. O padrão do protocolo é o ativo(Master)/backup
Segue a configuração do VRRP nos Roteadores R1 e R2 além da configuração do Switch.
# Switch vlan 2 # interface GigabitEthernet1/0/2 port link-mode bridge port access vlan 2 # interface GigabitEthernet1/0/3 port link-mode bridge port access vlan 2 # Roteador - R1 interface GigabitEthernet 0/0/2 port link-mode route ip add 192.168.1.2 255.255.255.0 vrrp vrid 1 virtual-ip 192.168.1.1 vrrp vrid 1 priority 110 Roteador - R2 interface GigabitEthernet 0/0/2 port link-mode route ip add 192.168.1.3 255.255.255.0 vrrp vrid 1 virtual-ip 192.168.1.1
Os comandos display vrrp e display vrrp verbose executados nos roteadores exibem valiosas informações sobre o status do VRRP.
A configuração da topologia para HP Network Simulator 7.1.50 pode ser baixada aqui.
Os comandos são identicos para a versão 5 do Comware.
Até logo.