forked from libremesh/libremesh.github.io
-
Notifications
You must be signed in to change notification settings - Fork 0
/
pt-br_howitworks.txt
133 lines (94 loc) · 5.63 KB
/
pt-br_howitworks.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
---
title: Como funciona
ref: how_it_works
lang: pt-br
---
Como funciona
============
== Objetivos a alcançar
- Escalabilidade
- Segmentação de redes
- Roaming de camada 2 dentro de certas áreas
- Seleção inteligente de gateway com redundância e possibilidade de escolha do usuário
- Compatibilidade com a maior parte dos cenários existentes
- Um firmware único para toda a rede (roteadores de base, backbone, empresas instalações rápidas, etc)
== O Básico
A infraestrutura de rede do LibreMesh é baseada em 2 camadas:
=== Camada 2 / nuvem
A camada 2 nuvem usa ao protocolo dinâmico de roteamento BATMAN-ADV
image::img/bat-adv.png[batmanadv,100,float="left"]
*******************
advanced é um protocolo de roteamento mesh que é executado no kernel space. Mesmo se a topologia da rede é feita de múltiplos nós e múltiplos hops (saltos), ele a abstrai para um único domínio de
colisão na camada 2. Então, da perspectiva do usuário, toda a mesh vai parecer uma única LAN. Essa arquitetura é muito interessante para fins de roaming, então conexões TCP e UDP não se perdem quando você troca de Access Point (AP).
*******************
=== Camada 3 / rede
Toda rede de camada 3 usa por padrão o protocolo de roteamento BMX
image::img/bmx7.png[bmx7,100,float="left"]
*******************
BMX6 (ou a nova versão BMX7) é um protocolo de roteamento
dinâmico IPV6 que oferece funções muito avançadas e baixo overhead
de rede (graças a estratégia de vetor de distância e uma série de
otimizações). Versão 7 tem, adicionalmente, extensões de roteamento de segurança.
*******************
=== Misturando camadas
Por padrão, todos os nodes executam ambos os protocolos de roteamento (BMX e BAT-ADV), mas em uma VLAN (1) diferente. Então o roteamento é isolado pela camada MAC.
[NOTE]
=========================
A VLAN BMX é sempre a mesma, então todos os nós conectados à camada de link vão procurar uns aos outros.
=========================
[NOTE]
=========================
A VLAN BATADV depende do identificador cloud que é calculado (por padrão) usando o SSID do AP (Access point).
=========================
[IMPORTANT]
=========================
Portanto a rede BMX vai ser única para toda a MESH, mas a rede BAT-ADV pode ficar dividida em muitas nuvens.
=========================
image::img/network1.png[align="center"]
**Essa configuração permite isolar a camada 2/nuvem.** Por exemplo num bairro, um complexo empresarial ou numa rede de hotspots abertos você pode escolher isolar sua LAN do resto da rede. Porém ao mesmo tempo, você pode alcançar os outros nós usando a rede de roteamento da camada 3.
Roaming vai ser disponível dentro da nuvem, então qualquer sessão TCP, video ou chamada SIP pode ser realizada enquanto se move. Por outro lado, graças a segmentação de camada 3, os problemas comumente encontrados na camada 2 de uma rede em bridge (como tempestade de broadcast ou problemas com DHCP) não vão perturbar a operação correta da rede.
[IMPORTANT]
=========================
E tudo isso automático, auto-mágico e transparente para o usuário final.
=========================
image::img/network2.png[align="center"]
== Detalhes
Os WiFI Access Points da mesma cloud compartilham alguns parâmetros:
* SSID, o nome de identificação do WiFi AP
* Endereços IPv4 e IPv6 especiais para anycast.footnote:[IPs compartilhados por vários dispositivos na rede]
* Um MAC address especial para anycast.
* Um servidor DHCP/RA para prover IPs válidos para todos os clientes da cloud.
Então um cliente conectado em um AP pode se mover pela mesh sem precisar renovar seu IP. Até a camada MAC vai ser sempre a mesma do seu ponto de vista.
image::img/network3.png[align="center"]
[NOTE]
======================
Os leases de DHCP (concessão) são compartilhados pela cloud para prevenir colisões
usando A.L.F.R.E.D
link:http://en.wiki.guifi.net/wiki/A.L.F.R.E.D.[A.L.F.R.E.D.]
Desde que os nós compartilhem um mesmo anycast MAC/IP, do ponto de vista do
cliente é totalmente transparente. Portanto o gateway é sempre o mesmo ainda que o nó
mesh que ele esteja anexado seja outro.
======================
image::img/network4.png[align="center"]
Quando um cliente quer sair da LAN (cloud) para conectar a internet ou outra rede, ele vai enviar
um pacote para o anycast especial do gateway. Então o nó onde o cliente está fisicamente conectado
vai tomar conta de todo o resto.
[NOTE]
==============
Uma regra de ebtables .footnote:[ebtables é como uma iptables mas para a camada 2/rede] no AP/LAN previne que os pacotes de propagação de camada 2 na nuvem sejam enviados para o endereço anycast. Então o nó mesh onde o cliente está associado pega o pacote, mas os outros não.
==============
image::img/network5.png[align="center"]
O pacote é roteado através do BMX para o melhor gateway de internet. Pode ser o nó da mesma
cloud ou de alguma outra cloud distante.
[NOTE]
=============
O BMX tem uma funcionalidade de 'inteligência' de gateway bem poderoso que
automaticamente detecta o melhor nó de gateway de internet levando em consideração
a largura de banda
=============
image::img/network6.png[align="center"]
[NOTE]
=============
No caminho de volta o pacote vai chegar no mesmo nó da cloud, mas não
necessariamente no mesmo nó que partiu. Independente disso, o pacote será enviado corretamente para quem o originou. Isso acontece porque o BMX smart gateway usa conexões de túnel de mão única para garantir que o gateway selecionado seja utilizado.
=============