Nesse bate-papo com o Micael Mota conversamos sobre carreira, curso técnico, faculdade, cursos extracurriculares e certificação.
A conversa foi sensacional e com várias lições sobre frustração, persistência e dedicação.
Author: Diego Dias
Introdução a VXLAN
Com o crescimento dos Data Centers, da virtualização de máquinas e de serviços de Cloud, surge a necessidade de estender as VLANs através ou além dos DCs.
Para conseguir manter a utilização dos recursos computacionais de maneira eficiente, há uma tendência de utilizar VMs pertencentes a um ambiente compartilhado em inúmeras localizações físicas e estas VMs devem mover-se entre diferentes localizações sob demanda. Mas a movimentação de VMs necessita que a máquina retenha o endereço MAC e IP para que o processo ocorra de maneira transparente para as camadas superiores como a de Aplicação. Este é um grande desafio para o modelo tradicional de Data Center, onde VMs necessitam mover-se dentro de um tradicional domínio de broadcast.
Para suportar a mobilidade de VMs entre PODs em um DC, ou sites, a rede deve ser desenhada como uma grande rede L2, o que acarreta várias limitações que precisam ser reendereçadas:
– Primeiro: Devido a virtualização de servidores, cada máquina virtual (VM) requer um endereço MAC único e um endereço IP. A escalabilidade da tabela de endereços de camada 2 é uma das grandes preocupações em Data Centers virtualizados. Com a virtualização, o número de endereços MAC por porta pode atingir de 50 a 100 VMs por servidor, sobrecarregando assim os Switches ToR (Top-of-Rack) ou da camada de aggregação. Com isso após a tabela MAC dos Switches atingir o limite, uma parte do tráfego começa a ser “inundado” por toda a rede, resultando em um grande fluxo de dados desnecessário.
– Outro ponto importante é a extensão de VLANs pelos Switches do DC que se torna uma tarefa complexa quando planejamos uma implantação fim-a-fim pelo Data Center.
– Com a utilização do STP para fornecer uma topologia livre de loops de camada 2, o protocolo Spanning-Tree desativa links redundantes. Assim, Equal-Cost Multi-Path (ECMP) não é habilitado. No entanto, 0 ECMP é fácil de habilitar em uma rede IP.
VXLAN
O padrão VXLAN (Virtual eXtensible Local Area Network) trabalha em cima da limitação da quantidade de VLANs em um Data Center que é a de 4K VLANs. O Protocolo VXLAN emprega MAC sobre IP/UDP, e permite assim aumentar o número de domínios de Broadcast para 16 milhões.
O VXLAN é uma rede de camada 2 sobreposta em uma rede de camada 3. Cada rede sobreposta é chamada de segmento VXLAN e é identificada por um ID único de 24 bits chamado VNI – VXLAN Network Identifier (Identificador de Rede VXLAN) ou VXLAN ID. Já a identificação de uma máquina virtual é uma combinação do endereço MAC e o VNI.
As Máquinas virtuais em VXLAN diferentes não podem comunicar umas com as outras (sem a utilização de um roteador). O pacote original enviado pela VM na camada 2 é encapsulado em um cabeçalho VXLAN que inclui o VNI associado ao segmento VXLAN que aquela máquina virtual pertence.
Imagem copiada do site da http://blogs.cisco.com/datacenter/cisco-vxlan-innovations-overcoming-ip-multicast-challenges/
O encapsulamento do quadro é feito pelo equipamento que está na extremidade do túnel VXLAN, que é chamado de VTEP (VXLAN Tunnel Endpoint).
O VTEP pode ser tanto ser implementado como um módulo de software em um Switch Virtual, em um Servidor ou em um Switch Top-of-Rack (ToR). Uma interface VTEP é vinculada a um endereço IP único e pode ser considerada equivalente a uma interface loopback.
Quando uma VM quer comunicar com outra VM no mesmo segmento, o VTEP vinculado à VM atribui o encapsulamento adequado da VXLAN, inserindo o cabeçalho VXLAN, sobre o cabeçalho original, colocando o endereço IP de origem do VTEP (como Source IP Address [SIP] nesse novo cabeçalho) e o endereço de destino (Destination IP Address [DIP]) correspondente ao VTEP que a VM de destino reside. Quando o pacote é recebido pelo VTEP de destino, o cabeçalho VXLAN é removido e o pacote interno e é encaminhado para a VM de destino.
O VTEP mantém uma tabela de endereços MAC aprendidos e armazena o endereço IP do túnel para o VTEP remoto. Quadros unicast entre VMs são enviadas diretamente para o endereço unicast L3 do VTEP remoto. Os pacotes multicast e broadcast das VMs são enviados a um grupo IP multicast associado à VNI, o VTEP remoto recebe o quadro multicast, encaminha o pacote a máquina destino (efetuando todos os mapeamentos do VTEP e VM de origem. A VM de destino faz uma resposta ARP normalmente em unicast. O VTEP encapsula o pacote ARP com o padrão VXLAN e encaminha o quadro para o VTEP da VM de origem….
Consequentemente, um segmento VXLAN “estendido” requer:
- Um Grupo IP Multicast associado
- Roteamento Multicast entre os VTEP
Mas como é feita a comunicação com equipamentos não-virtualizados?
Uma das maneiras de permitir a conexão entre VXLAN e uma VLAN tradicional é através de um equipamento (virtual ou não) chamado de VXLAN Gateway.
A funcionalidade do Gateway VXLAN pode ser embutida no VTEP, fazendo o mapeamento para substituição do encapsulamento VXLAN para cabeçalho 802.1Q e assim por diante, tendo a responsabilidade como um ponto de entrada e saída de uma nuvem VXLAN.
Pelas características de funcionamento para o Gateway VXLAN entre o ambiente físico e virtual, encontramos essa função em documentações atribuída como Layer 2 VXLAN Gateway (ou Gateway VXLAN de Camada 2).
Já para o roteamento entre VXLANs essa função é atribuída ao VXLAN Gateway, também chamada de Layer 3 VXLAN Gateway.
Referência
http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2012_2/nvgre/vxlan.html
http://networksbase.blogspot.in/2012/09/vxlan.html
http://codingrelic.geekhold.com/2011/09/care-and-feeding-of-vxlan.html
Data Center Virtualization Fundamentals – Cisco Press – 2013 – Gustavo A.A. Santana
Using TRILL, FabricPath, and VXLAN – Cisco Press 2014 – Sanjay K. H., Shuyam Kapadia,Padmanabhan Krishnan.
Configuração de rota estática IPv6
Durante o recebimento de pacotes para acessar outras Redes externa a LAN para comunicação entre máquinas IPv6, o roteador efetuará uma consulta na sua tabela de roteamento IPv6 para verificar se existe alguma rota para o destino. Se a rota existir o pacote será encaminhado, senão, o pacote será descartado.
A maior parte dos parâmetros de configuração de rotas estáticas em IPv6 são idênticos ao IPv4. Como por exemplo, rota estática padrão, sumarizada e flutuante.
Abaixo a sintaxe de um roteador Cisco IOS:
Router(config)# ipv6 route rede/prefixo [próximo-salto]
O next-hop (ou próximo salto) pode ser identificado por um endereço IPv6, interface de saída ou ambos.
É possível verificar a tabela de roteamento IPv6 com o comando show ipv6 route.
A rota “ipv6 route ::0 0 [próximo-salto]” é uma “rota padrão” e corresponde a qualquer prefixo IPv6 (utilizado quando uma rota específica não é encontrada na tabela de roteamento).
Exemplo de Configuração
Antes de iniciar a configuração de rotas estáticas IPv6, habilite o encaminhamento de pacotes IPv6 configurando ipv6 unicast-routing no modo de configuração global.
Endereço do next-hop como link-local
Caso haja a necessidade de configurar o endereço de next-hop como endereço IPv6 link-local, é necessário configurar a interface de saída, como no exemplo abaixo:
Router(config)#ipv6 route 2001:DB8:222::/64 FastEthernet0/0 FE80::C802:71FF:FEFC:
Testes
Para validar as rotas configuradas resumimos alguns comandos abaixo:
Router# ping ipv6 [endereço do host em IPv6] !Testes de Ping Router# traceroute [endereço do host em IPv6] !Testes de tracerout Router# show ipv6 route !Verificar tabela de roteamento IPv6 Router# show ipv6 interface [interface com endereço IPv6 no roteador] ! Verifique todos os endereços IPv6 da interface ( global, link-local, etc)
Até logo.
DIG
O comando ‘dig’ é uma ferramenta para consultar servidores DNS a fim de obter informações sobre endereços de host, servidores de email (MX), servidores de nomes (NS) e informações relacionadas. Esta ferramenta pode ser usada a partir de qualquer sistema operacional Linux (Unix) ou OS X nativamente. É a melhor ferramenta para diagnosticar e entender rapidamente as respostas do DNS.
Abaixo, fizemos uma pequena compilação para consulta de registros A, NS e MX.
Execute o comando
dig rotadefault.com.br ; <<>> DiG 9.10.3-P4-Debian <<>> rotadefault.com.br ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21507 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;rotadefault.com.br. IN A ;; ANSWER SECTION: rotadefault.com.br. 3600 IN A 191.252.51.69 ;; AUTHORITY SECTION: rotadefault.com.br. 86400 IN NS ns1.locaweb.com.br. rotadefault.com.br. 86400 IN NS ns2.locaweb.com.br. ;; ADDITIONAL SECTION: ns1.locaweb.com.br. 1283 IN A 189.126.108.2 ns2.locaweb.com.br. 83435 IN A 201.76.40.2 ns1.locaweb.com.br. 368 IN AAAA 2804:218:d1::ca5a ns2.locaweb.com.br. 60858 IN AAAA 2804:218:d2::cafe ;; Query time: 127 msec ;; SERVER: 181.213.132.2#53(181.213.132.2) ;; WHEN: Mon Oct 16 10:34:28 -02 2017 ;; MSG SIZE rcvd: 195
Olhando de perto
<<>> DiG 9.10.3-P4-Debian <<>> rotadefault.com.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21507
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
HEADER: exibe o número de versão do comando dig, as opções globais usadas pelo comando dig e algumas informações de cabeçalho adicionais. O status é um ponto importante; neste caso, não houve nenhum erro informado. Este campo pode mostrar um dos seguintes status quando uma consulta é solicitada:
- NOERROR: Tudo ok. A zona está sendo atendida pela autoridade solicitada sem problemas.
- SERVFAIL : O nome que foi consultado existe, mas não há dados ou os dados são invalidos para esse nome na autoridade requerida.
- NXDOMAIN: Non-Existent Domain – O nome em questão não existe e, portanto, não há dados DNS autenticados a serem atendidos. Como no exemplo abaixo:
dig testerotadefault.com.br ; <<>> DiG 9.9.3-P2 <<>> testerotadefault.com.br ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23792 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
- REFUSED: O servidor de nomes se recusa a executar a operação por motivos de política. Por exemplo, um servidor de nomes pode não querer fornecer a informação ao solicitante especifico ou um servidor de nomes pode não desejar executar uma operação específica (por exemplo, transferência de zona) para dados específicos.
Para as flags, do cabeçalho temos as seguintes opções:
QUESTION SECTION: Exibe as questões feitas ao DNS, por exemplo, uma vez que digitamos ‘dig rotadefault.com.br’, indicará nessa sessão a ser consultada para um registro A do site rotadefault.com.br.
;; QUESTION SECTION:
;rotadefault.com.br. IN A
ANSWER SECTION: Exibe a resposta que recebe do DNS. Exibe o registro A record de rotadefault.com.br;
;; ANSWER SECTION:
rotadefault.com.br. 3600 IN A 191.252.51.69
Veja que o TTL está em 3600 segundos, equivalente a uma hora.
AUTHORITY SECTION: Exibe o nome do servidor DNS que tem autoridade para responder essa consulta.
;; AUTHORITY SECTION:
rotadefault.com.br. 86400 IN NS ns1.locaweb.com.br.
rotadefault.com.br. 86400 IN NS ns2.locaweb.com.br.
ADDITIONAL SECTION: Exibe o endereço IP do servidor de nomes listados em AUTHORITY SECTION.
;; ADDITIONAL SECTION:
ns1.locaweb.com.br. 1283 IN A 189.126.108.2
ns2.locaweb.com.br. 83435 IN A 201.76.40.2
ns1.locaweb.com.br. 368 IN AAAA 2804:218:d1::ca5a
ns2.locaweb.com.br. 60858 IN AAAA 2804:218:d2::café
Exibindo apenas ANSWER SECTION da saída do comando ‘dig’
A grande parte das nossas consultas apenas procura a “ANSWER SECTION” do comando dig. Conforme comandos abaixo, podemos omitir algumas saídas:
+nocomments: Não exibe a linha de comentários;
+noauthority: Não exibe a saída autoritativa;
+noadditional : Não exibe ‘additional section’;
+nostats: Não exibe ‘stats section’;
+noanswer: Não exibe answer section.
+noall: Não exibe os resultados mas se utilizado como +noall +answer irá exibir somente as respostas;
+short: Exibe a resposta em um formato mínimo.
dig www.rotadefault.com.br +nocomments ; <<>> DiG 9.9.3-P2 <<>> www.rotadefault.com.br +nocomments ;; global options: +cmd ;rotadefault.com.br. IN A rotadefault.com.br. 1279 IN A 191.252.51.69 dig rotadefault.com.br +noall +answer ; <<>> DiG 9.10.3-P4-Debian <<>> rotadefault.com.br +noall +answer ;; global options: +cmd rotadefault.com.br. 3533 IN A 191.252.51.69 dig rotadefault.com.br +short 191.252.51.69
Consultando registros MX , NS, A, TXT, etc.
A consulta de diferentes registros DNS podem ser executados com os argumentos inseridos na consulta como:
dig uol.com.br MX
dig uol.com.br MX +answer +nocomments ; <<>> DiG 9.10.3-P4-Debian <<>> uol.com.br MX +answer +nocomments ;; global options: +cmd ;uol.com.br. IN MX uol.com.br. 14397 IN MX 10 mx.uol.com.br.
dig uol.com.br NS
dig uol.com.br NS +short eliot.uol.com.br. borges.uol.com.br. charles.uol.com.br.
dig uol.com.br A
dig uol.com.br A +answer +nocomments ; <<>> DiG 9.10.3-P4-Debian <<>> uol.com.br A +answer +nocomments ;; global options: +cmd ;uol.com.br. IN A uol.com.br. 11 IN A 200.221.2.45
dig uol.com.br ANY
dig uol.com.br ANY ; <<>> DiG 9.10.3-P4-Debian <<>> uol.com.br ANY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58271 ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;uol.com.br. IN ANY ;; ANSWER SECTION: uol.com.br. 3554 IN SOA eliot.uol.com.br. root.uol.com.br. 2016038165 7200 3600 432000 900 uol.com.br. 254 IN A 200.147.67.142 uol.com.br. 254 IN A 200.221.2.45 uol.com.br. 254 IN AAAA 2804:49c:3103:401:ffff:ffff:ffff:1 uol.com.br. 17954 IN MX 10 mx.uol.com.br. uol.com.br. 14 IN TXT "DZC=qvK68EJ" uol.com.br. 14 IN TXT "v=spf1 include:_net1.uol.com.br include:_net2.uol.com.br -all" uol.com.br. 3554 IN NS charles.uol.com.br. uol.com.br. 3554 IN NS borges.uol.com.br. uol.com.br. 3554 IN NS eliot.uol.com.br.
Consulta do reverso com -x
dig -x 200.147.67.142 +short 200-147-67-142.static.uol.com.br.
Caso você queira forçar a consulta utilizando um servidor DNS diferente da sua máquina use o @ip_servidor_dns
dig uol.com.br @4.2.2.2 ; <<>> DiG 9.9.3-P2 <<>> uol.com.br @4.2.2.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51526 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;uol.com.br. IN A ;; ANSWER SECTION: uol.com.br. 1 IN A 200.147.67.142
Se vocês tiverem alguma dica, algum comando secreto… especial, deixe nos comentários.
Referências
https://ns1.com/articles/decoding-dig-output
https://mediatemple.net/community/products/dv/204644130/understanding-the-dig-command
Jorge Passos – Minha Jornada ao PMP – Podcast #1
Nesse bate-papo com o Jorge Passos conversamos sobre carreira, Gerenciamento de Projetos e a sua jornada para obter a certificação PMP.
A conversa foi incrível e com várias lições sobre persistência, apoio da empresa, amigos e dedicação.
Rota estática flutuante (floating static route)
Uma rota estática flutuante é uma rota com uma distância administrativa maior do que a estabelecida por padrão em Switches e Roteadores. Por exemplo, no IOS da Cisco as rotas estáticas possuem distância administrativa com o valor 1 e o protocolo OSPF com o valor 110, nesse caso pelo fato da menor distância administrativa ser escolhida quando duas rotas idênticas (com a mesma “rede” e “máscara de rede”) são aprendidas de maneiras distintas pelo roteador, o dispositivo 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 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 (incluindo novamente a rota 192.168.1.0/24 de maneira dinâmica), a rota estática deixará de ser utilizada.
Rt(config)# ip route 192.168.1.0 255.255.255.0 172.17.1.2 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, deixe um comentário.
Cisco IOS: Pseudowires com L2TPv3
O protocolo L2TPv3 (Layer 2 Tunneling Protocol Version 3) é um padrão do IETF que pode ser usado como um protocolo alternativo ao MPLS para encapsulamento de vários protocolos de camada 2 em comunicações de redes IP e MPLS. o L2TPv3 oferece um serviço de pseudo-wire (PW) que simula o tráfego como se fosse um cabo ou fibra apagada entregue entre 2 pontos.
Os Pseudo-wires carregam o quadro Ethernet completo, incluindo o cabeçalho MAC. O quadro é inserido dentro do pacote L2TPv3 e transmitido para o seu roteador Par. O Roteador Par remove o cabeçalho do protocolo L2TPv3 e encaminha o quadro Ethernet intacto. Caso seja necessário o encaminhamento de TAGs 802.1q o mapeamento do VLAN ID deverá ser efetuado para cada VLAN.
Nesse post focaremos o uso do L2TPv3 sobre uma rede IP, para simular uma conexão de “Camada 2” entre dois sites distintos (o domínio de Broadcast será estendido).
Segue abaixo a configuração
Os seguintes passos abaixo deverão ser levados em conta na configuração ao iniciar a configuração do L2TPv3 em um Roteador com IOS Cisco.
- Habilite o CEF
- Use uma interface Loopback para uso da conexão do ponto-a-ponto para o pseudo-wire
- Certifique-se que o roteamento entre os roteadores esteja ok.
- Configure o peudowire class
- Vincule o pseudowire à interface
Validação
R2# show l2tun tunnel l2tp
L2TP Tunnel Information Total tunnels 1 sessions 1
LocID RemID Remote Name State Remote Address Port Sessions L2TP Class/
VPDN Group
54490 54540 R3 est 10.3.3.3 0 1 l2tp_default_cl
Como teste utilizamos a rede 192.168.45.0/24 nos sites R4 e R5
R4#ping 192.168.45.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.45.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 172/197/228 ms
Referências
http://www.shafagh.com/2009/10/ccie-sp-l2tpv3.html
http://tools.ietf.org/html/rfc3931
http://prol2tp.com/documentation.php?page=l2tpv3.html
http://www.networkworld.com/community/node/26272
Cisco IOS: Configurando QinQ
A feature QinQ (802.1Q sobre 802.1Q), conhecido também como Stacked VLAN ou VLAN sobre VLAN, suporta a utilização de duas TAGs 802.1Q no mesmo quadro Ethernet para trafegar uma VLAN dentro de outra VLAN – sem alterar o TAG 802.1Q original.
No caso do QinQ(802.1ad), a visão do o cliente é como se a Operadora tivesse estendido um cabo (como uma fibra apagada ou cabo UTP) entre 2 equipamentos, Switches por exemplo.
Já para a Operadora não importa se o cliente está mandando o tráfego (entre 2 filiais) com TAG ou sem TAG, pois ele adicionará mais uma TAG ao cabeçalho e removerá na outra ponta apenas a ultima TAG inserida.
Em resumo, o tráfego no sentido de entrada na porta configurada com QinQ adicionará uma TAG 802.1Q ao quadro (TAG da Operadora/Provedor), mesmo em casos que já houver a marcação de VLANs, entretanto no sentido de saída, é removido apenas a última TAG acrescentada, sendo mantida a TAG 802.1Q inserida pelo cliente.
Configurando
No Exemplo acima, com Switches Cisco, para o tráfego ser “tunelado” com a TAG adicional, devemos configurar os Switches A e B com uma VLAN para cada cliente , a configuração das interfaces conectadas aos Switches também deverão usar o comando “switchport mode do1q-tunnel”.
Em caso de necessidade de transporte de protocolos da camada enlace como CDP, LACP e STP, é possivel utilizar na interface algum dos comandos abaixo:
l2protocol-tunnel [cdp | stp | vtp]
A configuração dos Switches de cada cliente, nessa topologia, não sofre nenhuma alteração em particular; e a visão de cada cliente será como se os Switches estivessem diretamente conectados.
O “encapsulamento” do QinQ adiciona 4 bytes ao cabeçalho para cada quadro. Os Switches que recebem e encaminham os quadros QinQ devem aumentar o MTU para 1504. O MTU configurado, será verificado utilizando o comando show system mtu. Para aumentar o MTU utilize o commando system mtu 1504, entretanto, essa mudança requer que o Switch seja reiniciado.
Os frames com a TAG 802.1Q possuem o TPID 0x8100, no caso do QinQ (IEEE 802.1ad) o TPID poderá ter outros valores, como 0x9100.
Abraços a todos!
VLAN DESIGN – COMO PLANEJAR MELHOR A SEGMENTAÇÃO DE REDES
Nesse vídeo listamos alguns pontos para um melhor planejamento na segmentação de redes com a utilização de VLANs.
TOPOLOGIA DE REDE CAMPUS – NETWORK DESIGN – 2 E 3 CAMADAS
A integração da rede campus utilizando dados, voz e vídeo torna-se essencial para a alta disponibilidade e impulsionamento dos negócios. Logo, uma rede local (LAN) projetada corretamente é um requisito fundamental, pois uma rede construída de forma hierárquica torna mais fácil o seu gerenciamento, expansão e troubleshooting para detecção de problemas. O design de rede hierárquico envolve a divisão da rede em camadas discretas, facilitando escalabilidade e desempenho.
RotaDefault 