1
00:00:08,940 --> 00:00:14,220
Envie este exemplo vamos supor que A está enviando um quadro para D.

2
00:00:14,440 --> 00:00:17,260
Então, o endereço de origem que levou a será um.

3
00:00:17,380 --> 00:00:19,370
E o endereço de destino será D.

4
00:00:19,600 --> 00:00:27,010
Eu enviarei o quadro para alternar um deles, o qual copiará esse quadro para todas as portas baseadas novamente

5
00:00:27,010 --> 00:00:28,380
na arquitetura do switch.

6
00:00:28,510 --> 00:00:34,480
O async central irá checar o destino na tabela do acampamento e vamos supor no momento que não responda qual

7
00:00:34,480 --> 00:00:37,990
deles pode ser a tabela ou a tabela de endereços MAC.

8
00:00:38,230 --> 00:00:44,050
Assim, o quadro tentará sair dessa porta para 0 2, mas porque a cor marcada interna é vermelha

9
00:00:44,050 --> 00:00:44,880
para esse quadro.

10
00:00:44,920 --> 00:00:46,590
E este é um Greenport.

11
00:00:46,720 --> 00:00:49,280
O quadro não é permitido fora de 0 2.

12
00:00:49,600 --> 00:00:52,040
No entanto, nesta porta, porque é um link de tronco.

13
00:00:52,210 --> 00:00:57,400
E vamos supor que, no momento em que todos os terrenos sejam permitidos através desse tronco,

14
00:00:57,400 --> 00:01:04,220
esse quadro será enviado para fora da porta 0 3 para alternar, no entanto, logo antes do envio do quadro.

15
00:01:04,220 --> 00:01:06,760
Precisa ser marcado com o número do vilão.

16
00:01:07,100 --> 00:01:10,080
Então, neste caso, o identificador de vilão seria vermelho.

17
00:01:10,130 --> 00:01:15,750
Agora, como mencionado em switches villans identificados por números, mas para manter esses exemplos

18
00:01:15,760 --> 00:01:17,310
simples, vamos usar cores.

19
00:01:17,330 --> 00:01:24,470
Então, isso seria, na verdade, um número de 0 a 4.000 e 96 quadros são então enviados

20
00:01:24,830 --> 00:01:32,120
através do tronco para mudar para quem recebe o quadro mais uma vez o quadro é processado internamente.

21
00:01:32,120 --> 00:01:37,430
Agora este interruptor lê o vilão identificar um cabeçalho Q editado ou um e vê que ele

22
00:01:37,430 --> 00:01:44,540
pertence ao Villon vermelho que está marcado internamente dentro do switch que o quadro é enviado para o Allport 0 2, assim como

23
00:01:44,540 --> 00:01:45,160
0 1.

24
00:01:45,260 --> 00:01:50,630
E vamos supor mais uma vez que a tabela de endereços MAC é comutada para não contém o endereço

25
00:01:50,630 --> 00:01:51,570
MAC de D.

26
00:01:51,650 --> 00:01:58,040
Então, quando o quadro está tentando ir para a porta 0 1, ele é negado porque a cor do quadro é

27
00:01:58,430 --> 00:02:00,760
vermelho e essa interface está no Villon verde.

28
00:02:00,920 --> 00:02:02,710
Então o quadro é descartado.

29
00:02:02,730 --> 00:02:08,840
No entanto, fora dessa interface, o quadro é permitido porque a porta está no vilão vermelho e

30
00:02:08,840 --> 00:02:14,920
o quadro é marcado com o vilão vermelho, e toda a marcação é removida dessa porta.

31
00:02:14,960 --> 00:02:19,340
Portanto, é o mesmo que um quadro Ethernet normal para PCD.

32
00:02:19,340 --> 00:02:24,080
Mais uma vez os PJs estão alheios ao fato de terem sido colocados em vilões.

33
00:02:24,110 --> 00:02:26,660
Eles só veem Ethernet com stents.

34
00:02:26,660 --> 00:02:32,420
Portanto, um quadro padrão em que o endereço de origem de um endereço de destino D

35
00:02:32,420 --> 00:02:40,450
é transmitido para fora da porta 0 e processado pelo PC editado em uma chave tronceada tem um vilão espacial conhecido como vilão

36
00:02:41,050 --> 00:02:46,270
nativa nativa não é marcado quando uma porta no switch está configurado como um tronco.

37
00:02:46,630 --> 00:02:53,800
Por exemplo, esta interface no switch 1 e a mudança para essa interface pode receber e transmitir frames

38
00:02:53,800 --> 00:03:01,450
de frames pertencentes à villaine nativa, que não carregam tags violentas quando enviadas por este trunk pelo mesmo token,

39
00:03:01,450 --> 00:03:07,480
se um frame não marcado for recebido na porta de trunk daquele frame. seria automaticamente

40
00:03:07,480 --> 00:03:11,030
associado com a terra natal para o esporte.

41
00:03:11,050 --> 00:03:15,030
Agora, o tráfego de gerenciamento específico passará pela terra nativa.

42
00:03:15,220 --> 00:03:22,090
Assim, por exemplo, o uso de BPT na árvore de abrangência usará o Villon nativo e o protocolo de entroncamento dinâmico crítico de

43
00:03:22,930 --> 00:03:28,450
entroncamento dinâmico será uma maneira de os switches negociarem a configuração de um tronco entre si automaticamente e

44
00:03:28,900 --> 00:03:31,010
eu mostrarei um exemplo disso em breve.

45
00:03:32,130 --> 00:03:38,370
Certos tráfegos de gerenciamento sempre usarão um vilão se você tiver deixado a linha um como

46
00:03:38,760 --> 00:03:45,480
tráfego nativo da LAN, como CPV DP AGP, e sua DL D será transmitida através da terra nativa.

47
00:03:45,540 --> 00:03:52,650
Desmarcada se eu alguma vez A terra nativa for mudada para algo diferente da terra um, esses protocolos

48
00:03:52,650 --> 00:03:59,280
serão então marcados nesse CTP específico da vilania foi explicado na parte da CID 1 deste curso.

49
00:03:59,340 --> 00:04:05,190
Ele nos permite ver diretamente os dispositivos conectados e o protocolo de entroncamento que discutiremos

50
00:04:05,190 --> 00:04:06,550
nos próximos slides.

51
00:04:06,600 --> 00:04:13,350
É uma maneira de atualizar dinamicamente outros switches com alterações feitas em um único switch em um

52
00:04:13,960 --> 00:04:21,330
domínio VTB AGP ou protocolo de agregação de porta é um protocolo usado para a criação automática de canais

53
00:04:21,330 --> 00:04:28,380
ether e você DLT ou você precisa de detecção vinculada direcional é usado para monitorar o configuração física

54
00:04:28,380 --> 00:04:32,120
de cabos entre dispositivos e detectar links direcionais exclusivos.

55
00:04:32,130 --> 00:04:35,330
Isso nos permite detectar links cabeados incorretamente.

56
00:04:35,340 --> 00:04:40,380
O importante a ter em conta aqui é que há um vilão especial conhecido como

57
00:04:40,380 --> 00:04:46,770
a terra natal onde o tráfego é enviado sem marcação, se deixado no padrão de Villa e um lote

58
00:04:46,770 --> 00:04:49,880
de tráfego de gestão será enviado através dessa terra natal.

59
00:04:49,890 --> 00:04:56,460
É importante que a terra nativa em ambos os lados do tronco seja a mesma, se não definir o mesmo.

60
00:04:56,460 --> 00:05:00,620
Os pesquisadores irão notificá-lo dizendo que existe uma incompatibilidade nativa com a vilania.

61
00:05:01,080 --> 00:05:06,990
A questão que surge se as terras nativas não são as mesmas é que o tráfego de um

62
00:05:07,170 --> 00:05:11,750
vilão no comutador será automaticamente associado e terminará em um comutador diferente do outro.

63
00:05:11,760 --> 00:05:17,400
E obviamente todo o conceito de felino é separar o tráfego em um Thielen específico.

64
00:05:17,430 --> 00:05:23,100
Em outras palavras, um domínio de transmissão separado ou um tráfego de sub-rede separado de uma VLAN

65
00:05:23,160 --> 00:05:28,320
não deve acabar em outro vilão devido a um erro de configuração nativa da vilania.

66
00:05:28,340 --> 00:05:31,360
Agora isso é algo que você provavelmente não vê nas redes hoje.

67
00:05:31,580 --> 00:05:38,510
Em teoria, com uma vilã nativa, um interruptor como o switch 1 poderia dizer frames marcados para mudar para

68
00:05:38,600 --> 00:05:40,680
quadros não marcados para este MacBook.

69
00:05:40,820 --> 00:05:47,030
Assim, usando o Villon nativo, este MacBook ou um PC ainda seria capaz de se comunicar

70
00:05:47,330 --> 00:05:53,360
com a rede, mesmo que não entenda frames marcados editados ou um quadros-chave ou quadros marcados

71
00:05:53,360 --> 00:05:58,040
sejam usados ​​para comunicação via informações entre dispositivos de rede como switches.

72
00:05:58,040 --> 00:06:03,410
Esse dispositivo não necessariamente compreenderia quadros-chave editados ou em um keyframes, mas ainda poderia se comunicar

73
00:06:03,410 --> 00:06:05,840
com a rede usando o vilão nativo.

74
00:06:06,110 --> 00:06:07,800
No entanto, isso não é comum hoje em dia.

75
00:06:07,970 --> 00:06:16,130
O que é mais típico Hoje é um cenário como este, onde você tem um PC conectado a um telefone IP conectado

76
00:06:16,130 --> 00:06:17,770
a um switch Cisco.

77
00:06:17,780 --> 00:06:25,010
Agora, o telefone IP da Cisco possui um switch de três vias, uma porta é conectada de volta à infra-estrutura de rede.

78
00:06:25,130 --> 00:06:32,030
Assim, um comutador Cisco de uma segunda porta permite que o PC se conecte à infraestrutura por meio do telefone,

79
00:06:32,030 --> 00:06:38,600
e uma terceira porta permite que o tráfego de voz do aparelho seja priorizado sobre os dados quando enviado

80
00:06:38,600 --> 00:06:40,000
à infraestrutura da rede.

81
00:06:40,340 --> 00:06:46,970
Assim, o telefone foi construído em um switch de três vias, sempre orgulhoso de aumentar a voz sobre os dados.

82
00:06:47,020 --> 00:06:52,510
A coisa a tomar nota aqui, porém, é que o telefone pode ser configurado em um Villon separado

83
00:06:52,510 --> 00:06:53,380
para o PC.

84
00:06:53,380 --> 00:06:57,900
Então o telefone pode estar no violino vermelho e o PC pode estar na linha verde.

85
00:06:58,030 --> 00:07:00,610
Há muitas vantagens em fazer isso dessa maneira.

86
00:07:00,850 --> 00:07:07,270
Então, normalmente, do ponto de vista da segurança, este PC não conseguirá farejar o tráfego de voz

87
00:07:07,330 --> 00:07:09,760
e, portanto, ouvir a conversa por voz.

88
00:07:09,760 --> 00:07:14,600
Agora há muitas ressalvas relacionadas aos telefones Cisco e diferentes modelos são configurados de maneiras diferentes,

89
00:07:14,830 --> 00:07:21,160
mas, em teoria, o conceito é que o telefone está em um violão separado para o PC e, portanto, o PC

90
00:07:21,160 --> 00:07:24,090
não é capaz de ver o tráfego de voz.

91
00:07:24,100 --> 00:07:29,740
Existem aplicativos como o Cain e o Abel, que é uma ferramenta de hacking muito poderosa

92
00:07:29,740 --> 00:07:36,820
que permite capturar a rede e capturar o tráfego de voz como um arquivo no PC local para que você

93
00:07:36,820 --> 00:07:39,000
possa reproduzir a conversa por voz.

94
00:07:39,340 --> 00:07:44,950
Mas se o telefone estiver em uma segurança Villon separada é aprimorada porque o PC não é capaz de ver o tráfego

95
00:07:44,950 --> 00:07:47,920
de voz de um ponto de vista de qualidade de serviço.

96
00:07:47,920 --> 00:07:53,130
Isso também é muito melhor porque é mais fácil priorizar o tráfego de voz sobre o tráfego de dados.

97
00:07:53,290 --> 00:07:59,530
Se o seu em uma VM separada configurar sua rede desta forma também tem as vantagens de gerenciamento de endereço

98
00:07:59,530 --> 00:08:03,680
IP mais fácil porque você pode atribuir uma sub-rede separada para seus telefones.

99
00:08:03,690 --> 00:08:07,380
Esses são seus PCs e, assim, escalam seu endereçamento IP.

100
00:08:07,420 --> 00:08:13,030
Então o que acontece é que o switch é configurado com o que é chamado de voz Freelon

101
00:08:13,420 --> 00:08:19,780
e uma vilão nativa, a sensação de voz é marcada para que quadros marcados sejam enviados para o telefone e o

102
00:08:19,840 --> 00:08:26,650
telefone com a chave tripla seja capaz de ler os frames não marcados ou um keyframes são salvos no que é chamado

103
00:08:26,660 --> 00:08:28,960
de linha de dados ou iluminação nativa.

104
00:08:29,110 --> 00:08:34,730
Essa informação é enviada para o telefone e o telefone apenas muda para o PC.

105
00:08:34,840 --> 00:08:41,440
Assim, o PC recebe o untagged em quadros de terra nativos e o telefone recebe aquele arquivo marcado ou

106
00:08:41,440 --> 00:08:46,040
de voz e não emoldura a configuração, e o telefone é necessário para isso.

107
00:08:46,150 --> 00:08:51,280
Você literalmente digitou alguns comandos no interruptor dizendo o interruptor que a voz da terra é e o

108
00:08:51,280 --> 00:08:52,550
que é o DTV Bil'in.

109
00:08:52,750 --> 00:08:59,020
E isso acontece automaticamente porque, quando o telefone é inicializado, eles consultam o switch pelo CGP para

110
00:08:59,020 --> 00:09:01,010
descobrir a qual deles pertencem.

111
00:09:01,270 --> 00:09:06,530
Então, a mudança de data data a configuração do telefone através do uso de CTP.

112
00:09:06,850 --> 00:09:11,580
Portanto, esta é uma implementação muito comum de terras nativas no mundo real hoje.

113
00:09:12,530 --> 00:09:18,410
Então, apenas para resumir como as portas são atribuídas aos vilões, elas podem ser estaticamente atribuídas

114
00:09:18,410 --> 00:09:19,490
por um administrador.

115
00:09:19,520 --> 00:09:25,460
Então, para usar um administrador, entre em uma interface e coloque essa porta em um vilão.

116
00:09:25,460 --> 00:09:30,980
A segunda opção é criar o que é chamado de vilões dinâmicos usando vilões dinâmicos de servidor de

117
00:09:31,700 --> 00:09:39,170
política de associação de vilões que permitem uma transação de portas e que é feito emic atualizado com base no endereço Mac do dispositivo

118
00:09:39,170 --> 00:09:40,600
anexado a essa porta.

119
00:09:40,910 --> 00:09:46,400
Assim, em uma sala de reuniões, por exemplo, quando um diretor conecta um laptop com base

120
00:09:46,490 --> 00:09:52,640
no endereço Mac daquele laptop, essa porta é designada dinamicamente aos diretores quando um gerente conecta seu

121
00:09:52,640 --> 00:09:59,020
laptop à mesma porta no dia seguinte, por exemplo, que Villon é automaticamente atualizado para os gerentes Villon.

122
00:09:59,030 --> 00:10:04,400
Portanto, com base no endereço MAC de origem do quadro recebido na porta,

123
00:10:04,580 --> 00:10:12,400
a porta é automaticamente atribuída a terras diferentes e no ano passado temos vilões de voz que são usados

124
00:10:12,490 --> 00:10:19,720
​​especificamente para telefones IP BTP ou protocolo troncalizado villaine é uma camada proprietária da Cisco para protocolo que

125
00:10:19,720 --> 00:10:25,980
permite Propagação da informação de um switch para outro em vez de telnet para múltiplos switches.

126
00:10:26,080 --> 00:10:32,710
Você pode Karaite excluir ou renomear as terras em um switch e ter essas informações automaticamente propagadas para

127
00:10:33,100 --> 00:10:35,610
outros switches através de links de tronco.

128
00:10:35,620 --> 00:10:38,750
Observe o nome do protocolo de truncamento de vilão.

129
00:10:38,770 --> 00:10:42,820
Esta informação só pode ser propagada através de links de tronco.

130
00:10:42,820 --> 00:10:48,820
Agora o ETP pode poupar muito tempo que muitos engenheiros da Sisk dirão que o BTP pode lhe causar

131
00:10:48,850 --> 00:10:50,190
muitas dores de cabeça.

132
00:10:50,200 --> 00:10:55,960
Os switches podem ter toda a configuração do villaine eliminada se um novo switch for adicionado à

133
00:10:56,200 --> 00:10:58,320
rede sem seguir um procedimento adequado.

134
00:10:58,570 --> 00:11:04,540
Portanto, muitos engenheiros da Cisco não habilitarão a VCP em ambientes modernos, devido aos riscos

135
00:11:04,540 --> 00:11:06,340
inerentes associados a esse protocolo.

136
00:11:07,440 --> 00:11:13,650
As mensagens GTP são enviadas para o seguinte endereço Mac, que é um endereço multicast bem

137
00:11:13,770 --> 00:11:16,950
conhecido para inundação dos protocolos CTP e DTP.

138
00:11:16,950 --> 00:11:19,400
Existem três tipos de mensagens no DTP.

139
00:11:19,410 --> 00:11:25,950
Você tem alguns anúncios de subconjunto de anúncios gratuitos e solicitações de anúncios e explicarei cada um

140
00:11:25,950 --> 00:11:28,790
deles com mais detalhes nos próximos slides.

141
00:11:28,890 --> 00:11:35,380
Mas, por favor, esteja ciente de que há três mensagens digitadas ao configurar dispositivos DP que, por

142
00:11:35,380 --> 00:11:38,560
padrão, pertencerão ao VDB de domínio nulo para funcionar.

143
00:11:38,560 --> 00:11:45,490
Você precisa configurar e colocar os dispositivos em um único domínio VTB específico. Os dispositivos no mesmo

144
00:11:45,490 --> 00:11:49,460
domínio DTP serão atualizados com as informações da linha.

145
00:11:49,480 --> 00:11:56,920
Um switch só pode ser configurado em um único domínio VTB a qualquer momento, por padrão, os switches da Cisco

146
00:11:56,920 --> 00:12:04,450
estão no domínio nold ou não há domínio de gerenciamento até receberem um anúncio de um domínio sobre um link

147
00:12:04,450 --> 00:12:04,980
troncalizado.

148
00:12:05,080 --> 00:12:08,350
Ou até você configurar manualmente um domínio de gerenciamento.

149
00:12:08,580 --> 00:12:14,830
Portanto, neste exemplo, vamos supor que esses dispositivos foram colocados no domínio VTB com o nome

150
00:12:14,830 --> 00:12:15,750
de Cecka.

151
00:12:16,030 --> 00:12:22,300
Lembre-se de que essa VCP é uma camada para protocolo e requer links troncalizados para comunicação.

152
00:12:22,540 --> 00:12:29,860
Portanto, o VDB não irá atravessar Harada, um conceito importante para entender que o NVP é o conceito de um número

153
00:12:29,860 --> 00:12:30,490
de revisão.

154
00:12:31,380 --> 00:12:38,260
Toda vez que muda para o banco de dados do vilão, o número de revisão no BTP aumentará em 1.

155
00:12:38,460 --> 00:12:45,410
Então, vamos supor que todos os dispositivos neste pedido de desculpas têm um número de revisão de 1 seu em um

156
00:12:45,600 --> 00:12:51,720
ministério para um vilão digamos que nós três para o número de revisão dele será então incrementado de um

157
00:12:51,720 --> 00:12:59,320
número de visão 1 para número de revisão 2 que informações serão então anunciadas para todos os outros comutadores no domínio VTB, para

158
00:12:59,650 --> 00:13:05,410
que possam sincronizar seus bancos de dados com o número de revisão mais recente, que é o número

159
00:13:05,410 --> 00:13:06,440
de revisão 2.

160
00:13:06,550 --> 00:13:11,680
Assim, o switch no topo enviará o que é chamado de anúncio de resumo do GTP

161
00:13:11,710 --> 00:13:14,860
para todos os switches informando que uma alteração foi feita.

162
00:13:14,860 --> 00:13:17,610
Lembre-se de que isso é enviado usando um endereço multicast.

163
00:13:17,740 --> 00:13:21,070
Então, todos esses dispositivos verão essa mensagem.

164
00:13:21,070 --> 00:13:26,440
Eles solicitarão as informações mais recentes usando uma solicitação de anúncio e o switch

165
00:13:26,620 --> 00:13:31,800
no topo enviará informações detalhadas sobre a alteração usando um anúncio de subconjunto.

166
00:13:31,810 --> 00:13:37,150
O resultado líquido é que os números de revisão e todos esses comutadores serão incrementados para o

167
00:13:37,150 --> 00:13:40,740
mesmo número de revisão de um comutador onde a alteração foi feita.

168
00:13:40,780 --> 00:13:46,210
Então Viola e três aparecerão em todos os bancos de dados dos switches e o número de revisão será

169
00:13:46,210 --> 00:13:48,100
configurado para a revisão número dois.

170
00:13:48,250 --> 00:13:54,430
Todo o conceito com o VTB é que você pode fazer alterações em um dispositivo individual conforme essas alterações

171
00:13:54,430 --> 00:13:55,190
são feitas.

172
00:13:55,300 --> 00:14:00,700
Todos os outros switches são informados da alteração e eles sincronizarão seus bancos de dados com o número de revisão

173
00:14:00,700 --> 00:14:06,130
mais recente, de modo que eles acabem tendo os mesmos planos B e talvez os bancos de dados da Lenn.

174
00:14:06,130 --> 00:14:11,680
Isso significa que você, como administrador, apenas para fazer alterações em um comutador em vez de

175
00:14:11,680 --> 00:14:18,300
cinco comutadores no pedido de desculpas, observe que as portas são colocadas em vilões individuais, por exemplo, por um administrador.

176
00:14:18,610 --> 00:14:25,300
O DP não coloca portas em vilões individuais, apenas atualiza o banco de dados para que os

177
00:14:25,300 --> 00:14:31,770
switches saibam quais vilões existem, e um administrador ainda precisa colocar essas portas nos vilões relevantes.

178
00:14:31,990 --> 00:14:38,230
Portanto, este é apenas um mecanismo de atualização do banco de dados de vilões, para que os switches

179
00:14:38,230 --> 00:14:40,810
conheçam os vilões que existem na tipologia.

180
00:14:40,820 --> 00:14:43,500
Então, vamos olhar as mensagens VDB em mais detalhes.

181
00:14:43,520 --> 00:14:46,760
A primeira parada da mensagem VDB é um anúncio de resumo.

182
00:14:46,760 --> 00:14:51,620
Isso é enviado a cada cinco minutos ou sempre que houver uma alteração.

183
00:14:51,620 --> 00:14:58,340
Assim, sempre que um administrador fizer uma alteração em um switch, por exemplo, adicionando um Villon, um anúncio de

184
00:14:58,340 --> 00:15:03,590
resumo será enviado no endereço multicast bem conhecido para todos os switches no domínio.

185
00:15:03,590 --> 00:15:10,190
Portanto, isso é usado para informar outros switches do domínio VCP atual e o número de revisão da

186
00:15:10,190 --> 00:15:10,910
configuração atual.

187
00:15:11,210 --> 00:15:17,510
Então, como um exemplo no switch one, o administrador adiciona outro vilão, digamos que o vilão para o

188
00:15:17,510 --> 00:15:19,150
número de revisão será incrementado.

189
00:15:19,150 --> 00:15:23,160
Então, se o número de revisão fosse três, não seria incrementado para 4.

190
00:15:23,660 --> 00:15:29,660
Esta opção dirá em um anúncio resumido a todos os comutadores vizinhos informando-os do

191
00:15:29,660 --> 00:15:36,740
domínio VTB atual e os novos comutadores de número de revisão de configuração que recebem esse

192
00:15:37,060 --> 00:15:43,310
anúncio resumido enviarão de volta um pedido de resumo solicitando informações detalhadas sobre as

193
00:15:43,310 --> 00:15:44,160
alterações feitas.

194
00:15:44,180 --> 00:15:50,240
Existem três situações em que algumas solicitações são usadas Primeiramente, quando um switch foi redefinido ou quando

195
00:15:50,240 --> 00:15:57,250
o nome de domínio VTB está sendo alterado ou quando o switch recebeu um anúncio de resumo VTB com um

196
00:15:57,250 --> 00:16:00,500
número de revisão de configuração maior que o seu.

197
00:16:00,500 --> 00:16:07,370
Então, porque mudar para recebeu o anúncio de resumo de um indicando um alto número de revisão.

198
00:16:07,490 --> 00:16:12,170
Em outras palavras, o número de revisão e qual é a revisão anterior e o

199
00:16:12,170 --> 00:16:20,090
número de revisão no switch 2 é o número de revisão 3 O switch 2 agora solicitará informações do switch 1 para que ele possa

200
00:16:20,090 --> 00:16:26,750
atualizar seu banco de dados com as informações mais recentes que são enviadas de qual deles para mudar para usar o

201
00:16:26,750 --> 00:16:28,520
que é chamado de subconjunto.

202
00:16:28,550 --> 00:16:29,780
Propaganda.

203
00:16:29,780 --> 00:16:36,890
Contém uma lista das informações e, se forem várias vilões, mais de um anúncio de subconjunto poderá

204
00:16:36,890 --> 00:16:42,280
ser necessário para atualizar e sincronizar os bancos de dados de outros comutadores.

205
00:16:42,290 --> 00:16:47,370
Então, essencialmente, o que isto é é uma informação detalhada das mudanças que foram feitas.

206
00:16:47,540 --> 00:16:52,910
O anúncio de resumo apenas informa a mudança no formato de resumo do último número de revisão

207
00:16:52,910 --> 00:16:54,290
e do domínio BTP.

208
00:16:54,500 --> 00:17:00,860
Se o switch local perceber que está desatualizado, solicitará informações detalhadas para que ele possa sincronizar

209
00:17:00,860 --> 00:17:06,500
seu banco de dados e essas informações serão fornecidas usando um anúncio de subconjunto.

210
00:17:06,530 --> 00:17:12,290
O comutador agora é capaz de sincronizar os bancos de dados locais com o banco de dados do comutador com as

211
00:17:12,290 --> 00:17:13,140
informações mais recentes.

212
00:17:14,310 --> 00:17:16,910
Agora existem três modos no BTP.

213
00:17:17,100 --> 00:17:25,500
O modo padrão é o servidor, um switch VTB no modo de servidor pode criar vilões modificar vilões e

214
00:17:25,500 --> 00:17:26,370
excluir vilões.

215
00:17:26,400 --> 00:17:29,650
Também envia e envia anúncios.

216
00:17:29,790 --> 00:17:34,040
Então, se recebesse um anúncio de outro switch, ele o encaminharia.

217
00:17:34,290 --> 00:17:39,070
Se você fez alterações no switch local, ele enviaria alguns anúncios reais.

218
00:17:39,090 --> 00:17:43,340
Ele também sincronizaria seu banco de dados local com o número de revisão mais recente.

219
00:17:43,650 --> 00:17:47,460
E também salva as informações de configuração do vilão localmente.

220
00:17:47,460 --> 00:17:52,500
Portanto, este é o dispositivo em que você fará suas alterações. Vários switches podem ser

221
00:17:52,500 --> 00:17:56,530
configurados como servidores VTB, mas você precisa ter muito cuidado com isso.

222
00:17:56,580 --> 00:18:03,780
O segundo modo é o cliente VTB, um cliente VTB não pode criar mudanças ou excluir vilões.

223
00:18:04,020 --> 00:18:10,050
Também é capaz de enviar anúncios para que ele possa dizer em qualquer violência atualmente

224
00:18:10,050 --> 00:18:17,310
listada em seu banco de dados para outros switches VTB, ele também pode encaminhar receber propaganda de outros switches.

225
00:18:17,310 --> 00:18:23,760
Em terceiro lugar, também sincronizaria seu banco de dados com o último número de revisão de configuração. Esse é um

226
00:18:23,760 --> 00:18:29,970
grande problema em potencial com o GTP e que já foi gravado em muitos engenheiros da Cisco no passado.

227
00:18:29,970 --> 00:18:33,670
Muitos engenheiros da Cisco não usarão o VTB devido a esse problema.

228
00:18:33,930 --> 00:18:36,020
Então ele tem uma tipologia de amostra.

229
00:18:36,240 --> 00:18:41,850
Agora nós temos um servidor VTB e é uma cena que todos os switches no topo estão configurados

230
00:18:41,850 --> 00:18:48,600
como clientes VTB, as máquinas host estão no ataque Villano verde Bil'in e atualmente o número de revisão para o domínio

231
00:18:48,660 --> 00:18:50,320
é o número de revisão.

232
00:18:51,790 --> 00:18:57,200
Portanto, o último número de revisão de configuração é para o domínio VTB.

233
00:18:57,220 --> 00:19:03,580
A Cisco e os vilões que foram configurados nos switches são vilões vermelhos e verdes.

234
00:19:03,580 --> 00:19:06,880
Por favor, note mais uma vez que os switches têm um banco de dados de vilão.

235
00:19:06,880 --> 00:19:13,030
É isso que o VTB atualiza as portas individuais e os switches precisam ser colocados

236
00:19:13,030 --> 00:19:14,460
manualmente no correto.

237
00:19:14,500 --> 00:19:21,000
Agora alguém conecta uma mudança na topologia de, por exemplo, um ambiente de laboratório.

238
00:19:21,400 --> 00:19:27,270
A razão pela qual isso é perigoso é que em um ambiente de laboratório a lente pode ter sido adicionada e

239
00:19:27,610 --> 00:19:32,200
removida e, portanto, o número de revisão pode ser muito maior do que a rede de produção.

240
00:19:32,200 --> 00:19:38,020
Então, vamos supor que, no momento em que o número de revisão é 50, esse switch só tem o

241
00:19:38,020 --> 00:19:39,430
villaine azul configurado nele.

242
00:19:39,430 --> 00:19:44,140
Portanto, os vilões verde e vermelho não existem no banco de dados do vilão.

243
00:19:44,140 --> 00:19:49,750
Muitas pessoas cometem o erro de assumir que, desde que os switches configurados como um cliente

244
00:19:50,260 --> 00:19:53,290
VTB, ele não causará nenhum problema na rede.

245
00:19:53,290 --> 00:19:58,210
Assim, um administrador conectou o comutador e configurou essa porta como um tronco.

246
00:19:58,510 --> 00:20:02,610
Por favor, note mais uma vez que o anúncio ETP enviado apenas através de portas de tronco.

247
00:20:02,710 --> 00:20:08,880
Portanto, vamos supor que, em toda a rede, todos esses links sejam configurados como troncos assim que

248
00:20:08,880 --> 00:20:11,380
esse cliente for adicionado ao domínio VCP.

249
00:20:11,520 --> 00:20:17,980
E o que é realmente assustador é que esse cliente pode ser atualizado automaticamente com as informações da VCP.

250
00:20:18,030 --> 00:20:23,130
Em outras palavras, se estiver configurado com um domínio nold, ele poderá ingressar automaticamente no domínio VCP

251
00:20:23,130 --> 00:20:23,920
atual da Cisco.

252
00:20:24,180 --> 00:20:29,490
E assim que isso acontecer, os dispositivos irão sincronizar seus bancos de dados com o último

253
00:20:29,490 --> 00:20:35,160
número de revisão de configuração, que neste caso é 50 sun todos os switches no domínio ao vivo.

254
00:20:35,160 --> 00:20:41,730
O número de revisão é alterado para 50 porque todos os switches, incluindo o servidor

255
00:20:41,760 --> 00:20:49,080
VTB, serão sincronizados automaticamente para o cliente VTB. Os atuais villans vermelhos e verdes são automaticamente removidos

256
00:20:49,080 --> 00:20:55,230
do banco de dados violento e o único vilão que agora estará disponível nos

257
00:20:55,230 --> 00:20:58,800
bancos de dados violentos. todas essas opções são violentas.

258
00:20:58,800 --> 00:21:05,960
Agora todas as portas em todos os switches que foram manualmente colocados no Villon verde ou

259
00:21:06,090 --> 00:21:07,650
vermelho ou heire desativado.

260
00:21:07,650 --> 00:21:14,810
A questão aqui é que uma porta pertence ao Villon vermelho, mas o Villon vermelho não existe no banco de dados.

261
00:21:14,910 --> 00:21:17,510
Então a porta é desativada automaticamente.

262
00:21:17,790 --> 00:21:23,500
Isso significa que nenhum tráfego pode ser enviado ou recebido no esporte e a mesma coisa acontece em

263
00:21:23,520 --> 00:21:24,720
todos os outros switches.

264
00:21:24,750 --> 00:21:30,030
Essencialmente, o que acontece é que toda a rede é derrubada pela introdução

265
00:21:30,030 --> 00:21:31,200
do único comutador.

266
00:21:31,200 --> 00:21:37,350
Isso é extremamente preocupante, para dizer o mínimo que a introdução de um único switch

267
00:21:37,350 --> 00:21:39,690
pode derrubar toda uma rede corporativa.

268
00:21:39,810 --> 00:21:46,830
A única maneira de corrigir isso é conectar-se fisicamente ao servidor VTB e, em seguida, adicionar manualmente

269
00:21:46,920 --> 00:21:49,200
os vilões que foram excluídos.