[GTER] OSPF (t)NSSA + MPLS

Andre Almeida andre at bnet.com.br
Wed Dec 28 09:28:31 -02 2016


Jóia, eu apliquei um filtro de advertise no MPLS nas duas bordas, para elas
não anunciarem nada.

Isso fez o efeito de conter as labels de um POP para outro, ou seja, ficou
bem semelhante ao Totally NSSA.

Roteadores de borda dos POPs possuem duas rotas default (static), uma para
a primeira borda e outra para a segunda, sendo que não são ECMP mas sim a
distancia para a primeira borda é menor, fazendo com que ela seja a
principal para upload. E além disso a rota é monitorada via ping, para que
se a primeira borda cair, tenha como automaticamente alterar para a segunda.

Nos roteadores de borda dos POPs, eu ativei distribute for default route,
para que os APs do POP possam usar a label para default route, uma vez que
eles não necessitam nada além da default.
Até ai tudo bem, está funcionando OK.

O intuito era de poder fazer as duas bordas usarem as labels para
encaminhar os pacotes (download) até o cliente, mas quando eu ativo MPLS na
segunda borda, mesmo que tenha somente os roteadores de borda dos POPs como
neighbors, fica lento demais. Não noto aumento de latência em icmp mas todo
tráfego que vem pelo IX SP por exemplo, que está na segunda borda, fica uma
carroça.

Inclusive o próprio acesso a segunda borda, fica muito lento.
Já verifiquei MTU e está ok, até porque os pacotes não estão sendo dropados.

Eu achava que a lentidão era porque havia muitas labels em todo o cenário,
mas mesmo aplicando o filtro de advertise nas bordas (BGP) para deixar o
cenário mais semelhante ao NSSA, continua sendo inviável ativar MPLS na
segunda borda.

Sem o MPLS funciona normal, o tráfego de upload por exemplo, que deve ser
encaminhado para a segunda borda, embora passe antes pela primeira, pelo
fato de ser a default primária dos POPs, ela é encaminhada pois há troca de
rotas via iBGP entre elas.

A única coisa que não fiz foi habilitar MPLS entre as bordas. Ou seja,
sempre que pacotes enviados pelo cliente chegar na primeira borda, vai ser
removida a label (pelo PHP) e vai seguir o caminho normal e decisões a
partir da FIB.

Alguém tem alguma luz ai pra me dar?

Obrigado!

Andre Almeida

Em 27 de dezembro de 2016 10:22, Jader Vieira da Rosa <jader at contato.net>
escreveu:

> Bom dia, aqui utilizamos filtros no mpls de accept e advertise, permitido
> somente as loopbacks.
>
> Em 27 de dezembro de 2016 09:49, Andre Almeida <andre at bnet.com.br>
> escreveu:
>
> > Pessoal, boa tarde.
> >
> > Preciso de ajuda ou explicação para um problema:
> >
> > Em síntese, o cenário é o seguinte:
> >
> >
> > *   Mikrotik
> > *   2 Bordas (CCR e CHR)
> > *   Vários POPs, cada um com sua VLAN
> > *   Cada VLAN com OSPF rodando com área configurada como Totally NSSA
> >
> > ------------------------------------------------------------
> > -------------------------------------------------------------
> > As 2 Bordas fazem adjacência em todos as VLANs.
> > As 2 Bordas recebem todas as rotas de todos os POPs, cada uma na sua
> área.
> >
> > O Objetivo de ter sido Totally NSSA era justamente para impedir as rotas
> de
> > adentrarem de um POP ao outro (sem filtros), uma vez que os pacotes
> > precisam chegar a borda para ser encaminhado, no caso de comunicação
> > inter-pop.
> > E também porque cada painel do POP é um servidor PPPoE, ou seja, mais
> fácil
> > deixar marcada a opção de redistribute connected routes. (LSA
> >
> > Não há sumarização, pois as rotas não adentram uma na outra, e nas bordas
> > não vejo grandes problemas de ter a tabela full.
> > ------------------------------------------------------------
> > -------------------------------------------------------------
> >
> > Quando se habilita MPLS nesse cenário, todos os roteadores de todos os
> POPs
> > recebem diversas labels, uma para cada borda de TODOS os IPs da rede
> > inteira.
> > Ai me complica toda a vida....
> >
> > Alguma forma de resolver?
> >
> > Podem criticar o cenário, estou enviando também pra receber críticas
> > construtivas.
> > Mas o interessante seria me ajudar a resolver o problema atual.
> >
> > Obrigado
> >
> >
> > Att,
> >
> > Andre Almeida
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter



More information about the gter mailing list