Configurando o MikroTik do Zero

Vamos começar configurando um servidor básico com serviço de autenticação,

escolhi o pppoe pela facilidade e compatibilidade com a maioria dos sistemas
comerciais adotados no mercado além é claro do meu gosto pessoal.

Comecemos escolhendo a versão do MikroTik a utilizar, eu confio e utilizo a

bastante tempo a versão 3.30, 4.17, 5.11, procuro manter uma versão estável
até ter confiança suficiente de que todos os recursos que necessito estejam
funcionando de acordo em uma versão mais atual, que além disso deve ter
novos recursos para merecer um upgrade.

________________________________________________________________
__

Configuração as Interfaces

Dito isso vamos definir o nome das interfaces, começando com ether1 que
vamos re-nomear para “EthLinkD” que será nossa entrada do link, este por sua
vez pode ter qualquer origem seja um link dedicado ou uma adsl, trataremos
disso mais tarde.

Sem ordem o sucesso é uma possibilidade remota, na seqüência vamos agora

re-nomear a interface ether2 para “EthClientes”, que como o próprio nome diz
será a interface por onde forneceremos o acesso aos clientes.

O objetivo deste documento não é ser o mais detalhista possível, mas oferecer
uma visão clara de como configurar de maneira ordenada e lógica qualquer
equipamento, a metodologia empregada na implantação depende muito da
necessidade e pré disposições existentes, porém questões como a
nomenclatura a ser utilizada e a seqüência só depende da forma de raciocínio
de quem esta a configurar e do nível de compreensão pretendido para qualquer
usuário que acessar o sistema.

Em seguida faremos as definições de IP que são necessárias ao sistema, note

que ate agora estamos fazendo o acesso via MAC o que é extremamente lento.
Supondo que temos um IP roteado disponível para nosso link, seja ele público
ou privado, vou identificar uma classe que servirá de exemplo durante nossas
explanações.

Classe de IP: 172.16.50.128/29 – Esta será a classe que recebemos do roteador

(dedicado ou adsl não importa), no caso o IP que identifica no gateway será o
primeiro IP 72.16.50.129 e para a configuração do nosso sistema iremos utilizar
o IP 172.16.50.130/29.
________________________________________________________________
__

Configuração da Rota Default

Em seguida devemos informar o default gateway 172.16.50.129 na tabela de

rotas.

Resultando conforme abaixo em nossa tabela de rotas.

Se obtiver resultado diferente do exemplo (como uma rota na cor azul), pode
ser que o IP do gateway não tenha sido encontrado na rede ou que não tenha
definido corretamente o endereço IP na etapa anterior.

________________________________________________________________
__

Configuração do DNS

Vamos agora para a configuração de DNS, eu particularmente confio no DNS

gratuito OpenDNS, porém devo alertar em em certos casos já tive problema por
conta disso, um exemplo é quando um dos clientes sabendo que utiliza dos
serviços do OpenDNS vai até o site deste serviço e cadastra o/os IP’s utilizados
por seu sistema e cria regras de bloqueio (muito úteis inclusive principalmente
para limitar serviços indesejados), fazendo isso qualquer resolução de DNS que
partir dos IP’s informados na regra de filtro passam a ter as limitações impostas
em tais filtros, imagine um usuário mal intencionado bloqueando os serviços de
redes sociais, isso iria gerar uma revolta entre os clientes e com certeza não
desejamos algo desse tipo.

Portanto se utilizar deste serviço tenha certeza de que está imune a condição
citada, outro DNS que posso sugerir são do Google que apresentam na maioria
dos casos bom tempo de resposta e disponibilidade, no geral é o que conta,
você pode utilizar os de sua preferência, no exemplo vamos utilizar um DNS do
Google e outro do serviço gratuito OpenDNS.
GoogleDNS: 8.8.8.8/8.8.4.4
OpenDNS: 208.67.222.222/208.67.220.220

Vale ressaltar que a opção “Allow Remote Request” permite utilizar o IP do seu
MikroTik para resolução de DNS e cache deste serviço, sendo desejável eu
recomendo que marque esta opção, tendo o cuidado de bloquear requisições
vindas de fora do seu sistema para este serviço (90% dos casos).

Além disso devemos alterar o “Cache Size” para algo entre 4096 e 8192
possibilitando armazenar o maior número de endereços DNS no MikroTik local
dessa forma agilizando o processo de resolução dos equipamentos cliente
quando fizerem uso do servidor DNS disponível no MikroTik.

Tendo concluído com sucesso esta primeira etapa faremos um teste de ping
para aferir o funcionamento do sistema básico, começando com um teste direto
a um endereço IP. Para tal abra um terminal e digite:

ping 200.221.2.45
O resultado tem que ser como acima, se “packet loss” informar algo diferente
de 0% você tem algum problema de conexão ou então o IP que tentou pingar
não esta mais acessível.

O próximo passo é testar a resposta dos servidores DNS e para isso vamos
executar um ping informando o endereço de um site e não o seu IP.

ping uol.com.br
O resultado deve ser o mesmo anterior.

Desta vez quando efetuamos uma consulta ao DNS cache do MikroTik

encontramos as resoluções já consultadas e com TTL não expirado.
Vamos agora definir um DNS próprio para uso nos clientes deste MikroTik em
questão, faremos isso acessando o DNS Static, utilizaremos um IP qualquer que
no exemplo será 10.0.0.1.

O TTL é o tempo de expiração que vai manter a consulta a este DNS em cache,
quando será necessária nova consulta para resolução do endereço, em certos
casos é interessante manipular este tempo tendo em vista o grande número de
solicitações que podem ser feitas a um mesmo endereço, no caso de haverem
poucas mudanças do IP de destino.

Devemos observar que quando houver a manipulação do TTL padrão o

resultado pode ser um destino que aponta para um endereço que não
corresponde mais ao endereço desejado até a renovação da consulta e
portanto podendo causar falha no acesso, o MikroTik não suporta manipulação
da tabela DNS cache, e se pretende utilizar este serviço recomendo o BIND9
em servidor Linux que além disso oferece muitas outras possibilidades.

Observe que após a inserção do “DNS Static” imediatamente a tabela “DNS

Cache” foi incrementada e o TTL começa a contar até a próxima renovação.
________________________________________________________________
__

Configuração do Concentrador PPPOE

Vamos agora configurar o serviço PPPOE, chamaremos o serviço de ‘PC.PPPoE’

e selecionando a interface pela qual os clientes farão acesso a este serviço
vamos definir os valores padrões deste servidor.

Não faremos nenhuma alteração nos valores de MTU / MRRU / Timeout / Max
Sessions e na maioria dos casos é isso mesmo que recomendo, só altere se
houver uma necessidade que de outra forma não pode ser solucionada.
Marque “One Session Per Host” se desejar que apenas um usuário conecte para
cada cadastro de usuário/senha.
Com relação ao tipo de autenticação suportada pelo serviço até agora entre os
sistemas comerciais que utilizam o FreeRadius só encontrei autenticação PAP,
porém isso pode mudar, se o seu sistema suporta mais de um tipo marque as
respectivas opções suportadas, caso contrario basta manter apenas PAP e
desmarcar as demais, isso inclusive evita comportamento errôneo de alguns
sistemas comerciais em uso hoje em dia.
Recomendo que busque informações adicionais sobre cada método, isso não
vai mudar a sua vida, mas o hábito de pesquisar as opções o tornará apto a
responder as mais diversas perguntas quando questionado.

Obs: se o seu sistema suporta outros métodos eu gostaria de conhecê-lo.

Vamos agora para a configuração do Profile que nada mais é do que as

configurações do plano de acesso ao qual o cliente irá pertencer.

No primeiro plano vamos selecionar algo simples para assimilação rápida,

vamos chamar de ‘PC.Conecta’ fazendo referencia a um plano de entrada onde
o principal objetivo é que acesso a internet. Sendo este um plano básico não
tem como foco a velocidade de acesso, a principal característica deste plano
será sua velocidade de acesso limitada em 128kbps para download e 64kbps
para upload, o que em teoria deve garantir downloads de até 16kb/s e upload
de até 8kb/s.

- criando a pool de endereços ip

Em “Local Address” informaremos o IP que o cliente receberá como gateway e
em “Remote Address” indicamos a “Pool” de IP’s a qual o profile pertence, ou
seja os IP’s que os clientes irão receber após a conexão ter sido estabelecida
com o servidor. Para este primeiro plano vamos criar a “Pool” de nome
‘pool_conecta’ a qual inicia no IP 10.0.0.11 e termina em 10.0.0.249, você deve
estar se perguntando porquê não começar no antes e ir até o final dos IP’s, eu
faço uma reserva em cada pool quando possível para casos especiais em que
eu preciso fixar o IP que um determinado equipamento irá receber.

Como resultado teremos a tabela IP Pool conforme abaixo:

- criando o plano de acesso

Na criação do profile ‘PC.Conecta’, selecionamos a ‘pool_conecta’ para o

“Remote Address” e mantemos os campos Bridge / Incomming Filter / Outgoing
Filter / Address List / WINS Server inalterados, bastando para tanto configurar
apenas o campo “DNS Server”.

Utilizaremos o próprio MikroTik como servidor DNS primário, isso nos trará a
vantagem do DNS Cache, como DNS secundário vamos utilizar um DNS
qualquer informado pela operadora que pode ser obtido junto ao serviço de
atendimento ao cliente ou com uma breve busca na internet. Para este caso
vamos configurar o secundário com o SuperDNS servidor 1 cujo endereço é
dns1.superdns.com.br e seu ip corresponde a 72.233.55.28, entenda que é
apenas um exemplo e não recomendo este como seu DNS secundário.

Ainda no profile em questão, na aba “General” as opções “Use

Compression/Use VJ Compression/Use Encryption” devem ficar na posição ‘no’
e “Change TCP MSS” em ‘yes’, esta segunda pode lhe economizar alguma dor
de cabeça com MSN e coisas do gênero e você pode optar por não utilizar as
configurações indicadas aqui e ainda assim não ter problema algum desde que
saiba o que esta fazendo, não tenha medo de experimentar pois é também
dessa forma que se adquire conhecimento.

Na aba “Limits” vamos utilizar as velocidades relativas ao plano sendo que no

MikroTik como indicado no campo “Rate Limit” onde deve ser informado
primeiro o upload do plano que no caso é o rx do servidor (em relação ao
cliente que é quem vai utilizar o profile) e em seguida informar o download que
é o tx do servidor com as velocidades separadas por “/” da seguinte forma
64k/128k ou ainda 64000/128000. O campo “Rate Limit” permite configurações
bastante diversas com ou sem omissão de parâmetros, vale a pena estudar a
respeito.

Exemplo 1: 64000/128000 ou 64k/128k

2: 51k/102k 64k/128k 40k/81k
3: 51k/102k 64k/128k 40k/81k 8
4: 51k/102k 64k/128k 40k/81k 6 8
5: 51k/102k 64k/128k 40k/81k 128/192 8
6: 51k/102k 64k/128k 40k/81k 128/192 8 32k/64k

Composição do campo “Rate Limit (tx/rx)”

[rx-rate/rx-rate][rx-burst-rate/tx-burst-rate][rx-threshold/tx-threshold][rx-
time/tx-time] [prio/prio] [rx-limit-at/tx-limit-at]

- cadastro de usuário

Para saber mais sobre estas opções consulte o manual do MikroTik e/ou defina
os valores de exemplo em um plano e consulte na tabela “Queue Simple” a fila
do usuário após conexão. Também pode utilizar usar 1M no lugar de 1024k.
Pode-se utilizar k, M ou G.

Configurado o primeiro plano de acesso siga configurando os demais para

outras velocidades, mas antes disso voltamos ao serviço “PC.PPPoE” e
alteramos o “Default Profile” para ‘PC.Conecta’.

Seguindo com a configuração vamos agora cadastrar o primeiro usuário/cliente

para conexão via servidor PPPoE. Acesse o menu “Secrets” e preencha os
campos conforme indicado:

“Name:” testepc
“Password:” senhapc
“Profile:” “PC.Conecta”
“Service:” (pppoe, para outros tipos selecione da lista)
“Caller ID:” (opcional, cadastre o MAC se quiser amarração)
“Local Address:” (opcional, pode usar outro IP que será o gateway)
“Remote Address:” (opcional, IP do cliente que vai pegar do profile)

O campo “Caller ID:” pode ser preenchido com o MAC Address do equipamento
cliente e tem a função de ‘amarrar’ o login/name ao MAC, podemos ainda
preencher o campo “Remote Address” caso desejemos que este login/name
conecte sempre com o mesmo endereço IP.
O campo “Local Address” é fornecido automaticamente pelo profile selecionado
sendo este o gateway da conexão PPPoE, podendo ser informado manualmente
caso haja necessidade.

Curiosidades: em versões antigas (2.x) do MikroTik havia um bug de o cliente

conectar e não navegar, a navegação somente era possível quando o mesmo
recebia outro IP, esta situação era facilmente evitada preenchendo o endereço
do “Local Address” nos cadastros.

________________________________________________________________
__

Configuração do servidor NTP

Importante: configurar as informações de data, hora e localização, alguns

podem achar que é algo desnecessário, eu afirmo que tem muita importância
então vamos a isso. Primeiro configuramos o “Manual Time Zone”, no meu caso
estou em Comodoro que fica no interior do estado de Mato Grosso, sendo
assim o “Time Zone” é -04:00, em seguida acerte os valores da aba “Time”.
Na seqüência configuramos o “NTP Client” para manter nosso relógio em
sincronismo, fazemos isso utilizando os servidores nacionais sendo eles,
‘a.ntp.br’ e ‘b.ntp.br’ ou outro de sua preferência.

Note que ao aplicar a configuração o texto digitado se converte

automaticamente no IP de cada servidor e para isso utiliza o serviço DNS
configurado neste equipamento.

________________________________________________________________
__

Criando o MASCARAMENTO dos IP’s privados

Neste momento dado a natureza dos IP’s que utilizamos na ‘pool_acesso’
vamos criar o mascaramento local para que seja possível o trafego de dados
entre os clientes e a internet.

Acesse IP/Firewall/NAT e insira uma nova regra com as seguintes

características:

Na aba “General”
Chain: srcnat
Src. Address: 10.0.0.0/24 (classe destinada aos clientes)
Out . Interface: EthLinkD

Na aba “Action”
Action: masquerade

Você pode ter feito esse procedimento dezenas de vezes e de várias maneiras
diferentes sem se perguntar por que, neste caso quando fazemos o
mascaramento estamos dizendo para o MikroTik que todas as requisições
vindas dos clientes (pool_acesso, IP’s 10.0.0.0/24) com saída pela interface
“EthLinkD” serão mascaradas pelo NAT, em linhas gerais isso garante que o
firewall seja afetado positivamente para os acessos da sua rede interna, o que
isso significa? Que quando você for fazer utilização de um servidor externo de
quaisquer serviços conectados a outra interface que não seja “EthLinkD” (pode
ser EthIntranet ou outra qualquer), estes serviços irão registrar o IP individual
de quem estiver buscando pelo serviço e não o IP do servidor o qual seria
enviado caso não estivéssemos definindo uma interface especifica para a saída
padrão (leia-se rota default).
Um exemplo prático são os redirecionamentos para servidores de proxy cache,
sem informar a “Out. Interface” o servidor de cache vai entender que todas as
requisições são oriundas do IP do servidor MikroTik que fizer a conexão com o
proxy cache, imagine então se for um servidor de firewall e ou autenticações,
onde todos os usuários chegassem com o mesmo IP.

Feito isso já podemos conectar nosso primeiro cliente ainda que não tenhamos
configurado o servidor de cache, e para tanto se faz necessário configurar um
discador pppoe, seja em um rádio ou no próprio sistema operacional do
usuário.

De posse do usuário e senha cadatrados na “Secrets” conecte um cabo de rede

entre a interface “EthClientes” e o equipamento que fará a discagem, na
maioria dos casos os rádios suportam auto-MDIX, para micros ligados
diretamente ao servidor e placas de rede que não o suportem utilize um cabo
de rede crossover.

http://en.wikipedia.org/wiki/Ethernet_crossover_cable

Após conexão observamos em “Active Connections” a presença da conexão

discada e o respectivo endereço MAC na coluna “Caller ID”.

Na aba “Interface é” possível ver a interface criada pelo pppoe com trafego de
tx/rx (download/upload pois o sentido é servidor>cliente)
Em “Queue List” na aba “Simple Queue” é possível observar o tráfego do cliente
no controle de filas sendo que os valores instantâneos são para o tráfego que
passa pelo servidor com destino a internet.

A cor vermelha indica que o trafego excede 75% do valor configurado em “Max
Limit”, outras cores são laranja para 50% e verde para 25%.

________________________________________________________________
__

Integração ao sistema de cache NIMOC Power

Comecemos por configurar a interface que fará a comunicação com o cache,

neste caso especifico recomendo a instalação de uma interface com o único
propósito de se comunicar com o servidor de cache.

Vamos agora re-nomear a interface ether3 para “EthCache”, que como o

próprio nome diz será a interface exclusiva que será conectada ao NIMOC
Power.

Vamos agora configurar a conexão entre o MikroTik e o servidor de cache, no

MikroTik acesse o menu ‘IP / Address’ e configure o seguinte IP
192.168.10.253/30 na interface “EthCache”, este será o gateway e dns
secundário do servidor de cache.

Feito isso configure o seu servidor de cache N!MOC com as seguintes

informações.
IP Address: 192.168.10.254
Mascara: 255.255.255.252
Gateway: 192.168.10.253
Dns primário: 127.0.0.1
Dns secundário: 192.168.10.253

Para tanto vamos utilizar o aplicativo ‘niconfig’ que se encontra presente no

sistema instalado a partir do N!MOC INSTALLER CD:

Tento logado como root digite no console do N!MOC Linux:

niconfig <ENTER>
Caso sua placa de rede seja identificada diferente de ‘eth0’, não há problema
apenas lembre em qual interface você configurou o IP para futuras
configurações ou consultas se necessárias.

Na seqüencia vamos configurar IP 192.168.10.254 e mascara de rede

255.255.255.252, esta classe possui apenas os 2 IP’s livres para uso que
necessitamos na comunicação entre os dois servidores.
Ao final clique aceitar sobre a seleção SAIR.

Antes que comece a se questionar sobre o que acabamos de fazer e o uso do

sistema de cache com suporte a TPROXY quero adiantar que dessa forma será
possível e sem nenhuma limitação o uso do TPROXY tanto para IP’s públicos
quanto de IP’s privados, os IP’s configurados acima não influenciam no uso
desse recurso e só servem para o transito das demais classes de IP.

Obs: N!MOC Power LYE tem suporte a TPROXY em LINUX/BSD além de muitos
outros recursos importantes para a configuração de uma rede profissional.

Note que os IP’s de gateway e dns indicam que o MikroTik será o gateway e
dns secundário do servidor de cache e portanto todo trafego que o servidor de
cache solicitar irá passar pelo MikroTik, para isso devemos configurar o
mascaramento desta classe em ‘IP / Firewall / NAT’, adicione uma nova regra
da mesma forma que o fizemos quando criamos o mascaramento para os
clientes.
Na aba “General” no campo “Chain” selecione ‘srcnat’ em seguida no campo
“Src. Address:” digite 192.168.10.252/30 que será destinada a comunicação
entre o cache e o MikroTik, em seguida no campo “Out Interface” selecione a
interface utilizada na comunicação com a internet “EthLinkD”, e por último na
aba “Action” e campo de mesmo nome selecione ‘masquerade’.

E com isso concluímos o mascaramento da rede que dará suporte ao servidor

de cache.

Nossa tabela NAT deve agora estar como abaixo:

Agora vamos criar as marcações para o desvio do trafego via tabela mangle
para redirecionar as requisições da porta 80 até o cache N!MOC seguindo o
exemplo a seguir .
Acesse IP / Firewall / Mangle e insira uma nova regra, na abra “General”
selecione a “Chain” prerouting, “Protocol” tcp e “Dst. Port” 80 ainda em “In.
Interface” selecione a ‘EthCache’ e marque a flag “!” que significa negação, ou
seja todas as interfaces menos esta, na aba “Extras” em “Src. Address List”
informe o nome da lista que irá conter a lista que irá conter os IPs dos clientes
e servidores internos que não deverão passar pelo cache. Em seguida informe
em “Dst. Address List” a lista de IPs que irá conter os endereços de sites da
internet os quais não deseja que passem pelo cache, e não esqueça de marcar
a flag de negação “!” para ambas as listas.

Vamos agora para a aba “Action” e na opção de mesmo nome selecionamos

“mark routing” e em “New Routing Mark” nossa marcação de rota personalizada
chamaremos de “to_nimoc”, com relação a flag “Passthrough” podemos deixar
marcada se desejamos que o trafego continue a ser analisado pelas regras
seguintes da tabela ou desmarcarmos se não quisermos, é relativo e depende
muito do que se vai fazer nas regras seguintes, no exemplo deixaremos
marcada pois nosso exemplo será limitado e não teremos regras conflitantes
que poderiam sobre gravar nossa marcação.

Esta regra como foi concebida fará a marcação de rota sobre os IP’s
10.0.0.0/24 utilizados pelo plano/profile ”PC.Conecta” do “PPPoE Server” com a
identificação de ‘to_nimoc’.

IMPORTANTE: Quando os IP’s a receber a marcação forem privados e

mascarados, não há necessidade de tratar o retorno e a regra acima fará toda a
marcação necessária bastando adicionar uma rota na tabela de rotas, porém
quando se tratar de uma classe de IPs públicos ou mesmo uma classe cujo
mascaramento estiver atrás do equipamento onde estamos fazendo esta
marcação fazendo com que utilizemos o TPROXY, existe a necessidade de
tratarmos o retorno conforme a regra que segue.
Acesse IP / Firewall / Mangle e insira uma nova regra, na abra “General”
selecione a “Chain” prerouting, “Protocol” tcp e “Src. Port” 80 ainda em “In.
Interface” selecione ‘EthLinkD’, na aba “Extras” em “Src. Address List” informe
o nome da lista que irá conter os IP’s dos clientes e servidores internos que não
deverão passar pelo cache.

Em seguida informe em “Dst. Address List” a lista de IPs que irá conter os
endereços de sites da internet os quais não deseja que passem pelo cache,
note que aqui invertemos a posição das listas e isso é proposital já que estamos
tratando o trafego de retorno, e por último na aba “Action” no recurso de
mesmo nome selecione “mark routing” e em “New Routing Mark” informamos o
nome da rota que será “to_nimoc” mantendo a flag “Passthrough” marcada.

A tabela acima contém apenas a marcação de rotas necessária para uso com
TPROXY ativado, em caso de TPROXY desativado e classes de IP’s privados
como no exemplo 10.0.0.0/24 só é necessária a primeira regra onde utilizamos
Src. Address e a segunda deve ser eliminada. Vale ainda lembrar que devemos
ter uma regra ou conjunto de regras para cada classe de IP’s que desejamos
marcar as rotas para envio ao cache.

________________________________________________________________
__

N!MOC Power – Regras úteis

Adiciona IP a interface do MikroTik que fará comunicação com N!MOC Power.
Código :
/ip address
add address=192.168.10.253/24 comment=PC.NiMOC disabled=no interface=EthCache

Ativa resolução DNS para equipamentos remotes.

Código :
/ip dns
set allow-remote-requests=yes

Bloqueio de acesso externo ao cache N!MOC Power.

Código :
/ip firewall filter
add action=drop chain=input comment=PC.NIMOC disabled=no dst-port=8080 in-
interface=EthLinkD protocol=tcp

Bloqueio de acesso externo ao DNS N!MOC Power.

Código :
/ip firewall filter
add action=drop chain=input comment=PC.NIMOC disabled=no dst-port=53 in-
interface=EthLinkD protocol=udp

Suporte ao SSH N!MOC Power.

Código :
/ip firewall nat
add action=dst-nat chain=dstnat comment=PC.NiMOC disabled=no dst-port=220
protocol=tcp to-addresses=192.168.10.254 to-ports=22

Suporte ao relatório HTTP N!MOC Power.

Código :
/ip firewall nat
add action=dst-nat chain=dstnat comment=PC.NiMOC disabled=no dst-port=8282
protocol=tcp to-addresses=192.168.10.254 to-ports=82

Marcação de rota para IP privado no N!MOC Power.

Código :
/ip firewall mangle
add action=mark-routing chain=prerouting comment=PC.NIMOC disabled=no dst-
address-list=!sem_cache_dst dst-port=80 in-interface=!EthCache new-routing-
mark=to_nimoc passthrough=yes protocol=tcp src-address=10.0.0.0/24 src-
address-list=!sem_cache_src

Marcação de rota para IP público no N!MOC Power.

Código :
/ip firewall mangle
add action=mark-routing chain=prerouting comment=PC.NIMOC disabled=no dst-
address-list=!sem_cache_dst dst-port=80 in-interface=!EthCache new-routing-
mark=to_nimoc passthrough=yes protocol=tcp src-address=200.201.202.0/24 src-
address-list=!sem_cache_src
add action=mark-routing chain=prerouting comment=PC.NIMOC disabled=no dst-
address=200.201.202.0/24 dst-address-list=!sem_cache_src in-interface=EthLinkD
new-routing-mark=to_nimoc passthrough=yes protocol=tcp src-address-list=!
sem_cache_dst src-port=80

Redirecionamento de rota para N!MOC Power.

Código :
/ip route
add comment=PC.NIMOC disabled=no distance=1 dst-address=0.0.0.0/0
gateway=192.168.10.254 routing-mark=to_nimoc scope=30 target-scope=10

Lista de IP dos sites que não deverão passar pelo cache N!MOC Power.
Código :
/ip firewall address-list
add address=1.2.3.4 comment="PC.NIMOC - IP DE SITE SEM CACHE" disabled=no
list=sem_cache_dst

Lista de IP dos clientes que não deverão passar pelo cache N!MOC Power.
Código :
/ip firewall address-list
add address=1.2.3.4 comment="PC.NIMOC - IP DE CLIENTE SEM CACHE" disabled=no
list=sem_cache_src

Monitoramento do N!MOC Power e desativação automática de marcações.

Código :
/tool netwatch
add comment=PC.NIMOC disabled=no down-script="/ ip firewall nat set [find
comment=PC.NIMOC ] disabled=yes\r\
\n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=yes"
host=192.168.10.254 interval=5s timeout=2s up-script=\
"/ ip firewall nat set [find comment=PC.NIMOC ] disabled=no\r\
\n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=no"

Monitoramento da internet e desativação automática de marcações.

Código :
/tool netwatch
add comment=PC.NIMOC disabled=no down-script="/ ip firewall nat set [find
comment=PC.NIMOC ] disabled=yes\r\
\n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=yes"
host=8.8.8.8 interval=30s timeout=5s up-script=\
"/ ip firewall nat set [find comment=PC.NIMOC ] disabled=no\r\
\n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=no"
add comment=PC.NIMOC disabled=no down-script="/ ip firewall nat set [find
comment=PC.NIMOC ] disabled=yes\r\
\n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=yes"
host=200.221.2.45 interval=30s timeout=5s up-script=\
 "/ ip firewall nat set [find comment=PC.NIMOC ] disabled=no\r\
\n/ ip firewall mangle set [find comment=PC.NIMOC ] disabled=no

________________________________________________________________
__

Cache Full

Chegamos a um ponto importante, tanto se ouve falar em Cache Full que a

definição propriamente dita se torna confusa, seria um cache cheio ?

Cache Full na definição dos usuários que o utilizam significa enviar o conteúdo
web normalmente do tipo multimídia e armazenado em proxy cache local para
os usuários/clientes da rede furando o controle de banda convencional da
“Queue Simple” utilizando para isso a marcação de pacotes e a “Queue Three”
que comumente é utilizada para controle em sistemas de QoS.

O mais comum encontrado em dezenas de paginas web é baseado na

marcação de pacotes contendo o parâmetro o que pode ser feito pela tabela
“Mangle” na “Chain” postrouting, em seguida na aba “Advanced” em “Content”
digitando ‘X-Cache: HIT’ seguindo para a aba “Action” em campo de mesmo
nome selecione ‘mark packet’ e em “New Packet Mark” digite cachefull. Sequer
darei um exemplo utilizando a “Queue Three” por considerar que este método
possui uma série de problemas graves.

No entanto existem outros métodos possíveis que podem ser aplicados, um dos
quais relaciono abaixo tópicos que considero mais importantes.

1 – Marcar os pacotes pelo “DSCP/TOS” e não pela “Content”, isso porque este
segundo método além de inseguro é ineficaz e exige maior processamento.

2 – Informar por onde o trafego adentra ao MikroTik e/ou para onde segue,
isso ajuda a diminuir a carga e evita que a marcação seja utilizada para enviar
algum outro conteúdo forjado com a mesma marcação.

3 – Criar uma “Queue Type” que vai fazer o controle individua de uso do
conteúdo previamente marcado.

4 – Criar uma “Simple Queue” que será responsável por limitar o tráfego que
será enviado para determinada classe de IP’s. E inserir nela o controle
individual como veremos a seguir.

1.1 - Comecemos marcando os pacotes, para isso acesse IP / Firewall / Mangle

e insira uma nova regra, na abra “General” selecione a “Chain” prerouting,
“Protocol” tcp, “In. Interface” EthCache, na aba “Advanced” em “DSCP(TOS)”
informe o valor 18 que corresponde a marcação 72 no exemplo.

Ainda na mesma regra na aba “Action”, campo de mesmo nome selecione a

opção ‘mark connection’ e logo abaixo no campo “New Connection Mark” digite
‘conn_nimoc’. Clique em OK e esta pronta esta primeira regra, o que ela faz é
identificar as conexões oriundas do servidor de cache e que contém a marca
desejável recebida via “DSCP/TOS”, ainda falta marcar os pacotes dessas
conexões o que faremos na segunda regra.

Dica: para saber como funciona a relação entre valores basta saber que 0 = 0,
1 = 4, 2 = 8, 3 = 12 e finalmente 18 = 72, portanto multiplique a marcação
informada no MikroTik por 4 e vai obter o valor a ser configurado no parâmetro
DSCP/TOS quando suportado pelo cache. N!MOC Power tem suporte a
DSCP/TOS.

1.2 – Adicione uma nova regra e na abra “General” a “Chain” prerouting, e logo
abaixo no campo “Connection Mark” selecione a marcação chamada
‘conn_nimoc’, vá até a aba “Action” no campo de mesmo nome selecione ‘mark
packet’ e logo abaixo em “New Packet Mark” vamos colocar a identificação dos
pacotes como ‘pack_nimoc’, tendo o cuidado de desmarcar “Passthrough” pois
não queremos que o mesmo pacote esteja sujeito a receber outra marca depois
dessa o que faria com que a marca anterior fosse sobrescrita inutilizando nossa
primeira marcação.

Tabela mangle contendo apenas regras para marcação do conteúdo em cache.

Em “Queue Type” adicione uma nova a qual daremos o nome de
‘nimoc_conecta’ levando o nome do servidor de cache mais o plano de acesso
onde será utilizada. No campo “kind” selecione o tipo ‘pcq’ se não sabe como
funciona cada controle de filas recomendo que busque no manual, o pcq é um
dos mais práticos e faz muito bem o trabalho neste caso.

No campo “Rate” podemos definir duas formas distintas de se trabalhar no caso

do pcq, deixando o campo com valor 0 significa sem limite ou seja, o que for
definido no queue pai será o limite e os casos que se enquadrarem neste queue
type dividirão o valor do limite entre si, pode ser desejável em muitos casos. No
nosso exemplo vamos definir o valor de 256k pois queremos forçar este limite
individual, logo abaixo nos campos “Limit” e “Total Limit” vamos manter os
valores padrões que são adequados para o que já configuramos anteriormente
neste exemplo, é interessante que busquem estas informações nos manuais
pois elas podem fazer a diferença entre um serviço congestionado e uma
internet navegando solta.
Na seqüência temos quatro possíveis opções de classificadores ou “Classifier”,
vamos marcar apenas uma delas que é a “Dst. Address” ou seja do ponto de
vista do servidor “por” endereço de destino.

3.2 – O próximo passo é criar o controle que irá utilizar a “Queue Type” recém
criada, acesse “Queue List” e na aba “Simple Queue” criemos uma nova a qual
iremos chamar de NIMOC-Conecta, em “Target Address” identifique os IP’s que
serão de certa forma favorecidos por ela, no nosso caso os do plano
“PC.Conecta” representados pela classe 10.0.0.0/24, nos campos “Max Limit”
devemos nos preocupar apenas com o “Target Download”, explicarei logo mais,
para este campo vamos utilizar o valor de 2M ou seja 2 Megas.
Seguimos para a próxima aba “Advanced” e nela selecionamos a “Queue Type”
de nome ‘nimoc_conecta’ criada no passo anterior.

Chegamos no pulo do gato, temos agora um controle que restringe em 2 Megas

para toda a classe de IP’s 10.0.0.0/24 que atende os clientes do plano de 128k
sendo que o controle individual quem faz é a “Queue Type” a qual chamamos
de ‘nimoc_conecta’, neste estágio você deve estar se perguntando como
identificar os pacotes oriundos do cache para que tal controle seja somente
para o conteúdo vindo do cache com a marcação que fizemos, para tanto na
aba “Advanced” selecione em “Packet Marks” a marcação criada sobre os
pacotes vindos do cache que chamamos de ‘pack_nimoc’.

O último passo é fazer com que este controle seja sempre o primeiro na lista
“Queue Simple” e para isso basta arrastar para a primeira posição da lista, caso
utilize HOTSPOT irá precisar de um script para que cada vez que alguém logue
no sistema ele redefina a ordem da lista jogando este controle pra primeira
posição, como não é o caso do nosso exemplo vou tomar a liberdade e pular
esta etapa.

Com a solução proposta espero liquidar de vez o chamado CacheFull que só

traz dores de cabeça e deteriora completamente as conexões wireless, não que
o que propomos aqui se implementado erroneamente também não o faça mas
o risco é menor se você compreender o que esta fazendo do que configurar as
cegas.
O resultado dessa implementação é que o cliente ainda terá os 128k de
download quando o trêfego for oriundo da internet porém ele terá mais 256k
quando o conteúdo já estiver em cache totalizando uma banda de navegação
de 384k fazendo o cliente muito mais satisfeito e o provedor muito mais
econômico e competitivo com a banda disponível, como resultado temos uma
melhora significativa em serviços com consumo de streaming, o cliente ainda
consegue navegar pelos sites mais visitados e falar ao skype ou utilizar
tecnologias similares gastando o mínimo de banda do seu link.

________________________________________________________________
__

Repasse de IP Público com exemplo para PPPoE

Exemplo 1:
O Provedor recebe o link dedicado e uma classe /29, utiliza o primeiro IP dessa
classe como gateway e o segundo como IP do seu servidor MikroTik .

1.1 - Neste caso, configure a interface do Link como proxy-arp e a interface dos
clientes como reply-only depois adicione a seguinte regra no MikroTik em NEW
TERMINAL e cole:

Código :
/ ip firewall nat
add chain=dstnat action=passthrough src-address=XX.XX.XX.XX/XX
comment="REPASSE DE IP" disabled=no

Onde XX.XX.XX.XX/XX é o IP/MASCARA que tiver disponível do seu link

Após ter feito isso adicione cada IP no campo 'Remote Address' em 'PPP secret'
para cada cliente que tiver 'IP Público e fixo'. Ou crie uma pool em ‘IP / Pool'
contendo os IPs disponíveis e defina esta 'pool' no 'profile' default de seu
servidor PPPoE ou ainda apenas no profile/plano que estiverem os clientes que
vão receber IP Público e estes terão um IP dinâmico que poderá mudar a cada
nova conexão.

Dica: PROXY-ARP não é o método mais seguro, mas permite alguma

flexibilidade quando não dispuser de muitos IP’s e não tiver acesso à
configuração do roteador de borda.

Dica: Não crie um mascaramento dito 'genérico', mascare apenas as classes de

IP privadas que estiverem em uso. Ex: 10.0.0.0/24

Dica: Sempre informe a 'out-interface' no mascaramento como sendo a

interface do link (EthLinkD).
Dica: Cuidado com programas de gerenciamento para provedores que criam
regras em seu sistema, essa é pode ser a causa de muitos problemas.

Exemplo 2:
O provedor recebe o link dedicado em uma classe e possui outras classes
adicionais para utilizar com clientes, ou ainda pode quebrar em subclasses para
criar seu roteamento interno.
Este é o típico caso onde podemos aplicar o roteamento de forma bastante
simples.
Basicamente o que deve fazer é seguir com o roteamento da operadora 'pra
dentro' da sua estrutura, vamos lá:

2.1 - Coloque um IP público na interface do link.

2.2 - Defina as classes públicas nos pools de IP’s que irá utilizar para seus
usuários e a cadeia de conexão que deverão seguir. Ex: PoolA cai no PoolB
quando estiver cheio e assim por diante, recomendo que faça isso pois terá um
melhor controle e poderá utilizar para cada pool de IP’s um plano diferente e
isso pode ter várias implicações positivas em uma futura QoS.
2.3 - No profile padrão do ‘PPPoE Server’ indique que o 'Local Address' que
será o gateway default dos clientes é o IP público da interface do link, assim o
roteamento estará completo.
Trocando em miúdos, você estará indicando que a rota de saída dos IP’s segue
seu roteamento padrão.

Dica: Nunca mascare classes de IP’s públicos a não ser que tenha uma boa
justificativa, como por exemplo por possuir poucos IP’s pode criar um
mascaramento para cada plano e indicar uma saída para cada plano ou grupo
de clientes ou seja, clientes do planoA/grupoA saem mascarados pelo ip público
A, do B pelo B e assim por diante.

Exemplo 3:
Repassando mais de um IP pela conexão PPPoE utilizando roteamento estático.

3.1 - Defina um IP fixo para o cadastro do secret/usuário em questão no campo

'Remote Address', pode até ser um IP privado.
3.2 - Acesse o menu ‘IP / Route’ e adicione uma rota contendo no destino ‘Dst-
Address’ os IP’s que deseja repassar e no gateway o IP do usuário que definiu
no cadastro do usuário/secret no passo anterior.

Obs.: Se tiver muitos clientes com esta mesma necessidade este método é
inviável e se faz necessário implantar o OSPF para o gerenciamento das rotas.
Na maioria dos casos a implantação é simples e rápida e vai depender de como
a rede estiver configurada.

Exemplo 4:
Repasse de IP público utilizando roteamento interno por OSFP.
No caso de muitas rotas e/ou onde já tiver a autenticação na borda deverá
optar por um método de roteamento dinâmico e uma das vantagens é que com
isso economizará recursos da central, diminuindo o tráfego de broadcast e
possivelmente aumentando a segurança da sua rede de distribuição.

Se for migrar uma bridge de distribuição por exemplo, o primeiro passo é

passar a autenticação para as bordas, e na seqüência rotear os dispositivos
conectados a borda, seguindo em direção a saída do link, com isso será
possível fazer a migração a quente e continuar usufruindo da estrutura em
bridge até a virada total.

OSPF básico é também rápido de fazer configurar, você tem de definir a

network área que fará o transporte redistribuindo a rota default e redistribuir as
conectadas tipo 1 no seu servidor ou apenas as conectadas quando tiver fixa a
rota default.

FIG

Nas bordas precisa configurar a mesma network para o transporte e na

instância redistribuir a rota default e conectadas tipo 2 ou apenas as
conectadas na maioria dos casos.

FIG

Dessa forma teremos o funcionamento esperado e será possível visualizar as

instâncias UP em ambos os lados.
No exemplo temos 22 pontos participando do OSPF na área backbone.

FIG

Também podem existir outras áreas entre a borda e o seu concentrador

aumentando a complexidade e até terminar num anel podendo utilizar essa
topologia como backup de rotas com stp ou rstp e a possibilidade de custos
diferenciados para cada saída permitindo balancear melhor o tráfego.

________________________________________________________________
__

PCC Load Balance

No exemplo utilizaremos Mikrotik 3.30 e 3 links de mesma velocidade.

EthLinkA = Interface do 1º link

EthLinkB = Interface do 2º link
EthLinkC = Interface do 3º link
EthLB = Interface de saída do balance

Quando em modo roteado:

10.1.10.129 = IP do modem A
10.1.10.161 = IP do modem B
10.1.10.193 = IP do modem C

Endereços das interfaces no MikroTtik ROS – PCC Balance

10.1.10.130/27 = IP da interface EthLinkA
10.1.10.162/27 = IP da interface EthLinkB
10.1.10.194/27 = IP da interface EthLinkC
172.22.22.1/30 = IP de saída do balance

Endereço da interface do Servidor - Autenticador

172.22.22.2/30 = IP do servidor conectado a saída do balance

Regras e explanações sobre PCC

Tabela MANGLE – Lista de destinos sem balanceamento

Código :
/ip firewall mangle
add action=accept chain=prerouting comment="PC.SB" disabled=no dst-address-
list=sem_balance in-interface=EthLB

Esta regra aceita as conexões para todos os IP’s de destino que se encontrarem
na lista 'sem_balance' que irão sair pela rota padrão, veja o texto mais adiante.

Tabela MANGLE – Marcação de conexões

Código :
/ip firewall mangle
add action=mark-connection chain=input comment="PC.IN" connection-state=new
disabled=no in-interface=EthLinkA new-connection-mark=conn_na passthrough=yes
add action=mark-connection chain=input comment="" connection-state=new
disabled=no in-interface=EthLinkB new-connection-mark=conn_nb passthrough=yes
add action=mark-connection chain=input comment="" connection-state=new
disabled=no in-interface=EthLinkC new-connection-mark=conn_nc passthrough=yes
Cria as marcas (conn_na, conn_nb, conn_nc) para novas conexões em cada
uma das interfaces (EthLinkA, EthLinkB, EthLinkC)

Tabela MANGLE – Marcação de rotas

Código :
/ip firewall mangle
add action=mark-routing chain=output comment="PC.OUT" connection-mark=conn_na
disabled=no new-routing-mark=to_ra passthrough=no
add action=mark-routing chain=output comment="" connection-mark=conn_nb
disabled=no new-routing-mark=to_rb passthrough=no
add action=mark-routing chain=output comment="" connection-mark=conn_nc
disabled=no new-routing-mark=to_rc passthrough=no
Utiliza as marcações (conn_na, conn_nb, conn_nc) para criar as marcações das
respectivas rotas (to_ra, to_rb, to_rc)

Tabela MANGLE – Peer Connection Classifier (Identificação das

conexões)
Aqui começa o PCC propriamente dito.

Código :
/ip firewall mangle
add action=mark-connection chain=prerouting comment="PC.CON" disabled=no dst-
address-type=!local in-interface=EthLB new-connection-mark=conn_na
passthrough=yes per-connection-classifier=both-addresses:3/0
add action=mark-connection chain=prerouting comment="" disabled=no dst-
address-type=!local in-interface=EthLB new-connection-mark=conn_nb
passthrough=yes per-connection-classifier=both-addresses:3/1
add action=mark-connection chain=prerouting comment="" disabled=no dst-
address-type=!local in-interface=EthLB new-connection-mark=conn_nc
passthrough=yes per-connection-classifier=both-addresses:3/2

Agora utilizando os classificadores (0, 1 e 2) na interface de saída do balance

‘EthLB’ criamos novas marcas de conexão (conn_na, conn_nb, conn_nc).

Note que se tivéssemos 4 links seria aqui que faríamos as alterações para (0, 1,
2 e 3) ficando 4/0, 4/1, 4/2, 4/3 ou ainda se tivéssemos links assimétricos ( Ex:
LinkX de 512k - LinkY de 1024k - LinkZ de 2048k), deveríamos somar os
valores de todos os links e dividir pelo valor do menor link então teríamos:

Exemplo: (512k + 1024k + 2048k )/ 512k = 7

Assim teríamos 7 marcações de PCC indo de 7/0 até 7/6 das quais deveríamos
direcionar a primeira pro link X, a segunda e terceira pro link Y e as quatro
restantes para o link Z fazendo nosso sistema perfeitamente equilibrado, vale
ressaltar que sistemas do tipo ADSL não garantem a banda.

Portanto devemos fazer testes em cada um dos links para aferir as velocidades
possíveis em cada um, já vi muitos casos onde um link desse tipo de 2MB era
melhor do que o de 4MB da mesma operadora instalada no mesmo local, essa
relação depende diretamente da ocupação/uso instantâneo do concentrador da
operadora ao que cada link estiver conectado, normalmente adsl.

Utilizando das novas marcações de conexão (conn_na, conn_nb e conn_nc) do

passo anterior (PCC), criamos uma nova marcação de rota para os pacotes
entrando pela interface EthLB que chamaremos novamente de ‘to_ra’, ‘to_rb’ e
‘to_rc’.

Tabela MANGLE – Peer Connection Classifier (marcação das rotas)

Código :
/ip firewall mangle
add action=mark-routing chain=prerouting comment="PC.MR" connection-
mark=conn_na disabled=no in-interface=EthLB new-routing-mark=to_ra
passthrough=no
add action=mark-routing chain=prerouting comment="" connection-mark=conn_nb
disabled=no in-interface=EthLB new-routing-mark=to_rb passthrough=no
add action=mark-routing chain=prerouting comment="" connection-mark=conn_nc
disabled=no in-interface=EthLB new-routing-mark=to_rc passthrough=no

Assim tendo as conexões devidamente identificadas (conn_nX) e rotas definidas

para cada conexão (to_rX), seguimos para o mascaramento.

Tabela NAT - Mascaramento

Código :
/ip firewall nat
add action=masquerade chain=srcnat comment="PC.MSQ " disabled=no out-
interface=EthLinkA
add action=masquerade chain=srcnat comment="" disabled=no out-
interface=EthLinkB
add action=masquerade chain=srcnat comment="" disabled=no out-
interface=EthLinkC

Vale ressaltar que o mascaramento pode ser feito de várias formas, indicando
por exemplo o IP da interface de saída utilizando a action ‘src-nat’ (no caso de
termos mais de um IP de saída na mesma interface). Pela interface de cada link
como acima, ou ainda apenas mascarando a interface de saída do balance
‘EthLB’ em negação como abaixo, escolha a sua de acordo com o seu
entendimento e necessidade.

Código :
/ip firewall nat
add action=masquerade chain=srcnat comment="PC.MSQ " disabled=no out-
interface=!EthLB

Tabela NAT – DMZ / Demilitarized Zone

Código :
/ip firewall nat
add action=dst-nat chain=dstnat comment=PC.DMZ disabled=no dst-port=!8291 in-
interface=!EthLB protocol=tcp to-addresses=172.22.22.2

O exemplo acima redireciona todas (menos as da porta 8291 que é do acesso

ao winbox) as entradas pelas interfaces ‘diferentes’ da ‘EthLB’, portanto
estamos nos referindo as entradas dos links, para o IP 172.22.22.2 que no caso
será o servidor ligado a saída do balance.

O DMZ evita ter que criar uma regra para cada porta e cria uma zona de acesso
direto havendo correspondência entre as portas, pode-se excluir uma ou mais
portas do DMZ caso tenham um destino diferente.
No caso da porta de origem ser diferente da porta destino, devemos criar uma
regra indicando tal situação e posicioná-la antes da regra do DMZ.

Código :
/ip firewall nat
add action=dst-nat chain=dstnat comment=”PC.WBX” disabled=no dst-port=8292 in-
interface=!EthLB protocol=tcp to-addresses=172.22.22.2 to-ports=8291

A regra acima serve para o acesso do servidor pelo winbox a partir da internet
por qualquer dos links conectados ao balance e deve estar na tabela NAT antes
da regra de DMZ.

Seguimos para a próxima etapa onde iremos definir as rotas padrão e backup
para cada marcação criada até agora.

Tabela ROUTE – Indicação de rotas e redundância

Definimos 3 rotas sendo que cada uma tem um custo diferente e portanto a
primeira terá a preferência (distance=1), caso venha a faltar a segunda
assume(distance=2), em seguida a terceira(distance=3).

Código :
/ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0
gateway=10.1.10.129
add comment="" disabled=no distance=2 dst-address=0.0.0.0/0
gateway=10.1.10.161
add comment="" disabled=no distance=3 dst-address=0.0.0.0/0
gateway=10.1.10.193

Sendo a rota de custo menor (ex: distance=1) a rota padrão (default) para
todas as conexões que não receberem marca de rotas, nesta lista incluem-se os
serviços e destinos da lista ‘sem_balance’ comentada no inicio, portanto é
interessante que este link tenha boa capacidade pois além das conexões
oriundas das marcações irá receber o trafego sem marcação.

Em seguida todas as 3 rotas que utilizam marca de rotas ‘to_ra’, ‘to_rb’ e ‘to_rc’
dividem a carga que foi previamente marcada na tabela mangle.

Enviando ‘to_ra’ para o gateway 10.1.10.129, ‘to_rb’ para o gateway

10.1.10.161 e ‘to_rc’ para o gateway 10.1.10.193 todas com ‘distance=1’ ou
seja, como primeira opção de todas as marcações.

Código :
/ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0
gateway=10.1.10.129 routing-mark=to_ra
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0
gateway=10.1.10.161 routing-mark=to_rc
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0
gateway=10.1.10.193 routing-mark=to_rb

Podemos ainda definir links de backup para cada marcação e no caso se um

dos links cair, o link de backup assume a tarefa de transmitir os pacotes como
fizemos para a rota padrão, agora também para as marcações de rota.

Código :
/ip route
add comment="" disabled=no distance=2 dst-address=0.0.0.0/0
gateway=10.1.10.161 routing-mark=to_ra
add comment="" disabled=no distance=2 dst-address=0.0.0.0/0
gateway=10.1.10.193 routing-mark=to_rc
add comment="" disabled=no distance=2 dst-address=0.0.0.0/0
gateway=10.1.10.129 routing-mark=to_rb

Note que a o gateway de backup para ‘to_ra’ é 10.1.10.161, para ‘to_rb’ é

10.1.10.193 e para a ‘to_rc’ é 10.1.10.129.

Pode-se opcionalmente criar várias rotas de backup com custos (distance)

diferentes até cobrir todas as possibilidades.

Dica: Também é possível fazer com que o próprio Mikrotik ROS disque as
conexões do tipo ADSL/PPPOE aumentando a eficiência do sistema e utilizando
modens em bridge, sendo que neste caso é recomendado fazer o
mascaramento e indicação do gateway ambos pela interface pppoe-out e não
mais pelo IP.

Dica: com relação ao usar o check ping, devemos tomar cuidado pois links de
diferentes tipos tendem a ter diferentes tempos de resposta ao ping e quando
este método é utilizado pode ocorrer desigualdade entre os consumos dos links
apesar de as marcações estarem corretas, isso porque o sistema leva em
consideração o tempo de resposta de cada gateway.

Dica: para que o balance PCC funcione de maneira mais adequada, o menor
link deve ser superior ao maior plano comercializado e a maior eficiência do
balance depende de requisições menores chegando ao balance em grande
quantidade e não a poucas requisições em maior quantidade, lembre-se disso,
balance não é soma de link mas sim a divisão das requisições.

________________________________________________________________
__

DMZ no MikroTik

Se o que você quer no caso é apenas um redirecionamento público/privado e

seu retorno, tens duas formas bastante simples de fazer, por dst-nat e src-nat
ou utilizando netmap, observe os exemplos que seguem.

Adicione o ip público e mascara a interface pública do mikrotik (entrada do

link).

Na tabela NAT adicione uma regra cuja chain dst-nat redirecione o que chegar
para o ip público utilizando também a action dst-nat para o ip privado,
identificando a interface de entrada como sendo o seu link.

Código :
/ip firewall nat
add action=dst-nat chain=dstnat comment="PC.DSTR" disabled=no dst-
address=200.201.202.1 in-interface=EthLinkD to-addresses=10.90.1.1

Na sequencia faça o oposto, mascarando as requisições que chegarem do ip

privado para sairem pelo ip público identificando a interface de saída como
sendo o link.

Código :
/ip firewall nat
action=src-nat chain=srcnat comment="PC.MSQR" disabled=no out-
interface=EthLinkD src-address=10.90.1.1 to-addresses=200.201.202.1

E não esqueça de colocar estas regras antes do seu mascaramento geral para
que tenha o resultado esperado, este é um exemplo de NAT 1:1, você também
pode utilizar o netmap para a função e fazer o repasse para uma range de IPs
sem necessidade de criar uma regra para cada IP.

________________________________________________________________
__

Utilização de Burst no MikroTik

Acredito que a dúvida seja compartilhada com muitos, vou tentar explicar
apartir de exemplo simples o funcionamento do burst.
ML - Max Limit 120k = Máxima taxa de transferência após atingido o limite que
será calculado com base no tempo de 8s podendo atingir a velocidade máxima
de 'Burst Limit = 300k'
BL - Burst Limit 300k = Limite máximo de velocidade usando o recurso de
Burst ou em português 'Rajada' ou ainda ‘Estouro’.
BT - Burst Threshold 96k = Valor que poderá ser consumido para ter direito a
novo BL de 300k
TB - Burst Time 8s = Tempo sobre o qual são calculados os limites de
velocidade

Na prática: o burst é calculado utilizando ciclos com base no TB/16 (dividido

por 16), no exemplo acima teremos o ciclo de calculo executado a cada 0.5s ou
seja, duas vezes por segundo, o que significa dizer que a cada meio segundo
serão analisados os últimos 8s (TB) do tráfego.

De uma forma geral para ter direito ao burst o resultado calculado de BT deve
ser inferior ao valor informado para BT, seguindo fórmula: “(BTT/TB) < BT”,
onde BTT é a média do consumo nos últimos ‘X’ segundos definidos em TB.

Exemplo:
1s 2s 3s 4s 5s 6s 7s 8s
300k + 100k + 200k + 50k + 30k + 200k + 250k + 150k = 1280k
1280k/8s = 160k/s

Sendo a fórmula para a liberação de novo burst “BTT / TB < BT” e o valor
definido de BT atual definido de 96k, o calculo deste ciclo nos mostra o BT em
160k/s, ou seja, maior que 96k, o burst não será liberado e o valor limite
continua sendo de ML.

Ainda que o consumo nos próximos 6 segundos se mantenham em 120k:

250k + 150k + 120k + 120k + 120k + 120k +120k + 120k = 1120k
1120k/8s = 140k/s

O resultado continua acima do valor definido para BT que é de 96k, não tendo
direito a novo burst até que o resultado do ciclo seja inferior a BT.

Suponhamos que nos próximos 2 segundos o consumo caia:

120k + 120k 120k + 120k + 120k + 120k + 12k + 12k = 744k
744k/8s = 93k

Neste instante o valor calculado é inferior ao definido em BT, sendo assim já

estará liberado novamente o valor de BL para a próxima solicitação.

Se você chegou até aqui parabéns, já consegui o que buscava ao escrever este
material.

________________________________________________________________
__

NIMOC Power Cache

Se quiser continuar farei uma explanação sobre o N!MOC Power, um sistema de

cache que desenvolvemos focado em alto desempenho entenda-se isso por
rapidez e alto ganho.

O N!MOC Power incorpora os mais importantes recursos suportados por

servidores cache, trabalha com conteúdo dinâmico e estático dos mais diversos
sites suportando grande volume de carga e armazenamento. Orkut, YouTube,
Microsoft, dezenas de antivírus e sites de conteúdo multimídia de todos os tipos
são suportados, hoje são mais de 480 plugins já disponíveis e mesmo sem a
existência destes todo o trafego que passar pelo NIMOC terá seu conteúdo
analisado e alocado em disco quando configurado.

Suporte nativo a T-PROXY, REDIRECT, DSCP/TOS em diversos níveis,

personalização de plugins e listas são alguns dos recursos básicos presentes.

Recursos inovadores e exclusivos garantem a desempenho superior, a versão

LYE agrega adicionais importantíssimos e na maioria inéditos.

O sistema N!MOC distingue-se dos similares por oferecer um ganho superior

tanto em economia quanto em desempenho, o tempo de resposta é
aproximadamente 6x menor que os demais, podendo ultrapassar incríveis 50x
para abertura de páginas e não estou falando sobre aceleração via “Queue
Type” como alguns podem estar imaginando.

O conteúdo armazenado localmente é passível de uso por outras aplicações,

sendo que nada é adicionado aos arquivos originais, os mesmos são
armazenados da mesma forma que são recebidos ou armazenados na internet
excluído os utilizadores de responsabilidade por hospedar conteúdo ilegal e
mantendo-se dentro das normativas e leis internacionais que protegem alguns
tipos de conteúdo.

O N!MOC tem suporte incluso, você não precisa se preocupar com o suporte do
servidor, faremos isso pra você sem custo adicional e o valor é acessível a
provedores ou empresas de qualquer porte.

Não é necessário acessar nenhum painel, configurar nenhuma opção, basta

ligar o servidor e já estará funcionando, quando e se for necessária alguma
intervenção ela será feita por pessoal altamente capacitado e homologado na
plataforma.

Quando a implantação for feita por nossa equipe, oferecemos a “Garantia Life
Time”, ou seja, pelo tempo que você utilizar o sistema. Só quem tem o melhor
pode oferecer algo assim, garantia por toda a vida do produto só com máxima
qualidade do N!MOC Power LYE.

As atualizações são disponibilizadas sem custo conforme o plano escolhido e

não é necessária uma parada do sistema para 90% das atualizações, ou seja,
as conexões dos usuários não são interrompidas, os downloads não param no
meio e isso significa muito menos aborrecimentos pra você.

Se você tem interesse em ser representante ou desenvolvedor homologado de

aplicações, envie-nos o seu currículo, é necessária experiência em sistemas
operacionais e desejável conhecimento de duas das plataformas suportadas,
nossa intenção não é limitar o número de profissionais homologados, mas
nivelar por cima as solicitações para que os clientes ao receberem o suporte,
este seja adequado e livre falhas.

Fornecemos o treinamento necessário inclusive para o sistema operacional

então se você ainda não possui o conhecimento não deixe de buscá-lo.

E não se esqueça de quando usar ou citar material de terceiro em incluir as

fontes, isso não é vergonha muito pelo contrário é sinal de respeito e
reconhecimento e também nos qualifica.

Meus sinceros agradecimentos ao under-linux, seus mantenedores e

colaboradores que fazem desse o melhor fórum técnico da América Latina.

Ao colega de fórum Anderson Machado por sua dedicação e incontáveis

colaborações, também o meu reconhecimento ao MK-AUTH e seu mantenedor
Pedro Filho e aos demais amigos que conquistei durante estes anos online, os
meus cumprimentos de elevada estima.

Luciano Rampanelli / M4D3

pcram.com.br

msn: m4d3@hotmail.com / skype: m4d3m4n

Encontrou erros? Quer fazer um comentário ou dar sua sugestão?

http://goo.gl/Cw6Kh

Links úteis:
PCQ > http://goo.gl/p9Mfx / ConLiNUXCD > http://goo.gl/IMUtq
PCC > http://goo.gl/0yMZP / 3x1 > http://goo.gl/Kb3L2

Demonstrativo de Resultado NIMOC Power

Exemplo de gráficos após 6 meses da implantação do sistema em uma rede

com 560 usuários, alto ganho entre consumo de banda (em verde) e entrega
para os usuários (em azul) velocidade de acesso que melhorada
exponencialmente a experiência do usuário com conteúdo multimídia sem
comparação.

N!MOC conta com modo turbo um diferencial exclusivo que torna a navegação
muito mais rápida sem depender de outros sistemas. Surpreenda-se com o que
há de melhor em otimização de estrutura para internet com N!MOC Power LYE

DEUS SEJA LOUVADO

Miniaturas de Anexos