AULA 08 - REDES MÃO NA MASSA 2.0 - SPANNING TREE PROTOCOL E ETHERCHANNEL

Então, olá, seja bem-vindo aqui à aula oito do curso de redes M na Massa. Na aula de hoje, a gente vai falar um pouquinho, na verdade vai falar muito de loop de câmara dois, do protocolo span tre na teoria e na prática. E galera, seguinte, para quem não sabe, eu tenho uma plataforma de cursos pagos, eu tenho uma empresa de treinamento e ela tá completando 9 anos agora em maio. Tem curso de redes para quem tá começando, para quem já tá aí na área há algum tempo, a gente tem curso de CCNA, CCNP, OSPF, BGP,

MPLS, a gente tem curso de Fire Fortgate. Em breve a gente vai ter novos cursos lá na plataforma também. E para comemorar esse nosso aniversário, vai rolar promoção dia 19 de maio. 50% de desconto em todos os cursos, em todas as modalidades, seja assinatura ou curso com acesso vitalício. Então fiquem atento. Além do desconto, a gente vai ter também uma condição exclusiva para quem comprar dia 19 de maio e somente no dia 19 de maio. Essa outra condição exclusiva é segredo, eu vou revelar só dia 19. Então fiquem atento aí. Eu vou informar mais ainda

durante essa semana. E antes de começar a aula de hoje, os recados de sempre. Se você ainda não é inscrito, faça sua inscrição aqui no canal agora mesmo. Isso ajuda demais o nosso canal. Já deixa o seu like, habilite as notificações clicando no sininho aqui ao lado, assim você não perde nenhuma aula. O link da lista de presença vai tá aqui na descrição, assim como o link do PDF de rico com os slides, topologia e as configurações, os comandos utilizados aqui na aula de hoje. A gente tem também o grupo silencioso do Zap. Entre nele

para receber as informações do curso em primeira mão e também as promoções e também as promoções. O link também tá na descrição. Então bora começar mais uma vez com a parte teórica e depois o nosso LAB aí. Vamos lá. Então pessoal, essa aqui é a topologia que a gente deixou ela pronta, né? Na última aula a gente tá andando bem aqui no nosso cenário, então tecnicamente a gente já tem conexão aqui com o nosso dispositivo aqui que tá na internet, né? na verdade nossa loopback aqui. Então, a gente já consegue da nossa rede interna aqui

chegar aqui na internet. Só que a gente tem um design aqui de rede, uma arquitetura de rede aqui, que ela não é tolerante a falhas. Imagine o seguinte, imagine aqui que o nosso CORUM ele caia, né? Ele tem alguma queda de energia ali ou equipamento falhe, todo mundo aqui vai est isolado, né? Não vai conseguir chegar na internet. Então tá faltando a gente começar a pensar aqui na nossa rede em redundância, né? que é simplesmente a gente ter aqui contingência, né? A gente ter aqui equipamentos duplicados para caso algum caia aqui, a gente tem outro

e a gente começa a pensar em redundância aqui nessa camada porque aqui no acesso é complicado, né? Eu não preciso ter aqui, esse aqui não são equipamentos críticos, né? Tirando servidores aqui, que a gente pode pensar depois numa rede de produção, em algum algo desse tipo, mas esses equipamentos de acesso aqui, normalmente eles terão uma plaquinha de rede e farão ligação com o nosso suitch de acesso aqui. Já aqui nessa camada que a gente chama de distribuição, que vai fazer o roteamento entre as velans, a gente começa a pensar em redundância porque é um equipamento

crítico, né? Todos os suitches aqui, os nossos suitches de acesso vão ligar nessa camada aqui do nosso da nossa arquitetura aqui, do nosso layout de rede, né? nosso design de rede aqui. Então, a gente começa a pensar aqui e a gente vai adicionar agora um equipamento redundante. Então, essa esse equipamento em vermelho aqui que é o nosso core 2 e essas conexões vermelhas aqui é o que a gente vai adicionar na aula de hoje. A gente vai começar a pensar numa redundância aqui primeiro de camada dois. Então, nessa aula, a gente vai falar de camada

dois mais uma vez. A gente vai ter aqui conexões de camada dois. Lembra que isso aqui são as portas tronco, né? Então, a gente vai ter essa redundância aqui de camada dois. E na aula que vem a gente vai falar de redundância de camada três, vai falar de roteamento. Antes de falar de roteamento, porque não vou, por que que eu não vou colocar tudo que é redundância numa aula só? Porque eu acho que vai ficar muito grande. E aqui a gente tem que entender um cenário de loop de camada dois. A gente vai falar de

broadcast storm, a gente vai falar de span tre na aula de hoje. Então vamos aqui pra aula teórica e já começar a entender o que que é um loop de câmara dois. Se a gente pegar o nosso cenário anterior ali e começar a dividir ele em blocos aqui, se a gente pegar aqui o nosso AC1, como é que vai ficar a ligação dele com os dois cores? Ele vai ter uma portinha aqui com o core um e outra portinha aqui com o core 2. E o core 2 terá aqui duas portas ligadas aqui com o

core um. Então vocês concordam comigo que eu tenho aqui agora uma redundância. Se esse link cair, eu tenho o link para cá. Se essa caixa cair, eu tenho o link para cá. Se essa caixa aqui, que é o core 2, cair, eu tenho o link por aqui. Então a gente começa a ter um ambiente aqui com múltiplos caminhos. O problema no nosso cenário é que esses caminhos aqui, ó, eles são puramente Ler do Aqui não tem IP configurado, né? A gente tem aqui as portas tronco. Aqui vão ser encaminhados o quê? Os frames. Frame é

o quê? Camada dois. E a gente tem um problema na camada dois, é que quando a gente fala de frame, ele não tem um esquema de inibição de loop. Que que é um loop? A gente vai falar mais sobre isso, mas repare que aqui, ó, eu posso, se eu tiver um frame broadcast sendo gerado aqui pelo PC12, por exemplo, esse frame vai entrar aqui, vai pro core 1, vai pro core 2, vai pro core 1, depois volta pro AC1 e aí depois vai, já que é um broadcast, ele vai ficar aqui em loop, né? Pode

ir por essa porta aqui, vai por essa porta aqui também, vai por essa porta aqui e ele vai ficar indefinidamente aqui em loop. Eu vou explicar com mais detalhes daqui a pouco. Então, a gente tem aqui caminhos redundantes. Aqui a gente tem esse loop aqui que eu tô chamando de loop 1, que é core 1, core 2 e1. A gente tem também o nosso que eu tô chamando aqui de loop 2. A gente tem aqui core 1, core 2 e AC2. Repare que a gente tem aqui um outro loop aqui, ó. Tem essa voltinha completa

aqui. Eu tenho aqui o que eu tô chamando de loop 3, que é o switch do DC, core 2, core 1, outro loop aqui. E a gente tem aqui um outro loop que não é tão óbvio assim, que é entre core 1 e core 2. Já que eu tô usando aqui portas duplicadas aqui, ó, tenho dois caminhos para chegar aqui. A gente tá usando portas redundantes aqui, ó. Repare que eu tenho um loopzinho aqui dentro. Dentro dessa própria porta, eu tenho um cenário assim, ó. Aqui eu tenho um loop, né, que são caminhos redundantes aqui

entre dois equipamentos iguais aqui. Então, a gente tem esses quatro loops. E por que que isso é ruim? Porque a gente precisa de um protocolo chamado span tre. É um protocolo que já vem padrão dos equipamentos e a gente vai explicar a função dele aqui. Então repare que a gente tem aquele cenário de um loop aqui. Eu tenho aqui sutchit 1, sutchit 2 e sut 3. Vocês podem ver que é a mesma ideia. Esse exemplo didático que eu tô dando aqui é a mesma ideia que a gente tem no nosso cenário prático que a gente

vai ver no packet tracer. É a mesma coisa, só que eu tô dando aqui de forma mais didática pra gente começar a entender. Então a gente tem aqui o computadorzinho aqui com a tartaruguinha, com o nosso galinho aqui e o nosso golfinho para fim didáticos. para ficar mais simples. Vamos supor que o golfinho tá gerando um frame aqui, broadcast, ó, destino desse frame FF FF, ou seja, ele quer conversar com todo mundo da mesma rede. E vamos para fins didáticos, todo mundo aqui tá na mesma vela, todo mundo tá no mesmo domínio de broadcast, então

todo mundo vai receber uma cópia desse frame. Esse frame ele chegou aqui, né, no switch 3, o que que ele vai fazer? O Switch 3 analisa o Mac de destino para tomar decisão de qual porta que ele vai encaminhar aquele frame. Como é um frame broadcast, ele tem que encaminhar uma cópia desse frame para todas as portas ativas, exceto o que ele recebeu. Ele recebeu na 13. Ele tem a porta G0/1 ativa e a G0/2. Então ele vai gerar duas cópias desse frame. Lembrando, né? É um Fame Broadcast. Essas duas cópias elas vão chegar onde?

A primeira cópia vai chegar aqui no switch um e a segunda cópia vai chegar aqui no sutch 2. Qual que é o destino desse frame? Broadcash. Continua sendo broadcast. Que que o switch um vai fazer? Vai gerar duas cópias desse frame. Vai mandar uma cópiazinha aqui pra tartaruga e vai mandar outra cópia para quem? Pro switch 2 broadcast. Esse frame que chegou aqui no sut via porta G0/1, que que o Switch 2 vai fazer? Vai gerar duas cópias desse frame, uma para cá e uma para cá, uma para cá e outra para cá. Então, repare

que a tartaruga e o galinho já receberam uma cópia do frame que o golfinho mandou. Então, todos os dispositivos finais aqui já receberam uma cópia desse frame. Parou por aí? Não. Por quê? Porque ainda a gente tem essa cópia que foi mandada pro outro sutch a gente tem essa outra cópia aqui que foi mandada para esse switch aqui. Que que vai acontecer quanto esses suits aqui receberem essa cópia desse frame. Repare que é o mesmo frame, galera. Chegou aqui, ó. A cópia cinco chegou aqui e a cópia três chegou aqui. Que que ele vai fazer?

Vai gerar o quê? Duas cópias desse frame. Uma vai para cá, uma vai para cá e desse lado aqui, uma vai para cá e uma vai para cá. para cá, para cá, para cá e para cá. Então, gerou uma cópia aqui. Uma cópia vai para baixo, outra cópia vai para baixo, outra cópia vai aqui pro galinho. Então, chegou aqui agora o nosso galinho aqui, ó, tem duas cópias do mesmo frame, uma que ele recebeu anteriormente e uma que ele recebeu agora. A nossa tartaruga aqui tem duas cópias do mesmo frame e a gente ainda tem

aquela aquele frame que ele mandou para baixo aqui, ó, chegando no sutch 3 e aquele frame que ele mandou para baixo aqui, chegando aqui no sutch 3 também. Então, o Switch 3 tá recebendo mais duas cópias do mesmo frame. Que que ele vai fazer quando ele recebeu essa cópia desse frame aqui? Ele vai gerar uma cópia para mandar pra porta fest 0/3 e vai mandar uma cópia para G0/2. Esse frame que ele recebeu aqui, ele vai mandar uma cópia pra G, PR F0/13 e vai mandar uma cópia pra G0/1. Então, olha só, cópia para lá.

Repare que o nosso golfinho recebeu cópias do frame que ele enviou. E não é para isso acontecer. Ele tá recebendo cópias do próprio frame. Isso é um indício que esse frame tá em loop aqui. E por que que isso é ruim? Porque isso aqui nunca vai parar. A gente vai ter cópias aqui até o sutch travar. Isso é um loop de camada dois. A gente vai ter cópias aqui até esse equipamento travar. Então, cópia aqui, cópia aqui, loop de camada dois. Por que que isso acontece? Porque no frame, no framezinho lá, no cabeçalho do frame,

no header do frame que a gente fala, não existe um campo chamado TTL, que é o tempo de vida, né? Ele não vai, a cada salto que ele vai fazendo, ele não vai decrementando, né, um TTL. Igual na camada três, no pacote, tem um campo chamado TTL, que ele tem um valor ali de 255, né, o valor padrão. E a cada roteador que ele atravessa, esse campo ele é decrementado, 254, 253. Quando ele chega a zero, quando ele vai ser colocado ali zero, o roteador descarta esse pacote. Só que no frame, na camada dois, não

existe isso. Então o que que vai acontecer? Vai ter cópias aqui multiplicadas, multiplicadas, multiplicadas, multiplicadas até o sutch ficar com 99% de CPU e travar. Então você não vai conseguir mais alcançar os equipamentos, a rede vai ficar muito lenta e a rede vai parar. Problema, né, que a gente chama de broadcast storm, que é tempestade de broadcast. Isso aqui é uma tempestade, ela vai só aumentando aqui o encaminhamento de um frame repetidamente nos mesmos links, consumindo partes significativas da capacidade dos links. MAC Table Stability, atualização contínua da tabela MAC de um switch com entradas incorretas

em reação a frames em loop, resultando no envio de frames para os locais errados. Multiple frame transmission, um efeito colateral dos frames em loop, nos quais várias cóbias de um frame são entregues ao host pretendido, confundindo o host. E que que o Spanit faz, né? Ele simplesmente vai bloquear um desses caminhos. Ele vai escolher um desses caminhos redundantes e vai bloquear. Ele faz isso de forma automática. Todo dispositivo de camada dois já vem com span tre habilitado por padrão, ou pelo menos deveria. E ele funciona meio que plugin play. O problema é que se você

deixar ele plugin play, você pode ter um comportamento subótimo da rede. A gente pode ter uma escolha de um link bloqueado que não é o ideal. Então, se a gente pegar aqui que ele bloqueou esse link aqui, é como se esse link aqui não existisse. Que que vai acontecer? O golfinho tá mandando um frame broadcast. Ele vai mandar uma cópia desse frame pra porta G0/1, já que essa G0/2 é como se ela não existisse, que ela tá bloqueada. Chegou no sut, ele vai criar duas cópias desse frame. Vai mandar uma aqui pra tartaruga e uma

aqui pro galinho. Chegou aqui no galinho, ele vai mandar uma cópia desse frame, na verdade pro galinho, não, né? pro sutch 2. Chegou no sut, ele vai mandar uma cópia desse frame pro galinho e ele deveria mandar uma uma cópia desse frame, né, aqui para baixo. Só que como essa porta tá bloqueada, esse frame nunca vai chegar aqui no switch 3. Então a gente não tem um loop, né, a gente não tem um circuito fechado mais pra rede, né, é como se esse caminho não existisse. E como é que é feito, né, essa escolha de

qual porta será bloqueada? Existe um protocolo chamado Spanit e ele trabalha, né, fazendo uma eleição. Primeiro ele vai eleger qual é o suit mais importante da sua rede. Essa eleição é feita de forma automática, baseada em alguns parâmetros que já vem configurados no sutar esses parâmetros para eleger o switch root que a gente queira. Então, olha só, eu coloquei o Harry Potter aqui, o nosso escolhido, né, que vai ser o nosso sut aqui. Então, a gente tem aqui o mesmo cenário de um loop clássico com três suits aqui, suit 1, suitch 2, su 3. No

início da eleição não tem um root, né? Então, todo mundo se considera o rout, então todo mundo aqui é candidato. Como é que vai acontecer? Eles vão mandar o que a gente chama de BPDUs, bridge protocolt units. São mensagenzinhas de controle ali entre eles. Eles vão conversar entre si. E aqui ele manda o seguinte, né? O switch tá mandando, o sutch um tá mandando para todos os seus vizinhos aqui, custo do caminho para chegar no sutch root é igual a custo zero. Já que ele se considera o root, o custo para chegar no próprio root

é zero. Se eu sou o root, o custo para chegar em mim mesmo é zero. Todo suitch vai ter um negócio chamado bridge ID, que é esse valorzinho aqui, ó, 32 769 e um endereço MAC qualquer. Aqui eu parafim didáticos, né? Eu tô colocando tudo zero final um. Então o brid é um conjunto de priority mais esse endereço MAC aqui, que é um endereço MAC que representa o sutch um, não é uma porta específica, é o próprio sutch, o sutch inteiro. E aqui o root bridge ID é ele mesmo. Então olha só, esses dois valores

aqui são iguais porque ele tá se considerando o Harry Potter aqui da rede, o root da rede. Todo mundo vai fazer isso, só que repare que cada um dos sutits tem um brid diferente. O valor da parit tá igual nos dois, porque esse valor é o valor padrão 32769, mas o endereço MAC ele nunca vai ser igual. 001 aqui 02 e aqui no sutch 3 é o final 003 priority igual. Então todo mundo tá falando um com outro ali e mandando essas informações. Ou seja, todo mundo aqui tá se considerando root e eles vão comparar

essas informações dele com a informação que ele recebeu do vizinho ali. Então switch um será eleito o switch root da rede, pois tem um menor bridge ID. Então, se a gente pegar aqui, ó, o 32769 aqui, ele vai ser o switch root. Por quê? Porque se a gente comparar aqui, ó, o valor do breed ID aqui, a gente tem aqui, ele é composto, né, por dois campos. O primeiro valor é o valor da priority, ele tem 2 bytes. E o segundo valor aqui, o segundo campo de 6 bytes aqui, é o system ID. É o

endereço MAC do Switch inteiro, não é? É um Mac especial que representa o equipamento. Então, o Span Tree e o Rapt Span 3, que é uma versão mais rápida do Spanit 3, define mensagens chamadas BPDUS. bridge protocol data units, também chamadas BPDUs de configuração para trocar informações entre si. Mas por que que esse cara aqui foi escolhido root? Porque ele tem o menor bridge ID. Se eu pegar o bridge ID dele aqui, ó, é 32 769. Aí tem aqui 001. Então ele começa a comparar. Primeira coisa que ele vai comparar é o priority. Quem tiver

a menor priority vai ganhar. Só que todo mundo tem a priority igual. 32769. 32769. 32769, porque tá o padrão que vem de fábrica, ninguém alterou isso aqui. Aí o segundo campo que ele vai olhar é o valor do endereço MAC. Aqui ó, vocês tm a ID, o do sutch 1 é o final um, o do sutch 2 é o final do e do sut. Quem tem um menor aqui? 1, dois ou três? O um ganhou, né? Matemática avançada aqui. O um é o menor. Só por isso ele foi escolhido aqui o melhor suitch da rede,

né? Simplesmente porque ele tem o menor endereço MAC. Um ponto de atenção aqui que esse endereço MAC aqui os fabricantes dão, né, de forma sequencial. Então o primeiro equipamento que ele produziu lá, ele vai ter o MAC address, sei lá, final um. O segundo que ele que ele produziu vai ter o final dois. Esse aqui para fins didáticos, viu, galera? Não é bem assim que funciona, mas a ideia é o quê? o equipamento mais antigo da sua rede, provavelmente ele terá o menor endereço MAC, porque ele foi produzido primeiro. E normalmente o o equipamento mais

antigo da sua rede não é o melhor, ele é o mais antigo, ele é o mais velho com tecnologias mais legadas, mais antigas. Então se você deixar o seu spanitri padrão, provavelmente ele vai escolher o seu pior sutch para ser o rot. E a gente vai entender porque isso é um problema, né? Nesse caso aqui, o nosso sut foi escolhido aqui o nosso root. Depois da escolha do root, né? ele vai escolher o melhor caminho para chegar no sutch root. Então, do ponto de vista dos sutits que não são root, ele vai, eles vão escolher

o melhor caminho para chegar no root. Então, do ponto de vista aqui do sutch 3, qual é o melhor caminho para ele chegar no root? Repare que eles têm dois caminhos, um por aqui e um por aqui. O switch 3 tem um por aqui e um por aqui. Repare que cada enlacezinho desse aqui, ó, tem um valor de custo. Para fins didáticos, eu tô falando aqui que o custo desse enlace aqui, ó, é quatro. O custo desse aqui é quatro e o custo desse aqui é cinco para fim de dados. Como é que é calculado

esse custo? O span tre faz isso de forma automática. Existe uma tabelinha aí, mas de forma bem direta. Quanto mais rápido for aquela porta, menos custosa será aquele caminho. Então, quanto mais rápido for aquela porta, menos custo ela vai ter. Então, quanto mais custoso for aquele caminho, pior vai ser vai ser aquele caminho. Pensa no seguinte, você vai ter mais custo para chegar numa determinada cidade, passando por uma estrada de terra ou passando por uma estrada de asfalto. Uma estrada de asfalto é uma estrada melhor, ela vai ter ali condições melhor pro seu carro passar,

enquanto a estrada de terra ela pode estragar ali o seu carro, né, se tiver muito buraco e tudo mais. Então tem esses parâmetros que são vão ser verificados aqui no SP 3. Ele simplesmente considera que quanto mais rápida for aquela porta, uma porta giga, vai ser melhor que uma porta fash Ethernet. Uma porta de 1 GB vai ser melhor que uma uma porta de 100 M. E ele dá um valor, né, ele dá um custo, né, para esse cara. Então se eu pegar aqui do ponto de vista, né, doos outros sutches, né, repare que o

meu sutch um foi o root. Do ponto de vista do sutch 2, ele tem dois caminhos. via sutch 3, que vai ter o custo aqui de 4 + 5, que vai ser o quê? 9. E via sutch 1, que vai ter o custo de quê? De quatro. Então, qual porta que ele vai escolher sendo a melhor porta para chegar no root? Ele vai escolher a G0/2. Essa porta aqui vai ser o que a gente chama de root por. A porta G0/2 vai ser a melhor porta para chegar no root. Então ele escolheu aqui, ó, custo

do caminho para chegar no root quatro. Esse aqui é o meu brid e o root brid, que é o ID do brid do switch root do Harry Potter aqui, é o do Switch um. Então repare que esses campos aqui agora estão diferentes, né? O bridge ID dele é o próprio dele, né? Que tá configura, que vem de fábrica ali. E o root brid é o do sutch root. Então ele sabe que o sutch root é esse camaradinho aqui, ó. Se a gente pegar agora aqui o nosso sutch 3, ele tem dois caminhos também, ele tem

o caminho por aqui e o caminho por aqui. Via suitchit 2 vai ser 4 + 4 vai ter o quê? Matemática avançada, custo oito. Via suit 1 vai ter o custo de quê? O custo de cinco. Então qual porta que ele vai escolher para ser a sua root porte? O melhor caminho para chegar no root vai ser via G0/1. Então o custo do caminho para chegar no suit root é cinco. Então essa vai ser a minha root porte. Por que que ele escolhe aqui e eleve portas routes aqui? Porque essas portas routes elas nunca poderão

ser bloqueadas aqui, porque é a melhor porta, o melhor caminho para eu chegar no root. Ele vai escolher a porta que será bloqueada baseada na topologia para chegar no sutiot. Então ele nunca bloqueia portas do próprio sutiot. Ele nunca vai bloquear portas do próprio sutar portas que são o melhor caminho para chegar no suit root. Repare que ele já escolheu as suas portas root. Então ficou o quê? ficou só esse caminho aqui, ó. Então, a porta root é a porta em um sutch que não seja root, com menor custo para chegar no sut root, apenas

uma porta root em cada sutch, só tem apenas um melhor caminho para chegar no sut root. Então, repara que essas portas root só existem no sutchot. Esse switch aqui, que é o root sutch aqui, ó, que é o nosso suitch Harry Potter aqui, ele não tem porta root. Por qu, cara? Ele já é o root. Qual é a melhor porta para chegar nele mesmo? Não tem. Ele já é o root, então ele não tem root porte. A gente vai analisar agora esse enlace aqui. Qual porta será bloqueada? Será uma porta desse enlace que sobrou. As

portas aqui do suit root, elas são portas que a gente chama portas designadas. Então, basicamente é uma porta que não é uma porta root, mas também encaminha e recebe frames e bpduss. Um suitch root não tem root porte, pois ele já é o root. Então essas duas portas aqui do such root são portas que a gente chama de portas designadas. E nesse caminho aqui a gente vai escolher qual porta será a bloqueada. Como é que ele vai fazer essa análise? A eleição do spanit sempre vai ser baseada aqui no brid. Então ele vai comparar aqui

o brid aqui do sutch 2 com o brid do sutch 3. Ele vai comparar esses dois caras aqui. Switch 2 brid é 32 769 priority e o system ID aqui final 2 do switch 3 32 769 e final 3. Quem é o melhor aqui comparando esses dois? O melhor vai ser aquele que tem o menor priority. Só que a priority aqui elas são iguais. Então ele vai olhar agora o system ID. Quem tem o menor system ID? Quem tem o menor Sista ID é o Switch 2. Então o Switch 2 não terá a porta bloqueada.

Essa porta aqui dele será uma porta designada. Quem terá a porta bloqueada é o Switch 3. Então essa porta aqui tá bloqueada. Mas por que que ele não bloqueia as duas? Ele não bloqueia as duas pelo seguinte, porque vai que essa porta aqui, ó, do G0/1 caia. Ele tem que receber informações aqui, ó, do vizinho, para saber que existe um novo caminho aqui, ó. Se essas duas portas estão bloqueadas, ninguém vai avisar ninguém que essa porta caiu. Essas portas que estão em estado de bloqueio para evitar loops e não participam do encaminhamento de frames. Elas

apenas ouvem em processo BPDUs. Que que são os BPDUs? São aqueles frames de controle, né? Não são frames de dados. Então não vai ter um loop aqui porque os frames de dados eles não são processados aqui. Se a gente pegar o nosso nossa topologia, nossa árvore panitria, agora a rede entende que aquele caminho não existe mais porque esse caminho aqui tá bloqueado. Então a gente tem o quê? uma loop free topology, uma topologia livre de loop. Então é como se o caminho entre suitch 2 e suit 3 não existisse. A gente tem aqui os estados

das portas, né, para ela entrar em modo de blocking ali ou não. Então primeiro estado, né, a gente tem aqui o estado de bloqueio, né, não participa do encaminhamento de frames e também descarta os frames recebidos. A porta apenas escuta e processa as BPDUs em suas interfaces. Após 20 segundos, a porta do suitch muda do estado de bloqueio para o estado de listen. Após o estado de bloqueio, uma porta root ou uma porta designada passará para um estado de escuta, listening. Todas as outras portas permanecerão em estado de bloqueio. A porta em escuta aqui, né,

não participa do encaminhamento de frames e também descarta os frames recebidos. Recebe os BPDUs do segmento de rede. Após 15 segundos, a porta passa para o estado de listing para learning. Então, a gente tem aqui 20 segundos, depois 15 segundos. Aí a gente tem aqui o estado de learning. A porta recebe e processa VPDUs. Ela também começa a processar frames do usuário e atualizar a tabela Mac, mas os frames não são encaminhados ao destino. Após 15 segundos, a porta passa pro estado de learning para o estado de forward. Então aqui a gente tem mais 15

segundos. A porta no estado de forward aqui de encaminhamento, quer dizer que ela recebe, encaminha frames de controle e em frames de dados, né? A porta processará BPDUs, atualizará sua tabela MAC de endereço com os frames recebidos e encaminhará o tráfego do usuário através da porta. O estado de encaminhamento é o estado normal. A gente tem aqui a porta em modo disable, que simplesmente não participa do encaminhamento de quadros ou da operação do span tre porque é considerada não operacional. Uma porta que tá não tá ligada, né? Tá desligada ali, tá sem cabo, né? Táado

down ali. Uma porta que não participa do processo span 3. Só que repare, né? Vamos supor que a nossa rede tá assim, ela tá com uma looperology, tá tudo funcionando. Vamos supor que essa porta aqui caia. O span tre vai ter que restabelecer esse link aqui, ó. Quanto tempo ele vai demorar para restabelecer esse link? Ele vai ter que sair do modo de blocking aqui, ó, até chegar no modo de for. Só que repare que cada um desses estados aqui, ó, demora um tempo. Aqui tá demorando, né, 50 segundos. Então é quase 1 minuto de

rede parada para ele chegar nesse estado aqui de novo, né? Esse aqui é o span tre clássico, STP clássico. Hoje em dia, né? Sit já vem com rapid span tre, que ele é mais rápido que isso aqui, mas se você entende o span tre clássico, todos os outros são de forma tranquila, né? Basicamente os outros funcionam da mesma maneira, só que com otimizações nesses temporizadores aqui e estados diferentes aqui também são estados mais rápidos. E essa é a ideia, né, que a gente vai ver aqui hoje. E a gente vai ver também a agregação de

links, né, que é o famoso port channel. Se a gente tem um cenário igual aquele nosso ali, que a gente tem links redundantes ligados entre mesmos switches, a gente tem ali os dois cores ligados exatamente assim, ó. Se a gente deixar o nosso span tre padrão, o span tre considera isso aqui um loop, né? Então ele vai ter que bloquear uma dessas portas aqui também. Ele vai bloquear uma dessas portas aqui porque a gente tem um loop aqui. Qual porta que ele vai bloquear? A gente viu todo o processo ali, é provavelmente aquela onde tem

ali o switch com menor bridge ID. Então a gente pode simplesmente enganar o nosso span tre. Ele bloquearia aqui do sut, tendo em vista que o sut 4 teria aqui o maior bridge ID. Só que a gente pode enganar o spanit criando o que a gente chama de port channel ou agregação de links. Em links redundantes que conectam os mesmos sutitchs, podemos configurar o que a gente chama de Ether channel, port channel, agregação de link, link bundle, é tudo a mesma coisa. A gente vai usar um protocolo aqui para fazer isso, para criar uma porta

lógica em cada sutch, enganando assim o span tre, já que ele pensa que só existe um caminho, nenhum bloqueio será feito. Então o sutch é como se isso aqui fosse uma porta só. Então a gente consegue fazer isso em ligações redundantes para um mesmo equipamento. E é isso que a gente vai fazer agora. Bora aqui para o packet. Então vamos lá, galera. Vamos começar aqui adicionando o nosso core 2 aqui, que é o nosso sut core, que vai ser um 3650. A gente vem aqui em switch, a gente vem aqui em 3650, coloca ele aqui.

Vou mudar o nome dele aqui pra core 2. Vou fazer a ligação dos cabos aqui. Vou ligar aqui de acordo com a topologia. Então vou pegar aqui G1/0/1 na Gabit 0/2, G1/0/2 na G0/2, G1/0/3 na G0/2 aqui e vou ligar aqui os switch entre si. G1/0/ 22 com 22 e G1/0/23 com 23. Só conferir esses cabos aqui. Giga com giga, giga com giga. Então parece que tá tudo OK. No Core 1, eu vou colocar tomadita nele aqui para ele ligar. Venho aqui em CLI. A imagem tá carregando, ele tá iniciando agora. E a gente vai

começar a configuração básica dele aqui, ó. Ligou. Vou sair do modo de setup dando um no. Vou dar um eita, errei. Control shift 6 en conf. Vou colocar aqui host name core 2. Vou colocar aqui agora configurar os troncos, né? Todas as portas que a gente adicionou aqui serão troncos. Interface range gigabit 1/0/1 1/0/1 até 3. Switch portold trunk interface range 1/0/22 até 23. Switch portold trunker. Vou dar um end aqui. Vou dar um WR. Esperar as portas subirem aqui. Então vamos agora tentar entender a nossa topologia span tre aqui. Vou começar aqui pelo corum.

Eu vou dar um comando aqui que é o show spanny tre, enable show span tree. Então primeira coisa que a gente vê aqui nesse show span tree é que ele tem aqui, ó, uma entrada, uma instância de span tre para cada velan. Então ele tem aqui uma saída aqui, né, para velan 1, ele tem aqui pra velan 10, ele tem aqui para velan 20 e ele tem aqui pra velan 99. Então ele vai criar uma instância de spanit aqui. É como se ele rodasse um software de spanitria aqui para cada velan. Porque como cada velan

aqui é um domínio de broadcast diferente e o span tre que ele tá rodando aqui é o Perverlan Spanish Show Spanish Tree Brief Show Spanish Tree Summary. Ele tá rodando aqui um span tre uma versão chamada aqui, ó Pervelan Spanish Try mode, ou seja, ele vai criar uma árvore de spanitary para cada velan diferente. Eu não vou entrar no mérito disso aqui porque é um pouco mais complexo que o spanitary tradicional. É como se ele rodasse um planetiro tradicional para cada velã, então ele pode ter topologias diferentes para cada velã, mas a ideia de formação

aqui de inibição de loop é a mesma. Vamos analisar aqui da velan um, a topologia que ele tem aqui para vel um e depois a gente vai fazer uma modificação aqui. Então, a gente pegar para vel um aqui, repare que o root idoridade 32769 e a Bridge ID, que é o dele também é 32769. E quem ganhou aqui para ser o root é o MAC address, né? O System ID aqui, final 1881 001. 436C 1881 e esse aqui é o 0014382 D72. Então esse cara aqui tem uma menor system ID que esse aqui, então por

isso que ele foi eleito o root aqui para vel um. Analisar aqui as portas aqui embaixo, ó. A gente tem aqui 1 2 3 4 5 portas ligadas aqui, que são as portas que ligam suits, né? Então a gente tem 1 2 3 4 5, né? 1 2 3 4 5 portas ligando entre sutitschits aqui. E a porta root dele é a porta G1/0/3, que é essa porta que liga aqui, ó, no suitch DC, essa porta aqui que é a porta root dele. Então, a gente tentar desenhar o nosso cenário aqui do ponto de vista

do core um, a gente começa a tentar entender a topologia spanit aqui, pelo menos para vel um. Então, vou marcar de verde aqui a porta que ele considerou a rout, que é essa porta aqui, ó. Essa é a porta rout. Esse enlace aqui, né? G1/0/3. Vamos ver o core 2. Qual porta dele que é a root? Show span tre. O core 2, a porta root dele é a porta 1/0/3 também. Só que ele tem duas portas blockeds aqui, ó, que é a porta 1/0/23 e 1/0/22. Então, se eu pegar o nosso cenário aqui do core

2 é a porta também. Essa aqui é a verdinha, né? 1/0/3 é a route. E as portas bloqueadas são essas aqui, ó, que ligam aqui ao qu. Então essas portas aqui estão como blockets. Então provavelmente o meu sutch DC aqui é o meu switch root, pelo menos para vela um. Vamos pegar aqui o switch AC1, ver qual porta dele é a root. Show span tre. A porta dele root é a porta G0/1 e a G0/2 tá como blockets. G0/2 que tá blocked é a que sobe aqui pro switch core 2. Então essa porta aqui e

a porta root dele é a G0/1 que sobe aqui pro corum. Vamos ver qual é a porta aqui root por do AC2. Show pan. A porta root é a G0/1 e a blockeds é a G0/2. Lembrando que o cenário de vocês aí pode estar diferente do meu, porque tem influência também da caixa que ligou aqui primeiro. Qual que é o ID da sua caixa aí que pode ser diferente da minha? Então a porta G0/1 é a porta root e a porta G0/2 é a porta blockets. E assim tá o nosso cenário, né? O DC aqui

é o switch root. Vamos verificar aqui. Enable show. Ó o switch DC. This bridge the root. As portas dele estão como designadas. Então esse cara é o suot aqui, pelo menos para velão. Então é como, né, o nosso caminho aqui, o nosso cenário. Se a gente fosse desenhar a nossa topologia aqui, a nossa loop topology para vel um, é assim, ó. A gente tem esse core aqui, o core 1, ele liga aqui no AC1, a gente tem as ligações aqui pro AC2, a gente tem a ligação aqui pro sutitch DC. E o switch DC tem

uma ligação aqui com o core 2. Então a gente não tem, né, repare que a gente não tem nenhum loop possível, né? A gente tem só um caminho único aqui, core um. E o nosso root aqui é o nosso o nosso DC. Eu quero que o meu sutch core 1 seja o root. Eu quero que todo tráfego, por exemplo, se eu tenho um tráfego que vai aqui é condino ao core 2, por exemplo, que que ele tá fazendo, né? Ele vai ter que subir aqui, descer aqui e depois subir no core 2. Então eu tenho

um tráfego descendo até o AC. Eu não quero que eu tenha tráficos descendo até suitch de acesso. Eu quero que todo tráfego que suba, ele use o link do core aqui. Então a gente não tem um link aqui entre o core aqui. A gente não tem aqueles links aqui. Eu quero que o tráfego, se for com destino algum recurso que tiver aqui. Hoje a gente não tem nada no core 2, né? Mas se tiver, eu quero que o tráfego não desça, né? De novo, se eu tenho esse tráfego descendo, subindo até o core, descendo até

o acesso e depois vai para um outro core, esse tráfego não é um tráfego ótimo para mim, né? Que chama de subótimo. É um tráfego meio que burro, porque os switches de acesso são somentes para ligar o quê? Hosts finais. Eu não quero tráfego que vai no core descendo para um acesso e subindo. Então esse é o perigo, né, de você deixar o span trip padrão, né? Pode ser que suitches de acesso ou suitches antigos aí da sua rede sejam utilizados como tráfego, né? Como ponto e de interesse, né? como pontos centrais de tráfego aí

da sua rede. Vai funcionar sua rede assim vai, mas pode ser que ele fica mais lento, né? Se a gente tem uma ligação aqui entre cores, eu quero ligar elas. E se a gente tá usando sut core, que são suits mais parrudos que esses suits de acesso, são suitches que você tem todo porta giga, né? Aqui no nosso caso uma rede de produção que vai ter redes 10 GB e tudo mais, eu quero sempre usar eles. E como é que a gente faz para que o sut core seja eleito o root da rede? Seja eleito

o suitch principal. A prioridade de todo mundo não é 32769. E o primeiro critério para se verificar não é a prioridade. Então eu vou mudar a prioridade dele para zero. Ela vai ser a menor de todo mundo. E eu quero que o core do caso o core um caia, o core 2 seja eleito root. Então o meu core 1 vai ter a prioridade STP de zero e o meu core 2 vai ter a prioridade de 4096. Ah, mas por que que você não coloca então a prioridade do core 2 de 2? É porque a prioridade

do expan tem que ser múltiplos de 4096. Então tem que ser de 4096 para 4096. Isso tem a ver com os números de bits ali. Enfim, vamos configurar aqui então o nosso core um para ser o switch root aqui da nossa hit. Eu vou pegar aqui, vou dar um conf espaço t span velan. Vou colocar aqui de um até 1005. Priority zero end WR e o nosso core 2 eu vou colocar aqui confi espaço T span 3 vel van range velan 1 até 1005 priority 4096 wr o comando show span tre aqui de novo no

core 1 show span tre então repare que agora, né, this bridge is the root para velan um então quer dizer que ele é o root para velan 20 this bridge is the root olha o priority aqui ó priority tá 20 mas não colocou zer É porque no pervelance spend ele soma o valor da velan na priority. Então 0 + 20 é 20. Se eu vou pegar aqui velan 99, 0 + 99, 99. Priority aqui. Então ele é o root para todo mundo, né? This bridge the root para todo mundo. Então o nosso desenho agora ele

vai est assim, ó. Core 1, AC1, AC2 DC e Core 2. Repare que eu tenho uma portinha bloqueada aqui, ó. Tem uma porta que tá bloqueada. Então aqui a porta, provavelmente é a 22 que tá ativa aqui e a 23 tá bloqueada. Então a gente tem uma porta aqui bloqueada, só que agora o cenário, né, se eu tiver aqui algum recurso, né, o tráfego vai vir aqui assim, não vai descer e subir, né? Então tá, a primeira configuração nossa, tá feita, a gente deu uma melhoradinha aqui e a gente vai melhorar mais. Eu quero somar

esses dois links aqui, ó. Quero somar esses dois links aqui e criar um port channel. Eu quero ter uma porta aqui agora de 2 GB. Eu não quero que essa porta aqui seja bloqueada. Eu quero enganar o span aqui e criar aqui um port channel. E a gente vai fazer isso agora. Eu venho aqui no chor room. Eu, primeira coisa, né, eu vou dar um shutdown nessas portas. Vou dar um conf, interface range G1/0/ 22 até 23. Vou dar um shutdown nelas aqui. Eu gosto de configurar, né, o port channel com as portas desligadas e

depois eu ligo elas. É uma melhor prática. E eu v no core 2 e fazer a mesma coisa. Conf espaço T, interface range gigabit 1/0/22 até 23. E vou dar aqui um shutdown. nelas. Aí eu volto no corum e vou dar aqui um interrogação. Você vê os comandos possíveis? Deixa eu só lembrar aqui do port channel aqui no Cisco aqui, ó. Channel group. Então vou dar aqui um voltar aqui com espaço T interface range. Vou dar aqui um channel traço group. Vou colocar aqui um ID para esse por essa porta. Eu vou chamar de porta

das channel group das mode. Eu vou colocar aqui, vou usar um protocolo aqui chamado lsp que é link aggregation control protocol. Um protocolo livre. O PGP é um protocolo proprietário da Cisco. Então eu vou usar aqui o LCP e vou colocar aqui mode active. Ele vai negociar o tron, o vai negociar aqui o port channel, né, de forma ativa. Ele vai mandar as mensagens de negociação, não vai ficar esperando. Vou colocar aqui, vou dar um enter, ó, create interface port channel des e eu vou dar esse mesmo comando aqui, ó, channel group 10 mode active

no core 2. Então venho aqui no core 2, channel group 10 mode. Aí aqui pode ser passivo. Eu vou colocar os dois ativos porque também funciona. Pode ser um ativo, um passivo, pode ser os dois ativos, só não pode ser os dois passivos. Vou colocar active aqui. E aí eu vou dar um no shutd nessas portas aqui, começando pelo core 1, no shutd. Vou ligar elas e vou aqui dar um no shutd no core 2. Aí a gente vai ver se vai funcionar. Vamos dar aqui um endore 1 e vamos dar um show spanny tree.

Ó, apareceu aqui a porta 10, port channel 10, ó. Vamos dar um show interfaces. Port channel. Port channel 10. Aqui tá app connected. Vamos dar um show interface strunk. Ó, port tá aparecendo aqui bonitinho. Então tá funcionando, né? Vamos ver aqui se ó, os dois estão como laranjinhas aqui. Vamos ver o core do aqui. Show span tre, ó. Porta 10 aqui, ó. Subiu aqui. Agora ficou verdinho. Subiu aqui. Deixa eu span tre aqui, ó. Tá no estado de learning, né? Daqui a pouco ele vai est em forward aqui, ó. Ó, agora tá em forward. Então,

meu portal 10 aqui do ponto de vista do core 2 é minha root port. Tá vendo? root para chegar aqui no coreum. Então tá bonitinho funcionando aqui. Vamos verificar aqui no corum. Show span tre o portinel 10 aqui bonitinho. Aqui ele manteve aqui o 22 23, né? Por que que não tá aparecendo só o portin 10 aqui? Não sei se isso é algum bug. Aqui na vela um ele tá aparecendo as duas portas. Show interface trunk. Tá portinha 10 aqui. É provavelmente algum bugzinho aqui do packet. Vamos dar um ping aqui do PC10 no PC

13. Lembrando que aqui no core 2 eu ainda não configurei a redundância de layer 3, né? Então os gatos ainda não estão configurados aqui. A gente vai fazer isso na próxima aula, tá? Só layer dois. Então eu só vou conseguir pingar aqui. Se o quum cair, eu só vou pingar equipamentos da mesma rede, né? Então aqui no PC10 eu ainda consigo pingar de redes diferentes porque o meu core um tá ativo. Então se eu der um ping 192.168. 10.1, o meu gator tá up. Então eu pingo aqui redes diferentes. 20.13 13, por exemplo. É 20.13.

É, ó, tô pingando. 2014. Vou pingar também. Pingou. Vamos pingar aqui agora o 10.15. Vou pingar aqui. Tô pingando. Vamos pingar aqui. Dá um ping espaço menos T, que é um ping eterno, um ping que nunca para. Vou deixar aqui, ó, no top. E aí eu vou desligar o meu coreum. E vamos ver quanto tempo, né, vai demorar para porque agora o tráfego, né, tá vindo como tá subindo o PC10, indo aqui no sutch AC1, né? Se bem que ele tá indo, não tá indo pro Corum, né? Porque essa porta aqui tá bloqueada. Essas portas

aqui estão bloqueadas, né? Então tá indo pro Corum e descendo aqui pro AC2. Eu vou desligar o Coreum. Vamos ver quantos pacotinhos que a gente vai perder aqui. Eu venho aqui no core um, venho aqui em physical. Ã, deixa eu salvar primeiro, né? Dá um WR aqui para salvar. Não lembro se eu salvei. Physical. Eu vou tirar o cabo dele aqui, ó. Vou desligar ele, ó. Desligou, tá tudo vermelho aqui. Vai começar a perder pacote aqui, ó. Perdeu time out, perdeu um. Vamos ver quantos que ele vai perder até o span tre migrar para cá,

né? Vai demorar aí 1 minuto. Eu acho que não vai subir porque eu acho que eu esqueci de configurar uma coisa aqui no core 2. Que que vocês acham que eu esqueci? Vou ligar de novo aqui o nosso core 1. Ligar de novo aqui. Vou fechar aqui. Vou tirar isso aqui. Vou dar um contrtrl C aqui. Vem aqui no core 2. Eu acho que eu esqueci um negócio aqui. Show velã. Ah, esqueci de criar as velãos aqui, ó. Então, o que que tá acontecendo, né? Tá só, só tem a velan um aqui no core 2.

Eu tenho que criar aqui as velansãs 10, 20, 99, porque o frame saiu daqui na velan 10. Se ele chega aqui e não tem a velan 10 criada aqui, como é que o Core 2 vai alocar esse frame aqui em algum lugar? Ele não tem nem tabela MAC, né, da Velan 10 aqui. Ele não conhece a velan 10. El falar: "Cara, eu não conheço velan 10, eu conheço um 1002, 1003, 100, 1005". Então, a gente tem que criar aqui no core 2 as velans. Então, vou colocar aqui velan 10, velan 20 e velan 99. São

as velans que a gente tá trabalhando aqui. Dar um show span tre aqui agora. Velan 20, velan 10 e velan 99. Agora sim. Esperar a nossa rede converter aqui bonitinho, carregar tudo aqui. A gente faz o teste aqui. Vamos pegar o PC10 e dar um ping de novo aqui. Tá pingando, tá fazendo esse caminho por aqui, né? Bonitinho. Vamos ver se o nosso core 2 aqui já tá tudo em forwarding aqui. Não, tá ainda. Tá em listening aqui. Learning, ó. LRN, né? É learning. Quando tiver tudo em forwarding aqui, eu faço a, ó, tudo em

forward. FWD, FWD. Vamos testar agora. Agora sim a gente consegue testar. Então vamos pegar aqui o PC10, deixar ele aberto aqui e vamos tirar a tomadita do Corum aqui. Só conferir se ele ainda ele é o root, né? Enable show span tre. Ó, this bridge the root. This bridges the root. É beleza. Vamos tirar a tomadinha dele aqui. Desliga. Vamos desligar. Ver quantos pacotinhos vão perder aqui, ó. A gente perdeu aqui, ó, voltou já, ó. A gente perdeu aqui 1 2 3 4 5 pacotinhos aqui e voltou. Lembrando o seguinte, né? Eu não vou conseguir

pingar redes diferentes da minha, porque as interfaces velans, os Gator estão só no core um. Eu não configurei Gator no core 2. A gente vai ver por na próxima aula. Então, olha só, se eu pingar aqui, alguém diferente do meu não vai pingar. Eu só pingo a mesma rede. Então, a gente viu que funcionou aqui a nossa LER 2 aqui do core 2. Só que a gente tá perdendo aqui, ó, cinco pacotinhos. Será que dá para melhorar isso? Vamos ligar de novo o nosso core 1 aqui. Esperar ele iniciar aqui, ó. Tá ligando aqui, ó.

Então, vamos lá. Aparentemente tudo subiu aqui. Vamos ver as versões de span tre que a gente tem aqui. Spanny tree mode, interrogação. Ele me mostra as opções. Tem o PVAN Span Tree, que é esse que a gente tá usando, que é o padrão que vem no equipamento. E tem o rapid PV Span 3. Vamos mudar aqui pro Rapid, que é um span tre mais rápido. Vamos ver se vai dar diferença ali no nosso ping. Eu tenho que executar esse comando em todos os meus switch pra rede ficar e bonitinha aqui com as mesmas versões de

span assim. Se um tiver em outra versão e outra tiver em outra, vai funcionar, mas não é o ideal. Então vou dar aqui um span tre mode rapid PV span 3 em todo switch e aí vou dar um WR. Então fiz aqui no core 1, vou fazer aqui no core 2. Span mode wrap prevalence span end WR no AC1. Vou dar um enable aqui. Conf espaço T. Spon Tree mode wrapt PV span end WR no AC2 também. Enable conf espaço T. Spon 3 mode wrapped pil span end wr e aqui no dc também enable conf

espaço t spry mode wrapt pvl spon wr esperar a rede convergir aqui repar que tá laranjinha aqui ainda, né? Aparentemente tá todo mundo aqui com wrap de palance punit tre. Vamos pegar o PC10 e vamos dar aquele mesmo teste do ping, ó. Ping menos T, que é um ping eterno, né? Que ele nunca para e ping alguém na mesma rede que eu, né? que tá em outro sutch, no caso aqui o PC15. Então tô aqui desse lado, tô pingando o PC15 que tá aqui do outro lado. Então vai subir aqui, vai descer e vai até

o PC15. Então vamos desligar aqui o Corum. Vamos dar aqui um tirar da tomada mesmo. Tira a tomadinha dele aqui. Vamos ver quantos pings que vai perder aqui agora. Antes foram cinco, né? Vamos ver quantos serão aqui agora, ó. Perdeu um um ping. Isso aqui é lindo demais, né? Maravilha. Olha isso, cara. Perdeu um só dando um comando. Então a nossa rede tá bem melhor do que tava, né? Vou dar um contrl C aqui. Eu fico muito feliz com isso. Você tá louco. É isso, galera. Então, isso que eu tinha para fazer hoje, né, para

passar aqui para vocês hoje. Spanit. A gente viu camada dois aqui puramente, né, um protocolo de camada dois que é o span tre. Eu espero que vocês tenham curtido. Coloque o like aí, coloquem perguntas aí também se vocês tiverem. Se tiver muitas perguntas aqui, a gente faz uma live respondendo perguntas aqui. E é isso. Chama um amiguinho também para fazer o curso. Compartilhe com ele, chama um coleguinha, fala para ele se inscrever no canal aqui. Isso dá muito ânimo pra gente continuar. A gente tá chegando aí quase 80.000 inscritos. Vamos continuar crescendo aí e obrigado

por assistir, galera, e até a próxima.