1
00:00:03,180 --> 00:00:06,100
Em nosso próximo caso, vamos
falar sobre o iBGP em uma malha completa.

2
00:00:06,100 --> 00:00:08,380
Então, por que o iBGP Full Mesh é necessário?

3
00:00:08,380 --> 00:00:10,922
Veremos alguns
exemplos de configuração disso,

4
00:00:10,922 --> 00:00:12,880
e depois falaremos sobre
as vantagens do design

5
00:00:12,880 --> 00:00:16,000
e as desvantagens do projeto.

6
00:00:16,000 --> 00:00:19,550
Assim, o iBGP realiza uma nova
prevenção via filtragem de rotas.

7
00:00:19,550 --> 00:00:23,080
As rotas aprendidas do iBGP não podem
ser anunciadas para outro iBGP

8
00:00:23,080 --> 00:00:24,190
vizinhos.

9
00:00:24,190 --> 00:00:28,660
Isso implica que o iBGP requer
uma malha completa de peerings,

10
00:00:28,660 --> 00:00:31,390
ou um refletor de rota,
ou confederação.

11
00:00:31,390 --> 00:00:33,880
A vantagem do design de malha completa
é que ele oferece

12
00:00:33,880 --> 00:00:35,440
diversidade de caminhos.

13
00:00:35,440 --> 00:00:39,130
Assim, todos os pares BGP aprendem
todos os caminhos de saída possíveis.

14
00:00:39,130 --> 00:00:41,380
Considerando que, se fôssemos
usar um refletor de rota,

15
00:00:41,380 --> 00:00:43,660
anunciamos todas as
rotas para o refletor,

16
00:00:43,660 --> 00:00:46,180
o refletor toma uma decisão
e então anuncia

17
00:00:46,180 --> 00:00:48,640
apenas que uma decisão sobre ele.

18
00:00:48,640 --> 00:00:52,060
Então, nos casos em que estamos tentando
fazer caminhos múltiplos do BGP, às vezes

19
00:00:52,060 --> 00:00:54,580
somos obrigados a fazer uma malha completa
iBGP para

20
00:00:54,580 --> 00:00:56,560
para permitir que isso ocorra.

21
00:00:56,560 --> 00:00:58,690
Isso também permite
fluxos de tráfego ideais

22
00:00:58,690 --> 00:01:01,930
onde todos os pares BGP aprendem
o caminho de saída mais próximo.

23
00:01:01,930 --> 00:01:04,660
A seleção de caminho por padrão
seria baseada na métrica iBGP

24
00:01:04,660 --> 00:01:06,880
para o roteador de saída,
e às vezes isso

25
00:01:06,880 --> 00:01:09,100
é referido ao roteamento
hotpotato, onde

26
00:01:09,100 --> 00:01:12,790
estamos tentando encontrar a saída
mais próxima o mais rápido possível.

27
00:01:12,790 --> 00:01:15,490
A grande desvantagem
disso

28
00:01:15,490 --> 00:01:18,670
é o plano de controle
escalonamento é exponencial.

29
00:01:18,670 --> 00:01:22,270
Então temos n vezes n menos
1 sobre 2 número de peerings.

30
00:01:22,270 --> 00:01:24,850
Então, se tivermos 10 roteadores,
teremos 45 peerings.

31
00:01:24,850 --> 00:01:28,090
Se tivéssemos 100 roteadores, teríamos
quase 5.000 peerings.

32
00:01:28,090 --> 00:01:29,620
Se tivermos 500
roteadores, ele começa

33
00:01:29,620 --> 00:01:31,120
para ficar fora de controle
quantos pares

34
00:01:31,120 --> 00:01:33,300
que precisaríamos manter.

35
00:01:33,300 --> 00:01:37,038
Então, operacionalmente, isso é difícil
de escalar mesmo com automação,

36
00:01:37,038 --> 00:01:38,580
mas com automação,
há muito poucos

37
00:01:38,580 --> 00:01:41,160
soluções prontas para uso
que nos ajudariam

38
00:01:41,160 --> 00:01:44,700
para a malha completa do BGP.

39
00:01:44,700 --> 00:01:46,650
Então, adicionar ou alterar
configuração de peering

40
00:01:46,650 --> 00:01:49,500
será
administrativamente proibitivo.

41
00:01:49,500 --> 00:01:51,210
Para designs de malha parcial
, você não

42
00:01:51,210 --> 00:01:53,440
precisa escolher apenas um projeto.

43
00:01:53,440 --> 00:01:55,920
Por exemplo, você pode
fazer uma malha completa, além de rota

44
00:01:55,920 --> 00:01:57,600
reflexão, mais
confederação, eles

45
00:01:57,600 --> 00:02:00,520
todos podem interoperar
ao mesmo tempo.

46
00:02:00,520 --> 00:02:01,680
O por que você faria isso?

47
00:02:01,680 --> 00:02:04,740
Você pode fazer bolsões de
malha completa para diversidade de caminhos,

48
00:02:04,740 --> 00:02:07,110
e entre clusters,
você pode usar refletores de rota

49
00:02:07,110 --> 00:02:09,710
para maior escala.

50
00:02:09,710 --> 00:02:12,920
Isso é definido na RFC 4456.

51
00:02:12,920 --> 00:02:15,170
Ele diz que um dos principais
componentes da reflexão de rota

52
00:02:15,170 --> 00:02:17,510
abordagem para resolver
o problema de dimensionamento

53
00:02:17,510 --> 00:02:20,630
é que o refletor de rota
resume as informações de roteamento

54
00:02:20,630 --> 00:02:23,680
e reflete apenas o seu melhor caminho.

55
00:02:23,680 --> 00:02:27,890
Então o problema é que você tem
várias rotas para o refletor

56
00:02:27,890 --> 00:02:30,620
e o refletor vai
escolher apenas um desses caminhos

57
00:02:30,620 --> 00:02:32,790
e anunciá-lo em.

58
00:02:32,790 --> 00:02:35,840
Ele diz, tanto Multi-Exit
Discriminators e métricas iBGP

59
00:02:35,840 --> 00:02:38,270
pode afetar a seleção da rota
BGP.

60
00:02:38,270 --> 00:02:39,980
Com certas topologias
de reflexão de rota,

61
00:02:39,980 --> 00:02:41,660
a abordagem de reflexão completa
pode não

62
00:02:41,660 --> 00:02:44,390
produzir a mesma rota
resultado da seleção

63
00:02:44,390 --> 00:02:47,420
como a de uma abordagem
completa de malha iBGP.

64
00:02:47,420 --> 00:02:50,210
Uma maneira de fazer a seleção da rota
a mesma

65
00:02:50,210 --> 00:02:52,850
é configurando
métricas de IGP dentro do cluster

66
00:02:52,850 --> 00:02:55,190
ser melhor do que
métricas de IGP entre clusters,

67
00:02:55,190 --> 00:02:57,873
e manter uma malha
completa dentro do cluster.

68
00:02:57,873 --> 00:03:00,290
Basicamente, eles estão dizendo
que você pode combinar a rota

69
00:03:00,290 --> 00:03:04,340
refletores com uma malha
completa ao mesmo tempo

70
00:03:04,340 --> 00:03:07,850
para evitar este problema
onde o refletor de rota é