1
00:00:03,270 --> 00:00:05,940
A seguir, falaremos
sobre o iBGP versus o EBGP

2
00:00:05,940 --> 00:00:07,560
regras de peering.

3
00:00:07,560 --> 00:00:10,560
Nesta seção, veremos
o transporte iBGP versus EBGP

4
00:00:10,560 --> 00:00:12,750
estabelecimento, a
prevenção do loop,

5
00:00:12,750 --> 00:00:16,440
o significado do próximo salto
e, em seguida, o iBGP versus EBGP

6
00:00:16,440 --> 00:00:17,950
processamento do próximo salto.

7
00:00:17,950 --> 00:00:22,650
Assim, para iBGP, os pacotes padrão
para um tempo de vida de 255.

8
00:00:22,650 --> 00:00:24,330
Isso implica que
os vizinhos não

9
00:00:24,330 --> 00:00:26,850
precisam estar conectados diretamente
desde que tenhamos IP

10
00:00:26,850 --> 00:00:28,650
acessibilidade.

11
00:00:28,650 --> 00:00:30,330
E os pares iBGP,
normalmente somos

12
00:00:30,330 --> 00:00:32,619
vai perscrutá-los
através do loopback.

13
00:00:32,619 --> 00:00:34,350
Então isso vai
nos permitir redirecionar

14
00:00:34,350 --> 00:00:36,900
se uma das interfaces
físicas falhar, e nós

15
00:00:36,900 --> 00:00:41,330
ter um caminho alternativo para o
loopback do par iBGP.

16
00:00:41,330 --> 00:00:43,080
Além disso, isso
será necessário

17
00:00:43,080 --> 00:00:45,930
para algumas aplicações,
como uma camada MPLS 3

18
00:00:45,930 --> 00:00:49,720
VPN, sobre a qual falaremos
com mais detalhes posteriormente.

19
00:00:49,720 --> 00:00:54,030
Por outro lado, os pacotes EBGP
têm como padrão um tempo de vida de 1.

20
00:00:54,030 --> 00:00:55,860
Isso pode ser modificado
se os vizinhos forem

21
00:00:55,860 --> 00:00:58,890
vários saltos com
o vizinho ebgp-multihop

22
00:00:58,890 --> 00:01:03,590
comando ou o comando vizinho
ttl-security hops.

23
00:01:03,590 --> 00:01:07,250
Os peers não multi-hop devem ser
diretamente conectados por padrão.

24
00:01:07,250 --> 00:01:09,910
Assim, podemos modificar se os vizinhos
conectados fazem par

25
00:01:09,910 --> 00:01:10,700
através do loopback.

26
00:01:10,700 --> 00:01:13,560
Podemos emitir o vizinho
disable-connected-check.

27
00:01:13,560 --> 00:01:15,560
Isso se os vizinhos
estiverem conectados diretamente,

28
00:01:15,560 --> 00:01:17,840
mas estamos olhando
entre os loopbacks.

29
00:01:17,840 --> 00:01:20,010
Você pode usar
EBGP multi-hop.

30
00:01:20,010 --> 00:01:22,340
Você pode usar o tempo
de vida, segurança,

31
00:01:22,340 --> 00:01:26,120
ou podemos dizer vizinho
disable-connected-check.

32
00:01:26,120 --> 00:01:29,060
Para prevenção de loop iBGP
, isso vai

33
00:01:29,060 --> 00:01:31,580
ser feito via filtragem de rotas.

34
00:01:31,580 --> 00:01:35,060
A idéia é que uma rota aprendida
iBGP não pode ser anunciada em

35
00:01:35,060 --> 00:01:36,950
outro vizinho iBGP.

36
00:01:36,950 --> 00:01:38,960
Você precisa aprender
as informações diretamente

37
00:01:38,960 --> 00:01:41,070
da fonte original.

38
00:01:41,070 --> 00:01:43,010
O que isso implica
é que estamos

39
00:01:43,010 --> 00:01:45,770
terá que ter uma malha
completa de peerings iBGP, onde

40
00:01:45,770 --> 00:01:47,960
todos estão olhando
com todos os outros,

41
00:01:47,960 --> 00:01:50,810
ou duas exceções, que
chamamos de reflexão de rota, rota

42
00:01:50,810 --> 00:01:53,528
refletores ou confederação.

43
00:01:53,528 --> 00:01:55,820
Portanto, há prós e contras para
todos esses três designs.

44
00:01:55,820 --> 00:01:58,490
Vamos entrar neles
com mais detalhes

45
00:01:58,490 --> 00:02:01,070
enquanto continuamos
nossas configurações.

46
00:02:01,070 --> 00:02:03,320
Para prevenção de loop EBGP
, isso é feito

47
00:02:03,320 --> 00:02:05,910
através do caminho do sistema autônomo.

48
00:02:05,910 --> 00:02:07,820
Então o local
AS-Path é prefixado

49
00:02:07,820 --> 00:02:09,669
para as atualizações de saída.

50
00:02:09,669 --> 00:02:11,720
E quaisquer atualizações
de entrada que contenham

51
00:02:11,720 --> 00:02:13,190
o número do sistema autônomo
local

52
00:02:13,190 --> 00:02:15,210
vão ser descartados.

53
00:02:15,210 --> 00:02:17,660
Podemos modificar isso
com o vizinho allowas-in

54
00:02:17,660 --> 00:02:20,600
ou a substituição
em certos casos

55
00:02:20,600 --> 00:02:25,470
onde precisamos
permitir a entrada do AS.

56
00:02:25,470 --> 00:02:28,610
Por exemplo, se nós
olharmos para o roteador 1

57
00:02:28,610 --> 00:02:38,980
e olhe para o show IP BGP,
vemos o prefixo 155.1.10.0.

58
00:02:38,980 --> 00:02:42,640
Foi originado em AS 810.1.

59
00:02:42,640 --> 00:02:45,130
Então, toda vez que passamos
entre vizinhos EBGP,

60
00:02:45,130 --> 00:02:48,080
o número do sistema autônomo
será prefixado.

61
00:02:48,080 --> 00:02:50,620
Então, ele estará
à esquerda do caminho

62
00:02:50,620 --> 00:02:53,340
que estamos aprendendo.

63
00:02:53,340 --> 00:02:55,240
A importância do próximo salto
no BGP--

64
00:02:55,240 --> 00:02:56,790
temos que lembrar
que o BGP não é

65
00:02:56,790 --> 00:02:58,770
um protocolo de roteamento por conta própria.

66
00:02:58,770 --> 00:03:01,320
É um aplicativo usado
para trocar a camada de rede

67
00:03:01,320 --> 00:03:05,200
informações de acessibilidade, ou
para trocar redes.

68
00:03:05,200 --> 00:03:06,960
Então trocamos
os detalhes da rota,

69
00:03:06,960 --> 00:03:09,630
mas não trocamos
os detalhes do caminho.

70
00:03:09,630 --> 00:03:12,150
Dentro da camada de rede
informações de acessibilidade,

71
00:03:12,150 --> 00:03:14,710
nós contém o prefixo
e seu comprimento,

72
00:03:14,710 --> 00:03:17,070
os atributos como a preferência
local, o AS-Path,

73
00:03:17,070 --> 00:03:20,250
o MED, et cetera,
e então o próximo salto.

74
00:03:20,250 --> 00:03:24,870
Vimos em nosso caso o BGP
próximo salto controla a rota IGP

75
00:03:24,870 --> 00:03:26,070
recursão.

76
00:03:26,070 --> 00:03:28,617
O BGP conhece o próximo salto,
mas não necessariamente

77
00:03:28,617 --> 00:03:30,450
saber qual é a interface
de saída em ordem

78
00:03:30,450 --> 00:03:32,190
para alcançar este próximo salto.

79
00:03:32,190 --> 00:03:35,260
Portanto, o IGP, como o OSPF,
deve ser capaz de realizar

80
00:03:35,260 --> 00:03:36,150
ao longo da recursão.

81
00:03:36,150 --> 00:03:38,790
Caso contrário, a rota
não poderá ser usada.

82
00:03:38,790 --> 00:03:41,380
E vimos isso
de duas maneiras diferentes.

83
00:03:41,380 --> 00:03:46,740
Vimos rotas que iam
do roteador 10 para o roteador 8

84
00:03:46,740 --> 00:03:49,190
e depois para o roteador 1.

85
00:03:49,190 --> 00:03:56,082
O roteador 1 viu o próximo salto
como gig 0/1.58 no roteador 8.

86
00:03:56,082 --> 00:03:58,040
Então, como estávamos indo
na direção inversa,

87
00:03:58,040 --> 00:04:02,180
vimos o loopback do roteador 5
sendo anunciado para o roteador 8.

88
00:04:02,180 --> 00:04:04,580
8 estava anunciando isso para 10.

89
00:04:04,580 --> 00:04:10,550
10 viu o próximo salto como a interface do roteador
5 no show 0/1.58

90
00:04:10,550 --> 00:04:12,470
interface.

91
00:04:12,470 --> 00:04:14,300
Então, duas soluções para isso.

92
00:04:14,300 --> 00:04:18,505
Um, nós fizemos o próximo salto.

93
00:04:18,505 --> 00:04:20,630
Isso mudou o próximo salto
para a interface de loopback

94
00:04:20,630 --> 00:04:23,210
do roteador 8, que é o
endereço de peering que

95
00:04:23,210 --> 00:04:26,720
estavam usando entre
roteador 8 e roteador 10.

96
00:04:26,720 --> 00:04:31,430
A outra maneira que vimos foi apenas
injetar o prefixo no IGP

97
00:04:31,430 --> 00:04:35,540
para que tenhamos uma rota
para essa interface de trânsito.

98
00:04:35,540 --> 00:04:37,970
Então, o resultado da recursão
próxima-hop com falha que vimos

99
00:04:37,970 --> 00:04:40,400
foi a falha na
seleção do melhor caminho.

100
00:04:40,400 --> 00:04:42,740
E a maneira como podemos dizer
no show IP BGP

101
00:04:42,740 --> 00:04:44,360
a saída é se estamos
perdendo o maior

102
00:04:44,360 --> 00:04:49,293
do que assinar na
esquerda dos códigos de status.

103
00:04:49,293 --> 00:04:51,710
Isso significa que a rota não pode
ser instalada no roteamento

104
00:04:51,710 --> 00:04:55,070
base de informações e
não pode ser anunciado.

105
00:04:55,070 --> 00:04:56,320
Mas por que nos importamos com isso?

106
00:04:56,320 --> 00:04:57,820
É porque diferentes
peerings têm

107
00:04:57,820 --> 00:04:59,880
diferentes regras de processamento
de próximo salto.

108
00:04:59,880 --> 00:05:03,110
Assim, no processamento de próximo salto
iBGP, por padrão,

109
00:05:03,110 --> 00:05:06,680
as atualizações iBGP de saída não
modificam o atributo next-hop,

110
00:05:06,680 --> 00:05:09,620
independentemente do par iBGP.

111
00:05:09,620 --> 00:05:13,220
Podemos modificar isso
com um vizinho next-hop-self

112
00:05:13,220 --> 00:05:15,560
ou com um mapa de rotas
que tenha uma ação que

113
00:05:15,560 --> 00:05:18,610
diz definir IP no próximo salto.

114
00:05:18,610 --> 00:05:21,942
A partir do código mais recente, também
temos o conjunto next-hop-all,

115
00:05:21,942 --> 00:05:24,400
que é usado para inserir
o refletor de rota nos dados

116
00:05:24,400 --> 00:05:25,810
plano.

117
00:05:25,810 --> 00:05:29,200
Isso é usado em um design chamado
MPLS unificado, que não

118
00:05:29,200 --> 00:05:30,500
necessariamente precisa entrar.

119
00:05:30,500 --> 00:05:33,880
Mas lembre-se de que você
pode dizer ao refletor de rota

120
00:05:33,880 --> 00:05:37,630
para definir todos os próximos saltos para si mesmo
se você quiser que o refletor de rota

121
00:05:37,630 --> 00:05:40,030
estar no caminho do plano de dados.

122
00:05:40,030 --> 00:05:43,030
Para processamento de
próximo salto EBGP, por padrão,

123
00:05:43,030 --> 00:05:45,970
as atualizações EBGP de saída
têm a fonte de atualização local

124
00:05:45,970 --> 00:05:48,580
para o vizinho
definido como o próximo salto.

125
00:05:48,580 --> 00:05:51,250
Em outras palavras,
qualquer endereço

126
00:05:51,250 --> 00:05:53,233
que você está olhando
, isso vai

127
00:05:53,233 --> 00:05:55,150
para ser o que o próximo salto
será quando

128
00:05:55,150 --> 00:05:57,220
envie a atualização de BGP de saída.

129
00:05:57,220 --> 00:05:59,080
Então, se a fonte de atualização
é o loopback 0,

130
00:05:59,080 --> 00:06:02,770
o próximo salto será
loopback 0.

131
00:06:02,770 --> 00:06:05,590
Isso pode ser modificado
com o conjunto de ações do mapa de rotas

132
00:06:05,590 --> 00:06:07,720
próximo salto IP.

133
00:06:07,720 --> 00:06:11,265
Ou poderíamos dizer vizinho
próximo salto inalterado.

134
00:06:11,265 --> 00:06:12,640
Neste caso, isso
será

135
00:06:12,640 --> 00:06:16,000
usado para um próximo salto de terceiros,
que tem um caso de canto limitado

136
00:06:16,000 --> 00:06:16,570
inscrição.