Problema BGP

Boa Tarde pessoal , estou com um problema,
Bom tenho BGP e duas sessões fechado, tenho um linkA full routing 200mb, e um outro linkB 250mb fazendo troca de tráfego ( especificamente essa troca de tráfego, a operadoraB anuncia meus prefixos no PTT), meu consumo de dia em dia e assim, 200mb pelo linkB e 110 pelo linkA, Blz. Hoje aconteceu algo muito estranho, o linkA esta tendo consumo excessivo e o linkA não está tendo mais o mesmo consumo, agora esta assim linkA consumo 170mb linkB 53mb, meu trafego esta saindo tudo pelo linkA, e estou com medo de gargalo, liguei em ambas operadoras ela me disseram que pode, filtros meus, mas não alterei meus filtro e estava rodando legal ....

LinkA e LinkB divido os blocos em /24
Local Pref 220 linkB e linkA 200
Dou prioridade para troca de tráfego..

Não sei se vocês entenderam... mas agradeço a atenção e a colaboração de todos!

este é o tipo de dica que vc vai ter que pagar por uma consultoria, qualquer coisa estou a disposição

Jefferson,

Você poderia enriquecer o seu problema, ilustrando com os filtros e anúncios?
Pra mim, sua explicação ficou vaga.

Se você não mexeu em nada, nem eles, tem problema pra frente. Traceroute e looking glass pra te ajudar a resolver o problema, ou como o @Pirigoso disse, consultor.

Att,

tenta colocar um prefixo maior para o link A e deixa o link B com /24

Olá @JeffersonSato!

Seu caso realmente é um caso bem pontual que somente mesmo analisando na prática primeiramente os filtros de entrada e saída qual você aplicou nas sessões BGP da cada Peer e depois de conferido essa parte ir para uma segunda parte para conferir nos LG de algumas operadoras e depois no LG do PTT qual sua operadora do LINK B está te anunciando para saber o que realmente está ocorrendo.

Teoricamente, de acordo como o que você explicou, você está fazendo corretamente a manipulação da engenharia de tráfego de entrada usando o anunciando metade de blocos /24 para um Peer e a outra metade para o outro Peer, com isso conseguindo o balanceamento de tráfego ingress entre esses dois links e assim como também o tráfego egress usando o atributo localpref.

Mas nos informe mais detalhes de informações como:

1) Print dos seus filtros completos de entrada e saída(incluindo os atributos alterados pelo filtro);

2) O LINK B é um link de trânsito IP ou Link de PTT ou Link com Peeering Privado com uma operadora específica(Peering)?

3) O LINK B caso seja trânsito também, recebe FULL route, parcial, ou parcial_default?

4) Você está conectado diretamente ao PTT?


Quem sabe assim conseguimos pelo menos orienta-lo melhor.

Fico à disposição para eventuais esclarecimentos

Anexo 61804

Rafael Themístocles
[Consultor em Redes e Telecomunicações/NGN Network Project Engineer]
http://www.telmetrics.com.br
E-mail: [email protected]
[email protected]
Skype: rafaelthemistocles
Whatsapp: (11)9-5962-2128

Citação:

---

Postado originalmente por JeffersonSato

Boa Tarde pessoal , estou com um problema,
Bom tenho BGP e duas sessões fechado, tenho um linkA full routing 200mb, e um outro linkB 250mb fazendo troca de tráfego ( especificamente essa troca de tráfego, a operadoraB anuncia meus prefixos no PTT), meu consumo de dia em dia e assim, 200mb pelo linkB e 110 pelo linkA, Blz. Hoje aconteceu algo muito estranho, o linkA esta tendo consumo excessivo e o linkA não está tendo mais o mesmo consumo, agora esta assim linkA consumo 170mb linkB 53mb, meu trafego esta saindo tudo pelo linkA, e estou com medo de gargalo, liguei em ambas operadoras ela me disseram que pode, filtros meus, mas não alterei meus filtro e estava rodando legal ....

LinkA e LinkB divido os blocos em /24
Local Pref 220 linkB e linkA 200
Dou prioridade para troca de tráfego..

Não sei se vocês entenderam... mas agradeço a atenção e a colaboração de todos!

---

Galera desculpem a demora para postar,vou mostrar como estão os meus filtros!

Código :

---

/routing filter
add action=discard chain=NRTELECOM-IN disabled=no invert-match=no prefix=\
    19x.xxx.48.0/21 prefix-length=21-24 set-bgp-local-pref=220 \
    set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
    19x.xxx.48.0/21 prefix-length=21 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
    19x.xxx.49.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
    19x.xxx.50.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
    19x.xxx.51.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
    19x.xxx.52.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
    19x.xxx.53.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
    19x.xxx.54.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
    19x.xxx.55.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=discard chain=NRTELECOM-OUT disabled=no invert-match=no \
    set-bgp-prepend-path=""
add action=discard chain=ULTRAWAVE-IN disabled=no invert-match=no prefix=\
    19x.xxx.48.0/21 prefix-length=21-24 set-bgp-local-pref=200 \
    set-bgp-prepend-path=""
add action=jump chain=ULTRAWAVE-IN disabled=no invert-match=no jump-target=\
    BOGONS set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
    19x.XX.48.0/22 prefix-length=22 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
    19x.XXX.48.0/23 prefix-length=23 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
    19x.XXX.50.0/23 prefix-length=23 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
    19x.XXX.52.0/22 prefix-length=22 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
    19x.XXX.52.0/23 prefix-length=23 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
    19x.XXX.54.0/23 prefix-length=23 set-bgp-prepend-path=""
add action=discard chain=ULTRAWAVE-OUT disabled=no invert-match=no \
    set-bgp-prepend-path=""

---

Está desta forma entrei em contato com as duas operadoras... uma delas me informou que pode ser o caso, que a opera A tem conexão com PTT, se eu anunciar /24 para operadora A o trafego maior sairá por ela, então na logica operadora A esta vendendo Link Full com saída para o PTT também.... anunciei /22 e /23 para operadora A ficou legal.... só que hoje foi contrario, o link A caiu a taxa de downlaod e só saia pela operadora B... ai tive que anuciar /24 para operadora A novamente para ficar equilibrado.... que zica.... vlw

Citação:

---

Postado originalmente por thundernew

tenta colocar um prefixo maior para o link A e deixa o link B com /24

---

Bom Tarde Rafael ... nos falamos pelo telefone a um tempo atras, você estava falando sobre entrar no ptt, você dava consultoria e fazia todo processo não sei se lembra.... acho que o meu caso você já conhece, troca de trafego pela NOROESTE TELECOM!

Citação:

---

Postado originalmente por telmetrics

Olá @JeffersonSato!

Seu caso realmente é um caso bem pontual que somente mesmo analisando na prática primeiramente os filtros de entrada e saída qual você aplicou nas sessões BGP da cada Peer e depois de conferido essa parte ir para uma segunda parte para conferir nos LG de algumas operadoras e depois no LG do PTT qual sua operadora do LINK B está te anunciando para saber o que realmente está ocorrendo.

Teoricamente, de acordo como o que você explicou, você está fazendo corretamente a manipulação da engenharia de tráfego de entrada usando o anunciando metade de blocos /24 para um Peer e a outra metade para o outro Peer, com isso conseguindo o balanceamento de tráfego ingress entre esses dois links e assim como também o tráfego egress usando o atributo localpref.

Mas nos informe mais detalhes de informações como:

1) Print dos seus filtros completos de entrada e saída(incluindo os atributos alterados pelo filtro);

2) O LINK B é um link de trânsito IP ou Link de PTT ou Link com Peeering Privado com uma operadora específica(Peering)?

3) O LINK B caso seja trânsito também, recebe FULL route, parcial, ou parcial_default?

4) Você está conectado diretamente ao PTT?


Quem sabe assim conseguimos pelo menos orienta-lo melhor.

Fico à disposição para eventuais esclarecimentos

Anexo 61804

Rafael Themístocles
[Consultor em Redes e Telecomunicações/NGN Network Project Engineer]
http://www.telmetrics.com.br
E-mail: [email protected]
[email protected]
Skype: rafaelthemistocles
Whatsapp: (11)9-5962-2128

---

@JeffersonSato!

Me lembrei! Realmente nos falamos por telefone Jefferson.

Dei uma olhada rápida em como suas rotas estão sendo propagadas nos PTT's quais suas operadoras participam(AS52579 e AS262659) através de servidores LG PTT e dei uma olhada nas informações e filtro quais você publicou aqui no post e tenho alguns apontamentos e recomendações.

Como pode ver nos print's abaixo...

Anexo 61834Anexo 61835Anexo 61836


...constatamos que ambas operadoras qual você utiliza (AS52579 e AS262659) estão anunciando seus blocos nos PTT's quais elas participam, que são PTT-SPO, PTT-SJP e PTT-CAS. O AS52579 está anunciando os prefixos 19x.xxx.49.0/24 à 19x.xxx.55.0/24 corretamente nos PTT's SPO e SJP. Porém no PTT-CAS estão faltando os anúncios dos prefixos 19x.xxx.49.0/24 à 19x.xxx.51.0/24. Além de estra anunciando indiretamente seu prefixo 19x.xxx.48.0/22 no PTT-CAS e PTT-SJP via AS16735 (qual é trânsito do AS52579) devido ao AS16735 ser também trânsito do AS262659 que por sua vez anuncia seus prefixos de Downstreams.

O AS262659 está anunciando esta anunciando corretamente e indiretamente seu prefixo 19x.xxx.48.0/22 no PTT-CAS via AS16735, porém existem alguns problemas de filtro entre seu AS e os AS262659 e AS16735. Veja que no PTT-CAS os os prefixos /24 estão sendo anunciandos pelo AS16735 via AS262659, qual é sua Operadora de Trânsito que deveria estar anunciando somente seu /22 de acordo com seus filtros.

Conclusão:

AS262659 e AS52579 operam corretamente nos PTT's SPO e SJP, porém no PTT-CAS foi identificado problema de filtros que podem ter origem no AS263470(você) ou no AS16735(trânsito do AS52579). Caso seus filtros estejam diferentes da ultima vez que os postou favor desconsiderar esse problema de filtros.

Como ambas operadoras estão anunciando seus prefixos dentro do PTT, o AS262659 anunciando prefixo 19x.xxx.48.0/22 e o AS52579 anunciando prefixos mais específicos de 19x.xxx.49.0/24 á 19x.xxx.55.0/24(exceto PTT-CAS) terá preferência no PTT para tráfegos com destino ao seu AS, resultando em todo seu tráfego no originado pelo PTT sair exclusivamente pelo LINK da NRT(somente no sentido de download) , o que poderia caracterizar em certos momentos uso excessivo de download de somente um dos links uma vez que o LINK da NRT tem função exclusiva de peering privado(de acordo com informações que você passou e consulta a servidores looking glass internacionais da Level 3, pois seus prefixos /21 ou /22 não são anunciados pela NRT para operadoras de trânsito qual ela contrata).Para resolver isso segue recomendações abaixo.


Com base nas rápidas consultas LG dos PTT's, faço as seguintes recomendações:

1-Caso deseje balancear exclusivamente o tráfego de INGRESS originado pelos PTT's com destino ao seu ASN, recomendo que altere seus filtros NRTELECOM-OUT e ULTRAWAVE-OUT para anunciar 19x.xxx.48.0/21 em ambos filtros e 191.242.48.0 / 22 em NRTELECOM-OUT e 191.242.52.0 / 22 em ULTRAWAVE-OUT (exclusivo para balancear o tráfego de entrada);

2-Para dar preferência para seu tráfego de saída continua usando o LOCAL_PREF com prioridade maior para o LINK da NRT e verifique se as rotas da NRT estão realmente recendo prioridade no sentido de EGRESS. Caso não estejam, pode ser um problema do Mikrotik não estar aceitando o uso do atributo Local_Pref. Nesse caso recomendo o uso em conjunto da manipulação da distância administrativa do Peering com a NRT.

Essa solução deve funcionar como solução paleativa pra você já que você tem somente um link operando como Link de trânsito.

Recomendo que também de uma revisada no seus filtros pois como já mencionado, nas consultas de ontem no servidor LG do PTT-CAS, seus prefixos /24 estavam sendo anunciados pelo AS16735 via AS262659(Ultrawave) quando isso não deveria ocorrer.

Cordialmente

Rafael Themístocles
[Consultor em Redes e Telecomunicações/NGN Network Project Engineer]
http://www.telmetrics.com.br
E-mail: [email protected]
[email protected]
Skype: rafaelthemistocles
Whatsapp: (11)9-5962-2128






1-Filtros:

R:

Citação:

---

Postado originalmente por JeffersonSato

Galera desculpem a demora para postar,vou mostrar como estão os meus filtros!

/routing filter
add action=discard chain=NRTELECOM-IN disabled=no invert-match=no prefix=\
19x.xxx.48.0/21 prefix-length=21-24 set-bgp-local-pref=220 \
set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
19x.xxx.48.0/21 prefix-length=21 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
19x.xxx.49.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
19x.xxx.50.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
19x.xxx.51.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
19x.xxx.52.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
19x.xxx.53.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
19x.xxx.54.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=accept chain=NRTELECOM-OUT disabled=no invert-match=no prefix=\
19x.xxx.55.0/24 prefix-length=24 set-bgp-prepend-path=""
add action=discard chain=NRTELECOM-OUT disabled=no invert-match=no \
set-bgp-prepend-path=""
add action=discard chain=ULTRAWAVE-IN disabled=no invert-match=no prefix=\
19x.xxx.48.0/21 prefix-length=21-24 set-bgp-local-pref=200 \
set-bgp-prepend-path=""
add action=jump chain=ULTRAWAVE-IN disabled=no invert-match=no jump-target=\
BOGONS set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
19x.XX.48.0/22 prefix-length=22 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
19x.XXX.48.0/23 prefix-length=23 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
19x.XXX.50.0/23 prefix-length=23 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
19x.XXX.52.0/22 prefix-length=22 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
19x.XXX.52.0/23 prefix-length=23 set-bgp-prepend-path=""
add action=accept chain=ULTRAWAVE-OUT disabled=yes invert-match=no prefix=\
19x.XXX.54.0/23 prefix-length=23 set-bgp-prepend-path=""
add action=discard chain=ULTRAWAVE-OUT disabled=no invert-match=no \
set-bgp-prepend-path=""

---

Boa Tarde Galera, Como o tópico ainda esta aberto gostaria de dizer que ainda não resolvi o problema ...
Vou postar essas fotos representando, o fator que desconheço, realmente não sei se é um problema de BGP, ou se pode ser algum bug do mikrotik.... já entrei em contato com as duas operadoras, ambas dizem que esta tudo ok

qualquer ajuda agradeço!



Anexo 62205Anexo 62206