1
00:00:03,110 --> 00:00:05,770
Em nossa próxima seção, vamos
falar sobre o dimensionamento de iBGP

2
00:00:05,770 --> 00:00:08,302
técnicas, especificamente
com refletores de rota.

3
00:00:08,302 --> 00:00:10,510
Nesta seção, falaremos
sobre refletores de rota

4
00:00:10,510 --> 00:00:11,740
e clusters de refletores de rota.

5
00:00:11,740 --> 00:00:14,282
E depois disso, vamos
passar pela confederação.

6
00:00:14,282 --> 00:00:16,510
Assim, um refletor de rota iBGP
elimina a necessidade

7
00:00:16,510 --> 00:00:19,450
para malha completa porque só
precisamos fazer o peering com a rota

8
00:00:19,450 --> 00:00:20,590
refletor.

9
00:00:20,590 --> 00:00:22,600
Você pode pensar nisso
análogo ao OSPF

10
00:00:22,600 --> 00:00:26,500
roteador designado ou o sistema intermediário designado IS-IS

11
00:00:26,500 --> 00:00:29,500
porque é usado para
minimizar a replicação de prefixo.

12
00:00:29,500 --> 00:00:31,580
Então enviamos uma atualização
para o refletor de rota.

13
00:00:31,580 --> 00:00:33,580
O refletor de rota
enviará as atualizações

14
00:00:33,580 --> 00:00:34,840
aos seus clientes.

15
00:00:34,840 --> 00:00:37,210
Mas não modificará
nenhum dos outros atributos

16
00:00:37,210 --> 00:00:39,100
ao refletir as rotas.

17
00:00:39,100 --> 00:00:41,470
Por exemplo, analisamos
o processamento do próximo salto

18
00:00:41,470 --> 00:00:44,105
regra do EBGP para o iBGP.

19
00:00:44,105 --> 00:00:46,480
Ainda vamos nos deparar
com esse possível problema, em que

20
00:00:46,480 --> 00:00:50,230
se você não tiver uma atualização
para o valor do próximo salto,

21
00:00:50,230 --> 00:00:53,290
você não pode
usar o prefixo BGP.

22
00:00:53,290 --> 00:00:55,330
Para prevenção de loop,
um refletor de rota

23
00:00:55,330 --> 00:00:58,330
usa o que chamamos
o Cluster-ID.

24
00:00:58,330 --> 00:01:00,370
Assim, cada rota
que envia,

25
00:01:00,370 --> 00:01:04,480
ele define seu próprio ID de origem
na atualização

26
00:01:04,480 --> 00:01:06,318
como o Cluster-ID.

27
00:01:06,318 --> 00:01:08,860
Se a rota retornar e
o refletor de rota a receber,

28
00:01:08,860 --> 00:01:10,610
ele irá descartar
qualquer rota que tenha

29
00:01:10,610 --> 00:01:13,240
seu próprio Cluster-ID integrado.

30
00:01:13,240 --> 00:01:16,900
Portanto, não há problema em os refletores de rota
refletirem um para o outro.

31
00:01:16,900 --> 00:01:19,985
O Cluster-ID vai cuidar
da prevenção de loop.

32
00:01:19,985 --> 00:01:22,360
Os refletores de rota podem ter
três tipos diferentes de pares.

33
00:01:22,360 --> 00:01:25,750
Temos peers EBGP,
peers de cliente iBGP,

34
00:01:25,750 --> 00:01:28,120
e pares não clientes iBGP.

35
00:01:28,120 --> 00:01:30,760
A diferença entre o
cliente iBGP e o não cliente

36
00:01:30,760 --> 00:01:33,790
peers é simplesmente estamos usando
o cliente de refletor de rota

37
00:01:33,790 --> 00:01:36,700
declaração para
o vizinho iBGP.

38
00:01:36,700 --> 00:01:38,980
Mas haverá
processamento de próximo salto diferente

39
00:01:38,980 --> 00:01:41,680
e diferentes regras
de propaganda, dependendo

40
00:01:41,680 --> 00:01:44,300
em que estamos usando.

41
00:01:44,300 --> 00:01:46,900
Portanto, o refletor de rota
processa as atualizações de maneira diferente,

42
00:01:46,900 --> 00:01:50,240
dependendo de que tipo
de peer eles vieram.

43
00:01:50,240 --> 00:01:53,200
Então, se a rota foi aprendida
de um vizinho EBGP,

44
00:01:53,200 --> 00:01:55,840
podemos anunciar isso
para outros vizinhos EBGP,

45
00:01:55,840 --> 00:01:58,690
para outros clientes
e para não clientes.

46
00:01:58,690 --> 00:02:01,090
Se a rota no refletor de
rota veio de um cliente,

47
00:02:01,090 --> 00:02:04,220
podemos anunciá-lo
para colegas, clientes,

48
00:02:04,220 --> 00:02:05,590
e não clientes.

49
00:02:05,590 --> 00:02:07,420
Mas se a rota veio
de um não cliente,

50
00:02:07,420 --> 00:02:09,970
só podemos passar
isso para os pares EBGP

51
00:02:09,970 --> 00:02:12,010
e aos pares do cliente.

52
00:02:12,010 --> 00:02:14,680
E com base nisso, é aqui que
seu posicionamento do refletor de rota

53
00:02:14,680 --> 00:02:17,380
será baseado
nessas três regras.

54
00:02:17,380 --> 00:02:19,660
Para projetos
BGP de maior escala, você

55
00:02:19,660 --> 00:02:22,750
não deve usar um
refletor de rota única.

56
00:02:22,750 --> 00:02:24,340
E os clusters do refletor de rota
estão indo

57
00:02:24,340 --> 00:02:26,720
para permitir redundância
e hierarquia.

58
00:02:26,720 --> 00:02:28,630
Portanto, o cluster é
definido como os clientes

59
00:02:28,630 --> 00:02:30,670
que o refletor de
rota está atendendo.

60
00:02:30,670 --> 00:02:32,260
Refletores de rota
no mesmo cluster

61
00:02:32,260 --> 00:02:35,200
vão usar
o mesmo Cluster-ID

62
00:02:35,200 --> 00:02:37,180
Também podemos fazer rota
por endereço-família

63
00:02:37,180 --> 00:02:37,930
refletores.

64
00:02:37,930 --> 00:02:39,430
Por exemplo, podemos
ter um par

65
00:02:39,430 --> 00:02:42,220
de refletores de rota
para unicast IPv4,

66
00:02:42,220 --> 00:02:44,260
que é o roteamento global
regular e, em seguida,

67
00:02:44,260 --> 00:02:47,110
outro par para IPv6
unicast, que

68
00:02:47,110 --> 00:02:50,020
ser para roteamento global IPv6.

69
00:02:50,020 --> 00:02:53,870
Isso evitará
o compartilhamento do destino dos serviços.

70
00:02:53,870 --> 00:02:56,350
Então, se os refletores da rota IPv6
ficarem inativos,

71
00:02:56,350 --> 00:02:59,240
não necessariamente
afetará a rota IPv4

72
00:02:59,240 --> 00:03:00,640
reflexão.

73
00:03:00,640 --> 00:03:03,280
Para peerings entre clusters
entre os refletores de rota,

74
00:03:03,280 --> 00:03:06,250
estes podem ser peerings
de cliente ou não-cliente.

75
00:03:06,250 --> 00:03:08,900
Dependendo do
design de redundância,

76
00:03:08,900 --> 00:03:11,930
serão mais rotas
duplicadas, mais processamento.

77
00:03:11,930 --> 00:03:16,480
Mas os loops serão
prevenidos pelo Cluster-ID.

78
00:03:16,480 --> 00:03:18,370
Então, por padrão, todos
refletores de rota

79
00:03:18,370 --> 00:03:19,540
estão em um cluster separado.

80
00:03:19,540 --> 00:03:22,540
Eles usam seu roteador
ID como o Cluster-ID.

81
00:03:22,540 --> 00:03:25,000
Se você usar o mesmo Cluster-ID
nos refletores de rota,

82
00:03:25,000 --> 00:03:27,740
então eles não vão
aceitar as atualizações um do outro.

83
00:03:27,740 --> 00:03:30,490
Então isso vai depender
do design de redundância.

84
00:03:30,490 --> 00:03:33,395
Outra opção é usar
refletores de rota virtual.

85
00:03:33,395 --> 00:03:35,020
Portanto, um refletor de rota
geralmente não

86
00:03:35,020 --> 00:03:36,450
precisa estar no caminho
do plano de dados.

87
00:03:36,450 --> 00:03:39,550
É usado apenas para
enviar as atualizações.

88
00:03:39,550 --> 00:03:42,340
Não estamos necessariamente
enviando pacotes através dele.

89
00:03:42,340 --> 00:03:46,930
Podemos usar algo como
IOS-XRv, CSR-1000v ou Quagga,

90
00:03:46,930 --> 00:03:52,203
o processo Linux BGP, para
ser um refletor de rota BGP.

91
00:03:52,203 --> 00:03:53,620
Com os refletores de rota
virtuais,

92
00:03:53,620 --> 00:03:56,380
não há necessidade de instalar
as rotas no RIB ou FIB

93
00:03:56,380 --> 00:03:59,398
se o roteador não estiver
no caminho do plano de dados.

94
00:03:59,398 --> 00:04:01,690
Há um recurso chamado
Download RIB seletivo que

95
00:04:01,690 --> 00:04:03,550
impede que caminhos BGP
sejam instalados

96
00:04:03,550 --> 00:04:06,910
no RIB, que é o comando table
map sob o BGP

97
00:04:06,910 --> 00:04:08,435
processo.

98
00:04:08,435 --> 00:04:10,060
O objetivo disso é
ser capaz de dimensionar

99
00:04:10,060 --> 00:04:12,910
a um número muito alto
de rotas sem ter

100
00:04:12,910 --> 00:04:14,695
para realmente instalar as rotas.

101
00:04:14,695 --> 00:04:17,320
Então você ainda está refletindo,
mas não está instalando

102
00:04:17,320 --> 00:04:20,110
na tabela BGP.

103
00:04:20,110 --> 00:04:24,460
Para confederação, isso também
reduz um iBGP de malha completa

104
00:04:24,460 --> 00:04:28,190
dividindo o AS em
sistemas sub-autônomos menores.

105
00:04:28,190 --> 00:04:30,610
Dentro desse Sub-AS,
temos uma malha completa,

106
00:04:30,610 --> 00:04:32,560
ou temos reflexão de rota.

107
00:04:32,560 --> 00:04:36,190
Entre os Sub-ASes, eles
vão agir como EBGP.

108
00:04:36,190 --> 00:04:38,140
E dispositivos fora
da confederação

109
00:04:38,140 --> 00:04:40,155
não conhece
a estrutura interna.

110
00:04:40,155 --> 00:04:42,280
Veremos que os números
do sistema subautônomo

111
00:04:42,280 --> 00:04:44,280
serão retirados
dos anúncios

112
00:04:44,280 --> 00:04:47,410
quando vamos aos verdadeiros pares EBGP.

113
00:04:47,410 --> 00:04:50,310
Para confederação,
normalmente usamos

114
00:04:50,310 --> 00:04:55,690
ASes no intervalo privado,
que é 64512 até 65535.

115
00:04:55,690 --> 00:04:59,482
E podemos usar um
IGP diferente dentro de cada Sub-AS.

116
00:04:59,482 --> 00:05:01,690
Então poderíamos usar o próximo salto
nos roteadores de borda

117
00:05:01,690 --> 00:05:03,900
para modificar
próximo salto para algo

118
00:05:03,900 --> 00:05:07,770
que temos uma rota para.

119
00:05:07,770 --> 00:05:09,780
O próximo salto, a preferência
local e o MED

120
00:05:09,780 --> 00:05:12,300
são mantidos no
sistema sub-autônomo EBGP

121
00:05:12,300 --> 00:05:13,920
pares.

122
00:05:13,920 --> 00:05:16,770
Para prevenção de loop
em uma confederação,

123
00:05:16,770 --> 00:05:20,970
temos a sequência AS CONFED
e temos o AS CONFED SET.

124
00:05:20,970 --> 00:05:23,130
Esses atributos nunca
deixam a confederação.

125
00:05:23,130 --> 00:05:25,650
Esses serão
os ASes privados, pois estamos

126
00:05:25,650 --> 00:05:29,280
anunciando os prefixos.

127
00:05:29,280 --> 00:05:30,840
Por que temos os dois?

128
00:05:30,840 --> 00:05:33,510
Eles geralmente
conseguem o mesmo objetivo.

129
00:05:33,510 --> 00:05:35,940
Os caminhos de migração são
diferentes entre os dois

130
00:05:35,940 --> 00:05:37,020
deles, porém.

131
00:05:37,020 --> 00:05:39,780
A migração para
confederação é mais difícil

132
00:05:39,780 --> 00:05:41,940
porque você precisa
iniciar o processo BGP.

133
00:05:41,940 --> 00:05:44,190
Você precisa reiniciar
o processo BGP

134
00:05:44,190 --> 00:05:47,160
com o número do sistema
sub-autônomo.

135
00:05:47,160 --> 00:05:49,320
Se você estiver começando
uma configuração em branco,

136
00:05:49,320 --> 00:05:51,240
então a confederação é mais fácil.

137
00:05:51,240 --> 00:05:54,540
Chamamos isso de Greenfield, onde
você está começando do zero.

138
00:05:54,540 --> 00:05:56,610
Migrar para um refletor de rota
é fácil, no entanto.

139
00:05:56,610 --> 00:05:59,520
Você só precisa adicionar os pares
e remover os antigos

140
00:05:59,520 --> 00:06:02,730
que você não precisa.

141
00:06:02,730 --> 00:06:05,190
Para mais informações
sobre isso, há

142
00:06:05,190 --> 00:06:07,170
uma palestra do Google
chamada "BGP aos 18--

143
00:06:07,170 --> 00:06:10,200
Lições em Design de Protocolo",
pelo Dr. Yakov Rekhter.

144
00:06:10,200 --> 00:06:12,270
Ele foi o co-designer do BGP.

145
00:06:12,270 --> 00:06:15,780
Definitivamente um vídeo
interessante, se você tiver algum tempo

146
00:06:15,780 --> 00:06:17,610
dedicar a isso.

147
00:06:17,610 --> 00:06:22,650
E então a apresentação do Cisco Live
BRKRST-3321

148
00:06:22,650 --> 00:06:25,800
é "Escalando BGP".

149
00:06:25,800 --> 00:06:28,890
Vamos dar uma olhada nisso
na linha de comando, onde estamos

150
00:06:28,890 --> 00:06:34,260
vai configurar o roteador
5 como o refletor de rota para AS

151
00:06:34,260 --> 00:06:36,340
100.

152
00:06:36,340 --> 00:06:38,200
Então, a primeira coisa
que vamos fazer é

153
00:06:38,200 --> 00:06:42,840
vamos
pear com o roteador 5.

154
00:06:42,840 --> 00:06:49,700
Então config t, roteador BGP
100, vizinho 150.1.5.5,

155
00:06:49,700 --> 00:06:52,340
remoto-como 100.

156
00:06:52,340 --> 00:07:01,620
Vizinho 150.1.5.5,
fonte de atualização é loopback 0.

157
00:07:01,620 --> 00:07:07,330
Então, isso será em todos
dos clientes, o que

158
00:07:07,330 --> 00:07:14,570
especificamente será
roteador 1, roteador 2, roteador 3,

159
00:07:14,570 --> 00:07:16,340
roteador 4 e roteador 6.

160
00:07:31,810 --> 00:07:40,970
OK, 1, 2, 3, 4 e 6.

161
00:07:40,970 --> 00:07:43,400
Portanto, para o roteador 6, precisamos
estender o domínio IGP.

162
00:07:43,400 --> 00:07:46,760
Se olharmos para o resumo da interface IP OSPF do show--

163
00:07:46,760 --> 00:07:49,670
não estamos executando o OSPF, então vamos
olhar para a interface show IP

164
00:07:49,670 --> 00:07:52,360
apresentação.

165
00:07:52,360 --> 00:07:58,820
Vamos executar o OSPF no
loopback, IP OSPF 1, área 0.

166
00:07:58,820 --> 00:08:04,890
E no show 0/1.146,
IP OSPF 1, área 0.

167
00:08:04,890 --> 00:08:07,600
Mesma coisa no roteador 4 --

168
00:08:07,600 --> 00:08:12,680
show 0/1.146, IP OSPF 1, área 0.

169
00:08:12,680 --> 00:08:16,500
Mostre o resumo da interface IP OSPF.

170
00:08:16,500 --> 00:08:18,820
Também estamos executando
no loopback

171
00:08:18,820 --> 00:08:22,777
e também
no túnel DMVPN.

172
00:08:22,777 --> 00:08:24,610
Além disso, temos um
comprimento ponto a ponto

173
00:08:24,610 --> 00:08:26,950
que vai em direção
ao refletor de rota,

174
00:08:26,950 --> 00:08:30,850
que é o show de interface 0/1.45.

175
00:08:30,850 --> 00:08:33,100
Vamos executar o OSPF nessa
interface também.

176
00:08:35,620 --> 00:08:44,340
E por último no roteador
1, interface gig 0/1.146,

177
00:08:44,340 --> 00:08:45,855
IP OSPF 1, área 0.

178
00:08:48,490 --> 00:08:51,770
Em seguida, no roteador 5, vamos
pear no caminho de volta.

179
00:08:51,770 --> 00:08:54,890
Então, se mostrarmos a seção run
BGP, estaremos

180
00:08:54,890 --> 00:08:58,080
já emparelhando com o roteador 1.

181
00:08:58,080 --> 00:09:03,000
Então temos vizinho
150.1.2.2, remoto-como 100,

182
00:09:03,000 --> 00:09:05,650
fonte de atualização é loopback 0.

183
00:09:05,650 --> 00:09:12,210
Vizinho 150.1.3.3,
remoto-como 100,

184
00:09:12,210 --> 00:09:15,320
update-source-- loopback 0.

185
00:09:15,320 --> 00:09:23,800
Vizinho ao roteador
4 do loopback,

186
00:09:23,800 --> 00:09:26,053
loopback de fonte de atualização 0.

187
00:09:26,053 --> 00:09:27,220
E finalmente, o roteador 6--

188
00:09:27,220 --> 00:09:35,280
150.1.6.6, remoto como 100,
e loopback de fonte de atualização 0.

189
00:09:35,280 --> 00:09:36,810
Em seguida, vamos fazer
algumas propagandas

190
00:09:36,810 --> 00:09:39,590
no processo BGP.

191
00:09:39,590 --> 00:09:47,350
Então, no roteador 3, vamos
anunciar este show 0/1.37.

192
00:09:47,350 --> 00:09:54,620
Se mostrarmos a interface IP
brevemente, 155.1.37.0/24 é o que

193
00:09:54,620 --> 00:09:56,270
vamos anunciar.

194
00:09:56,270 --> 00:10:03,730
Portanto, sob BGP 100,
rede 155.1.37.0,

195
00:10:03,730 --> 00:10:07,890
com máscara 255.255.255.0.

196
00:10:07,890 --> 00:10:10,520
Também anunciaremos
nossos loopbacks no BGP

197
00:10:10,520 --> 00:10:14,560
processo em todos esses dispositivos.

198
00:10:14,560 --> 00:10:23,760
Então roteador 1, roteador BGP 100,
rede 150.1.1.1 com uma máscara

199
00:10:23,760 --> 00:10:24,260
de /32.

200
00:10:27,350 --> 00:10:33,470
Mesma coisa no roteador 2, roteador
BGP 100, rede 150.1.2.2.

201
00:10:33,470 --> 00:10:37,320
com uma máscara de todos os 255's.

202
00:10:37,320 --> 00:10:43,540
Roteador 4, roteador BGP
100, rede 150.1.4.4,

203
00:10:43,540 --> 00:10:46,570
máscara de todos os 255's.

204
00:10:46,570 --> 00:10:48,430
Roteador 5, a mesma coisa--

205
00:10:48,430 --> 00:10:54,850
rede 150.1.5.5
com uma máscara de /32.

206
00:10:54,850 --> 00:11:02,478
E por último, no roteador 6,
rede 150.1.6.6 com máscara

207
00:11:02,478 --> 00:11:03,020
de todos os 255.

208
00:11:05,610 --> 00:11:07,770
Agora, neste ponto,
não configuramos o roteador 5

209
00:11:07,770 --> 00:11:09,588
como o refletor de rota.

210
00:11:09,588 --> 00:11:11,130
Temos apenas os
peerings centralizados

211
00:11:11,130 --> 00:11:12,760
que está indo em direção a eles.

212
00:11:12,760 --> 00:11:15,630
Então, se olharmos
para o show IP BGP,

213
00:11:15,630 --> 00:11:18,330
estamos recebendo
os seis loopbacks,

214
00:11:18,330 --> 00:11:22,578
além disso, estamos recebendo
este 155.1.37.0.

215
00:11:22,578 --> 00:11:24,870
Agora, se olharmos do ponto de vista dos
outros pares,

216
00:11:24,870 --> 00:11:29,018
como no roteador 1,
e mostre o IP BGP,

217
00:11:29,018 --> 00:11:31,060
veremos que não estamos
recebendo os loopbacks,

218
00:11:31,060 --> 00:11:37,480
nem estamos recebendo
o 155.1.37.0.

219
00:11:37,480 --> 00:11:41,270
A razão é que
sob as regras normais,

220
00:11:41,270 --> 00:11:46,960
você não pode pegar uma rota
de um vizinho iBGP

221
00:11:46,960 --> 00:11:51,010
e então anunciá-lo de volta
para outro vizinho iBGP.

222
00:11:51,010 --> 00:11:54,250
Estamos falando de fora
do escopo da reflexão de rota.

223
00:11:54,250 --> 00:11:57,088
Depois de configurar o roteador
5 como um refletor de rota,

224
00:11:57,088 --> 00:11:58,630
então devemos ver
que os loopbacks

225
00:11:58,630 --> 00:12:00,922
serão passados ​​entre
todos os pares do cliente.

226
00:12:03,280 --> 00:12:06,220
Então, no roteador 5, vamos olhar
na seção show run BGP.

227
00:12:09,000 --> 00:12:12,750
E vamos levar
isso para o Bloco de Notas.

228
00:12:12,750 --> 00:12:15,960
Vamos substituir
o loopback 0 da fonte de atualização

229
00:12:15,960 --> 00:12:19,020
com cliente de refletor de rota.

230
00:12:23,150 --> 00:12:24,780
Então 1, 2, 3, 4 e
6-- são todos

231
00:12:24,780 --> 00:12:27,530
serão clientes de refletor de rota
do roteador 5.

232
00:12:36,830 --> 00:12:42,987
Agora, no roteador 1, se olharmos
para o show IP BGP,

233
00:12:42,987 --> 00:12:45,320
devemos ver que estamos
recebendo todos os loopbacks,

234
00:12:45,320 --> 00:12:49,220
além disso, estamos recebendo
o 155.1.37.0.

235
00:12:49,220 --> 00:12:53,660
Então, se fizermos ping em 155.1.37.3,
source loopback 0,

236
00:12:53,660 --> 00:12:55,400
devemos ter IP
acessibilidade para isso.

237
00:12:58,540 --> 00:13:01,100
Além disso, se observarmos
qualquer um dos prefixos individuais,

238
00:13:01,100 --> 00:13:04,390
por exemplo, a rota
do roteador 2, mostre o IP BGP--

239
00:13:04,390 --> 00:13:07,960
este prefixo em particular--
temos dentro da atualização

240
00:13:07,960 --> 00:13:12,640
a lista de clusters, que é
o ID do roteador 5.

241
00:13:12,640 --> 00:13:14,890
Este é o único atributo
que o refletor de rota

242
00:13:14,890 --> 00:13:17,890
está mudando, que
é o Cluster-ID.

243
00:13:17,890 --> 00:13:20,750
Não está modificando
o valor do próximo salto,

244
00:13:20,750 --> 00:13:24,910
o que significa que ainda
precisamos apontar para o IGP

245
00:13:24,910 --> 00:13:28,703
para chegar ao
destino específico.

246
00:13:28,703 --> 00:13:30,120
Agora, no caso
de alguns deles,

247
00:13:30,120 --> 00:13:34,640
também vemos a minúscula
r, o que significa falha de RIB.

248
00:13:34,640 --> 00:13:37,340
A falha do RIB significa que
você tem a rota BGP,

249
00:13:37,340 --> 00:13:40,100
mas você também tem uma rota
IGP que tem uma rota menor

250
00:13:40,100 --> 00:13:41,952
distância administrativa.

251
00:13:41,952 --> 00:13:43,910
Isso ocorre porque estamos
anunciando os loopbacks

252
00:13:43,910 --> 00:13:47,015
no OSPF, além disso, estamos
anunciando-os no BGP.

253
00:13:49,653 --> 00:13:51,320
OK, vamos em frente
e testar a conectividade

254
00:13:51,320 --> 00:13:54,641
para fora do AS para AS 810.1.

255
00:13:54,641 --> 00:14:01,250
Vamos pingar 155.1.10.10,
fonte é loopback 0.

256
00:14:01,250 --> 00:14:04,430
Então, agora, devemos ter total
acessibilidade dentro do AS 100

257
00:14:04,430 --> 00:14:10,240
e para AS 810.1.

258
00:14:10,240 --> 00:14:13,920
E novamente, nossa configuração
final no roteador 5,

259
00:14:13,920 --> 00:14:22,430
se mostrarmos a seção de execução BGP,
estamos especificando o remote-as,

260
00:14:22,430 --> 00:14:23,968
fonte de atualização é loopback 0.

261
00:14:23,968 --> 00:14:26,510
E também especificamos
que são refletores de rota

262
00:14:26,510 --> 00:14:28,490
clientes.

263
00:14:28,490 --> 00:14:31,115
Então, configuração de
refletores de rota BGP--

264
00:14:31,115 --> 00:14:33,740
vimos que o refletor de rota
vai atualizar de forma diferente,

265
00:14:33,740 --> 00:14:37,020
dependendo de que tipo de peer
as atualizações vinham.

266
00:14:37,020 --> 00:14:39,020
Tivemos um problema
no qual estávamos aprendendo rotas

267
00:14:39,020 --> 00:14:40,790
de pares não clientes.

268
00:14:40,790 --> 00:14:43,910
Conseguimos anunciá-los
para pares da EBGP e para clientes,

269
00:14:43,910 --> 00:14:45,568
mas não para outros não clientes.

270
00:14:48,500 --> 00:14:51,705
A configuração em si
é apenas a rota vizinha

271
00:14:51,705 --> 00:14:52,830
declaração do cliente refletor.

272
00:14:52,830 --> 00:14:55,430
Isso está no próprio refletor.

273
00:14:55,430 --> 00:14:57,840
A configuração será
por família de endereços.

274
00:14:57,840 --> 00:14:59,900
Só porque somos um
refletor para a versão IP

275
00:14:59,900 --> 00:15:02,330
4 unicast não
implica que seremos

276
00:15:02,330 --> 00:15:05,347
um refletor para IP versão 6.

277
00:15:05,347 --> 00:15:07,430
O cliente não precisa
especificar que a rota

278
00:15:07,430 --> 00:15:09,210
refletor é um refletor de rota.

279
00:15:09,210 --> 00:15:13,700
Eles apenas têm uma instrução de peering
normal indo em direção a eles.

280
00:15:13,700 --> 00:15:16,100
O BGP Cluster-ID,
podemos manualmente

281
00:15:16,100 --> 00:15:18,025
defina isso se você quiser.

282
00:15:18,025 --> 00:15:20,150
Isso acontecerá se você
tiver vários refletores

283
00:15:20,150 --> 00:15:22,220
dentro do mesmo cluster,
e você quer que eles

284
00:15:22,220 --> 00:15:24,230
ignorar as rotas uns dos outros.

285
00:15:24,230 --> 00:15:27,140
Mas caso contrário, temos
o roteador

286
00:15:27,140 --> 00:15:31,760
O ID será herdado
como o Cluster-ID.

287
00:15:31,760 --> 00:15:34,580
Vimos isso quando
fomos a um dos clientes,

288
00:15:34,580 --> 00:15:36,770
e mostre o IP BGP em uma
das rotas refletidas,