https://wiki.brasilpeeringforum.org/api.php?action=feedcontributions&feedformat=atom&user=Leonardo.furtado 2026-05-30T13:05:50Z Contribuições do(a) usuário(a) MediaWiki 1.35.14 https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=4002 2025-12-26T12:47:53Z

<p>Leonardo.furtado: Correções ortográficas.</p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, às vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre control plane e data plane? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil aquilo que estou maquinando lá nos confins da minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas ideias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação, após anos e anos dialogando com diversos profissionais da área, entre alunos, colegas de trabalho e clientes, especialmente quando discutindo (ou apenas observando) a questão de resultados na carreira profissional deles e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?''''' <br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações e afins?''''' <br /> * '''''Com quantas pessoas você já dialogou sobre estagnação em relação a conhecimentos? Pessoas que já atuam na área há alguns anos, mas que estão literalmente estagnadas?''''' <br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um deles!) que possuem, em seus computadores ou até mesmo em HDs externos, uma fartura monstruosa de materiais de todos os tipos... e-books, cursos, PDFs, PPTs etc., mas que, ao mesmo tempo, não conseguem extrair praticamente nada de útil disso tudo, ou que usufruem muito pouco?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;studentholics&quot;, você conhece? Aqueles caras que fazem cursos com frequência, de praticamente tudo, mas que, ao mesmo tempo, aparentemente não veem muita diferença em suas carreiras?'''''<br /> Convenhamos: a quantidade de materiais — fartura mesmo — disponíveis na internet é praticamente infinita, desde artigos, blogs, vídeos, tutoriais, cursos online, sem contar com aquilo que você pode fazer fora da internet, como cursos, seminários e workshops presenciais, entre tantas outras coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, não consegue atingir seus objetivos de carreira. Essas pessoas têm dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos atuais, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus mais de 30 anos de carreira, consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você se identifica com algum deles:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria etc.), mas não tem organização pessoal para usufruir disso (foco, disciplina, compromisso, responsabilidade etc.).'''''<br /> # '''''O indivíduo que não tem recursos suficientes (materiais, acesso a cursos, mentoria etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade etc.).'''''<br /> # '''''O indivíduo que não tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui tanto recursos quanto organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou ainda não obteve o êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta, aliás, recomendo que você também a faça a si mesmo: '''o que esses quatro perfis têm em comum?''' <br /> <br /> As minhas respostas seriam:<br /> # '''Obtenção de conhecimentos e habilidades.''' Sim, esses quatro perfis têm em comum o interesse pela obtenção de conhecimentos como um dos pilares dos objetivos de carreira, juntamente com as habilidades correspondentes aos conhecimentos específicos da área, bem como outros possíveis conhecimentos periféricos. Tudo isso visa, especificamente, neste caso, ao crescimento ou à evolução em suas profissões.<br /> # '''Atitudes e motivações pessoais.''' Para alguns, trata-se de uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos melhor remunerados. Para outros, é a pura satisfação de lidar com algo que lhes dê prazer ou que os capacite a encarar e superar desafios. Para muitos, são as duas coisas!<br /> Mais uma pergunta aqui: é possível identificar os elementos impeditivos comuns a esses quatro perfis? Em outras palavras, por que, com tantos recursos, materiais, cursos e “excesso de informação”, muitos profissionais da área não conseguem adquirir conhecimentos, desenvolver habilidades, construir competências e, consequentemente, evoluir?<br /> <br /> As respostas podem variar de acordo com cada indivíduo, mas a minha resposta mais precisa para essa pergunta seria: o método. O problema, na minha opinião, está no método. O método pode estar ausente, incompleto, desfocado, desviado ou disforme. Método significa &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método''&quot;.<br /> <br /> Eu entendo que, antes de sair estudando tudo o que vê pela frente, lendo indiscriminadamente todo tipo de material, fazendo todos os cursos e exames de certificação que aparecerem, etc., é fundamental que você estabeleça um método. Será exatamente esse método que norteará todo o seu roteiro de ascensão profissional, apontará a direção na qual você deverá navegar, ditará algumas diretrizes essenciais para o êxito dessa empreitada pela busca do conhecimento e responderá a muitas das perguntas e preocupações que você vive no momento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, orientados por objetivos, motivações pessoais e diretrizes do trabalho atual (“''O que eu devo estudar?''”).<br /> ** Validação da aderência dos temas e tópicos (“''O que é relevante para reconhecimento profissional e para meu desempenho ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''”).<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;Qual deverá ser a ordem de prioridades e sequências dos meus estudos?&quot;)<br /> * Elaboração de um plano de estudos. (&quot;Como devo conduzir a minha busca por conhecimentos?&quot;. &quot;''Como desenvolver as minhas habilidades?''&quot;)<br /> ** Metodologias didáticas de ensino e aprendizado.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação, aderência e aptidão.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> ** Educação continuada.<br /> * Etc.<br /> Por isso entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como disciplina, foco, compromisso e tudo mais, tudo deve começar com a definição e a instauração propriamente dita de um método, pois ele deverá compor o alicerce que acomodará todo o resto. E é basicamente por esse modelo ou arranjo de ideias que resolvi organizar este artigo. <br /> <br /> Entenda que este artigo tem uma pegada um tanto pessoal, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em Pedagogia, '''&lt;u&gt;não&lt;/u&gt;''' sou educador ou professor por ofício. Sou apenas um (acredito) qualificado profissional de tecnologia, com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em tantas empresas que já perdi as contas, além de umas 7 mil horas de voo atuando também como instrutor de cursos credenciados dos principais fabricantes. Embora essas credenciais não me qualifiquem como pedagogo ou educador, acho que reúno bagagem o suficiente para, legitimamente, contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito em suas carreiras.<br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando “''como decolar na carreira de tecnologia da informação e comunicação?''”, a minha resposta mais objetiva para essa pergunta seria: '''''conhecimento'''''. Há aqueles que adorariam complicar as coisas e sugerir a incorporação de outros elementos e complexidades, tais como condição social, falta de oportunidades, fator “Q.I.” (“Quem Indica”, o famoso contatinho com o “Comandante Faber Castell” lá da empresa), profissional naturalmente desmotivado por ter percebido, após algum tempo, que aquela profissão não era para ele, entre outros fatores e complicações.<br /> <br /> O fato é que, independentemente disso tudo, você jamais decolará na carreira sem conhecimento. Você pode até ter ótimos conhecimentos e estar com falta de sorte no momento, mas um indivíduo sem conhecimento é um indivíduo pouco útil para esta ou qualquer carreira ou profissão. Você pode até conseguir um emprego na área com conhecimentos fracos ou medianos, mas decolar, jamais!<br /> <br /> No entanto, o termo “conhecimento” é um tanto subjetivo, e precisaríamos explorá-lo com maior propriedade para que conseguíssemos traçar um caminho que, de fato, pudesse levá-lo ao tão desejado êxito na carreira de tecnologia da informação e comunicação (ou “TIC”). E é exatamente essa e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja um iniciante na área ou um profissional já experiente.<br /> <br /> Para provar que o termo “conhecimento” é tão subjetivo para os nossos propósitos e, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimento e como eles se relacionam com nossa carreira na área de TIC ===<br /> Para que tudo faça sentido neste artigo, precisamos entender melhor o uso do termo, desse substantivo chamado “conhecimento”. Afinal, precisamos identificar quais coisas, situações, contextos e propósitos devem estar compreendidos nessa definição, e como isso se manifesta nos diversos tipos de conhecimento, de acordo com alguns dos modelos empregados pelos indivíduos mais “letrados” nessa seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimento que você precisa perseguir para atuar na área de TIC, ou para se especializar em uma determinada tecnologia, variam de acordo com o perfil que você possui hoje ou que pretende ter em um futuro próximo, seja para concorrer a uma nova vaga, buscar um upgrade de nível na área, entre outras situações.<br /> <br /> Para começar, vamos tentar classificar esses padrões de conhecimento que entendo fazerem parte da área de TIC, utilizando inicialmente uma linguagem mais técnica. Na tabela a seguir, focarei nos tipos de conhecimento e em como eles podem estar associados à nossa carreira em TIC. Para esta discussão de casos, deixarei de fora alguns tipos de conhecimento que considero irrelevantes para os propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> <br /> OBS: os “''&lt;u&gt;exemplos relacionados à nossa área de TIC&lt;/u&gt;''” da tabela a seguir mesclam, de forma muito íntima e implícita, “conhecimento” e “habilidade”, mas saiba, desde já, que são coisas distintas. Isso será esclarecido posteriormente neste artigo.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia a dia, obtido principalmente por observação e pela experiência em lidar com os resultados herdados pelo senso comum; conhecimento obtido por meio da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos cientificamente comprovados por meio de métodos, observações associadas a experimentos, e serve para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre questões imateriais e subjetivas, baseado na reflexão e na construção de conceitos e ideias, a partir do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais a determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito baseia-se nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, nesse caso, um conhecimento particular do indivíduo. Frequentemente obtido com base na tentativa e erro.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento se apoia em experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se em experiências pessoais, mais do que em conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações do dia a dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada ideia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada ideia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentos científicos, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou da experimentação, e exato.<br /> |Falível, pois não é definitivo, já que determinada ideia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo, exercitadas sob o senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> * Entrelaçamento quântico <br /> * Tabela Periódica <br /> * Leis de Newton <br /> * Princípio de Arquimedes <br /> * Algoritmo de Dijkstra <br /> |<br /> * &quot;O ignorante afirma, o sábio duvida, o sensato reflete.&quot; (Aristóteles)<br /> * &quot;Só sei que nada sei.&quot; (Sócrates)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> * &quot;Não existem métodos fáceis para resolver problemas difíceis.&quot; (René Descartes)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> * Aplicar um complexo e plástico golpe de capoeira!<br /> * Arriscar-se com êxito fazendo parkour no alto dos edifícios<br /> Em todos estes casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à nossa área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF, com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex.: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fda fluidez na execução d procedimento, o profissional muitas dezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede, com bastante fluidez e obedecendo às guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidade de circuitos digitais, incorporando, em seu trabalho, os conceitos discutidos no &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity) e no &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção na configuração de elementos de rede, relacionando corretamente as áreas funcionais e os controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia impulsionada pelo mercado, liderada por um determinado fabricante e centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing.<br /> * &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se, de certa forma, aos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. <br /> * &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará o mesmo que as implementações RSVP-TE atuais fazem?&quot;. &quot;Vala a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado como marketing/branding do que com soluções técnicas de fato inovadoras?. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados, usando como &quot;bússola&quot; conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e de análise de resultados, incorporando seus próprios padrões e métodos à medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se de incluir sempre o parâmetro &quot;add&quot; no comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}<br /> Note que não está sendo feito qualquer julgamento em termos de “''que tipo de conhecimento é melhor?''”, porque isso simplesmente não existe! Em termos de resultados ou eficácia, um conhecimento empírico pode ser (e muitas vezes é!) o meio mais correto ou indicado para resolvermos um problema, assim como um conhecimento puramente tácito pode promover os resultados desejados de forma mais efetiva do que um conhecimento apenas empírico. Um conhecimento científico não é melhor só porque é baseado em alguma teoria aliada a uma comprovação por método, pois um conhecimento filosófico pode resolver e, com alguma frequência, isso acontece; um desafio que não está sendo possível solucionar com um conhecimento científico. Enfim, acho que você me entendeu.<br /> <br /> Caso você não tenha identificado alguma afinidade ou utilidade entre a tabela acima e a proposta deste artigo, algo como “tudo muito supérfluo!”, sugiro que repense. Apesar de ter um aspecto um tanto teórico, considero de suma importância que você saiba identificar como os seus conhecimentos vigentes estão enquadrados ou tipificados. Lá na frente, isso poderá ser útil na hora de identificar o que precisa ser feito para aprimorar a maneira como você entende o funcionamento de determinadas tecnologias ou soluções, ou ainda quais práticas e processos precisam ser melhorados para um suporte mais efetivo a elas, entre outras situações. Alguns exemplos de como este “''drag &amp; drop''” poderia ser feito:<br /> * '''De tudo o que você sabe dissertar ou executar, em sua forma mais prática ou efetiva (implantar, configurar, operar, prestar suporte), ou seja, tecnologias, equipamentos, soluções, processos e afins, o que de fato você:'''<br /> ** '''''Conhece por herança organizacional, seja na empresa atual, em experiências prévias ou por meio de convívio e troca de experiências com grupos de indivíduos e suas opiniões?''''' <br /> *** Procure identificar e relacionar essas habilidades e competências. <br /> **** Por exemplo, você adquiriu uma habilidade e experiência por meio de um roteiro ou processo interno da empresa (“é assim que você deve fazer”, “assim funciona” ou “não faça isso!”), ou pelo modus operandi do setor da empresa, etc. <br /> *** Estes seriam &lt;u&gt;conhecimentos empíricos&lt;/u&gt;!<br /> ** '''''Conhece por algum processo de validação, com o emprego de práticas documentadas em artefatos de indústria, BCOPs, frameworks, e com eficácia e resultados tecnicamente comprovados?''''' <br /> *** Procure identificar e relacionar essas habilidades e competências. <br /> **** Por exemplo, você adquiriu conhecimentos e experiência em um projeto e implantação de BGP integralmente apoiado por BCPs (BCP 38, 194, 185, MANRS); ou em uma validação de circuito de dados com base no &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt;, etc. <br /> *** Estes seriam os seus &lt;u&gt;conhecimentos científicos&lt;/u&gt;!<br /> ** '''''Conhece a partir de questionamentos de princípios de aderência, aplicabilidade, julgamento de utilidade, associação de benefícios e casos de uso?''''' <br /> *** Procure identificar e relacionar essas habilidades e competências. <br /> **** Por exemplo, você adquiriu conhecimentos e experiência ao conduzir uma análise qualitativa de riscos ou uma matriz funcional de qualidade; ou em questionamentos e dissertações de casos quanto ao uso de determinadas tecnologias e soluções, etc. <br /> *** Estes seriam os seus &lt;u&gt;conhecimentos filosóficos&lt;/u&gt;!<br /> ** '''''Conhece por experiência e vivência próprias, ou seja, tentativa e erro, satisfação e frustração com resultados, etc.?''''' <br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, saber identificar e antecipar riscos em determinadas manobras de configuração em função de uma experiência prévia ruim; saber conduzir uma operação seguindo uma ordem apropriada, evitando problemas de indisponibilidade, também por experiência prévia; saber qual versão de software usar por não conter um bug que, em um caso anterior, provocou um distúrbio na sua infraestrutura; saber que, antes de ativar um recurso no software do seu roteador, com base em experiência prévia/própria, outro recurso deve estar habilitado como pré-requisito, caso contrário não funcionará ou provocará algum tipo de distúrbio, etc. <br /> *** Estes seriam os seus &lt;u&gt;conhecimentos tácitos&lt;/u&gt;!<br /> Viu só? Nem tudo que é teoria é “burocrático”! Há sempre como extrair coisas positivas de muitos conceitos teóricos ou aparentemente abstratos. E vou um pouco além nesse discurso sobre como isso poderá ser útil para você. Imagine que você fizesse uma autoavaliação (aliás, sugiro mesmo que faça isso!). Qual seria o resultado? E quais seriam os significados desses resultados? Quanto aos “significados”, eu tecerei uma opinião estritamente pessoal, pois a interpretação de cada caso é realmente bastante individualizada. Eu posso pensar de um jeito, e você de outro completamente diferente. Certo? Caso você tenha interesse em saber como eu (autor) penso, estas seriam as minhas respostas:<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou que a maior parte deles é &quot;tácita&quot;.'''''<br /> <br /> Isso, para mim, significaria uma coisa: generalizando aqui, você pode até ser bem &quot;safo&quot;, mas apenas na medida em que seus conhecimentos sejam realmente sólidos e gerem bons resultados. O que é difícil. Explico o porquê. São preocupantes as possíveis (e não confirmadas, por isso estou generalizando) divergências entre o que órgãos da indústria ou fabricantes promovem como recomendações e boas práticas e o que você de fato executa, ou como executa, o seu trabalho.<br /> <br /> Com a complexidade cada vez maior das soluções tecnológicas, bem como dos padrões de boas práticas operacionais, é pouco provável que um indivíduo majoritariamente &quot;tácito&quot; seja efetivo em suas atribuições, especialmente considerando as inúmeras métricas que sustentam todo o funcionamento do aparato tecnológico, como Disponibilidade, Desempenho, Segurança, Confiabilidade, Escalabilidade etc. <br /> <br /> Dificilmente um indivíduo com esse perfil conseguiria orquestrar um ambiente com conhecimentos puramente tácitos. &quot;Ah, mas ele estudou o manual do fabricante para fazer o procedimento 'x'!&quot; Mas, espera aí, isso não é conhecimento tácito! Da mesma forma: &quot;Ele seguiu o processo da Operação da empresa para fazer a configuração.&quot; Mas, espera aí, isso também não é conhecimento tácito! Percebe a diferença? <br /> <br /> Não consigo visualizar um indivíduo majoritariamente &quot;tácito&quot; como funcional, pois tal perfil representaria um risco tremendo para os negócios de uma empresa. Gambiarras e experimentações individualizadas, com pouco ou nenhum apoio em conhecimentos científicos ou empíricos, não são uma opção! Na área de redes e afins, conhecimento tácito é algo muito íntimo e específico (vide os exemplos da tabela anterior) e, em geral, é muito bom/útil como complemento de outras formas de conhecimento, como o científico e o empírico. <br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou que a maior parte deles é de natureza “empírica”.'''''<br /> <br /> Tudo o que um indivíduo aprende a executar em um ambiente de redes, obedecendo a algum padrão ou procedimento estabelecido pela empresa ou pelo mercado (“senso comum”), é considerado conhecimento empírico. O mesmo vale para conhecimentos obtidos junto a uma comunidade de especialistas. Isso é bom ou até muito bom, especialmente quando o indivíduo passa a entender os cuidados que devem ser observados durante a condução do trabalho em questão. Isso significa que, na maior parte do tempo, ele estará conduzindo atividades de acordo com padrões ou modelos confiáveis, realizando configurações, ajustes, manobras, adaptações e afins, sempre inspirado em um esqueleto funcional e seguro, com resultados auditáveis ou claramente perceptíveis.<br /> <br /> É nessas horas, inclusive, voltando ao caso anterior, que os conhecimentos tácitos complementam o processo e fazem diferença: nem sempre os padrões ou procedimentos são bem elaborados ou seguros; nem sempre as descrições de requisitos e respectivas tarefas asseguram que o trabalho a ser realizado estará isento de riscos ou que vá funcionar “de primeira”. Com frequência, o indivíduo percebe isso e passa a tomar cuidados extras na condução de suas atividades, recorrendo à própria experiência e vivência para executar as tarefas, evitar armadilhas, maximizar resultados etc. É nessas horas que o indivíduo “safo” usa sua experiência (conhecimentos tácitos) como complemento aos conhecimentos obtidos de forma empírica ou científica.<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética de seus conhecimentos indicou que a maior parte deles é de natureza &quot;filosófica&quot;.'''''<br /> <br /> Um indivíduo, ao lidar com uma demanda cotidiana que envolva ações cujos conhecimentos correspondentes ou associados foram obtidos de forma empírica (um procedimento, um processo, um modelo etc.), independentemente do estágio de carreira em que adquiriu esse conhecimento, poderá eventualmente divergir de opiniões. Poderá não concordar, pelo menos não de início, ou até que seja convencido por alguém. Poderá ponderar, questionar os propósitos assumidos ou os critérios adotados e, em função disso, desejar modificar ou aprimorar aquela demanda ou aquele processo, refinando o método como um todo ou parte dele. <br /> <br /> Obviamente, apenas &quot;questionar&quot;, &quot;ponderar&quot; ou &quot;criticar&quot; e, ao mesmo tempo, recusar-se a cumprir seu dever, seja qual for a tarefa que lhe tenha sido atribuída, não é o que chamo de conhecimento filosófico; isso se aproxima mais de uma &quot;birra de criança&quot;. Conhecimento filosófico não é fazer birra nem adotar atitudes antiprofissionais. O que se espera, em uma iniciativa correta nesses casos, é um perfil questionador, em que o indivíduo traga à tona novos desafios e propósitos para a elaboração de novas respostas, sempre com foco em efetividade e resultados.<br /> <br /> Essa é uma qualidade do conhecimento que caracteriza bem o perfil de um profissional centrado em qualidade e resultados. Vemos isso com frequência em arquitetos de soluções, em alguns perfis de gestores e até mesmo em engenheiros de redes e analistas.<br /> <br /> === Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC ===<br /> Fugindo momentaneamente deste discurso sobre tipos de conhecimento e retornando ao tema das motivações, abordado anteriormente, mas agora incorporando justificativas e argumentos à fórmula, quais seriam as principais razões para que um indivíduo busque efetivamente conhecimentos relacionados aos temas da área de TIC? Tentemos exercitar essa reflexão de forma ampla e um tanto generalista, deixando de lado as individualidades que movem o coração de cada um de nós. Talvez eu esteja correto em boa parte do que sugiro a seguir, mas é bem provável que você também tenha seus próprios argumentos, justificativas e motivações.<br /> {| class=&quot;wikitable&quot;<br /> |+Alguns casos de argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC<br /> ! colspan=&quot;3&quot; |Argumentos<br /> |-<br /> !Requisitos para Funções Vigentes<br /> !Requisitos para Funções Futuras<br /> !Requisitos para Prospecções e Planos de Carreira<br /> |-<br /> |Obter as qualificações e competências para a conformidade com os requisitos vigentes estabelecidos pelo empregador.<br /> |Aprendizado e domínio de novas tecnologias, equipamentos ou ferramentas, como parte de um processo de adoção tecnológica na empresa, os quais são impostos ou estabelecidos pelo empregador.<br /> |Obter as qualificações e competências exigidas para o enquadramento de perfil junto a uma vaga ou oportunidade pretendida pelo mercado de trabalho.<br /> |-<br /> |Aprimorar as habilidades de alinhamento aos requisitos vigentes, impostos ou estabelecidos pelo empregador.<br /> |Aprimoramento e domínio de habilidades para remodelagem, em futuro próximo, de componentes, processos e práticas vigentes, e para a extração de melhores resultados com o uso de tecnologias atuais, em grande parte por iniciativa própria.<br /> |Obter as qualificações e competências exigidas, visando à evolução ou ao crescimento de carreira, na mesma empresa em que atua no momento ou em outras oportunidades e prospecções.<br /> |-<br /> ! colspan=&quot;3&quot; |Justificativas<br /> |-<br /> |O empregador produz a descrição do cargo que você ocupa (&quot;''job description''&quot;), estabelecendo os pré-requisitos da função, incluindo habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |Tecnologias evoluem. Equipamentos e software ficam obsoletos. Novas ferramentas e soluções são introduzidas para aprimorar as funções. Ciclos de compras de soluções a cada 3-5 anos. Nesta área, esta será a sua realidade quando atuando em praticamente qualquer empresa.<br /> |O empregador elabora a descrição do cargo que você pretende ocupar (&quot;''job description''&quot;), estabelecendo os pré-requisitos da função, incluindo habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |-<br /> |Para manter-se neste cargo, você precisa reunir as devidas comprovações de que possui os pré-requisitos, além de, obviamente, demonstrar resultados no exercício da função.<br /> |É esperado do indivíduo o devido compromisso em adquirir novas habilidades, desde aprender a lidar com um novo tipo de solução ou equipamento de fabricante/modelo diferente daquele a que você está habituado; dominar uma nova ferramenta; dominar um novo processo. É um processo contínuo de aprendizado.<br /> |Para ocupar o cargo pretendido, você precisa reunir as devidas comprovações de que ostenta ou possui estes pré-requisitos, além de experiência comprovada, etc., e isso é normalmente verificado em uma entrevista ou durante um processo seletivo.<br /> |-<br /> ! colspan=&quot;3&quot; |Motivações<br /> |-<br /> |Por razões óbvias, decorrentes das relações trabalhistas, você precisa se &quot;enquadrar&quot;. Numa relação trabalhista, há uma troca: você fornece resultados por meio do seu trabalho e o seu empregador o recompensa por isto. <br /> Se você não conseguir fornecer resultados, por quaisquer que sejam os motivos, mas, neste nosso exemplo aqui, por insuficiência de conhecimentos, a probabilidade é que você seja desligado do cargo.<br /> <br /> '''Manter-se empregado, por si só, já seria uma motivação, talvez a principal.'''<br /> |Conforme já citado neste caso, tecnologias evoluem. Equipamentos ficam obsoletos e são substituídos, sejam por questões de capacidade, inovação tecnológica (novos recursos), descontinuação ou longevidade de suporte do fabricante, ou decorrente de um novo projeto na área de concessão ou expansão. <br /> <br /> Novos projetos sempre surgirão prevendo o atendimento de objetivos estabelecidos por áreas internas do negócio.<br /> <br /> Empresas normalmente procuram capacitar os times atuais para lidar com estes novos desafios, ao invés de, toda vez que surgir um projeto com uma tecnologia nova, contratar mais e mais profissionais.<br /> <br /> Nestas situações específicas você tem uma ótima oportunidade de aprender coisas novas, capacitar-se com novos conhecimentos e habilidades, e de evoluir tecnicamente em sua profissão.<br /> <br /> '''A oportunidade de aprender e evoluir. Muitas vezes tendo acesso a recursos de treinamentos de custo elevado, inviáveis na ótica de investimento pessoal. A possibilidade de atuar em um projeto de visibilidade que vá enriquecer o seu currículo; a abertura de novas oportunidades.'''<br /> <br /> '''A troca de experiências com profissionais diferenciados que poderão estar envolvidos num projeto juntamente com você (ex: especialistas do fabricante, profissionais-referência da área, etc). São ótimas motivações.'''<br /> |Quando somos jovens, temos um sonho. Desejamos ingressar no mercado de trabalho seguindo o nosso coração ou o que for mais viável ou conveniente em termos de oportunidade. O fato que a maioria quer mesmo é trabalhar. <br /> Alguns tem a sorte de acertar em sua primeira oportunidade de emprego, pelo menos no que diz respeito à área ou segmento de trabalho pretendido.<br /> <br /> Apesar de existirem ferramentas que facilitem a entrada de novos profissionais no marcado de trabalho, tais como programas de estágio e intercâmbios, ainda assim há alguns pré-requisitos que precisam ser preenchidos.<br /> <br /> O jovem profissional pode até não ter experiência alguma na função, o que, inclusive, é o esperado na maioria dos casos.<br /> <br /> Preparar-se devidamente para um processo seletivo, especificamente através da obtenção dos conhecimentos teóricos e técnicos exigidos para a oportunidade em questão, garantiriam chances bem maiores de êxito.<br /> <br /> Preparar-se adequadamente para suprir algo &quot;extra&quot;, além do que está sendo exigido, mas que seja compatível com a função/oportunidade pretendida, aumentariam ainda mais estas chances.<br /> <br /> '''A oportunidade de você começar direito. A oportunidade de você dar o pontapé inicial na sua carreira e já preenchendo as competências-base de tudo aquilo que norteará a sua evolução na área. O seu primeiro emprego. São excelentes questões motivacionais.'''<br /> |-<br /> |Muito frequentemente conseguimos uma vaga para um emprego sem necessariamente atendermos a todos os requisitos definidos para esta, mas, quando isto acontece, normalmente preenchemos os principais requisitos, restando &quot;apenas&quot; alguns destes a serem cumpridos.<br /> Nestes casos, geralmente o empregador está &quot;apostando&quot; em você, nas suas habilidades, e na sua capacidade de desenvolver-se continuadamente, buscando preencher &quot;in loco&quot; aqueles requisitos que você não preencheu quando assumiu aquela função.<br /> <br /> '''Manter-se empregado. Não decepcionar aqueles que apostaram em você. Aprender uma nova habilidade; evoluir. Ser reconhecido pelos seu esforço e comprometimento. Seriam ótimas motivações.'''<br /> |Nem todas as situações de &quot;cenário futuro&quot; precisam ser por imposição do empregador ou por circunstâncias de novos projetos iniciados pela empresa. <br /> <br /> Você pode (e deve!) estar atento e sensível às áreas de desenvolvimento e aprimoramento pessoal. A educação continuada poderá abrir novas oportunidades na empresa em que você atua, ou em novos mercados.<br /> <br /> Ao aprimorar as suas habilidades e conquistar novos conhecimentos, você adquirirá naturalmente um senso crítico que tende a funcionar como uma &quot;faísca&quot; para o surgimento de novas formas de fornecer resultados para os negócios da companhia ou para as suas próprias atribuições.<br /> <br /> Nestas situações, você pode conquistar novas oportunidades, tais como encabeçar um novo projeto iniciado por você mesmo, liderar um time, tornar-se uma referência para a resolução de problemas críticos, pontuais ou recorrentes, destravar quase que por completo o seu pontencial.<br /> <br /> '''A satisfação de projetar e construir coisas, de sentir uma afinidade entre aquilo que você vislumbrou e aquilo que está acontecendo; reputação, credibilidade, saber que a empresa e seus colaboradores podem contar com você; a perspectiva de aumento salarial ou de promoção para um cargo. Todos estes são ótimas motivações.'''<br /> |Talvez você esteja passando por aquela fase em que já não se motivado com a função atual.<br /> <br /> As vezes, você até se encontra motivado, mas não se sente desafiado o suficiente e não vê perspectivas de mudanças na dinâmica do seu trabalho na função atual. <br /> <br /> Você quer evoluir, quer dar o próximo salto na sua carreira, seguir adiante.<br /> <br /> Crescer profissionalmente, ser melhor recompensado por isso; ter uma equiparação salarial proporcional ao valor que você pretende oferecer o seu empregador.<br /> <br /> Preencher um cargo mais ousado, assumir mais responsabilidades, tomar decisões importantes.<br /> <br /> Isto raramente acontece no &quot;modo automático&quot;; sem planejamento.<br /> <br /> Você realmente terá que trilhar este caminho, ou seja, planejar todas as ações necessárias viabilizarão este upgrade na carreira. <br /> <br /> Você precisará ser ousado, sistemático, organizado. Quase por simbiose: estudar, capacitar-se e implementar as suas ideias na forma mais prática e objetiva possível. Sem fazer isto, dificilmente você conseguirá absorver os conhecimentos que possibilitarão este impulsionamento na sua carreira.<br /> <br /> '''Dar efetivamente o próximo salto, evoluir objetivamente na carreira. Conquistar novos horizontes; aumento salarial; aspiração de um cargo mais valorizado e diferenciado. Tornar-se uma referência; um profissional conhecedor, credenciado e respeitado. São todas estas excelentes motivações.'''<br /> |}<br /> <br /> === Conhecimentos, Habilidades, Atitudes e Competências (CHAC) e desempenho: suas diferenças e como integrá-los ===<br /> Como já discorri bastante sobre conhecimentos, é hora de avançarmos para as questões de habilidades, atitudes, competências e desempenho. Muitos acreditam que conhecimento e habilidade sejam a mesma coisa. Pode parecer confuso, mas, na verdade, não são. Da mesma forma, “habilidades” e “competências” também não significam exatamente a mesma coisa. Esta seção do artigo apresenta a minha visão sobre as diferenças entre esses conceitos e inclui, nesse conjunto, as atitudes que devem acompanhar o seu desenvolvimento profissional em conhecimentos, habilidades e competências, bem como a forma como o desempenho se relaciona com todos eles.<br /> <br /> O '''''&lt;u&gt;conhecimento&lt;/u&gt;''''' é o entendimento técnico ou teórico de um assunto específico. Na área de TIC, é perfeitamente possível ler bastante e se informar sobre uma tecnologia que não necessariamente faça parte do seu perfil ou do seu cotidiano. Por exemplo, você pode estar bem informado sobre desenvolvimento de aplicações Web quando, na prática, é um profissional de redes. Outro exemplo: você pode ser um bom conhecedor de segurança da informação por ter lido ou estudado bastante seus aspectos teóricos e técnicos, feito cursos, treinamentos etc., mas isso não significa que possua as habilidades associadas a esses conhecimentos. São duas coisas completamente diferentes. É possível que você não esteja trabalhando com determinada tecnologia, isto é, ainda não atue na prática com os casos de uso dessa tecnologia, mas tenha um interesse natural pelos temas daquela área e, consequentemente, passe a estudá-los, ganhando boa fluência teórica e técnica.<br /> <br /> A '''&lt;u&gt;''habilidade''&lt;/u&gt;''', por sua vez, é a capacidade de executar aquilo que é ditado pelos seus conhecimentos adquiridos. Ou seja, você aprendeu a tecnologia, solução ou ferramenta; obteve os devidos conhecimentos e, por meio de muita prática em ambientes que simulam condições e cenários reais, adquiriu as habilidades associadas a esses conhecimentos. Ou, melhor ainda, aplicou esses conhecimentos em um projeto ou situação do dia a dia. Há uma diferença considerável entre conhecer bem alguma coisa e possuir as habilidades necessárias para lidar com essas questões em suas formas mais práticas.<br /> <br /> Um exemplo: eu (autor) sou aficionado por astronomia e astrofísica e passo horas todas as semanas lendo sobre o tema, estudando e me informando de verdade. Isso me coloca na condição de conhecedor do assunto (numa escala que vai de leigo total, iniciante, até “crânio master”, embora eu esteja bem longe desse nível), mas nem de longe isso representa uma habilidade: eu seria incapaz de atuar nessa área com os conhecimentos que possuo no momento e me enxergo muito distante disso. São realidades completamente distintas. Ler bastante sobre um assunto traz muito conhecimento, fato, mas quanto disso se traduz em habilidades? Ler e decorar todas as bulas de medicamentos e saber dissertar de cor e salteado sobre elas não faz de você um médico farmacologista!<br /> <br /> A '''''&lt;u&gt;atitude&lt;/u&gt;''''' tem relação com a forma como você enxerga a conexão entre os conhecimentos indispensáveis para seus propósitos de carreira (vide tabela “Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC”) e a preparação e obtenção efetiva das habilidades necessárias correspondentes. Entenda que empregadores, empresas e clientes estão interessados em mais do que apenas você conhecer alguma coisa: todos esperam confiança no seu trabalho, além de resultados consistentes! E, acredite, essa confiança é avaliada desde o início das relações pretendidas (por exemplo, um processo seletivo, uma proposta para prestação de serviços, uma reunião de negócios para fechamento de contrato) e continua durante a execução do seu trabalho (a maneira como você inicia e planeja as atividades, organiza o seu trabalho, justifica suas ações, aplica configurações, realiza o suporte etc.). Tudo isso move o ponteiro do “desconfiômetro” para baixo ou para cima. Quem nunca ouviu falar de casos em que “fulano falando é quase um mestre, mas, na hora de colocar a mão na massa, trava”? Essa é a diferença entre conhecimento e habilidade! A atitude é o que você faz para transformar seus conhecimentos em habilidades. São os seus métodos, práticas, disciplina, responsabilidade, compromisso, proatividade e ação.<br /> <br /> A '''''&lt;u&gt;competência&lt;/u&gt;''''' pode ser definida como um conjunto de habilidades harmonicamente desenvolvidas que caracterizam a sua função ou profissão, como, por exemplo, a de engenheiro de redes. Enquanto habilidades tendem a ser coisas mais específicas (por exemplo, um protocolo, um equipamento, um serviço), a competência é o desenvolvimento de um conjunto de habilidades que configura um perfil típico para determinado cargo ou função. Para exemplificar, um engenheiro de redes deve possuir diversas competências, cada qual reunindo conjuntos de habilidades necessárias para o pleno exercício da função.<br /> <br /> Já o '''&lt;u&gt;''desempenho''&lt;/u&gt;''' é um indicador da competência que pode ser usado para mensurar o grau de aptidão e os resultados de um indivíduo no exercício de suas funções. Uma questão interessante sobre o desempenho é que ele não é sinônimo integral de competência. Um desempenho ruim pode não indicar exatamente falta de competência, mas, em alguns casos, que os resultados insatisfatórios vêm sendo provocados por interferências e fatores alheios às competências do indivíduo, tais como ausência de materiais ou recursos adequados para a condução do trabalho, condições gerais de trabalho ruins, ou ainda aspectos emocionais que estejam afetando a qualidade das entregas desse profissional. A lista é grande. Mas, em geral, podemos considerar e utilizar o desempenho como uma métrica importante para determinar a competência de um indivíduo.<br /> <br /> Se organizássemos esses conceitos, teríamos os seguintes resultados:<br /> * Conhecimentos representam aquilo que você sabe, obtidos de forma empírica, tácita, científica ou filosófica. Treinamentos, cursos, palestras, workshops, brainstorms etc. são formas de obter ou aprimorar seus conhecimentos.<br /> * Habilidades representam a tradução desses conhecimentos para um plano mais prático. É o &quot;saber fazer&quot; propriamente dito, ou seja, como você utiliza os conhecimentos obtidos na sua vida profissional, nas tarefas do cotidiano etc. Seu envolvimento em ações práticas, como desenvolver um projeto, instalar e configurar equipamentos, adicionar uma funcionalidade ao seu projeto lógico, efetuar diagnóstico e suporte a problemas, entre outras, são exemplos de habilidades. Muitas habilidades, embora possam ser demonstradas na prática, não exigem que você lide diretamente com o componente relacionado ao conhecimento correspondente em uma implementação ou ação de suporte. Por exemplo, conhecimentos aprofundados sobre um determinado protocolo de roteamento (como BGP), mas que não são aplicados diretamente na configuração de um equipamento, e sim em um plano de projeto, na elaboração de um cronograma, na produção de documentação ou na definição de um novo processo referente a essa tecnologia; esse seria o caso de um engenheiro de pré-vendas ou Systems Engineer.<br /> * Competências representam os conjuntos de habilidades que caracterizam seu cargo ou função. Quando é demandada uma competência de &quot;routing e switching&quot; para um perfil profissional (por exemplo, um engenheiro de redes), o que se assume nesse caso? Que você tenha experiência em descrever o equipamento, suas características físicas e lógicas e suas capacidades; realizar a instalação física e a configuração lógica; lidar com um projeto técnico que indique como as tecnologias estarão integradas na rede; definir quais padrões e diretrizes de configuração deverão ser implementados; além de efetuar a configuração e a manutenção da solução, entre outros aspectos. Esse é um exemplo de competência típica de um engenheiro de redes. É importante salientar que há diferenças entre as palavras &quot;competência&quot; e &quot;competente&quot;. &quot;Competência&quot; significa possuir habilidades, comportamentos e atitudes compatíveis com as tarefas que fazem parte da sua função profissional, em qualquer situação relacionada às suas atribuições. Já a palavra &quot;competente&quot; significa ter capacidade para fazer algo em determinado momento.<br /> * Desempenho é a demonstração das suas competências na forma de resultados. É o indicador de que você é efetivo na condução das habilidades que compõem essas competências.<br /> <br /> === Habilidades técnicas (&quot;''Hard Skills''&quot;) e habilidades comportamentais (&quot;''Soft Skills''&quot;) ===<br /> Nem tudo o que deve fazer parte do perfil de um profissional é composto apenas por habilidades técnicas, ou ''hard skills''. É verdade que, por muitos anos, os critérios de seleção de um perfil profissional em processos de recrutamento eram baseados quase que integralmente nessas habilidades mais técnicas, como competências relacionadas exclusivamente a equipamentos, tecnologias, protocolos, serviços e soluções. Para ser honesto, atualmente as habilidades comportamentais pesam significativamente a favor ou contra as chances de um candidato conseguir um emprego, uma promoção ou um aumento de salário.<br /> <br /> Com o mundo cada vez mais dinâmico e conectado, com desafios mais complexos a serem superados, espera-se que, em muitos casos, o indivíduo desenvolva habilidades que vão além do que ele sabe fazer com determinado tipo de solução. As empresas e seus processos seletivos estão cada vez mais rigorosos na avaliação das habilidades comportamentais e interpessoais. Antes de explicar como podemos desenvolver ambos os tipos de habilidades, acho que vale mostrar alguns exemplos de cada uma delas.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Exemplos de habilidades técnicas (&quot;''hard skills''&quot;) e habilidades comportamentais (&quot;''soft skills''&quot;)<br /> !Habilidades técnicas (hard skills)<br /> !Características<br /> !Habilidades comportamentais (soft skills)<br /> !Características<br /> |-<br /> |<br /> |<br /> |'''Atitude'''<br /> |A atitude é uma habilidade comportamental pouco específica, pois abrange uma diversidade de possibilidades, mas não menos apreciável: na verdade, é uma das características mais cobiçadas por empregadores, clientes e prospecções.<br /> No geral, a atitude é um conjunto de comportamentos que define o seu perfil como indivíduo e como profissional. Apresentarei alguns exemplos de atitudes ainda nesta tabela.<br /> |-<br /> |<br /> |<br /> |'''Capacidade analítica'''<br /> |A capacidade analítica é essencialmente uma forma de pensar cujo objetivo é explicar situações e fatos por meios de uma decomposição mais simples e de fácil explicação.<br /> Um profissional com boa capacidade analítica tem muita facilidade em interpretar dados e fornecer explicações simples, mas não menos úteis, para situações complexas e em momentos decisivos.<br /> |-<br /> |<br /> |<br /> |'''Capacidade de persuasão'''<br /> |A persuasão é uma forma de comunicação estratégica que se faz por meio de argumentos lógicos ou simbólicos, sendo a capacidade de argumentação e a retórica essenciais para persuadir alguém ou modificar o panorama de uma situação a seu favor, ou a favor da sua empresa, em uma negociação ou gerenciamento de crise.<br /> A persuasão precisa estar acompanhada de outras habilidades comportamentais, como a ética, empatia, criatividade, capacidade de comunicação (em muitos casos) e inteligência emocional. <br /> <br /> Na área de TIC, é uma habilidade indispensável para profissionais de vendas, pré-vendas e palestrantes, mas também pode ser útil para profissionais de perfil mais técnico.<br /> |-<br /> |<br /> |<br /> |'''Capacidade de trabalhar sob pressão'''<br /> |Em poucas palavras, é uma habilidade que permite ao indivíduo identificar prioridades para assegurar os resultados almejados, além de definir as melhores ações, mesmo em condições adversas, ao mesmo tempo em que, mantendo-se o equilíbrio pessoal, responde às demandas e privilegiando frequentemente a qualidade e o prazo daquele objetivo.<br /> Muitos cargos e funções exigem um perfil de indivíduo capaz saiba lidar com trabalho sob pressão. Na nossa área, times de suporte, logística e operações são constantemente bombardeados por situações que exigem este tipo de habilidade.<br /> <br /> Trabalhar sob pressão (ou ter essa capacidade) automaticamente inclui outras habilidades comportamentais, como a inteligência emocional e a flexibilidade ou resiliência.<br /> |-<br /> |<br /> |<br /> |'''Comunicação interpessoal'''<br /> |A comunicação interpessoal é uma habilidade comportamental que indica a proficiência do indivíduo em estabelecer comunicações efetivas com outras pessoas ou grupos de indivíduos, com foco nas relações e na troca de idéias e experiências.<br /> <br /> Alguns cargos e funções exigem extenso uso da comunicação entre as partes, e o indivíduo com boa comunicação interpessoal conseguirá desempenhá-los com naturalidade.<br /> |-<br /> |<br /> |<br /> |'''Criatividade'''<br /> |A criatividade é a capacidade de criar, produzir ou inventar coisas novas, bem como a capacidade de transformar situações e inovar no modo de agir. <br /> <br /> Dentre os atributos de um profissional criativo temos a curiosidade e a forma diferente de olhar as coisas, além da busca incessante por novas oportunidades e possibilidades. <br /> <br /> Na área de TIC, a criatividade é fundamental para todo e qualquer profissional envolvido na produção de conceitos para superar os desafios do negócio. <br /> <br /> Projetistas (projetos de solução e adoção tecnológica), engenheiros de pré-venda, times de vendas, entre outros, precisam destacar bem esta habilidade, pois a criatividade faz uma diferença estupenda para as competências desses perfis.<br /> |-<br /> |<br /> |<br /> |'''Empatia'''<br /> |Uma habilidade comportamental bastante peculiar, que se traduz em uma capacidade notoriamente psicológica e que envolve a compreensão e a troca de sentimentos e emoções entre dois indivíduos.<br /> <br /> A empatia é uma capacidade bastante apreciada em diversas situações e é um excelente fomentador de outras capacidades comportamentais, como a persuasão, o senso de liderança, a positividade e o trabalho em equipe.<br /> |-<br /> |<br /> |<br /> |'''Ética'''<br /> |A ética dita a conduta humana e profissional, e a moral é a qualidade desta conduta, especialmente quando, em julgamento os pontos de vista do bem e do msobre l. Ou do certo e do errado. A ética é um conceito um tanto amplo (altruísmo, caráter, costume, hábito, etc.).<br /> <br /> A ética deve ser exercida sob o ponto de vista de que aquilo que você está fazendo é o certo, ou, se o que você não está fazendo for o errado, você não está fazendo, mesmo que, naturalmente, defendendo os interesses do seu empregador. Mas para tudo há um limite.<br /> <br /> Sem ética pessoal e profissional, você estará fadado a orbitar o perímetro dos profissionais que transmitem desconfiança e insegurança nas relações de trabalho. Reflita!<br /> |-<br /> |<br /> |<br /> |'''Falar em público'''<br /> |Conforme um ditado conhecido popularmente: pesadelo para uns, sonho para outros. O indivíduo que consegue vencer seus medos e superar as barreiras de suas limitações, nesta questão de comunicação com o público, consegue, por tabela, conquistar novos horizontes e deseolver melhor a sua capacidade de liderar iniciativas, projetando-se melhor para a sua evolução na carreira.<br /> <br /> Esta habilidade é particularmente almejada para perfis de gestores, times comerciais, engenheiros de pré-venda, entre outros.<br /> |-<br /> |<br /> |<br /> |'''Flexibilidade / resiliência'''<br /> |A resiliência, uma habilidade comportamental, pode ser definida como a capacidade do indivíduo de superar adversidades, sem que essas superações gerem sentimentos negativos no cotidiano do próprio indivíduo. Em outras palavras, o indivíduo consegue lidar naturalmente com adversidades, sem quaisquer prejuízos quanto ao seu desempenho no trabalho e em sua vida pessoal.<br /> <br /> Obviamente, entendo que, para tudo, há limites, mas isso está fora de questão nesta dissertação, pois não estou considerando casos extremistas, apenas os &quot;razoáveis&quot;.<br /> <br /> Em combinação com outras habilidades comportamentais, como a inteligência emocional e a capacidade de trabalhar sob pressão, o indivíduo &quot;resiliente&quot; possui mais condições de enfrentar e superar desafios enquanto mantendo-se focado na resoleão destes.<br /> <br /> A resiliência do indivíduo no campo de trabalho é uma das habilidades comportamentais mais apreciadas por gestores.<br /> |-<br /> |<br /> |<br /> |'''Gestão do tempo'''<br /> |A gestão do tempo pode ser definida como um processo de organização, planejamento pessoal e organizacional/corporativo, e a efetiva divisão do tempo entre as atividades específicas que o indivíduo precisa executar em seu cotidiano.<br /> <br /> Tem como proposta, por meio de princípios de planejamento, priorização e organização de tarefas, promover melhor aproveitamento do tempo emdedico em cada tarefa, o que frequentemente gresulta emmelhores rdesempenhs em termos de produtividade e eficiência.<br /> <br /> A gestão do tempo anda lado a lado com outras habilidades comportamentais, tais como a capacidade de trabalhar sob pressão, a resiliência, a inteligência emoc,ional, e outras.<br /> |-<br /> |<br /> |<br /> |'''Inteligência emocional'''<br /> |Para muitos, a inteligência emocional é uma habilidade comportamental distinta. No entanto, penso um tanto diferente disto: trata-se de um conjunto de habilidades que incluem a capacidade do indivíduo de lidar com a pressão no trabalho, autoconfiança, desenvolvimento de empatia, lidar e superar emoções negativas, autoanálise de comportamentos e atitudes no cotidiano, etc.<br /> |-<br /> |<br /> |<br /> |'''Motivação'''<br /> |A união de atitudes e comportamentos que promovem o desempenho geral do indivíduo no trabalho define melhor a habilidade comportamental de &quot;motivação&quot;. Quanto mais bem desenvolvida for esta habilidade, maior disposição, vontade e comprometimento o indivíduo terá com a qualidade do seu trabalho.<br /> |-<br /> |<br /> |<br /> |'''Paciência'''<br /> |A paciência é uma característica da inteligência emocional, algo bem próximo de uma virtude mesmo. Traduz-se na capacidade do indivíduo de enfrentar comportamentos extremistas por parte de colaboradores, gestores e clientes. Muitas vezes, quando a outra parte extrapola os limites do razoável, destilando até mesmo injúrias e outras formas de agressão. Saber lidar com estas situações sem que tragam prejuízo ao equilíbrio emocional e produtivo do indivíduo, tanto no trabalho quanto em sua vida pessoal, é, de fato, um sinal de virtude bastante apreciado.<br /> |-<br /> |<br /> |<br /> |'''Positividade'''<br /> |A positividade é uma habilidade comportamental que traz consigo uma diversidade de atitudes bastante agradáveis para todo o círculo de colaboração em que o indivíduo está inserido. A positividade permite construir bons relacionamentos internos e externos (ao local de trabalho), fornece ótimo supàte de integ,ração com resul eados, dissemina sentimentos de gratião, dentre taoutros ntos sentimentos bons. <br /> <br /> O indivíduo que exercita a positividade busca sempre extrair o melhor das experiências, boas e ruins,, e tem como visão o aprendizad o constan te. Mesmo quando ocorrem frustrações, o indivíduo, equipadocome positividade, consegue extrair um ótimo aprendizado para que estes desafios possam ser superados corretamente em outras ocasiões.<br /> |-<br /> |<br /> |<br /> |'''Proatividade'''<br /> |O indivíduo proativo (ou pró-ativo) é aquele que se antecipa às situações e assume a responsabilidade pelas próprias escolhas e ações, em razão de situações impostas pelo trabalho. A proatividade pode ser mensurada de algumas formas, inclusive na questão de prevenção de incidentes ou simplesmente para evitar que problemas ocorram, justamente pelo fato do indivíduo ter tido o discernimento acerca da necessidade e da devida competência para implementar as medidas preventivas cabíveis.<br /> <br /> É uma das habilidades comportamentais mais cobiçadas por gestores!<br /> |-<br /> |<br /> |<br /> |'''Rede de contatos ativos'''<br /> |Ter uma rede de contatos ativa pode ser um tremendo diferencial para determinados perfis de trabalho! As utilidades de um ótimo networking ativo vão além das perspectivas de novas oportunidades de emprego - pesquisas indicam que em média 30% das contratações acontecem com base na indicação/networking - já que pode servir também para facilitar o intercâmbio de informações estratégicas, a troca de serviços entre o indivíduo ou a empresa em que o indivíduo trabalha e uma cadeia inteira de fornecedores capacitados. Alguns perfis de trabalho dependem bastante do networking ativo do candidato!<br /> |-<br /> |<br /> |<br /> |'''Resolução de conflitos'''<br /> |Os conflitos acontecem por diversas razões, desde posições divergentes em relação a alguma necessidade, objetivo ou comportamento até interesses de ordem comum. Alguns indivíduos possuem ótimas habilidades de negociação e são recheados de valores éticos e morais, em que não há intenção de promover um ganhador ou perdedor, e sim um resultado &quot;win-win&quot;, sempre prezando pela integridade das relações e pela proteção justa dos interesses da companhia.<br /> |-<br /> |<br /> |<br /> |'''Senso de liderança'''<br /> |Liderar, por exemplo, é ser uma referência na condução de suas tarefas, saber compartilhar conhecimentos em equipe e motivar outros colaboradores, levando-os a atingir melhores níveis de produtividade e satisfação pessoal no trabalho. Conectar e engajar equipes em busca do bem comum; compreender os resultados e assumir as responsabilidades. São exemplos de características que envolvem o senso de liderança, presente em profissionais de diferentes áreas.<br /> |-<br /> |<br /> |<br /> |'''Solução de problemas'''<br /> |Alguns indivíduos parecem que foram feitos para atuar em funções onde a atividade primária é a resolução de problemas! Reúnem algumas qualidades e habilidades comportamentais que , de forma apropriada, fomentama &quot;solução de problemas&quot;, incluindo trabalho sob pressão, resiliência, paciência, senso de liderança e empatia.<br /> <br /> Independentemente deste perfil, todos os profissionais da área de TIC precisam possuir uma razoável habilidade para solucionar problemas, mas isto só é factível a partir do momento em que o indivíduo domina as habilidades técnicas (&quot;hard skills&quot;) associadas ao problema em questão.<br /> <br /> Portanto, na nossa área, a habilidade comportamental anda lado a lado com as habilidades técnicas correspondentes, pois praticamente uma depende da outra. No entanto, as habilidades técnicas não são suficientes: de que adianta dominar profundamente uma tecnologia, solução ou plataforma, se não se dispõe de inteligência emocional para lidar com situações ou problemas envolvendo a disponibilidade do serviço junto aos clientes? Se o indivíduo não consegue trabalhar sob pressão? Ou se o indivíduo não tiver paciência para interagir com as áreas afetadas pelo problema?<br /> |-<br /> |<br /> |<br /> |'''Tomada de decisão'''<br /> |Há vários tipos de &quot;tomadas de decisão&quot;: aquelas que tomamos com base em instintos, em crenças subconscientes, em crenças conscientes, em valores pessoais ou institucionais. Independentemente do caso, a tomada de decisões é algo muito mais complexo do que apenas o próprio nome sugere. <br /> <br /> Em primeiro momento, tomar decisões envolve a identificação do problema, bem como definir os critérios, analisar, escolher alternativas e verificar a eficácia da decisão. O processo que consiste em realizar uma escolha dentre diversas alternativas; definir o problema, coletar dados e informações, analisar alternativas, escolher a melhor opção, planejar e executar, e monitorar/acompanhar os resultados desta tomada de decisões. <br /> <br /> A tomada de decisões é uma habilidade comportamental que pode ser mensurada pela experiência do indivíduo em lidar com uma diversidade grande de situações. É uma daquelas habilidades &quot;auditáveis&quot;, em que indivíduos com mais tempo de profissão, desde que expostos adequadamente a diversos tipos de desafios e respectivos &quot;outcomes&quot;, tendem a demonstrar aihor aptidão.<br /> |-<br /> |<br /> |<br /> |'''Trabalho em equipe'''<br /> |Em uma empresa, o trabalho em equipe ocorre quando um time (setor, departamento, grupo de trabalho) realiza um esforço coletivo para resolver um problema, seja de ordem pontual, como parte de um processo recorrente de resolução de problemas, ou então na simples condução de atividades rotineiras de caráter operacional. Parece trivial, certo? Mas saiba que a qualidade da interação entre membros de muitas equipes com as quais já tive contato realmente me surpreendeu, e por várias ocasiões! Alguns profissionais não demonstram bom entrosamento com os demais membros de sua equipe, por mais qualificados tecnicamente que sejam!<br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=3941 2025-08-29T02:56:40Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Arquiteto de soluções, engenheiro de redes, professor e palestrante com 30 anos de experiência em projetos complexos em diversos mercados verticais. Foco em soluções inovadoras de alto impacto e excelência em cada projeto.<br /> <br /> Especialista em routing &amp; switching, segurança, colaboração, wireless e soluções industriais, com foco principal em service providers e data centers.<br /> <br /> Atuou em empresas como AWS, Cisco, NYSE/Euronext, instituições financeiras, operadoras de telecomunicações e integradores Cisco e Juniper. Atualmente, trabalha como Engenheiro de Desenvolvimento de Redes para uma hyperscale na Irlanda.<br /> <br /> Vasta experiência como instrutor, professor e palestrante, compartilhando conhecimento com a comunidade de TIC.<br /> <br /> Ex-chair do Comitê de Programa do Brasil Peering Forum (BPF) e ex-coordenador das task forces de ''Roteamento e MPLS'' e ''Capacitação''.[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Newsletter:''' https://www.theroutingintent.com/<br /> <br /> '''Plataforma de cursos:''' https://ead.leonardofurtado.academy<br /> <br /> '''Programa de formação de engenheiros de redes:''' https://nexthopireland.com/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Temas Sugeridos para Contribuições Futuras==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=3940 2025-08-21T13:07:22Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Arquiteto de soluções e engenheiro de redes com 30 anos de experiência em projetos complexos em diversos mercados verticais. Foco em soluções inovadoras de alto impacto e excelência em cada projeto.<br /> <br /> Especialista em routing &amp; switching, segurança, colaboração, wireless e soluções industriais, com foco principal em service providers e data centers.<br /> <br /> Experiência em empresas como AWS, Cisco, NYSE/Euronext, instituições financeiras, operadoras de telecomunicações e integradores Cisco e Juniper. Atualmente Engenheiro de Redes para uma hyperscale na Irlanda.<br /> <br /> Vasta experiência como instrutor, professor e palestrante, compartilhando conhecimento com a comunidade de TI.<br /> <br /> Ex-chair do Comitê de Programa do Brasil Peering Forum (BPF) e coordenador das task forces de ''Roteamento e MPLS'' e ''Capacitação''.[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Newsletter:''' https://www.theroutingintent.com/<br /> <br /> '''Plataforma de cursos:''' https://ead.leonardofurtado.academy<br /> <br /> '''Programa de formação de engenheiros de redes:''' https://nexthopireland.com/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Temas Sugeridos para Contribuições Futuras==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=3928 2025-07-23T09:47:57Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Sou arquiteto de soluções, engenheiro de redes, instrutor e palestrante, com 29 anos de experiência em projetos complexos realizados em diversos mercados verticais, incluindo telecomunicações, data centers, financeiro, óleo e gás, indústrias, transportes e varejo. Ao longo da minha carreira, tenho me dedicado a entregar soluções inovadoras e de alto impacto, sempre buscando a excelência em cada projeto.<br /> <br /> Tenho uma sólida experiência em diferentes áreas tecnológicas, como routing &amp; switching, segurança, colaboração, wireless e soluções industriais. No entanto, meus maiores interesses e especialização estão focados nos segmentos de service providers e data centers, onde construí grande parte do meu conhecimento.<br /> <br /> Já tive a oportunidade de trabalhar em grandes empresas como Amazon Web Services, Cisco, New York Stock Exchange (NYSE/Euronext), instituições financeiras, além de operadoras de telecomunicações e parceiros integradores da Cisco e Juniper. Atualmente, atuo como Engenheiro de Redes Sênior na Irlanda, onde continuo a aplicar minha experiência em redes e telecomunicações.<br /> <br /> Possuo ainda incontáveis horas como instrutor, professor, e palestrante em eventos e treinamentos, onde compartilho meu conhecimento e experiência com a comunidade de TI. <br /> <br /> Por alguns anos, desempenhei o papel de presidente do Comitê de Programa do Brasil Peering Forum (BPF), além de ter coordenado diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Newsletter:''' https://www.theroutingintent.com/<br /> <br /> '''Plataforma de cursos EAD:''' https://ead.leonardofurtado.academy<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Temas Sugeridos para Contribuições Futuras==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=3927 2025-07-23T09:28:20Z

<p>Leonardo.furtado: Atualização</p> <hr /> <div>==Perfil do Profissional==<br /> Sou arquiteto de soluções, engenheiro de redes, instrutor e palestrante, com 29 anos de experiência em projetos complexos realizados em diversos mercados verticais, incluindo telecomunicações, data centers, financeiro, óleo e gás, indústrias, transportes e varejo. Ao longo da minha carreira, tenho me dedicado a entregar soluções inovadoras e de alto impacto, sempre buscando a excelência em cada projeto.<br /> <br /> Tenho uma sólida experiência em diferentes áreas tecnológicas, como routing &amp; switching, segurança, colaboração, wireless e soluções industriais. No entanto, meus maiores interesses e especialização estão focados nos segmentos de service providers e data centers, onde construí grande parte do meu conhecimento.<br /> <br /> Já tive a oportunidade de trabalhar em grandes empresas como Amazon Web Services, Cisco, New York Stock Exchange (NYSE/Euronext), instituições financeiras, além de operadoras de telecomunicações e parceiros integradores da Cisco e Juniper. Atualmente, atuo como Engenheiro de Redes Sênior na Irlanda, onde continuo a aplicar minha experiência em redes e telecomunicações.<br /> <br /> Possuo ainda incontáveis horas como instrutor, professor, e palestrante em eventos e treinamentos, onde compartilho meu conhecimento e experiência com a comunidade de TI. <br /> <br /> Por alguns anos, desempenhei o papel de presidente do Comitê de Programa do Brasil Peering Forum (BPF), além de ter coordenado diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Newsletter:''' https://www.theroutingintent.com/<br /> <br /> '''Plataforma de cursos EAD:''' https://ead.leonardofurtado.academy<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Aprimorando_a_Disponibilidade_da_rede_do_ISP&diff=3913 2025-04-30T16:05:56Z

<p>Leonardo.furtado: Simplificação do texto, correção ortográfica, e adição de uma seção final</p> <hr /> <div>=== Aprimorando a Disponibilidade da Rede do ISP ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Neste artigo abordaremos informações essenciais para o correto dimensionamento de uma das torres funcionais mais básicas da infraestrutura de redes do ISP. Entre os principais indicadores-chave de desempenho do negócio (KPI) do provedor, destacam-se dois como primários: '''Performance''' (ou &quot;Desempenho&quot;) e '''Disponibilidade'''. As razões são simples, como podemos ver na seguinte reflexão:<br /> * De que adianta uma Internet rápida ou muito rápida se o serviço fica indisponível para o cliente com frequência?<br /> * De que adianta uma Internet com alta disponibilidade se seu desempenho é ruim?<br /> Estes dois indicadores são considerados primários justamente porque o assinante consegue percebê-los facilmente durante a utilização dos serviços de comunicação de dados ou de Internet.<br /> <br /> Este artigo focará na torre funcional de '''Disponibilidade''', enquanto o tema Desempenho será abordado em outro artigo.<br /> <br /> === Definição do Conceito de Disponibilidade e das Torres Funcionais Periféricas ===<br /> Eu trato a Disponibilidade como uma &quot;torre funcional&quot;, pois é possível identificar, categorizar e agrupar especificações técnicas que contribuem para o aumento (ou diminuição) deste indicador. Isso inclui características físicas e eletromecânicas (como hardware em configuração redundante), além de abordagens sistêmicas que englobam serviços, recursos e facilidades, como protocolos e outros elementos de software, que maximizam a Disponibilidade.<br /> <br /> A Disponibilidade tem um objetivo simples: garantir que o serviço ou produto esteja pronto para uso sempre que o cliente (ou assinante) precisar. Quando o usuário não consegue acessar o serviço, caracterizamos uma indisponibilidade, que pode ocorrer com diferentes frequências.<br /> <br /> O indicador de Disponibilidade é influenciado por duas outras torres funcionais essenciais para a satisfação do usuário: '''''Confiabilidade''''' e '''''Resiliência'''''.<br /> <br /> A Confiabilidade, embora seja um indicador independente, contribui diretamente para aumentar a disponibilidade da rede. Ela engloba aspectos como qualidade de manufatura dos componentes, presença de redundância sistêmica (física e lógica) e recursos complementares que fortalecem o conjunto confiabilidade + disponibilidade.<br /> <br /> A Resiliência se refere à capacidade do dispositivo ou da rede de reagir a falhas na infraestrutura, sejam elas físicas (em componentes) ou lógicas.<br /> <br /> É importante frisar que resiliência não é redundância. Resiliência é a capacidade de cada componente, individualmente, responder a diversas situações que afetem sua disponibilidade, considerando seu papel em uma comunicação fim-a-fim e sua posição em um diagrama de bloco de confiabilidade, seja em série ou em paralelo.<br /> <br /> Em síntese: a '''''Disponibilidade''''' é nosso indicador principal, que pode ser calculado e aprimorado através de especificações tecnológicas baseadas nos princípios de '''''Confiabilidade''''' e '''''Resiliência'''''.<br /> <br /> === Os Desafios dos Provedores na Questão da Disponibilidade ===<br /> Os provedores de acesso à Internet precisam compreender com absoluta clareza os fundamentos de ''disponibilidade'' + ''confiabilidade'' + ''resiliência'' para que as suas infraestruturas sejam modificadas com o objetivo de atender ou exceder as expectativas de seus clientes. Dentre os tantos desafios, podemos elencar algumas situações ou verdades sobre o tema:<br /> # A disponibilidade do dispositivo não tem relação direta com a disponibilidade de uma rede. São coisas distintas!<br /> # A disponibilidade de um dispositivo e a sua devida redundância são frequentemente conflitantes, pois alguns dispositivos mais simples podem ser mais confiáveis enquanto alguns dispositivos mais confiáveis tendem a não ser simples!<br /> # Os altos Custos são uma eterna dúvida, e precisam ser bem equacionados.<br /> <br /> ==== O quanto de Disponibilidade a sua infraestrutura de redes precisa e o quanto você está disposto a pagar por isto? ====<br /> Uma coisa que pode não parecer óbvia: excesso de redundância é prejudicial. Além de aumentar significativamente os custos do projeto e da infraestrutura, torna as funções lógicas da rede demasiadamente complexas - podendo até se tornar contraproducente.<br /> <br /> A escolha da quantidade ou qualidade da redundância em uma rede não pode ser tratada como uma simples questão de preferência pessoal, como escolher o ponto da carne no churrasco (cru, mal passado, ao ponto, bem passado…).<br /> <br /> Os projetos de infraestrutura que visam melhor disponibilidade precisam estabelecer um padrão ideal de redundância física e lógica, evitando tanto a escassez quanto o excesso. Um dos maiores desafios está em projetar uma infraestrutura ''redundante'', ''confiável'' e ''resiliente'' para atingir o indicador de '''Disponibilidade''' desejado, garantindo que os '''''Custos''''' sejam compatíveis com a missão do negócio e a realidade financeira do operador de redes.<br /> <br /> Nesta questão, segue a minha primeira dica:&lt;blockquote&gt;'''''Determine os custos de DOWNTIME primeiro, para depois determinar e balancear os custos de Disponibilidade. Será mais fácil aceitar a realidade do investimento necessário quando se compreende claramente os impactos de uma falha no negócio, seja ela simples ou uma catástrofe na rede do seu provedor.'''''&lt;/blockquote&gt;<br /> * O quanto você está disposto a perder financeiramente com uma falha na sua rede?<br /> <br /> * O quanto você está disposto a perder em termos de base de clientes, participação de mercado / market share, reputação e afins, como consequências de desastres na sua rede?<br /> * O quanto você está disposto a investir para mitigar corretamente os tantos riscos que podem provocar desde pequenas, mas inconvenientes, indisponibilidades, até grandes dores de cabeça com falhas e impactos massivos?<br /> Exercite precisamente as três questões acima antes mesmo de tentar elaborar o seu próximo projeto de infraestrutura!<br /> [[Arquivo:Bpf-ha-1.png|centro|miniaturadaimagem|640x640px|Compatibilizando os Custos de Downtime versus os Custos de Disponibilidade]]<br /> <br /> Procure identificar e quantificar os seguintes impactos para o negócio do seu provedor:<br /> * '''Impactos de natureza imediata'''<br /> ** Perda de receitas<br /> ** Custos com reparos e manutenção corretiva<br /> ** Penalidades contratuais de SLA<br /> ** Insatisfação dos clientes<br /> ** Atrasos em projetos internos e externos<br /> ** Impactos negativos na operação do negócio<br /> * '''Impactos de natureza de longo prazo'''<br /> ** Danos à imagem da empresa/ISP<br /> ** ''Churn'' e evasão de assinantes<br /> ** Fortalecimento indevido da concorrência<br /> ** Processos e reparações judiciais<br /> ** Perda de confiança dos funcionários, colaboradores, mercado e clientes<br /> <br /> === Compreendendo a Derivação do Indicador de Disponibilidade ===<br /> Nesta seção do artigo, apresentarei os fundamentos dos cálculos de disponibilidade de uma rede.<br /> <br /> O principal objetivo é permitir que o ISP estabeleça um nível de disponibilidade matematicamente quantificável. Isso significa que a rede terá um índice de disponibilidade mensurável, que será comunicado aos clientes nos acordos de SLA. Este índice é expresso através de um valor percentual, como demonstrado a seguir:<br /> [[Arquivo:Bpf-ha-2.png|centro|miniaturadaimagem|640x640px|Quantificação da confiabilidade e disponibilidade de uma rede]]<br /> Para calcular a disponibilidade, precisamos primeiro medir a confiabilidade de uma rede, pois a ''Confiabilidade'' é um conceito mensurável. Para este cálculo, utilizamos dois indicadores primários:<br /> <br /> '''Mean Time Between Failures (MTBF)'''<br /> <br /> É o tempo total de operação do dispositivo e/ou da rede dividido pela quantidade de falhas. Para simplificar, começamos analisando um dispositivo individual antes de considerar o ambiente completo.<br /> <br /> Em outras palavras: &quot;''quando o componente falha?''&quot;<br /> <br /> '''Mean Time to Repair (MTTR)'''<br /> <br /> É o tempo total necessário para resolver uma falha, incluindo: detecção do incidente, diagnóstico do problema e reparo efetivo. O reparo pode envolver configuração, reinicialização do equipamento, substituição de módulos ou conserto de enlaces de comunicação.<br /> <br /> Em outras palavras: &quot;''quanto tempo leva para consertá-lo?''&quot;<br /> <br /> A confiabilidade de uma rede e, por consequência, sua disponibilidade, podem ser calculadas através de uma fórmula simples:[[Arquivo:Bpf-ha-3.png|centro|miniaturadaimagem|640x640px|Cálculo da disponibilidade de uma rede]]<br /> <br /> ==== Confeccionando o seu Diagrama de Blocos de Confiabilidade ====<br /> Do inglês '''''Reliability Block Diagram (RBD)''''', este diagrama é uma ferramenta essencial para iniciar os cálculos de confiabilidade e disponibilidade de uma rede. O RBD utiliza um método diagramático para demonstrar como a confiabilidade dos componentes contribui para o sucesso ou falha de um sistema complexo. No nosso caso, o equipamento da rede.<br /> <br /> Os fabricantes de equipamentos de redes, especialmente os de primeira linha, são extremamente criteriosos na gestão de qualidade de manufatura de seus produtos. Embora muitos dos conceitos que abordarei estejam na esfera do fabricante e não do provedor, vale a pena entender um pouco desse processo. Vamos lá?<br /> <br /> No desenvolvimento de um novo equipamento, e deixando de lado os processos iniciais, a confiabilidade dos componentes é rigorosamente avaliada.<br /> <br /> São mais de 150 requisitos técnicos distribuídos em mais de 15 disciplinas de confiabilidade, incluindo ''Integridade de Sinais'', ''Diagnósticos'', ''Mecânica'', ''Térmica'', ''Elétrica'', ''CAD'', ''Engenharia de Hardware'', ''Silício'' (ASIC, FPGA e afins), ''Ópticos'', ''Manufatura e Engenharia de Componentes''.<br /> <br /> Todos esses requisitos passam por uma extensa esteira de Qualidade e Confiabilidade (PQE), onde o produto e seus componentes são testados em diversas condições: temperatura de operação e armazenamento, altitude, umidade condensada, vibração, choque, interferência EMI e RFI, entre outros. Só após esses testes o fabricante determina os valores de MTBF dos componentes.<br /> <br /> É com esses valores de MTBF que você, profissional de redes de um ISP, poderá trabalhar. O primeiro passo é solicitar ao fabricante as figuras de confiabilidade (MTBF) do seu equipamento. O fabricante não fornecerá o MTBF de cada componente individual, já que isso seria desnecessário. Em vez disso, você receberá valores agrupados por conjuntos funcionais do equipamento. Por exemplo:<br /> * MTBF da fonte de alimentação elétrica<br /> * MTBF do módulo de ventilação<br /> * MTBF do módulo de supervisão e controle (ex: RSP, RP, RE, Supervisor, etc.)<br /> * MTBF do módulo de portas (line card)<br /> * Etc.<br /> Com essas informações em mãos, você deve desenhar o RBD (mesmo que simplificado) do equipamento e calcular sua confiabilidade e disponibilidade. Vamos usar um exemplo simples para demonstrar um RBD com as figuras de escalabilidade fornecidas pelo fabricante:<br /> <br /> OBS: durante este procedimento, é essencial validar tanto os componentes com redundância em série quanto em paralelo. Por exemplo: mesmo que um roteador possua duas fontes de alimentação instaladas (redundância em paralelo para a parte elétrica), a falha de um único módulo de supervisão e controle interromperia completamente seu funcionamento. Isso ocorre porque existe uma disposição em &quot;série&quot; entre os blocos funcionais &quot;alimentação elétrica&quot; e &quot;supervisão e controle&quot;, onde um depende do outro para manter o equipamento operacional.[[Arquivo:Bpf-ha-4.png|centro|miniaturadaimagem|800x800px|Calculando a disponibilidade de um dispositivo (Fonte: Cisco)]]<br /> O exemplo acima mostra que o equipamento possui uma disponibilidade ligeiramente superior a 99,99% (conhecida como &quot;4-Nines&quot;), o que representa matematicamente cerca de 50 minutos de downtime por ano.<br /> <br /> Após validar o índice de confiabilidade e disponibilidade de cada equipamento da sua rede, incluindo também os enlaces/links, seu próximo passo será determinar a confiabilidade e disponibilidade completa de toda a rede. Veja um exemplo de como isto pode ser feito:[[Arquivo:Bpf-ha-5.png|centro|miniaturadaimagem|640x640px|Disponibilidade de um cenário de rede (Fonte: Cisco)]]<br /> [[Arquivo:Bpf-ha-6.png|centro|miniaturadaimagem|640x640px|Disponibilidade de um cenário de rede com componentes em SÉRIE (Fonte: Juniper Networks)]]<br /> [[Arquivo:Bpf-ha-7.png|centro|miniaturadaimagem|640x640px|Disponibilidade de um cenário de rede com componentes em PARALELO (Fonte: Juniper Networks)]]<br /> <br /> Ao final desse processo, você terá uma compreensão clara dos níveis de disponibilidade de cada dispositivo, enlace e toda a infraestrutura de rede. Como resultado, poderá definir o '''''Service Level Agreement (SLA)''''' de sua rede, mesmo que inicialmente apenas em relação ao MTBF.<br /> <br /> ==== Uma Observação Importante quanto ao MTBF ====<br /> Há um aspecto interessante sobre as figuras de confiabilidade (MTBF) fornecidas pelos fabricantes: elas são valores estáticos.<br /> <br /> Os componentes são submetidos a testes rigorosos de estresse eletrônico e mecânico sob diversas condições (temperatura, altitude, pressão, umidade, vibração, choque/impacto, etc.). Como resultado, os níveis de confiabilidade dos componentes são validados matematicamente e disponibilizados ao usuário do equipamento.<br /> <br /> Na maioria dos casos, esses valores não são publicamente disponíveis, sendo necessário solicitá-los diretamente ao fabricante. É importante notar que, por serem estáticos, não há como aprimorá-los.<br /> <br /> Os únicos &quot;ajustes&quot; possíveis nestes casos são a seleção criteriosa da composição do equipamento quanto à sua redundância física e ações relacionadas.<br /> <br /> ===== Fatores que Afetam o MTBF de um Dispositivo e/ou da Rede =====<br /> '''Chassi:''' é um elemento primariamente passivo, assim como seu backplane.<br /> <br /> '''Módulo de Supervisão e Controle (ex: RP, RSP, RE, Supervisor):''' pode ser único ou redundante. Ao inserir dois módulos no chassi, você melhora substancialmente o MTBF deste bloco através da redundância em &quot;paralelo&quot;.<br /> <br /> '''Fontes de alimentação elétrica:''' um equipamento com fonte única depende totalmente da disponibilidade desta fonte. Alguns equipamentos aceitam duas ou mais fontes. Porém, equipamentos mais robustos têm requisitos elétricos mais exigentes e podem necessitar de um número mínimo de fontes instaladas para manter todos os módulos funcionando. Nesses casos, a redundância não seria 1 + 1, mas sim N + 1 ou N + N.<br /> <br /> '''Módulo de ventilação:''' alguns fabricantes de equipamentos mais simples usam módulos com ventoinhas integradas que não podem ser substituídas sem desligar e desmontar o equipamento (afetando o MTTR). Outros modelos têm ventoinhas independentes controladas por uma única placa (ficando em &quot;série&quot;). Há ainda modelos com bandejas independentes com múltiplas ventoinhas, mas exigem um número mínimo delas funcionando com ''thresholds'' de RPM específicos, conforme demandado pelos sensores de temperatura.<br /> <br /> '''Módulo de portas/interfaces físicas (line cards):''' considere um cenário com dois uplinks críticos conectados a portas independentes do mesmo módulo line card. Existe uma relação em &quot;série&quot; entre estes uplinks e o módulo - se ele falhar, ambos os uplinks ficam indisponíveis. De que adianta ter um chassi com duas controladoras, quatro fontes de alimentação e dois módulos de ventilação se os uplinks dependem de um único módulo de portas? O problema está no design da conectividade. Ao distribuir as conexões físicas redundantes em módulos diferentes, você aumenta o MTBF do bloco de conectividade entre o equipamento e os uplinks.<br /> <br /> Espero que você tenha compreendido isso.<br /> <br /> ==== Compreendendo o Mean Time to Repair (MTTR) ====<br /> Diferentemente do MTBF, cujos valores são praticamente estáticos (variando apenas no projeto da redundância), o MTTR possui natureza altamente variável e dinâmica. O MTTR indica o tempo necessário para reparar uma falha ou incidente e restabelecer o funcionamento dos serviços afetados. <br /> <br /> A interpretação desses valores também difere: para o MTBF, quanto maior o valor, melhor, pois indica menor frequência de falhas. Já para o MTTR, quanto menor o valor, melhor, pois o objetivo é minimizar o tempo necessário para resolver o problema e restaurar o serviço.<br /> <br /> ===== Fatores que Afetam o MTTR de um Dispositivo e/ou da Rede =====<br /> O MTTR é severamente afetado e em uma variedade de situações que fica até difícil sintetiza-lo aqui. Citarei algumas destas situações:<br /> <br /> O MTTR é significativamente afetado por diversas situações, das quais destacaremos as principais:<br /> <br /> &lt;u&gt;Falha de componente físico (módulo, fonte...):&lt;/u&gt; se um módulo em seu datacenter falhar e afetar serviços na rede, qual seria o tempo necessário para restaurar o serviço?<br /> * '''Notificação e detecção do problema'''<br /> ** Qual foi o intervalo entre o surgimento do problema e sua detecção efetiva?<br /> ** Quanto tempo foi necessário para diagnosticar o problema, compreendê-lo e isolar a causa-raiz, permitindo determinar a ação corretiva adequada? &lt;u&gt;O MTTR aqui é afetado pela qualidade dos seus processos e ferramentas de gerenciamento de incidentes, além do conhecimento e habilidades de seus funcionários e colaboradores.&lt;/u&gt;<br /> * '''Material sobressalente para reposição'''<br /> ** Você possui peça de reposição em estoque local?<br /> ** Precisa se deslocar para obter a peça de reposição e retornar ao local de instalação?<br /> ** Você não possui peça de reposição disponível.<br /> *** Possui contrato de assistência técnica estendida com o fabricante?<br /> **** Caso afirmativo, qual é o SLA deste RMA (próximo dia útil, 4 horas, 2 horas)?<br /> ** Na ausência de peças de reposição e sem acesso ao RMA por falta de contrato de assistência técnica estendida, quais são suas opções?<br /> *** É possível comprar um módulo imediatamente, considerando o melhor prazo de entrega (que pode variar de horas a dias)?<br /> *** Existe a possibilidade de empréstimo com algum parceiro ou fornecedor enquanto aguarda a compra do módulo? &lt;u&gt;O MTTR é diretamente impactado pelos seus processos de logística, plano de contingenciamento e recuperação de desastres. Sem essas medidas preventivas, prepare-se para um downtime prolongado e prejudicial ao negócio.&lt;/u&gt;<br /> * '''Execução de manobras corretivas'''<br /> ** A reposição do módulo exigirá esforços com configurações/reconfigurações?<br /> *** Você por acaso possui cópias de segurança (backup) vigentes/recentes do equipamento referentes ao módulo que falhou e de seus serviços dependentes.<br /> ** Você não possui backup das configurações ou o backup é relativamente antigo.<br /> *** Caso tenha que reconfigurar, quanto tempo levaria para você refazer toda a configuração, testá-la e isentá-la de erros, e restaurar o serviço.<br /> ** &lt;u&gt;O MTTR aqui é afetado pela qualidade de seus processos operacionais, em especial as questões de antecipação de problemas, gerenciamento de riscos, gerenciamento de incidentes, gerenciamento de configurações, e skill de seus profissionais e colaboradores.&lt;/u&gt;<br /> * '''Acionamento da convergência da infraestrutura'''<br /> ** &lt;u&gt;O MTTR é afetado aqui conforme a abordagem tecnológica de seu projeto técnico sobre a rede. Ou seja, o padrão de seu projeto, a hierarquia da sua rede, os protocolos de resiliência empregados, e os recursos adicionais que promovem maior confiabilidade para o projeto da rede.&lt;/u&gt;<br /> Como podemos perceber, o MTTR é bastante modificado em função de uma série de contextos e situações, dentre os quais elenquei apenas alguns! A questão &quot;operacional&quot; é um dos mais importantes, e focaremos nisto em outro artigo aqui no BPF, assim como conceitos de gerenciamento FCAPS, TMN e afins., além da parte de skills/habilidades/competências, processos e outros temas.<br /> <br /> ==== O Cálculo Efetivo da Disponibilidade de uma Rede ====<br /> Agora que você compreendeu melhor o MTBF e o MTTR, bem como os modelos de redundância em série e em paralelo, vamos consolidar estes conceitos através de um modelo didático:<br /> <br /> ===== Disponibilidade Calculada =====<br /> A disponibilidade calculada pode ser determinada observando-se os seguintes critérios:<br /> * '''Projeto da rede:''' classe dos equipamentos, componentes em configuração redundante, hierarquia da rede (como o modelo hierárquico + estruturado + modular e as &quot;camadas de função&quot;), entre outros.<br /> * '''MTBF e MTTR dos componentes:''' é importante destacar que existem diversos modelos e simulações, incluindo [[wikipedia:Markov_model|''Markov’s Modeling'']], ''Reliability Block Diagram'' (RBD) e &quot;''sensitivity analysis - Telcordia SR-1171 Methods and Procedures for System Reliability Analysis''&quot;, relacionados às especificações de requisitos de produtos e metas de confiabilidade estabelecidas pelo mercado e clientes.<br /> O cálculo básico da disponibilidade pode ser representado da seguinte forma:<br /> [[Arquivo:Bpf-ha-8.png|centro|miniaturadaimagem|640x640px|Fórmula do cálculo de disponibilidade em Série e em Paralelo]]<br /> <br /> ===== Disponibilidade Mensurada =====<br /> A disponibilidade mensurada requer o emprego de elementos externos ou complementares para sua medição. Alguns exemplos:<br /> * Testes de conectividade com ferramentas padrão como o protocolo ICMP (''ping'', ''traceroute'' e similares).<br /> * Testes de conectividade com ferramentas específicas como ''Cisco Service Level Agreement'' (IP SLA), ''Cisco Service Assurance Agent'' (SAA) e ferramentas equivalentes de outros fabricantes.<br /> * Testes de disponibilidade com consultas a objetos gerenciados (OID) via SNMP.<br /> * Testes com sondas externas para medição de desempenho conforme RFCs específicos (exemplo: JDSU).<br /> * Análise e interpretação de registros de chamados técnicos e logs de indisponibilidade.<br /> * Métodos observáveis como o acompanhamento de RMA de componentes defeituosos.<br /> <br /> ===== Disponibilidade Planejada =====<br /> Em especial com foco na redução do MTTR:<br /> * Realização de auditoria para análise qualitativa de riscos e gerenciamento de riscos, visando identificar e mensurar os riscos de indisponibilidade e seus impactos nos indicadores de performance da organização.<br /> * Desenvolvimento de plano de contingência e recuperação de desastres para mitigar riscos críticos do negócio, reduzindo o MTTR e aprimorando o SLA.<br /> * Implementação de processos operacionais robustos e seguros, alinhados aos modelos consagrados da indústria para gerenciamento de mudanças, configurações e incidentes.<br /> * Investimento em treinamento e capacitação da equipe para atuação eficiente em falhas, tanto em ações preventivas quanto corretivas.<br /> <br /> === Elevando o SLA da sua Rede para o Próximo Nível ===<br /> O Service Level Agreement (SLA) é o principal indicador que você fornece ao mercado e aos seus clientes. Ele é determinado pela combinação da Disponibilidade Calculada, Mensurada e Planejada. Em outras palavras, o SLA é governado pela torre funcional de &quot;Disponibilidade&quot; do seu projeto técnico, que se baseia na Confiabilidade e na Resiliência. Para facilitar o tratamento das áreas de disponibilidade, é importante separar as áreas-foco da resiliência de uma rede:<br /> <br /> ==== Resiliência Nível Sistêmico ====<br /> São considerados aqui aspectos como a confiabilidade do hardware e software, bem como ações para redução do MTTR em falhas de componentes físicos e lógicos (RP/RSP/RE, line cards, módulos de software etc.). A arquitetura de software tem papel fundamental na resiliência do equipamento. Veremos isso nos exemplos a seguir, utilizando um roteador Cisco ASR 1000 e os softwares Cisco IOS XE e Cisco IOS XR.<br /> [[Arquivo:Bpf-ha-10.png|centro|miniaturadaimagem|500x500px|Exemplo de recursos de disponibilidade de um equipamento (Fonte: Cisco)]]<br /> [[Arquivo:Bpf-ha-11.png|centro|miniaturadaimagem|500x500px|Exemplo de arquitetura de disponibilidade de software (Fonte: Cisco)]]<br /> [[Arquivo:Bpf-ha-12.png|centro|miniaturadaimagem|500x500px|Exemplo de arquitetura de disponibilidade de software (Fonte: Cisco)]]<br /> Observação: consulte o fabricante de sua escolha para conhecer as características de disponibilidade sistêmicas da arquitetura do equipamento pretendido. <br /> <br /> ==== Resiliência Nível Rede ====<br /> São considerados aqui aspectos como as propriedades do projeto técnico, a hierarquia e as camadas de função da rede, além da adoção de mecanismos que forneçam uma convergência e recuperação de falhas mais rápida e ágil. Isso inclui tecnologias suplementares, protocolos de resiliência e mecanismos de proteção.<br /> <br /> [[Arquivo:Bpf-ha-9.png|centro|miniaturadaimagem|900x900px|Exemplos de tecnologias para o aumento da disponibilidade na rede (Fonte: Cisco)]]<br /> [[Arquivo:Bpf-ha-15.png|centro|miniaturadaimagem|900x900px|Exemplos de tecnologias para o aumento da disponibilidade de serviços L3VPN MPLS (Fonte: Cisco)]]<br /> [[Arquivo:Bpf-ha-16.png|centro|miniaturadaimagem|900x900px|Exemplos de tecnologias de alta disponibilidade para os planos de controle e de serviços (Fonte: Cisco)]]<br /> [[Arquivo:Bpf-ha-17.png|centro|miniaturadaimagem|900x900px|Exemplos de tecnologias para a rápida detecção de falhas de enlaces (Fonte: Cisco)]]<br /> <br /> ==== Resiliência Nível Operacional ====<br /> São consideradas aqui todas as questões associadas à parte operacional do provedor, incluindo processos, métodos, boas práticas, capacitação de pessoal e ferramentas necessárias para ações de diagnóstico, correção e reparo. Futuros artigos no BPF abordarão este tema em detalhes.<br /> <br /> === Exemplos de Procedimentos, Tecnologias, Protocolos e Serviços de Confiabilidade da Infraestrutura ===<br /> Consulte a ilustração a seguir para compreender os principais elementos de confiabilidade em uma infraestrutura de forma consolidada. A lista não é exaustiva; diversos outros elementos importantes não puderam ser incluídos.<br /> [[Arquivo:Bpf-ha-13.png|centro|miniaturadaimagem|1231x1231px]]<br /> <br /> === Dicas para Elevar a sua Disponibilidade e SLA ===<br /> Na verdade, não há nada de secreto. Siga estas dicas comprovadas para elevar o padrão de disponibilidade e SLA ao próximo nível:<br /> # '''Documente toda a sua rede'''. Produza artefatos detalhando as camadas L1, L2 e L3, assim como cada elemento ativo. Utilize planilhas, bases de conhecimento internas e diagramas. A propósito, confira o artigo [[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]] em nossa Wiki!<br /> # '''Produza o Diagrama de Blocos de Confiabilidade (RBD)'''. Comece com cada dispositivo individual e depois expanda para toda a rede. Determine com precisão o '''MTBF''', '''MTTR''' e o '''MTD''' (''Mean Down Time'').<br /> # '''Localize os Single Points of Failure (SPOF) de sua rede'''. Identifique e marque cada ponto único de falha para posterior resolução e mitigação.<br /> # '''Elabore e documente o Mapa de Indisponibilidades'''. Detalhe como cada tipo de incidente pode ocorrer, áreas de serviços impactadas, usuários afetados e duração prevista. Classifique esses dados por categoria, escopo, perímetro, volume e aspectos temporais.<br /> # '''Realize a Análise de Riscos Qualitativa e Quantitativa'''. Isto auxiliará na aprovação do projeto e seus investimentos necessários. Conheça detalhadamente seus riscos, possíveis falhas e impactos no negócio (multas, reparações, reputação e perda de clientes). Quantifique financeiramente estes danos. Compare &quot;''quanto eu vou perder se a minha rede parar''&quot; versus &quot;''quando vou gastar para a minha rede não parar e eu não ter estas perdas''&quot;. Vale mais investir ou correr o risco?<br /> # '''Elabore um Projeto Executivo'''. Este documento objetivo documentará as iniciativas para resolver os riscos identificados. Foque na viabilidade técnica para garantir a aprovação do projeto.<br /> # '''Elabore um Projeto Técnico Detalhado'''. Quando necessário, o PTD abordará especificações técnicas essenciais para integrações complexas.<br /> # '''Elabore um Plano Diretor de Investimentos'''. Busque apoio de fabricantes e parceiros estratégicos competentes. Evite consultores superficiais e vendedores sem expertise técnica em implantação e suporte. Procure viabilizar investimentos com apoio do fabricante, canais de distribuição, parceiros estratégicos (VAR/revenda) e instituições financeiras.<br /> # '''Contrate uma empresa de serviços qualificada'''. Reconheça suas limitações e confie em especialistas. Aproveite para: '''a) acompanhar de perto e aprender'''; '''b) concentrar-se nos resultados do negócio, não em distrações'''.<br /> # '''Mantenha a documentação atualizada'''. Garanta que todos os artefatos da rede permaneçam consistentes e vigentes.<br /> # '''Revalide o plano de contingência e recuperação de desastres'''.<br /> '''Assista ao Vídeo &quot;BPF: compreendendo os fundamentos de Disponibilidade da rede de um ISP&quot;'''<br /> <br /> Este vídeo com 41 minutos de duração explora os temas discutidos aqui através de uma linguagem bem fácil e objetiva. Assista aqui: https://youtu.be/egrNHwwoaOY <br /> [[Arquivo:Bpf-ha-14.png|centro|miniaturadaimagem|640x640px|BPF: compreendendo os fundamentos de Disponibilidade da rede de um ISP]]<br /> <br /> === Inovações recentes ===<br /> Para elevar estas ideias ao próximo nível:<br /> <br /> '''1. Redes Autocorretivas (Self-Healing Networks)'''<br /> <br /> As redes autocorretivas representam um avanço significativo na automação. Elas permitem que a infraestrutura detecte, diagnostique e resolva problemas autonomamente, sem intervenção humana. Essa abordagem reduz o tempo de inatividade e melhora a resiliência operacional.<br /> <br /> '''2. Operações de Rede Baseadas em IA (AIOps)'''<br /> <br /> A integração de Inteligência Artificial nas operações de rede permite análises preditivas e automação de tarefas complexas.<br /> <br /> '''3. Arquitetura de Automação Sem Limites (Boundless Automation)'''<br /> <br /> A Emerson desenvolveu a arquitetura Boundless Automation™, integrando dados de dispositivos de campo, edge computing e nuvem em uma infraestrutura adaptável. Essa abordagem permite otimização em tempo real e resposta rápida a falhas, aumentando a disponibilidade da rede.<br /> <br /> '''4. Plataformas de Automação Agnósticas a Fornecedores'''<br /> <br /> Com redes cada vez mais complexas, cresce a adoção de plataformas de automação independentes de fornecedor único. Essas soluções integram diversos dispositivos e sistemas, simplificando a gestão e aumentando a flexibilidade operacional.<br /> <br /> '''5. Redes Zero-Touch com AutoML'''<br /> <br /> As redes Zero-Touch automatizam completamente a gestão de rede, usando aprendizado de máquina automatizado para adaptação dinâmica e otimização de desempenho. Essa abordagem é crucial para redes 5G e tecnologias futuras.<br /> <br /> '''6. Redundância Transparente de Alta Disponibilidade (HSR)'''<br /> <br /> O protocolo High-availability Seamless Redundancy oferece failover sem interrupções, garantindo continuidade mesmo durante falhas de componentes. É especialmente valioso em ambientes industriais que exigem alta disponibilidade.<br /> <br /> === Considerações Finais ===<br /> Você sabia que a maior parte dos incidentes que provocam indisponibilidades em uma rede são decorrentes de falha humana? Ausência de processos seguros para gestão de mudanças, por exemplo? O artigo focou em comentar primariamente a parte da infraestrutura e menos na parte de &quot;pessoal&quot;, mas, não se preocupe, o BPF em breve publicará artigos sobre o tema de processos e boas práticas operacionais para ambientes de provedores.<br /> <br /> Espero que este artigo tenha sido útil. Até o próximo!<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Capacitação]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Solucoes_para_o_gerenciamento_efetivo_do_bgp_em_um_sistema_autonomo&diff=3912 2025-04-27T15:25:00Z

<p>Leonardo.furtado: Simplificação de palavras, redução de excessos, correção ortográfica.</p> <hr /> <div>=== Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo ===<br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Todos os engenheiros de redes sênior que atuam em ISPs ou em empresas que possuam um Sistema Autônomo compreendem a importância de estudar as informações das sessões e tabelas BGP. Este estudo vai além da perspectiva do próprio ASN, estendendo-se a diversos pontos de monitoramento, incluindo coletores, ''route views'', ''looking glasses'' e outros recursos distribuídos pela Internet. Em outras palavras, é essencial entender como seu ASN vê o mundo e como o mundo vê seu ASN.<br /> <br /> Esta análise é fundamental para prevenir os dois principais tipos de incidentes no roteamento de Internet: ''route leaks'' e ''prefix hijack''. Contudo, as necessidades de monitoramento BGP de um ASN são mais abrangentes que apenas esses incidentes (embora sejam gravíssimos). Para estes, já existem BCOPs específicas de prevenção e mitigação, como o &lt;nowiki&gt;RFC 7454&lt;/nowiki&gt; / BCP 194, BCP 38, BCP 185 e MANRS. A gestão do BGP vai muito além das questões de segurança.<br /> <br /> O Sistema Autônomo precisa monitorar constantemente '''''seu BGP''''' como um todo, incluindo dezenas de objetos, métricas e KPIs. Isso permite endereçar diversos desafios além da segurança do roteamento, como: escalabilidade, engenharia de tráfego com redução inteligente de custos, melhoria na qualidade de serviço, planejamento de capacidades, métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, padrões de convergência da rede, investimentos, desenvolvimento de produtos e serviços, e aspectos financeiros.<br /> <br /> Os modelos tradicionais de monitoramento BGP têm limitações: ''routeviews'' e ''looking glasses'' geralmente não mantêm históricos de rotas, impossibilitando saber o que aconteceu, quando e por quem. Além disso, uma sessão BGP anuncia apenas suas melhores rotas (''best path''), informação obtida via CLI ou telemetria, mas sem histórico. Para superar essas limitações, empresas recorrem a soluções que mantêm essas informações em bases de dados flexíveis, escaláveis e gerenciáveis, seja através de sistemas customizados ou comerciais, preferencialmente integráveis com Sistemas de Suporte à Operação (OSS).<br /> <br /> Proponho ampliar os conceitos de ferramentas para monitoramento BGP: além dos ''looking glasses'' e consultas a ''route views'', os ASNs devem manter bases de dados próprias com históricos completos do BGP, abrangendo seu cone de clientes e relações com upstreams de trânsito IP e sessões de peering. Isso vai além do &quot;snapshot&quot; atual, permitindo análise temporal de prefixos e ASNs para aplicações técnicas e de negócios. Essa &quot;'''''telemetria orientada a modelos'''''&quot; combina ferramentas baseadas em eventos (CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, BMP) e telemetria de streaming periódica, monitorando objetos relacionados à capacidade e estatísticas de consumo. Interessante, não?<br /> <br /> Em suma, este artigo apresenta propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!<br /> <br /> ==== Observação importante: ====<br /> Se você está esperando uma solução &quot;pronta&quot; ou uma &quot;receita de bolo&quot;, lamento informar, mas não é esta a intenção do artigo. Apresentarei uma visão mais ampla do contexto, explorando o tema através de conceitos de pesquisa aplicada e desenvolvimento experimental. Considere isto um ponto de partida para que você desenvolva seus próprios conhecimentos sobre adoção tecnológica, processos e instrumentos para o gerenciamento e monitoramento do BGP de seu AS. Isso o ajudará a tomar decisões sobre uma ou mais das seguintes possibilidades:<br /> # Investimentos em soluções comerciais existentes, que permitam customizações e integração com outros sistemas para atender às necessidades específicas do seu negócio.<br /> # Desenvolvimento de sistemas com equipe própria de software, contemplando todos os modelos de gerenciamento desejados.<br /> # Adoção de ferramentas específicas para necessidades pontuais, sejam soluções de código aberto ou comerciais.<br /> <br /> === Um &quot;abre-alas&quot; sobre a importância e missão dos sistemas de gerenciamento no geral ===<br /> Antes de começarmos, gostaria de comentar uma característica do meu trabalho que influencia completamente meu julgamento. Aqueles que me conhecem há muito tempo sabem que sou bastante insistente em minhas análises, visões, conclusões e objeções. E essas pessoas que me conhecem bem, quantas vezes já não me ouviram repetir a seguinte frase?&lt;blockquote&gt;''&quot;Muitos profissionais de ISP (incluindo gestores) falham ao investir e tomar decisões cruciais para seus negócios: adquirem soluções tecnológicas focando apenas nas necessidades de curto prazo, frequentemente optando por alternativas minimalistas e baseadas unicamente no menor custo&quot;''&lt;/blockquote&gt;A relação desta frase com o artigo em questão é óbvia, como você verá a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem um propósito bem definido para as áreas do negócio que realmente importam. Frequentemente, a necessidade é óbvia ou específica, como &quot;monitorar o consumo de banda de uma interface conectada a um upstream de trânsito IP&quot; - algo plenamente justificável!<br /> <br /> No entanto, o maior problema não está no objeto gerenciado (monitoramento de banda, problemas de interface, processamento, etc.), mas na ausência de análises associadas aos objetos gerenciados pelas ferramentas escolhidas pela organização e implantadas pela equipe técnica. Em outras palavras: o software está &quot;lá&quot;, implantado, sendo subutilizado pelos operadores.<br /> <br /> Mas quais são os reais objetivos? Quais são os indicadores desejados? Quais são os ''thresholds''? Quais são as métricas gerenciáveis de cada componente? Como determinados ''thresholds'' e eventos impactam o negócio? Que ações tomaremos para prevenir, mitigar e responder aos eventos detectados? Como este objeto gerenciado influencia as diversas áreas do negócio — comercial, reputacional, financeiro (capex, opex, fluxo de caixa), engenharia (capacidade, disponibilidade, resiliência, recursos, tráfego), operações, fornecedores e outros?<br /> <br /> A lista é extensa.<br /> <br /> Em 30 anos de profissão, o que mais encontrei foram soluções de gerenciamento praticamente &quot;encalhadas&quot;, subutilizadas! São sistemas complexos e interessantes dos quais se extraem apenas recursos pontuais, sem que dados importantes sejam coletados, tratados e aproveitados pelas áreas relevantes do negócio, seja para aprimorar aspectos técnicos ou comerciais.<br /> <br /> Resumindo: ''em muitas empresas não há efetivamente um projeto prevendo a construção (ou adoção/contratação) de sistemas de gerenciamento''. O gerenciamento efetivo é frequentemente a parte mais negligenciada da infraestrutura.<br /> <br /> Dissertar extensivamente sobre isso está fora do escopo deste artigo, mas a mensagem é simples: ao lidar com sistemas de gerenciamento, independentemente da finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), conduza um projeto técnico consistente e específico que identifique e documente os seguintes:<br /> * Em alinhamento com o projeto de infraestrutura atual, considerando todo o parque tecnológico existente (hardware e software), quais são as necessidades da área técnica e demais áreas interessadas da empresa?<br /> * Quais problemas enfrentamos atualmente e quais gostaríamos de prevenir?<br /> * Como cada problema, incidente ou circunstância afeta os negócios da empresa? É possível quantificar os prejuízos (reputação, multas, reparações, cancelamentos de contratos, perda de receitas, custos imprevistos, etc.)? Quais áreas internas são impactadas e como podemos estabelecer essa correlação?<br /> * Quais serão os objetos gerenciados?<br /> * Quais recursos de gerenciamento nosso parque tecnológico (HW e SW) suporta? Quais são as capacidades necessárias para cada recurso?<br /> * Dentre as tecnologias e recursos disponíveis e suportados pela infraestrutura, quais são as opções mais adequadas para cada objeto gerenciado? (prós e contras, matriz funcional de qualidade, etc.)<br /> * Quais indicadores e métricas devemos estabelecer para estes objetos gerenciados, considerando os recursos de gerenciamento mais apropriados aos nossos objetivos?<br /> * Como as áreas internas do negócio utilizarão estes análises, indicadores e métricas?<br /> * Quais processos devemos estabelecer para ações de prevenção, mitigação e reação em relação aos ''thresholds'' dos objetos gerenciados?<br /> * Entre outras questões importantes.<br /> Somente após responder estas perguntas e planejar toda a iniciação do projeto de gestão é que você encontrará a solução ideal e as ferramentas apropriadas, utilizando critérios consistentes de funcionalidades, recursos, integração e custos. Esta é a abordagem que deve ser pensada e projetada, lembrando que é necessário estabelecer os processos antes de chegar a estas conclusões. Dica: para o tema &quot;processos&quot;, confira o artigo [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]! <br /> <br /> A implantação e operação de sistemas de gerenciamento, independentemente de sua finalidade, deve começar com um plano de projeto que identifique: necessidades, desafios, métricas desejadas, capacidades requeridas, elementos a serem gerenciados, recursos necessários, métodos de coleta e processamento de dados, e como a organização utilizará estas informações para melhorar seus indicadores.<br /> <br /> [[Arquivo:Bpf-gerbgp-requisitos.png|centro|miniaturadaimagem|900x900px|&quot;Carroça não anda na frente de boi&quot;: exercite o planejamento antes de sair implantando ferramentas, e usufrua de melhores resultados!]]<br /> <br /> === Por que um ASN precisa investir no gerenciamento de seu ambiente BGP? ===<br /> Ou '''''quais problemas poderão ser resolvidos com o gerenciamento efetivo do BGP em seu ASN'''''?<br /> <br /> A sequência deste artigo estará centrada no &quot;BGP&quot; e em elementos que participam diretamente de seu funcionamento. Não pretendo dissertar sobre necessidades, objetivos e requisitos gerais das disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isso não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?<br /> <br /> Imaginemos que as áreas de engenharia e operações de um ISP concordem sobre a necessidade de ter ampla visibilidade e acesso a informações do BGP. Isso permitiria discutir formas de antecipar e mitigar riscos, além de responder a diversos tipos de incidentes relacionados à segurança, disponibilidade, performance e SLA em geral. Também auxiliaria no planejamento de capacidades e na engenharia financeira do negócio. Se fôssemos exercitar este consenso entre as duas áreas, quais seriam os critérios mais relevantes? Para este exercício, proponho categorizar os requisitos da seguinte forma:<br /> * '''Segurança do roteamento BGP'''<br /> * '''Segurança do plano de controle da rede'''<br /> * '''Segurança contra ataques de negação de serviços'''<br /> * '''Instabilidades do BGP'''<br /> * '''Engenharia de tráfego'''<br /> * '''Planejamento de capacidades'''<br /> * '''Reputação e conformidade'''<br /> O seu trabalho, na condição de engenheiro de rede ou arquiteto de soluções, deverá ser a busca por respostas para iniciar este planejamento![[Arquivo:Bpf-gerbgp-planejamento.png|centro|miniaturadaimagem|900x900px|Brainstorming para o planejamento de uma solução de gerenciamento específica para o BGP]]<br /> Vamos explorar este caso hipotético analisando os conceitos de Necessidades, Requisitos e Problemas ou desafios a serem resolvidos pelas organizações que operam um Sistema Autônomo, sejam elas provedores de acesso à Internet (ISP) ou não:<br /> {| class=&quot;wikitable&quot;<br /> |+<br /> Matriz de Necessidades, Requisitos e Desafios a serem Superados para a Demanda &quot;BGP&quot; do ISP<br /> !Categoria<br /> !Necessidade<br /> !Requisito<br /> !Problemas ou desafios a serem resolvidos<br /> !Partes interessadas<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento da segurança do roteamento BGP'''<br /> |Deteção e mitigação de prefixos Bogons<br /> |Identificação e mitigação de prefixos Bogons, Maritans e não alocados<br /> |<br /> * Evitar o recebimento e propagação de rotas referentes a prefixos Bogons, Martians e Unallocated<br /> * Aumentar a reputação do Sistema Autônomo, como parte de boas práticas para a prevenção de incidentes de segurança associados a anúncios bogons.<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de vazamento de rotas e sequestro de prefixos do ASN<br /> |Identificação e mitigação de route leaks<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Assegurar que o ASN não crie ou gere route leaks, assim como assegurar que route leaks não sejam aceitos a partir de sessões de clientes, peering e trânsito<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Encurtar o tempo de deteção de incidentes envolvendo route leaks<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de route leaks<br /> |NOC, Engenharia<br /> |-<br /> |Identificação e mitigação de sequestro de prefixos (prefix hijacks)<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Evitar que o ASN não sequestre prefixos, assim como recusar o recebimento de quaisquer anúncios com ROA (RPKI) e/ou IRR inválidos<br /> * Encurtar o tempo e detecção de incidentes envolvendo o sequestro de prefixos<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de sequestro de prefixos<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de abusos contra recursos do BGP<br /> |Controle de recebimento de anúncios de ASNs vizinhos<br /> |<br /> * Evitar abusos e possíveis impactos relacionados à capacidades e escassez de recursos<br /> * Evitar que ASNs de clientes anunciem de forma acidental ou maliciosa uma quantidade de prefixos superior à estimada ou autorizada<br /> * Evitar abusos com a desagregação através de anúncios excessivamente específicos recebidos de clientes, peering e trânsito<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> |Controle de abuso de AS-Path Prepending<br /> |<br /> * Evitar que o ASN do ISP, assim como ASNs vizinhos e o restante da Internet, sofram possíveis impactos e instabilidades quanto à prefixos com excesso de AS-Path Prepending atrelado aos anúncios<br /> * Evitar abusos quanto ao recebimento de rotas BGP que contenham AS-Path Prepending excessivos (uma forma de ''Self-Inflicted Vulnerability'')<br /> * Encurtar o tempo de detecção de incidentes desta natureza.<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da segurança do plano de controle da rede'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de incidentes de segurança contra o próprio BGP<br /> |Controle de vulnerabilidades sobre as mensagens do BGP<br /> |<br /> * Evitar indisponibilidades e outros tipos de incidentes que possam ser provocados com a exploração das mensagens do BGP (conforme (3.1. Vulnerabilities in BGP Messages do &lt;nowiki&gt;RFC 4272&lt;/nowiki&gt;)<br /> * Evitar a manipulação e injeção maliciosa de atributos sobre os anúncios por mensagens ''Update'' do BGP<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de exploração destas vulnerabilidades<br /> |SOC, NOC. Engenharia<br /> |-<br /> |Controle de incidentes de segurança lançados diretamente contra as sessões BGP<br /> |<br /> * Evitar que as sessões BGP sejam atingidas diretamente por técnicas maliciosas que visam desde o downtime/indisponibilidade, sequestro de sessões, injeção de informações errôneas<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de ataques lançados contra os processos BGP<br /> |SOC, NOC, Engenharia<br /> |-<br /> |'''Gerenciamento da segurança contra negação de serviços'''<br /> |Detecção e mitigação contra ataques DDoS<br /> |Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS<br /> |<br /> * Evitar ou atenuar efeitos adversos de indisponibilidades, instabilidades, impactos severos no SLA de clientes, prejuízos financeiros de grandes proporções, e danos na reputação da empresa<br /> * Evitar a injeção de informações maliciosas na tabela BGP que permitam livre comunicação entre hosts infectados em suas botnets<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e mitigação de DDoS<br /> |SOC, NOC, Engenharia<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento de instabilidades do BGP'''<br /> | rowspan=&quot;5&quot; |Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA<br /> |Detecção de oscilações de sessões BGP<br /> |<br /> * Evitar que ocorram instabilidades na prestação de serviços de acesso à Internet por conta de oscilações das sessões BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e problemas com as sessões BGP<br /> |NOC<br /> |-<br /> |Detecção de oscilações de rotas (route flaps)<br /> |<br /> * Evitar que ocorram indisponibilidades na comunicação com determinados serviços/destinos de Internet por conta de oscilações e intermitências quanto à convergência da tabela BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e oscilações de rotas BGP<br /> |NOC<br /> |-<br /> |Detecção de rotas eventualmente suprimidas por Dampening<br /> |<br /> * Evitar discrepâncias nas matrizes de tráfego e, de certa forma, atenuar a assimetria do roteamento IP, ''blackhole'' ou ''routing loops'' por conta da eventual supressão de rotas (dampening) executada no ASN local ou em vizinhos<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de supressão de rotas BGP e como estes eventos afetam o comportamento da rede e a disponibilidade de serviços<br /> |NOC<br /> |-<br /> |Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces<br /> |<br /> * Evitar que determinados recursos tais como capacidade de enlaces, arquiteturas de roteadores (CPU, memória, FIB, etc.) fiquem subutilizados enquanto outros elementos fiquem sobrecarregados<br /> * Evitar gargalos nas operações e transações de rede, os quais podem provocar impactos no SLA<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção de gargalos e esgotamento de recursos<br /> |NOC, Engenharia<br /> |-<br /> |Planejamento e antecipação de cenários &quot;what if&quot;<br /> |<br /> * Evitar que manobras de configurações, incluindo modificações nas políticas de roteamento e ações de engenharia de tráfego provoquem distúrbios não antecipados<br /> * Antecipar impactos na convergência e disponibilidade da rede através de uma análise preditiva envolvendo cenários de falhas<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;4&quot; |'''Gerenciamento da engenharia de tráfego'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de impactos sobre os recursos de infraestrutura decorrentes de eventos pontuais na Internet<br /> |Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento<br /> |<br /> * Superar as limitações operacionais da empresa em função da escassez de informações e a falta de visibilidade sobre os fluxos de tráfego<br /> * Aprimorar as ações de dimensionamento de recursos de infraestrutura, tais como plataformas de switches e roteadores, além de enlaces de comunicação de dados<br /> * Aprimorar os resultados das ações de engenharia tráfego para fins de acomodar melhor as conversações da rede sobre os recursos disponíveis<br /> * Atenuar ou eliminar os desafios que provocam impactos sobre o SLA de assinantes<br /> * Fornecer analíticos, dados históricos e baselines relacionados às matrizes de tráfego, com histórico de consumo por ASN, peer, prefixo, protocolo de transporte, tipo de aplicação, marcações, atributos, etc.<br /> |Engenharia<br /> |-<br /> |Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas<br /> |<br /> * Reduzir os indicadores de MTTR e MDT associados aos eventos de falhas relacionadas ao BGP<br /> * Reduzir os indicadores de reclamações por conta da violação de SLAs envolvendo indisponibilidades, latência, jitter, perda de pacotes, etc.<br /> * Reduzir os impactos provocados nas áreas internas do negócio que são destinadas ao interfaceamento com clientes, tais como comercial, atendimento a clientes, NOC, jurídico, etc.<br /> * Fornecer analíticos, dados históricos e baselines referentes aos impactos decorrentes de falhas para alimentar as tomadas de decisão e para nortear os investimentos e processos de mitigação<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Aprimoramento de SLA<br /> |Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP<br /> |<br /> * Reduzir impactos não antecipados sobre ações de engenharia de rede e de tráfego executadas pela área de engenharia ou de operações da empresa<br /> * Aprimorar as tomadas de decisão acerca das políticas de roteamento para o atendimento dos modelos de interconexão privado e público<br /> * Aprimorar as tomadas de decisão para as políticas de roteamento de acordo com os modelos de interesse de tráfego (''hot potato'', ''cold potato'', e outras diretrizes) sobre os regimes de interconexão <br /> * Fomentar ações racionais de engenharia de tráfego para equilibrar as métricas de SLA (latência, jitter, disponibilidade) sobre os custos (opex) de cada enlace de transporte e de de cada acordo de troca de tráfego<br /> |Engenharia<br /> |-<br /> |Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como MPLS TE e SR-TE<br /> |<br /> * Assegurar aderência quanto ao mapeamento do tráfego sobre os recursos locais do AS, prevendo simultaneamente as métricas de desempenho e a relação de custos de infraestrutura para a sustentação de SLAs<br /> * Promover a redução racional de custos através da associação de classes de tráfego ou de matrizes de conversação sobre os enlaces e sessões associadas às métricas de SLA de cada caso<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;3&quot; |'''Gerenciamento da planejamento de capacidades'''<br /> | rowspan=&quot;3&quot; |Planejamento de capacidades com foco na redução racional de custos operacionais<br /> |Bilhetagem e tarifação de tráfego<br /> |<br /> * Determinação da matriz de tráfego em combinação com iniciativas de bilhetagem e tarifação para determinar rateio de custos de infraestrutura nas áreas internas do negócio<br /> * Fornecer métricas de utilização dos fluxos de tráfego de interesse sobre os recursos de transporte para identificar áreas de otimização de custos<br /> * Viabilizar a compreensão da participação de cada centro de custo / área interna do negócio quanto aos padrões de consumo e contribuições orçamentárias<br /> * Viabilizar e fomentar a derivação da política de preços de produtos e serviços destinados a clientes em função das matrizes de tráfego, interesses de tráfego e modelos de interconexão<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Dimensionamento de recursos de transporte e acordos de troca de tráfego<br /> |<br /> * Planejamento de capacidades de conexões do ISP com os acordos de troca de tráfego nos regimes de peering e trânsito IP, incluindo 95th percentil<br /> |Engenharia<br /> |-<br /> |<br /> * Dimensionamento de especificações, requisitos, recursos e capacidades das arquiteturas e demais componentes de infraestrutura a serem utilizados para a sustentação dos modelos de interconexão para os perfis de tráfego<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da reputação e conformidade'''<br /> |Conquistar níveis de excelência em conformidade<br /> |Deteção e mitigação de incidentes e situações não aderentes aos frameworks e boas práticas destinadas aos Sistemas Autônomos<br /> |<br /> * Fornecer analíticos e dados históricos que classifiquem as ocorrências de incidentes provocados por eventos previstos e imprevistos pelas políticas internas da empresa<br /> * Fornecer métricas auditáveis quanto os incidentes de segurança associados ao BGP<br /> |NOC, SOC, Engenharia<br /> |-<br /> |Conquistar níveis de excelência na reputação do Sistema Autônomo<br /> |Fornecimento de ferramentas para o compartilhamento de transparência e iniciativas de suporte com outros (demais) Sistemas Autônomos<br /> |<br /> * Manutenção de sistemas e bases de informação que divulguem, dentre outros, a política de roteamento da empresa, plano de communities, &quot;normas da casa&quot;, requisitos de segurança, requisitos de interconexão, modalidades de SLA, etc.<br /> * Manutenção de sistemas e bases de informação que forneçam os pontos de contato e suporte para as demandas associadas ao BGP e contextos periféricos do AS, tais como &quot;Abuse&quot;, &quot;Peering&quot;, &quot;NOC&quot;, e outros<br /> * Disponibilização de ferramentas de autosserviço para a redução do tempo de diagnóstico e identificação de problemas por parte de NOCs de outros Sistemas Autônomos, tais como Looking Glass e outros.<br /> * Promover aderência quanto às boas práticas citadas pelos objetivos &quot;''Coordination''&quot; e &quot;''Global Validation''&quot; do ''Mutually Agreed Norms for Routing Security'' (MANRS) <br /> * Fornecer analíticos acerca da utilização das ferramentas de autosserviço para identificar necessidades de mercado, técnicas, perfil dos visitantes, áreas de interesse e geração de novas oportunidades <br /> |NOC<br /> |}<br /> <br /> === Exemplos de soluções conhecidas para o atendimento das diversas necessidades e requisitos associados ao gerenciamento do Sistema Autônomo ===<br /> No que diz respeito aos conjuntos de necessidades e requisitos fornecidos na tabela anterior, compreendo que se tratam de situações absolutamente reais. Ao projetar a tabela acima, não pensei diretamente nas possíveis soluções e ferramentas para cada caso. Toda a linha de raciocínio foi estabelecida sobre '''''necessidades + requisitos + problemas + desafios''''' que a maioria dos operadores de redes precisa lidar em suas operações cotidianas.<br /> <br /> Entretanto, chegou o momento de traduzir isto para um plano concreto. Precisamos identificar ferramentas que forneçam resultados para cada uma das situações descritas na tabela anterior. É isto que farei agora: primeiro, &quot;espalhar na mesa&quot; as soluções disponíveis no mercado que podem executar estes casos e atender estas necessidades.<br /> <br /> Note que as ferramentas associadas a cada tipo de requisito não se limitam apenas às funcionalidades daquele requisito específico. Organizei desta forma para demonstrar que cada ferramenta foi considerada após identificar e confirmar o par &quot;necessidade + requisito&quot; em meu conceito de projeto.<br /> <br /> Está fora do escopo desta parte do artigo qualquer análise de aderência qualitativa (&quot;''o quão bem a ferramenta X executa e atende as necessidades, requisitos, problemas, desafios...''&quot;), assim como comparações entre as opções mencionadas (&quot;''qual é a melhor ferramenta para a necessidade X?''&quot;).<br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança do roteamento BGP<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação e mitigação de prefixos Bogons, Martians e não alocados'''<br /> | rowspan=&quot;3&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://radar.qrator.net/ RADAR by QRATOR]<br /> * [https://team-cymru.com/community-services/bogon-reference/ Team Cymru fullbogons]<br /> |-<br /> |'''Identificação e mitigação de route leaks'''<br /> |-<br /> |'''Identificação de sequestro de prefixos'''<br /> |}<br /> O &lt;nowiki&gt;RFC 7908&lt;/nowiki&gt; (''Problem Definition and Classification of BGP Route Leaks'') caracteriza e classifica detalhadamente os incidentes denominados route leaks, enquanto o draft-ietf-grow-route-leak-detection-mitigation-02 (''Methods for Detection and Mitigation of BGP Route Leaks'') propõe mecanismos para sua detecção e mitigação. A dissertação sobre route leaks está fora do escopo deste artigo.<br /> <br /> Adicionalmente, foram produzidos diversos documentos com recomendações para mitigação de prefix hijack, incluindo o BCP 185 (''Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)''), &lt;nowiki&gt;RFC 7682&lt;/nowiki&gt; (''Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration''), &lt;nowiki&gt;RFC 2650&lt;/nowiki&gt; (''Using RPSL in Practice''), e o &quot;''Action 1: Prevent propagation of incorrect routing information''&quot; do Mutually Agreed Norms for Routing Security (MANRS). A dissertação sobre prefix hijack está fora do escopo deste artigo.<br /> <br /> As ferramentas mencionadas na tabela acima podem fornecer dados e, em alguns casos, oferecer automação na resposta a incidentes de route leaks, prefix hijacks e outras situações. Uma possibilidade interessante é a integração entre essas ferramentas/serviços através de suas APIs. Por exemplo, a [https://developer.thousandeyes.com/v6/ ThousandEyes fornece APIs] que podem ser integradas com outros sistemas, assim como as [https://portal.bgpmon.net/bgpmonapi.php APIs do BGPmon da Cisco], [https://api.qrator.net/ APIs da QRATOR], etc.<br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança e instabilidades do roteamento BGP <br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de recebimento de anúncios de ASNs vizinhos'''<br /> | rowspan=&quot;5&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://bgpstream.caida.org/ BGPStream]<br /> * [https://share.zabbix.com/search?searchword=BGP&amp;search_cat=1 Zabbix com plugins compatíveis com estas necessidades]<br /> |-<br /> |'''Controle de abuso de AS-Path Prepending'''<br /> |-<br /> |'''Detecção de oscilações de sessões BGP'''<br /> |-<br /> |'''Detecção de oscilações de rotas (route flaps)'''<br /> |-<br /> |'''Detecção de rotas eventualmente suprimidas por Dampening'''<br /> |}<br /> As ferramentas indicadas na tabela acima fornecem as funcionalidades necessárias para que o administrador do Sistema Autônomo possa identificar e reagir a diversas situações envolvendo sessões e anúncios do protocolo BGP. <br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento engenharia de tráfego e planejamento de capacidades<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento'''<br /> | rowspan=&quot;7&quot; |<br /> * [https://www.made4flow.com.br Made4Flow]<br /> * [https://www.telcomanager.com/trafip-analise-de-trafego/ TRAFip]<br /> * [https://www.noction.com/intelligent-routing-platform-bgp-network-optimization Noction IRP]<br /> * [https://www.blueplanet.com/products/route-optimization.html Ciena BluePlanet ROA]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/crosswork-network-automation/datasheet-c78-740228.html Cisco Crosswork Network Insights]<br /> * [https://www.manageengine.com/products/netflow/ ManageEngine NetFlow Analyzer]<br /> * [https://developer.cisco.com/docs/wan-automation-engine/#!overview/cisco-wan-automation-engine Cisco WAE em combinação com XTC]<br /> |-<br /> |'''Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas'''<br /> |-<br /> |'''Bilhetagem e tarifação de tráfego'''<br /> |-<br /> |'''Dimensionamento de recursos de transporte e acordos de troca de tráfego'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como BGP-LS, MPLS TE e SR-TE'''<br /> |-<br /> |'''Planejamento e antecipação de cenários &quot;what if&quot;'''<br /> |}<br /> Compreender os fluxos de tráfego, tanto na rede do próprio AS quanto nas conexões com AS vizinhos, é fundamental para que o provedor tome decisões técnicas adequadas no projeto e na operação diária. O provedor necessita dessas informações para realizar o dimensionamento correto dos recursos que atenderão seus assinantes e serviços, executar a engenharia de tráfego e abordar aspectos cruciais como disponibilidade, padrões de redundância, resiliência e métricas de confiabilidade. Tudo isso deve estar alinhado ao projeto técnico e ao plano de negócios. As ferramentas mencionadas na tabela acima oferecem funcionalidades que atendem adequadamente a estes requisitos.<br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento da segurança do plano de controle da rede e segurança contra negação de serviços<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de vulnerabilidades sobre as mensagens do BGP'''<br /> | rowspan=&quot;4&quot; |<br /> * Ferramentas e soluções de detecção e prevenção de intrusão<br /> * [https://ddos.lp.made4it.com.br/ Made4Flow Anti-DDoS]<br /> * [https://www.andrisoft.com/software/wanguard Andrisoft Wanguard]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://br.netscout.com/arbor-ddos Arbor para Operadoras]<br /> * [https://wiki.brasilpeeringforum.org/w/UTRS_Registro_e_Configuracao Team Cymru UTRS]<br /> |-<br /> |'''Controle de incidentes de segurança lançados diretamente contra as sessões BGP'''<br /> |-<br /> |'''Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS'''<br /> |-<br /> |'''Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces'''<br /> |}<br /> Tão importante quanto a disponibilidade, performance e visibilidade geral dos componentes associados ao funcionamento do BGP em um Sistema Autônomo é o gerenciamento da segurança da infraestrutura como um todo, especialmente nas questões diretamente relacionadas ao roteamento do AS. Quanto à segurança geral do AS, diversos aspectos já foram abordados em outros artigos publicados na Wiki do Brasil Peering Forum, como o [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] e [[Boas Praticas para Melhorar a Seguranca de seu Provedor|Boas Práticas para Melhorar a Segurança de seu Provedor]]. As soluções mencionadas na tabela acima são recomendadas para mitigar incidentes de segurança e ataques DDoS direcionados à rede do ISP e/ou seu cone de clientes.<br /> <br /> === Modelos e ferramentas orientadas ao gerenciamento do BGP ===<br /> Deixando de lado o discurso sobre &quot;necessidades, requisitos, desafios, etc.&quot;, vamos discutir as possibilidades práticas de modelos e ferramentas de gerenciamento que podemos utilizar com o BGP. Afinal, não adianta imaginarmos um mundo perfeito ao estilo &quot;''imagine all the people...''&quot; se não temos formas efetivas de implementar o que desejamos, certo? Precisamos ser realistas e analisar as possibilidades concretas. Por mais que nossas mentes criativas sonhem em fazer tudo funcionar num estalar de dedos, na prática precisamos lidar com as limitações das informações e análises que podemos efetivamente extrair dos elementos de nossa rede. <br /> <br /> Antes de explorarmos os tipos de dados disponíveis em nosso ambiente e suas aplicações, vamos primeiro entender os protocolos, serviços e procedimentos que nos permitem coletar informações dos equipamentos e sistemas de nossa infraestrutura.<br /> <br /> === Modelo &quot;pull&quot; tradicional de recuperação de dados ===<br /> O modelo ''pull'' de recuperação de dados consiste em procedimentos onde estações de gerenciamento acessam os dispositivos para obter informações sobre objetos gerenciados. Os procedimentos mais comuns utilizam protocolos como ''Simple Network Management Protocol'' (SNMP), ''Remote Monitoring'' (RMON), ''Secure Shell'' (SSH) e ''Telnet''.<br /> <br /> Como o próprio termo sugere (''pull''), os sistemas de gerenciamento requisitam informações dos equipamentos através de mecanismos de solicitação e resposta. No SNMP, por exemplo, utilizam-se mensagens ''GetRequest'', ''GetBulkRequest'' e ''GetResponse'' para consultar objetos gerenciados (''Object Identifier'' (OID)). Estes objetos são especificados em bibliotecas ''Management Information Base'' (MIB) que devem ser compatíveis tanto com o equipamento (ex: roteador) quanto com a estação de gerenciamento.<br /> <br /> Outra abordagem envolve scripts nas estações de gerenciamento que estabelecem conexões diretas com a interface de linha de comando (CLI) dos equipamentos. Estes scripts executam comandos específicos como a verificação de contadores de interface (&quot;''show interfaces''&quot;), status das sessões BGP (&quot;''show bgp summary''&quot; e &quot;''show bgp neighbor''&quot;), ou contagem de rotas anunciadas para vizinhos BGP (&quot;''show route advertising-protocol bgp x.x.x.x''&quot; no JUNOS, &quot;''show bgp neighbor x.x.x.x advertised-routes''&quot; no Cisco IOS XR). A saída desses comandos é armazenada em arquivos temporários para posterior processamento e análise por outros scripts e procedimentos.<br /> <br /> ==== Modelo &quot;push&quot; tradicional de recuperação de dados ====<br /> O modelo ''push'' de recuperação de dados ocorre no sentido inverso ao modelo ''pull'': os equipamentos da rede encaminham as informações para as estações de gerenciamento. Isto pode ocorrer através de definições periódicas do serviço monitorado ou baseado em eventos. Um exemplo são as mensagens ''Trap'' do protocolo SNMP, que incluem duas variáveis primárias: o ''sysUpTime'' e o ''snmpTrapOID'', além de instruções para reportar condições detectadas no monitoramento de um OID. O coletor de eventos reconhece estas mensagens através do ''InformRequest-PDU''.<br /> <br /> Outro exemplo de modelo ''push'' é o serviço Syslog com suas 24 &quot;''facilities''&quot; (0 a 23) definidas pelo &lt;nowiki&gt;RFC 5424&lt;/nowiki&gt;. Algumas facilities são reservadas para aplicações específicas, enquanto outras são de uso local. Estas se combinam com 8 níveis de severidade (0=EMERGENCY, 1=ALERT, 2=CRITICAL, 3=ERROR, 4=WARNING, 5=NOTICE, 6=INFORMATIONAL, 7=DEBUG) para comunicar eventos a uma estação coletora. Sistemas de correlação de eventos processam estas informações para reportar diversas situações e gerar métricas. Scripts podem atuar de forma independente ou integrada aos sistemas de gerenciamento.<br /> <br /> O modelo ''push'' também inclui ferramentas nativas dos sistemas operacionais de roteadores e switches, como o ''Cisco Embedded Event Manager'' (EEM) e ''Junos Event Scripts'', além de recursos similares de outros fabricantes, que permitem flexibilizar o encaminhamento de eventos e informações para servidores da rede.<br /> <br /> ==== Telemetria orientada a modelos ====<br /> Ou MDT. Embora os modelos ''pull'' e ''push'' tradicionais tenham limitações, protocolos como SNMP, shell scripting e recursos nativos dos roteadores não serão abandonados. Ao contrário, devem ganhar propósitos mais específicos, menos generalistas, enquanto novas tecnologias surgem para aprimorar o gerenciamento de configurações, performance, falhas, analíticos e ''big data''. É neste contexto que surge o conceito de '''''telemetria''''' em sua forma mais abrangente.<br /> <br /> A telemetria orientada a modelos integra &quot;''telemetria orientada a eventos''&quot; e &quot;''telemetria de streaming periódica''&quot;, oferecendo resultados superiores não apenas para o gerenciamento FCAPS, mas principalmente para ''big data'' e analíticos, diferenciando-se dos modelos tradicionais.<br /> <br /> A principal distinção entre as abordagens tradicional e de telemetria está na forma de coleta. O modelo tradicional usa principalmente SNMP com método ''pull'', exceto para SNMP Traps que operam por ''push''. Na telemetria por streaming periódico, os dados fluem em tempo real dos elementos da rede para os coletores, seguindo o conceito ''push'', mas com maior capacidade e disponibilidade de informações. Um exemplo notável de telemetria orientada a eventos é o ''BGP Monitoring Protocol'' (BMP), que monitora operações BGP em tempo real no seu ASN. Os benefícios desta abordagem serão detalhados adiante.<br /> <br /> A ilustração a seguir exemplifica as diferenças e principais componentes empregados em cada um dos casos citados aqui:[[Arquivo:Bpf-gerbgp-comparativosger.jpg|centro|miniaturadaimagem|907x907px|Comparativos entre os modelos de gerenciamento factíveis para o BGP]]<br /> <br /> ==== Comparativos entre os diversos tipos de tecnologias (protocolos e serviços), suas capacidades, finalidades e propósitos, e suas respectivas categorizações ====<br /> A tabela a seguir apresenta informações essenciais sobre os aspectos e possibilidades do gerenciamento BGP.<br /> {| class=&quot;wikitable&quot;<br /> |+Tabela comparativa entre diversos tipos de protocolos e serviços, suas capacidades, finalidades e propósitos<br /> !Ferramenta<br /> <br /> (Protocolo e/ou Serviço)<br /> !Alguns exemplos de situações em que pode ser empregada<br /> |-<br /> |'''SNMP (operações &quot;Get&quot;)'''<br /> |Operações de recuperação e amostragem de informações obtidas por meios de operações &quot;get&quot; do SNMP.<br /> * Consultas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Identificação de propriedades de sessões BGP (ex: temporizadores) e capacidades suportadas<br /> * Identificação da quantidade de rotas aceitas de uma sessão BGP<br /> * Identificação da quantidade de rotas recusadas de uma sessão BGP<br /> * Identificação da quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Identificação de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> * Recuperação da tabela de roteamento (Ex: 1.3.6.1.2.1.4.21 - ipRouteTable)<br /> |-<br /> |'''SNMP Traps'''<br /> |Alertas que poderão ser recebidos por sistemas de gerenciamento com suporte às MIBs necessárias.<br /> * Alertas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Alertas de quantidade de rotas recebidas de uma sessão BGP<br /> * Alertas de quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Alertas de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> |-<br /> |'''RMON'''<br /> |O RMON tem pouca ou nenhuma utilidade específica para os interesses de gerenciamento do BGP, mas suas capacidades e recursos poderão ser obtidas e combinadas para agregar valor ao propósito de gerenciamento como um todo.<br /> * Estatísticas em tempo real de utilização dos segmentos Ethernet envolvidos no transporte de sessões BGP (utilização, erros, colisões)<br /> * Fornecer histórico de estatísticas selecionadas, e com suporte ao uso de variáveis especificadas pelo usuário.<br /> <br /> * Encaminhamento de alarmes para RMON SNMP traps quando houver o cruzamento de determinados thresholds pré-definidos, inclusive com suporte a grupos de alarmes.<br /> * Monitoramento de hosts, tais como a quantidade de bytes e frames enviados e recebidos de vizinhos BGP.<br /> * Ordenamento de &quot;top hosts&quot; com coleta e manutenção de dados referentes a conexões ativas por um determinado período de tempo.<br /> * Matriz de tráfego entre dois roteadores envolvidos numa sessão BGP.<br /> * Filtragem de dados com base em padrões de interesse do administrador, tais como endereços MAC, e portas de protocolos de transporte.Captura de pacotes para análise posterior em depuradores.<br /> * Descoberta e estatísticas por protocolo.<br /> * Mapeamento entre endereços MAC e endereços IP referentes as sessões BGP<br /> * Estatísticas de tráfego L3 com ordenamento por host ou par de conversação (origem/destino), como complemento ao monitoramento do BGP.<br /> * Estatísticas de tráfego L7 por protocolo de aplicação e por host, como complemento ao monitoramento do BGP.<br /> |-<br /> |'''Syslog'''<br /> |Alertas que poderão ser recebidos por servidores syslog &quot;crus&quot; ou uma solução específica para correlação de eventos e processamento de analíticos.<br /> * Alertas de esgotamento de recursos de memória para algum processo ou ação do BGP<br /> * Alertas de problemas com a instalação de rotas BGP devido a inconsistências ou atributos inválidos<br /> * Alertas de falhas de semântica de políticas (route-map, route-policy, etc.) vinculadas a sessões BGP<br /> * Alertas de falhas nas estruturas internas dos processos BGP<br /> * Alertas de problemas de processamento de ações sobre atributos (ex: remoção de AS_PATH, modificação de NEXT_HOP)<br /> * Alertas de recebimento de prefixos inválidos (ex: Martians)<br /> |-<br /> |'''Shell scripting para invocação de CLI'''<br /> |Recuperação de qualquer informação possível por comandos na CLI do roteador.<br /> * Verificação do status de todas as vizinhanças BGP<br /> * Verificação detalhada de uma vizinhança BGP específica<br /> * Contadores de prefixos anunciados e recebidos por vizinho BGP<br /> * Detalhamento das rotas BGP anunciadas para um determinado vizinho BGP<br /> * Detalhamento das rotas BGP recebidas de um determinado vizinho<br /> * Consultas sobre a tabela BGP integral<br /> * Consultas sobre a tabela BGP com parâmetros de refinamento (expressão regular/regex, community, next-hop, policy...)<br /> * Consultas sobre a tabela BGP de rotas não filtradas (pré-policy) de um determinado vizinho (soft-reconfig inbound)<br /> |-<br /> |'''Cisco EEM'''<br /> |Componente do software de roteadores da Cisco, permitindo que você automatize tarefas, execute modificações e ajustes sobre diversos componentes lógicos, e crie ações alternativas. Dentre muitas possibilidades, e focando aqui no BGP, é possível:<br /> * Monitorar o estado operacional ou funcionamento de determinados protocolos e serviços e tomar ações automaticamente em função de algum evento pré-definido por você.<br /> * Implementar uma rotina de verificação de oscilação de sessões BGP, as quais, atingindo um determinado &quot;''threshold''&quot;, poderá invocar uma ação de notificação por Syslog, SNMP, Email (que poderá ser uma máscara de WhatsApp ou Telegram).<br /> * Em adição ao conceito acima, executar uma ação que poderá incluir a modificação de uma route policy para consequente redução do atributo LOCAL_PREF implementado sobre as rotas recebidas de um peer que está oscilando.<br /> * Em adição ao conceito acima, executar uma ação que poderá decidir por desabilitar administrativamente aquela sessão por um determinado período de tempo ou até que haja garantias de que a sessão esteja estável por &quot;x&quot; horas.<br /> * Implementar uma rotina de detecção de existência ou ausência de uma determinada rota BGP na tabela de roteamento (RIB), permitindo uma ação desejada que poderia incluir o estabelecimento de um túnel GRE ou TE, o &quot;shutdown&quot; ou &quot;no shutdown&quot; de uma interface, uma mudança de policy, etc.<br /> * Implementar uma rotina que vá coletar informações (tabela BGP, NLRIs com determinados atributos (ex: communities), rotas BGP da RIB, sessões, etc.) em intervalos periódicos, escrevendo os ''outputs''/dados em um arquivo em um servidor FTP.<br /> * &quot;Quem tem limites é município&quot;. O limite é virtualmente a capacidade criativa do administrador da rede; a sua imaginação. Experimente!<br /> |-<br /> |'''Juniper Event Scripts'''<br /> |Componente embarcado no sistema operacional JUNOS dos roteadores da Juniper Networks e com proposta similar ao Cisco EEM.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o Juniper Event Scripts propõe-se a fazer aquilo que o Cisco EEM faz, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas duas ferramentas.<br /> |-<br /> |'''Huawei Open Programmability System (OPS)'''<br /> |Componente embarcado no sistema operacional dos roteadores da Huawei e com proposta similar ao Cisco EEM e ao Juniper Event Scripts.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o OPS propõe-se a fazer aquilo que o Cisco EEM e o Juniper Event Scripts fazem, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas três ferramentas.<br /> |-<br /> |'''OpenConfig, NETCONF, RESTCONF, gNMI, gRPC, e modelos YANG'''<br /> |O OpenConfig, padrão aberto para o desenvolvimento de interfaces programáticas, viabiliza um gerenciamento mais dinâmico das infraestruturas (ex: telemetria) utilizando como transporte os protocolos e procedimentos NETCONF, RESTCONF, gNMI ou gRPC, em combinação com repositórios de dados modelados pelo YANG, para proporcionar um novo universo de possibilidades em termos de gerenciamento.<br /> <br /> Uma de suas principais aplicabilidades envolve o chamado ''Model-Driven Telemetry'' ou MDT. Quando pensando em gerenciamento por este modelo de telemetria, as possibilidades chegam a surpreender, pois a entrada de dados por ser feita pelos protocolos supracitados, ou ainda por JSON, Kafka, Google Protocol Buffer (GPB), Google RPC (GRPC), dentre outros, a lista é interessante.<br /> <br /> Já a saída de dados poderá ser feita para Kafka, Prometheus, InfluxDB, JSON, XML, e outros, pois a lista é igualmente interessante, o que abre um leque realmente surpreendente de situações e possibilidades. Nunca as redes foram tanto &quot;''software-defined''&quot;: o MDT é um divisor de águas! <br /> * Modelagem e streaming periódico/contínuo de dados para a representação das rotas BGP da RIB com suporte a 5 RIBs lógicas por família de endereços.<br /> * Provimento de definições de dados para tabelas BGP, tipos, identidades, especificações, atributos, e afins, para o gerenciamento efetivo do BGP por OpenConfig.<br /> * Gerenciamento, automação e orquestração de sessões e políticas de roteamento.<br /> * Streaming contínuo de indicadores de performance do BGP, incluindo FSM das sessões, quantidade de sessões, quantidade de rotas total e aceitas/recusadas por neighbor, etc.<br /> * Streaming contínuo de indicadores de anomalias associadas ao BGP.<br /> |-<br /> |'''NetFlow / JFlow / sFlow'''<br /> |O emprego destas tecnologias correlacionam os registros dos fluxos de tráfego juntamente com as informações de roteamento BGP para que seja possível visualizar as conversações para a extração de diversos analíticos importantes.<br /> * Monitoramento em tempo real de registros de fluxos de conversações juntamente com as indicações de Sistemas Autônomos envolvidos.<br /> * Identificação através de pesquisas customizadas sobre fluxos de tráfego por origem, destino, par origem-destino, protocolo de transporte, marcação de QoS, Sistema Autônomo BGP, etc.<br /> * Identificação dos &quot;''top talkers''&quot; por uma variedade de critérios de consulta.<br /> |-<br /> |'''BGP Link-State (BGP-LS)'''<br /> |O BGP Link-State (LS) é uma extensão do protocolo BGP fornecida por meios de um ''Address Family Identifier'' (AFI) e ''Sub-address Family Identifier'' (SAFI) para transportar o ''Link-State Database'' (LSDB) de protocolos IGP (OSPF e IS-IS) através do BGP. <br /> <br /> O BGP-LS permite uma série de aplicações, desde o fornecimento de informações topológicas detalhadas da rede para servidores específicos orientados à otimização de tráfego de rede na camada de Aplicação (ALTO), suporte a Path Computation Element (PCE) para engenharia de tráfego, e outros.<br /> <br /> No que diz respeito ao monitoramento do BGP, o BGP-LS poderá atuar como um componente adicional para agregar mais informações em diversas bases e sistemas onde os dados específicos de BGP são coletados, mantidos, processados, e representados.<br /> * Fornecimento de informações topológicas detalhadas da rede.<br /> * Combinação e correlação dos dados topológicos com estruturas de dados fornecidas por outros meios de gerenciamento centrados na otimização e visibilidade do BGP, tais como sFlow/JFlow/NetFlow, BMP, CLI, e SNMP.<br /> * Visibilidade, correlação de eventos, aprimorar ações de planejamento de capacidades e de engenharia de tráfego, e detecção de incidentes de segurança.<br /> |-<br /> |'''BGP Monitoring Protocol (BMP)'''<br /> |Acesso de sistemas de gerenciamento ao Adj-RIB-In de peers BGP para o recebimento periódico de estatísticas do protocolo.<br /> * Recebimento periódico de estatísticas que possam ser usadas para monitorar as atividades específicas do BGP.<br /> * Recebimento de notificações acerca do estado operacional das sessões BGP.<br /> * Recebimento das tabelas BGP pré-policy, ou seja, antes que o roteador implemente os filtros de import/export sobre as rotas.<br /> * Recebimento das tabelas BGP pós-policy, ou seja, após o roteador ter filtrado e filtrado atributos associados às rotas.<br /> * Em combinação com validadores de IRR, poderá detectar route leaks gerados ou recebidos pelo AS local.<br /> * Em combinação com validadores de RPKI, poderá detectar violações de ASN de origem associados às rotas recebidas ou enviadas.<br /> * Poderá ser combinado para fornecer funcionalidade de Looking Glass.<br /> * Fornecimento de visibilidade histórica envolvendo estado de sessões.<br /> * Fornecimento de visibilidade e histórico de prefixos com refinamento por &quot;peer&quot;, &quot;ASN&quot; e &quot;prefixo&quot;.<br /> * Permite estudar através de uma linha temporal todos os anúncios e recebimentos realizados, incluindo rotas aceitas e recusadas.<br /> * Permite estudar através de uma linha temporal todas as modificações de atributos executadas sobre rotas aceitas.<br /> |}<br /> Como não é possível abordar todos os aspectos em um único artigo — talvez outros textos sobre o tema sejam publicados na Wiki do BPF — vou demonstrar algumas possibilidades com ferramentas e opções da tabela acima. Que tal nos concentrarmos em dois componentes: SNMP e BMP? <br /> <br /> === Monitoramento do BGP com o Simple Network Management Protocol (SNMP) ===<br /> O monitoramento de infraestruturas de redes por SNMP é algo bem estabelecido entre os profissionais da área. Quanto ao monitoramento do BGP, o SNMP tem sido amplamente utilizado por empresas para atender às necessidades e desafios mencionados anteriormente. Por ser uma prática tão difundida — e frequentemente o único método de gerenciamento e monitoramento adotado por ISPs regionais de pequeno e médio porte — não me estenderei muito nesta seção do artigo.<br /> <br /> Diversas plataformas baseadas em software podem ser utilizadas para monitorar o BGP, das quais destaco:<br /> * [https://www.zabbix.com/ Zabbix]<br /> * [https://www.librenms.org/ LibreNMS]<br /> * [https://www.observium.org/ Observium]<br /> * [https://www.nagios.com/ Nagios]<br /> * [https://www.cacti.net/ Cacti]<br /> * [https://www.opennms.com/ OpenNMS]<br /> * [https://www.solarwinds.com/pt/ Solarwinds]<br /> * [https://www.paessler.com/prtg PRTG]<br /> * Integrações de boa parte destas soluções com o [https://grafana.com/ Grafana] para a geração de dashboards<br /> * Soluções comercias de fabricantes tais como Cisco, Juniper e outros<br /> Está fora do escopo deste artigo fazer comparativos (&quot;qual é o melhor?&quot;, etc.) entre estas soluções.<br /> <br /> Independentemente da abordagem/solução que você escolha para atender suas necessidades, será necessário garantir suporte a componentes específicos para o monitoramento do BGP, especialmente a BGP4-MIB, conforme descrita no RFC 4273 (''Definitions of Managed Objects for BGP-4'') e RFC 4275 (''BGP-4 MIB Implementation Survey''). Você também precisará considerar MIBs que implementem OIDs proprietários de acordo com o fabricante do equipamento a ser monitorado pela gerência SNMP, como a [https://www.juniper.net/documentation/en_US/junos/topics/reference/mibs/mib-jnx-bgpmib2.txt '''''Juniper-BGP-MIB'''''] e [https://mibs.cloudapps.cisco.com/ITDIT/MIBS/MainServlet?ReleaseSel=4669&amp;PlatformSel=269&amp;fsSel=348 '''''Cisco-BGP-MIBv2'''''], e assegurar que seus sistemas de gerenciamento (ex: Zabbix) implementem funções para consultas aos OIDs desejados com estas MIBs. Além disso, muitos destes sistemas já possuem plugins prontos para o monitoramento do BGP em diversas condições, por exemplo:<br /> * Zabbix<br /> ** [https://share.zabbix.com/network_devices/cisco/cisco-bgp-ipv4-ipv6-32-bit-asn Cisco BGP IPv4/IPv6 32-bit ASN]<br /> ** [https://share.zabbix.com/network_devices/juniper/juniper-mx-discovery-int-re-bgp4-ipv4-and-ipv6 Template SNMP Juniper MX discovery: int, RE, BGP4 ipv4 and ipv6]<br /> ** [https://share.zabbix.com/network_devices/mikrotik/zabbix-routeros-bgp-monitoring Zabbix RouterOS BGP Monitoring]<br /> * LibreNMS<br /> ** [https://docs.librenms.org/API/Routing/ Monitoramento de sessões BGP] e [https://docs.librenms.org/Alerting/Entities/ Entities]<br /> * Observium<br /> ** [https://docs.observium.org/config_options/ Monitoramento de sessões BGP]<br /> * Nagios<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check-BGP-neighbor-JunOS/details Check BGP Neighbor JunOS]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp/details check_bgp]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_counters/details check_bgp_counters]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_v4_v6/details check_bgp_v4_v6]<br /> * Grafana<br /> ** [https://grafana.com/grafana/plugins/alexanderzobnin-zabbix-app Plugin para Zabbix]<br /> ** [https://grafana.com/grafana/plugins?orderBy=weight&amp;direction=asc Plugins para diversas finalidades e integrações]<br /> ** [https://grafana.com/grafana/dashboards?dataSource=alexanderzobnin-zabbix-datasource&amp;orderBy=name&amp;direction=asc Dashboards &quot;prontos&quot;]<br /> * Outros! basta pesquisar pelos recursos desejados junto à documentação do seu sistema de gerenciamento, entrar em contato com o suporte de desenvolvimento, contratar uma consultoria especializada, etc.<br /> O monitoramento do BGP por SNMP é simples e amplamente utilizado por operadores de redes. As estações de gerenciamento são configuradas para realizar consultas periódicas aos roteadores usando operações &quot;Get&quot; sobre os Object Identifiers (OID) desejados. Estes OIDs devem ser especificados em uma MIB apropriada (ex: BGP4-MIB), com suporte necessário tanto no roteador monitorado quanto no software da estação de gerenciamento. O SNMP atua como um mecanismo de solicitação e resposta. As informações coletadas são armazenadas em bases de dados vinculadas a estas soluções e processadas para gerar relatórios específicos nas funções do sistema. Além disso, estes dados podem ser consultados através de integrações com outros sistemas (ex: Grafana) para criar visualizações mais elaboradas, como painéis e dashboards. Por exemplo:<br /> [[Arquivo:Bpf-gerbgp-snmp.jpg|centro|miniaturadaimagem|900x900px|Exemplo de monitoramento do BGP por procedimento SNMP]]<br /> É importante ressaltar que o gerenciamento de incidentes BGP, como oscilações de sessões (ou &quot;flapping&quot;), pode ser feito através de mensagens SNMP trap. O sistema de gerenciamento (software &quot;NMS&quot;) processa essas mensagens conforme as diretivas definidas para o elemento de rede, destacando os eventos de falha nos painéis de visualização. Embora este seja um conceito básico, vale mencioná-lo para benefício dos leitores menos familiarizados com o tema.<br /> [[Arquivo:Bpf-gerbgp-snmptrap.jpg|centro|miniaturadaimagem|900x900px|SNMP traps para a funcionalidade de notificações e alertas do gerenciamento de falhas]]<br /> <br /> Com profissionais caprichosos, é possível criar painéis eficientes usando soluções simples baseadas em SNMP, especialmente ao utilizar o Grafana. Demonstraremos alguns casos de uso da integração Zabbix + Grafana para monitoramento BGP, onde, além do SNMP, outros métodos podem ser necessários para coletar e visualizar as informações desejadas em cada painel.<br /> <br /> No painel demonstrado a seguir, idealizado pelo Caio Ribeiro da [https://www.facebook.com/flowbix Flowbix], foi possível concentrar muita informação útil/relevante numa única tela: desde status das sessões BGP com seus respectivos ''uptimes'', total de prefixos IPv4 com indicadores de RIB e FIB, estado dos módulos ópticos do equipamento roteador BGP monitorado, a estatísticas de consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio1.jpg|centro|miniaturadaimagem|1280x1280px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também idealizado pela Flowbix, outra consolidação de dados importantes numa única tela, incluindo latência, índice de perda de pacotes, disponibilidade, uso de recursos tais como CPU, memória e espaço em disco, estado geral das sessões BGP monitoradas, e consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio2.jpg|centro|miniaturadaimagem|967x967px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também elaborado pela Flowbix, temos estatísticas mais centradas no estado das sessões BGP, e em combinação com uma visão geral dos índices de latência registrados.<br /> [[Arquivo:Bpf-gerbgp-caio3.jpg|centro|miniaturadaimagem|900x900px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Na verdade, as possibilidades de construção de painéis para objetos gerenciados por SNMP usando uma combinação de NMS (como Zabbix) e Grafana, junto com outros procedimentos, são bastante extensas. Muitas soluções podem ser implementadas, desde que se tenha o conhecimento técnico necessário para criar essas integrações. Caso contrário, por que não considerar investir em serviços de integração para seu negócio?<br /> <br /> === Monitoramento por meios do BGP Monitoring Protocol (BMP) ===<br /> Muitos profissionais da área, incluindo engenheiros das principais empresas de Internet do mundo, fabricantes e pesquisadores, concluíram que precisavam ter acesso ao conteúdo das rotas mantidas nas tabelas BGP de roteadores, bem como uma visão das mensagens Update usadas na troca de rotas entre sessões BGP. O grande desafio era que os modelos tradicionais de gerenciamento (como SNMP) tornavam praticamente impossível obter essas informações. Foi então que surgiu o '''''BGP Monitoring Protocol''''', especificado originalmente no &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; (''BGP Monitoring Protocol (BMP)'') e complementado pelo &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)'').<br /> <br /> O BMP oferece acesso contínuo ao ''Adj-RIB-In'' de uma sessão BGP, além de fornecer despejos periódicos de dados estatísticos para uma estação coletora. Com software específico, os engenheiros do Sistema Autônomo podem analisar o funcionamento e comportamento do BGP.<br /> <br /> Antes de explorar os benefícios do monitoramento do BGP com o protocolo BMP, é importante conhecer alguns componentes e conceitos fundamentais:<br /> * '''''Adj-RIB-In''''': conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt; (''A Border Gateway Protocol 4 (BGP-4)''), o ''Adj-RIBs-In'' contém as informações de roteamento não processadas anunciadas pelo roteador BGP para seus vizinhos. Também conhecido como &quot;''pre-policy Adj-RIBs-In''&quot;, na perspectiva do BMP, representa todas as rotas recebidas pelo coletor antes do processamento por uma policy inbound.<br /> * '''''Post-Policy Adj-RIBs-In''''': representa o resultado da aplicação da política de roteamento inbound (ou &quot;import&quot;, como é conhecido em algumas plataformas), antes do processo de seleção de caminhos (best-path) do BGP para a composição da tabela de roteamento local. Na perspectiva do BMP, representa as informações recebidas pelo coletor após a aplicação de policies inbound ou modificações de atributos.<br /> Ou seja, a diferença entre ''pre-policy Adj-RIB-In'' e ''post-policy Adj-RIB-In'' é que, no primeiro caso, as rotas recebidas são exportadas para o coletor BMP sem a aplicação de filtros. No post-policy, as informações são encaminhadas após o roteador ter aplicado filtros e modificado potenciais atributos através de policies inbound, mas antes do processo de seleção de ''best path'' para compor a RIB local dessas rotas BGP. O monitoramento de updates pré-policies inbound tem sido a aplicação mais comum do BMP, enquanto o post-policy concentra-se na auditoria e validação das políticas de roteamento implementadas.<br /> <br /> Contudo, monitorar apenas o ''Adj-RIB-In'' limita os dados disponíveis aos coletores BMP. Como poucos Sistemas Autônomos implementam BMP, e os que implementam raramente compartilham essas informações (mesmo em modo somente leitura), as empresas perdem visibilidade sobre o que foi efetivamente anunciado e aceito pelos peers vizinhos. Embora seja possível consultar estas informações via Looking Glass (não baseado em BMP) para verificar anúncios nas tabelas BGP do AS vizinho, esta solução não oferece dados históricos nem as funcionalidades disponíveis no BMP. Para resolver esta limitação, surge o &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)''), que introduz novas funcionalidades:<br /> * '''''Adj-RIB-Out:''''' conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt;, o ''Adj-RIB-Out'' contém as rotas designadas para anúncios para os peers BGP por intermédio das mensagens UPDATE.<br /> * '''''Pre-policy Adj-RIB-Out''''': é o resultado de representação dos prefixos que serão anunciados pelas mensagens UPDATE antes da aplicação de policies outbound (ou &quot;export&quot;). Geralmente é a mesma coisa que encontra-se no momento na RIB local do roteador.<br /> * '''''Post-policy Adj-RIB-Out:''''' é o resultado do envio de prefixos através de anúncios (UPDATE) após o processamento das informações pelas policies outbound. É a representação do que de fato está sendo anunciado para um peer BGP específico.<br /> O ''BGP Monitoring Protocol'' (BMP) opera sobre uma sessão TCP entre o roteador monitorado e a estação coletora BMP. A configuração da sessão é flexível, permitindo conexão passiva (iniciada apenas pelo roteador) e mecanismos de backoff para tentativas de conexão com intervalos configuráveis, além de outros parâmetros para controle de fluxo entre o roteador e a estação coletora. Embora nenhuma mensagem BMP seja enviada da estação coletora para o roteador, o administrador pode configurar uma policy inbound para recusar possíveis anúncios da estação coletora. O &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; especifica as seguintes mensagens:<br /> * '''''Type 0: Route Monitoring (RM)''''': fornece um dump inicial de todas as rotas recebidas de um peer e atua como mecanismo contínuo para relatar incrementalmente as rotas anunciadas e revogadas (''withdrawn'') para a estação coletora BMP. A mensagem consiste de ''Common Header'' + ''Per-Peer Header'' + mensagem BGP ''UPDATE'' na íntegra.<br /> * '''''Type 1: Statistics Report (SR)''''': oferece estatísticas periódicas das atividades BGP do roteador. A mensagem consiste de ''Common Header'' + ''Per-Peer Header'' + campo de 4 bytes indicando a quantidade de contadores, cada um codificado como TLV. As estatísticas são informadas como ''Counters'' (32-bit) ou ''Gauges'' (64-bit).<br /> * '''''Type 2: Peer Down Notification''''': indica quando uma sessão BGP foi desconectada e seu motivo. A mensagem menciona um dos 5 motivos indicativos (''Reason'' 1 a ''Reason'' 5) do encerramento da sessão.<br /> * '''''Type 3: Peer Up Notification''''': informa quando uma sessão BGP fica Up ou &quot;Established&quot;. Inclui dados sobre a negociação entre os roteadores (conteúdo da mensagem OPEN) e informações da sessão BGP. A mensagem consiste de ''Common Header'' + ''Per-Peer Header'' + mensagem (BGP) ''OPEN'' enviada + mensagem ''OPEN'' recebida + informações do peer (opcional).<br /> * '''''Type 4: Initiation Message''''': identifica o roteador BGP para o coletor BMP, incluindo fabricante/modelo e versão de software, servindo como controle de inventário. Consiste de ''Common Header'' + 2 ou mais ''Information TLVs'', sendo ''sysDescr'' e ''sysName'' obrigatórios e os demais opcionais.<br /> * '''''Type 5: Termination Message''''': informa a interrupção da sessão BMP entre roteador e coletor. Consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' descrevendo um dos 5 motivos (''Reason'' 0 a Reason 4) da ''terminação''.<br /> * '''''Type 6: Route Mirroring Message''''': permite ao roteador monitorado enviar duplicatas exatas das mensagens recebidas, podendo espelhar uma sessão BGP ou relatar PDUs malformados. Consiste de ''Common Header'' + ''Per-Peer Header'' + conjuntos de TLVs descritivos, com 2 bytes para o código do tipo (ex: Type 0 = ''BGP Message'', Type 1 = ''Information'', Type 1 Code 0 = ''Errored PDU'' e Type 1 Code 1 = ''Messages Lost''), 2 bytes para comprimento e um campo de valor variável.<br /> Por sua vez, o &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; implementa modificações nas estruturas dessas mensagens para acomodar as situações Adj-RIB-In e Adj-RIB-Out. Isso inclui o flag O definido como &quot;0&quot; em mensagens BMP com cabeçalho per-peer, além dos flags específicos para identificar Adj-RIB-In ou Adj-RIB-Out nas mensagens Route Monitoring e Route Mirroring.<br /> [[Arquivo:Bpf-gerbgp-bmpheaders.jpg|centro|miniaturadaimagem|900x900px|Cabeçalhos do BMP conforme &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt;]]Acredito que você já esteja entendendo melhor as funcionalidades básicas proporcionadas pelo ''BGP Monitoring Protocol'' (BMP)! Que tal apresentarmos um caso prático envolvendo o monitoramento do BGP por esta tecnologia?<br /> <br /> ==== Caso de uso: monitoramento por BGP Monitoring Protocol (BMP) com o Streaming Network Analytics System (SNAS) ====<br /> O caso a seguir apresenta uma das diversas possibilidades de monitoramento BGP em um Sistema Autônomo usando BMP. Para evitar uma explicação excessivamente longa, elaborei um simples &quot;canvas&quot; que representa um conceito de solução baseada no Streaming Network Analytics System (SNAS). O modelo canvas tem uma estrutura modificada para refletir as características gerais da solução proposta de forma clara e concisa. Em uma única página, apresento a relação de Problemas/Necessidades, Solução, Argumentos de Adoção, Vantagens, Desvantagens, Resultados, Características de Extensibilidade e Integração e um Bloco Representativo da Solução. Esta organização do canvas foi pensada para explicar a solução da forma mais eficiente possível.<br /> [[Arquivo:Bpf-gerbgp-openbmp.jpg|centro|miniaturadaimagem|900x900px|Canvas model do conceito de solução factível com base numa derivação do SNAS para o gerenciamento com o BGP Monitoring Protocol ]]<br /> A solução é composta pelos seguintes componentes, cada um com uma função específica, todos empacotados para implementação em containers com Docker: <br /> * '''openBMP:''' atua como coletor de BMP. Uma sessão BMP é estabelecida entre este coletor e cada roteador onde desejamos monitorar ou coletar os dados referentes ao BGP.<br /> * '''Apache Kafka:''' plataforma de processamento de streaming de alta capacidade e baixa latência para tratamento de dados em tempo real. O Kafka permite conectar múltiplos ''publishers'' e ''subscribers'' para disseminação rápida de dados, oferecendo excelente integração e compartilhamento com outros sistemas. A instalação inclui o '''''Zookeeper''''', software da Apache que atua como serviço centralizado para manter dados de nomenclatura e configuração, fornecendo sincronização flexível e robusta nos sistemas distribuídos. O ''Zookeeper'' gerencia o status dos nós do cluster Kafka e rastreia tópicos e partições.<br /> * '''PostgreSQL:''' O projeto SNAS originalmente usava MySQL/MariaDB, mas os desenvolvedores optaram por um banco de dados mais eficiente devido às limitações do MariaDB, como gerenciamento manual de partições temporais, recuperação de espaço em disco, requisitos de memória do InnoDB e suporte limitado a JSON. O PostgreSQL resolve estas questões e adiciona funcionalidades relevantes. O container inclui: '''''TimescaleDB''''' (extensão para tornar SQL escalável com dados temporais), '''''RPKI Validator''''' (para verificação de status ROA dos prefixos), e consultas IRR via '''''Whois'''''.<br /> * '''Grafana:''' o SNAS original tem seu próprio front-end WebUI, compatível apenas com MySQL/MariaDB. Para usar a WebUI original com PostgreSQL ou Grafana com MariaDB, são necessárias adaptações no código. Existem 12 dashboards predefinidos para esta solução openBMP/SNAS, mas você pode criar dashboards personalizados conforme suas necessidades.<br /> * '''Docker:''' embora a implementação do SNAS não dependa exclusivamente do Docker, a containerização oferece benefícios na separação das aplicações. Para testes iniciais, você pode clonar uma instalação pronta e executá-la em minutos. Posteriormente, pode decidir sobre sua implementação definitiva em produção, seja com Docker ou não.<br /> [[Arquivo:Bpf-gerbgp-snasdocker.jpg|centro|miniaturadaimagem|900x900px|Cenário: SNAS em containers Docker]]<br /> Embora tenhamos uma solução &quot;pronta&quot; com os componentes mencionados, é possível criar diferentes tipos de integrações com sistemas internos ou soluções comerciais. Estes sistemas podem consumir dados do BMP de duas formas: via streaming nativo BMP ou através de acesso direto às informações armazenadas no banco de dados. Além disso, há o potencial de distribuição de dados em tempo real através do Kafka. Os desenvolvedores do SNAS apresentam este e outros cenários de integração em sua documentação. Destaco um destes cenários a seguir:<br /> [[Arquivo:Bpf-gerbgp-snas.jpg|centro|miniaturadaimagem|900x900px|Exemplo de cenário de integração do SNAS]]A solução a seguir é baseada exclusivamente no SNAS e oferece duas opções de banco de dados: a instalação padrão com MariaDB e frontend WebUI do SNAS, ou a instalação com PostgreSQL integrado ao Grafana, incluindo dashboards personalizados para nossas necessidades de monitoramento. Para ilustrar melhor como funciona esta integração entre os bancos de dados e as interfaces WebUI e Grafana, observe a figura abaixo:<br /> [[Arquivo:Bpf-gerbgp-snasio.jpg|centro|miniaturadaimagem|900x900px|Coletor, DB e Frontend do SNAS.io (Fonte: snas.io)]]'''Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos'''<br /> <br /> Um caso real aqui obtido com um ISP que realiza o monitoramento por BMP com painéis Grafana. Existem duas perspectivas distintas: como seu Sistema Autônomo (você) enxerga o mundo e como as demais empresas na Internet enxergam seu AS. Uma funcionalidade interessante em um dos 12 dashboards &quot;prontos&quot; do SNAS é a visualização de qualquer ASN pela perspectiva das suas tabelas BGP. O coletor BMP (''openbmp'') recebe as mensagens dos roteadores monitorados, reorganiza os dados e os repassa para o Kafka, que os comunica à base SQL. O dashboard do Grafana consulta essas tabelas e apresenta como um determinado ASN é visto a partir do ASN da sua empresa. São exibidas informações relevantes como relações de upstreams e downstreams do ASN pesquisado, junto com a resolução das bases IRR, incluindo os objetos route/route6 identificados.<br /> <br /> Esta ferramenta é valiosa não só para você, administrador do AS, mas também para outros ASs estudarem como são vistos a partir da sua rede. É uma iniciativa colaborativa que facilita o diagnóstico de problemas de roteamento entre os ASs.[[Arquivo:Bpg-gerbgp-bmpasvniew.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para funcionalidade Looking Glass'''<br /> <br /> Looking Glass não é novidade alguma, muito pelo contrário. É surpreendente, porém, a quantidade de ASNs que não disponibilizam esta ferramenta como &quot;esforço de cooperação&quot;, permitindo que outros profissionais e empresas possam consultá-la para diagnosticar e resolver problemas de roteamento relacionados aos anúncios BGP. Inacreditável!<br /> <br /> Embora Looking Glasses sejam úteis e conhecidos, existe uma limitação importante: ao consultar um Looking Glass sobre determinado prefixo/rota, a resposta reflete apenas o estado atual no momento da consulta. Perde-se a visibilidade histórica sobre o prefixo consultado: &quot;''quantas vezes houve alterações nas propriedades desta rota?''&quot;, &quot;''esta rota estava presente neste LG ontem à noite, quando meus usuários reclamaram de problemas de acesso?''&quot;, &quot;''qual é a frequência de oscilações das minhas rotas neste ASN por um determinado upstream?''&quot;. É precisamente nesses casos que este dashboard com funcionalidade estilo Looking Glass se torna extremamente útil.<br /> <br /> Este dashboard, também produzido com o Grafana, permite pesquisar um prefixo e visualizar, através de uma linha temporal, todo o histórico de mudanças associadas ao seu anúncio, respondendo a muitos desses questionamentos. Atualmente, não é possível pesquisar outras propriedades da rota, como atributos específicos, principalmente o AS_PATH. No entanto, isso é tecnicamente viável - basta estudar a estrutura de dados na base SQL, ajustar as ''queries'' e desenvolver seu próprio dashboard para consultas por expressão regular e afins![[Arquivo:Bpg-gerbgp-bmplg.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]<br /> [[Arquivo:Bpg-gerbgp-bmplg2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos'''<br /> <br /> Outro dashboard montado com o Grafana oferece uma utilidade excepcional: a capacidade de consultar o histórico de anúncios originados a partir de um determinado ASN. Na verdade, são três dashboards distintos que oferecem visibilidade sobre prefixos, ordenados &quot;''por prefixo''&quot;, &quot;''por peer''&quot; e &quot;''por ASN''&quot;.<br /> <br /> Este tipo de consulta é muito útil para compreender a frequência de alterações nas rotas originadas em um ASN, especialmente quando usuários relatam problemas de acesso a conteúdos vinculados a estas redes. Também ajuda a identificar quais upstreams diretos são mais &quot;estáveis&quot;, pois alterações frequentes e recorrentes destes anúncios por um determinado peer podem indicar que um upstream está enfrentando dificuldades ou realizando ajustes nas políticas de roteamento, causando oscilações e instabilidades na convergência do BGP.<br /> <br /> As pesquisas podem ser realizadas em qualquer um destes três dashboards, conforme a necessidade:<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas especificamente a um prefixo qualquer:''''' utilize o dashboard &quot;''Prefix History (by Prefix)''&quot; para visualizar todas as mudanças associadas ao prefixo, incluindo data/hora, tipo de evento (''advertised'', ''withdrawn''), roteador monitorado, peer externo, prefixo/rota consultado, ASN de origem, lista de AS-Path e communities associadas ao período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a quaisquer prefixos originados especificamente em um ASN qualquer:''''' utilize o dashboard &quot;''Prefix History (by ASN)''&quot; para verificar data/hora, tipo de evento (''advertised'', ''withdrawn''), roteador monitorado, peer externo, prefixos/rotas identificados, ASN de origem consultado, lista de AS-Path e communities associadas ao período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a eventos referentes a quaisquer prefixos e de quaisquer ASNs, coletados a partir de um roteador monitorado combinado com cada peer:''''' utilize o dashboard &quot;''Prefix History (by Peer)''&quot; para filtrar eventos conforme coletados pelos roteadores monitorados pelo coletor BMP, incluindo data/hora, tipo de evento (''advertised'', ''withdrawn''), roteador monitorado, peer externo, prefixo, lista de AS-Path e communities associadas ao período.<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por ASN]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por Peer]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis3.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por prefixo]]'''Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos'''<br /> <br /> Um dashboard mais visual e estético, mas igualmente importante. Este painel permite identificar, através de gráficos, possíveis anomalias nas sessões BGP e suas atividades relacionadas a anúncios. Você poderá monitorar o volume e a frequência de eventos advertised e withdrawn, visualizar anúncios (advertised) por roteador, retiradas (withdrawn) por roteador, além de Updates e Withdraws por peer.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmptop.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de de incidentes de segurança como BGP'''<br /> <br /> Conforme comentado anteriormente, o container que oferece o componente '''''openbmp_psql''''' (PostgreSQL) não contém apenas o PostgreSQL — há também o ''TimescaleDB'' e um '''''validador de RPKI'''''. Conforme os dados coletados pelo ''openbmp'' são armazenados na base via interface com o ''Kafka'', rotinas em segundo plano identificam os registros ROA ''Valid'', ''Unknown'' ou ''Invalid'' para cada prefixo mantido nas tabelas da solução. Este dashboard apresenta um &quot;mapa&quot; dos prefixos de um ASN que possuem erros de validação RPKI. Adicionalmente, rotinas secundárias realizam consultas às bases de ''Internet Routing Registry'' (IRR) referentes a estes mesmos prefixos.<br /> <br /> Consequentemente, através deste dashboard no Grafana, você consegue identificar potenciais incidentes de sequestro de prefixos (''hijacks'') e vazamento de rotas (''route leaks'') associados a um ASN específico. Esta visualização é valiosa para detectar problemas nos anúncios de prefixos que podem ser recusados tanto pelas políticas de roteamento do seu ASN quanto pelos upstreams. Isso é especialmente relevante já que as empresas têm adotado crescente automação na implementação de filtros para anúncios de seu cone de clientes — filtros que consideram tanto a validação RPKI (descarte de ROA inválido) quanto a validação por IRR.<br /> <br /> Apesar de não ser infalível, este dashboard é particularmente útil para monitorar a segurança geral do roteamento BGP quanto à validação por RPKI e IRR, com ênfase na detecção de ''hijacks'' e ''route leaks''.[[Arquivo:Bpg-gerbgp-bmpbgpsec.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de Hijacks e Route Leaks]]<br /> [[Arquivo:Bpf-gerbgp-incidents.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento incidentes de segurança do BGP (Fonte: snas.io)]]<br /> <br /> '''Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR'''<br /> <br /> Este painel utiliza os componentes mencionados no painel anterior (validador RPKI e consultas ao IRR) para mostrar de forma simplificada a quantidade de prefixos na base que apresentam problemas de validação RPKI ou IRR.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR]]'''Caso de uso: monitoramento de sessão BGP por BMP com a WebUI nativa do SNAS.io''' <br /> <br /> O monitoramento via BMP permite extrair informações essenciais para as operações diárias do ISP, como verificar o estado das sessões BGP e seus detalhes relacionados — similar ao resultado obtido ao executar o comando &quot;show bgp neighbor&quot; em um roteador.<br /> <br /> [[Arquivo:Bpf-gerbgp-snaspeer info.png|centro|miniaturadaimagem|800x800px|Caso de uso: Peer Info com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: painel Top 20 de prefixos anunciados e removidos com a WebUI nativa do SNAS.io''' <br /> <br /> Com funcionalidade similar ao que foi mostrado no painel AS View com o Grafana, a interface WebUI original do SNAS.io provê uma visibilidade geral do AS numa relação &quot;Top 20&quot;.<br /> [[Arquivo:Bpf-gerbgp-snastop20.png|centro|miniaturadaimagem|800x800px|Caso de uso: Top 20 prefixos anunciados e removidos com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: análise de segurança com a WebUI nativa do SNAS.io''' <br /> <br /> Com visibilidade similar ao que foi demonstrado em alguns painéis anteriores, esta facilidade permite uma rápida visualização acerca da quantidade de ASNs com problemas de validação do RPKI.<br /> [[Arquivo:Bpf-gerbgp-snastsecurity report.png|centro|miniaturadaimagem|800x800px|Caso de uso: análise de segurança com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snasrpki drill down.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatório de violação de RPKI com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: integração e visibilidade com BGP Link-State (BGP-LS)'''<br /> <br /> Para atender aplicações que necessitam de visibilidade topológica em áreas IGP ou sistemas autônomos, foi definida uma AFI/SAFI específica para o BGP. Esta extensão permite que o protocolo transporte informações detalhadas sobre estados de links, codificando a topologia da rede nos NLRI e suas propriedades nos atributos do BGP-LS. A ferramenta SNAS.io apresenta estes detalhes topológicos transportados pelo BGP, auxiliando engenheiros de rede na otimização do fornecimento de diferentes perfis de conteúdo.<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate map traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate SPF and traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: relatórios por Sistema Autônomo com a WebUI nativa do SNAS.io'''<br /> <br /> Como o próprio nome sugere, por esta interface podemos informar um número de AS e obter informações detalhadas, incluindo os registros correspondentes das bases IRR, os prefixos originados pelo ASN pesquisado e, conforme o entendimento do BGP, a relação de upstreams e downstreams desse ASN.<br /> [[Arquivo:As view.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatórios por AS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> <br /> ==== Caso de uso: monitoramento, analíticos e big data com o Streaming Network Analytics System (SNAS/openBMP) em combinação com o Platform for Network Data Analytics (PNDA) ====<br /> A combinação do PNDA com o SNAS funciona como uma espécie de &quot;''unha e carne''&quot;, pois agrega facilidades que evidenciam os padrões de visibilidade e transparência do comportamento geral do BGP, especialmente as métricas essenciais para a tomada de decisões estratégicas no dia a dia. O combo &quot;PNDA + SNAS&quot; abre as portas do '''''big data''''' para as necessidades de BGP e do roteamento do AS!<br /> <br /> Nesta solução, o SNAS captura os eventos BGP dos roteadores usando o ''BGP Monitoring Protocol'' (BMP), conforme demonstrado anteriormente. Em seguida, encaminha os eventos coletados via ''Logstash'' para o cluster PNDA através de sua interface com o Kafka — explicando assim uma das razões para termos incluído o Kafka neste contexto. O HDFS do PNDA oferece capacidade para registrar e manter grandes volumes de dados históricos de eventos, tornando a solução altamente escalável. Uma aplicação baseada no Spark executa consultas sobre esses dados, extraindo as informações necessárias. Os resultados são armazenados no componente HBase do PNDA e disponibilizados através de uma API REST, permitindo que usuários e administradores visualizem os dados através de uma interface Web intuitiva.<br /> <br /> Para os propósitos aqui discutidos, o PNDA executa os seguintes procedimentos com suas tecnologias integradas:<br /> * Entrada de dados por uma infinidade de opções, incluindo '''''Logstash''''', '''''Open Daylight''''', '''''Bulk Ingest''''' tool, '''''SNAS.io''''', '''''SNMP''''', '''''pmacct''''', '''''Cisco IOS XR Telemetry''''', etc.<br /> * Distribuição de dados por '''''Apache Kafka''''' e '''''Zookeeper'''''.<br /> * Processamento de stream em alta velocidade com '''''Spark Streaming'''''.<br /> * Processamento em lote de alto volume com '''''Spark'''''.<br /> * Exploração de dados de forma livre com o '''''Jupyter'''''.<br /> * Consulta estruturada sobre big data com '''''Impala'''''.<br /> * Manipulação de séries temporais com '''''OpenTSDB''''' e '''''Grafana'''''.<br /> O PNDA é bastante sofisticado em relação às tecnologias disponibilizadas. Uma instalação padrão inclui os seguintes componentes:<br /> * '''''SaltStack:''''' software de código aberto baseado em Python para automação de TI orientada a eventos, execução remota de tarefas e gerenciamento de configurações.<br /> * '''''OpenStack Heat templates:''''' implementa um mecanismo de orquestração para ativar aplicativos de nuvem compostos, usando modelos em arquivos de texto que podem ser tratados como código.<br /> * '''''AWS CFN templates:''''' oferece uma linguagem comum para modelar e provisionar recursos de aplicativos da AWS e de terceiros em ambiente de nuvem.<br /> * '''''Apache Kafka:''''' atua como porta de entrada para os fluxos de dados originados pelos equipamentos da rede.<br /> * '''''Bulk Ingest:''''' alternativa ao Kafka para cenários de migração de dados existentes para o PNDA.<br /> * '''''Zookeeper for Kafka:''''' utilizado pelo Kafka para descoberta e busca de partições junto aos brokers.<br /> * '''''JMX Proxy:''''' expõe atributos MBean disponíveis em uma JVM através de solicitações HTTP simples.<br /> * '''''Apache Impala:''''' mecanismo de execução paralela para consultas SQL com acesso de baixa latência e exploração interativa de dados no HDFS e HBase. Permite armazenamento em formato bruto, realizando agregação no momento da consulta.<br /> * '''''CMAK (aka &quot;Kafka Manager&quot;):''''' ferramenta de gerenciamento de clusters Kafka.<br /> * '''''ELK''''' (Logserver)<br /> ** '''''Elasticsearch:''''' componente da arquitetura de logs do PNDA.<br /> ** '''''Logstash:''''' componente para recebimento, transformação e compartilhamento de dados de múltiplas fontes.<br /> ** '''''Kibana:''''' plugin de visualização de dados do Elasticsearch.<br /> * '''''Jupyter Hub''''' e '''''Jupyter Notebook:''''' aplicação para criar e compartilhar documentos com código ativo, equações, visualizações e texto explicativo. Suporta exploração e apresentação de dados do HDFS e HBase.<br /> * '''''OpenTSDB:''''' banco de dados escalável de séries temporais para armazenamento e fornecimento de grandes volumes de dados, mantendo a granularidade.<br /> * '''''Grafana:''''' construtor de gráficos e painéis para visualização de métricas temporais do PNDA.<br /> * '''''Anaconda:''''' distribuição gratuita e de código aberto das linguagens Python e R para computação científica.<br /> * '''''Consul.io:''''' gerenciamento de endpoints e descoberta de serviços.<br /> * '''''Apache Flink:''''' framework e mecanismo de processamento distribuído para cálculos com estado em fluxos de dados limitados e ilimitados. Projetado para execução em clusters, com processamento em memória e alta escalabilidade.<br /> * '''''Apache Knox:''''' gateway de aplicativo para interação com APIs REST e UIs do Apache Hadoop, fornecendo ponto único de acesso para interações REST e HTTP com os clusters.<br /> O PNDA é uma plataforma escalável e aberta de big data que suporta análises operacionais e inteligência de negócios para redes e serviços, não se limitando apenas a ambientes ISP. As tecnologias utilizadas variam conforme a distribuição Hadoop escolhida, podendo o PNDA ser implantado com Cloudera CDH ou Hortonworks HDP. Cada distribuição requer seus próprios componentes adicionais. Por exemplo, uma instalação baseada em Cloudera CDH PNDA exige Apache Avro, Crunch, DataFu, Hadoop, HBase, Hive, Hue, Impala, Kite SDK, Mahout, Parquet, Pig, Spark, Sqoop/Sqoop2, ZooKeeper, entre outros. A ilustração a seguir demonstra as diversas possibilidades de recebimento de eventos e streaming com o PNDA. Note que o SNAS.io é mencionado como uma das formas de recebimento de dados:<br /> [[Arquivo:Bpf-gerbgp-pnda.jpg|centro|miniaturadaimagem|900x900px|Visão geral do PNDA (Fonte: PNDA.io)]]<br /> <br /> A integração do OpenBMP ou SNAS com o PNDA será feita através do Logstash. Os roteadores monitorados enviam mensagens BMP para o OpenBMP/SNAS, que então encaminha estes dados para o Kafka. O barramento de dados do Kafka permite que diversos aplicativos, seja em lote ou streaming, acessem feeds BMP provenientes dos roteadores. Assim, a proposta é gerar os dados BMP no coletor OpenBMP/SNAS e direcioná-los ao Kafka, onde serão consumidos pelo Logstash da instalação PNDA. Esta integração está comentada neste link&lt;nowiki/&gt;https://github.com/SNAS/openbmp/blob/master/docs/LOGSTASH.md.<br /> <br /> A interação dos administradores da rede com estes dados poderá ser feita por APIs ou por qualquer outra aplicação que seja pensada para consumir estes dados.<br /> <br /> '''Caso de uso: monitoramento, analíticos e big data com SNAS.io e PNDA.io'''<br /> <br /> Se você ainda está se questionando sobre as vantagens e benefícios de incorporar conceitos de telemetria para o monitoramento do seu BGP, esta seção do artigo pode convencê-lo. Um dos maiores atrativos da telemetria orientada a modelos (eventos + streaming periódico) é permitir a obtenção de dados em tempo real, com flexibilidade e granularidade muito superiores aos modelos de gerenciamento tradicionais já discutidos. Ao combinar este modelo de gerenciamento com as soluções certas baseadas em software, você passa a ter acesso a praticamente tudo aquilo que era inconcebível com os modelos tradicionais.<br /> <br /> Nunca foi tão viável entrar no mundo de analytics e big data com foco em redes, especialmente para BGP. A combinação de SNAS.io e PNDA.io pode destravar a inteligência que falta na maioria dos Sistemas Autônomos de ISPs de pequeno e médio porte. Big data não é mais exclusividade de grandes operadoras!<br /> <br /> Entre as diversas possibilidades com big data aplicado ao BGP, destaca-se a capacidade de classificar e filtrar todo o histórico de anúncios originados e propagados por AS. Isso permite entender melhor como as alterações feitas por upstreams afetam a convergência do roteamento BGP do seu AS. Isto é mostrado na ilustração a seguir:[[Arquivo:Bpf-gerbgp-pnda1.png|centro|miniaturadaimagem|900x900px|Análise de prefixos originados e anunciados por AS (Fonte: pnda.io)]]Outra possibilidade é consultar informações detalhadas sobre qualquer AS mencionado nos anúncios registrados na base de dados da solução. Isso, por si só, economiza um tempo considerável, eliminando a necessidade de recorrer a sistemas ou websites externos. Além disso, essas informações sobre os AS podem ser processadas para gerar uma infinidade de análises e relatórios adicionais. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda2.png|centro|miniaturadaimagem|900x900px|Informações detalhadas por AS (Fonte: pnda.io)]]Uma das necessidades mais críticas em projetos avançados de engenharia de tráfego com BGP é ter visibilidade detalhada das relações entre Sistemas Autônomos (AS) na perspectiva do AS da sua empresa. Essa visibilidade permite estudar adequadamente a cadeia de relações e conduzir análises de matrizes de tráfego, entre outros aspectos importantes.<br /> <br /> A obtenção dessas informações por métodos tradicionais é praticamente inviável. SNMP não oferece essa capacidade. Usar CLI/Scripting para recuperação, ''parsing'' e armazenamento dessas informações em banco de dados seria uma solução frágil, pouco escalável e computacionalmente intensiva — ou seja, impraticável.<br /> <br /> No entanto, o monitoramento do BGP via telemetria, junto com soluções de software especializadas para processamento desses dados, possibilita uma análise completa de como o AS da sua empresa se relaciona com os demais AS da Internet. Com funções inteligentes de pesquisa de baixa complexidade, você consegue mapear claramente essas relações. A ilustração a seguir mostra isso:[[Arquivo:Bpf-gerbgp-pnda3.png|centro|miniaturadaimagem|900x900px|Análise de relações entre os AS associados aos anúncios mantidos na base de dados (Fonte: pnda.io)]]Outra aplicação muito útil: imagine que você precise estudar os caminhos de AS_PATH associados a determinados destinos, por exemplo, entre dois ASs quaisquer. Como você faria isto pelos métodos tradicionais? Você precisaria acessar diversos roteadores e analisar manualmente, um por um, todos os anúncios em combinação com cada opção de caminho entre a origem e o destino desejados. Se você conhece bem o BGP e trabalha em uma operadora ou ISP de maior porte, certamente já realizou este tipo de trabalho diversas vezes. É algo que exige muito tempo, foco e atenção! Agora, com uma plataforma de analytics &amp; big data para dados BGP, você pode facilmente estudar todos os caminhos entre origem e destino pretendidos. Com apenas alguns cliques, é possível identificar os caminhos ativos e determinar quais têm o menor e maior comprimento de AS_PATH. E tudo isso em questão de segundos! Isto é demonstrado na ilustração a seguir:[[Arquivo:Bpf-gerbgp-pnda4.png|centro|miniaturadaimagem|900x900px|Análise caminhos &quot;ativo, mais curto, mais longo&quot; entre dois AS (Fonte: pnda.io)]]A segurança do BGP apresenta diversos desafios, especialmente quanto a anomalias em prefixos e no atributo AS_PATH. Felizmente, como todas as informações do BGP são mantidas em bases de dados otimizadas para análises, é possível identificar problemas de segurança com relativa facilidade. A ilustração abaixo exemplifica isso:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda5.png|centro|miniaturadaimagem|900x900px|Análise de anomalias associadas a prefixos e AS_PATH (Fonte: pnda.io)]]Mais uma funcionalidade interessante aqui: a possibilidade de estudar cada ASN identificado na base de dados da solução. É possível consultar informações detalhadas de cada ASN, visualizar o histórico dos anúncios enviados e recebidos, analisar a lista de AS_PATH associada aos anúncios e investigar possíveis problemas no roteamento BGP do seu AS, entre outras funcionalidades.<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda6.png|centro|miniaturadaimagem|900x900px|Análise de caminhos por AS (Fonte: pnda.io)]]<br /> <br /> Por ser uma solução baseada principalmente em software de código aberto, o potencial de customização é extraordinário. Com times de desenvolvimento experientes, sua empresa pode personalizar a solução conforme necessário, incorporando diversos elementos e refinando até alcançar os resultados desejados pelas áreas internas do negócio que se beneficiam das funções, relatórios e análises do monitoramento BGP.<br /> <br /> Para concluir o tema SNAS.io + PNDA.io, se você quiser experimentar uma versão minimalista (com algumas limitações e não recomendada para ambientes de produção), recomendo o Red PNDA! Você pode baixar a OVA e executá-la como máquina virtual em uma sandbox para explorar e aprender a desenvolver em um ambiente PNDA propício.<br /> <br /> === Conclusão do artigo e próximos passos ===<br /> O tema gerenciamento é extremamente extenso, mesmo tendo focado apenas no gerenciamento e monitoramento do BGP. Não há como abordar completamente o tema em um único artigo. No entanto, já estão planejados para a wiki do BPF os seguintes conteúdos relacionados ao gerenciamento e monitoramento do BGP:<br /> * Aplicabilidades do ''Multi-Threaded Routing Toolkit'' (MRT) - &lt;nowiki&gt;RFC 6396&lt;/nowiki&gt; e &lt;nowiki&gt;RFC 8050&lt;/nowiki&gt;<br /> * Gerenciamento e monitoramento por telemetria com exemplos de soluções (ex: Cisco IOS XR Telemetry, Pipeline, e outros)<br /> * Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> * Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> * Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> * Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manager (EPN-M)<br /> Siga acompanhando os trabalhos do Brasil Peering Forum! Espero que você tenha curtido este artigo; divulgue-o!<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> [[Categoria:Roteamento]]<br /> [[Categoria:Infraestrutura]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=3787 2024-09-04T13:05:16Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Sou arquiteto de soluções, engenheiro de redes, instrutor e palestrante, com 29 anos de experiência em projetos complexos realizados em diversos mercados verticais, incluindo telecomunicações, data centers, financeiro, óleo e gás, indústrias, transportes e varejo. Ao longo da minha carreira, tenho me dedicado a entregar soluções inovadoras e de alto impacto, sempre buscando a excelência em cada projeto.<br /> <br /> Tenho uma sólida experiência em diferentes áreas tecnológicas, como routing &amp; switching, segurança, colaboração, wireless e soluções industriais. No entanto, meus maiores interesses e especialização estão focados nos segmentos de service providers e data centers, onde construí grande parte do meu conhecimento.<br /> <br /> Já tive a oportunidade de trabalhar em grandes empresas como Amazon Web Services, Cisco, New York Stock Exchange (NYSE/Euronext), instituições financeiras, além de operadoras de telecomunicações e parceiros integradores da Cisco e Juniper. Atualmente, atuo como Engenheiro de Redes Sênior na Irlanda, onde continuo a aplicar minha experiência em redes e telecomunicações.<br /> <br /> Possuo ainda incontáveis horas como instrutor, professor, e palestrante em eventos e treinamentos, onde compartilho meu conhecimento e experiência com a comunidade de TI. <br /> <br /> Por alguns anos, desempenhei o papel de presidente do Comitê de Programa do Brasil Peering Forum (BPF), além de ter coordenado diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Plataforma de cursos EAD:''' https://ead.leonardofurtado.academy<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=3786 2024-08-26T14:24:49Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Leonardo Furtado é Engenheiro de Redes, Arquiteto de Soluções, Instrutor, e especialista em desenvolvimento de negócios. Possui formação em Ciência da Computação e 28 anos de experiência em diversas indústrias e mercados verticais. <br /> <br /> No seu histórico, atuou na Cisco como Instrutor e Facilitador para o Cisco Learning Services (High Touch Delivery Learning Services), fornecendo treinamentos avançados sobre soluções, plataformas e arquiteturas Cisco de última geração. Além disso, ocupou cargos técnicos sênior em empresas de diversos segmentos de mercado. Atualmente, vive e trabalha na Irlanda. Ele também é um Certified Cisco Systems Instructor (CCSI) para o programa oficial de educação e treinamento da Cisco (Cisco Learning Partner).<br /> <br /> Leonardo desempenhou o papel de presidente do Comitê de Programa do Brasil Peering Forum (BPF), além de ter coordenado diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Plataforma de cursos EAD:''' https://ead.leonardofurtado.academy<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=3600 2023-11-08T17:27:13Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Leonardo Furtado é Engenheiro de Redes, Arquiteto de Soluções, Instrutor, e especialista em desenvolvimento de negócios. Possui formação em Ciência da Computação e 28 anos de experiência em diversas indústrias e mercados verticais. <br /> <br /> No seu histórico, atuou na Cisco como Instrutor e Facilitador para o Cisco Learning Services (High Touch Delivery Learning Services), fornecendo treinamentos avançados sobre soluções, plataformas e arquiteturas Cisco de última geração. Além disso, ocupou cargos técnicos sênior em empresas de diversos segmentos de mercado. Atualmente, vive e trabalha na Irlanda. Ele também é um Certified Cisco Systems Instructor (CCSI) para o programa oficial de educação e treinamento da Cisco (Cisco Learning Partner).<br /> <br /> Leonardo desempenhou o papel de presidente do Comitê de Programa do Brasil Peering Forum (BPF), além de ter coordenado diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> <br /> '''Servidor Discord:''' https://discord.gg/Vmf4Xdn23V<br /> <br /> '''Podcast:''' https://anchor.fm/leonardofurtado<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.Furtado&diff=2937 2021-04-10T06:30:27Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Leonardo Furtado possui formação em Ciência da Computação e é Arquiteto de Soluções com 23 anos de atuação em diversas indústrias e mercados verticais.<br /> <br /> É diretor do Gifará Serviços Avançados em TIC (&lt;nowiki&gt;https://www.gifara.com.br&lt;/nowiki&gt;).[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]Em adição, atua pela Cisco como Instrutor e Facilitador para o Cisco Learning Services (High Touch Delivery Learning Services) para treinamentos avançados de soluções, plataformas e arquiteturas Cisco de última geração.<br /> <br /> É também um ''Certified Cisco Systems Instructor'' (CCSI) para o programa de educação e treinamentos oficiais da Cisco (Cisco Learning Partner).<br /> <br /> É chair do Comitê de Programa do Brasil Peering Forum (BPF), além de coordenar diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''Podcast:''' https://anchor.fm/leonardofurtado<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> <br /> '''Servidor Discord:''' https://discord.gg/Vmf4Xdn23V<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=2936 2021-04-10T06:29:57Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Leonardo Furtado possui formação em Ciência da Computação e é Arquiteto de Soluções com 23 anos de atuação em diversas indústrias e mercados verticais.<br /> <br /> É diretor do Gifará Serviços Avançados em TIC (&lt;nowiki&gt;https://www.gifara.com.br&lt;/nowiki&gt;).[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]Em adição, atua pela Cisco como Instrutor e Facilitador para o Cisco Learning Services (High Touch Delivery Learning Services) para treinamentos avançados de soluções, plataformas e arquiteturas Cisco de última geração.<br /> <br /> É também um ''Certified Cisco Systems Instructor'' (CCSI) para o programa de educação e treinamentos oficiais da Cisco (Cisco Learning Partner).<br /> <br /> É chair do Comitê de Programa do Brasil Peering Forum (BPF), além de coordenar diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''Podcast:''' https://anchor.fm/leonardofurtado<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> <br /> '''Servidor Discord:''' https://discord.gg/Vmf4Xdn23V<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=2869 2021-03-07T01:42:47Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Leonardo Furtado possui formação em Ciência da Computação e é Arquiteto de Soluções com 23 anos de atuação em diversas indústrias e mercados verticais.<br /> <br /> É diretor do Gifará Serviços Avançados em TIC (&lt;nowiki&gt;https://www.gifara.com.br&lt;/nowiki&gt;).[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]Em adição, atua pela Cisco como Instrutor e Facilitador para o Cisco Learning Services (High Touch Delivery Learning Services) para treinamentos avançados de soluções, plataformas e arquiteturas Cisco de última geração.<br /> <br /> É também um ''Certified Cisco Systems Instructor'' (CCSI) para o programa de educação e treinamentos oficiais da Cisco (Cisco Learning Partner).<br /> <br /> É chair do Comitê de Programa do Brasil Peering Forum (BPF), além de coordenar diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''Podcast:''' https://anchor.fm/leonardofurtado<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.Furtado&diff=2868 2021-03-07T01:42:24Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Leonardo Furtado possui formação em Ciência da Computação e é Arquiteto de Soluções com 23 anos de atuação em diversas indústrias e mercados verticais.<br /> <br /> É diretor do Gifará Serviços Avançados em TIC (&lt;nowiki&gt;https://www.gifara.com.br&lt;/nowiki&gt;).[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]Em adição, atua pela Cisco como Instrutor e Facilitador para o Cisco Learning Services (High Touch Delivery Learning Services) para treinamentos avançados de soluções, plataformas e arquiteturas Cisco de última geração.<br /> <br /> É também um ''Certified Cisco Systems Instructor'' (CCSI) para o programa de educação e treinamentos oficiais da Cisco (Cisco Learning Partner).<br /> <br /> É chair do Comitê de Programa do Brasil Peering Forum (BPF), além de coordenar diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''Podcast:''' https://anchor.fm/leonardofurtado<br /> <br /> '''YouTube:''' https://www.youtube.com/c/LeonardoFurtadoNYC<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=2867 2021-03-07T01:40:22Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Leonardo Furtado possui formação em Ciência da Computação e é Arquiteto de Soluções com 23 anos de atuação em diversas indústrias e mercados verticais.<br /> <br /> É diretor do Gifará Serviços Avançados em TIC (&lt;nowiki&gt;https://www.gifara.com.br&lt;/nowiki&gt;).[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]Em adição, atua pela Cisco como Instrutor e Facilitador para o Cisco Learning Services (High Touch Delivery Learning Services) para treinamentos avançados de soluções, plataformas e arquiteturas Cisco de última geração.<br /> <br /> É também um ''Certified Cisco Systems Instructor'' (CCSI) para o programa de educação e treinamentos oficiais da Cisco (Cisco Learning Partner).<br /> <br /> É chair do Comitê de Programa do Brasil Peering Forum (BPF), além de coordenar diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> <br /> '''Podcast:''' https://anchor.fm/leonardofurtado<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Leonardo.furtado&diff=2846 2021-02-19T03:32:26Z

<p>Leonardo.furtado: </p> <hr /> <div>==Perfil do Profissional==<br /> Leonardo Furtado possui formação em Ciência da Computação e é Arquiteto de Soluções com 23 anos de atuação em diversas indústrias e mercados verticais.<br /> <br /> É diretor do Gifará Serviços Avançados em TIC (&lt;nowiki&gt;https://www.gifara.com.br&lt;/nowiki&gt;).[[Arquivo:Leonardo-Furtado.jpg|miniaturadaimagem|ligação=https://wiki.brasilpeeringforum.org/w/Arquivo:Leonardo-Furtado.jpg]]Em adição, atua pela Cisco como Instrutor e Facilitador para o Cisco Learning Services (High Touch Delivery Learning Services) para treinamentos avançados de soluções, plataformas e arquiteturas Cisco de última geração.<br /> <br /> É também um ''Certified Cisco Systems Instructor'' (CCSI) para o programa de educação e treinamentos oficiais da Cisco (Cisco Learning Partner).<br /> <br /> É chair do Comitê de Programa do Brasil Peering Forum (BPF), além de coordenar diretamente as task forces de ''Roteamento e MPLS'' e ''Capacitação''.<br /> ==Contato==<br /> Para contatos referentes a serviços de consultoria técnica especializada, fornecimento de soluções, projetos, suporte e treinamentos:<br /> <br /> '''LinkedIn:''' https://www.linkedin.com/in/leofurtadonyc/<br /> <br /> '''Telegram:''' https://t.me/leofurtadonyc<br /> ==Artigos Publicados para o BPF==<br /> *[[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]]<br /> *[[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> *[[Aprimorando a Disponibilidade da rede do ISP]]<br /> *[[Balanceamento de Trafego em Redes MPLS|Balanceamento de Tráfego em Redes MPLS]]<br /> *[[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> *[[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> *[[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]]<br /> *[[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]]<br /> *[[Construção de Redes de Gerenciamento OOB para o ISP]]<br /> *[[Dimensionando Roteador para BGP]]<br /> *[[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]]<br /> *[[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]]<br /> *[[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> *[[Fundamentos de Roteamento para Provedores]]<br /> *[[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]]<br /> *[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]]<br /> *[[Introducao ao Unified MPLS|Introdução ao Unified MPLS]]<br /> *[[O ipv6 e agora|O IPv6 é agora!]]<br /> *[[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]]<br /> *[[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]]<br /> *[[Redes MPLS para Provedores]]<br /> *[[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]]<br /> *[[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> ==Vídeos Publicados para o BPF e em seu Canal Pessoal==<br /> *[https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP]<br /> *[https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP]<br /> *[https://youtu.be/DhNLWkE2Sak Camadas de Função em uma Rede Hierárquica, Estruturada e Modular]<br /> *[https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP]<br /> *[https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP]<br /> *[https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP]<br /> *[https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores]<br /> *[https://www.youtube.com/playlist?list=PLamICWhfVUj0ts4MFc0ZDLKnfaEiN2aJJ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Playlist]<br /> *[https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN]<br /> *[https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]<br /> *[https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE]<br /> *[https://youtu.be/q2knxa3AtAo Estudo de caso: o BGP EVPN para o transporte de serviços L2, L3, ambos Unicast e Multicast, em ISPs]<br /> *[https://youtu.be/5jSTW8QbI2g Iniciantes: conceitos fundamentais sobre projetos na área de redes]<br /> *[https://youtu.be/WUWPNIaCbNw Iniciantes: conceitos fundamentais sobre projetos na área de redes - PARTE 2]<br /> *[https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1]<br /> *[https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS]<br /> *[https://youtu.be/E_aj6n_YJfU Refutando o Terraplanismo da Telecom]<br /> *[https://youtu.be/QxWiGxGeHkY Software Defined Networking SDN para Leigos]<br /> *[https://youtu.be/lEJkyVhDqio Soluções para o gerenciamento efetivo do BGP em um Sistema Autônomo]<br /> *Mais vídeos no [https://www.youtube.com/leonardofurtadonyc YouTube]<br /> ==Eventos e Palestras onde Atuou como Palestrante==<br /> *[https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/apresenta%C3%A7%C3%A3o-dos-switches-da-linha-cisco-catalyst-9000-series/ba-p/3326858/jump-to/first-unread-message Evento Webcast Apresentação dos Switches da linha Cisco Catalyst 9000 Series], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP], da Comunidade de Suporte Cisco em Português<br /> *[https://community.cisco.com/t5/eventos-de-routing-switching/desvendando-o-mpls-evento-webcast/ba-p/3103463 Evento Webcast Desvendando o MPLS], da Comunidade de Suporte Cisco em Português<br /> *[https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte], FutureISP 2019<br /> *[https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco para o ISP], FutureISP 2018<br /> *[https://youtu.be/rnVPrw3Dx8k Palestra Transformação de Pequenos Provedores em Grandes Operadoras], FutureISP 2017<br /> ==Próximas Contribuições do Autor para o BPF==<br /> As próximas contribuições deste autor para artigos na Wiki e/ou vídeos no canal do YouTube do Brasil Peering Forum. Não necessariamente na ordem apresentada a seguir. A maior parte, senão todos, será concluída durante o período do ano de 2020.<br /> *Introdução ao IP Multicast para Provedores<br /> *Introdução aos Conceitos e Soluções DWDM para Leigos<br /> *Transição de Infraestruturas MPLS Tradicionais para o SRTILFA<br /> *Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE<br /> *Implementação de AAA e TACACS+ para Controle de Acesso Centralizado aos Elementos de Rede<br /> *Soluções SD-WAN para o Mercado de Provedores<br /> *Descrevendo as Arquiteturas de Roteadores e Switches Orientados parra as Redes de Telecomunicações<br /> *Boas Práticas e Ferramentas para o Dimensionamento de Plataformas visando a Aquisição de Elementos Ativos de Redes<br /> *O ''Internet of Things'' (IoT) para o Desenvolvimento de Novos Modelos de Negócios do Provedor<br /> *Sugestões de Modelos de Implementação de Broadband Network Gateway (BNG) e Comparativos entre PPPoE e IPoE<br /> *Cenário e Aplicabilidades do Protocolo Diameter para Soluções e Serviços de Operadores de Redes<br /> *Técnicas de Transição para o IPv6 no ISP e em seus Assinantes Residenciais e Corporativos<br /> *Diferenças e Aplicabilidades entre as Diversas Abordagens e Soluções de Carrier-Grade NAT (CGN)<br /> *Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP<br /> *Soluções para Serviços de Valor Agregado (SVA) para os Mercados Residencial e Corporativo<br /> *Introdução aos Conceitos e Processos de Inovação para a Transformação de Negócios do ISP<br /> *Introdução ao Framework TOGAF para a Maximização de Resultados do ISP<br /> *Introdução ao Framework Zachman para a Definição Estruturada de Arquiteturas Corporativas<br /> *Introdução ao ITIL e COBIT para Boas Práticas Operacionais do ISP<br /> *Introdução ao Metro Ethernet Forum e Padrões Carrier Ethernet<br /> *Implementação de Boas Práticas Operacionais conforme Padrões ITU-T e MEF<br /> *Identificação e Resolução de Problemas de Transmissão de Pacotes em uma Rede<br /> *Recursos de Diagnósticos e de Suporte Disponíveis em Roteadores Clássicos do Segmento de ISP<br /> *Conhecendo com Detalhes o Funcionamento do Gerenciamento de Redes com o SNMP<br /> *Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> *Protocolos e Serviços OAM para Melhor Gerenciamento e SLA de Operadores de Redes<br /> *Recomendações e Soluções para a Correlação de Eventos com Foco na Segurança e Gerenciamento de Falhas do ISP<br /> *Cenários a Aplicabilidades com o NetFlow e IPFIX em Ambientes de ISP<br /> *Introdução ao Software-Defined Networking (SDN) e a sua Aplicabilidade para os Operadores de Redes de Telecomunicações<br /> *Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> *Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> *Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> *Tech Notes: Introdução à Arquitetura Cisco Digital Network Architecture (Cisco DNA) para Ambientes Corporativos<br /> *Troubleshooting de Problemas Frequentes com o BGP no ISP<br /> *Boas Práticas para a Construção de Políticas de Roteamento Efetivas com o BGP<br /> *Importância, Limitações e Comparativos entre IRR e RPKI para a Segurança do Roteamento de Internet<br /> *Implementação de BGP FlowSpec para o Aumento da Segurança e Mitigação de DDoS<br /> *BGP &quot;''Deep Dive''&quot;: Caso de Estudos e Boas Práticas para Sessões, Políticas de Roteamento, IRR, RPKI, e Segurança do BGP<br /> *Boas Práticas para a Proteção e Mitigação contra Ataques DDoS<br /> ==Eventos de Capacitação para a Comunidade==<br /> A seguir temos uma lista proposta de eventos ''online'' com a comunidade de profissionais que atuam em operadores de redes ou ISPs. Os temas e datas de cada evento estão aprovados e, portanto, inscreva-se utilizando os links correspondentes. As vagas são limitadas!<br /> *'''''Apresentação da Arquitetura e Solução Cisco ASR 1000'''''<br /> **Com foco nos serviços de BNG/BRAS, CGNAT, ps-QOS, ISG/ALG, e BGP, em regime de pilha dupla (IPv4/IPv6). Com demonstrações em ambiente controlado.<br /> **Duração: 4 horas, online<br /> **Data: 16 de janeiro de 2020, das 18:30h as 22:30h (online)<br /> **Link de Inscrição: https://forms.gle/wTotVLsPJEGAvn7J9<br /> **Vagas disponíveis: 50 participantes<br /> *'''''Workshop Avançado de Intermediate System to Intermediate System (IS-IS)'''''<br /> **Com foco nos conceitos teóricos e práticos para abordagens de projetos, configuração, monitoramento e suporte. Com prática em laboratórios!<br /> **Duração: 5 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 12 participantes<br /> *'''''Workshop Tendências de Competências e Habilidades para a Capacitação de Profissionais de Redes do ISP'''''<br /> **Duração: 3 horas, online<br /> **Data: &lt;u&gt;a ser determinada&lt;/u&gt;<br /> **Link de Inscrição:<br /> **Vagas disponíveis: 50 participantes</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2538 2020-07-01T01:02:14Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira, consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos e habilidades. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, juntamente com as devidas habilidades correspondentes aos conhecimentos específicos da área, assim como possíveis outros conhecimentos (periféricos), visando, especificamente, neste caso, o crescimento ou evolução em suas profissões.<br /> # Atitudes e motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem adquirir conhecimentos, habilidades, desenvolver competências, e, consequentemente, evoluir?'''''<br /> <br /> As respostas podem variar de acordo com cada indivíduo, mas a minha resposta mais precisa para esta pergunta seria o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema, na minha opinião, está no método. O método pode estar ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames de certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento, e responderá a tantas das perguntas e preocupações que você vive no momento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;. &quot;''Como desenvolver as minhas habilidades?''&quot;)<br /> ** Metodologias didáticas de ensino e aprendizado.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação, aderência e aptidão.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> ** Educação continuada.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, tampouco professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em tantas empresas que já perdi as contas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que reúno bagagem o suficiente para, legitimamente. contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a minha resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''. Há aqueles que adorariam complicar as coisas e sugerir a incorporação de outros elementos e complexidades, tais como condição social, falta de oportunidades, fator &quot;Q.I.&quot; (&quot;Quem Indica&quot;, o famoso contatinho com o &quot;Comandante Faber Castell&quot; lá da empresa), profissional naturalmente desmotivado por ter percebido, após um tempo, que aquela profissão não era para ele, dentre outros fatores e complicações. O fato é, independentemente disso tudo, você &lt;u&gt;jamais decolará&lt;/u&gt; na carreira sem o conhecimento. Seja você rico ou pobre, preto ou branco, nordestino ou sulista, hétero ou homo, evangélico ou ateísta, tudo isso é mínimo se comparado ao que realmente importa para você conseguir deslanchar nesta área, aliás, em qualquer profissão: '''''conhecimento'''''. Você pode até ter ótimos conhecimentos e estar com falta de sorte no momento, mas um indivíduo sem conhecimento é um indivíduo pouco útil para esta ou qualquer carreira ou profissão.Você pode até conseguir um emprego na área com conhecimentos fracos ou medianos, mas, decolar, jamais!<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que conseguíssemos traçar um caminho que de fato pudesse levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos, e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com alguns dos modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, focarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir alguns tipos de conhecimento que são irrelevantes para os meus propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> <br /> OBS: os &quot;''&lt;u&gt;exemplos relacionados à nossa área de TIC&lt;/u&gt;''&quot; da tabela a seguir mesclam, de forma muito íntima e implícita &quot;conhecimento&quot; e &quot;habilidade&quot;, mas saiba de antemão que são coisas distintas. Isto será esclarecido posteriormente neste artigo.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, obtido principalmente por observação, experiência em lidar com os resultados herdados por senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo. Frequentemente obtido com base na tentativa e erro.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação, e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> * Entrelaçamento quântico <br /> * Tabela Periódica <br /> * Leis de Newton <br /> * Princípio de Arquimedes <br /> * Algoritmo de Dijkstra <br /> |<br /> * &quot;O ignorante afirma, o sábio duvida, o sensato reflete.&quot; (Aristóteles)<br /> * &quot;Só sei que nada sei.&quot; (Sócrates)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> * &quot;Não existem métodos fáceis para resolver problemas difíceis.&quot; (René Descartes)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> * Aplicar um complexo e plástico golpe de capoeira!<br /> * Arriscar-se com êxito fazendo parkour no alto dos edifícios<br /> Em todos estes casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à nossa área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede com bastante fluidez e obedecendo as guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção sobre a configuração de elementos de rede, relacionando corretamente as áreas funcionais e controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia sendo impulsionada pelo mercado, liderada por um determinado fabricante, centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing.<br /> * &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se, de certa forma, à favor dos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. <br /> * &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará efetivamente a mesma coisa que as implementações RSVP-TE atuais fazem?&quot;. &quot;Valeria a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?&quot;. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado com marketing/branding do que com soluções técnicas de fato inovadoras?&quot;. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se sempre de incluir o parâmetro &quot;add&quot; para o comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}<br /> Note que não está sendo feito qualquer julgamento em termos de &quot;''que tipo de conhecimento é melhor?''&quot; porque isto simplesmente não existe! Em termos de resultados, ou eficácia, um conhecimento empírico pode ser (e muitas vezes é!) o meio mais correto ou indicado para resolvermos um problema, ou que um conhecimento puramente tácito promova os resultados desejados de forma mais efetiva que com um conhecimento empírico apenas. Um conhecimento científico não é melhor só porque é baseado em alguma teoria aliada à uma comprovação por método, pois um conhecimento filosófico pode resolver, e com alguma frequência isto acontece, um desafio que não está sendo possível resolver com um conhecimento científico; enfim, acho que você me entendeu.<br /> <br /> Caso você não tenha identificado uma afinidade ou utilidade entre esta tabela acima e a proposta deste artigo, algo tipo &quot;tudo muito supérfluo!&quot;, sugiro que repense! Apesar de ter um aspecto um tanto teórico, acho de suma importância você saber identificar como os seus conhecimentos vigentes estão enquadrados ou tipificados. Lá na frente isto poderá ser útil na hora de identificar o que precisa ser feito para aprimorar a maneira como você entende o funcionamento de determinadas tecnologias ou soluções, ou quais práticas e processos precisam ser aprimorados para um suporte mais efetivo destas, dentre outras situações. Alguns exemplos de como este &quot;''drag &amp; drop''&quot; poderia ser feito:<br /> * '''De tudo o que você sabe dissertar ou executar, em sua forma mais prática ou efetiva (implantar, configurar, operar, prestar suporte), ou seja, tecnologias, equipamentos, soluções, processos e afins, o que de fato você:'''<br /> ** '''''Conhece por herança organizacional, seja na empresa atual ou experiências prévias, ou através de convívio e troca de experiências com grupos de indivíduos e suas opiniões?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências. <br /> **** Por exemplo, adquiriu uma habilidade e experiência através de um roteiro, processo interno da empresa (&quot;é assim que você deve fazer&quot;, &quot;assim funciona&quot;, ou &quot;não faça isto!&quot;), modus operandi do setor da empresa, etc.<br /> *** Estes seriam &lt;u&gt;conhecimentos empíricos&lt;/u&gt;!<br /> ** '''''Conhece, por meios de algum processo de validação, e com o emprego de práticas documentadas em artefatos de indústria, BCOPs, frameworks, e com eficácias e resultados tecnicamente comprovados?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, adquiriu conhecimentos e experiência em um projeto e implantação de BGP integralmente apoiado por BCPs (BCP 38, 194, 185, MANRS); uma validação de circuito de dados com base no RFC 2544, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos científicos&lt;/u&gt;!<br /> ** '''''Conhece por questionamentos de princípios de aderência, aplicabilidades, julgamento de utilidade, associação de benefícios e casos de uso?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, adquiriu conhecimentos e experiência em conduzir uma análise qualitativa de riscos ou de uma matriz funcional de qualidade; questionamentos e dissertações de casos quanto ao uso de determinadas tecnologias e soluções, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos filosóficos&lt;/u&gt;!<br /> ** '''''Conhece por experiência e vivência próprias, ou seja, tentativa e erro, satisfação e frustração com resultados, etc.?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, saber identificar e antecipar riscos em determinadas manobras de configuração em função de experiência prévia ruim; saber conduzir uma operação através de uma ordem apropriada, evitando-se problemas de indisponibilidades, também por experiência prévia; saber qual versão de software usar por não conter um bug que, em um caso anterior, provocou um distúrbio na sua infraestrutura; saber que, antes de ativar um recurso no software de seu roteador, por experiência prévia/própria, outro recurso deve estar habilitado como pré-requisito, do contrário não funcionará ou provocará algum tipo de distúrbio, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos tácitos&lt;/u&gt;!<br /> Viu só? Nem tudo o que é teoria é &quot;burocrático&quot;! Há sempre como extrair coisas positivas de muitos conceitos teóricos ou aparentemente abstratos. E vou um pouco além neste discurso sobre como isto poderá ser útil para você. Imagine que você fizesse uma auto-avaliação (aliás, sugiro mesmo que faça isto!), qual seria o resultado? E quais seriam os significados destes resultados? Quanto aos &quot;significados&quot;, eu tecerei uma opinião estritamente pessoal, pois a interpretação de cada caso é realmente bastante individualizada. Eu posso pensar de um jeito, e você de outro completamente diferente. Certo? Caso você tenha interesse em saber como &lt;u&gt;'''eu'''&lt;/u&gt; (autor) penso, estas seriam as minhas respostas:<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;tácita'''''&quot;<br /> <br /> Isto para mim significaria uma coisa: generalizando aqui, você pode até ser bem &quot;safo&quot;, mas desde que seus conhecimentos sejam realmente bem seguros e produzam bons resultados. O que é difícil. Explico o por que. São preocupantes as possíveis (e não confirmadas, por isto estou generalizando) divergências entre o que órgãos de indústria ou fabricantes promovem como recomendações e boas práticas, e o que você de fato executa ou como executa o seu trabalho.<br /> <br /> Com a complexidade cada vez mais crescente das soluções tecnológicas, assim como os padrões de boas práticas operacionais, é pouco provável que um indivíduo majoritariamente &quot;tácito&quot; seja efetivo em suas atribuições, especialmente quando pensando aqui nas tantas métricas sobre as quais deverá estar apoiado todo o funcionamento do aparato tecnológico, ou seja, ''Disponibilidade'', ''Performance'', ''Segurança'', ''Confiabilidade'', ''Disponibilidade'', ''Escalabilidade'', e etc. <br /> <br /> Dificilmente um indivíduo deste perfil conseguiria orquestrar um ambiente com conhecimentos puramente tácitos. &quot;Ah, mas ele estudou o manual do fabricante para fazer o procedimento 'x'!&quot;, mas, peraí, isto não seria um conhecimento tácito! Assim como &quot;ele seguiu o processo da Operação da empresa para fazer a configuração&quot;, mas, peraí, isto também não seria um conhecimento tácito! Compreende a diferença? <br /> <br /> Não consigo vislumbrar um indivíduo majoritariamente &quot;tácito&quot; funcional, pois, tal perfil, seria um risco tremendo para os negócios de uma empresa. Gambiarras e experimentações individualizadas, com pouco ou nenhum apoio e suporte de conhecimentos científicos ou empíricos, não são uma opção! Nesta área de redes e afins, conhecimento tácito é algo muito íntimo e específico (vide os exemplos da tabela anterior), e geralmente são muito bons/úteis como complemento de outras formas de conhecimento, como o científico e o empírico. <br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;empírica'''''&quot;<br /> <br /> Tudo o que um indivíduo aprendeu a executar num ambiente de redes obedecendo algum padrão ou procedimento estabelecido pela empresa ou pelo mercado (&quot;senso comum&quot;), é considerado um conhecimento empírico. Assim como conhecimentos obtidos junto à uma comunidade de especialistas. O que é bom ou muito bom. Especialmente quando o indivíduo passa a entender os cuidados que devem ser observados durante a condução do trabalho em questão. Isto significa que, na maior parte do tempo, este indivíduo estará conduzindo atividades de acordo com padrões ou modelos confiáveis, realizando configurações, ajustes, manobras, adaptações e afins, tudo inspirado num esqueleto funcional, seguro, e resultados auditáveis ou perceptíveis.<br /> <br /> É nessas horas, inclusive, voltando ao caso anterior, que os conhecimentos &lt;u&gt;tácitos&lt;/u&gt; complementam e fazem a diferença: nem sempre os padrões ou procedimentos são bem elaborados ou seguros; nem sempre as descrições dos requisitos e respectivas tarefas asseguram que o trabalho a ser realizado estará isento de riscos ou que vá funcionar &quot;de primeira&quot;. Como ocorre por muitas vezes, o indivíduo tende a perceber isto e a tomar cuidados extras na hora de conduzir seus trabalhos, podendo usar a sua própria experiência/vivência na hora de fazer as coisas, evitar armadilhas, maximizar resultados, etc. É nessas horas que o indivíduo &quot;safo&quot; usa a sua experiência (conhecimentos tácitos) como complemento aos conhecimentos obtidos de forma empírica ou científica.<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;filosófica&quot;'''''<br /> <br /> Um indivíduo, através de uma demanda cotidiana que implemente ações cujos conhecimentos correspondentes/associados foram obtidos de forma empírica (um procedimento, um processo, um modelo...), não importando em qual estágio de sua carreira ele obteve este conhecimento, poderá eventualmente divergir de opiniões. Poderá não concordar, pelo menos não inicialmente, ou até que seja convencido por alguém. Poderá ponderar, questionar os propósitos imputados ou critérios adotados. E, em função disto, poderá desejar modificar ou aprimorar aquela demanda ou aquele processo. Refinar o método como um todo, ou parte dele. <br /> <br /> Obviamente que, &quot;questionar&quot;, &quot;ponderar&quot;, ou &quot;criticar&quot; apenas, recusando-se a todo custo a cumprir com o seu dever, qualquer que tenha sido a tarefa imputada a ele, eu não chamaria isto de conhecimento filosófico, e sim de &quot;birra de criança&quot;. O conhecimento filosófico não é fazer birra ou ter atitudes antiprofissionais! O que se espera de uma iniciativa correta para estes casos é um perfil questionador de um indivíduo trazendo à tona novos desafios e propósitos para a elaboração de novas respostas, e tudo objetivando efetividade e resultados.<br /> <br /> Isto é uma qualidade de conhecimento que tipifica bem um perfil de profissional centrado em qualidade e resultados, e vemos isto muito presente em arquitetos de soluções, alguns perfis de gestores, e até mesmo em engenheiros de redes e analistas.<br /> <br /> === Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC ===<br /> Fugindo aqui momentaneamente deste discurso de tipo de conhecimentos, e retornando ao tema de motivações abordado previamente, mas, desta vez, incorporando justificativas e argumentos na fórmula, quais são as principais motivações, justificativas e argumentos para que um indivíduo vá buscar efetivamente conhecimentos relacionados aos temas da área de TIC? Tentemos exercitar isto de forma ampla e um pouco generalista, desprezando as individualidades que movem o coração de cada um de nós. Talvez eu esteja acertando em boa parte sobre tudo o que está sugerido a seguir, mas é bem provável também que você mesmo possua seus próprios argumentos, justificativas e motivações.<br /> {| class=&quot;wikitable&quot;<br /> |+Alguns casos de argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC<br /> ! colspan=&quot;3&quot; |Argumentos<br /> |-<br /> !Requisitos para Funções Vigentes<br /> !Requisitos para Funções Futuras<br /> !Requisitos para Prospecções e Planos de Carreira<br /> |-<br /> |Obter as qualificações e competências para a conformidade com requisitos vigentes, os quais são estabelecidos pelo empregador.<br /> |Aprendizado e domínio de novas tecnologias, equipamentos ou ferramentas, como parte de um processo de adoção tecnológica na empresa, os quais são impostos ou estabelecidos pelo empregador.<br /> |Obter as qualificações e competências exigidas para enquadramento de perfil junto à uma vaga ou oportunidade pretendida pelo mercado de trabalho.<br /> |-<br /> |Aprimorar as habilidades em alinhamento com os requisitos vigentes, os quais são impostos ou estabelecidos pelo empregador.<br /> |Aprimoramento e domínio de habilidades para remodelagem em futuro próximo de componentes, processos e práticas vigentes, e a extração de melhores resultados com o uso de tecnologias atuais, em grande parte por iniciativa própria.<br /> |Obter as qualificações e competências exigidas visando a evolução ou crescimento de carreira, na mesma empresa em que atua no momento ou em outras oportunidades e prospecções.<br /> |-<br /> ! colspan=&quot;3&quot; |Justificativas<br /> |-<br /> |O empregador produz a descrição do cargo que você ocupa (&quot;''job description''&quot;), estabelecendo os pré-requisitos para a função, dentre habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |Tecnologias evoluem. Equipamentos e software ficam obsoletos. Novas ferramentas e solução são introduzidas para aprimorar funções. Ciclos de compras de soluções a cada 3-5 anos. Nesta área, esta será a sua realidade quando atuando em praticamente qualquer empresa.<br /> |O empregador produz a descrição do cargo que você pretende ocupar (&quot;''job description''&quot;), estabelecendo os pré-requisitos para a função, dentre habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |-<br /> |Para manter-se neste cargo você precisa reunir as devidas comprovações de que possui estes pré-requisitos, além de, obviamente, demonstrar resultados no exercício da função.<br /> |É esperado do indivíduo o devido compromisso em adquirir novas habilidades, desde a aprender a lidar com novo tipo de solução, ou equipamento de fabricante/modelo diferente daquele que você está habituado; dominar uma nova ferramenta; dominar um novo processo. É um processo contínuo de aprendizado.<br /> |Para ocupar o cargo pretendido você precisa reunir as devidas comprovações de que ostenta ou possui estes pré-requisitos, além de experiência comprovada, etc., e isto é normalmente verificado em uma entrevista ou durante um processo seletivo.<br /> |-<br /> ! colspan=&quot;3&quot; |Motivações<br /> |-<br /> |Por razões óbvias, decorrentes das relações trabalhistas, você precisa se &quot;enquadrar&quot;. Numa relação trabalhista há uma troca: você fornece resultados através do seu trabalho, e o seu empregador o recompensa por isto. <br /> Se você não conseguir fornecer resultados, por quaisquer que sejam os motivos, mas, neste nosso exemplo aqui, por insuficiência de conhecimentos, a probabilidade é que você seja desligado do cargo.<br /> <br /> '''Manter-se empregado, por si só, já seria uma motivação, talvez a principal.'''<br /> |Conforme já citado para este caso, tecnologias evoluem. Equipamentos ficam obsoletos e são substituídos, sejam por questões de capacidade, inovação tecnológica (novos recursos), descontinuação ou longevidade de suporte do fabricante, ou decorrente de um novo projeto na área de concessão ou expansão. <br /> <br /> Novos projetos sempre surgirão prevendo o atendimento de objetivos estabelecidos por áreas internas do negócio.<br /> <br /> Empresas normalmente procuram capacitar os times atuais para lidar com estes novos desafios, ao invés de, toda vez que surgir um projeto com uma tecnologia nova, contratar mais e mais profissionais.<br /> <br /> Nestas situações específicas você tem uma ótima oportunidade de aprender coisas novas, capacitar-se com novos conhecimentos e habilidades, e de evoluir tecnicamente em sua profissão.<br /> <br /> '''A oportunidade de aprender e evoluir. Muitas vezes tendo acesso a recursos de treinamentos de custo elevado, inviáveis na ótica de investimento pessoal. A possibilidade de atuar em um projeto de visibilidade que vá enriquecer o seu currículo; a abertura de novas oportunidades.'''<br /> <br /> '''A troca de experiências com profissionais diferenciados que poderão estar envolvidos num projeto juntamente com você (ex: especialistas do fabricante, profissionais-referência da área, etc). São ótimas motivações.'''<br /> |Quando somos jovens, temos um sonho. Desejamos ingressar no mercado de trabalho seguindo ou o nosso coração ou o que for mais viável ou conveniente em termos de oportunidade. O fato que a maioria quer mesmo é trabalhar. <br /> Alguns tem a sorte de acertar em sua primeira oportunidade de emprego, pelo menos no que diz respeito à área ou segmento de trabalho pretendido.<br /> <br /> Apesar de existirem ferramentas que facilitem a entrada de novos profissionais no marcado de trabalho, tais como programas de estágio e intercâmbios, ainda assim há alguns pré-requisitos que precisam ser preenchidos.<br /> <br /> O jovem profissional pode até não ter experiência alguma na função, o que, inclusive, é o esperado na maioria dos casos.<br /> <br /> Preparar-se devidamente para um processo seletivo, especificamente através da obtenção dos conhecimentos teóricos e técnicos exigidos para a oportunidade em questão, garantiriam chances bem maiores de êxito.<br /> <br /> Preparar-se adequadamente para suprir algo &quot;extra&quot;, além do que está sendo exigido, mas que seja compatível com a função/oportunidade pretendida, aumentariam ainda mais estas chances.<br /> <br /> '''A oportunidade de você começar direito. A oportunidade de você dar o pontapé inicial na sua carreira e já preenchendo as competências-base de tudo aquilo que norteará a sua evolução na área. O seu primeiro emprego. São excelentes questões motivacionais.'''<br /> |-<br /> |Muito frequentemente conseguimos uma vaga para um emprego sem necessariamente atendermos a todos os requisitos que foram definidos para esta, mas, quando isto acontece, normalmente preenchemos os principais requisitos, restando &quot;apenas&quot; alguns destes a serem cumpridos.<br /> Nestes casos, geralmente o empregador está &quot;apostando&quot; em você, nas suas habilidades, e na sua capacidade de desenvolver-se continuadamente, buscando preencher &quot;in loco&quot; aqueles requisitos que você não preencheu quando assumiu aquela função.<br /> <br /> '''Manter-se empregado. Não decepcionar aqueles que apostaram em você. Aprender uma nova habilidade; evoluir. Ser reconhecido pelos seu esforço e comprometimento. Seriam ótimas motivações.'''<br /> |Nem todas as situações de &quot;cenário futuro&quot; precisam ser por imposição do empregador ou por circunstâncias de novos projetos iniciados pela empresa. <br /> <br /> Você pode (e deve!) estar atento e sensível às áreas de desenvolvimento e aprimoramento pessoal. A educação continuada poderá abrir novas oportunidades na empresa em que você atua, ou em novos mercados.<br /> <br /> Ao aprimorar as suas habilidades e conquistar novos conhecimentos, você adquirirá naturalmente um senso crítico que tende a funcionar como uma &quot;faísca&quot; para o surgimento de novas formas de fornecer resultados para os negócios da companhia ou para as suas próprias atribuições.<br /> <br /> Nestas situações, você pode conquistar novas oportunidades, tais como encabeçar um novo projeto iniciado por você mesmo, liderar um time, tornar-se uma referência para a resolução de problemas críticos, pontuais ou recorrentes, destravar quase que por completo o seu pontencial.<br /> <br /> '''A satisfação de projetar e construir coisas, de sentir uma afinidade entre aquilo que você vislumbrou e aquilo que está acontecendo; reputação, credibilidade, saber que a empresa e seus colaboradores podem contar com você; a perspectiva de aumento salarial ou de promoção para um cargo. Todos estes são ótimas motivações.'''<br /> |Talvez você esteja passando por aquela fase de não sentir-se mais motivado com a função atual.<br /> <br /> As vezes, você até encontra-se motivado, mas não se sente desafiado o suficiente e não vê perspectivas de mudanças na dinâmica do seu trabalho na função atual. <br /> <br /> Você quer evoluir, quer dar o próximo salto na sua carreira, seguir adiante.<br /> <br /> Crescer profissionalmente, ser melhor recompensado por isto; ter uma equiparação salarial proporcional ao valor que você pretende fornecer para o seu empregador.<br /> <br /> Preencher um cargo mais ousado, ter mais responsabilidades, tomar decisões importantes.<br /> <br /> Isto raramente acontece no &quot;modo automático&quot;; sem planejamento.<br /> <br /> Você realmente terá que trilhar este caminho, ou seja, planejar todas as ações que viabilizarão este upgrade na carreira. <br /> <br /> Você precisará ser ousado, sistemático, organizado. Quase que por simbiose, estudar + capacitar-se + implementar as suas idéias na forma mais prática ou objetiva possível. Sem fazer isto, dificilmente você conseguirá absorver os conhecimentos que possibilitarão este impulsionamento na sua carreira.<br /> <br /> '''Dar efetivamente o próximo salto, evoluir objetivamente na carreira. Conquistar novos horizontes; aumento salarial; aspiração de um cargo mais valorizado e diferenciado. Tornar-se uma referência; um profissional conhecedor, credenciado e respeitado. São todas estas excelentes motivações.'''<br /> |}<br /> <br /> === Conhecimentos, Habilidades, Atitudes e Competências (CHAC) e desempenho: as suas diferenças, e como reuni-las ===<br /> Como já dissertei um tanto sobre conhecimentos, está na hora de partirmos para a questão de habilidades, atitudes, competências, e o desempenho. Muitos acreditam que conhecimento e habilidade sejam a mesma coisa. Pode parecer confuso, mas, na verdade, não são. Também não significam exatamente a mesma coisa &quot;habilidades&quot; e &quot;competências&quot;. Esta seção do artigo aborda a minha visão sobre as diferenças entre estes casos, e inclui no bolo também as atitudes que deverão acompanhar o seu desenvolvimento profissional com estes conhecimentos, habilidades e competências, e como o desempenho participa disto tudo.<br /> <br /> O '''''&lt;u&gt;conhecimento&lt;/u&gt;''''' é o entendimento técnico ou teórico de um assunto específico. Na área de TIC, é perfeitamente possível você ler bastante e informar-se sobre uma tecnologia que não necessariamente faça parte do seu perfil ou de seu cotidiano. Por exemplo, &quot;estar por dentro&quot; (bem informado) sobre desenvolvimento de aplicações Web, quando, na prática, você é um profissional de redes. Como outro exemplo, você pode ser bom conhecedor de &quot;segurança da informação&quot; por ter lido ou até mesmo estudado muita coisa nos aspectos teórico e técnico, feito cursos/treinamentos, etc., mas isto não significa que você possua as habilidades associadas aos conhecimentos obtidos. São duas coisas completamente diferentes. É possível que você não esteja trabalhando com determinada tecnologia, isto é, você (ainda) não atua na prática com os casos discutidos por uma dada tecnologia, mas que você tenha um interesse natural pelos temas daquela área e, consequentemente, passe a estudar estes temas, ganhando boa fluência teórica e técnica.<br /> <br /> A '''''&lt;u&gt;habilidade&lt;/u&gt;''''', por sua vez, é a sua capacidade de saber executar aquelas coisas que são ditadas pelos seus conhecimentos adquiridos. Ou seja, você aprendeu a tecnologia, solução ou ferramenta; obteve os devidos conhecimentos, e, através de muita prática em ambientes que simulam condições e cenários reais, adquiriu as boas habilidades associadas a estes conhecimentos. Ou, melhor ainda, executou estes conhecimentos ''in loco'' em um projeto ou situação cotidiana. Há uma diferença razoável entre conhecer bem alguma coisa e possuir as habilidades &quot;abençoadas&quot; para saber lidar com estas questões nas suas formas mais práticas.<br /> <br /> Um exemplo aqui: eu (autor) sou aficcionado por astronomia e astrofísica, e passo horas todas as semanas lendo sobre o tema, &quot;estudando&quot;, me informando de verdade. Isto me coloca na condição de conhecedor do tema (e numa escala que vai de &quot;leigo total&quot;, &quot;iniciante&quot;, até &quot;crânio master&quot;, embora eu esteja bem longe desse nível aí), mas nem de longe isso representa uma habilidade: eu seria incapaz de atuar nesta área com os conhecimentos que possuo no momento, e me enxergo muito distante disso tudo. São realidades completamente distintas. Você ler bastante sobre um assunto traz muito conhecimento, fato, mas o quanto disso se traduz em habilidades? Ler e decorar todas as bulas de medicamentos, saber dissertar de cor e salteado sobre elas, não te faz um médico farmacologista!<br /> <br /> A '''''&lt;u&gt;atitude&lt;/u&gt;''''' tem relação com a forma em que você enxerga esta referência entre os conhecimentos que são indispensáveis para os seus propósitos de carreira (vide tabela &quot;''Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC''&quot;) e a preparação e obtenção efetiva das habilidades necessárias correspondentes. Entenda que empregadores/empresas/clientes estão interessados em mais que apenas você conhecer alguma coisa: todos esperam confiança no seu trabalho, além dos devidos resultados! E, acredite, esta confiança vem desde o início das relações pretendidas (ex: um processo seletivo, uma proposta para prestação de serviços, uma reunião de negócios para fechar um contrato), durante a própria condução do seu trabalho (a maneira como você inicia e planeja as atividades, organiza o seu trabalho, justifica as suas ações, efetiva configurações, realiza o suporte etc.), enfim, tudo isto move o ponteiro do &quot;desconfiômetro&quot; para baixo ou para cima. Quem nunca ouviu falar de casos de &quot;''fulano'' falando é quase que um mestre, mas, na hora de colocar a mão na massa, 'trava'&quot;? Essa é a diferença entre conhecimento e habilidade! A atitude é o que você deve fazer a respeito para transformar os seus conhecimentos em habilidades. São os seus métodos, práticas, disciplina, responsabilidade, compromisso, proatividade e ação.<br /> <br /> A '''''&lt;u&gt;competência&lt;/u&gt;''''' pode ser definida como um conjunto de habilidades harmonicamente desenvolvidas para caracterizar a sua função ou profissão, como, por exemplo, um engenheiro de redes. Enquanto habilidades tendem a ser coisas mais específicas (por exemplo, um protocolo, um equipamento, um serviço), uma competência, por sua vez, é o desenvolvimento de um conjunto de habilidades que fornecem este perfil tipificado para um cargo/função. Para exemplificar, um engenheiro de redes deve possuir diversas competências, cada qual reunindo seus conjuntos de habilidades necessárias para o exercício da função.<br /> <br /> Já o '''''&lt;u&gt;desempenho&lt;/u&gt;''''' trata-se de um indicador da competência que pode ser usado para mensurar o grau de aptidão e resultados de um indivíduo no exercício de suas funções. Uma questão interessante envolvendo o desempenho é que, ao mesmo tempo, não é um sinônimo integral de competência! Confuso, não? Eu explico: um desempenho ruim pode não indicar exatamente uma falta de competência, e sim, possivelmente, em alguns casos, que os resultados ruins tem sido provocados por interferências e fatores alheios às competências do indivíduo, tais como a ausência de materiais/recursos em condições adequadas para a condução de um trabalho, as próprias condições de trabalho no geral, aspectos emocionais que por ventura estejam afetando a qualidade do trabalho daquele profissional, enfim, a lista é grande aqui. Mas, no geral, podemos afirmar e utilizar o &quot;desempenho&quot; como métrica de determinação da competência de um indivíduo.<br /> <br /> Se organizássemos estes conceitos teríamos os seguintes resultados:<br /> * Conhecimentos representam aquilo que você sabe, obtidos de forma empírica, tácita, científica e filosófica. Treinamentos, cursos, palestras, workshops, brainstorms, etc., são formas de você obter ou aprimorar seus conhecimentos.<br /> * Habilidades representam a tradução destes conhecimentos para um plano ou aspecto mais prático. É o &quot;saber fazer&quot; propriamente dito. Ou seja, como você utiliza os conhecimentos obtidos na sua vida profissional, nas tarefas do cotidiano, etc. O seu envolvimento em ações mais práticas tais como desenvolver um projeto, instalar e configurar equipamentos, aditivar uma funcionalidade no seu projeto lógico, efetuar diagnóstico e suporte a problemas, etc., são exemplos de habilidades. Muitas habilidades, apesar de poderem ser demonstradas na prática, não envolvem você ter que lidar diretamente com o componente relacionado ao conhecimento correspondente numa implementação ou ação de suporte. Por exemplo, conhecimentos aprofundados sobre um determinado protocolo de roteamento (ex: BGP), mas que você não vá lidar com isto num equipamento, e sim em um plano de projeto, elaboração de um cronograma, produção de uma documentação, ou geração de um novo processo referente a esta tecnologia; estes seriam o caso de um engenheiro de pré-vendas ou Systems Engineer.<br /> * Competências representam os conjuntos de habilidades que tipificam o seu cargo/função. Quando uma competência de &quot;''routing e switching''&quot; é demandada para um perfil profissional (engenheiro de redes), o que assumimos neste caso? Que você tenha experiência em dissertar sobre o equipamento, suas características físicas e lógicas, capacidades; instalação física e configuração lógica, lidar com um projeto técnico que informe como as tecnologias estarão integradas na rede, quais padrões e diretivas de configuração deverão ser implementados, a configuração e manutenção efetivas da solução, etc. Isto é um exemplo de uma competência típica de um engenheiro de redes. É importante salientar que há diferenças entre as palavras &quot;competência&quot; e &quot;competente&quot;. A &quot;competência&quot; significa possuir habilidades, comportamentos e atitudes compatíveis com as tarefas que fazem parte da sua função profissional, em qualquer situação relacionada às suas atribuições. A palavra &quot;competente&quot; significa ter capacidade para fazer algo em determinado momento.<br /> * Desempenho é a demonstração das suas competências na forma de resultados. É o indicador de que você é efetivo na condução das habilidades que constituem estas competências.<br /> <br /> === Habilidades técnicas (&quot;''Hard Skills''&quot;) e habilidades comportamentais (&quot;''Soft Skills''&quot;) ===<br /> Nem tudo aquilo que deve fazer parte do perfil do profissional é composto por apenas habilidades técnicas, ou &quot;''hard skills''&quot;! É verdade que por muitos anos os critérios de seleção de um perfil profissional durante processos de recrutamento eram baseados quase que integralmente nestas habilidades mais técnicas, como competências relacionadas exclusivamente a equipamentos, tecnologias, protocolos, serviços e soluções. Para ser honesto, atualmente as habilidades comportamentais pesam significativamente a favor ou contra as chances do candidato de conseguir um emprego, promoção ou aumento de salário!<br /> <br /> Com o mundo cada vez mais dinâmico e conectado, com desafios mais complexos a serem superados e tudo mais, espera-se do indivíduo em muitos casos habilidades que vão além do que ele sabe fazer com determinado tipo de solução. As empresas e seus processos seletivos estão cada vez mais rigorosos nesta parte envolvendo habilidades comportamentais e interpessoais. Antes de explicar como podemos desenvolver ambos os tipos de habilidades, acho que convém mostrar alguns exemplos de cada caso.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Exemplos de habilidades técnicas (&quot;''hard skills''&quot;) e habilidades comportamentais (&quot;''soft skills''&quot;)<br /> !Habilidades técnicas (hard skills)<br /> !Características<br /> !Habilidades comportamentais (soft skills)<br /> !Características<br /> |-<br /> |<br /> |<br /> |'''Atitude'''<br /> |A atitude é uma habilidade comportamental pouco específica, pois abrange uma diversidade de possibilidades, mas não menos apreciável: na verdade, é uma das características mais cobiçadas por empregadores, clientes e prospecções.<br /> No geral, a atitude é praticamente &quot;um conjunto de atitudes&quot; que define o seu perfil como indivíduo e profissional. Apresentarei alguns exemplos de atitudes ainda nesta tabela.<br /> |-<br /> |<br /> |<br /> |'''Capacidade analítica'''<br /> |A capacidade analítica é essencialmente uma forma de pensar que tem como objetivo a explicação de situações e fatos por meios de uma decomposição mais simples e de fácil explicação.<br /> Um profissional com boa capacidade analítica tem muita facilidade em interpretar dados e fornecer explicações simples, mas não menos úteis, para situações complexas e em momentos decisivos.<br /> |-<br /> |<br /> |<br /> |'''Capacidade de persuasão'''<br /> |A persuasão é uma forma de comunicação estratégica que é feita através de argumentos lógicos ou simbólicos, sendo a capacidade de argumentação e a retórica essenciais para conseguir persuadir alguém ou modificar o panorama de alguma situação a seu favor, ou a favor da sua empresa, em uma negociação ou gerenciamento de crise.<br /> A persuasão precisa estar acompanhada de outras habilidades comportamentais, como a ética, empatia, criatividade, capacidade de comunicação (em muitos casos) e inteligência emocional. <br /> <br /> Na área de TIC, é uma habilidade indispensável para profissionais de vendas, pré-vendas e palestrantes, mas também pode ser útil para profissionais de perfil mais técnico.<br /> |-<br /> |<br /> |<br /> |'''Capacidade de trabalhar sob pressão'''<br /> |Em poucas palavras, é uma habilidade que permite o indivíduo identificar prioridades para assegurar os resultados almejados, permitindo ainda a definição das melhores ações, mesmo em condições adversas, ao mesmo tempo em que mantendo-se o equilíbrio pessoal, respondendo às demandas e privilegiando frequentemente a qualidade e o prazo daquele objetivo.<br /> Muitos cargos e funções exigem um perfil de indivíduo que saiba lidar com trabalho sob pressão. Na nossa área, times de suporte, logística e operações são constantemente bombardeados por situações que exigem este tipo de habilidade.<br /> <br /> Trabalhar sob pressão (ou ter essa capacidade) automaticamente inclui outras habilidades comportamentais, como a inteligência emocional e a flexibilidade ou resiliência.<br /> |-<br /> |<br /> |<br /> |'''Comunicação interpessoal'''<br /> |A comunicação interpessoal é uma habilidade comportamental que que indica a proficiência do indivíduo em estabelecer comunicações efetivas com outras pessoas ou grupos de indivíduos, com foco nas relações e troca de idéias e experiências.<br /> <br /> Alguns cargos e funções fazem extenso uso de comunicação entre as partes, e o indivíduo com boa comunicação interpessoal conseguirá desempenhar as suas funções com naturalidade.<br /> |-<br /> |<br /> |<br /> |'''Criatividade'''<br /> |A criatividade é a capacidade de criar, produzir ou inventar coisas novas, bem como a capacidade de transformar situações e inovar no modo de agir. <br /> <br /> Dentre os atributos de um profissional criativo temos a curiosidade e a forma diferente de olhar as coisas, além da busca incessante por novas oportunidades e possibilidades. <br /> <br /> Na área de TIC, a criatividade é fundamental para todo e qualquer profissional que estiver engajado em produzir conceitos para superar os desafios do negócio. <br /> <br /> Projetistas (projetos de solução e adoção tecnológica), engenheiros de pré-vendas, times de vendas, dentre outros, precisam destacar bem esta habilidade, pois a criatividade faz uma diferença estupenda para as competências destes perfis.<br /> |-<br /> |<br /> |<br /> |'''Empatia'''<br /> |Uma habilidade comportamental bastante peculiar que se traduz em uma capacidade notoriamente psicológica, e que envolve a compreensão e a troca de sentimentos e emoções entre dois indivíduos.<br /> <br /> A empatia é uma capacidade bastante apreciada em diversas situações, e é um excelente fomentador de outras capacidades comportamentais, como a persuação, senso de liderança, positividade e trabalho em equipe.<br /> |-<br /> |<br /> |<br /> |'''Ética'''<br /> |A ética dita a conduta humana e profissional, e a moral é a qualidade desta conduta, especialmente quando está em julgamento os pontos de vista do bem e do mal. Ou do certo e do errado. A ética é um conceito um tanto amplo (altruísmo, caráter, costume, hábito, etc.).<br /> <br /> A ética deve ser exercitada sob o ponto de vista da certeza de que aquilo que você está fazendo é o certo, ou aquilo que seria o errado você não está fazendo, mesmo que, naturalmente, defendendo os interesses do seu empregador. Mas para tudo há um limite.<br /> <br /> Sem ética pessoal e profissional, você estará fadado a orbitar o perímetro dos profissionais que transmitem desconfiança e insegurança para relações de trabalho. Reflita!<br /> |-<br /> |<br /> |<br /> |'''Falar em público'''<br /> |Conforme um ditado conhecido popularmente: pesadelo para uns, sonho para outros. O indivíduo que consegue vencer seus medos e superar as barreiras de suas limitações, nesta questão de comunicação com o público, consegue, por tabela, conquistar novos horizontes e desenvolver melhor a sua capacidade de liderar iniciativas, projetando-se melhor para a sua evolução na carreira.<br /> <br /> Esta habilidade é particularmente almejada para perfis de gestores, times comerciais, engenheiros de pré-vendas, dentre outros.<br /> |-<br /> |<br /> |<br /> |'''Flexibilidade / resiliência'''<br /> |A resiliência, uma habilidade comportamental, pode ser definida como a capacidade do indivíduo de superar adversidades, mas sem que estas superações tragam sentimentos negativos para o cotidiano do próprio indivíduo. Em outras palavras, o indivíduo consegue lidar naturalmente com adversidades e sem quaisquer prejuízos quanto ao seu desempenho no trabalho e em sua vida pessoal.<br /> <br /> Obviamente entendo que para tudo há limites, mas isto está fora de questão nesta dissertação, pois não estou considerando casos extremistas, apenas os &quot;razoáveis&quot;.<br /> <br /> Em combinação com outras habilidades comportamentais, tais como a inteligência emocional e a capacidade de trabalhar sob pressão, o indivíduo &quot;resiliente&quot; possui mais condições de enfrentar e superar desafios enquanto mantendo-se focado na resolução destes.<br /> <br /> A resiliência do indivíduo no campo de trabalho é uma das habilidades comportamentais mais apreciadas por gestores.<br /> |-<br /> |<br /> |<br /> |'''Gestão do tempo'''<br /> |A gestão do tempo pode ser definida como um processo de organização, planejamento pessoal e organizacional/corporativista, e a efetiva divisão do tempo entre as atividades específicas que o indivíduo precisa executar em seu cotidiano.<br /> <br /> Tem como proposta, através de princípios de planejamento, priorização e organização de tarefas, promover melhor aproveitamento do tempo empregado em cada tarefa, o que frequentemente gera melhores resultados em termos de produtividade e eficiência.<br /> <br /> A gestão do tempo anda lado-a-lado com outras habilidades comportamentais, tais como a capacidade do indivíduo trabalhar sob pressão, resiliência, inteligência emocional, e outras.<br /> |-<br /> |<br /> |<br /> |'''Inteligência emocional'''<br /> |Para muitos, a inteligência emocional é uma habilidade comportamental distinta. No entanto, penso um tanto diferente disto: trata-se de um conjunto de habilidades que incluem a capacidade do indivíduo de lidar com a pressão no trabalho, autoconfiança, desenvolvimento de empatia, lidar e superar emoções negativas, auto-análise de comportamentos e atitudes no cotidiano, etc.<br /> |-<br /> |<br /> |<br /> |'''Motivação'''<br /> |A união de atitudes e comportamentos que promovem o desempenho geral do indivíduo no trabalho é o que melhor define a habilidade comportamental &quot;motivação&quot;. Quanto melhor desenvolvida for esta habilidade, maior disposição, vontade e comprometimento o indivíduo terá para com a qualidade de seu trabalho.<br /> |-<br /> |<br /> |<br /> |'''Paciência'''<br /> |A paciência é uma característica da inteligência emocional, algo bem próximo de uma virtude mesmo. Traduz-se na capacidade do indivíduo de enfrentar comportamentos extremistas de colaboradores, gestores e clientes. Muitas das vezes quando a outra parte extrapola os limites do razoável, destilando até mesmo injúrias e outras formas de agressão. Saber lidar com estas situações sem que estas tragam prejuízos para o equilíbrio emocional e produtivo do indivíduo no trabalho, e, também, em sua vida pessoal, é de fato uma virtude, bastante apreciada por sinal.<br /> |-<br /> |<br /> |<br /> |'''Positividade'''<br /> |A positividade é uma habilidade comportamental que traz consigo uma diversidade de atitudes bastante agradáveis para todo o círculo de colaboração em que o indivíduo está inserido. A positividade permite construir bons relacionamentos internos e externos (ao local de trabalho), fornece ótimo suporte de integração com resultados, dissemina sentimentos de gratidão, dentre tantos sentimentos bons. <br /> <br /> O indivíduo que exercita a positividade busca sempre extrair o melhor das experiências boas e ruins, e tem como visão o aprendizado constante. Mesmo quando ocorrem frustrações, o indivíduo, equipado de positividade, consegue extrair um ótimo aprendizado para que estes desafios possam ser superados corretamente em outras ocasiões.<br /> |-<br /> |<br /> |<br /> |'''Proatividade'''<br /> |O indivíduo proativo (ou pró-ativo) é aquele que se antecipa às situações e assume a responsabilidade pelas próprias escolhas e ações, em razão de situações impostas pelo trabalho. A proatividade pode ser mensurada de algumas formas, inclusive na questão de prevenção de incidentes ou simplesmente para evitar que problemas ocorram, justamente pelo fato do indivíduo ter tido o discernimento acerca da necessidade e a devida competência para implementar as medidas preventivas cabíveis.<br /> <br /> É uma das habilidades comportamentais mais cobiçadas por gestores!<br /> |-<br /> |<br /> |<br /> |'''Rede de contatos ativos'''<br /> |Ter uma rede de contatos ativa pode ser um tremendo diferencial para determinados perfis de trabalho! As utilidades de um ótimo networking ativo vão além das perspectivas de novas oportunidades de emprego - pesquisas indicam que em média 30% das contratações acontecem com base na indicação/networking - já que pode servir também para facilitar o intercâmbio de informações estratégicas, a troca de serviços entre o indivíduo ou a empresa em que o indivíduo trabalha e uma cadeia inteira de fornecedores capacitados. Alguns perfis de trabalho dependem bastante do networking ativo do candidato!<br /> |-<br /> |<br /> |<br /> |'''Resolução de conflitos'''<br /> |Os conflitos acontecem por diversas razões, desde a posições divergentes com relação a alguma necessidade, objetivo, comportamento, a interesses de ordem comum. Alguns indivíduos possuem ótimas habilidades de negociação e recheadas de valores éticos e morais, na qual não há a intenção de promover um ganhador ou perdedor, e sim um resultado &quot;win-win&quot;, sempre prezando pela integridade das relações, e a proteção justa dos interesses da companhia.<br /> |-<br /> |<br /> |<br /> |'''Senso de liderança'''<br /> |Liderar por exemplo, ser uma referência na condução de suas tarefas, saber compartilhar conhecimentos em equipe, saber motivar outros colaboradores, fazendo-os atingir melhores níveis de produtividade e satisfação pessoal com o trabalho. Conectar e engajar equipes em busca do bem comum; compreender resultados e assumir as responsabilidades. São exemplos de características que cercam o senso de liderança, presente nos profissionais mais distintos.<br /> |-<br /> |<br /> |<br /> |'''Solução de problemas'''<br /> |Alguns indivíduos parecem que foram feitos para atuar em funções onde a atividade primária é a resolução de problemas! Reúnem algumas qualidades e habilidades comportamentais que fomentam apropriadamente a &quot;solução de problemas&quot;, incluindo trabalho sob pressão, resiliência, paciência, senso de liderança e empatia.<br /> <br /> Independentemente deste perfil, todos os profissionais da área de TIC precisam possuir uma razoável habilidade para solucionar problemas, mas isto só é factível a partir do momento em que o indivíduo domina as habilidades técnicas (&quot;hard skills&quot;) associadas ao problema em questão.<br /> <br /> Portanto, na nossa área, a habilidade comportamental aqui anda lado-a-lado com as habilidades técnicas correspondentes, pois praticamente uma coisa depende da outra. No entanto, as habilidades técnicas apenas não são suficientes: de que adianta dominar profundamente uma tecnologia, solução ou plataforma, e não possuir inteligência emocional para lidar com situações ou problemas envolvendo a disponibilidade do serviço junto a clientes? Se o individuo não consegue trabalhar sob pressão? Ou se o indivíduo não tiver paciência para interagir com as áreas afetadas pelo problema?<br /> |-<br /> |<br /> |<br /> |'''Tomada de decisão'''<br /> |Há vários tipos de &quot;tomadas de decisão&quot;: aquelas que tomamos com base em instintos, ou em crenças subconscientes, crenças conscientes, valores pessoais ou institucionais. Independentemente do caso, a tomada de decisões é algo muito mais complexo do que apenas o próprio nome sugere. <br /> <br /> Em primeiro momento, tomar decisões envolve a identificação do problema, bem como definir os critérios, analisar, escolher alternativas e verificar a eficácia da decisão. O processo que consiste em realizar uma escolha dentre diversas alternativas; definir o problema, coletar dados e informações, analisar alternativas, escolher a melhor opção, planejar e executar, e monitorar/acompanhar os resultados desta tomada de decisões. <br /> <br /> A tomada de decisões é uma habilidade comportamental que pode ser mensurada pela experiência do indivíduo em lidar com uma diversidade grande de situações. É uma daquelas habilidades &quot;auditáveis&quot;, em que indivíduos com mais tempo de profissão, desde que expostos adequadamente a diversos tipos de desafios e respectivos &quot;outcomes&quot;, tendem a demonstrar melhor aptidão.<br /> |-<br /> |<br /> |<br /> |'''Trabalho em equipe'''<br /> |Em uma empresa, o trabalho em equipe é quando um time (setor, departamento, grupo de trabalho) resolve criar um esforço coletivo para resolver um problema, seja de ordem pontual ou como parte de um processo recorrente para a resolução de problemas, ou então a simples condução de atividades rotineiras de aspecto operacional. Parece trivial, certo? Mas saiba que a qualidade de interação entre membros de muitas equipes com as quais já tive contato realmente me deixou surpreso, e por várias ocasiões! Alguns profissionais não demonstram bom entrosamento com os demais membros de sua equipe, por mais qualificados tecnicamente que sejam!<br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Enciclopedia_e_desciclopedia_da_telecom&diff=2524 2020-06-15T22:56:07Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Enciclopédia e &quot;Desciclopédia&quot; da Telecom ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Este artigo sofrerá adições de termos, acrônimos e expressões, um tanto frequentemente! Será a nossa Enciclopédia para descrever e, sempre que possível, exemplificar cada um dos termos usados pelas empresas e profissionais das áreas de telecomunicações e redes! Da mesma forma, este artigo fornecerá, e buscará deixar destacado, juntamente a cada termo, onde aplicável, uma &quot;Desciclopédia&quot; (nada melhor que uma dose de humor, certo?) para comentar situações que são verdadeiras gambiarras encontradas no setor de telecomunicações. <br /> <br /> A Enciclopédia reúne as expressões legítimas e corretas. Já a Desciclopédia, reúne situações um tanto controversas que surgiram na cabeça altamente criativa dos profissionais da área; as gambiarras! <br /> <br /> OBS: a prioridade de edição do artigo será o fornecimento das explicações referentes aos termos e, em segundo momento, a inclusão de algum tipo de exemplo ou referência. Se algum termo não contiver um exemplo ou uma referência, simplesmente aguarde, pois isto será realizado posteriormente. <br /> <br /> Desde já, solicito para que você siga acompanhando os trabalhos do '''''Brasil Peering Forum (BPF)''''', faça o bom e sensato uso de boas práticas, e diga não às gambiarras!<br /> [[Arquivo:Bpf-enciclopedia-cover.png|centro|miniaturadaimagem|700x700px]]<br /> <br /> ==== Como consultar este artigo ou buscar os termos e expressões desejadas ====<br /> Para este procedimento, sugiro:<br /> * Todos os acrônimos, termos ou expressões estão listados em ordem alfabética. Você poderá navegar pelo índice remissivo, clicar no acrônimo ou termo desejado, e ser direcionado diretamente para ele. Ou;<br /> * Faça uma pesquisa diretamente através de seu navegador (ex: CTRL-F)!<br /> Aprecie sem moderação!<br /> <br /> === Enciclopédia ===<br /> <br /> ==== 6PE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS (6PE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6PE é um cenário de transição para a adoção do roteamento IPv6 onde, no Core do operador da rede (ISP), não há endereçamento IPv6 (ainda), e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. Para maior eficiência, flexibilidade, e redução de custos, o 6PE pode ser projetado em um ambiente de backone (Core) isento de BGP, num cenário denominado &quot;''6PE com BGP-Free Core''&quot; mas, no entanto, são coisas distintas, e uma coisa não depende da outra, embora a combinação de ambas as estratégias tende a agregar muitos benefícios.<br /> [[Arquivo:Bpf-enciclopedia-6pe.png|centro|miniaturadaimagem|600x600px|Enciclopedia: 6PE]]<br /> <br /> ==== 6VPE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS VPN (6VPE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6VPE é um cenário de transição para a adoção do roteamento IPv6 na relação entre o ISP e clientes corporativos de serviços L3VPN MPLS, onde, no Core do operador da rede (ISP), não há endereçamento IPv6, e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. A diferença primária entre o 6PE e o 6VPE é que o 6PE lida com o roteamento IPv6 unicast sobre uma infraestrutura de backbone IPv4 em uma rede MPLS, enquanto o 6VPE lida com a troca de prefixos IPv6 unicast sobre uma infraestrutura L3VPN MPLS com sessões IBGP em IPv4 e com o suporte VPNv6 entre os roteadores PE. O BGP-Free Core não é um requisito para 6VPE ou 6PE, mas poderá agregar maior flexibilidade e promover redução de custos para o operador de redes.<br /> [[Arquivo:Bpf-enciclopedia-6vpe.png|centro|miniaturadaimagem|600x600px|Enciclopédia: 6VPE]]<br /> <br /> ==== AAA ====<br /> Acrônimo: ''Authentication, Authorization, Accounting''.<br /> <br /> O AAA pode ser tratado como um framework ou um conjunto de especificações tecnológicas e recursos para a concepção de mecanismos mais seguros visando a admissão de usuários e endpoints (dispositivos) em uma rede. O AAA, além de representar um conjunto de procedimentos, é usado geralmente em combinação com protocolos e serviços tais como RADIUS, TACACS+ e Diameter. Como o próprio nome sugere, a proposta é a de fornecer métodos seguros visando a autenticação de usuário e/ou dispositivo (ex: computador, roteador CPE, ou outro tipo de dispositivo), a posterior autorização, o que, por sua vez, ditará propriedades para o acesso concedido, tais como a atribuição dinâmica de VLAN, uma ACL dinâmica, um ''Scalable Group Tag'' (SGT), atribuição de endereçamento IPv4 e IPv6 (muito comum no caso do PPPoE), dentre uma diversidade de outras variáveis que podem ser associadas ao usuário e/ou ao seu dispositivo. E, por último, a manutenção de registros de atividades para fins de auditoria daquele acesso, ou seja, o ''Accounting''.<br /> <br /> &lt;u&gt;Exemplos de cenários onde o AAA é empregado:&lt;/u&gt; controle de acesso centralizado aos equipamentos da rede por parte de operadores/administradores, e com autorização e registros de comandos na CLI, autenticação de portas de switches com o protocolo 802.1X (conhecido também como solução IBNS), controle de acesso e admissão à rede (uma evolução do IBNS conhecida por ''Network Access Control'' (NAC)), autenticação de assinantes PPPoE e IPoE em concentradores de serviços de Internet banda larga (BNG/BRAS), autenticação de usuários e dispositivos móveis em redes WLAN, dentre outros casos.<br /> <br /> ==== Access-List ====<br /> Uma Lista de Acesso (Access-List ou ACL) é uma ferramenta absolutamente versátil disponível em roteadores e switches, e também em outros tipos de equipamentos de redes, e que tem como principal proposta a de atuar como mecanismo de classificação de pacotes ou, alternativamente, em muitos casos, para classificação de rotas. Após a classificação de pacotes ou de rotas, dependendo de como e para que uma ACL estiver sendo utilizada, uma ação pode ser vinculada para o pacote ou para a rota, e conforme diretivas imputadas pelo administrador da rede.<br /> <br /> &lt;u&gt;Exemplos de cenários onde uma ACL é empregada:&lt;/u&gt; filtro ''stateless'' de pacotes (''stateless packet filtering''), filtro ''stateful'' de pacotes (''stateful packet filtering'', quando a ACL é vinculada em um roteador com suporte a firewall stateful), classificação de tráfego que deverá ou não sofrer tradução de endereços IP (em ambiente NAT e CGNAT), classificação de pacotes que deverão sofrer uma política de roteamento diferenciada para encaminhamento de tráfego &quot;bypassando&quot; a tabela de roteamento (uma PBR, ABF, e similares), classificação de pacotes para o posicionamento destes em classes de tráfego e posterior tratamento de qualidade de serviço (QoS), classificação de pacotes autorizados para serviços de gerenciamento do equipamento (acesso remoto à CLI por SSH, acesso remoto ao equipamento via SNMP, NETCONF, etc.), classificação dos pacotes de servidores NTP autorizados a sincronizar data/hora com o seu equipamento, classificação de rotas que deverão ser invocadas por um filtro de rotas ou por uma política de roteamento (para ''accept'' ou ''drop'', com ou sem modificação de atributos), e muitos outros.<br /> <br /> Uma ACL pode ser considerada um verdadeiro &quot;canivete suíço&quot;! No entanto, para algumas necessidades, há ferramentas melhores ou mais versáteis que uma ACL. Por exemplo, uma ''prefix-list'' ou ''prefix-set'' é mais flexível e adequada para filtrar rotas em uma policy de roteamento, do que usar uma ACL para este mesmo propósito.<br /> <br /> ==== AS ====<br /> Acrônimo: ''Autonomous System''.<br /> <br /> Conheça mais: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]].<br /> <br /> Um (o) sistema autônomo representa a coletânea de dispositivos de rede sob uma administração comum, e o termo é geralmente empregado para representar uma rede inteira de uma determinada empresa, seja ela um provedor de acesso à Internet (ISP), uma empresa do segmento corporativo, ou uma instituição qualquer. Em um primeiro momento, o AS tipifica exatamente isto: a &quot;rede&quot; daquela empresa, os seus equipamentos, as suas diretivas e políticas; ou seja, uma coisa mais abstrata. No entanto, algumas tecnologias levam o termo AS para as suas próprias funcionalidades, capacidades e propriedades, dando uma expedição bem mais tangível ao termo, e em sua forma mais prática e real. Uma desta tecnologias é o protocolo de roteamento BGP, como todo profissional de ISP sabe.<br /> <br /> No caso do BGP, o Sistema Autônomo (AS) não é apenas algo teórico, e sim o componente principal e real do próprio protocolo de roteamento. Você, de fato, define/configura o AS no BGP dos seus roteadores, juntamente com uma série de propriedades e parâmetros (tais como sessões, anúncios, filtros, políticas de roteamento, recursos adicionais/periféricos do BGP, etc.) para representar aquela rede e as suas respectivas políticas de roteamento, ou seja, havendo uma relação muito íntima e tangível com esta definição de AS. A Internet é composta por dezenas de milhares de sistemas autônomos, obviamente interconectados pelo protocolo de roteamento BGP.<br /> [[Arquivo:Bpf-enciclopedia-as.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Autonomous System (AS)]]<br /> <br /> ==== BGP ====<br /> Acrônimo: ''Border Gateway Protocol.''<br /> <br /> Conheça mais aqui: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]] e [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O BGP ou BGP-4 é um protocolo de roteamento do tipo vetor de caminhos e exterior (''path vector'' e EGP), e pode ser considerado como a base de todo o roteamento de Internet. Todo o funcionamento da Internet depende da boa operação do BGP e, sem ele, simplesmente não há a Internet. Obviamente que a Internet depende de muito mais coisas que o protocolo de roteamento BGP para funcionar, mas, sem dúvidas, ele é um componente tido como central.<br /> <br /> O protocolo de roteamento BGP tem sofrido muitos aditivos ao longo dos anos, com a adição de novas funcionalidades e recursos, dentre os quais convém destacar aqui o suporte às diversas famílias de endereços, tais como IPv4 Unicast, IPv6 Unicast, IPv4 Multicast, IPv6 Multicast, VPNv4, VPNv6, L2VPN, EVPN, Labeled Unicast, Traffic Engineering, e outros. Confira alguns destes recursos aqui:<br /> * [https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Border Gateway Protocol (BGP) Parameters], [https://www.iana.org/assignments/capability-codes/capability-codes.xhtml Capability Codes], [rfc:7606 Multiprotocol Extensions for BGP-4], [https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml Subsequent Address Family Identifiers (SAFI) Parameters], e há muitos outros.<br /> <br /> ==== BNG ====<br /> Acrônimo: ''Broadband Network Gateway''.<br /> <br /> Conheça mais: [[Concentradores PPPoE com IPv6]].<br /> <br /> O BNG substitui outro nome/termo, mais defasado, chamado BRAS, ou seja, apesar de serem termos intercambiáveis, recomenda-se, nos dias atuais, referenciá-lo como BNG. O BNG é essencialmente uma plataforma de roteamento equipada com funcionalidades, recursos, protocolos e serviços primários e periféricos orientados para a solução de conectividade de Internet banda larga, atendendo primariamente os assinantes residenciais, embora nada impeça que seja utilizado também para produto de Internet banda larga voltada ao segmento corporativo. O roteador BNG atua como dispositivo roteador (gateway) para as sessões autenticadas de usuários mantidas por ele (daí o termo &quot;concentrador BNG&quot;). O BNG é geralmente usado em combinação com outros componentes e procedimentos, sendo alguns destes mandatórios, enquanto outros são opcionais, variando conforme as definições de cada projeto técnico. Exemplos de tecnologias e procedimentos que &quot;casam&quot; com uma solução BNG: RADIUS, Diameter, PPPoE, IPoE, sejam estes arranjados sobre uma rede puramente Metro Ethernet + IP, ou FTTH/GPON + Metro + IP.<br /> <br /> ==== BRAS ====<br /> Acrônimo: ''Broadband Remote Access Server''.<br /> <br /> Vide o acrônimo BNG (Broadband Network Gateway).<br /> <br /> ==== Caches Enter-Deep ou Bring-Home ====<br /> O Enter-Deep Cache possui como estratégia estar profundamente fincado nas redes de acesso dos provedores de acesso à Internet (ISP), geralmente sendo adotados na forma de clusters implantados nas redes do ISP ao redor do mundo. Esta filosofia de cache foi introduzida pela Akamai e é usada por muitas empresas que seguiram na mesma filosofia. In a &quot;nutshell&quot;, e explicando isto de forma bem simplista e minimalista, como a coisa funciona, usando um exemplo simples envolvendo o Google: todos estes inúmeros ou quase incontáveis clusters localizados nas redes dos ISPs e nos data centers desta empresa no mundo compõem uma rede privada do Google. Sendo assim, quando um usuário faz uma requisição ou consulta de pesquisa, esta consulta tende a ser encaminhada primeiramente pelo provedor de acesso (ISP) local para um cache local próximo, de onde deverão sair conteúdos estáticos para o cliente enquanto este cache local, ao mesmo tempo, encaminha uma consulta pela rede privada do Google para um de seus data centers, de onde deverão sair os dados e resultados de pesquisa personalizadas para o cliente. Em um exemplo envolvendo um vídeo do YouTube, este vídeo poderá ser recuperado diretamente do cache local do ISP, se este possuir a arquitetura e se este conteúdo puder ser fornecido das proximidades deste enter-deep cache, enquanto os anúncios associados ao vídeo são recuperados a partir dos data centers do Google. Em geral, os serviços de nuvem do Google são fornecidos por uma infraestrutura de rede privada independente da Internet pública, daí as excepcionais vantagens dos ISPs em poderem contar, quando autorizados e sobre forte regime de contrato e NDA, com estas soluções baseadas enter-deep cache. Ganha o usuário, com acesso com latência mais baixa aos conteúdos, e ganha o ISP, com previsibilidade no tráfego e redução de custos com os enlaces de trânsito IP.<br /> <br /> Já a estratégia Bring Home (&quot;trazer para casa&quot;), é uma segunda filosofia de design adotada por muitas empresas de CDN. A proposta aqui é trazer os ISPs para &quot;casa&quot;, conectando clusters em pontos de presença (PoPs) construídos através de uma rede privada de alta velocidade, ao invés de implantar estes clusters diretamente nas infraestruturas de redes dos ISPs. Estes pontos de presença (PoPs) geralmente ficam mais próximos aos operadores de redes Tier-1, podendo estender-se para além destes em alguns casos. Comparado com o enter-deep cache em termos de filosofia de design, o Bring Home normalmente resulta em menores custos de manutenção, mas é menos interessante no ponto de vista de latência e taxas de transferências de dados para os usuários finais, quando comparando estes benefícios com a filosofia do Enter-Deep cache.<br /> <br /> ==== CDN ====<br /> Acrônimo: ''Content Delivery Network''.<br /> <br /> Conheça mais: [[CDN Peering e PNI - Brasil]].<br /> <br /> Ou Rede de Fornecimento de Conteúdo. Uma CDN é um sistema de servidores amplamente distribuídos que fornece acesso à páginas e à diversos tipos de conteúdos para os usuários da Internet, e com base em uma diversidade de métricas e procedimentos, tais como a geolocalização do assinante/usuário, local de origem dos conteúdos, e centros de distribuição de dados (que hospedam uma CDN) em melhores condições de fornecerem o conteúdo para o usuário requisitante, para citar algumas destas métricas e procedimentos.<br /> <br /> Como principais benefícios, as CDN asseguram menores índices de latência no fornecimento de conteúdo para os usuários requisitantes, um benefício percebido pelos próprios usuários finais, pois estes terão uma melhor experiência de consumo destes conteúdos, e permite excelentes capacidades de engenharia de rede e de tráfego para os serviços de trânsito; melhor cenário financeiro na questão de despesas operacionais de médio e longo prazos, o que seria um ótimo benefício para os ISPs que contarem com as CDNs de diversos fornecedores de conteúdos. Ou seja, ganha o usuário, com maior fluidez e experiência de consumo de conteúdos, e ganha o ISP, com seus clientes mais satisfeitos com a experiência de navegação, além dos resultados com as despesas operacionais de médio e longo prazos.<br /> <br /> ==== CFP ====<br /> Acrônimo: ''C form-factor pluggable (CFP)''.<br /> <br /> O CFP é resultante de um acordo do tipo ''multi-source agreement'' estabelecido entre os principais fabricantes de soluções da indústria para a produção de um transceptor ótico para transmissão de sinais de alta velocidade. O CFP foi desenvolvido primariamente para redes Ethernet em 100 Gbps, operando nas em 10 vias a 10 Gbps em cada sentido (Tx e Rx), ou 4 vias a 25 Gbps, também em cada sentido. As variações existentes:<br /> <br /> &lt;u&gt;CFP&lt;/u&gt; (82 mm × 13.6 mm × 144.8 mm, conexão elétrica de 148 pinos, consumo inferior a 24 W, 10×10G ou 4×25G vias). &lt;u&gt;CFP2&lt;/u&gt; (41.5 mm × 12.4 mm × 107.5 mm, conexão elétrica de 104 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 12 W, 10×10G, 4×25G, 8×25G, ou 8×50G vias, Analog Coherent Optics (ACO)). &lt;u&gt;CFP4&lt;/u&gt; (21.5 mm × 9.5 mm × 92 mm, conexão elétrica de 56 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 6 W, 4×10G ou 4×25G vias). &lt;u&gt;CFP8&lt;/u&gt; (40 mm × 9.5 mm × 102 mm, conexão elétrica de 124 pinos, sem DSP, consumo máximo de 24 W, 16×25G vias (25.78125 ou 26.5625 GBd) ou 8×50G vias). &lt;u&gt;MSA 5″×7″ (Gen 1)&lt;/u&gt; (conexão elétrica de 168 pinos, embarca DSP, consumo inferir a 80 W). &lt;u&gt;MSA 4″×5″ (Gen 2)&lt;/u&gt; (conexão elétrica de 168 pinos, DSP, consumo elétrico inferior a 40 W).<br /> <br /> ==== CGNAT ====<br /> Acrônimo: ''Carrier-Grade Network Address Translation (CGNAT ou CGN).''<br /> <br /> O CGNAT é ao mesmo tempo uma solução e um mal necessário, sempre requerido quando não há endereços IPv4 públicos suficientes para atender toda a base de clientes de um ISP. Em termos mais técnicos, o CGNAT é essencialmente uma tecnologia que realiza a tradução dos endereços IPv4 de origem dos assinantes/clientes/usuários, onde estes são geralmente endereçados com endereços IP da faixa 100.64.0.0/10 ([rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]), e não com os endereços IPv4 privativos previstos pelo RFC 1918, como alguns acreditam, para um endereço IPv4 público. O CGNAT difere da solução NAT tradicional por sofrer algumas modificações para viabilizar a tradução de endereços em larga escala e atendendo, dependendo da plataforma, a dezenas de milhares de usuários, daí o termo &quot;''carrier grade''&quot;. A principal diferença entre CGNAT e NAT é que o CGNAT é configurado para fazer a tradução do endereço IP de origem e respectivas portas usadas na conversação, mas &lt;u&gt;sem&lt;/u&gt; manter quaisquer informações referentes aos endereços IP e portas de destino, sendo isto, inclusive, um dos principais motivos pelos quais o CGNAT escala para milhões de traduções simultâneas de endereços. Há diversas abordagens de CGNAT, tanto ''stateful'' quanto ''stateless'', tais como NAT44, NAT444 / Double NAT 44, em regime determinístico ou pré-definido, ou ainda em alocação de portas em massa (Bulk Port Allocation (BPA)), ou ainda em combinação com técnicas de transição para IPv6 de assinantes com NAT 64SL, NAT64SF, IPv6 Rapid Deployment (6rd), Dual-Stack Lite (DS-Lite), e MAP-T/E<br /> <br /> Como boa prática, o CGNAT não deve substituir a necessidade pela adoção do protocolo IPv6 nas redes dos ISPs. Aliás, inclusive, estimulamos que o IPv6 seja adotado o mais rapidamente possível para a sua infraestrutura ficar cada vez menos refém do CGNAT, pois há limitações e aborrecimentos associados a esta tecnologia. Quanto mais IPv6 você possuir em sua rede, menor será a dependência por CGNAT!<br /> <br /> ==== Control Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Controle. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, que é responsável por hospedar diversos dos protocolos e serviços para funções de redes nas Camadas 2 e 3, assim como as respectivas estruturas de dados mantidas pelos processos de cada um destes protocolos e serviços.<br /> <br /> Exemplos de protocolos que atuam nesta área do equipamento: Spanning Tree Protocol (STP), Resilient Ethernet Protocol (REP), Ethernet Automatic Protection Switching (EAPS), G.8032 Ethernet Ring Protection Switching, Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP), Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP), Resource Reservation Protocol for Traffic Engineering (RSVP-TE), Address Resolution Protocol (ARP), e muitos outros, lembrando que estes protocolos mantém as suas estruturas de dados, tais como LSDB (OSPF), LIB (LDP), BGP Table (BGP), ARP Cache (ARP), etc. A tabela de roteamento, também conhecida por RIB, é mantida no plano de controle dos roteadores.<br /> [[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]<br /> <br /> ==== CPAK ====<br /> <br /> ==== Data Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Dados. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, e que mantém as estruturas de dados relacionadas às ações de processamento de quadros (no L2) e pacotes (no L3). Estruturas de dados tais como a Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), Adjacency Table, Content Addressable Table (CAM ou MAC Table), são exemplos de estruturas de dados mantidas no Data Plane. As arquiteturas modernas de roteadores e switches tendem a combinar múltiplas estruturas de dados primárias e periféricas, geralmente mantidas em componentes de hardware especializados do equipamento, para construir e programar o ''pipeline'' de processamento de pacotes, para que, além da óbvia comutação do quadro ou o roteamento do pacote, outras ações possam ser executadas sobre os pacotes, tais como a determinação se um determinado pacote deverá ser tratado como L2 ou L3, consulta ou lookup de endereços IP, consulta à listas de controle de acesso (ACL), policiamento de taxa, queueing e prioridades, manipulação de cabeçalhos L2 e L3 (marcação, tradução de endereços, operações com tags de VLAN, operações com labels MPLS), etc. Exemplos de estruturas assim são as Ternary Content Addressable Memory (TCAM) e arranjos Tree-Bitmap (TBM) e M-trie.<br /> [[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]<br /> <br /> ==== DDoS ====<br /> Acrônimo: ''Distributed Denial of Service''.<br /> <br /> Conheça mais: [[O Minimo que voce precisa saber sobre DDoS|O Mínimo que você precisa saber sobre DDoS]] e [https://youtu.be/l2tVyz1Ba1A &lt;nowiki&gt;[BPF] Entrevista com o Thiago Ayub sobre ataques e mitigação DDoS&lt;/nowiki&gt;].<br /> <br /> Atividade criminosa que tem por objetivo promover a interrupção das operações de uma infraestrutura de redes através da sua incapacidade de continuidade de prestação dos serviços. Ou seja, como o próprio nome sugere, é um ataque de negação de serviços, porém distribuída, no sentido que milhares de dispositivos na Internet são controlados de forma maliciosa para lançarem ataques contra uma rede. Redes que são vitimadas sofrem dois padrões de distúrbios primários, sendo o primeiro o esgotamento de recursos computacionais dos equipamentos da rede, e, o segundo, a saturação dos enlaces de trânsito IP. Em qualquer uma das circunstâncias, os efeitos são muito negativos e percebidos pelos clientes do ISP afetado pela atividade criminosa. Os motivadores dos ataques de DDoS tem sido cada vez mais preocupantes, e são cada vez mais frequentes as situações envolvendo competidores inescrupulosos de um ISP que está sendo vítima de um ataque, mas há também muitos casos de criminosos que atacam ISPs por &quot;profissão e esporte&quot;, exigindo quantias em - sempre por pagamentos em criptomoedas, tais como o Bitcoin - para encerrar os ataques.<br /> <br /> ==== De-Peering ====<br /> Como o próprio nome sugere, é uma ação de desfeita de peering entre dois participantes ou entre um participante principal e múltiplos (dezenas) de outros participantes. O de-peer significa o encerramento da relação e a respectiva desconexão do acordo de peering entre dois sistemas autônomos. Mesmo que, de certa forma, um tanto raros, as motivações de um &quot;de-peer&quot; ou &quot;de-peering&quot; frequentemente estão associadas a mudanças na política de peering da organização principal, ou quando uma das duas partes envolvidas naquela relação de peering viola algum termo do acordo, algo que costuma promover o que chamamos de &quot;network clean-up&quot;. Algumas situações que tipificam e até mesmo justificam um de-peering: uma das duas partes está recebendo tráfego malicioso (ex: DDoS) excessivamente, e o acordo de peering pode ser interrompido em função disto. Violação da política de roteamento, onde um dos participantes injeta informações errôneas através desta sessão de peering (ex: route leak, hijack de prefixos, e &quot;vacilos&quot; similares), e isto é agravado quando a parte é reincidente, o que poderia justificar o cancelamento do acordo de peering. Mudanças na política de roteamento e peering de um dos participantes, e o entendimento que o referido acordo entre ambas as partes não é mais necessário ou interessante, ou ainda que a outra parte não mais atende os pré-requisitos para a manutenção deste acordo. E, para finalizar, possíveis problemas envolvendo capacidades e custos. Não é a toa que as modalidades de interconexão pagas (paid peering) tem se popularizado, em particular para lidar com as questões de capacidade e custos que em alguns casos poderiam justificar um de-peer de um ou mais participantes.<br /> <br /> ==== EAQ ====<br /> Acrônimo: ''Entidade Aferidora de Qualidade''<br /> <br /> A Entidade Aferidora da Qualidade (EAQ) foi criada em atendimento às Resoluções da Anatel 574 e 575 de 28 de outubro de 2011. A EAQ é parte do processo de aferição dos indicadores de qualidade das redes de telecomunicações que suportam o acesso à internet em Banda Larga fixa e móvel no Brasil, e a seleção desta entidade é feita de forma a garantir o cumprimento do Regulamento de Gestão da Qualidade do Serviço de Comunicação Multimídia - RGQ-SCM, aprovado pela Resolução nº 574, de 28 de outubro de 2011 e do Regulamento de Gestão da Qualidade da Prestação do Serviço Móvel Pessoal - RGQ-SMP, aprovado pela Resolução nº 575, de 28 de outubro de 2011.<br /> <br /> ==== eNodeB ====<br /> O Nó B do E-UTRAN, também conhecido como Evolved Node B ou eNodeB ou eNB, é o elemento no E-UTRA do LTE que é a evolução do elemento Nó B no UTRA do UMTS. É o hardware conectado à rede de telefonia móvel que se comunica diretamente sem fio com os telefones móveis (UEs), como uma estação base de transceptores (BTS) nas redes GSM. Tradicionalmente, um Nó B tem funcionalidade mínima e é controlado por um Radio Network Controller (RNC). No entanto, com um eNB, não há elemento controlador separado. Isso simplifica a arquitetura e permite menores tempos de resposta.<br /> <br /> ==== Ethernet ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O Ethernet é uma arquitetura de interconexão para redes de computadores, originalmente pensada para os ambientes de Redes de Áreas Locais (LAN), pois, naquele tempo, o Ethernet não era funcional para comunicações a longa distância, tais como circuitos de WAN e redes Metropolitanas (MAN). A tecnologia de transmissão do Ethernet é por regime estatístico e baseada no encaminhamento de quadros (''frames''). O Ethernet é especificado para velocidades de operação selecionadas entre 10 Mbps e 400 Gbps, usando uma especificação comum de controle de acesso ao meio físico (''Media Access Control'' ou MAC). O mecanismo de contenção para o compartilhamento do meio físico no Ethernet é feito por um procedimento denominado ''Carrier Sense Multiple Access with Detection Collision Detection'' (CSMA / CD), definindo tanto a operação de mídia compartilhada (half duplex), bem como a operação em full duplex. Ao longo dos anos o Ethernet sofreu vários aditivos para acomodar novas funcionalidades e capacidades, dentre as quais posso destacar aqui os padrões DCBX para o funcionamento do Ethernet em ambientes de Data Center críticos, por exemplo, permitindo transportar o ''Fibre Channel'' diretamente sobre o Ethernet (FCoE), e também os padrões Metro Ethernet / Carrier Ethernet que fizeram com que o Ethernet aos poucos fosse evoluindo e sendo adotado pelos operadores de rede / service providers / ISP, a ponto de hoje ser a tecnologia de enlace predominante neste setor. Os principais atrativos do Ethernet incluem a flexibilidade e excelente relação custo x benefício, especialmente quando comparado às tecnologias de transmissão determinísticas (ex: SDH), sendo este fator econômico o principal motivo quanto a expansão do Ethernet para os ISPs.<br /> <br /> ==== EVPN ====<br /> Acrônimo: ''Ethernet Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> Tecnologia de transporte de serviços de Camada 2 (L2) sobre infraestrutura MPLS ou VxLAN, ou seja, L2VPN, em especial buscando, através da evolução tecnológica e pela qualidade de suas ferramentas, cumprir com os mesmos objetivos da soluções L2VPN MPLS tradicionais, tais como o VPLS, H-VPLS e VPWS, sejam estes em implementação Martini ou Kompella, porém sem incorrer nas mesmas dificuldades e complexidades associadas a estes tecnologias clássicas. Em outras palavras, o EVPN é a legítima evolução da tecnologias L2VPN tradicionais, pois resolve muitos dos conhecidos desafios dos setups típicos de L2VPN. O EVPN tem como principal proposta a implementação de uma diversidade muito ampla de serviços L2 sobre infraestruturas baseadas no IP/MPLS e em regimes ponto-a-ponto e multiponto, sendo ideal para atendermos às demandas por L2VPN dos dias atuais e com maior flexibilidade e elasticidade. Como benefícios, o EVPN não exige um protocolo adicional como ocorre no L2VPN MPLS clássico (em especial a implementação Martini), e também não exige o emprego de Pseudowires. O EVPN usa o MP-BGP (mais precisamente o AFI 25 e SAFI 70) para trocar rotas específicas para esta família de endereços, promove maior eficiência no aprendizado e distribuição de endereços MAC, e com aprendizado destes ocorrendo no plano de controle, e não no plano de dados, permite redundância &quot;''All-Active''&quot;, além de outras interessantíssimas capacidades e recursos.<br /> <br /> ==== FlowSpec ====<br /> Acrônimo: ''BGP Flow Specification''.<br /> <br /> O recurso ou tecnologia BGP ''flow specification'' (flowspec) permite definir procedimentos para codificar regras de especificação de fluxo na forma de BGP ''Network Layer Reachability Information'' (NLRI) que podem ser usadas em diversas situações, sendo que a sua principal proposta é viabilizar o filtro de pacotes com o objetivo de mitigação de ataques de negação de serviços do tipo DDoS. Para se ter uma idéia, nos métodos tradicionais de mitigação de DDoS, como é o caso do RTBH (''Remotely Triggered Black Hole Filtering'' ou &quot;buraco negro disparado remotamente&quot;), uma rota BGP é injetada anunciando o endereço do site sob ataque juntamente com uma community BGP específica para este propósito de proteção. Essa community especial nos roteadores de borda serve para definir o próximo salto para um próximo salto especial - ou seja, uma modificação proposital do atributo &quot;NEXT_HOP&quot; da referida rota BGP - para descartar ou anular pacotes destinados àquele alvo, ou seja, permitindo que o tráfego de ataque destinado ao endereço IP/alvo seja descartado no backbone do ISP. Mesmo que isto permita oferecer boa proteção, a estratégia com o uso do RTBH torna o servidor ou host configurado com aquele endereço IP completamente inacessível. Por outro lado, o BGP flowpecpec permite uma abordagem mais granular e permite ainda que você efetivamente construa instruções para combinar um fluxo específico com a origem, destino, parâmetros L4 e especificações de pacotes, como comprimento, fragmento etc., possibilitando uma instalação dinâmica de uma ação nos roteadores de borda para: a) descartar o tráfego lançado contra o alvo. b) injetar o tráfego em uma VRF específica para uma análise mais detalhada. c) policiamento da taxa deste tráfego identificado pelo flowspec. Portanto, em vez de associar uma rota com uma community especial (RTBH) para que os roteadores de borda façam o descarte &quot;cru e nu&quot; do pacote, o BGP flowspec envia um formato de fluxo específico aos roteadores de borda, instruindo-os a criar uma espécie de ACL para que seja possível construir uma política com uma ação que você desejar (os casos &quot;a&quot;, &quot;b&quot; e &quot;c&quot; citados previamente). Para conseguir isso, o BGP flowspec adiciona um novo NLRI ao protocolo BGP, possibilitando fornecer detalhes sobre especificações de fluxos, critérios de correspondência (&quot;matching&quot;) suportados e ação de filtragem de tráfego.<br /> <br /> O BGP Flowspec é um aditivo muito sofisticado para as intenções dos ISPs na questão de mitigação de ataques DDoS em suas infraestruturas.<br /> <br /> ==== FTTH ====<br /> Acrônimo: ''Fiber-to-the-Home''.<br /> <br /> O &quot;''Fiber To The Home''&quot; (FTTH), também chamado de &quot;''Fiber To The Premises''&quot; (FTTP) ou ''&quot;Fiber To The Building''&quot; (FTTB), é o conceito de projeto, instalação o uso de fibra ópticas a partir de um ponto central diretamente para edifícios individuais, como residências, edifícios de apartamentos e empresas, para fornecer acesso à Internet em alta velocidade. O ''Fiber to the Home'' (FTTH) em si é um tipo de rede de acesso que oferece a alta velocidade de conexão à Internet, usando fibra óptica que é executada diretamente na casa, no prédio ou no escritório do assinante/cliente. O FTTH oferece aos consumidores acesso a uma grande variedade de aplicativos interativos, como comunicação por vídeo, jogos, vídeo sob demanda, teletrabalho e eSaúde, dentre uma diversidade muito grande aplicações que são possíveis com o uso de uma rede relativamente muito simples, porém bastante efetiva, e com ótima relação custo/benefício.<br /> <br /> ==== GGSN ====<br /> Acrônimo: ''Gateway GPRS Support Node''.<br /> <br /> O ''Gateway GPRS Support Node'' (GGSN) é um dos dois componentes do domínio ''Packet-Switched'' (PS) ''General Packet Radio Services'' (GPRS). O GGSN, juntamente com o SGSN (''Serving GPRS Support Node'', que entrega pacotes de dados de e para as estações móveis dentro de sua área de serviço), lida com transmissões de pacotes entre a rede GPRS e redes externas de baseadas em comutação de pacotes, como a Internet ou até mesmo de infraestruturas mais legadas baseadas em pacotes, como é o caso de uma rede X.25. Do ponto de vista de uma rede externa, o GGSN é um roteador para uma subrede, porque o GGSN acaba por &quot;ocultar&quot; a infraestrutura GPRS da rede externa. Quando o GGSN recebe dados endereçados a um usuário específico, verifica se o usuário está ativo. Caso afirmativo, o GGSN encaminha os dados para o SGSN que atende o usuário móvel, mas, caso o usuário móvel estiver inativo, os dados serão descartados. Na outra direção, os pacotes de origem móvel são roteados para a rede correta pelo GGSN, que é o ponto de ancoragem que permite a mobilidade do terminal do usuário nas redes GPRS / UMTS, onde, essencialmente, ele desempenha o papel no GPRS equivalente ao agente doméstico no IP móvel, e mantém o roteamento necessário para encapsular as unidades de dados de protocolo (PDUs) para o SGSN que atende uma determinada estação móvel (MS).<br /> <br /> ==== GPON ====<br /> Acrônimo: ''Gigabit Passive Optical Network''.<br /> <br /> ==== H-VPLS ====<br /> Acrônimo: ''Hierarchical Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN MPLS orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. A diferença primária entre H-VPLS e VPLS é que o H-VPLS procura promover uma hierarquia para o estabelecimento dos pseudowires e a efetiva troca de tráfego L2 entre os sites participantes, e com o objetivo de aprimoramos a escalabilidade e a eficiência da solução VPLS. Um dos maiores benefícios do H-VPLS é a redução do overhead de sinalização e também dos requerimentos de replicação de pacotes sobre os roteadores provider edge (PE). No H-VPLS, dois tipos de dispositivos PE são definidos: o u-PE e n-PE. O u-PE recebe o tráfego L2 nativo do cliente e faz as funções L2 locais, agrega o tráfego e o encaminha até o roteador n-PE, que é onde, de fato, ocorre o encaminhamento do tráfego pelo VPLS e com base no ''Virtual Switching Instance'' (VSI).<br /> <br /> ==== Hub-and-Spoke ====<br /> <br /> ==== IPFIX ====<br /> Acrônimo: ''Internet Protocol Flow Information Export''.<br /> <br /> O ''IP Flow Information Export'' (IPFIX), é um protocolo que especifica um método para que engenheiros de redes consigam exportar dados analíticos referentes aos fluxos de tráfego que percorrem em suas redes ou sistemas autônomos para estações coletoras, devidamente equipadas com soluções específicas baseadas em software, para fins de compreenderem com clareza as matrizes de comunicação referentes aos endereços IP de origem, endereços IP de destino, ordenamento de protocolos detectados ou registrados nestas conversações, portas de origem e destino (para o caso de TCP e UDP), marcações de QoS indicadas (ex: DSCP), sistemas autônomos envolvidos, volumetria destes fluxos que representam estas conversações, &quot;''top talkers''&quot;, dentre outros dados extremamente úteis. O IPFIX é um protocolo de padrão aberto que visa promover maior flexibilidade se comparado ao NetFlow da Cisco, seja na versão &quot;10&quot;, 9 ou 5, ao Juniper JFLOW, que é bastante similar ao NetFlow v5 da Cisco, e ao CFLOW. Comparativamente, o IPFIX contém os mesmos 79 campos do NetFlow v9, mas vai além e acomoda até 238 campos, o que possibilita uma lista bastante extensa de informações para atender a muitas das necessidades dos engenheiros de redes, e estando um passo à frente para inovações futuras. Assim como NetFlow/CFLOW/JFLOW, o IPFIX tem como proposta primária auxiliar profissionais de redes e empresas no planejamento de capacidades, bilhetagem e tarifação de tráfego, detecção e prevenção de incidentes de segurança, resposta automática a ataques de negação de serviço com acionamento de RTBH, dentre outras conhecidas aplicações. Vide &lt;nowiki&gt;RFC 7011&lt;/nowiki&gt; (''Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information'') para maiores informações.<br /> <br /> ==== IPoE ====<br /> Acrônimo: ''IP over Ethernet.''<br /> <br /> O ''Internet Protocol (IP) over Ethernet'' (IPoE) é uma das soluções adotadas para a disseminação do produto de Internet banda larga nas redes dos provedores de acesso à Internet. É basicamente uma forma de fornecer tráfego de Internet banda larga sem o encapsulamento PPP sobre o Ethernet. Atualmente, a tecnologia predominante para a autenticação e autorização de assinantes de Internet banda larga é o ''Point-to-Point Protocol over Ethernet'' (PPPoE), que, apesar de estar presente na grande maioria das instalações, possui alguns desafios e diversas limitações. O IPoE entra nesta seara justamente para substituir o PPPoE nos concentradores de assinantes (conhecidos por plataformas BNG ou BRAS), ou seja, para conquistarmos maior flexibilidade com a oferta de serviços para os assinantes sem incorrermos nos problemas e desafios associados ao uso massivo do PPPoE nestes equipamentos concentradores, dentre outras características, vantagens e benefícios. Dentre as principais vantagens em substituir o PPPoE pelo IPoE está na eliminação de um protocolo específico para o procedimento (PPP), consequentemente havendo uma redução bastante satisfatória do processamento dos equipamentos concentradores, pois, um dos principais &quot;problemas&quot; do PPPoE é que este introduz um cabeçalho adicional de 8 bytes de comprimento para cada pacote entre o dispositivo CPE/CE (assinante) e o concentrador onde a sessão do usuário foi autenticada e está estabelecida. E os concentradores de assinantes precisam manter o estado destas sessões para realizar diversos procedimentos para a manutenção do serviço do assinante. Outro &quot;problema&quot; do PPPoE está em sua dificuldade em lidar eficientemente com o tráfego Multicast, sendo que este problema não está presente o IPoE, o que pode ser um fator determinante para optar pelo IPoE para assinantes de Internet banda larga com o produto IPTV. O IPoE não é o &quot;the new kid on the block&quot;, e está por aí desde os primórdios do &lt;nowiki&gt;RFC 894&lt;/nowiki&gt;, sendo inclusive suportado há muitos anos pelos principais produtos concentradores do mercado.<br /> <br /> ==== IPv4 ====<br /> Acrônimo: ''Internet Protocol version 4''.<br /> <br /> ==== IPv6 ====<br /> Acrônimo: ''Internet Protocol version 6''.<br /> <br /> ==== IRR ====<br /> Acrônimo: ''Internet Routing Registry''.<br /> <br /> O ''Internet Routing Registry'' (IRR) é um banco de dados que possui objetos inseridos e mantidos através de uma linguagem própria denominada ''Routing Policy Specification Language'' (RPSL). Estas construções RPSL são expressas em diversos tipos de objetos dos bancos de dados que estão registrados em Registros Regionais da Internet (RIRs), os quais podem ser consultados pelo serviço Whois. Cada tipo de objeto de uma base de dados IRR pode representar um determinado tipo de informação, tal como um prefixo de propriedade ou alocado para um ISP, um objeto que divulgue a sua política de roteamento, ou um objeto que represente informações de contato administrativo e de suporte técnico, dentre outros tipos de objetos. O uso correto dos recursos de uma base IRR é amplamente estimulado entre os provedores de acesso à Internet para que cada um publique corretamente os seus prefixos (a título de objetos &quot;''route''&quot; e &quot;''route6''&quot;), os seus grupos representando, cada qual, seus upstreams de trânsito, peerings, e cones de clientes (por meios de objetos &quot;''as-set''&quot;), a divulgação da intenção em termos de política de roteamento (por meios de objetos &quot;''aut-num''&quot;, com campos &quot;''import''&quot;, &quot;''export''&quot;, &quot;''mp-import''&quot; e &quot;''mp-export''&quot;), além de objetos representando ações administrativas, tais como pessoal de contato para suporte (objetos &quot;''person''&quot; e &quot;''role''&quot;). A manutenção dos objetos em uma base IRR por um ISP é fundamental para que haja um consenso na Internet sobre como os filtros de anúncios devem ser construídos pelos Sistemas Autônomos, assim como fornecer a devida visibilidade para o acionamento dos times de suporte quando problemas ocorrerem com o roteamento de Internet envolvendo um determinado Sistema Autônomo. O ''Mutually Agreed Norms for Routing Security'' (MANRS) inclusive estabelece como dois dos seus principais objetivos a &quot;Coordenação&quot; e &quot;Validação Global&quot; entre os ISPs, cujas as ações são bastante centradas nos registros de objetos nas bases de dados de IRR, e com a divulgação do objeto &quot;''as-set''&quot; principal do ASN em seu cadastro no site PeeringDB. É importante salientar que muitos ISPs produzem filtros automaticamente com base nos registros de um sistema autônomo especificados numa base conhecida de IRR, daí a importância em certificar-se que o seu AS tenha os dados corretos inseridos na base de dados de um IRR, pois, a qualquer momento, algum ISP upstream poderá simplesmente recusar o recebimento de anúncios que tiverem sido originados no seu ASN, justamente por não haver consistência destas informações nos registros de uma base IRR.<br /> <br /> ==== IRU ====<br /> Acrônimo: ''Indefeasible Right of Use''.<br /> <br /> O direito de uso indefiável (IRU) é um tipo de contrato permanente de locação de telecomunicações, que não pode ser desfeito, entre os proprietários de um sistema de comunicações e um cliente desse sistema. A palavra &quot;indefiável&quot; significa &quot;incapaz de ser anulado ou desfeito&quot;. O IRU é o arrendamento efetivo de longo prazo (propriedade temporária) de uma parte da capacidade de um cabo submarino ou de outra infraestrutura de telecomunicações. Um exemplo deste tipo de arrendamento seria um IRU especificando um determinado número de canais de uma determinada largura de banda por um período bastante prolongado de uso. Neste caso, o IRU é concedido pela empresa ou consórcio de empresas que construíram o cabo, oferecendo a um provedor de serviços de Internet a capacidade de garantir à seus próprios clientes o trânsito internacional sobre este referido cabo, na capacidade assegurada pelo IRU, e por um período de prazo bastante prolongado.<br /> <br /> ==== IX ====<br /> Acrônimo: ''Internet Exchange''.<br /> <br /> Vide Ponto de Troca de Tráfego (PTT).<br /> <br /> ==== Jitter ====<br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> <br /> O jitter é a variação de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das &quot;especificações biológicas&quot; (auditivas e/ou visuais) do ser humano, que é o indivíduo que está interagindo com a aplicação através da rede com transmissões com níveis de jitter acima dos padrões aceitáveis.<br /> [[Arquivo:Bpf-qos-6.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Jitter]]<br /> <br /> ==== L2VPN ====<br /> Acrônimo: ''Layer 2 Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> O ''Layer 2 Virtual Private Network'' (L2VPN) consiste em um conceito que representa um conjunto de tecnologias orientadas ao transporte de serviços L2 sobre uma infraestrutura baseada no IP, com ou sem o auxílio do MPLS. Enquadram-se neste caso as tecnologias que obviamente exigem o MPLS para operar, como é o caso do ''Virtual Private LAN Service'' (VPLS), para a construção e transporte de redes L2 em regime multiponto, e o ''Virtual Private Wire Service'' (VPWS), para a construção e transporte de redes L2 em regime ponto-a-ponto, sendo que ambos operam sobre uma infraestrutura MPLS.<br /> <br /> Tecnologias de &quot;''tunneling''&quot; não deixam de ser também soluções de L2VPN, pelo menos no que diz respeito à privacidade e a segregação de serviços L2 de assinantes distintos sobre uma rede IP. Outro exemplo clássico de solução para este propósito é o ''Virtual Extensible LAN'' (VxLAN), muito utilizado em ambientes de data center como cenário centrado na elasticidade de domínios L2 e excelente mobilidade de workloads/VMs. E também, mais recentemente, a evolução das soluções L2VPN tradicionais para o ''Ethernet VPN'' (EVPN).<br /> <br /> No entanto, quando utilizando o termo &quot;L2VPN&quot;, estamos quase sempre nos referindo aos clássicos modelos VPLS e VPWS empregados nas redes MPLS dos operadores de rede, e estes serviços são provisionados com o auxílio de ''pseudowires'' com o protocolo LDP em vizinhança direcionada (T-LDP) entre os roteadores participantes de um determinado serviço, o que seria a proposta de implementação ''Martini'', ou então com o protocolo BGP, para a descoberta de vizinhos e também para o procedimento de sinalização, o que seria a proposta de implementação ''Kompella''.<br /> <br /> O principal objetivo da L2VPN é viabilizar o transporte de serviços L2, primariamente o Ethernet, através de uma rede completamente baseada no IP+MPLS, e sem que seja necessário estender as VLANs destes clientes atendidos através do backbone do operador de redes ou ISP. Ganha-se muito na questão operacional, além de aprimoramentos de indicadores importantes tais como a escalabilidade, confiabilidade, resiliência e melhor facilidade para o provisionamento e manutenção destes serviços. Os operadores de redes encontram no L2VPN uma forma bem adequada de fornecer serviços atraentes para seus clientes, tais como LAN-to-LAN, ''Data Center Interconnect'', &quot;''Clear Channel''&quot;, dentre outros, sem incorrer nas complexidades e riscos associados ao emprego das tecnologias L2 básicas em suas infraestruturas, tais como o entroncamento excessivo de VLANs de clientes nos uplinks do backbone, no provisionamento e manutenção de instâncias de protocolos de resiliência L2 (que são pouco escaláveis e um tanto inseguros em redes grandes), os riscos eminentes de ocorrerem ''bridging loops'' em função das extensões destas VLANs de clientes e respectivos protocolos de resiliência L2 no backbone do ISP, dentre outros argumentos muito sólidos.<br /> <br /> As L2VPNs podem ser utilizadas também para o transporte de tecnologias legadas sobre uma infraestrutura IP+MPLS, conforme tipificado pela solução ''Any Transport over MPLS'' (AToM) como um todo, permitindo, além do próprio Ethernet, o transporte de redes ''Asynchronous Transfer Mode'' (ATM), ''Frame Relay'', enlaces ponto a ponto ''High-Level Data Link Control'' (HDLC) e ''Point-to-Point Protocol'' (PPP), e até mesmo de outras tecnologias de transmissão digital, porém de natureza determinística (e não estatística, como seria o caso do Ethernet e do IP!), tais como ''Plesiochronous Digital Hierarchy'' (PDH) e ''Synchronous Digital Hierarchy'' (SDH)! Ou seja, soluções tais como o HDLCoMPLS, PPPoMPLS, FRoMPLS, CESoPSN, SAToP, TDMoIP, procedimentos GFP + LCAS + VCAT, etc. Para entender melhor estes casos, um tanto atípicos para os dias atuais, consulte o RFC 3985 (''Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture'') e outros RFCs. <br /> [[Arquivo:Bpf-enciclopedia-l2vpn.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN]]<br /> <br /> ==== L3VPN ====<br /> Acrônimo: ''Layer 3 Virtual Private Network''.<br /> <br /> ==== Latência ====<br /> Latência de rede é o termo usado para indicar qualquer tipo de atraso que ocorra na comunicação de dados em uma rede. As conexões de rede nas quais ocorrem pequenos atrasos são chamadas de redes de baixa latência, enquanto as conexões de rede que sofrem de longos atrasos são chamadas de redes de alta latência. A alta latência cria gargalos em qualquer comunicação de rede e impede que os dados tirem proveito máximo do canal de rede, diminuindo efetivamente a largura de banda de comunicação, além de apresentae aquela sensação de &quot;rede lenta&quot;. O impacto da latência na largura de banda da rede pode ser temporário ou persistente, com base na origem destes atrasos. Em termos práticos, a latência pode ser definida pelo tempo que leva para uma solicitação viajar do remetente para o destinatário e para o destinatário processar essa solicitação e fornecer a resposta para o remetente. Em outras palavras, o tempo de ida e volta do seu navegador para um servidor. Obviamente, é desejável que esse tempo permaneça o mais próximo possível de 0, no entanto, pode haver muitas coisas em jogo para impedir que os tempos de latência de um determinado serviço permaneçam baixos. Diversos elementos fatoram para o aumento da latência, dentre eles os atrasos de natureza fixa (serialização, transmissão e propagação) e os de natureza variável (processamento e enfileiramento/queueing), sendo que todos estes atrasos são adicionados por cada elemento de rede ativo que existir no caminho entre o cliente e o servidor. A latência pode e deve ser objeto de estudos e trabalhos de reestruturações tanto do aparato tecnológico em si (categoria dos elementos ativos, tais como roteadores, switches e concentradores) quanto das ações de engenharia de rede (organização topológica, emprego efetivo de recursos nos locais certos, etc.) e engenharia de tráfego (políticas consistentes de QoS, engenharia de tráfego MPLS, engenharia de tráfego do BGP, escolha e aquisição de enlaces com latências reportadas mais baixas, etc.). Em uma rede Ethernet, IP ou MPLS, a latência sempre existirá; é inevitável. O seu trabalho deverá saber projetar a rede, escolher bem seus componentes e dimensionar adequadamente seus recursos para que os índices de latência não sejam percebidos ou prejudiciais para a experiência de navegação e usabilidade de seus clientes.<br /> [[Arquivo:Bpf-qos-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: latência]]<br /> <br /> ==== MPLS ====<br /> Acrônimo: ''Multiprotocol Label Switching''.<br /> <br /> Conheça mais: [[Redes MPLS para Provedores]].<br /> <br /> Tecnologia de encaminhamento de pacotes cujas as operações não envolvem a consulta do cabeçalho IP. Numa rede completamente MPLS, o objetivo é fazer com que as consultas para a determinação de caminhos e o efetivo encaminhamento de pacotes ocorram por meios de instruções e operações mais simplificadas, denominadas &quot;''labels''&quot;, os quais são especificados em cabeçalhos enxutos chamados de &quot;''shim header''&quot;, e em três simples operações: imposição (push), troca (swap), e disposição (pop). O MPLS surgiu inicialmente como tecnologia visando atenuar o processamento dos roteadores de backbone dos grandes operadores de redes, pois as operações com ''labels'' tinham como apelo serem mais simplificadas e desprenderem menos esforços computacionais do que as operações com os cabeçalhos IP. Atualmente este argumento, ou motivador inicial quanto ao surgimento do MPLS, é praticamente nulo, em função da sofisticação das arquiteturas de roteadores dos dias atuais, pois os novos processadores conseguem sustentar ótimas taxas de encaminhamento de pacotes e independentemente se estes possuem ''labels'' ou não, e com múltiplos serviços concorrentes. No entanto, o MPLS como um todo evoluiu muito, e uma gama de funcionalidades excepcionais foram agregadas para rodar no topo das infraestruturas MPLS, obviamente exigindo o ''label switching'' para isto, assegurando qualidade, flexibilidade e elasticidade para quase tudo o que temos de bom nas infraestruturas de redes dos ISPs. Exemplos de soluções que rodam e/ou que dependem do MPLS para funcionar incluem L3VPN MPLS, L2VPN MPLS, MPLS TE, MPLS QoS, GMPLS. Algumas destas tecnologias que rodam no topo do MPLS surgiram para resolver problemas bastante conhecidos existentes em ambientes legados, tais como escalabilidade, confiabilidade, convergência e afins (ex: L2VPN MPLS visando sanear os desafios das redes L2 clássicas; MPLS TE visando resolver os desafios de engenharia de tráfego IP, etc.), e isto ao mesmo tempo em que outros conceitos foram surgindo para fomentar ainda mais a escalabilidade, flexibilidade e redução de custos (BGP-Free Core, 6PE/6VPE, e Unified MPLS são exemplos clássicos). O MPLS pode ser considerado como um marco, um verdadeiro divisor de águas, para todo o segmento de telecomunicações.<br /> <br /> ==== MPLS Traffic Engineering ====<br /> Conheça mais: [[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]].<br /> <br /> O MPLS-TE é uma solução que embarca duas propostas principais: a) engenharia de tráfego, b) proteção e recuperação contra falhas de enlaces e roteadores. Embora frequentemente combinado com os projetos MPLS clássicos (sem TE), o MPLS-TE não depende dos procedimentos do MPLS LDP. Para a parte de engenharia de tráfego, o MPLS-TE propõe-se a sanar algumas deficiências que são inerentes do próprio roteamento IP, os quais incluem congestionamentos decorrentes do mapeamento ineficiente dos fluxos de tráfego sobre os recursos da rede (interfaces, enlaces e roteadores), e fazendo isso com um bom arranjo de ferramentas que permite flexibilidade para a manipulação dos fluxos de tráfego através da rede do ISP e sem que isto exija modificações complexas nas propriedades do roteamento IP, tais como distância administrativa e métricas de rotas IGP, políticas de roteamento no backbone, rotas estáticas e afins. Já para a questão da rápida recuperação de falhas, o MPLS-TE fornece um recurso denominado Fast Reroute (FRR), o qual, através de uma estratégia conhecida por &quot;''Make-before-Break''&quot;, viabiliza a construção de LSPs de contingência para pronto uso em caso de falhas do next hop ou do nexto hop do next hop, promovendo índices de recuperação de falhas aproximados em 50 milissegundos.<br /> <br /> ==== Multi-CDN ====<br /> <br /> ==== Multi-tenant ====<br /> <br /> ==== NAT ====<br /> Acrônimo: ''Network Address Translation''.<br /> <br /> Tecnologia que realiza a tradução de endereços IP especificados nos cabeçalho IP dos pacotes em trânsito em um roteador. O NAT foi concebido originalmente como uma das iniciativas de soluções para conter o &quot;desmatamento&quot; do endereçamento IPv4, ou seja, sendo usado para conter ou desacelerar o rápido esgotamento da disponibilidade de endereços IP públicos. Há muitos anos iniciativas tais como o ''Classless Interdomain Routing'' (CIDR), ''Variable Length Subnet Masking'' (VLSM), endereçamento IPv4 privativo (IANA RFC 1918 [rfc:1918 - Address Allocation for Private Internets]), e ''Network Address Translation'' (NAT) foram introduzidas nos conceitos de projetos de redes para que tivéssemos a sobrevida do espaço de endereços IPv4 públicos até os dias atuais. Estima-se que, sem estas iniciativas, o esgotamento destes endereços teria ocorrido há muito tempo. Falando especificamente de NAT, esta solução anda lado a lado, como &quot;unha e carne&quot;, com os endereços IP privativos. Redes corporativas e domésticas/residenciais inteiras são endereçadas com endereços IP privativos (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16), e não há rotas no backbone da Internet para estes prefixos. Para que um usuário portando um endereço IP privativo destes possa navegar pela Internet, torna-se necessário realizar a tradução de seu endereço IP de origem para um endereço IP público disponível através desta configuração de NAT. Há vários tipos de cenários envolvendo o NAT, tais como o NAT dinâmico (numa relação ''one-to-one''), o ''Port Address Translation'' (também dinâmico, mas numa relação ''many-to-one''), NAT estático (relação 1:1) e NAT estático por portas (relação 1:1 com portas), sendo que o PAT ou &quot;''masquerading''&quot; é um dos cenários mais amplamente difundidos. Para os ISPs ou operadores de rede, no que diz respeito à conectividade de Internet de assinantes residenciais com endereços IPv4, no entanto, não utiliza-se o NAT &quot;convencional&quot;, e sim uma extensão funcional denominada ''Carrier Grade NAT'' (CGN ou CGNAT), já citada em nossa Enciclopédia, em combinação com outra faixa de endereços IPv4 privativos, a 100.64.0.0/10 (conforme [rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]). Para finalizar, entenda que o NAT pode ser usado também para a tradução de endereços IP de destino, mas fica à critério de cada projeto técnico e de suas particularidades.<br /> <br /> ==== NETCONF/Yang ====<br /> Acrônimo: ''Network Configuration''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no &lt;nowiki&gt;RFC 6241&lt;/nowiki&gt;. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações. Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração &quot;na mão&quot;. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, &quot;automatizados&quot;, é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho. O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, e é tido por muitos como a melhor interface southbound para ambientes de orquestração atualmente.<br /> <br /> O YANG por sua vez é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.<br /> <br /> ==== NetFlow ====<br /> A tecnologia como um todo é composta por caches de fluxo, coletores de fluxo e analisadores de dados. O NetFlow, quando foi criado há muitos anos, surgiu inicialmente como uma proposta para ''switching path'', mas rapidamente evoluiu para aquilo que muitos dos profissionais de redes compreendem sobre ele. O NetFlow é atualmente e há muitos anos uma tecnologia que visa fornecer excepcional visibilidade na rede e em resposta aos constantemente evoluídos requisitos para que os operadores de redes saibam como as suas redes estão se comportando, e fornecendo respostas para situações tais como: mapa de uso de aplicativos e redes, produtividade e utilização de recursos de rede, impacto das alterações na rede, detecção de anomalias na rede, assim como a identificação de vulnerabilidades de segurança, e problemas de conformidade a longo prazo. Para estas e outras necessidades, os engenheiros de redes passam a possuir ferramentas para entender quem, o que, quando, onde e como o tráfego da rede está fluindo, fomentando melhor entendimento sobre como as tecnologias empregadas na rede estão funcionando em alinhamento com os negócios da empresa; trilha de auditoria de como a rede é utilizada, aumento da conscientização quanto aos investimentos e uso da rede como um todo, redução de vulnerabilidades da rede, redução dos índices de downtime e distúrbios gerais, redução de custos, etc. O NetFlow pode ser usado como uma ferramenta &quot;simples&quot; para o gerenciamento de performance da rede, ou para situações bem mais ousadas, incluindo ações de planejamento de capacidades, engenharia de rede, engenharia de tráfego, bilhetagem e tarifação de tráfego, e detecção e mitigação de malware e de ataques DDoS sobre a rede, para citar alguns casos. Em termos práticos, o NetFlow é configurado em roteadores e switches, onde estiver disponível/suportado, podendo ser customizável em alguns casos, e, após isto, o equipamento exportará os bilhetes de fluxos de tráfego por NetFlow até uma estação coletora, a qual processará e consumirá estes dados, de acordo com os exemplos de soluções e casos citados anteriormente, e podendo interagir de volta com a rede para que ações sejam executadas pelos dispositivos da rede.<br /> <br /> O NetFlow é um protocolo proprietário da Cisco, mas que está disponível em outros fabricantes do mercado. O seu equivalente em termos de padrão aberto é o protocolo ''Internet Protocol Flow Information eXport'' (IPFIX).<br /> <br /> ==== NFV ====<br /> Acrônimo: ''Network Functions Virtualization''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware &quot;''commodity''&quot;. Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado. Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. <br /> <br /> ==== NodeB ====<br /> Um Node B é um termo para denotar uma estação base na terminologia WCDMA/UMTS, e é responsável pelo enlace de rádio entre o usuário da rede móvel e a parte fixa da rede ''UMTS Terrestrial Radio Access Network'' (UTRAN), conforme definido pelo 3GPP, ou seja, fornecendo a cobertura de rádio e conversão de dados entre esta rede de rádio e os ''Radio Network Controllers'' (RNCs).<br /> <br /> ==== OM ====<br /> OM1 - <br /> <br /> OM2 - 62,5/125 microns<br /> <br /> OM4 - 50/125 microns<br /> <br /> ==== Open/R ====<br /> (IGP virtualizado)<br /> <br /> ==== OSPF ====<br /> Acrônimo: ''Open Shortest Path First''.<br /> <br /> Conheça mais: [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas práticas para a implantação do OSPF em ambientes de ISP]]<br /> <br /> Protocolo de roteamento dinâmico do tipo interior e por definição de estado de enlaces (Link-State). O OSPF é um dos principais componentes das infraestruturas de redes dos provedores de acesso à Internet, sendo indispensável para viabilizar o roteamento necessário para o transporte das sessões BGP, resolução de roteamento recursivo referente ao atributo NEXT_HOP das rotas BGP mantidas nos Sistema Autônomo do ISP, além de atuar também para funções de roteamento de alguns serviços internos específicos do ISP. Muito frequentemente o OSPF é utilizado, também, em alinhamento com a tecnologia para fins de engenharia de tráfego com o MPLS TE, sendo, neste caso, inclusive, um componente obrigatório para este tipo de projeto. O OSPF destaca-se pela eficiência nas ações de rápida convergência, rápida recuperação de falhas e escalabilidade. Alternativamente ao OSPF, os operadores de redes podem optar pelo protocolo de roteamento IS-IS.<br /> <br /> ==== PCC ====<br /> Acrônimo: ''Path Computation Client.'' <br /> <br /> O PCC é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), o próprio cliente PCC (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCE ====<br /> Acrônimo: ''Path Computation Element''.<br /> <br /> O PCE é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCEP ====<br /> Acrônimo: ''Path Computation Element Communication Protocol''.<br /> <br /> O PCEP é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client'' (PCC)), o próprio protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)). O novo paradigma de redes programáveis orientadas a aplicações foi o que impulsionou as extensões PCEP, as quais possuem definições nos ''drafts draft-ietf-pce-stateful-pce'', ''draft-crabbe-pce-pce-initiated-lsp'', ''draft-ali-pce-remote-initiated-gmpls-lsp'', e outros.<br /> <br /> ==== Peering ====<br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Peering ou Troca de tráfego é uma relação comercial e técnica entre duas redes. É um acordo em que as redes admitem trocar tráfego entre os clientes uns dos outros, desde que o relacionamento seja '''mutuamente benéfico''', e nem sempre os acordos são isentos de custo ou trocas comerciais. Para garantir que cada lado do acordo tenha benefícios similares, as redes podem precisar atender aos requisitos pré-definidos para serem elegíveis. Por exemplo, uma rede pode precisar manter uma certa proporção de troca de tráfego, presença geográfica ou capacidade de backbone. A implantação real dessas relações de Peering, geralmente ocorre em locais comuns, como os NAPs e IXs estabelecidos pelo mundo (''Public'' Peering), ou através de links dedicados pagos pelas redes envolvidas (PNI-''Private network Interconnect'').<br /> <br /> ==== PGW ====<br /> Acrônimo: ''Packet Data Network Gateway''.<br /> <br /> ==== PNI ====<br /> Acrônimo: ''Private Network Interconnection''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> O famoso Private Peering ou Interconexão Privada em português - é aquele que normalmente não envolve quaisquer pontos de troca pública, ou seja, são portas de roteadores ''back-to-back'' normalmente interligadas por um ''cross-connect'' ou &quot;''golden jumper''&quot; ou até por capacidade em redes de transporte ''LAN-to-LAN''.<br /> <br /> ==== PPPoE ====<br /> Acrônimo: ''Point-to-Point Protocol over Ethernet''.<br /> <br /> O PPPoE é um protocolo utilizado para encapsular quadros PPP dentro de quadros Ethernet, tendo surgido no final dos anos 90 juntamente com a proliferação da Internet banda larga proporcionada com a entrada das tecnologias de transmissão baseadas no DSL. O PPPoE servia então como uma solução de tunelamento dos pacotes sobre a conexão DSL. Atualmente, com a predominância das redes FTTH, o PPPoE continua sendo utilizado nas redes dos ISPs, mas primariamente como mecanismo de autenticação e autorização de assinantes dos produtos de Internet banda larga dos ISPs, sendo o principal procedimento utilizado para este propósito, e a sua operação neste modelo ocorre entre o equipamento do assinante (CPE/CE) e o concentrador de assinantes (BNG ou BRAS), cuja a separação poderá ser uma rede Metro Ethernet (L2) clássica, ou L2 sobre MPLS (L2VPN), ou xPON.<br /> [[Arquivo:Bpf-protecao-roteadores-7.png|centro|miniaturadaimagem|600x600px|Enciclopédia: PPPoE]]<br /> <br /> ==== PTT ====<br /> Acrônimo: ''Ponto de Troca de Tráfego''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Ponto de Troca de Tráfego (PTT), em inglês ''Internet Exchange Point'' (IXP), é um modelo de interconexão de redes entre os provedores de Internet e redes de fornecimento de conteúdo. Os Pontos de Troca de Tráfego (PTT) funcionam como hubs em que provedores podem conectar seus sistemas autônomos (AS), facilitando o tráfego de informações entre si. No Brasil, o IX.br é um projeto de PTTs locais gerido pelo Núcleo de Informação e Coordenação do Ponto Br (NIC.br) e pelo Comitê Gestor da Internet no Brasil (CGI.br), que facilita o fluxo de informações entre provedores de Internet e conteúdo online em diversas regiões no país. Na prática, quanto maior e melhor for um PTT, mais dados os provedores conseguem trocar, melhorando a eficiência da rede e encurtando o caminho da conexão entre os computadores, pois projetos de PTTs como o do IX.br proporcionam a ligação direta entre os participantes, permitindo que muitos Sistemas Autonômos (AS) troquem tráfego diretamente. A interligação de diversos AS em um IX, ou Ponto de Troca de Tráfego (PTT), simplifica o trânsito da Internet e diminui o número de redes até um determinado destino. Isso melhora a qualidade, reduz custos e aumenta a resiliência da rede. Também é possível oferecer ou contratar outros serviços a partir da conexão do seu ISP em um IX, como, por exemplo, serviços de trânsito de Internet.<br /> <br /> ==== QoS ====<br /> Acrônimo: ''Quality of Service''.<br /> <br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]].<br /> <br /> O ''Quality of Service'' (QoS) não deve ser compreendido como uma única tecnologia apenas, e sim um conjunto de tecnologias, ferramentas e práticas que, devidamente arrendadas, buscam sanear algumas das deficiências típicas de transmissão presentes em ambientes de redes de natureza estatística, especialmente o controle de latência, jitter, e perda de pacotes, decorrentes da insuficiência de recursos para a transmissão de pacotes nestes ambientes, como, por exemplo, os conhecidos gargalos/congestionamentos, esgotamento de buffers, e outros. Com a convergência de praticamente todo o tipo de aplicação e serviço para o transporte sobre redes baseadas no protocolo IP, soluções estas tais como Voice over IP (VoIP), Comunicações Unificadas (aka &quot;Telefonia IP e/ou Colaboração&quot;), Vídeo-conferência (em regime específico para tal, ou em conjunto com uma solução de Colaboração), etc., os engenheiros de redes precisam acomodar adaptações que permitam com que estes tipos de tráfego fluam de acordo com os padrões aceitáveis para uma boa interação humana através destas redes - em particular a audição e a visão. Anteriormente as soluções de vídeo e voz funcionavam sobre infraestruturas de redes digitais, ou seja, baseadas em transmissão deterministica, as quais não sofriam dos mesmos problemas das redes de transmissão estatísticas e baseadas em pacotes (congestionamentos; gargalos, descartes de pacotes devido a insuficiência temporária de buffers, etc.), como é o caso do Ethernet, IP e MPLS. Os requerimentos para o transporte de voz são bem mais agressivos nas questões de latência, jitter e perda de pacotes, se comparados com as transmissões de aplicações puramente de dados. As transmissões de vídeo podem ser extremamente agressivas, pois possuem os mesmos requisitos de latência, jitter e perda de pacotes das transmissões de voz, só que comportam-se em grande parte como uma aplicações de dados com elevada taxa de transmissão e consumo de recursos da rede. Para que a experiência de uma comunicação entre duas pessoas através de um serviço de VoIP/Telefonia IP/Colaboração/Vídeo fique isenta de picotes na voz, metalização da voz, ecos, atrasos excessivos, congelamento de imagens, perda de sincronismo entre vídeo e áudio, dentre outros, torna-se necessário priorizar estes tipos de transmissão com auxílio de políticas e configurações específicas. E é exatamente para isto que o QoS precisa ser adotado nas redes nos dias atuais. O mesmo é válido quando tratando-se de transmissões na rede envolvendo uma aplicação de dados crítica (um sistema ERP ou CRM) e uma navegação usual ou recreativa de Internet, onde, nestes casos, é muito desejável que a prioridade de transmissão seja de uma aplicação mais importante quando houver insuficiência de recursos para acomodar ambos os tipos de tráfego em um determinado momento. <br /> <br /> O QoS especifica uma diversidade de ferramentas e técnicas devidamente categorizadas em Classificação, Marcação, Gerenciamento de Congestionamentos, Controle de Congestionamentos, Policiamento, Moldagem e Eficiência de Links. <br /> [[Arquivo:Bpf-qos-9.png|centro|miniaturadaimagem|600x600px|Enciclopédia: QoS]]<br /> <br /> ==== QSFP ====<br /> Acrônimo: ''Quad Small Form Factor Pluggable''.<br /> <br /> ==== RADIUS ====<br /> Acrônimo: ''Remote Authentication Dial In User Service''.<br /> <br /> ==== RGI Classe V da Anatel para SCM ====<br /> <br /> ==== RNC ====<br /> Acrônimo: ''Radio Network Controller''.<br /> <br /> ==== Roteador ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== Route-policy ====<br /> Uma route policy é uma ferramenta que &quot;materializa&quot; ou &quot;instrumentaliza&quot;, através de conceitos de sintaxe e semântica de uma interface de linha de comando (CLI), que é parte integrante do sistema operacional de roteadores, a política de roteamento idealizada pelo administrador ou engenheiro de uma rede para o seu projeto ou o atendimento de uma necessidade específica. Enquanto uma &quot;política de roteamento&quot; é o conceito projetado para uma interpretação mais humana da palavra, pois especifica a idéia, intenção ou interesse; é a &quot;política no papel&quot;, como, por exemplo, na perspectiva de cada roteador BGP vizinho ao seu roteador, quais prefixos importar, quais prefixos exportar, quais atributos deverão ser modificados, e sobre quais prefixos/rotas estas modificações devem ser feitas, para conceber quaisquer que sejam as necessidades em termos de engenharia de rede e de tráfego do projeto técnico idealizado pelo engenheiro da rede, contemplando ainda questões associadas à segurança do roteamento de Internet (prevenção de ''route leaks'', ''prefix hijacks'', supressão do recebimento e envio de ''bogons''/''martians''/''unallocated'', etc.). A '''''route policy''''', por sua vez, já é a efetiva instrumentação propriamente dita desta política de roteamento. É a &quot;policy&quot; na sua forma de configuração na linguagem suportada pelo sistema de seu roteador. Ou seja, &quot;os comandos&quot; da CLI, a sintaxe, a semântica. O termo route policy em si serve para o generalizar um conjunto de ferramentas que são encontradas nos roteadores e utilizadas para definirmos &quot;na forma de CLI&quot; as nossas políticas de roteamento, as quais deverão ser aplicadas nos sentidos &quot;entrada&quot; (''import'' ou &quot;''in''&quot;) e &quot;saída&quot; (''export'' ou &quot;''out''&quot;) de nossas vizinhanças BGP. Cada plataforma de roteador e de cada fabricante tem o seu conjunto próprio de ferramentas, capacidades, sintaxes, recursos suportados (e não suportados), etc. Por exemplo, roteadores Juniper (software &quot;JUNOS&quot;) implementam as suas facilidades por meios do ''Routing Policy Framework'', que consiste de termos (&quot;''terms''&quot;) definidos na forma de um ou mais ''policy-statement'', com sofisticadas e variadas opções de incidência de classificação (''match'') e ações a serem adotadas em cada incidência (''accept'', ''reject'', modificar atributos, etc.), e podendo ainda acionar outras ferramentas e recursos periféricos para uma classificação mais refinada dos prefixos (ex: ''route-filter-list'', ''community'', etc). Roteadores Cisco equipados como Cisco IOS XR Software, por sua vez, possuem um sistema periférico muito robusto denominado ''Routing Policy Language'' (RPL), que combina diversos tipos de objetos (''prefix-set'', ''as-path-set'', ''community-set'', ''extcommunity-set'', dentre outros), para definir uma sofisticada, porém de simples interpretação, política de roteamento na forma de &quot;''route-policy''&quot;, com operações intuitivas na forma de &quot;''if'' / ''else'' / ''then'' / ''set'' / ''pass'' / ''drop'' / ''done'' / ''endif'', etc.&quot;. Já os roteadores da Cisco baseados no Cisco IOS e IOS XE Software apresentam as conhecidas e pioneiras &quot;''Route Maps''&quot;, as quais atuam em conjunto com outros recursos disponíveis na plataforma, tais como ''prefix-lists'', ''community-lists'', ''ip as-path access-lists'', e outras. Já os roteadores da Huawei no geral implementam recursos similares em termos de implementação aos do Cisco IOS / IOS XE, tais como ''route-policy'', ''ip-prefix'', ''community-filter'' e outros, enquanto equipamentos mais recentes deste fabricante já implementam uma solução diferente denominada ''eXtended routing-Policy Language'' (XPL), inspirada no RPL do Cisco IOS XR. Independentemente do &quot;vendor&quot; ou do equipamento, o fato é que route policies são indispensáveis, pois são usadas cotidianamente para o cumprimento de diversos objetivos relacionados ao roteamento de Internet ou de qualquer projeto de infraestrutura IP onde o BGP seja utilizado para fornecer segurança e engenharia de tráfego.<br /> <br /> ==== RPKI ====<br /> Acrônimo: ''Resource Public Key Infrastructure (RPKI)''.<br /> <br /> ==== RTBH ====<br /> Acrônimo: ''Remotely Triggered Black Hole (RTBH)''.<br /> <br /> ==== RUM ====<br /> <br /> ==== SBI ====<br /> Acrônimo: ''Settlement Based Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão também conhecido como Peering Pago (Paid Peering), onde uma das redes paga a outra pela troca de tráfego.<br /> <br /> ==== SCM ====<br /> Acrônimo: ''Serviço de Comunicação Multimídia''.<br /> <br /> ==== SDN ====<br /> Acrônimo: ''Software-Defined Networking''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.<br /> [[Arquivo:Bpf-prog-sdn3.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SDN]]<br /> <br /> ==== SeAC ====<br /> Acrônimo: ''Serviço de Acesso Condicionado''.<br /> <br /> ==== SFI ====<br /> Acrônimo: ''Settlement-free Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão onde nenhuma das partes paga a outra pela troca de tráfego entre ambas.<br /> <br /> ==== SFP ====<br /> Acrônimo: ''Small Form Factor Pluggable''.<br /> <br /> ==== Segment Routing (SR) ====<br /> <br /> ==== Segment Routing v6 (SRv6) ====<br /> <br /> ==== SGSN ====<br /> Acrônimo: ''Serving GPRS Support Node''.<br /> <br /> ==== STFC ====<br /> Acrônimo: ''Serviço Telefônico Fixo Comutado''.<br /> <br /> ==== SMP ====<br /> <br /> ==== SNMP ====<br /> Acrônimo: ''Simple Network Management Protocol''.<br /> [[Arquivo:Bpf-protecao-roteadores-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SNMP]]<br /> <br /> ==== SSH ====<br /> Acrônimo: ''Secure Shell''.<br /> <br /> ==== Switch ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== SyncE ====<br /> Acrônimo: ''Synchronous Ethernet''.<br /> <br /> O SyncE é uma das quatro soluções de ''timing'' sobre redes de transmissão baseadas em pacotes, juntamente com o ''Precision Time Protocol'' (PTP), ''Network Time Protocol'' (NTP) e ''Timing over IP Connection and Transfer of Clock BOF'' (TICTOC). O SyncE é ao mesmo tempo um protocolo e um método de sincronismo para instruções de ''timing'' operando diretamente sobre o Ethernet, ou seja, sem o envolvimento de protocolos de camadas superiores (ex: IP, UDP ou TCP), e possui um procedimento que remonta ao que as redes SDH fazem. O SyncE é utilizado especialmente para o sincronismo de frequência, sendo inclusive muito preciso quanto a isto, mas não provê sincronismo de data e hora, pois este tipo de distribuição de informação (data/hora) precisa ou deve ser feita por outro protocolo (ex: NTP ou PTP). Diversos padrões regem o SyncE, dentre eles o ITU-T G.8261, G.8262, G.8264 e G.781. Em termos de eficácia, o SyncE é a referência de frequência mais estável e a mais precisa disponível atualmente, após as opções por PRC, BITS e GPS, e operadores de telefonia móvel estão avançando no suporte ao SyncE em suas redes como medida de redução de custos e sem o comprometimento da qualidade, ou seja, evitando instalações de GPS em cada estação da rede móvel.<br /> <br /> ==== TACACS+ ====<br /> Acrônimo: ''Terminal Access Controller Access-Control System Plus''.<br /> <br /> ==== Telnet ====<br /> <br /> ==== Trânsito ====<br /> <br /> ==== uRPF ====<br /> Acrônimo: ''Unicast Reverse Path Forwarding''.<br /> <br /> O ''Unicast Reverse Path Forwarding'' (uRPF) é um recurso disponível no software dos roteadores que é utilizado primariamente como mecanismo de &quot;antispoofing&quot;, ou seja, serve para a validação do endereço IP de origem sobre os pacotes recebidos nas interfaces do roteadores. A outra funcionalidade do uRPF é atuar como mecanismo de prevenção de ''routing loops'', em especial em situações relacionadas ao IP Multicasting. No que concerne ao mecanismo de &quot;antispoofing&quot; de endereços IP de origem em tráfego unicast em si, o uRPF é a ferramenta mais indicada para ser adotada nas interfaces que apontam diretamente para as conexões do cone de clientes (downstreams) do provedor de acesso à Internet (ISP), sendo ali o ponto correto de posicionamento e configuração deste mecanismo. Quanto as razões para a utilização do uRPF, o principal e mais forte argumento é a eliminação ou redução dos vetores de ataques DDoS, pois, para que este tipo de ataque possa ser bem sucedido, torna-se necessário que os hosts infectados (&quot;zumbis&quot;), que, neste caso, seriam os clientes do seu ISP, e de outros ISPs também, controlados por uma botnet, encaminhem pacotes com endereços IP de origem &quot;spoofados&quot; (forjados) para que aparentem terem sido enviados a partir do host ou rede que será a vítima deste ataque (cujo seu(s) endereço(s) IP foi (foram) forjado(s)/spoofado(s) por dezenas de milhares de outros hosts na Internet), o que promoverá, consequentemente, e infelizmente, o êxito deste ataque DDoS. Ou seja, sem o spoofing de endereços IP de origem, conceber ataques DDoS na Internet fica uma tarefa praticamente impossível - ou até que outras formas de ataques de negação de serviço sejam idealizadas pelos malfeitores da Internet. Por estas e outras razões que o &quot;Antispoofing&quot;, que inclusive é um dos objetivos estipulados pelo ''Mutually Agreed Norms for Routing Security'' (MANRS), deve ser projetado e configurado corretamente em todas as interfaces que admitem os clientes de um ISP, ou seja, em todo o seu &quot;downstream&quot;. Se todos os ISPs fizessem isso, simplesmente não haveria ataques DDoS na Internet. Ou pelo menos não nos moldes em que estes ataques são concebidos atualmente. Há algumas formas ou modalidades de implementação do uRPF, sendo eles o &quot;''Strict''&quot;, &quot;''Feasible''&quot; e &quot;''Loose''&quot;. Alternativamente ao uRPF, há outras ferramentas que podem ser consideradas para este propósito de antispoofing, incluindo Access Control Lists e IP Source Guard, mas, no caso de service providers / ISPs, o uRPF é o mecanismo mais indicado. Faça a sua parte e contribua para uma Internet mais segura: siga as recomendações do BCP 38 (''Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing''), que é citado no objetivo &quot;Antispoofing&quot; do MANRS, e ajude a reduzirmos substancialmente os ataques DDoS que assolam a Internet!<br /> <br /> ==== VPLS ====<br /> Acrônimo: ''Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. <br /> [[Arquivo:Bpf-enciclopedia-vpls.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN multiponto (VPLS)]]<br /> <br /> ==== VPNv4 ====<br /> Acrônimo: ''Virtual Private Network version 4''.<br /> <br /> O VPNv4 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv4 é definido como uma extensão para o suporte mulitprotocolo do BGP (&lt;nowiki&gt;RFC 4364&lt;/nowiki&gt; e &lt;nowiki&gt;RFC 4659&lt;/nowiki&gt;), e é representado pelo ''Address Family Identifiers'' (AFI) número 1 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. O endereço VPNv4 possui 96 bits de comprimento, sendo 64 bits composto pelo ''Route Distinguisher'' e os 32 bits restantes sendo o prefixo IPv4 da rota original (ex: envidada do roteador CE para o roteador PE, antes da conversão desta rota IPv4 unicast para uma rota VPNv4 pelo roteador PE). Roteadores ''Provider Edge'' (PE) de um backbone de operadora de telecomunicações ou ISP são configurados para trocar rotas VPNv4 através de sessões MP-BGP entre si, as quais são devidamente estabelecidas sobre uma rede MPLS para viabilizar a comunicação entre os sites participantes de uma determinada VPN, usando outros atributos associados aos anúncios destas rotas VPNv4 (ex: extended communities denominadas ''Route Targets'', dentre outros parâmetros e atributos).<br /> <br /> ==== VPNv6 ====<br /> Acrônimo: ''Virtual Private Network version 6''.<br /> <br /> O VPNv6 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv6 é representado pelo ''Address Family Identifiers'' (AFI) número 2 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. Um endereço VPNv6 possui 64 bits de comprimento, sendo 8 octetos o &quot;''Route Distinguisher''&quot; e 16 octetos o endereço IPv6 unicast. À exemplo do VPNv4, o VPNv6 é trocado entre roteadores PE com o auxílio do protocolo BGP (MP-BGP) para o estabelecimento de L3VPN MPLS funcionais com o IPv6 dos sites atendidos/conectados. Para estas L3VPN com IPv6, as sessões IBGP entre os roteadores PE participantes poderá ser feita em IPv4 ou IPv6, e a codificação do atributo NEXT_HOP será distinta para cada caso (&quot;''BGP speaker requesting IPv6 transport''&quot; ou &quot;''BGP speaker requesting IPv4 transport''&quot;). Sobre a codificação do atributo Next Hop, um draft recente está propondo a modificação de alguns destes procedimentos (draft-litkowski-bess-vpnv4-ipv6-nh-handling-00).<br /> <br /> ==== VPWS ====<br /> Acrônimo: ''Virtual Private Wire Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços ponto-a-ponto, ou seja, onde envolve-se apenas dois sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. As diferenças principais entre o VPLS e o VPWS é que, no caso do VPWS, não há aprendizado de endereços MAC, e a solução comporta-se como um ''clear channel'' mesmo.<br /> [[Arquivo:Bpf-enciclopedia-vpws.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN ponto-a-ponto (VPWS)]]<br /> <br /> ==== VxLAN ====<br /> Acrônimo: ''Virtual Extensible LAN''.<br /> <br /> Historicamente a segmentação de uma rede L2 tradicional tem sido fornecida por VLANs padronizadas conforme o IEEE 802.1Q, onde VLANs são criadas e distribuídas nos switches da rede para fornecer a segmentação lógica desejada para as funções de camada 2 em seus domínios de broadcast. No entanto, devido ao uso ineficiente dos links de rede disponíveis com o uso de VLAN, aos requisitos rígidos de posicionamento de dispositivos em redes de missão crítica como datacenters, e à escalabilidade limitada a um máximo de 4094 VLANs, o uso de VLANs tornou-se um fator limitante para muitas redes e de diversas empresas, especialmente data centers e provedores de acesso à Internet. Os ISPs já possuem uma solução baseada no Flexible VLAN Tagging ou Ethernet Flow Point em combinação com soluções L2VPN clássicas, mas este tipo de solução não atende os requisitos de conectividade com alta densidade e elasticidade de multitenantes. Alguns fabricantes líderes de mercado, incluindo a Cisco, Cumulus Networks, Arista, Broadcom, VMware, Intel e Red Hat, uniram-se para propor ao IETF uma solução para sanear os desafios de rede L2 mencionados previamente, e daí surgiu o VXLAN. O VXLAN fornece o posicionamento elástico da carga de trabalho (workload) e maior escalabilidade da segmentação da Camada 2, exigidas pelas demandas de aplicativos atuais, provendo os mesmos serviços Ethernet / camada 2 que VLANs demandam nos dias atuais, só que com maior extensibilidade, flexibilidade e escalabilidade. Em termos mais técnicos, o VXLAN é um esquema de sobreposição (overlay) da camada 2 em uma rede da camada 3. A tecnologia usa o encapsulamento MAC-in-User Datagram Protocol (MAC-in-UDP) para fornecer um meio de estender os segmentos da Camada 2 através da rede do data center, compondo uma solução formidável para oferecer suporte a um ambiente multitenant flexível e em larga escala através de uma infraestrutura física comum compartilhada. O protocolo de transporte na rede física do datacenter inclui o IP e o UDP. Para este procedimento, o VXLAN define um esquema de encapsulamento MAC-in-UDP em que o quadro original da camada 2 possui um cabeçalho VXLAN adicionado e é então colocado em um pacote UDP-IP. Com esse encapsulamento MAC-in-UDP, o VXLAN encapsula a rede da Camada 2 pela rede da Camada 3, fazendo as extensões desejadas das VLANs através da rede, mas, no entanto, sem incorrer nas mesmas limitações de flexibilidade, escalabilidade e diâmetro das redes L2 tradicionais.<br /> <br /> === Desciclopédia ===<br /> <br /> ==== Ajuste Fino ====<br /> Ajuste Fino descreve medidas paliativas ou &quot;''worarounds''&quot; para a superação de deficiências e limitações apresentadas ou impostas por algumas plataformas de equipamentos quando falham ao cumprir com as diretivas e configurações definidas pelos administradores, e cujas as falhas geralmente são acompanhadas de sentimentos de bastante frustração. Para exemplificar um dos tantos casos aqui, há um bocado de relatos onde um equipamento, que supostamente deveria possuir um bom suporte ao protocolo de roteamento BGP, com tabelas de Internet completas (full routes), &quot;trava&quot; rotineiramente ao apresentar ciclos de processamento elevados, bastando que apenas um de seus muitos núcleos disponíveis para esta finalidade fique engargalado para que o referido problema seja notado, consequentemente exigindo a reinicialização (&quot;reboot&quot;) do equipamento para a restauração da normalidade. Para mitigar este problema, dois argumentos possíveis são praticados pelos consultores: a) &quot;''você que não sabe configurar''&quot;, ou seja, na prática, como a quantidade de casos é um tanto grande, entendemos, portanto, que ninguém sabe configurar. b) &quot;''isto é fácil, é só mexer aqui, aqui, aqui e ali, e fazer isso, que você não terá mais o problema''&quot;. O argumento &quot;b&quot; é o que chamamos de Ajuste Fino. Quais tipos de manobras são consideradas ajuste finos? Vejamos: agendamento de reinicialização ou boot automático em intervalos periódicos, podendo ser diário ou semanal + upgrade de memória + publicação das full routes em uma VRF + balanceamento do tráfego através de múltiplos dispositivos, visando diminuir a carga + deixar na tabela principal apenas a rota padrão. Na verdade, fica até complicado definir os ajustes finos, pois são segredos comerciais guardados a sete chaves! O termo acabou generalizando e atualmente todo o workaround empregado para fugirmos de alguma restrição tecnológica ou de algum bug de software é chamado de &quot;Ajuste Fino&quot;, e isto independente do fabricante, modelo e marca do equipamento. Ajuste Fino pode ser considerado um workaround ou gambiarra para qualquer situação onde você teve que fazer algumas manobras esquisitas e fora do que usualmente precisamos fazer para as coisas funcionarem conforme &quot;by the books&quot;.<br /> [[Arquivo:Bpf-desc-ajustefino.png|centro|miniaturadaimagem|494x494px|Ajuste Fino!]]<br /> <br /> ==== Balance Soma-Link ====<br /> Clássica gambiarra que predominou em muitos ISPs pequenos e por muitos anos. A estratégia consistia em contratar dezenas de links banda larga ADSL para desempenharem a função de Trânsito IP do provedor, e fazer uma configuração com roteadores Mikrotik ou de classe similar para executar o balanceamento do tráfego através destas conexões, e sob o pretexto de que este tipo de &quot;solução&quot; somava a capacidade dos links e ainda por cima promovia uma distribuição simétrica ou bem uniforme do tráfego. Alguns consultores, por falta de opções ou recursos, ou despreparados tecnicamente, ou, em alguns casos, malandros mesmo, militavam abertamente nas redes sociais sobre estas façanhas. Desnecessário comentar aqui que tal gambiarra é completamente equivocada nos pontos de vista legal e ético, além de tecnicamente bastante frágil. Felizmente caiu em desuso, mas ainda assim é possível encontrar estas maluquices por aí. Nem o próprio MacGyver, ícone do famoso seriado dos anos 80, especializado em promover gambiarras incríveis para todo e qualquer tipo de situação, teria sido tão &quot;genial&quot; quanto os malandros que inventaram o &quot;Balance Soma-Link&quot;! A diferença é que as gambiarras do MacGyver funcionam e são quase sempre éticas, já essa gambiarra aí...<br /> [[Arquivo:Bpf-desc-loadbalance.png|centro|miniaturadaimagem|600x600px|Gambiarra do Balance Soma-Link]]<br /> <br /> ==== Bridge Roteada ====<br /> <br /> ==== Hiluxer ====<br /> Hiluxer é como são chamados os donos de ISPs que preferem investir em conforto pessoal do que em seus próprios negócios. O &quot;X&quot; da questão não está no fato do dono do ISP querer e poder usufruir daquilo que construiu, ou seja, de ter os seus &quot;mimos&quot;, usufruir de sua riqueza e de prover conforto para si e para seus familiares, e sim na forma em que ele negligencia o seu próprio empreendimento. É óbvio que o dono do ISP pode e deve usufruir de tudo aquilo que ele conseguiu conquistar com o sucesso de seu negócio! O problema é que alguns donos de ISPs não fazem a menor idéia do quão necessário é manter a regularidade de investimentos para a engenharia e a operação de redes de um ISP, por mais que sejam... donos de um ISP! Para estes indivíduos, para tudo há uma solução mais simples: investimentos orientados às necessidades de curto prazo apenas (desprezando o longo prazo), soluções minimalistas e centradas no fator de menor custo. O Hiluxer quer fornecer um serviço de primeira qualidade, mas com processos e investimentos de &lt;u&gt;''quinta categoria''&lt;/u&gt;!<br /> <br /> Os Hiluxers não compreendem alguns fundamentos importantes para a sustentação do próprio negócio, tais como a gestão da cadeia de fornecedores, engenharia e operação de redes (desempenho, disponibilidade, confiabilidade, resiliência, escalabilidade, matriz funcional de qualidade, usabilidade, gerenciamento, segurança, QoE, etc.), além de roadmap de produto, marketing, vendas, logística, atendimento a clientes, e tantos outros. Quando confrontado por times internos (por exemplo, colaboradores da área técnica) para que sejam tomadas decisões importantes para uma questão tecnológica ou desafio operacional da empresa, o Hiluxer interfere de forma improdutiva e frequentemente desviando da solução ou mitigação ideal para sanear o problema ou desafio exposto. Os colaboradores da área técnica de um ISP &quot;Hiluxer&quot; tem que se virar como podem para manter a parte técnica da empresa funcionando, usando todo o tipo de artifício e gambiarra que puderem. <br /> <br /> Mas, no entanto, na hora de comprar a nova versão do Hilux... o referido indivíduo não pensa duas vezes, e parte para visitar a concessionária! Isto é real!<br /> [[Arquivo:Bpf-desc-hiluxer.jpg|centro|miniaturadaimagem|600x600px|Desciclopédia: Toyota Hilux GR Sport - um carro top, sem dúvidas!]]<br /> <br /> ==== IP Confinado ====<br /> Conheça mais: [[CDN Peering e PNI - Brasil|https://wiki.brasilpeeringforum.org/w/CDN_Peering_e_PNI_-_Brasil]]<br /> <br /> O &quot;IP Confinado&quot; é um produto ofertado por alguns provedores com a proposta de fornecer conteúdo de &quot;CDNs apenas&quot; para clientes interessados neste tipo de serviço. O que justifica o &quot;IP Confinado&quot; estar sendo listado em nossa desciclopédia não é a parte técnica da &quot;solução&quot; em si, e sim as diversas violações contratuais associadas com a prática. Muitos destes ISPs promovem algumas práticas que não são permitidas conforme os contratos que são estabelecidos entre ISPs e as detentoras das CDNs. Por exemplo, não é permitido que o ISP mencione que &quot;vende tráfego de CDN&quot;, muito menos destacando ou citando os nomes das empresas/CDNs envolvidas na &quot;oferta&quot;; incorporar logotipos/logomarcas destas empresas em qualquer tipo de propaganda ou material publicitário, expor as fotos dos equipamentos/servidores de CDN implantados em seus data centers, etc. Ou seja, o &quot;IP Confinado&quot; está frequentemente associado a abusos por parte de ISPs, tais como violações de direitos autorais, direitos de propriedade intelectual, direitos de imagem e afins. <br /> <br /> Entenda: é permitido que o ISP venda &quot;implicitamente&quot; o conteúdo de CDNs como parte de uma oferta de &quot;Trânsito IP Parcial&quot; e similares, mas desde que mantendo sob sigilo as informações que possam identificar as empresas que fornecem as CDNs para o ISP. A venda de conteúdo de CDN em si é tida como uma prática ilegal.<br /> [[Arquivo:Ipconfinado.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Confinado]]<br /> <br /> ==== IP Ilegal ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Puro ====<br /> O &quot;IP Puro&quot; nada mais é que uma proposta de fornecimento de um serviço de trânsito para um cliente-ISP final e que exclua deste link todo o tráfego de CDNs que por ventura estiver presente na infraestrutura do ISP contratado, muitas das vezes até mesmo excluindo tráfego originado de sessões de peering privado (PNI). Ou seja, tráfego exclusivamente obtido por upstreams de trânsito IP. Muitos ISPs contam com infraestruturas de CDNs em seus ambientes, juntamente com as sessões de trânsito IP com seus upstreams e também os pontos de troca de tráfego, sejam estes privativos, compartilhados ou bilaterais. Quando um ISP contrata um serviço de trânsito IP junto a outro ISP, neste link escoará todo o tipo de tráfego que existir na infraestrutura do ISP contratado, ou seja, tráfego proveniente dos peerings (ex: IX.br, PNI com Google, Facebook, etc.), trânsito (os upstreams daquele ISP contratado), e, claro, o tráfego das CDNs que existirem no ISP contratado. <br /> <br /> O que alguns ISPs-clientes fazem é exigir que o tráfego destas CDNs (e de peerings também, em muitos casos) não seja fornecido no link de trânsito IP contratado. As discussões acerca deste tipo de necessidade um tanto curiosa ou inusitada são tantas as vezes que um produto denominado &quot;IP Puro&quot; acaba sendo informalmente definido entre os participantes do meio. As vantagens e benefícios alegados por alguns são bastante questionáveis, pois entendemos que o ISP-cliente tem muito mais a perder do que a ganhar com esta preferência. O &quot;IP Puro&quot; é um exemplo clássico de nossa Desciclopédia!<br /> [[Arquivo:Ippuro.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Puro]]<br /> <br /> ==== IP Real ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Válido ====<br /> Endereços IP &quot;válidos&quot;, na mente de muitos profissionais da área, são aqueles endereços IP cuja conectividade com a Internet é plenamente funcional, justamente por não estarem contidos nas faixas especificadas pelo &lt;nowiki&gt;RFC 1918&lt;/nowiki&gt; (''Address Allocation for Private Internets'') ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt; (''IANA-Reserved IPv4 Prefix for Shared Address Space''). Ou seja, a verdade é que IP válido é qualquer endereço IP que não seja privativo.<br /> <br /> Na verdade, todo endereço IP é válido! O correto seria diferenciar o endereço IP em &quot;público&quot; e &quot;privado&quot;, e não em válido ou inválido (quando o endereço for privativo). <br /> [[Arquivo:Bpf-desc-ipvalido.png|centro|miniaturadaimagem|421x421px|Desciclopédia: o que seria um IP &quot;inválido&quot;...]]<br /> <br /> ==== IX Confinado ====<br /> <br /> ==== Link Dedicado Full Duplex ====<br /> <br /> ==== Link Semi-Dedicado ====<br /> O &quot;Link Semi-Dedicado&quot; é algo que expressa muito bem a cultura do brasileiro! Para resumir ou antecipar aqui, isto é basicamente uma gambiarra comercial.<br /> <br /> Para explicar isto melhor, vejamos o serviço de um link dedicado. Serviços de links dedicados são e devem ser tipicamente fornecidos através de uma infraestrutura Metro Ethernet, a qual disponibiliza recursos mais exclusivos e dedicados para o assinante/cliente, tais como uma porta dedicada em um switch Metro para aquele cliente, o enlace da fibra óptica é dedicado na última milha para a conexão do equipamento CPE/CE do cliente, a banda contratada é absolutamente simétrica e pode ser ajustada para até a capacidade máxima suportada pela porta (ex: 200 Mbps sobre porta 1 Gbps, 500 Mbps sobre porta 1 Gbps, ou 1 Gbps direto na porta). Ou seja, um Link Dedicado reúne componentes e arranjos tecnológicos mais caros e especializados para maximizar a experiência do cliente quanto à contratação do serviço. Novamente, é uma tecnologia mais cara, mas o cliente que contrata este serviço sabe exatamente o que e por que está contratando.<br /> <br /> Por outro lado, temos as tecnologias de Internet banda larga, inicialmente lá atrás com tecnologias baseadas no DSL (empregando DSLAMs e/ou MSANs, por exemplo), e nos últimos anos, o FTTH com xPON (principalmente o GPON), que operam especialmente sobre uma rede de acesso completamente compartilhada e com banda assimétrica Up e Down para as taxas mais elevadas.<br /> <br /> O GPON todos nós sabemos que é uma rede óptica passiva de natureza compartilhada, e toda a infraestrutura GPON é indiscutivelmente mais barata que uma rede Metro Ethernet; a diferença é muito expressiva neste sentido. Enquanto isto, é de amplo conhecimento que serviços de Internet banda larga são bem mais baratos (e viáveis para muitas pequenas empresas) que serviços de Internet com link dedicado, certo?<br /> <br /> O que alguns ISPs fazem, inclusive isto começou com um grande operador de redes: o &quot;meio-termo&quot;. Basicamente estas empresas tem vendido links de Internet banda larga com taxas um pouco mais elevadas, mas compatíveis com a característica assimétrica do projeto da rede GPON para a região onde o cliente está localizado, e suprimem, na cara de pau, o termo &quot;banda larga&quot;, usando o termo &quot;dedicado ou semi-dedicado&quot; para promover ou fornecer o serviço. Nada contra o GPON, muito pelo contrário! É uma tecnologia que permitiu baratear bastante os custos de construção de redes e a difundir melhor a Internet banda larga para muitos segmentos de pequenos negócios. Quando confrontados por clientes na questão de simetria da banda, os consultores do ISP procuram &quot;driblar&quot;, evitando mencionar que a rede é compartilhada (e que tem essa questão de restrições envolvendo a simetria Up e Down), e, quando sofrem o ultimato, informam que o serviço é &quot;Semi Dedicado&quot; (ou seja, nunca fazem menção ao aspecto compartilhado ou ao próprio GPON).<br /> <br /> Uma gambiarra estritamente comercial! É que nem você falar que mora num bairro adjacente ao seu, ao invés de citar o nome real conforme o seu CEP, porque seu bairro tem uma má fama. Ou que nem você ter vergonha de assumir a sua namoradinha(o) em público!<br /> [[Arquivo:Bpf-enciclopedia-semidedicado.jpg|centro|miniaturadaimagem|500x500px|Desciclopédia: Link Semi-Dedicado]]<br /> <br /> ==== Lupebequi ====<br /> <br /> ==== Rota Presa ====<br /> O termo &quot;rota presa&quot; ganhou tração há alguns anos, juntamente com o impulsionamento do crescimento de provedores de acesso à Internet de pequeno porte. Na ocasião, muitos ISPs de pequeno porte, a maioria destes, na verdade, contavam com classes de equipamentos roteadores equipados com arquiteturas de processamento de pacotes baseadas em software, especialmente aqueles que implementavam mecanismos de ''route cache''. Com o crescimento da empresa no que diz respeito à base de assinantes, consumo de recursos de rede (banda, enlaces de trânsito IP, sessões, traduções de endereços, etc.), diversos ISPs passaram a experimentar rotineiramente problemas com o BGP, em particular com rotas ficando &quot;presas&quot; na tabela BGP e/ou RIB, mesmo com a sessão BGP correspondente ao recebimento daquelas rotas estando indisponível. Como as situações reportadas por profissionais e consultores da área eram um tanto frequentes, o termo &quot;Rota Presa&quot; acabou generalizando e tornando-se versátil para descrever o óbvio: para tudo há limites. Mesmo que um equipamento ''soft router'', e que implemente ''route cache'', possa ser bastante atraente na relação custo x benefício, e ser capaz de agregar muitos recursos e facilidades interessantes, uma arquitetura de roteamento baseada em processamento de pacotes por interrupções de software, nestas características, frequentemente possui problemas de escalabilidade, dentre outros problemas. Na medida em que aumenta-se o consumo de recursos de rede (banda, sessões, traduções simultâneas de NAT, etc.), o processamento será aumentado proporcionalmente. Até que isto comece a provocar problemas de desempenho e outros incidentes. Isto porque a combinação de classe de hardware de alguns equipamentos conhecidos do mercado, e a arquitetura de soft router com route cache, possui limitações nas questões de desempenho e escalabilidade, algo que é igualmente e rotineiramente negligenciado por ISPs e consultores. Mesmo após esta constatação, muitos ISPs continuavam apostando nesta abordagem em termos de arquitetura de roteador para a função de borda, ou seja, postergando o inevitável: já estava na hora de migrar aquela arquitetura para plataformas mais especializadas para esta missão.<br /> <br /> O interessante é que há uma relação muito íntima entre a &quot;Rota Presa&quot; e o &quot;Ajuste Fino&quot;! Para alguns, o problema de &quot;rotas presas&quot; e sintomas similares somente pode ser saneado com a migração de arquitetura (trocando o roteador), enquanto, para outros, especialmente os &quot;magos da telecom&quot;, o problema de &quot;rota presa&quot; é provocado pela incompetência de quem configura o equipamento, pois basta o sujeito executar alguns procedimentos secretos (&quot;Ajuste Fino&quot;) para que este problema não ocorra. :-)<br /> [[Arquivo:Bpf-desc-rotapresa.png|centro|miniaturadaimagem|518x518px|Desciclopédia: Rota Presa<br /> <br /> Fonte: Consultores da Depressão]]<br /> <br /> ==== SkyGato ====<br /> <br /> ==== Terraplanistas da Telecom ====<br /> O que seriam &quot;terraplanistas da telecom&quot;? Analogia aos terraplanistas &quot;originais&quot;: indivíduos que se acham superiores a gerações inteiras de verdadeiros gênios inspiradores, dos quais incluo aqui Eratóstenes, Galileo Galilei, Isaac Newton, Albert Einstein, Johannes Kepler, Arthur Eddington, Edwin Powell Hubble, Milton L. Humason, Tycho Brahe, Michael Faraday, Stephen Hawking, Steven Weinberg, James Clerk Maxwell, Peter Higgs, Edward Witten, Freeman Dyson, Werner Heisenberg, Erwin Schrodinger, Alan Guthm, Ernest Rutherford, Paul Dirac, Niels Bohr.... fora Anaximandro, Arquimedes, e tantos outros, dentre gênios e perseguidos. Todo um esforço gigantesco e desde os tempos mais remotos para que evoluíssemos humana e tecnologicamente e nas áreas de física e astrofísica, construíssemos coisas incríveis, compreendêssemos o universo próximo, mesmo que faltando ainda tantas perguntas sem respostas, para termos uma classe de indivíduos em franca expansão (&quot;terraplanistas&quot;) usando a tecnologia, todo o aparato tecnológico à seu favor para, nas redes sociais, bradarem aos 4 ventos: &quot;A TERRA É PLANA!&quot;. Surreal!<br /> <br /> Na mesma moeda, analogias aqui, os &quot;''terraplanistas da telecom''&quot; são aqueles indivíduos que atuam na área e que tentam refutar o irrefutável. Literalmente '''''&lt;u&gt;rasgam&lt;/u&gt;''''' RFCs, BCOPs, padrões/standards, e frameworks. Não somente isto: acidentalmente ou propositalmente quase que rasgam também os trabalhos dos &quot;gênios da nossa área&quot;; Radia Joy Perlman, John Moy, Yakov Rekhter, Kirk Lougheed, Vint Cerf, Robert Kahn, Robert Metcalfe, David Boggs, W. David Sincoskie, Ali Sajassi, dentre tantos caras que criaram tudo o que usamos nas redes hoje, fora os grupos de trabalho incluindo IETF, IEEE, IANA, RIPE, NIC.br, LACNOG, NANOG, GPF, e, porque não, as recomendações do BPF, e o escambáu. As BCOPs e RFC são literalmente '''&lt;u&gt;nada&lt;/u&gt;''' para alguns destes indivíduos (sim, eu atestei isto! Eu li e conferi isso numa discussão!). O que um Job Snijders falaria no ouvido desses caras, entraria por um lado e sairia pelo outro!<br /> <br /> Parece exagero, mas tem surgido uma classe de indivíduos que tenta refutar uma diversidade de fatos irrefutáveis sobre as características, disponibilidades e aplicabilidades de tecnologias associadas à redes, telecomunicações no geral; a Internet. Dentre os absurdos que vemos por aí, temos: &quot;''é mentira que o IPv4 está se esgotando!''&quot;, &quot;''o OSPF está morrendo!''&quot;, &quot;''operadoras estão deixando de usar o MPLS''&quot;, &quot;''a navegação por IPv6 prejudica a performance da minha Internet&quot;'', &quot;''não preciso implantar o IPv6, porque o IPv6 ainda não é usado&quot;'', ''&quot;blackhole é mitigação de DDoS''&quot;, &quot;''trânsito sem PTT é melhor''&quot;, &quot;''existe trânsito IP puro''&quot;, &quot;''sessão de peering com IX Europeu melhora a performance porque a lista de AS_PATH é menor''&quot;, dentre outras coisas engraçadas. Note que não são apenas &quot;opiniões&quot;: essas situações fazem parte de recomendações de fato que os &quot;terraplanistas da telecom&quot; promovem!<br /> <br /> O meu termo aqui de &quot;terraplanistas da telecom&quot; não faz julgamento de quanto o indivíduo sabe ou não sabe sobre estas tecnologias. Realmente não compete a mim julgar o nível de conhecimento de qualquer um que seja, e isto está absolutamente fora de questão. O que me cabe a fazer, obviamente, é questionar porque eles falam mal de certas coisas que eles mesmos não compreendem ou dominam? Não seria mais prudente pesquisar, informar-se, praticar, exercitar, questionar, etc., a ponto do indivíduo ser fluente o suficiente nesse ou naquele tema (protocolo, tecnologias), antes de tentar influenciar as outras pessoas?<br /> <br /> Uma coisa é você falar que não sabe ou não domina uma tecnologia, por isso que você não a quer ou prefere evitá-la. Uma coisa é você falar que determinada tecnologia não é compatível com os seus planos e pelas razões X, Y e Z. Em ambos os exemplos, argumentos e justificativas válidos. Agora, falar que &quot;''é mentira que o IPv4 está se esgotando''&quot; e coisas deste tipo é um verdadeiro desserviço para a comunidade!<br /> [[Arquivo:Bpf-enciclopedia-terraplanistas.png|centro|miniaturadaimagem|600x600px|Desciclopédia: terraplanistas da telecom]]<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Geral]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Enciclopedia_e_desciclopedia_da_telecom&diff=2523 2020-06-15T20:56:12Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Enciclopédia e &quot;Desciclopédia&quot; da Telecom ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Este artigo sofrerá adições de termos, acrônimos e expressões, um tanto frequentemente! Será a nossa Enciclopédia para descrever e, sempre que possível, exemplificar cada um dos termos usados pelas empresas e profissionais das áreas de telecomunicações e redes! Da mesma forma, este artigo fornecerá, e buscará deixar destacado, juntamente a cada termo, onde aplicável, uma &quot;Desciclopédia&quot; (nada melhor que uma dose de humor, certo?) para comentar situações que são verdadeiras gambiarras encontradas no setor de telecomunicações. <br /> <br /> A Enciclopédia reúne as expressões legítimas e corretas. Já a Desciclopédia, reúne situações um tanto controversas que surgiram na cabeça altamente criativa dos profissionais da área; as gambiarras! <br /> <br /> OBS: a prioridade de edição do artigo será o fornecimento das explicações referentes aos termos e, em segundo momento, a inclusão de algum tipo de exemplo ou referência. Se algum termo não contiver um exemplo ou uma referência, simplesmente aguarde, pois isto será realizado posteriormente. <br /> <br /> Desde já, solicito para que você siga acompanhando os trabalhos do '''''Brasil Peering Forum (BPF)''''', faça o bom e sensato uso de boas práticas, e diga não às gambiarras!<br /> [[Arquivo:Bpf-enciclopedia-cover.png|centro|miniaturadaimagem|700x700px]]<br /> <br /> ==== Como consultar este artigo ou buscar os termos e expressões desejadas ====<br /> Para este procedimento, sugiro:<br /> * Todos os acrônimos, termos ou expressões estão listados em ordem alfabética. Você poderá navegar pelo índice remissivo, clicar no acrônimo ou termo desejado, e ser direcionado diretamente para ele. Ou;<br /> * Faça uma pesquisa diretamente através de seu navegador (ex: CTRL-F)!<br /> Aprecie sem moderação!<br /> <br /> === Enciclopédia ===<br /> <br /> ==== 6PE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS (6PE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6PE é um cenário de transição para a adoção do roteamento IPv6 onde, no Core do operador da rede (ISP), não há endereçamento IPv6 (ainda), e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. Para maior eficiência, flexibilidade, e redução de custos, o 6PE pode ser projetado em um ambiente de backone (Core) isento de BGP, num cenário denominado &quot;''6PE com BGP-Free Core''&quot; mas, no entanto, são coisas distintas, e uma coisa não depende da outra, embora a combinação de ambas as estratégias tende a agregar muitos benefícios.<br /> [[Arquivo:Bpf-enciclopedia-6pe.png|centro|miniaturadaimagem|600x600px|Enciclopedia: 6PE]]<br /> <br /> ==== 6VPE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS VPN (6VPE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6VPE é um cenário de transição para a adoção do roteamento IPv6 na relação entre o ISP e clientes corporativos de serviços L3VPN MPLS, onde, no Core do operador da rede (ISP), não há endereçamento IPv6, e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. A diferença primária entre o 6PE e o 6VPE é que o 6PE lida com o roteamento IPv6 unicast sobre uma infraestrutura de backbone IPv4 em uma rede MPLS, enquanto o 6VPE lida com a troca de prefixos IPv6 unicast sobre uma infraestrutura L3VPN MPLS com sessões IBGP em IPv4 e com o suporte VPNv6 entre os roteadores PE. O BGP-Free Core não é um requisito para 6VPE ou 6PE, mas poderá agregar maior flexibilidade e promover redução de custos para o operador de redes.<br /> [[Arquivo:Bpf-enciclopedia-6vpe.png|centro|miniaturadaimagem|600x600px|Enciclopédia: 6VPE]]<br /> <br /> ==== AAA ====<br /> Acrônimo: ''Authentication, Authorization, Accounting''.<br /> <br /> O AAA pode ser tratado como um framework ou um conjunto de especificações tecnológicas e recursos para a concepção de mecanismos mais seguros visando a admissão de usuários e endpoints (dispositivos) em uma rede. O AAA, além de representar um conjunto de procedimentos, é usado geralmente em combinação com protocolos e serviços tais como RADIUS, TACACS+ e Diameter. Como o próprio nome sugere, a proposta é a de fornecer métodos seguros visando a autenticação de usuário e/ou dispositivo (ex: computador, roteador CPE, ou outro tipo de dispositivo), a posterior autorização, o que, por sua vez, ditará propriedades para o acesso concedido, tais como a atribuição dinâmica de VLAN, uma ACL dinâmica, um ''Scalable Group Tag'' (SGT), atribuição de endereçamento IPv4 e IPv6 (muito comum no caso do PPPoE), dentre uma diversidade de outras variáveis que podem ser associadas ao usuário e/ou ao seu dispositivo. E, por último, a manutenção de registros de atividades para fins de auditoria daquele acesso, ou seja, o ''Accounting''.<br /> <br /> &lt;u&gt;Exemplos de cenários onde o AAA é empregado:&lt;/u&gt; controle de acesso centralizado aos equipamentos da rede por parte de operadores/administradores, e com autorização e registros de comandos na CLI, autenticação de portas de switches com o protocolo 802.1X (conhecido também como solução IBNS), controle de acesso e admissão à rede (uma evolução do IBNS conhecida por ''Network Access Control'' (NAC)), autenticação de assinantes PPPoE e IPoE em concentradores de serviços de Internet banda larga (BNG/BRAS), autenticação de usuários e dispositivos móveis em redes WLAN, dentre outros casos.<br /> <br /> ==== Access-List ====<br /> Uma Lista de Acesso (Access-List ou ACL) é uma ferramenta absolutamente versátil disponível em roteadores e switches, e também em outros tipos de equipamentos de redes, e que tem como principal proposta a de atuar como mecanismo de classificação de pacotes ou, alternativamente, em muitos casos, para classificação de rotas. Após a classificação de pacotes ou de rotas, dependendo de como e para que uma ACL estiver sendo utilizada, uma ação pode ser vinculada para o pacote ou para a rota, e conforme diretivas imputadas pelo administrador da rede.<br /> <br /> &lt;u&gt;Exemplos de cenários onde uma ACL é empregada:&lt;/u&gt; filtro ''stateless'' de pacotes (''stateless packet filtering''), filtro ''stateful'' de pacotes (''stateful packet filtering'', quando a ACL é vinculada em um roteador com suporte a firewall stateful), classificação de tráfego que deverá ou não sofrer tradução de endereços IP (em ambiente NAT e CGNAT), classificação de pacotes que deverão sofrer uma política de roteamento diferenciada para encaminhamento de tráfego &quot;bypassando&quot; a tabela de roteamento (uma PBR, ABF, e similares), classificação de pacotes para o posicionamento destes em classes de tráfego e posterior tratamento de qualidade de serviço (QoS), classificação de pacotes autorizados para serviços de gerenciamento do equipamento (acesso remoto à CLI por SSH, acesso remoto ao equipamento via SNMP, NETCONF, etc.), classificação dos pacotes de servidores NTP autorizados a sincronizar data/hora com o seu equipamento, classificação de rotas que deverão ser invocadas por um filtro de rotas ou por uma política de roteamento (para ''accept'' ou ''drop'', com ou sem modificação de atributos), e muitos outros.<br /> <br /> Uma ACL pode ser considerada um verdadeiro &quot;canivete suíço&quot;! No entanto, para algumas necessidades, há ferramentas melhores ou mais versáteis que uma ACL. Por exemplo, uma ''prefix-list'' ou ''prefix-set'' é mais flexível e adequada para filtrar rotas em uma policy de roteamento, do que usar uma ACL para este mesmo propósito.<br /> <br /> ==== AS ====<br /> Acrônimo: ''Autonomous System''.<br /> <br /> Conheça mais: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]].<br /> <br /> Um (o) sistema autônomo representa a coletânea de dispositivos de rede sob uma administração comum, e o termo é geralmente empregado para representar uma rede inteira de uma determinada empresa, seja ela um provedor de acesso à Internet (ISP), uma empresa do segmento corporativo, ou uma instituição qualquer. Em um primeiro momento, o AS tipifica exatamente isto: a &quot;rede&quot; daquela empresa, os seus equipamentos, as suas diretivas e políticas; ou seja, uma coisa mais abstrata. No entanto, algumas tecnologias levam o termo AS para as suas próprias funcionalidades, capacidades e propriedades, dando uma expedição bem mais tangível ao termo, e em sua forma mais prática e real. Uma desta tecnologias é o protocolo de roteamento BGP, como todo profissional de ISP sabe.<br /> <br /> No caso do BGP, o Sistema Autônomo (AS) não é apenas algo teórico, e sim o componente principal e real do próprio protocolo de roteamento. Você, de fato, define/configura o AS no BGP dos seus roteadores, juntamente com uma série de propriedades e parâmetros (tais como sessões, anúncios, filtros, políticas de roteamento, recursos adicionais/periféricos do BGP, etc.) para representar aquela rede e as suas respectivas políticas de roteamento, ou seja, havendo uma relação muito íntima e tangível com esta definição de AS. A Internet é composta por dezenas de milhares de sistemas autônomos, obviamente interconectados pelo protocolo de roteamento BGP.<br /> [[Arquivo:Bpf-enciclopedia-as.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Autonomous System (AS)]]<br /> <br /> ==== BGP ====<br /> Acrônimo: ''Border Gateway Protocol.''<br /> <br /> Conheça mais aqui: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]] e [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O BGP ou BGP-4 é um protocolo de roteamento do tipo vetor de caminhos e exterior (''path vector'' e EGP), e pode ser considerado como a base de todo o roteamento de Internet. Todo o funcionamento da Internet depende da boa operação do BGP e, sem ele, simplesmente não há a Internet. Obviamente que a Internet depende de muito mais coisas que o protocolo de roteamento BGP para funcionar, mas, sem dúvidas, ele é um componente tido como central.<br /> <br /> O protocolo de roteamento BGP tem sofrido muitos aditivos ao longo dos anos, com a adição de novas funcionalidades e recursos, dentre os quais convém destacar aqui o suporte às diversas famílias de endereços, tais como IPv4 Unicast, IPv6 Unicast, IPv4 Multicast, IPv6 Multicast, VPNv4, VPNv6, L2VPN, EVPN, Labeled Unicast, Traffic Engineering, e outros. Confira alguns destes recursos aqui:<br /> * [https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Border Gateway Protocol (BGP) Parameters], [https://www.iana.org/assignments/capability-codes/capability-codes.xhtml Capability Codes], [rfc:7606 Multiprotocol Extensions for BGP-4], [https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml Subsequent Address Family Identifiers (SAFI) Parameters], e há muitos outros.<br /> <br /> ==== BNG ====<br /> Acrônimo: ''Broadband Network Gateway''.<br /> <br /> Conheça mais: [[Concentradores PPPoE com IPv6]].<br /> <br /> O BNG substitui outro nome/termo, mais defasado, chamado BRAS, ou seja, apesar de serem termos intercambiáveis, recomenda-se, nos dias atuais, referenciá-lo como BNG. O BNG é essencialmente uma plataforma de roteamento equipada com funcionalidades, recursos, protocolos e serviços primários e periféricos orientados para a solução de conectividade de Internet banda larga, atendendo primariamente os assinantes residenciais, embora nada impeça que seja utilizado também para produto de Internet banda larga voltada ao segmento corporativo. O roteador BNG atua como dispositivo roteador (gateway) para as sessões autenticadas de usuários mantidas por ele (daí o termo &quot;concentrador BNG&quot;). O BNG é geralmente usado em combinação com outros componentes e procedimentos, sendo alguns destes mandatórios, enquanto outros são opcionais, variando conforme as definições de cada projeto técnico. Exemplos de tecnologias e procedimentos que &quot;casam&quot; com uma solução BNG: RADIUS, Diameter, PPPoE, IPoE, sejam estes arranjados sobre uma rede puramente Metro Ethernet + IP, ou FTTH/GPON + Metro + IP.<br /> <br /> ==== BRAS ====<br /> Acrônimo: ''Broadband Remote Access Server''.<br /> <br /> Vide o acrônimo BNG (Broadband Network Gateway).<br /> <br /> ==== Caches Enter-Deep ou Bring-Home ====<br /> O Enter-Deep Cache possui como estratégia estar profundamente fincado nas redes de acesso dos provedores de acesso à Internet (ISP), geralmente sendo adotados na forma de clusters implantados nas redes do ISP ao redor do mundo. Esta filosofia de cache foi introduzida pela Akamai e é usada por muitas empresas que seguiram na mesma filosofia. In a &quot;nutshell&quot;, e explicando isto de forma bem simplista e minimalista, como a coisa funciona, usando um exemplo simples envolvendo o Google: todos estes inúmeros ou quase incontáveis clusters localizados nas redes dos ISPs e nos data centers desta empresa no mundo compõem uma rede privada do Google. Sendo assim, quando um usuário faz uma requisição ou consulta de pesquisa, esta consulta tende a ser encaminhada primeiramente pelo provedor de acesso (ISP) local para um cache local próximo, de onde deverão sair conteúdos estáticos para o cliente enquanto este cache local, ao mesmo tempo, encaminha uma consulta pela rede privada do Google para um de seus data centers, de onde deverão sair os dados e resultados de pesquisa personalizadas para o cliente. Em um exemplo envolvendo um vídeo do YouTube, este vídeo poderá ser recuperado diretamente do cache local do ISP, se este possuir a arquitetura e se este conteúdo puder ser fornecido das proximidades deste enter-deep cache, enquanto os anúncios associados ao vídeo são recuperados a partir dos data centers do Google. Em geral, os serviços de nuvem do Google são fornecidos por uma infraestrutura de rede privada independente da Internet pública, daí as excepcionais vantagens dos ISPs em poderem contar, quando autorizados e sobre forte regime de contrato e NDA, com estas soluções baseadas enter-deep cache. Ganha o usuário, com acesso com latência mais baixa aos conteúdos, e ganha o ISP, com previsibilidade no tráfego e redução de custos com os enlaces de trânsito IP.<br /> <br /> Já a estratégia Bring Home (&quot;trazer para casa&quot;), é uma segunda filosofia de design adotada por muitas empresas de CDN. A proposta aqui é trazer os ISPs para &quot;casa&quot;, conectando clusters em pontos de presença (PoPs) construídos através de uma rede privada de alta velocidade, ao invés de implantar estes clusters diretamente nas infraestruturas de redes dos ISPs. Estes pontos de presença (PoPs) geralmente ficam mais próximos aos operadores de redes Tier-1, podendo estender-se para além destes em alguns casos. Comparado com o enter-deep cache em termos de filosofia de design, o Bring Home normalmente resulta em menores custos de manutenção, mas é menos interessante no ponto de vista de latência e taxas de transferências de dados para os usuários finais, quando comparando estes benefícios com a filosofia do Enter-Deep cache.<br /> <br /> ==== CDN ====<br /> Acrônimo: ''Content Delivery Network''.<br /> <br /> Conheça mais: [[CDN Peering e PNI - Brasil]].<br /> <br /> Ou Rede de Fornecimento de Conteúdo. Uma CDN é um sistema de servidores amplamente distribuídos que fornece acesso à páginas e à diversos tipos de conteúdos para os usuários da Internet, e com base em uma diversidade de métricas e procedimentos, tais como a geolocalização do assinante/usuário, local de origem dos conteúdos, e centros de distribuição de dados (que hospedam uma CDN) em melhores condições de fornecerem o conteúdo para o usuário requisitante, para citar algumas destas métricas e procedimentos.<br /> <br /> Como principais benefícios, as CDN asseguram menores índices de latência no fornecimento de conteúdo para os usuários requisitantes, um benefício percebido pelos próprios usuários finais, pois estes terão uma melhor experiência de consumo destes conteúdos, e permite excelentes capacidades de engenharia de rede e de tráfego para os serviços de trânsito; melhor cenário financeiro na questão de despesas operacionais de médio e longo prazos, o que seria um ótimo benefício para os ISPs que contarem com as CDNs de diversos fornecedores de conteúdos. Ou seja, ganha o usuário, com maior fluidez e experiência de consumo de conteúdos, e ganha o ISP, com seus clientes mais satisfeitos com a experiência de navegação, além dos resultados com as despesas operacionais de médio e longo prazos.<br /> <br /> ==== CFP ====<br /> Acrônimo: ''C form-factor pluggable (CFP)''.<br /> <br /> O CFP é resultante de um acordo do tipo ''multi-source agreement'' estabelecido entre os principais fabricantes de soluções da indústria para a produção de um transceptor ótico para transmissão de sinais de alta velocidade. O CFP foi desenvolvido primariamente para redes Ethernet em 100 Gbps, operando nas em 10 vias a 10 Gbps em cada sentido (Tx e Rx), ou 4 vias a 25 Gbps, também em cada sentido. As variações existentes:<br /> <br /> &lt;u&gt;CFP&lt;/u&gt; (82 mm × 13.6 mm × 144.8 mm, conexão elétrica de 148 pinos, consumo inferior a 24 W, 10×10G ou 4×25G vias). &lt;u&gt;CFP2&lt;/u&gt; (41.5 mm × 12.4 mm × 107.5 mm, conexão elétrica de 104 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 12 W, 10×10G, 4×25G, 8×25G, ou 8×50G vias, Analog Coherent Optics (ACO)). &lt;u&gt;CFP4&lt;/u&gt; (21.5 mm × 9.5 mm × 92 mm, conexão elétrica de 56 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 6 W, 4×10G ou 4×25G vias). &lt;u&gt;CFP8&lt;/u&gt; (40 mm × 9.5 mm × 102 mm, conexão elétrica de 124 pinos, sem DSP, consumo máximo de 24 W, 16×25G vias (25.78125 ou 26.5625 GBd) ou 8×50G vias). &lt;u&gt;MSA 5″×7″ (Gen 1)&lt;/u&gt; (conexão elétrica de 168 pinos, embarca DSP, consumo inferir a 80 W). &lt;u&gt;MSA 4″×5″ (Gen 2)&lt;/u&gt; (conexão elétrica de 168 pinos, DSP, consumo elétrico inferior a 40 W).<br /> <br /> ==== CGNAT ====<br /> Acrônimo: ''Carrier-Grade Network Address Translation (CGNAT ou CGN).''<br /> <br /> O CGNAT é ao mesmo tempo uma solução e um mal necessário, sempre requerido quando não há endereços IPv4 públicos suficientes para atender toda a base de clientes de um ISP. Em termos mais técnicos, o CGNAT é essencialmente uma tecnologia que realiza a tradução dos endereços IPv4 de origem dos assinantes/clientes/usuários, onde estes são geralmente endereçados com endereços IP da faixa 100.64.0.0/10 ([rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]), e não com os endereços IPv4 privativos previstos pelo RFC 1918, como alguns acreditam, para um endereço IPv4 público. O CGNAT difere da solução NAT tradicional por sofrer algumas modificações para viabilizar a tradução de endereços em larga escala e atendendo, dependendo da plataforma, a dezenas de milhares de usuários, daí o termo &quot;''carrier grade''&quot;. A principal diferença entre CGNAT e NAT é que o CGNAT é configurado para fazer a tradução do endereço IP de origem e respectivas portas usadas na conversação, mas &lt;u&gt;sem&lt;/u&gt; manter quaisquer informações referentes aos endereços IP e portas de destino, sendo isto, inclusive, um dos principais motivos pelos quais o CGNAT escala para milhões de traduções simultâneas de endereços. Há diversas abordagens de CGNAT, tanto ''stateful'' quanto ''stateless'', tais como NAT44, NAT444 / Double NAT 44, em regime determinístico ou pré-definido, ou ainda em alocação de portas em massa (Bulk Port Allocation (BPA)), ou ainda em combinação com técnicas de transição para IPv6 de assinantes com NAT 64SL, NAT64SF, IPv6 Rapid Deployment (6rd), Dual-Stack Lite (DS-Lite), e MAP-T/E<br /> <br /> Como boa prática, o CGNAT não deve substituir a necessidade pela adoção do protocolo IPv6 nas redes dos ISPs. Aliás, inclusive, estimulamos que o IPv6 seja adotado o mais rapidamente possível para a sua infraestrutura ficar cada vez menos refém do CGNAT, pois há limitações e aborrecimentos associados a esta tecnologia. Quanto mais IPv6 você possuir em sua rede, menor será a dependência por CGNAT!<br /> <br /> ==== Control Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Controle. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, que é responsável por hospedar diversos dos protocolos e serviços para funções de redes nas Camadas 2 e 3, assim como as respectivas estruturas de dados mantidas pelos processos de cada um destes protocolos e serviços.<br /> <br /> Exemplos de protocolos que atuam nesta área do equipamento: Spanning Tree Protocol (STP), Resilient Ethernet Protocol (REP), Ethernet Automatic Protection Switching (EAPS), G.8032 Ethernet Ring Protection Switching, Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP), Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP), Resource Reservation Protocol for Traffic Engineering (RSVP-TE), Address Resolution Protocol (ARP), e muitos outros, lembrando que estes protocolos mantém as suas estruturas de dados, tais como LSDB (OSPF), LIB (LDP), BGP Table (BGP), ARP Cache (ARP), etc. A tabela de roteamento, também conhecida por RIB, é mantida no plano de controle dos roteadores.<br /> [[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]<br /> <br /> ==== CPAK ====<br /> <br /> ==== Data Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Dados. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, e que mantém as estruturas de dados relacionadas às ações de processamento de quadros (no L2) e pacotes (no L3). Estruturas de dados tais como a Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), Adjacency Table, Content Addressable Table (CAM ou MAC Table), são exemplos de estruturas de dados mantidas no Data Plane. As arquiteturas modernas de roteadores e switches tendem a combinar múltiplas estruturas de dados primárias e periféricas, geralmente mantidas em componentes de hardware especializados do equipamento, para construir e programar o ''pipeline'' de processamento de pacotes, para que, além da óbvia comutação do quadro ou o roteamento do pacote, outras ações possam ser executadas sobre os pacotes, tais como a determinação se um determinado pacote deverá ser tratado como L2 ou L3, consulta ou lookup de endereços IP, consulta à listas de controle de acesso (ACL), policiamento de taxa, queueing e prioridades, manipulação de cabeçalhos L2 e L3 (marcação, tradução de endereços, operações com tags de VLAN, operações com labels MPLS), etc. Exemplos de estruturas assim são as Ternary Content Addressable Memory (TCAM) e arranjos Tree-Bitmap (TBM) e M-trie.<br /> [[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]<br /> <br /> ==== DDoS ====<br /> Acrônimo: ''Distributed Denial of Service''.<br /> <br /> Conheça mais: [[O Minimo que voce precisa saber sobre DDoS|O Mínimo que você precisa saber sobre DDoS]] e [https://youtu.be/l2tVyz1Ba1A &lt;nowiki&gt;[BPF] Entrevista com o Thiago Ayub sobre ataques e mitigação DDoS&lt;/nowiki&gt;].<br /> <br /> Atividade criminosa que tem por objetivo promover a interrupção das operações de uma infraestrutura de redes através da sua incapacidade de continuidade de prestação dos serviços. Ou seja, como o próprio nome sugere, é um ataque de negação de serviços, porém distribuída, no sentido que milhares de dispositivos na Internet são controlados de forma maliciosa para lançarem ataques contra uma rede. Redes que são vitimadas sofrem dois padrões de distúrbios primários, sendo o primeiro o esgotamento de recursos computacionais dos equipamentos da rede, e, o segundo, a saturação dos enlaces de trânsito IP. Em qualquer uma das circunstâncias, os efeitos são muito negativos e percebidos pelos clientes do ISP afetado pela atividade criminosa. Os motivadores dos ataques de DDoS tem sido cada vez mais preocupantes, e são cada vez mais frequentes as situações envolvendo competidores inescrupulosos de um ISP que está sendo vítima de um ataque, mas há também muitos casos de criminosos que atacam ISPs por &quot;profissão e esporte&quot;, exigindo quantias em - sempre por pagamentos em criptomoedas, tais como o Bitcoin - para encerrar os ataques.<br /> <br /> ==== De-Peering ====<br /> Como o próprio nome sugere, é uma ação de desfeita de peering entre dois participantes ou entre um participante principal e múltiplos (dezenas) de outros participantes. O de-peer significa o encerramento da relação e a respectiva desconexão do acordo de peering entre dois sistemas autônomos. Mesmo que, de certa forma, um tanto raros, as motivações de um &quot;de-peer&quot; ou &quot;de-peering&quot; frequentemente estão associadas a mudanças na política de peering da organização principal, ou quando uma das duas partes envolvidas naquela relação de peering viola algum termo do acordo, algo que costuma promover o que chamamos de &quot;network clean-up&quot;. Algumas situações que tipificam e até mesmo justificam um de-peering: uma das duas partes está recebendo tráfego malicioso (ex: DDoS) excessivamente, e o acordo de peering pode ser interrompido em função disto. Violação da política de roteamento, onde um dos participantes injeta informações errôneas através desta sessão de peering (ex: route leak, hijack de prefixos, e &quot;vacilos&quot; similares), e isto é agravado quando a parte é reincidente, o que poderia justificar o cancelamento do acordo de peering. Mudanças na política de roteamento e peering de um dos participantes, e o entendimento que o referido acordo entre ambas as partes não é mais necessário ou interessante, ou ainda que a outra parte não mais atende os pré-requisitos para a manutenção deste acordo. E, para finalizar, possíveis problemas envolvendo capacidades e custos. Não é a toa que as modalidades de interconexão pagas (paid peering) tem se popularizado, em particular para lidar com as questões de capacidade e custos que em alguns casos poderiam justificar um de-peer de um ou mais participantes.<br /> <br /> ==== EAQ ====<br /> Acrônimo: ''Entidade Aferidora de Qualidade''<br /> <br /> A Entidade Aferidora da Qualidade (EAQ) foi criada em atendimento às Resoluções da Anatel 574 e 575 de 28 de outubro de 2011. A EAQ é parte do processo de aferição dos indicadores de qualidade das redes de telecomunicações que suportam o acesso à internet em Banda Larga fixa e móvel no Brasil, e a seleção desta entidade é feita de forma a garantir o cumprimento do Regulamento de Gestão da Qualidade do Serviço de Comunicação Multimídia - RGQ-SCM, aprovado pela Resolução nº 574, de 28 de outubro de 2011 e do Regulamento de Gestão da Qualidade da Prestação do Serviço Móvel Pessoal - RGQ-SMP, aprovado pela Resolução nº 575, de 28 de outubro de 2011.<br /> <br /> ==== eNodeB ====<br /> O Nó B do E-UTRAN, também conhecido como Evolved Node B ou eNodeB ou eNB, é o elemento no E-UTRA do LTE que é a evolução do elemento Nó B no UTRA do UMTS. É o hardware conectado à rede de telefonia móvel que se comunica diretamente sem fio com os telefones móveis (UEs), como uma estação base de transceptores (BTS) nas redes GSM. Tradicionalmente, um Nó B tem funcionalidade mínima e é controlado por um Radio Network Controller (RNC). No entanto, com um eNB, não há elemento controlador separado. Isso simplifica a arquitetura e permite menores tempos de resposta.<br /> <br /> ==== Ethernet ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O Ethernet é uma arquitetura de interconexão para redes de computadores, originalmente pensada para os ambientes de Redes de Áreas Locais (LAN), pois, naquele tempo, o Ethernet não era funcional para comunicações a longa distância, tais como circuitos de WAN e redes Metropolitanas (MAN). A tecnologia de transmissão do Ethernet é por regime estatístico e baseada no encaminhamento de quadros (''frames''). O Ethernet é especificado para velocidades de operação selecionadas entre 10 Mbps e 400 Gbps, usando uma especificação comum de controle de acesso ao meio físico (''Media Access Control'' ou MAC). O mecanismo de contenção para o compartilhamento do meio físico no Ethernet é feito por um procedimento denominado ''Carrier Sense Multiple Access with Detection Collision Detection'' (CSMA / CD), definindo tanto a operação de mídia compartilhada (half duplex), bem como a operação em full duplex. Ao longo dos anos o Ethernet sofreu vários aditivos para acomodar novas funcionalidades e capacidades, dentre as quais posso destacar aqui os padrões DCBX para o funcionamento do Ethernet em ambientes de Data Center críticos, por exemplo, permitindo transportar o ''Fibre Channel'' diretamente sobre o Ethernet (FCoE), e também os padrões Metro Ethernet / Carrier Ethernet que fizeram com que o Ethernet aos poucos fosse evoluindo e sendo adotado pelos operadores de rede / service providers / ISP, a ponto de hoje ser a tecnologia de enlace predominante neste setor. Os principais atrativos do Ethernet incluem a flexibilidade e excelente relação custo x benefício, especialmente quando comparado às tecnologias de transmissão determinísticas (ex: SDH), sendo este fator econômico o principal motivo quanto a expansão do Ethernet para os ISPs.<br /> <br /> ==== EVPN ====<br /> Acrônimo: ''Ethernet Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> Tecnologia de transporte de serviços de Camada 2 (L2) sobre infraestrutura MPLS ou VxLAN, ou seja, L2VPN, em especial buscando, através da evolução tecnológica e pela qualidade de suas ferramentas, cumprir com os mesmos objetivos da soluções L2VPN MPLS tradicionais, tais como o VPLS, H-VPLS e VPWS, sejam estes em implementação Martini ou Kompella, porém sem incorrer nas mesmas dificuldades e complexidades associadas a estes tecnologias clássicas. Em outras palavras, o EVPN é a legítima evolução da tecnologias L2VPN tradicionais, pois resolve muitos dos conhecidos desafios dos setups típicos de L2VPN. O EVPN tem como principal proposta a implementação de uma diversidade muito ampla de serviços L2 sobre infraestruturas baseadas no IP/MPLS e em regimes ponto-a-ponto e multiponto, sendo ideal para atendermos às demandas por L2VPN dos dias atuais e com maior flexibilidade e elasticidade. Como benefícios, o EVPN não exige um protocolo adicional como ocorre no L2VPN MPLS clássico (em especial a implementação Martini), e também não exige o emprego de Pseudowires. O EVPN usa o MP-BGP (mais precisamente o AFI 25 e SAFI 70) para trocar rotas específicas para esta família de endereços, promove maior eficiência no aprendizado e distribuição de endereços MAC, e com aprendizado destes ocorrendo no plano de controle, e não no plano de dados, permite redundância &quot;''All-Active''&quot;, além de outras interessantíssimas capacidades e recursos.<br /> <br /> ==== FlowSpec ====<br /> Acrônimo: ''BGP Flow Specification''.<br /> <br /> O recurso ou tecnologia BGP ''flow specification'' (flowspec) permite definir procedimentos para codificar regras de especificação de fluxo na forma de BGP ''Network Layer Reachability Information'' (NLRI) que podem ser usadas em diversas situações, sendo que a sua principal proposta é viabilizar o filtro de pacotes com o objetivo de mitigação de ataques de negação de serviços do tipo DDoS. Para se ter uma idéia, nos métodos tradicionais de mitigação de DDoS, como é o caso do RTBH (''Remotely Triggered Black Hole Filtering'' ou &quot;buraco negro disparado remotamente&quot;), uma rota BGP é injetada anunciando o endereço do site sob ataque juntamente com uma community BGP específica para este propósito de proteção. Essa community especial nos roteadores de borda serve para definir o próximo salto para um próximo salto especial - ou seja, uma modificação proposital do atributo &quot;NEXT_HOP&quot; da referida rota BGP - para descartar ou anular pacotes destinados àquele alvo, ou seja, permitindo que o tráfego de ataque destinado ao endereço IP/alvo seja descartado no backbone do ISP. Mesmo que isto permita oferecer boa proteção, a estratégia com o uso do RTBH torna o servidor ou host configurado com aquele endereço IP completamente inacessível. Por outro lado, o BGP flowpecpec permite uma abordagem mais granular e permite ainda que você efetivamente construa instruções para combinar um fluxo específico com a origem, destino, parâmetros L4 e especificações de pacotes, como comprimento, fragmento etc., possibilitando uma instalação dinâmica de uma ação nos roteadores de borda para: a) descartar o tráfego lançado contra o alvo. b) injetar o tráfego em uma VRF específica para uma análise mais detalhada. c) policiamento da taxa deste tráfego identificado pelo flowspec. Portanto, em vez de associar uma rota com uma community especial (RTBH) para que os roteadores de borda façam o descarte &quot;cru e nu&quot; do pacote, o BGP flowspec envia um formato de fluxo específico aos roteadores de borda, instruindo-os a criar uma espécie de ACL para que seja possível construir uma política com uma ação que você desejar (os casos &quot;a&quot;, &quot;b&quot; e &quot;c&quot; citados previamente). Para conseguir isso, o BGP flowspec adiciona um novo NLRI ao protocolo BGP, possibilitando fornecer detalhes sobre especificações de fluxos, critérios de correspondência (&quot;matching&quot;) suportados e ação de filtragem de tráfego.<br /> <br /> O BGP Flowspec é um aditivo muito sofisticado para as intenções dos ISPs na questão de mitigação de ataques DDoS em suas infraestruturas.<br /> <br /> ==== FTTH ====<br /> Acrônimo: ''Fiber-to-the-Home''.<br /> <br /> O &quot;''Fiber To The Home''&quot; (FTTH), também chamado de &quot;''Fiber To The Premises''&quot; (FTTP) ou ''&quot;Fiber To The Building''&quot; (FTTB), é o conceito de projeto, instalação o uso de fibra ópticas a partir de um ponto central diretamente para edifícios individuais, como residências, edifícios de apartamentos e empresas, para fornecer acesso à Internet em alta velocidade. O ''Fiber to the Home'' (FTTH) em si é um tipo de rede de acesso que oferece a alta velocidade de conexão à Internet, usando fibra óptica que é executada diretamente na casa, no prédio ou no escritório do assinante/cliente. O FTTH oferece aos consumidores acesso a uma grande variedade de aplicativos interativos, como comunicação por vídeo, jogos, vídeo sob demanda, teletrabalho e eSaúde, dentre uma diversidade muito grande aplicações que são possíveis com o uso de uma rede relativamente muito simples, porém bastante efetiva, e com ótima relação custo/benefício.<br /> <br /> ==== GGSN ====<br /> Acrônimo: ''Gateway GPRS Support Node''.<br /> <br /> O ''Gateway GPRS Support Node'' (GGSN) é um dos dois componentes do domínio ''Packet-Switched'' (PS) ''General Packet Radio Services'' (GPRS). O GGSN, juntamente com o SGSN (''Serving GPRS Support Node'', que entrega pacotes de dados de e para as estações móveis dentro de sua área de serviço), lida com transmissões de pacotes entre a rede GPRS e redes externas de baseadas em comutação de pacotes, como a Internet ou até mesmo de infraestruturas mais legadas baseadas em pacotes, como é o caso de uma rede X.25. Do ponto de vista de uma rede externa, o GGSN é um roteador para uma subrede, porque o GGSN acaba por &quot;ocultar&quot; a infraestrutura GPRS da rede externa. Quando o GGSN recebe dados endereçados a um usuário específico, verifica se o usuário está ativo. Caso afirmativo, o GGSN encaminha os dados para o SGSN que atende o usuário móvel, mas, caso o usuário móvel estiver inativo, os dados serão descartados. Na outra direção, os pacotes de origem móvel são roteados para a rede correta pelo GGSN, que é o ponto de ancoragem que permite a mobilidade do terminal do usuário nas redes GPRS / UMTS, onde, essencialmente, ele desempenha o papel no GPRS equivalente ao agente doméstico no IP móvel, e mantém o roteamento necessário para encapsular as unidades de dados de protocolo (PDUs) para o SGSN que atende uma determinada estação móvel (MS).<br /> <br /> ==== GPON ====<br /> Acrônimo: ''Gigabit Passive Optical Network''.<br /> <br /> ==== H-VPLS ====<br /> Acrônimo: ''Hierarchical Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN MPLS orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. A diferença primária entre H-VPLS e VPLS é que o H-VPLS procura promover uma hierarquia para o estabelecimento dos pseudowires e a efetiva troca de tráfego L2 entre os sites participantes, e com o objetivo de aprimoramos a escalabilidade e a eficiência da solução VPLS. Um dos maiores benefícios do H-VPLS é a redução do overhead de sinalização e também dos requerimentos de replicação de pacotes sobre os roteadores provider edge (PE). No H-VPLS, dois tipos de dispositivos PE são definidos: o u-PE e n-PE. O u-PE recebe o tráfego L2 nativo do cliente e faz as funções L2 locais, agrega o tráfego e o encaminha até o roteador n-PE, que é onde, de fato, ocorre o encaminhamento do tráfego pelo VPLS e com base no ''Virtual Switching Instance'' (VSI).<br /> <br /> ==== Hub-and-Spoke ====<br /> <br /> ==== IPFIX ====<br /> Acrônimo: ''Internet Protocol Flow Information Export''.<br /> <br /> O ''IP Flow Information Export'' (IPFIX), é um protocolo que especifica um método para que engenheiros de redes consigam exportar dados analíticos referentes aos fluxos de tráfego que percorrem em suas redes ou sistemas autônomos para estações coletoras, devidamente equipadas com soluções específicas baseadas em software, para fins de compreenderem com clareza as matrizes de comunicação referentes aos endereços IP de origem, endereços IP de destino, ordenamento de protocolos detectados ou registrados nestas conversações, portas de origem e destino (para o caso de TCP e UDP), marcações de QoS indicadas (ex: DSCP), sistemas autônomos envolvidos, volumetria destes fluxos que representam estas conversações, &quot;''top talkers''&quot;, dentre outros dados extremamente úteis. O IPFIX é um protocolo de padrão aberto que visa promover maior flexibilidade se comparado ao NetFlow da Cisco, seja na versão &quot;10&quot;, 9 ou 5, ao Juniper JFLOW, que é bastante similar ao NetFlow v5 da Cisco, e ao CFLOW. Comparativamente, o IPFIX contém os mesmos 79 campos do NetFlow v9, mas vai além e acomoda até 238 campos, o que possibilita uma lista bastante extensa de informações para atender a muitas das necessidades dos engenheiros de redes, e estando um passo à frente para inovações futuras. Assim como NetFlow/CFLOW/JFLOW, o IPFIX tem como proposta primária auxiliar profissionais de redes e empresas no planejamento de capacidades, bilhetagem e tarifação de tráfego, detecção e prevenção de incidentes de segurança, resposta automática a ataques de negação de serviço com acionamento de RTBH, dentre outras conhecidas aplicações. Vide &lt;nowiki&gt;RFC 7011&lt;/nowiki&gt; (''Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information'') para maiores informações.<br /> <br /> ==== IPoE ====<br /> Acrônimo: ''IP over Ethernet.''<br /> <br /> O ''Internet Protocol (IP) over Ethernet'' (IPoE) é uma das soluções adotadas para a disseminação do produto de Internet banda larga nas redes dos provedores de acesso à Internet. É basicamente uma forma de fornecer tráfego de Internet banda larga sem o encapsulamento PPP sobre o Ethernet. Atualmente, a tecnologia predominante para a autenticação e autorização de assinantes de Internet banda larga é o ''Point-to-Point Protocol over Ethernet'' (PPPoE), que, apesar de estar presente na grande maioria das instalações, possui alguns desafios e diversas limitações. O IPoE entra nesta seara justamente para substituir o PPPoE nos concentradores de assinantes (conhecidos por plataformas BNG ou BRAS), ou seja, para conquistarmos maior flexibilidade com a oferta de serviços para os assinantes sem incorrermos nos problemas e desafios associados ao uso massivo do PPPoE nestes equipamentos concentradores, dentre outras características, vantagens e benefícios. Dentre as principais vantagens em substituir o PPPoE pelo IPoE está na eliminação de um protocolo específico para o procedimento (PPP), consequentemente havendo uma redução bastante satisfatória do processamento dos equipamentos concentradores, pois, um dos principais &quot;problemas&quot; do PPPoE é que este introduz um cabeçalho adicional de 8 bytes de comprimento para cada pacote entre o dispositivo CPE/CE (assinante) e o concentrador onde a sessão do usuário foi autenticada e está estabelecida. E os concentradores de assinantes precisam manter o estado destas sessões para realizar diversos procedimentos para a manutenção do serviço do assinante. Outro &quot;problema&quot; do PPPoE está em sua dificuldade em lidar eficientemente com o tráfego Multicast, sendo que este problema não está presente o IPoE, o que pode ser um fator determinante para optar pelo IPoE para assinantes de Internet banda larga com o produto IPTV. O IPoE não é o &quot;the new kid on the block&quot;, e está por aí desde os primórdios do &lt;nowiki&gt;RFC 894&lt;/nowiki&gt;, sendo inclusive suportado há muitos anos pelos principais produtos concentradores do mercado.<br /> <br /> ==== IPv4 ====<br /> Acrônimo: ''Internet Protocol version 4''.<br /> <br /> ==== IPv6 ====<br /> Acrônimo: ''Internet Protocol version 6''.<br /> <br /> ==== IRR ====<br /> Acrônimo: ''Internet Routing Registry''.<br /> <br /> O ''Internet Routing Registry'' (IRR) é um banco de dados que possui objetos inseridos e mantidos através de uma linguagem própria denominada ''Routing Policy Specification Language'' (RPSL). Estas construções RPSL são expressas em diversos tipos de objetos dos bancos de dados que estão registrados em Registros Regionais da Internet (RIRs), os quais podem ser consultados pelo serviço Whois. Cada tipo de objeto de uma base de dados IRR pode representar um determinado tipo de informação, tal como um prefixo de propriedade ou alocado para um ISP, um objeto que divulgue a sua política de roteamento, ou um objeto que represente informações de contato administrativo e de suporte técnico, dentre outros tipos de objetos. O uso correto dos recursos de uma base IRR é amplamente estimulado entre os provedores de acesso à Internet para que cada um publique corretamente os seus prefixos (a título de objetos &quot;''route''&quot; e &quot;''route6''&quot;), os seus grupos representando, cada qual, seus upstreams de trânsito, peerings, e cones de clientes (por meios de objetos &quot;''as-set''&quot;), a divulgação da intenção em termos de política de roteamento (por meios de objetos &quot;''aut-num''&quot;, com campos &quot;''import''&quot;, &quot;''export''&quot;, &quot;''mp-import''&quot; e &quot;''mp-export''&quot;), além de objetos representando ações administrativas, tais como pessoal de contato para suporte (objetos &quot;''person''&quot; e &quot;''role''&quot;). A manutenção dos objetos em uma base IRR por um ISP é fundamental para que haja um consenso na Internet sobre como os filtros de anúncios devem ser construídos pelos Sistemas Autônomos, assim como fornecer a devida visibilidade para o acionamento dos times de suporte quando problemas ocorrerem com o roteamento de Internet envolvendo um determinado Sistema Autônomo. O ''Mutually Agreed Norms for Routing Security'' (MANRS) inclusive estabelece como dois dos seus principais objetivos a &quot;Coordenação&quot; e &quot;Validação Global&quot; entre os ISPs, cujas as ações são bastante centradas nos registros de objetos nas bases de dados de IRR, e com a divulgação do objeto &quot;''as-set''&quot; principal do ASN em seu cadastro no site PeeringDB. É importante salientar que muitos ISPs produzem filtros automaticamente com base nos registros de um sistema autônomo especificados numa base conhecida de IRR, daí a importância em certificar-se que o seu AS tenha os dados corretos inseridos na base de dados de um IRR, pois, a qualquer momento, algum ISP upstream poderá simplesmente recusar o recebimento de anúncios que tiverem sido originados no seu ASN, justamente por não haver consistência destas informações nos registros de uma base IRR.<br /> <br /> ==== IRU ====<br /> Acrônimo: ''Indefeasible Right of Use''.<br /> <br /> O direito de uso indefiável (IRU) é um tipo de contrato permanente de locação de telecomunicações, que não pode ser desfeito, entre os proprietários de um sistema de comunicações e um cliente desse sistema. A palavra &quot;indefiável&quot; significa &quot;incapaz de ser anulado ou desfeito&quot;. O IRU é o arrendamento efetivo de longo prazo (propriedade temporária) de uma parte da capacidade de um cabo submarino ou de outra infraestrutura de telecomunicações. Um exemplo deste tipo de arrendamento seria um IRU especificando um determinado número de canais de uma determinada largura de banda por um período bastante prolongado de uso. Neste caso, o IRU é concedido pela empresa ou consórcio de empresas que construíram o cabo, oferecendo a um provedor de serviços de Internet a capacidade de garantir à seus próprios clientes o trânsito internacional sobre este referido cabo, na capacidade assegurada pelo IRU, e por um período de prazo bastante prolongado.<br /> <br /> ==== IX ====<br /> Acrônimo: ''Internet Exchange''.<br /> <br /> Vide Ponto de Troca de Tráfego (PTT).<br /> <br /> ==== Jitter ====<br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> <br /> O jitter é a variação de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das &quot;especificações biológicas&quot; (auditivas e/ou visuais) do ser humano, que é o indivíduo que está interagindo com a aplicação através da rede com transmissões com níveis de jitter acima dos padrões aceitáveis.<br /> [[Arquivo:Bpf-qos-6.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Jitter]]<br /> <br /> ==== L2VPN ====<br /> Acrônimo: ''Layer 2 Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> O ''Layer 2 Virtual Private Network'' (L2VPN) consiste em um conceito que representa um conjunto de tecnologias orientadas ao transporte de serviços L2 sobre uma infraestrutura baseada no IP, com ou sem o auxílio do MPLS. Enquadram-se neste caso as tecnologias que obviamente exigem o MPLS para operar, como é o caso do ''Virtual Private LAN Service'' (VPLS), para a construção e transporte de redes L2 em regime multiponto, e o ''Virtual Private Wire Service'' (VPWS), para a construção e transporte de redes L2 em regime ponto-a-ponto, sendo que ambos operam sobre uma infraestrutura MPLS.<br /> <br /> Tecnologias de &quot;''tunneling''&quot; não deixam de ser também soluções de L2VPN, pelo menos no que diz respeito à privacidade e a segregação de serviços L2 de assinantes distintos sobre uma rede IP. Outro exemplo clássico de solução para este propósito é o ''Virtual Extensible LAN'' (VxLAN), muito utilizado em ambientes de data center como cenário centrado na elasticidade de domínios L2 e excelente mobilidade de workloads/VMs. E também, mais recentemente, a evolução das soluções L2VPN tradicionais para o ''Ethernet VPN'' (EVPN).<br /> <br /> No entanto, quando utilizando o termo &quot;L2VPN&quot;, estamos quase sempre nos referindo aos clássicos modelos VPLS e VPWS empregados nas redes MPLS dos operadores de rede, e estes serviços são provisionados com o auxílio de ''pseudowires'' com o protocolo LDP em vizinhança direcionada (T-LDP) entre os roteadores participantes de um determinado serviço, o que seria a proposta de implementação ''Martini'', ou então com o protocolo BGP, para a descoberta de vizinhos e também para o procedimento de sinalização, o que seria a proposta de implementação ''Kompella''.<br /> <br /> O principal objetivo da L2VPN é viabilizar o transporte de serviços L2, primariamente o Ethernet, através de uma rede completamente baseada no IP+MPLS, e sem que seja necessário estender as VLANs destes clientes atendidos através do backbone do operador de redes ou ISP. Ganha-se muito na questão operacional, além de aprimoramentos de indicadores importantes tais como a escalabilidade, confiabilidade, resiliência e melhor facilidade para o provisionamento e manutenção destes serviços. Os operadores de redes encontram no L2VPN uma forma bem adequada de fornecer serviços atraentes para seus clientes, tais como LAN-to-LAN, ''Data Center Interconnect'', &quot;''Clear Channel''&quot;, dentre outros, sem incorrer nas complexidades e riscos associados ao emprego das tecnologias L2 básicas em suas infraestruturas, tais como o entroncamento excessivo de VLANs de clientes nos uplinks do backbone, no provisionamento e manutenção de instâncias de protocolos de resiliência L2 (que são pouco escaláveis e um tanto inseguros em redes grandes), os riscos eminentes de ocorrerem ''bridging loops'' em função das extensões destas VLANs de clientes e respectivos protocolos de resiliência L2 no backbone do ISP, dentre outros argumentos muito sólidos.<br /> <br /> As L2VPNs podem ser utilizadas também para o transporte de tecnologias legadas sobre uma infraestrutura IP+MPLS, conforme tipificado pela solução ''Any Transport over MPLS'' (AToM) como um todo, permitindo, além do próprio Ethernet, o transporte de redes ''Asynchronous Transfer Mode'' (ATM), ''Frame Relay'', enlaces ponto a ponto ''High-Level Data Link Control'' (HDLC) e ''Point-to-Point Protocol'' (PPP), e até mesmo de outras tecnologias de transmissão digital, porém de natureza determinística (e não estatística, como seria o caso do Ethernet e do IP!), tais como ''Plesiochronous Digital Hierarchy'' (PDH) e ''Synchronous Digital Hierarchy'' (SDH)! Ou seja, soluções tais como o HDLCoMPLS, PPPoMPLS, FRoMPLS, CESoPSN, SAToP, TDMoIP, procedimentos GFP + LCAS + VCAT, etc. Para entender melhor estes casos, um tanto atípicos para os dias atuais, consulte o RFC 3985 (''Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture'') e outros RFCs. <br /> [[Arquivo:Bpf-enciclopedia-l2vpn.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN]]<br /> <br /> ==== L3VPN ====<br /> Acrônimo: ''Layer 3 Virtual Private Network''.<br /> <br /> ==== Latência ====<br /> Latência de rede é o termo usado para indicar qualquer tipo de atraso que ocorra na comunicação de dados em uma rede. As conexões de rede nas quais ocorrem pequenos atrasos são chamadas de redes de baixa latência, enquanto as conexões de rede que sofrem de longos atrasos são chamadas de redes de alta latência. A alta latência cria gargalos em qualquer comunicação de rede e impede que os dados tirem proveito máximo do canal de rede, diminuindo efetivamente a largura de banda de comunicação, além de apresentae aquela sensação de &quot;rede lenta&quot;. O impacto da latência na largura de banda da rede pode ser temporário ou persistente, com base na origem destes atrasos. Em termos práticos, a latência pode ser definida pelo tempo que leva para uma solicitação viajar do remetente para o destinatário e para o destinatário processar essa solicitação e fornecer a resposta para o remetente. Em outras palavras, o tempo de ida e volta do seu navegador para um servidor. Obviamente, é desejável que esse tempo permaneça o mais próximo possível de 0, no entanto, pode haver muitas coisas em jogo para impedir que os tempos de latência de um determinado serviço permaneçam baixos. Diversos elementos fatoram para o aumento da latência, dentre eles os atrasos de natureza fixa (serialização, transmissão e propagação) e os de natureza variável (processamento e enfileiramento/queueing), sendo que todos estes atrasos são adicionados por cada elemento de rede ativo que existir no caminho entre o cliente e o servidor. A latência pode e deve ser objeto de estudos e trabalhos de reestruturações tanto do aparato tecnológico em si (categoria dos elementos ativos, tais como roteadores, switches e concentradores) quanto das ações de engenharia de rede (organização topológica, emprego efetivo de recursos nos locais certos, etc.) e engenharia de tráfego (políticas consistentes de QoS, engenharia de tráfego MPLS, engenharia de tráfego do BGP, escolha e aquisição de enlaces com latências reportadas mais baixas, etc.). Em uma rede Ethernet, IP ou MPLS, a latência sempre existirá; é inevitável. O seu trabalho deverá saber projetar a rede, escolher bem seus componentes e dimensionar adequadamente seus recursos para que os índices de latência não sejam percebidos ou prejudiciais para a experiência de navegação e usabilidade de seus clientes.<br /> [[Arquivo:Bpf-qos-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: latência]]<br /> <br /> ==== MPLS ====<br /> Acrônimo: ''Multiprotocol Label Switching''.<br /> <br /> Conheça mais: [[Redes MPLS para Provedores]].<br /> <br /> Tecnologia de encaminhamento de pacotes cujas as operações não envolvem a consulta do cabeçalho IP. Numa rede completamente MPLS, o objetivo é fazer com que as consultas para a determinação de caminhos e o efetivo encaminhamento de pacotes ocorram por meios de instruções e operações mais simplificadas, denominadas &quot;''labels''&quot;, os quais são especificados em cabeçalhos enxutos chamados de &quot;''shim header''&quot;, e em três simples operações: imposição (push), troca (swap), e disposição (pop). O MPLS surgiu inicialmente como tecnologia visando atenuar o processamento dos roteadores de backbone dos grandes operadores de redes, pois as operações com ''labels'' tinham como apelo serem mais simplificadas e desprenderem menos esforços computacionais do que as operações com os cabeçalhos IP. Atualmente este argumento, ou motivador inicial quanto ao surgimento do MPLS, é praticamente nulo, em função da sofisticação das arquiteturas de roteadores dos dias atuais, pois os novos processadores conseguem sustentar ótimas taxas de encaminhamento de pacotes e independentemente se estes possuem ''labels'' ou não, e com múltiplos serviços concorrentes. No entanto, o MPLS como um todo evoluiu muito, e uma gama de funcionalidades excepcionais foram agregadas para rodar no topo das infraestruturas MPLS, obviamente exigindo o ''label switching'' para isto, assegurando qualidade, flexibilidade e elasticidade para quase tudo o que temos de bom nas infraestruturas de redes dos ISPs. Exemplos de soluções que rodam e/ou que dependem do MPLS para funcionar incluem L3VPN MPLS, L2VPN MPLS, MPLS TE, MPLS QoS, GMPLS. Algumas destas tecnologias que rodam no topo do MPLS surgiram para resolver problemas bastante conhecidos existentes em ambientes legados, tais como escalabilidade, confiabilidade, convergência e afins (ex: L2VPN MPLS visando sanear os desafios das redes L2 clássicas; MPLS TE visando resolver os desafios de engenharia de tráfego IP, etc.), e isto ao mesmo tempo em que outros conceitos foram surgindo para fomentar ainda mais a escalabilidade, flexibilidade e redução de custos (BGP-Free Core, 6PE/6VPE, e Unified MPLS são exemplos clássicos). O MPLS pode ser considerado como um marco, um verdadeiro divisor de águas, para todo o segmento de telecomunicações.<br /> <br /> ==== MPLS Traffic Engineering ====<br /> Conheça mais: [[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]].<br /> <br /> O MPLS-TE é uma solução que embarca duas propostas principais: a) engenharia de tráfego, b) proteção e recuperação contra falhas de enlaces e roteadores. Embora frequentemente combinado com os projetos MPLS clássicos (sem TE), o MPLS-TE não depende dos procedimentos do MPLS LDP. Para a parte de engenharia de tráfego, o MPLS-TE propõe-se a sanar algumas deficiências que são inerentes do próprio roteamento IP, os quais incluem congestionamentos decorrentes do mapeamento ineficiente dos fluxos de tráfego sobre os recursos da rede (interfaces, enlaces e roteadores), e fazendo isso com um bom arranjo de ferramentas que permite flexibilidade para a manipulação dos fluxos de tráfego através da rede do ISP e sem que isto exija modificações complexas nas propriedades do roteamento IP, tais como distância administrativa e métricas de rotas IGP, políticas de roteamento no backbone, rotas estáticas e afins. Já para a questão da rápida recuperação de falhas, o MPLS-TE fornece um recurso denominado Fast Reroute (FRR), o qual, através de uma estratégia conhecida por &quot;''Make-before-Break''&quot;, viabiliza a construção de LSPs de contingência para pronto uso em caso de falhas do next hop ou do nexto hop do next hop, promovendo índices de recuperação de falhas aproximados em 50 milissegundos.<br /> <br /> ==== Multi-CDN ====<br /> <br /> ==== Multi-tenant ====<br /> <br /> ==== NAT ====<br /> Acrônimo: ''Network Address Translation''.<br /> <br /> Tecnologia que realiza a tradução de endereços IP especificados nos cabeçalho IP dos pacotes em trânsito em um roteador. O NAT foi concebido originalmente como uma das iniciativas de soluções para conter o &quot;desmatamento&quot; do endereçamento IPv4, ou seja, sendo usado para conter ou desacelerar o rápido esgotamento da disponibilidade de endereços IP públicos. Há muitos anos iniciativas tais como o ''Classless Interdomain Routing'' (CIDR), ''Variable Length Subnet Masking'' (VLSM), endereçamento IPv4 privativo (IANA RFC 1918 [rfc:1918 - Address Allocation for Private Internets]), e ''Network Address Translation'' (NAT) foram introduzidas nos conceitos de projetos de redes para que tivéssemos a sobrevida do espaço de endereços IPv4 públicos até os dias atuais. Estima-se que, sem estas iniciativas, o esgotamento destes endereços teria ocorrido há muito tempo. Falando especificamente de NAT, esta solução anda lado a lado, como &quot;unha e carne&quot;, com os endereços IP privativos. Redes corporativas e domésticas/residenciais inteiras são endereçadas com endereços IP privativos (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16), e não há rotas no backbone da Internet para estes prefixos. Para que um usuário portando um endereço IP privativo destes possa navegar pela Internet, torna-se necessário realizar a tradução de seu endereço IP de origem para um endereço IP público disponível através desta configuração de NAT. Há vários tipos de cenários envolvendo o NAT, tais como o NAT dinâmico (numa relação ''one-to-one''), o ''Port Address Translation'' (também dinâmico, mas numa relação ''many-to-one''), NAT estático (relação 1:1) e NAT estático por portas (relação 1:1 com portas), sendo que o PAT ou &quot;''masquerading''&quot; é um dos cenários mais amplamente difundidos. Para os ISPs ou operadores de rede, no que diz respeito à conectividade de Internet de assinantes residenciais com endereços IPv4, no entanto, não utiliza-se o NAT &quot;convencional&quot;, e sim uma extensão funcional denominada ''Carrier Grade NAT'' (CGN ou CGNAT), já citada em nossa Enciclopédia, em combinação com outra faixa de endereços IPv4 privativos, a 100.64.0.0/10 (conforme [rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]). Para finalizar, entenda que o NAT pode ser usado também para a tradução de endereços IP de destino, mas fica à critério de cada projeto técnico e de suas particularidades.<br /> <br /> ==== NETCONF/Yang ====<br /> Acrônimo: ''Network Configuration''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no &lt;nowiki&gt;RFC 6241&lt;/nowiki&gt;. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações. Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração &quot;na mão&quot;. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, &quot;automatizados&quot;, é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho. O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, e é tido por muitos como a melhor interface southbound para ambientes de orquestração atualmente.<br /> <br /> O YANG por sua vez é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.<br /> <br /> ==== NetFlow ====<br /> A tecnologia como um todo é composta por caches de fluxo, coletores de fluxo e analisadores de dados. O NetFlow, quando foi criado há muitos anos, surgiu inicialmente como uma proposta para ''switching path'', mas rapidamente evoluiu para aquilo que muitos dos profissionais de redes compreendem sobre ele. O NetFlow é atualmente e há muitos anos uma tecnologia que visa fornecer excepcional visibilidade na rede e em resposta aos constantemente evoluídos requisitos para que os operadores de redes saibam como as suas redes estão se comportando, e fornecendo respostas para situações tais como: mapa de uso de aplicativos e redes, produtividade e utilização de recursos de rede, impacto das alterações na rede, detecção de anomalias na rede, assim como a identificação de vulnerabilidades de segurança, e problemas de conformidade a longo prazo. Para estas e outras necessidades, os engenheiros de redes passam a possuir ferramentas para entender quem, o que, quando, onde e como o tráfego da rede está fluindo, fomentando melhor entendimento sobre como as tecnologias empregadas na rede estão funcionando em alinhamento com os negócios da empresa; trilha de auditoria de como a rede é utilizada, aumento da conscientização quanto aos investimentos e uso da rede como um todo, redução de vulnerabilidades da rede, redução dos índices de downtime e distúrbios gerais, redução de custos, etc. O NetFlow pode ser usado como uma ferramenta &quot;simples&quot; para o gerenciamento de performance da rede, ou para situações bem mais ousadas, incluindo ações de planejamento de capacidades, engenharia de rede, engenharia de tráfego, bilhetagem e tarifação de tráfego, e detecção e mitigação de malware e de ataques DDoS sobre a rede, para citar alguns casos. Em termos práticos, o NetFlow é configurado em roteadores e switches, onde estiver disponível/suportado, podendo ser customizável em alguns casos, e, após isto, o equipamento exportará os bilhetes de fluxos de tráfego por NetFlow até uma estação coletora, a qual processará e consumirá estes dados, de acordo com os exemplos de soluções e casos citados anteriormente, e podendo interagir de volta com a rede para que ações sejam executadas pelos dispositivos da rede.<br /> <br /> O NetFlow é um protocolo proprietário da Cisco, mas que está disponível em outros fabricantes do mercado. O seu equivalente em termos de padrão aberto é o protocolo ''Internet Protocol Flow Information eXport'' (IPFIX).<br /> <br /> ==== NFV ====<br /> Acrônimo: ''Network Functions Virtualization''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware &quot;''commodity''&quot;. Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado. Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. <br /> <br /> ==== NodeB ====<br /> Um Node B é um termo para denotar uma estação base na terminologia WCDMA/UMTS, e é responsável pelo enlace de rádio entre o usuário da rede móvel e a parte fixa da rede ''UMTS Terrestrial Radio Access Network'' (UTRAN), conforme definido pelo 3GPP, ou seja, fornecendo a cobertura de rádio e conversão de dados entre esta rede de rádio e os ''Radio Network Controllers'' (RNCs).<br /> <br /> ==== OM ====<br /> OM1 - <br /> <br /> OM2 - 62,5/125 microns<br /> <br /> OM4 - 50/125 microns<br /> <br /> ==== Open/R ====<br /> (IGP virtualizado)<br /> <br /> ==== OSPF ====<br /> Acrônimo: ''Open Shortest Path First''.<br /> <br /> Conheça mais: [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas práticas para a implantação do OSPF em ambientes de ISP]]<br /> <br /> Protocolo de roteamento dinâmico do tipo interior e por definição de estado de enlaces (Link-State). O OSPF é um dos principais componentes das infraestruturas de redes dos provedores de acesso à Internet, sendo indispensável para viabilizar o roteamento necessário para o transporte das sessões BGP, resolução de roteamento recursivo referente ao atributo NEXT_HOP das rotas BGP mantidas nos Sistema Autônomo do ISP, além de atuar também para funções de roteamento de alguns serviços internos específicos do ISP. Muito frequentemente o OSPF é utilizado, também, em alinhamento com a tecnologia para fins de engenharia de tráfego com o MPLS TE, sendo, neste caso, inclusive, um componente obrigatório para este tipo de projeto. O OSPF destaca-se pela eficiência nas ações de rápida convergência, rápida recuperação de falhas e escalabilidade. Alternativamente ao OSPF, os operadores de redes podem optar pelo protocolo de roteamento IS-IS.<br /> <br /> ==== PCC ====<br /> Acrônimo: ''Path Computation Client.'' <br /> <br /> O PCC é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), o próprio cliente PCC (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCE ====<br /> Acrônimo: ''Path Computation Element''.<br /> <br /> O PCE é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCEP ====<br /> Acrônimo: ''Path Computation Element Communication Protocol''.<br /> <br /> O PCEP é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client'' (PCC)), o próprio protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)). O novo paradigma de redes programáveis orientadas a aplicações foi o que impulsionou as extensões PCEP, as quais possuem definições nos ''drafts draft-ietf-pce-stateful-pce'', ''draft-crabbe-pce-pce-initiated-lsp'', ''draft-ali-pce-remote-initiated-gmpls-lsp'', e outros.<br /> <br /> ==== Peering ====<br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Peering ou Troca de tráfego é uma relação comercial e técnica entre duas redes. É um acordo em que as redes admitem trocar tráfego entre os clientes uns dos outros, desde que o relacionamento seja '''mutuamente benéfico''', e nem sempre os acordos são isentos de custo ou trocas comerciais. Para garantir que cada lado do acordo tenha benefícios similares, as redes podem precisar atender aos requisitos pré-definidos para serem elegíveis. Por exemplo, uma rede pode precisar manter uma certa proporção de troca de tráfego, presença geográfica ou capacidade de backbone. A implantação real dessas relações de Peering, geralmente ocorre em locais comuns, como os NAPs e IXs estabelecidos pelo mundo (''Public'' Peering), ou através de links dedicados pagos pelas redes envolvidas (PNI-''Private network Interconnect'').<br /> <br /> ==== PGW ====<br /> Acrônimo: ''Packet Data Network Gateway''.<br /> <br /> ==== PNI ====<br /> Acrônimo: ''Private Network Interconnection''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> O famoso Private Peering ou Interconexão Privada em português - é aquele que normalmente não envolve quaisquer pontos de troca pública, ou seja, são portas de roteadores ''back-to-back'' normalmente interligadas por um ''cross-connect'' ou &quot;''golden jumper''&quot; ou até por capacidade em redes de transporte ''LAN-to-LAN''.<br /> <br /> ==== PPPoE ====<br /> Acrônimo: ''Point-to-Point Protocol over Ethernet''.<br /> <br /> O PPPoE é um protocolo utilizado para encapsular quadros PPP dentro de quadros Ethernet, tendo surgido no final dos anos 90 juntamente com a proliferação da Internet banda larga proporcionada com a entrada das tecnologias de transmissão baseadas no DSL. O PPPoE servia então como uma solução de tunelamento dos pacotes sobre a conexão DSL. Atualmente, com a predominância das redes FTTH, o PPPoE continua sendo utilizado nas redes dos ISPs, mas primariamente como mecanismo de autenticação e autorização de assinantes dos produtos de Internet banda larga dos ISPs, sendo o principal procedimento utilizado para este propósito, e a sua operação neste modelo ocorre entre o equipamento do assinante (CPE/CE) e o concentrador de assinantes (BNG ou BRAS), cuja a separação poderá ser uma rede Metro Ethernet (L2) clássica, ou L2 sobre MPLS (L2VPN), ou xPON.<br /> [[Arquivo:Bpf-protecao-roteadores-7.png|centro|miniaturadaimagem|600x600px|Enciclopédia: PPPoE]]<br /> <br /> ==== PTT ====<br /> Acrônimo: ''Ponto de Troca de Tráfego''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Ponto de Troca de Tráfego (PTT), em inglês ''Internet Exchange Point'' (IXP), é um modelo de interconexão de redes entre os provedores de Internet e redes de fornecimento de conteúdo. Os Pontos de Troca de Tráfego (PTT) funcionam como hubs em que provedores podem conectar seus sistemas autônomos (AS), facilitando o tráfego de informações entre si. No Brasil, o IX.br é um projeto de PTTs locais gerido pelo Núcleo de Informação e Coordenação do Ponto Br (NIC.br) e pelo Comitê Gestor da Internet no Brasil (CGI.br), que facilita o fluxo de informações entre provedores de Internet e conteúdo online em diversas regiões no país. Na prática, quanto maior e melhor for um PTT, mais dados os provedores conseguem trocar, melhorando a eficiência da rede e encurtando o caminho da conexão entre os computadores, pois projetos de PTTs como o do IX.br proporcionam a ligação direta entre os participantes, permitindo que muitos Sistemas Autonômos (AS) troquem tráfego diretamente. A interligação de diversos AS em um IX, ou Ponto de Troca de Tráfego (PTT), simplifica o trânsito da Internet e diminui o número de redes até um determinado destino. Isso melhora a qualidade, reduz custos e aumenta a resiliência da rede. Também é possível oferecer ou contratar outros serviços a partir da conexão do seu ISP em um IX, como, por exemplo, serviços de trânsito de Internet.<br /> <br /> ==== QoS ====<br /> Acrônimo: ''Quality of Service''.<br /> <br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]].<br /> <br /> O ''Quality of Service'' (QoS) não deve ser compreendido como uma única tecnologia apenas, e sim um conjunto de tecnologias, ferramentas e práticas que, devidamente arrendadas, buscam sanear algumas das deficiências típicas de transmissão presentes em ambientes de redes de natureza estatística, especialmente o controle de latência, jitter, e perda de pacotes, decorrentes da insuficiência de recursos para a transmissão de pacotes nestes ambientes, como, por exemplo, os conhecidos gargalos/congestionamentos, esgotamento de buffers, e outros. Com a convergência de praticamente todo o tipo de aplicação e serviço para o transporte sobre redes baseadas no protocolo IP, soluções estas tais como Voice over IP (VoIP), Comunicações Unificadas (aka &quot;Telefonia IP e/ou Colaboração&quot;), Vídeo-conferência (em regime específico para tal, ou em conjunto com uma solução de Colaboração), etc., os engenheiros de redes precisam acomodar adaptações que permitam com que estes tipos de tráfego fluam de acordo com os padrões aceitáveis para uma boa interação humana através destas redes - em particular a audição e a visão. Anteriormente as soluções de vídeo e voz funcionavam sobre infraestruturas de redes digitais, ou seja, baseadas em transmissão deterministica, as quais não sofriam dos mesmos problemas das redes de transmissão estatísticas e baseadas em pacotes (congestionamentos; gargalos, descartes de pacotes devido a insuficiência temporária de buffers, etc.), como é o caso do Ethernet, IP e MPLS. Os requerimentos para o transporte de voz são bem mais agressivos nas questões de latência, jitter e perda de pacotes, se comparados com as transmissões de aplicações puramente de dados. As transmissões de vídeo podem ser extremamente agressivas, pois possuem os mesmos requisitos de latência, jitter e perda de pacotes das transmissões de voz, só que comportam-se em grande parte como uma aplicações de dados com elevada taxa de transmissão e consumo de recursos da rede. Para que a experiência de uma comunicação entre duas pessoas através de um serviço de VoIP/Telefonia IP/Colaboração/Vídeo fique isenta de picotes na voz, metalização da voz, ecos, atrasos excessivos, congelamento de imagens, perda de sincronismo entre vídeo e áudio, dentre outros, torna-se necessário priorizar estes tipos de transmissão com auxílio de políticas e configurações específicas. E é exatamente para isto que o QoS precisa ser adotado nas redes nos dias atuais. O mesmo é válido quando tratando-se de transmissões na rede envolvendo uma aplicação de dados crítica (um sistema ERP ou CRM) e uma navegação usual ou recreativa de Internet, onde, nestes casos, é muito desejável que a prioridade de transmissão seja de uma aplicação mais importante quando houver insuficiência de recursos para acomodar ambos os tipos de tráfego em um determinado momento. <br /> <br /> O QoS especifica uma diversidade de ferramentas e técnicas devidamente categorizadas em Classificação, Marcação, Gerenciamento de Congestionamentos, Controle de Congestionamentos, Policiamento, Moldagem e Eficiência de Links. <br /> [[Arquivo:Bpf-qos-9.png|centro|miniaturadaimagem|600x600px|Enciclopédia: QoS]]<br /> <br /> ==== QSFP ====<br /> Acrônimo: ''Quad Small Form Factor Pluggable''.<br /> <br /> ==== RADIUS ====<br /> Acrônimo: ''Remote Authentication Dial In User Service''.<br /> <br /> ==== RGI Classe V da Anatel para SCM ====<br /> <br /> ==== RNC ====<br /> Acrônimo: ''Radio Network Controller''.<br /> <br /> ==== Roteador ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== Route-policy ====<br /> Uma route policy é uma ferramenta que &quot;materializa&quot; ou &quot;instrumentaliza&quot;, através de conceitos de sintaxe e semântica de uma interface de linha de comando (CLI), que é parte integrante do sistema operacional de roteadores, a política de roteamento idealizada pelo administrador ou engenheiro de uma rede para o seu projeto ou o atendimento de uma necessidade específica. Enquanto uma &quot;política de roteamento&quot; é o conceito projetado para uma interpretação mais humana da palavra, pois especifica a idéia, intenção ou interesse; é a &quot;política no papel&quot;, como, por exemplo, na perspectiva de cada roteador BGP vizinho ao seu roteador, quais prefixos importar, quais prefixos exportar, quais atributos deverão ser modificados, e sobre quais prefixos/rotas estas modificações devem ser feitas, para conceber quaisquer que sejam as necessidades em termos de engenharia de rede e de tráfego do projeto técnico idealizado pelo engenheiro da rede, contemplando ainda questões associadas à segurança do roteamento de Internet (prevenção de ''route leaks'', ''prefix hijacks'', supressão do recebimento e envio de ''bogons''/''martians''/''unallocated'', etc.). A '''''route policy''''', por sua vez, já é a efetiva instrumentação propriamente dita desta política de roteamento. É a &quot;policy&quot; na sua forma de configuração na linguagem suportada pelo sistema de seu roteador. Ou seja, &quot;os comandos&quot; da CLI, a sintaxe, a semântica. O termo route policy em si serve para o generalizar um conjunto de ferramentas que são encontradas nos roteadores e utilizadas para definirmos &quot;na forma de CLI&quot; as nossas políticas de roteamento, as quais deverão ser aplicadas nos sentidos &quot;entrada&quot; (''import'' ou &quot;''in''&quot;) e &quot;saída&quot; (''export'' ou &quot;''out''&quot;) de nossas vizinhanças BGP. Cada plataforma de roteador e de cada fabricante tem o seu conjunto próprio de ferramentas, capacidades, sintaxes, recursos suportados (e não suportados), etc. Por exemplo, roteadores Juniper (software &quot;JUNOS&quot;) implementam as suas facilidades por meios do ''Routing Policy Framework'', que consiste de termos (&quot;''terms''&quot;) definidos na forma de um ou mais ''policy-statement'', com sofisticadas e variadas opções de incidência de classificação (''match'') e ações a serem adotadas em cada incidência (''accept'', ''reject'', modificar atributos, etc.), e podendo ainda acionar outras ferramentas e recursos periféricos para uma classificação mais refinada dos prefixos (ex: ''route-filter-list'', ''community'', etc). Roteadores Cisco equipados como Cisco IOS XR Software, por sua vez, possuem um sistema periférico muito robusto denominado ''Routing Policy Language'' (RPL), que combina diversos tipos de objetos (''prefix-set'', ''as-path-set'', ''community-set'', ''extcommunity-set'', dentre outros), para definir uma sofisticada, porém de simples interpretação, política de roteamento na forma de &quot;''route-policy''&quot;, com operações intuitivas na forma de &quot;''if'' / ''else'' / ''then'' / ''set'' / ''pass'' / ''drop'' / ''done'' / ''endif'', etc.&quot;. Já os roteadores da Cisco baseados no Cisco IOS e IOS XE Software apresentam as conhecidas e pioneiras &quot;''Route Maps''&quot;, as quais atuam em conjunto com outros recursos disponíveis na plataforma, tais como ''prefix-lists'', ''community-lists'', ''ip as-path access-lists'', e outras. Já os roteadores da Huawei no geral implementam recursos similares em termos de implementação aos do Cisco IOS / IOS XE, tais como ''route-policy'', ''ip-prefix'', ''community-filter'' e outros, enquanto equipamentos mais recentes deste fabricante já implementam uma solução diferente denominada ''eXtended routing-Policy Language'' (XPL), inspirada no RPL do Cisco IOS XR. Independentemente do &quot;vendor&quot; ou do equipamento, o fato é que route policies são indispensáveis, pois são usadas cotidianamente para o cumprimento de diversos objetivos relacionados ao roteamento de Internet ou de qualquer projeto de infraestrutura IP onde o BGP seja utilizado para fornecer segurança e engenharia de tráfego.<br /> <br /> ==== RPKI ====<br /> Acrônimo: ''Resource Public Key Infrastructure (RPKI)''.<br /> <br /> ==== RTBH ====<br /> Acrônimo: ''Remotely Triggered Black Hole (RTBH)''.<br /> <br /> ==== RUM ====<br /> <br /> ==== SBI ====<br /> Acrônimo: ''Settlement Based Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão também conhecido como Peering Pago (Paid Peering), onde uma das redes paga a outra pela troca de tráfego.<br /> <br /> ==== SCM ====<br /> Acrônimo: ''Serviço de Comunicação Multimídia''.<br /> <br /> ==== SDN ====<br /> Acrônimo: ''Software-Defined Networking''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.<br /> [[Arquivo:Bpf-prog-sdn3.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SDN]]<br /> <br /> ==== SeAC ====<br /> Acrônimo: ''Serviço de Acesso Condicionado''.<br /> <br /> ==== SFI ====<br /> Acrônimo: ''Settlement-free Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão onde nenhuma das partes paga a outra pela troca de tráfego entre ambas.<br /> <br /> ==== SFP ====<br /> Acrônimo: ''Small Form Factor Pluggable''.<br /> <br /> ==== Segment Routing (SR) ====<br /> <br /> ==== Segment Routing v6 (SRv6) ====<br /> <br /> ==== SGSN ====<br /> Acrônimo: ''Serving GPRS Support Node''.<br /> <br /> ==== STFC ====<br /> Acrônimo: ''Serviço Telefônico Fixo Comutado''.<br /> <br /> ==== SMP ====<br /> <br /> ==== SNMP ====<br /> Acrônimo: ''Simple Network Management Protocol''.<br /> [[Arquivo:Bpf-protecao-roteadores-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SNMP]]<br /> <br /> ==== SSH ====<br /> Acrônimo: ''Secure Shell''.<br /> <br /> ==== Switch ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== SyncE ====<br /> Acrônimo: ''Synchronous Ethernet''.<br /> <br /> O SyncE é uma das quatro soluções de ''timing'' sobre redes de transmissão baseadas em pacotes, juntamente com o ''Precision Time Protocol'' (PTP), ''Network Time Protocol'' (NTP) e ''Timing over IP Connection and Transfer of Clock BOF'' (TICTOC). O SyncE é ao mesmo tempo um protocolo e um método de sincronismo para instruções de ''timing'' operando diretamente sobre o Ethernet, ou seja, sem o envolvimento de protocolos de camadas superiores (ex: IP, UDP ou TCP), e possui um procedimento que remonta ao que as redes SDH fazem. O SyncE é utilizado especialmente para o sincronismo de frequência, sendo inclusive muito preciso quanto a isto, mas não provê sincronismo de data e hora, pois este tipo de distribuição de informação (data/hora) precisa ou deve ser feita por outro protocolo (ex: NTP ou PTP). Diversos padrões regem o SyncE, dentre eles o ITU-T G.8261, G.8262, G.8264 e G.781. Em termos de eficácia, o SyncE é a referência de frequência mais estável e a mais precisa disponível atualmente, após as opções por PRC, BITS e GPS, e operadores de telefonia móvel estão avançando no suporte ao SyncE em suas redes como medida de redução de custos e sem o comprometimento da qualidade, ou seja, evitando instalações de GPS em cada estação da rede móvel.<br /> <br /> ==== TACACS+ ====<br /> Acrônimo: ''Terminal Access Controller Access-Control System Plus''.<br /> <br /> ==== Telnet ====<br /> <br /> ==== Trânsito ====<br /> <br /> ==== uRPF ====<br /> Acrônimo: ''Unicast Reverse Path Forwarding''.<br /> <br /> O ''Unicast Reverse Path Forwarding'' (uRPF) é um recurso disponível no software dos roteadores que é utilizado primariamente como mecanismo de &quot;antispoofing&quot;, ou seja, serve para a validação do endereço IP de origem sobre os pacotes recebidos nas interfaces do roteadores. A outra funcionalidade do uRPF é atuar como mecanismo de prevenção de ''routing loops'', em especial em situações relacionadas ao IP Multicasting. No que concerne ao mecanismo de &quot;antispoofing&quot; de endereços IP de origem em tráfego unicast em si, o uRPF é a ferramenta mais indicada para ser adotada nas interfaces que apontam diretamente para as conexões do cone de clientes (downstreams) do provedor de acesso à Internet (ISP), sendo ali o ponto correto de posicionamento e configuração deste mecanismo. Quanto as razões para a utilização do uRPF, o principal e mais forte argumento é a eliminação ou redução dos vetores de ataques DDoS, pois, para que este tipo de ataque possa ser bem sucedido, torna-se necessário que os hosts infectados (&quot;zumbis&quot;), que, neste caso, seriam os clientes do seu ISP, e de outros ISPs também, controlados por uma botnet, encaminhem pacotes com endereços IP de origem &quot;spoofados&quot; (forjados) para que aparentem terem sido enviados a partir do host ou rede que será a vítima deste ataque (cujo seu(s) endereço(s) IP foi (foram) forjado(s)/spoofado(s) por dezenas de milhares de outros hosts na Internet), o que promoverá, consequentemente, e infelizmente, o êxito deste ataque DDoS. Ou seja, sem o spoofing de endereços IP de origem, conceber ataques DDoS na Internet fica uma tarefa praticamente impossível - ou até que outras formas de ataques de negação de serviço sejam idealizadas pelos malfeitores da Internet. Por estas e outras razões que o &quot;Antispoofing&quot;, que inclusive é um dos objetivos estipulados pelo ''Mutually Agreed Norms for Routing Security'' (MANRS), deve ser projetado e configurado corretamente em todas as interfaces que admitem os clientes de um ISP, ou seja, em todo o seu &quot;downstream&quot;. Se todos os ISPs fizessem isso, simplesmente não haveria ataques DDoS na Internet. Ou pelo menos não nos moldes em que estes ataques são concebidos atualmente. Há algumas formas ou modalidades de implementação do uRPF, sendo eles o &quot;''Strict''&quot;, &quot;''Feasible''&quot; e &quot;''Loose''&quot;. Alternativamente ao uRPF, há outras ferramentas que podem ser consideradas para este propósito de antispoofing, incluindo Access Control Lists e IP Source Guard, mas, no caso de service providers / ISPs, o uRPF é o mecanismo mais indicado. Faça a sua parte e contribua para uma Internet mais segura: siga as recomendações do BCP 38 (''Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing''), que é citado no objetivo &quot;Antispoofing&quot; do MANRS, e ajude a reduzirmos substancialmente os ataques DDoS que assolam a Internet!<br /> <br /> ==== VPLS ====<br /> Acrônimo: ''Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. <br /> [[Arquivo:Bpf-enciclopedia-vpls.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN multiponto (VPLS)]]<br /> <br /> ==== VPNv4 ====<br /> Acrônimo: ''Virtual Private Network version 4''.<br /> <br /> O VPNv4 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv4 é definido como uma extensão para o suporte mulitprotocolo do BGP (&lt;nowiki&gt;RFC 4364&lt;/nowiki&gt; e &lt;nowiki&gt;RFC 4659&lt;/nowiki&gt;), e é representado pelo ''Address Family Identifiers'' (AFI) número 1 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. O endereço VPNv4 possui 96 bits de comprimento, sendo 64 bits composto pelo ''Route Distinguisher'' e os 32 bits restantes sendo o prefixo IPv4 da rota original (ex: envidada do roteador CE para o roteador PE, antes da conversão desta rota IPv4 unicast para uma rota VPNv4 pelo roteador PE). Roteadores ''Provider Edge'' (PE) de um backbone de operadora de telecomunicações ou ISP são configurados para trocar rotas VPNv4 através de sessões MP-BGP entre si, as quais são devidamente estabelecidas sobre uma rede MPLS para viabilizar a comunicação entre os sites participantes de uma determinada VPN, usando outros atributos associados aos anúncios destas rotas VPNv4 (ex: extended communities denominadas ''Route Targets'', dentre outros parâmetros e atributos).<br /> <br /> ==== VPNv6 ====<br /> Acrônimo: ''Virtual Private Network version 6''.<br /> <br /> O VPNv6 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv6 é representado pelo ''Address Family Identifiers'' (AFI) número 2 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. Um endereço VPNv6 possui 64 bits de comprimento, sendo 8 octetos o &quot;''Route Distinguisher''&quot; e 16 octetos o endereço IPv6 unicast. À exemplo do VPNv4, o VPNv6 é trocado entre roteadores PE com o auxílio do protocolo BGP (MP-BGP) para o estabelecimento de L3VPN MPLS funcionais com o IPv6 dos sites atendidos/conectados. Para estas L3VPN com IPv6, as sessões IBGP entre os roteadores PE participantes poderá ser feita em IPv4 ou IPv6, e a codificação do atributo NEXT_HOP será distinta para cada caso (&quot;''BGP speaker requesting IPv6 transport''&quot; ou &quot;''BGP speaker requesting IPv4 transport''&quot;). Sobre a codificação do atributo Next Hop, um draft recente está propondo a modificação de alguns destes procedimentos (draft-litkowski-bess-vpnv4-ipv6-nh-handling-00).<br /> <br /> ==== VPWS ====<br /> Acrônimo: ''Virtual Private Wire Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços ponto-a-ponto, ou seja, onde envolve-se apenas dois sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. As diferenças principais entre o VPLS e o VPWS é que, no caso do VPWS, não há aprendizado de endereços MAC, e a solução comporta-se como um ''clear channel'' mesmo.<br /> [[Arquivo:Bpf-enciclopedia-vpws.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN ponto-a-ponto (VPWS)]]<br /> <br /> ==== VxLAN ====<br /> Acrônimo: ''Virtual Extensible LAN''.<br /> <br /> Historicamente a segmentação de uma rede L2 tradicional tem sido fornecida por VLANs padronizadas conforme o IEEE 802.1Q, onde VLANs são criadas e distribuídas nos switches da rede para fornecer a segmentação lógica desejada para as funções de camada 2 em seus domínios de broadcast. No entanto, devido ao uso ineficiente dos links de rede disponíveis com o uso de VLAN, aos requisitos rígidos de posicionamento de dispositivos em redes de missão crítica como datacenters, e à escalabilidade limitada a um máximo de 4094 VLANs, o uso de VLANs tornou-se um fator limitante para muitas redes e de diversas empresas, especialmente data centers e provedores de acesso à Internet. Os ISPs já possuem uma solução baseada no Flexible VLAN Tagging ou Ethernet Flow Point em combinação com soluções L2VPN clássicas, mas este tipo de solução não atende os requisitos de conectividade com alta densidade e elasticidade de multitenantes. Alguns fabricantes líderes de mercado, incluindo a Cisco, Cumulus Networks, Arista, Broadcom, VMware, Intel e Red Hat, uniram-se para propor ao IETF uma solução para sanear os desafios de rede L2 mencionados previamente, e daí surgiu o VXLAN. O VXLAN fornece o posicionamento elástico da carga de trabalho (workload) e maior escalabilidade da segmentação da Camada 2, exigidas pelas demandas de aplicativos atuais, provendo os mesmos serviços Ethernet / camada 2 que VLANs demandam nos dias atuais, só que com maior extensibilidade, flexibilidade e escalabilidade. Em termos mais técnicos, o VXLAN é um esquema de sobreposição (overlay) da camada 2 em uma rede da camada 3. A tecnologia usa o encapsulamento MAC-in-User Datagram Protocol (MAC-in-UDP) para fornecer um meio de estender os segmentos da Camada 2 através da rede do data center, compondo uma solução formidável para oferecer suporte a um ambiente multitenant flexível e em larga escala através de uma infraestrutura física comum compartilhada. O protocolo de transporte na rede física do datacenter inclui o IP e o UDP. Para este procedimento, o VXLAN define um esquema de encapsulamento MAC-in-UDP em que o quadro original da camada 2 possui um cabeçalho VXLAN adicionado e é então colocado em um pacote UDP-IP. Com esse encapsulamento MAC-in-UDP, o VXLAN encapsula a rede da Camada 2 pela rede da Camada 3, fazendo as extensões desejadas das VLANs através da rede, mas, no entanto, sem incorrer nas mesmas limitações de flexibilidade, escalabilidade e diâmetro das redes L2 tradicionais.<br /> <br /> === Desciclopédia ===<br /> <br /> ==== Ajuste Fino ====<br /> Ajuste Fino descreve medidas paliativas ou &quot;''worarounds''&quot; para a superação de deficiências e limitações apresentadas ou impostas por algumas plataformas de equipamentos quando falham ao cumprir com as diretivas e configurações definidas pelos administradores, e cujas as falhas geralmente são acompanhadas de sentimentos de bastante frustração. Para exemplificar um dos tantos casos aqui, há um bocado de relatos onde um equipamento, que supostamente deveria possuir um bom suporte ao protocolo de roteamento BGP, com tabelas de Internet completas (full routes), &quot;trava&quot; rotineiramente ao apresentar ciclos de processamento elevados, bastando que apenas um de seus muitos núcleos disponíveis para esta finalidade fique engargalado para que o referido problema seja notado, consequentemente exigindo a reinicialização (&quot;reboot&quot;) do equipamento para a restauração da normalidade. Para mitigar este problema, dois argumentos possíveis são praticados pelos consultores: a) &quot;''você que não sabe configurar''&quot;, ou seja, na prática, como a quantidade de casos é um tanto grande, entendemos, portanto, que ninguém sabe configurar. b) &quot;''isto é fácil, é só mexer aqui, aqui, aqui e ali, e fazer isso, que você não terá mais o problema''&quot;. O argumento &quot;b&quot; é o que chamamos de Ajuste Fino. Quais tipos de manobras são consideradas ajuste finos? Vejamos: agendamento de reinicialização ou boot automático em intervalos periódicos, podendo ser diário ou semanal + upgrade de memória + publicação das full routes em uma VRF + balanceamento do tráfego através de múltiplos dispositivos, visando diminuir a carga + deixar na tabela principal apenas a rota padrão. Na verdade, fica até complicado definir os ajustes finos, pois são segredos comerciais guardados a sete chaves! O termo acabou generalizando e atualmente todo o workaround empregado para fugirmos de alguma restrição tecnológica ou de algum bug de software é chamado de &quot;Ajuste Fino&quot;, e isto independente do fabricante, modelo e marca do equipamento. Ajuste Fino pode ser considerado um workaround ou gambiarra para qualquer situação onde você teve que fazer algumas manobras esquisitas e fora do que usualmente precisamos fazer para as coisas funcionarem conforme &quot;by the books&quot;.<br /> [[Arquivo:Bpf-desc-ajustefino.png|centro|miniaturadaimagem|494x494px|Ajuste Fino!]]<br /> <br /> ==== Balance Soma-Link ====<br /> Clássica gambiarra que predominou em muitos ISPs pequenos e por muitos anos. A estratégia consistia em contratar dezenas de links banda larga ADSL para desempenharem a função de Trânsito IP do provedor, e fazer uma configuração com roteadores Mikrotik ou de classe similar para executar o balanceamento do tráfego através destas conexões, e sob o pretexto de que este tipo de &quot;solução&quot; somava a capacidade dos links e ainda por cima promovia uma distribuição simétrica ou bem uniforme do tráfego. Alguns consultores, por falta de opções ou recursos, ou despreparados tecnicamente, ou, em alguns casos, malandros mesmo, militavam abertamente nas redes sociais sobre estas façanhas. Desnecessário comentar aqui que tal gambiarra é completamente equivocada nos pontos de vista legal e ético, além de tecnicamente bastante frágil. Felizmente caiu em desuso, mas ainda assim é possível encontrar estas maluquices por aí. Nem o próprio MacGyver, ícone do famoso seriado dos anos 80, especializado em promover gambiarras incríveis para todo e qualquer tipo de situação, teria sido tão &quot;genial&quot; quanto os malandros que inventaram o &quot;Balance Soma-Link&quot;! A diferença é que as gambiarras do MacGyver funcionam e são quase sempre éticas, já essa gambiarra aí...<br /> [[Arquivo:Bpf-desc-loadbalance.png|centro|miniaturadaimagem|600x600px|Gambiarra do Balance Soma-Link]]<br /> <br /> ==== Bridge Roteada ====<br /> <br /> ==== Hiluxer ====<br /> Hiluxer é como são chamados os donos de ISPs que preferem investir em conforto pessoal do que em seus próprios negócios. O &quot;X&quot; da questão não está no fato do dono do ISP querer e poder usufruir daquilo que construiu, ou seja, de ter os seus &quot;mimos&quot;, usufruir de sua riqueza e de prover conforto para si e para seus familiares, e sim na forma em que ele negligencia o seu próprio empreendimento. É óbvio que o dono do ISP pode e deve usufruir de tudo aquilo que ele conseguiu conquistar com o sucesso de seu negócio! O problema é que alguns donos de ISPs não fazem a menor idéia do quão necessário é manter a regularidade de investimentos para a engenharia e a operação de redes de um ISP, por mais que sejam... donos de um ISP! Para estes indivíduos, para tudo há uma solução mais simples: investimentos orientados às necessidades de curto prazo apenas (desprezando o longo prazo), soluções minimalistas e centradas no fator de menor custo. O Hiluxer quer fornecer um serviço de primeira qualidade, mas com processos e investimentos de &lt;u&gt;''quinta categoria''&lt;/u&gt;!<br /> <br /> Os Hiluxers não compreendem alguns fundamentos importantes para a sustentação do próprio negócio, tais como a gestão da cadeia de fornecedores, engenharia e operação de redes (desempenho, disponibilidade, confiabilidade, resiliência, escalabilidade, matriz funcional de qualidade, usabilidade, gerenciamento, segurança, QoE, etc.), além de roadmap de produto, marketing, vendas, logística, atendimento a clientes, e tantos outros. Quando confrontado por times internos (por exemplo, colaboradores da área técnica) para que sejam tomadas decisões importantes para uma questão tecnológica ou desafio operacional da empresa, o Hiluxer interfere de forma improdutiva e frequentemente desviando da solução ou mitigação ideal para sanear o problema ou desafio exposto. Os colaboradores da área técnica de um ISP &quot;Hiluxer&quot; tem que se virar como podem para manter a parte técnica da empresa funcionando, usando todo o tipo de artifício e gambiarra que puderem. <br /> <br /> Mas, no entanto, na hora de comprar a nova versão do Hilux... o referido indivíduo não pensa duas vezes, e parte para visitar a concessionária! Isto é real!<br /> [[Arquivo:Bpf-desc-hiluxer.jpg|centro|miniaturadaimagem|600x600px|Desciclopédia: Toyota Hilux GR Sport - um carro top, sem dúvidas!]]<br /> <br /> ==== IP Confinado ====<br /> Conheça mais: [[CDN Peering e PNI - Brasil|https://wiki.brasilpeeringforum.org/w/CDN_Peering_e_PNI_-_Brasil]]<br /> <br /> O &quot;IP Confinado&quot; é um produto ofertado por alguns provedores com a proposta de fornecer conteúdo de &quot;CDNs apenas&quot; para clientes interessados neste tipo de serviço. O que justifica o &quot;IP Confinado&quot; estar sendo listado em nossa desciclopédia não é a parte técnica da &quot;solução&quot; em si, e sim as diversas violações contratuais associadas com a prática. Muitos destes ISPs promovem algumas práticas que não são permitidas conforme os contratos que são estabelecidos entre ISPs e as detentoras das CDNs. Por exemplo, não é permitido que o ISP mencione que &quot;vende tráfego de CDN&quot;, muito menos destacando ou citando os nomes das empresas/CDNs envolvidas na &quot;oferta&quot;; incorporar logotipos/logomarcas destas empresas em qualquer tipo de propaganda ou material publicitário, expor as fotos dos equipamentos/servidores de CDN implantados em seus data centers, etc. Ou seja, o &quot;IP Confinado&quot; está frequentemente associado a abusos por parte de ISPs, tais como violações de direitos autorais, direitos de propriedade intelectual, direitos de imagem e afins. <br /> <br /> Entenda: é permitido que o ISP venda &quot;implicitamente&quot; o conteúdo de CDNs como parte de uma oferta de &quot;Trânsito IP Parcial&quot; e similares, mas desde que mantendo sob sigilo as informações que possam identificar as empresas que fornecem as CDNs para o ISP. A venda de conteúdo de CDN em si é tida como uma prática ilegal.<br /> [[Arquivo:Ipconfinado.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Confinado]]<br /> <br /> ==== IP Ilegal ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Puro ====<br /> O &quot;IP Puro&quot; nada mais é que uma proposta de fornecimento de um serviço de trânsito para um cliente-ISP final e que exclua deste link todo o tráfego de CDNs que por ventura estiver presente na infraestrutura do ISP contratado, muitas das vezes até mesmo excluindo tráfego originado de sessões de peering privado (PNI). Ou seja, tráfego exclusivamente obtido por upstreams de trânsito IP. Muitos ISPs contam com infraestruturas de CDNs em seus ambientes, juntamente com as sessões de trânsito IP com seus upstreams e também os pontos de troca de tráfego, sejam estes privativos, compartilhados ou bilaterais. Quando um ISP contrata um serviço de trânsito IP junto a outro ISP, neste link escoará todo o tipo de tráfego que existir na infraestrutura do ISP contratado, ou seja, tráfego proveniente dos peerings (ex: IX.br, PNI com Google, Facebook, etc.), trânsito (os upstreams daquele ISP contratado), e, claro, o tráfego das CDNs que existirem no ISP contratado. <br /> <br /> O que alguns ISPs-clientes fazem é exigir que o tráfego destas CDNs (e de peerings também, em muitos casos) não seja fornecido no link de trânsito IP contratado. As discussões acerca deste tipo de necessidade um tanto curiosa ou inusitada são tantas as vezes que um produto denominado &quot;IP Puro&quot; acaba sendo informalmente definido entre os participantes do meio. As vantagens e benefícios alegados por alguns são bastante questionáveis, pois entendemos que o ISP-cliente tem muito mais a perder do que a ganhar com esta preferência. O &quot;IP Puro&quot; é um exemplo clássico de nossa Desciclopédia!<br /> [[Arquivo:Ippuro.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Puro]]<br /> <br /> ==== IP Real ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Válido ====<br /> Endereços IP &quot;válidos&quot;, na mente de muitos profissionais da área, são aqueles endereços IP cuja conectividade com a Internet é plenamente funcional, justamente por não estarem contidos nas faixas especificadas pelo &lt;nowiki&gt;RFC 1918&lt;/nowiki&gt; (''Address Allocation for Private Internets'') ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt; (''IANA-Reserved IPv4 Prefix for Shared Address Space''). Ou seja, a verdade é que IP válido é qualquer endereço IP que não seja privativo.<br /> <br /> Na verdade, todo endereço IP é válido! O correto seria diferenciar o endereço IP em &quot;público&quot; e &quot;privado&quot;, e não em válido ou inválido (quando o endereço for privativo). <br /> [[Arquivo:Bpf-desc-ipvalido.png|centro|miniaturadaimagem|421x421px|Desciclopédia: o que seria um IP &quot;inválido&quot;...]]<br /> <br /> ==== IX Confinado ====<br /> <br /> ==== Link Dedicado Full Duplex ====<br /> <br /> ==== Link Semi-Dedicado ====<br /> O &quot;Link Semi-Dedicado&quot; é algo que expressa muito bem a cultura do brasileiro! Para resumir ou antecipar aqui, isto é basicamente uma gambiarra comercial.<br /> <br /> Para explicar isto melhor, vejamos o serviço de um link dedicado. Serviços de links dedicados são e devem ser tipicamente fornecidos através de uma infraestrutura Metro Ethernet, a qual disponibiliza recursos mais exclusivos e dedicados para o assinante/cliente, tais como uma porta dedicada em um switch Metro para aquele cliente, o enlace da fibra óptica é dedicado na última milha para a conexão do equipamento CPE/CE do cliente, a banda contratada é absolutamente simétrica e pode ser ajustada para até a capacidade máxima suportada pela porta (ex: 200 Mbps sobre porta 1 Gbps, 500 Mbps sobre porta 1 Gbps, ou 1 Gbps direto na porta). Ou seja, um Link Dedicado reúne componentes e arranjos tecnológicos mais caros e especializados para maximizar a experiência do cliente quanto à contratação do serviço. Novamente, é uma tecnologia mais cara, mas o cliente que contrata este serviço sabe exatamente o que e por que está contratando.<br /> <br /> Por outro lado, temos as tecnologias de Internet banda larga, inicialmente lá atrás com tecnologias baseadas no DSL (empregando DSLAMs e/ou MSANs, por exemplo), e nos últimos anos, o FTTH com xPON (principalmente o GPON), que operam especialmente sobre uma rede de acesso completamente compartilhada e com banda assimétrica Up e Down para as taxas mais elevadas.<br /> <br /> O GPON todos nós sabemos que é uma rede óptica passiva de natureza compartilhada, e toda a infraestrutura GPON é indiscutivelmente mais barata que uma rede Metro Ethernet; a diferença é muito expressiva neste sentido. Enquanto isto, é de amplo conhecimento que serviços de Internet banda larga são bem mais baratos (e viáveis para muitas pequenas empresas) que serviços de Internet com link dedicado, certo?<br /> <br /> O que alguns ISPs fazem, inclusive isto começou com um grande operador de redes: o &quot;meio-termo&quot;. Basicamente estas empresas tem vendido links de Internet banda larga com taxas um pouco mais elevadas, mas compatíveis com a característica assimétrica do projeto da rede GPON para a região onde o cliente está localizado, e suprimem, na cara de pau, o termo &quot;banda larga&quot;, usando o termo &quot;dedicado ou semi-dedicado&quot; para promover ou fornecer o serviço. Nada contra o GPON, muito pelo contrário! É uma tecnologia que permitiu baratear bastante os custos de construção de redes e a difundir melhor a Internet banda larga para muitos segmentos de pequenos negócios. Quando confrontados por clientes na questão de simetria da banda, os consultores do ISP procuram &quot;driblar&quot;, evitando mencionar que a rede é compartilhada (e que tem essa questão de restrições envolvendo a simetria Up e Down), e, quando sofrem o ultimato, informam que o serviço é &quot;Semi Dedicado&quot; (ou seja, nunca fazem menção ao aspecto compartilhado ou ao próprio GPON).<br /> <br /> Uma gambiarra estritamente comercial! É que nem você falar que mora num bairro adjacente ao seu, ao invés de citar o nome real conforme o seu CEP, porque seu bairro tem uma má fama. Ou que nem você ter vergonha de assumir a sua namoradinha(o) em público!<br /> [[Arquivo:Bpf-enciclopedia-semidedicado.jpg|centro|miniaturadaimagem|500x500px|Desciclopédia: Link Semi-Dedicado]]<br /> <br /> ==== Lupebequi ====<br /> <br /> ==== Rota Presa ====<br /> O termo &quot;rota presa&quot; ganhou tração há alguns anos, juntamente com o impulsionamento do crescimento de provedores de acesso à Internet de pequeno porte. Na ocasião, muitos ISPs de pequeno porte, a maioria destes, na verdade, contavam com classes de equipamentos roteadores equipados com arquiteturas de processamento de pacotes baseadas em software (''soft routers''). Com o crescimento da empresa no que diz respeito à base de assinantes, consumo de recursos de rede (banda, enlaces de trânsito IP, sessões, traduções de endereços, etc.), diversos ISPs passaram a experimentar rotineiramente problemas com o BGP, em particular com rotas ficando &quot;presas&quot; na tabela BGP e/ou RIB, mesmo com a sessão BGP correspondente ao recebimento daquelas rotas estando indisponível. Como as situações reportadas por profissionais e consultores da área eram um tanto frequentes, o termo &quot;Rota Presa&quot; acabou generalizando e tornando-se versátil para descrever o óbvio: para tudo há limites. Mesmo que um equipamento ''soft router'' possa ser bastante atraente na relação custo x benefício, e ser capaz de agregar muitos recursos e facilidades interessantes, uma arquitetura de roteamento baseada em processamento de pacotes por interrupções de software frequentemente possui problemas de escalabilidade. Na medida em que aumenta-se o consumo de recursos de rede (banda, sessões, traduções simultâneas de NAT, etc.), o processamento será aumentado proporcionalmente. Até que isto comece a provocar problemas de desempenho e outros incidentes. Isto porque a combinação de classe de hardware de alguns equipamentos conhecidos do mercado, e a arquitetura de soft router, possui limitações nas questões de desempenho e escalabilidade, algo que é igualmente e rotineiramente negligenciado por ISPs e consultores. Mesmo após esta constatação, muitos ISPs continuavam apostando nesta abordagem em termos de arquitetura de roteador para a função de borda, ou seja, postergando o inevitável: já estava na hora de migrar aquela arquitetura para plataformas mais especializadas para esta missão.<br /> <br /> O interessante é que há uma relação muito íntima entre a &quot;Rota Presa&quot; e o &quot;Ajuste Fino&quot;! Para alguns, o problema de &quot;rotas presas&quot; e sintomas similares somente pode ser saneado com a migração de arquitetura (trocando o roteador), enquanto, para outros, especialmente os &quot;magos da telecom&quot;, o problema de &quot;rota presa&quot; é provocado pela incompetência de quem configura o equipamento, pois basta o sujeito executar alguns procedimentos secretos (&quot;Ajuste Fino&quot;) para que este problema não ocorra. :-)<br /> [[Arquivo:Bpf-desc-rotapresa.png|centro|miniaturadaimagem|518x518px|Desciclopédia: Rota Presa<br /> <br /> Fonte: Consultores da Depressão]]<br /> <br /> ==== SkyGato ====<br /> <br /> ==== Terraplanistas da Telecom ====<br /> O que seriam &quot;terraplanistas da telecom&quot;? Analogia aos terraplanistas &quot;originais&quot;: indivíduos que se acham superiores a gerações inteiras de verdadeiros gênios inspiradores, dos quais incluo aqui Eratóstenes, Galileo Galilei, Isaac Newton, Albert Einstein, Johannes Kepler, Arthur Eddington, Edwin Powell Hubble, Milton L. Humason, Tycho Brahe, Michael Faraday, Stephen Hawking, Steven Weinberg, James Clerk Maxwell, Peter Higgs, Edward Witten, Freeman Dyson, Werner Heisenberg, Erwin Schrodinger, Alan Guthm, Ernest Rutherford, Paul Dirac, Niels Bohr.... fora Anaximandro, Arquimedes, e tantos outros, dentre gênios e perseguidos. Todo um esforço gigantesco e desde os tempos mais remotos para que evoluíssemos humana e tecnologicamente e nas áreas de física e astrofísica, construíssemos coisas incríveis, compreendêssemos o universo próximo, mesmo que faltando ainda tantas perguntas sem respostas, para termos uma classe de indivíduos em franca expansão (&quot;terraplanistas&quot;) usando a tecnologia, todo o aparato tecnológico à seu favor para, nas redes sociais, bradarem aos 4 ventos: &quot;A TERRA É PLANA!&quot;. Surreal!<br /> <br /> Na mesma moeda, analogias aqui, os &quot;''terraplanistas da telecom''&quot; são aqueles indivíduos que atuam na área e que tentam refutar o irrefutável. Literalmente '''''&lt;u&gt;rasgam&lt;/u&gt;''''' RFCs, BCOPs, padrões/standards, e frameworks. Não somente isto: acidentalmente ou propositalmente quase que rasgam também os trabalhos dos &quot;gênios da nossa área&quot;; Radia Joy Perlman, John Moy, Yakov Rekhter, Kirk Lougheed, Vint Cerf, Robert Kahn, Robert Metcalfe, David Boggs, W. David Sincoskie, Ali Sajassi, dentre tantos caras que criaram tudo o que usamos nas redes hoje, fora os grupos de trabalho incluindo IETF, IEEE, IANA, RIPE, NIC.br, LACNOG, NANOG, GPF, e, porque não, as recomendações do BPF, e o escambáu. As BCOPs e RFC são literalmente '''&lt;u&gt;nada&lt;/u&gt;''' para alguns destes indivíduos (sim, eu atestei isto! Eu li e conferi isso numa discussão!). O que um Job Snijders falaria no ouvido desses caras, entraria por um lado e sairia pelo outro!<br /> <br /> Parece exagero, mas tem surgido uma classe de indivíduos que tenta refutar uma diversidade de fatos irrefutáveis sobre as características, disponibilidades e aplicabilidades de tecnologias associadas à redes, telecomunicações no geral; a Internet. Dentre os absurdos que vemos por aí, temos: &quot;''é mentira que o IPv4 está se esgotando!''&quot;, &quot;''o OSPF está morrendo!''&quot;, &quot;''operadoras estão deixando de usar o MPLS''&quot;, &quot;''a navegação por IPv6 prejudica a performance da minha Internet&quot;'', &quot;''não preciso implantar o IPv6, porque o IPv6 ainda não é usado&quot;'', ''&quot;blackhole é mitigação de DDoS''&quot;, &quot;''trânsito sem PTT é melhor''&quot;, &quot;''existe trânsito IP puro''&quot;, &quot;''sessão de peering com IX Europeu melhora a performance porque a lista de AS_PATH é menor''&quot;, dentre outras coisas engraçadas. Note que não são apenas &quot;opiniões&quot;: essas situações fazem parte de recomendações de fato que os &quot;terraplanistas da telecom&quot; promovem!<br /> <br /> O meu termo aqui de &quot;terraplanistas da telecom&quot; não faz julgamento de quanto o indivíduo sabe ou não sabe sobre estas tecnologias. Realmente não compete a mim julgar o nível de conhecimento de qualquer um que seja, e isto está absolutamente fora de questão. O que me cabe a fazer, obviamente, é questionar porque eles falam mal de certas coisas que eles mesmos não compreendem ou dominam? Não seria mais prudente pesquisar, informar-se, praticar, exercitar, questionar, etc., a ponto do indivíduo ser fluente o suficiente nesse ou naquele tema (protocolo, tecnologias), antes de tentar influenciar as outras pessoas?<br /> <br /> Uma coisa é você falar que não sabe ou não domina uma tecnologia, por isso que você não a quer ou prefere evitá-la. Uma coisa é você falar que determinada tecnologia não é compatível com os seus planos e pelas razões X, Y e Z. Em ambos os exemplos, argumentos e justificativas válidos. Agora, falar que &quot;''é mentira que o IPv4 está se esgotando''&quot; e coisas deste tipo é um verdadeiro desserviço para a comunidade!<br /> [[Arquivo:Bpf-enciclopedia-terraplanistas.png|centro|miniaturadaimagem|600x600px|Desciclopédia: terraplanistas da telecom]]<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Geral]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Bpf-desc-hiluxer.jpg&diff=2522 2020-06-15T20:48:48Z

<p>Leonardo.furtado: </p> <hr /> <div>Desciclopédia: Toyota Hilux GR Sport - um carro top, sem dúvidas!</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Enciclopedia_e_desciclopedia_da_telecom&diff=2521 2020-06-15T20:10:08Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Enciclopédia e &quot;Desciclopédia&quot; da Telecom ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Este artigo sofrerá adições de termos, acrônimos e expressões, um tanto frequentemente! Será a nossa Enciclopédia para descrever e, sempre que possível, exemplificar cada um dos termos usados pelas empresas e profissionais das áreas de telecomunicações e redes! Da mesma forma, este artigo fornecerá, e buscará deixar destacado, juntamente a cada termo, onde aplicável, uma &quot;Desciclopédia&quot; (nada melhor que uma dose de humor, certo?) para comentar situações que são verdadeiras gambiarras encontradas no setor de telecomunicações. <br /> <br /> A Enciclopédia reúne as expressões legítimas e corretas. Já a Desciclopédia, reúne situações um tanto controversas que surgiram na cabeça altamente criativa dos profissionais da área; as gambiarras! <br /> <br /> OBS: a prioridade de edição do artigo será o fornecimento das explicações referentes aos termos e, em segundo momento, a inclusão de algum tipo de exemplo ou referência. Se algum termo não contiver um exemplo ou uma referência, simplesmente aguarde, pois isto será realizado posteriormente. <br /> <br /> Desde já, solicito para que você siga acompanhando os trabalhos do '''''Brasil Peering Forum (BPF)''''', faça o bom e sensato uso de boas práticas, e diga não às gambiarras!<br /> [[Arquivo:Bpf-enciclopedia-cover.png|centro|miniaturadaimagem|700x700px]]<br /> <br /> ==== Como consultar este artigo ou buscar os termos e expressões desejadas ====<br /> Para este procedimento, sugiro:<br /> * Todos os acrônimos, termos ou expressões estão listados em ordem alfabética. Você poderá navegar pelo índice remissivo, clicar no acrônimo ou termo desejado, e ser direcionado diretamente para ele. Ou;<br /> * Faça uma pesquisa diretamente através de seu navegador (ex: CTRL-F)!<br /> Aprecie sem moderação!<br /> <br /> === Enciclopédia ===<br /> <br /> ==== 6PE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS (6PE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6PE é um cenário de transição para a adoção do roteamento IPv6 onde, no Core do operador da rede (ISP), não há endereçamento IPv6 (ainda), e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. Para maior eficiência, flexibilidade, e redução de custos, o 6PE pode ser projetado em um ambiente de backone (Core) isento de BGP, num cenário denominado &quot;''6PE com BGP-Free Core''&quot; mas, no entanto, são coisas distintas, e uma coisa não depende da outra, embora a combinação de ambas as estratégias tende a agregar muitos benefícios.<br /> [[Arquivo:Bpf-enciclopedia-6pe.png|centro|miniaturadaimagem|600x600px|Enciclopedia: 6PE]]<br /> <br /> ==== 6VPE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS VPN (6VPE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6VPE é um cenário de transição para a adoção do roteamento IPv6 na relação entre o ISP e clientes corporativos de serviços L3VPN MPLS, onde, no Core do operador da rede (ISP), não há endereçamento IPv6, e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. A diferença primária entre o 6PE e o 6VPE é que o 6PE lida com o roteamento IPv6 unicast sobre uma infraestrutura de backbone IPv4 em uma rede MPLS, enquanto o 6VPE lida com a troca de prefixos IPv6 unicast sobre uma infraestrutura L3VPN MPLS com sessões IBGP em IPv4 e com o suporte VPNv6 entre os roteadores PE. O BGP-Free Core não é um requisito para 6VPE ou 6PE, mas poderá agregar maior flexibilidade e promover redução de custos para o operador de redes.<br /> [[Arquivo:Bpf-enciclopedia-6vpe.png|centro|miniaturadaimagem|600x600px|Enciclopédia: 6VPE]]<br /> <br /> ==== AAA ====<br /> Acrônimo: ''Authentication, Authorization, Accounting''.<br /> <br /> O AAA pode ser tratado como um framework ou um conjunto de especificações tecnológicas e recursos para a concepção de mecanismos mais seguros visando a admissão de usuários e endpoints (dispositivos) em uma rede. O AAA, além de representar um conjunto de procedimentos, é usado geralmente em combinação com protocolos e serviços tais como RADIUS, TACACS+ e Diameter. Como o próprio nome sugere, a proposta é a de fornecer métodos seguros visando a autenticação de usuário e/ou dispositivo (ex: computador, roteador CPE, ou outro tipo de dispositivo), a posterior autorização, o que, por sua vez, ditará propriedades para o acesso concedido, tais como a atribuição dinâmica de VLAN, uma ACL dinâmica, um ''Scalable Group Tag'' (SGT), atribuição de endereçamento IPv4 e IPv6 (muito comum no caso do PPPoE), dentre uma diversidade de outras variáveis que podem ser associadas ao usuário e/ou ao seu dispositivo. E, por último, a manutenção de registros de atividades para fins de auditoria daquele acesso, ou seja, o ''Accounting''.<br /> <br /> &lt;u&gt;Exemplos de cenários onde o AAA é empregado:&lt;/u&gt; controle de acesso centralizado aos equipamentos da rede por parte de operadores/administradores, e com autorização e registros de comandos na CLI, autenticação de portas de switches com o protocolo 802.1X (conhecido também como solução IBNS), controle de acesso e admissão à rede (uma evolução do IBNS conhecida por ''Network Access Control'' (NAC)), autenticação de assinantes PPPoE e IPoE em concentradores de serviços de Internet banda larga (BNG/BRAS), autenticação de usuários e dispositivos móveis em redes WLAN, dentre outros casos.<br /> <br /> ==== Access-List ====<br /> Uma Lista de Acesso (Access-List ou ACL) é uma ferramenta absolutamente versátil disponível em roteadores e switches, e também em outros tipos de equipamentos de redes, e que tem como principal proposta a de atuar como mecanismo de classificação de pacotes ou, alternativamente, em muitos casos, para classificação de rotas. Após a classificação de pacotes ou de rotas, dependendo de como e para que uma ACL estiver sendo utilizada, uma ação pode ser vinculada para o pacote ou para a rota, e conforme diretivas imputadas pelo administrador da rede.<br /> <br /> &lt;u&gt;Exemplos de cenários onde uma ACL é empregada:&lt;/u&gt; filtro ''stateless'' de pacotes (''stateless packet filtering''), filtro ''stateful'' de pacotes (''stateful packet filtering'', quando a ACL é vinculada em um roteador com suporte a firewall stateful), classificação de tráfego que deverá ou não sofrer tradução de endereços IP (em ambiente NAT e CGNAT), classificação de pacotes que deverão sofrer uma política de roteamento diferenciada para encaminhamento de tráfego &quot;bypassando&quot; a tabela de roteamento (uma PBR, ABF, e similares), classificação de pacotes para o posicionamento destes em classes de tráfego e posterior tratamento de qualidade de serviço (QoS), classificação de pacotes autorizados para serviços de gerenciamento do equipamento (acesso remoto à CLI por SSH, acesso remoto ao equipamento via SNMP, NETCONF, etc.), classificação dos pacotes de servidores NTP autorizados a sincronizar data/hora com o seu equipamento, classificação de rotas que deverão ser invocadas por um filtro de rotas ou por uma política de roteamento (para ''accept'' ou ''drop'', com ou sem modificação de atributos), e muitos outros.<br /> <br /> Uma ACL pode ser considerada um verdadeiro &quot;canivete suíço&quot;! No entanto, para algumas necessidades, há ferramentas melhores ou mais versáteis que uma ACL. Por exemplo, uma ''prefix-list'' ou ''prefix-set'' é mais flexível e adequada para filtrar rotas em uma policy de roteamento, do que usar uma ACL para este mesmo propósito.<br /> <br /> ==== AS ====<br /> Acrônimo: ''Autonomous System''.<br /> <br /> Conheça mais: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]].<br /> <br /> Um (o) sistema autônomo representa a coletânea de dispositivos de rede sob uma administração comum, e o termo é geralmente empregado para representar uma rede inteira de uma determinada empresa, seja ela um provedor de acesso à Internet (ISP), uma empresa do segmento corporativo, ou uma instituição qualquer. Em um primeiro momento, o AS tipifica exatamente isto: a &quot;rede&quot; daquela empresa, os seus equipamentos, as suas diretivas e políticas; ou seja, uma coisa mais abstrata. No entanto, algumas tecnologias levam o termo AS para as suas próprias funcionalidades, capacidades e propriedades, dando uma expedição bem mais tangível ao termo, e em sua forma mais prática e real. Uma desta tecnologias é o protocolo de roteamento BGP, como todo profissional de ISP sabe.<br /> <br /> No caso do BGP, o Sistema Autônomo (AS) não é apenas algo teórico, e sim o componente principal e real do próprio protocolo de roteamento. Você, de fato, define/configura o AS no BGP dos seus roteadores, juntamente com uma série de propriedades e parâmetros (tais como sessões, anúncios, filtros, políticas de roteamento, recursos adicionais/periféricos do BGP, etc.) para representar aquela rede e as suas respectivas políticas de roteamento, ou seja, havendo uma relação muito íntima e tangível com esta definição de AS. A Internet é composta por dezenas de milhares de sistemas autônomos, obviamente interconectados pelo protocolo de roteamento BGP.<br /> [[Arquivo:Bpf-enciclopedia-as.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Autonomous System (AS)]]<br /> <br /> ==== BGP ====<br /> Acrônimo: ''Border Gateway Protocol.''<br /> <br /> Conheça mais aqui: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]] e [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O BGP ou BGP-4 é um protocolo de roteamento do tipo vetor de caminhos e exterior (''path vector'' e EGP), e pode ser considerado como a base de todo o roteamento de Internet. Todo o funcionamento da Internet depende da boa operação do BGP e, sem ele, simplesmente não há a Internet. Obviamente que a Internet depende de muito mais coisas que o protocolo de roteamento BGP para funcionar, mas, sem dúvidas, ele é um componente tido como central.<br /> <br /> O protocolo de roteamento BGP tem sofrido muitos aditivos ao longo dos anos, com a adição de novas funcionalidades e recursos, dentre os quais convém destacar aqui o suporte às diversas famílias de endereços, tais como IPv4 Unicast, IPv6 Unicast, IPv4 Multicast, IPv6 Multicast, VPNv4, VPNv6, L2VPN, EVPN, Labeled Unicast, Traffic Engineering, e outros. Confira alguns destes recursos aqui:<br /> * [https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Border Gateway Protocol (BGP) Parameters], [https://www.iana.org/assignments/capability-codes/capability-codes.xhtml Capability Codes], [rfc:7606 Multiprotocol Extensions for BGP-4], [https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml Subsequent Address Family Identifiers (SAFI) Parameters], e há muitos outros.<br /> <br /> ==== BNG ====<br /> Acrônimo: ''Broadband Network Gateway''.<br /> <br /> Conheça mais: [[Concentradores PPPoE com IPv6]].<br /> <br /> O BNG substitui outro nome/termo, mais defasado, chamado BRAS, ou seja, apesar de serem termos intercambiáveis, recomenda-se, nos dias atuais, referenciá-lo como BNG. O BNG é essencialmente uma plataforma de roteamento equipada com funcionalidades, recursos, protocolos e serviços primários e periféricos orientados para a solução de conectividade de Internet banda larga, atendendo primariamente os assinantes residenciais, embora nada impeça que seja utilizado também para produto de Internet banda larga voltada ao segmento corporativo. O roteador BNG atua como dispositivo roteador (gateway) para as sessões autenticadas de usuários mantidas por ele (daí o termo &quot;concentrador BNG&quot;). O BNG é geralmente usado em combinação com outros componentes e procedimentos, sendo alguns destes mandatórios, enquanto outros são opcionais, variando conforme as definições de cada projeto técnico. Exemplos de tecnologias e procedimentos que &quot;casam&quot; com uma solução BNG: RADIUS, Diameter, PPPoE, IPoE, sejam estes arranjados sobre uma rede puramente Metro Ethernet + IP, ou FTTH/GPON + Metro + IP.<br /> <br /> ==== BRAS ====<br /> Acrônimo: ''Broadband Remote Access Server''.<br /> <br /> Vide o acrônimo BNG (Broadband Network Gateway).<br /> <br /> ==== Caches Enter-Deep ou Bring-Home ====<br /> O Enter-Deep Cache possui como estratégia estar profundamente fincado nas redes de acesso dos provedores de acesso à Internet (ISP), geralmente sendo adotados na forma de clusters implantados nas redes do ISP ao redor do mundo. Esta filosofia de cache foi introduzida pela Akamai e é usada por muitas empresas que seguiram na mesma filosofia. In a &quot;nutshell&quot;, e explicando isto de forma bem simplista e minimalista, como a coisa funciona, usando um exemplo simples envolvendo o Google: todos estes inúmeros ou quase incontáveis clusters localizados nas redes dos ISPs e nos data centers desta empresa no mundo compõem uma rede privada do Google. Sendo assim, quando um usuário faz uma requisição ou consulta de pesquisa, esta consulta tende a ser encaminhada primeiramente pelo provedor de acesso (ISP) local para um cache local próximo, de onde deverão sair conteúdos estáticos para o cliente enquanto este cache local, ao mesmo tempo, encaminha uma consulta pela rede privada do Google para um de seus data centers, de onde deverão sair os dados e resultados de pesquisa personalizadas para o cliente. Em um exemplo envolvendo um vídeo do YouTube, este vídeo poderá ser recuperado diretamente do cache local do ISP, se este possuir a arquitetura e se este conteúdo puder ser fornecido das proximidades deste enter-deep cache, enquanto os anúncios associados ao vídeo são recuperados a partir dos data centers do Google. Em geral, os serviços de nuvem do Google são fornecidos por uma infraestrutura de rede privada independente da Internet pública, daí as excepcionais vantagens dos ISPs em poderem contar, quando autorizados e sobre forte regime de contrato e NDA, com estas soluções baseadas enter-deep cache. Ganha o usuário, com acesso com latência mais baixa aos conteúdos, e ganha o ISP, com previsibilidade no tráfego e redução de custos com os enlaces de trânsito IP.<br /> <br /> Já a estratégia Bring Home (&quot;trazer para casa&quot;), é uma segunda filosofia de design adotada por muitas empresas de CDN. A proposta aqui é trazer os ISPs para &quot;casa&quot;, conectando clusters em pontos de presença (PoPs) construídos através de uma rede privada de alta velocidade, ao invés de implantar estes clusters diretamente nas infraestruturas de redes dos ISPs. Estes pontos de presença (PoPs) geralmente ficam mais próximos aos operadores de redes Tier-1, podendo estender-se para além destes em alguns casos. Comparado com o enter-deep cache em termos de filosofia de design, o Bring Home normalmente resulta em menores custos de manutenção, mas é menos interessante no ponto de vista de latência e taxas de transferências de dados para os usuários finais, quando comparando estes benefícios com a filosofia do Enter-Deep cache.<br /> <br /> ==== CDN ====<br /> Acrônimo: ''Content Delivery Network''.<br /> <br /> Conheça mais: [[CDN Peering e PNI - Brasil]].<br /> <br /> Ou Rede de Fornecimento de Conteúdo. Uma CDN é um sistema de servidores amplamente distribuídos que fornece acesso à páginas e à diversos tipos de conteúdos para os usuários da Internet, e com base em uma diversidade de métricas e procedimentos, tais como a geolocalização do assinante/usuário, local de origem dos conteúdos, e centros de distribuição de dados (que hospedam uma CDN) em melhores condições de fornecerem o conteúdo para o usuário requisitante, para citar algumas destas métricas e procedimentos.<br /> <br /> Como principais benefícios, as CDN asseguram menores índices de latência no fornecimento de conteúdo para os usuários requisitantes, um benefício percebido pelos próprios usuários finais, pois estes terão uma melhor experiência de consumo destes conteúdos, e permite excelentes capacidades de engenharia de rede e de tráfego para os serviços de trânsito; melhor cenário financeiro na questão de despesas operacionais de médio e longo prazos, o que seria um ótimo benefício para os ISPs que contarem com as CDNs de diversos fornecedores de conteúdos. Ou seja, ganha o usuário, com maior fluidez e experiência de consumo de conteúdos, e ganha o ISP, com seus clientes mais satisfeitos com a experiência de navegação, além dos resultados com as despesas operacionais de médio e longo prazos.<br /> <br /> ==== CFP ====<br /> Acrônimo: ''C form-factor pluggable (CFP)''.<br /> <br /> O CFP é resultante de um acordo do tipo ''multi-source agreement'' estabelecido entre os principais fabricantes de soluções da indústria para a produção de um transceptor ótico para transmissão de sinais de alta velocidade. O CFP foi desenvolvido primariamente para redes Ethernet em 100 Gbps, operando nas em 10 vias a 10 Gbps em cada sentido (Tx e Rx), ou 4 vias a 25 Gbps, também em cada sentido. As variações existentes:<br /> <br /> &lt;u&gt;CFP&lt;/u&gt; (82 mm × 13.6 mm × 144.8 mm, conexão elétrica de 148 pinos, consumo inferior a 24 W, 10×10G ou 4×25G vias). &lt;u&gt;CFP2&lt;/u&gt; (41.5 mm × 12.4 mm × 107.5 mm, conexão elétrica de 104 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 12 W, 10×10G, 4×25G, 8×25G, ou 8×50G vias, Analog Coherent Optics (ACO)). &lt;u&gt;CFP4&lt;/u&gt; (21.5 mm × 9.5 mm × 92 mm, conexão elétrica de 56 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 6 W, 4×10G ou 4×25G vias). &lt;u&gt;CFP8&lt;/u&gt; (40 mm × 9.5 mm × 102 mm, conexão elétrica de 124 pinos, sem DSP, consumo máximo de 24 W, 16×25G vias (25.78125 ou 26.5625 GBd) ou 8×50G vias). &lt;u&gt;MSA 5″×7″ (Gen 1)&lt;/u&gt; (conexão elétrica de 168 pinos, embarca DSP, consumo inferir a 80 W). &lt;u&gt;MSA 4″×5″ (Gen 2)&lt;/u&gt; (conexão elétrica de 168 pinos, DSP, consumo elétrico inferior a 40 W).<br /> <br /> ==== CGNAT ====<br /> Acrônimo: ''Carrier-Grade Network Address Translation (CGNAT ou CGN).''<br /> <br /> O CGNAT é ao mesmo tempo uma solução e um mal necessário, sempre requerido quando não há endereços IPv4 públicos suficientes para atender toda a base de clientes de um ISP. Em termos mais técnicos, o CGNAT é essencialmente uma tecnologia que realiza a tradução dos endereços IPv4 de origem dos assinantes/clientes/usuários, onde estes são geralmente endereçados com endereços IP da faixa 100.64.0.0/10 ([rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]), e não com os endereços IPv4 privativos previstos pelo RFC 1918, como alguns acreditam, para um endereço IPv4 público. O CGNAT difere da solução NAT tradicional por sofrer algumas modificações para viabilizar a tradução de endereços em larga escala e atendendo, dependendo da plataforma, a dezenas de milhares de usuários, daí o termo &quot;''carrier grade''&quot;. A principal diferença entre CGNAT e NAT é que o CGNAT é configurado para fazer a tradução do endereço IP de origem e respectivas portas usadas na conversação, mas &lt;u&gt;sem&lt;/u&gt; manter quaisquer informações referentes aos endereços IP e portas de destino, sendo isto, inclusive, um dos principais motivos pelos quais o CGNAT escala para milhões de traduções simultâneas de endereços. Há diversas abordagens de CGNAT, tanto ''stateful'' quanto ''stateless'', tais como NAT44, NAT444 / Double NAT 44, em regime determinístico ou pré-definido, ou ainda em alocação de portas em massa (Bulk Port Allocation (BPA)), ou ainda em combinação com técnicas de transição para IPv6 de assinantes com NAT 64SL, NAT64SF, IPv6 Rapid Deployment (6rd), Dual-Stack Lite (DS-Lite), e MAP-T/E<br /> <br /> Como boa prática, o CGNAT não deve substituir a necessidade pela adoção do protocolo IPv6 nas redes dos ISPs. Aliás, inclusive, estimulamos que o IPv6 seja adotado o mais rapidamente possível para a sua infraestrutura ficar cada vez menos refém do CGNAT, pois há limitações e aborrecimentos associados a esta tecnologia. Quanto mais IPv6 você possuir em sua rede, menor será a dependência por CGNAT!<br /> <br /> ==== Control Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Controle. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, que é responsável por hospedar diversos dos protocolos e serviços para funções de redes nas Camadas 2 e 3, assim como as respectivas estruturas de dados mantidas pelos processos de cada um destes protocolos e serviços.<br /> <br /> Exemplos de protocolos que atuam nesta área do equipamento: Spanning Tree Protocol (STP), Resilient Ethernet Protocol (REP), Ethernet Automatic Protection Switching (EAPS), G.8032 Ethernet Ring Protection Switching, Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP), Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP), Resource Reservation Protocol for Traffic Engineering (RSVP-TE), Address Resolution Protocol (ARP), e muitos outros, lembrando que estes protocolos mantém as suas estruturas de dados, tais como LSDB (OSPF), LIB (LDP), BGP Table (BGP), ARP Cache (ARP), etc. A tabela de roteamento, também conhecida por RIB, é mantida no plano de controle dos roteadores.<br /> [[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]<br /> <br /> ==== CPAK ====<br /> <br /> ==== Data Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Dados. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, e que mantém as estruturas de dados relacionadas às ações de processamento de quadros (no L2) e pacotes (no L3). Estruturas de dados tais como a Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), Adjacency Table, Content Addressable Table (CAM ou MAC Table), são exemplos de estruturas de dados mantidas no Data Plane. As arquiteturas modernas de roteadores e switches tendem a combinar múltiplas estruturas de dados primárias e periféricas, geralmente mantidas em componentes de hardware especializados do equipamento, para construir e programar o ''pipeline'' de processamento de pacotes, para que, além da óbvia comutação do quadro ou o roteamento do pacote, outras ações possam ser executadas sobre os pacotes, tais como a determinação se um determinado pacote deverá ser tratado como L2 ou L3, consulta ou lookup de endereços IP, consulta à listas de controle de acesso (ACL), policiamento de taxa, queueing e prioridades, manipulação de cabeçalhos L2 e L3 (marcação, tradução de endereços, operações com tags de VLAN, operações com labels MPLS), etc. Exemplos de estruturas assim são as Ternary Content Addressable Memory (TCAM) e arranjos Tree-Bitmap (TBM) e M-trie.<br /> [[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]<br /> <br /> ==== DDoS ====<br /> Acrônimo: ''Distributed Denial of Service''.<br /> <br /> Conheça mais: [[O Minimo que voce precisa saber sobre DDoS|O Mínimo que você precisa saber sobre DDoS]] e [https://youtu.be/l2tVyz1Ba1A &lt;nowiki&gt;[BPF] Entrevista com o Thiago Ayub sobre ataques e mitigação DDoS&lt;/nowiki&gt;].<br /> <br /> Atividade criminosa que tem por objetivo promover a interrupção das operações de uma infraestrutura de redes através da sua incapacidade de continuidade de prestação dos serviços. Ou seja, como o próprio nome sugere, é um ataque de negação de serviços, porém distribuída, no sentido que milhares de dispositivos na Internet são controlados de forma maliciosa para lançarem ataques contra uma rede. Redes que são vitimadas sofrem dois padrões de distúrbios primários, sendo o primeiro o esgotamento de recursos computacionais dos equipamentos da rede, e, o segundo, a saturação dos enlaces de trânsito IP. Em qualquer uma das circunstâncias, os efeitos são muito negativos e percebidos pelos clientes do ISP afetado pela atividade criminosa. Os motivadores dos ataques de DDoS tem sido cada vez mais preocupantes, e são cada vez mais frequentes as situações envolvendo competidores inescrupulosos de um ISP que está sendo vítima de um ataque, mas há também muitos casos de criminosos que atacam ISPs por &quot;profissão e esporte&quot;, exigindo quantias em - sempre por pagamentos em criptomoedas, tais como o Bitcoin - para encerrar os ataques.<br /> <br /> ==== De-Peering ====<br /> Como o próprio nome sugere, é uma ação de desfeita de peering entre dois participantes ou entre um participante principal e múltiplos (dezenas) de outros participantes. O de-peer significa o encerramento da relação e a respectiva desconexão do acordo de peering entre dois sistemas autônomos. Mesmo que, de certa forma, um tanto raros, as motivações de um &quot;de-peer&quot; ou &quot;de-peering&quot; frequentemente estão associadas a mudanças na política de peering da organização principal, ou quando uma das duas partes envolvidas naquela relação de peering viola algum termo do acordo, algo que costuma promover o que chamamos de &quot;network clean-up&quot;. Algumas situações que tipificam e até mesmo justificam um de-peering: uma das duas partes está recebendo tráfego malicioso (ex: DDoS) excessivamente, e o acordo de peering pode ser interrompido em função disto. Violação da política de roteamento, onde um dos participantes injeta informações errôneas através desta sessão de peering (ex: route leak, hijack de prefixos, e &quot;vacilos&quot; similares), e isto é agravado quando a parte é reincidente, o que poderia justificar o cancelamento do acordo de peering. Mudanças na política de roteamento e peering de um dos participantes, e o entendimento que o referido acordo entre ambas as partes não é mais necessário ou interessante, ou ainda que a outra parte não mais atende os pré-requisitos para a manutenção deste acordo. E, para finalizar, possíveis problemas envolvendo capacidades e custos. Não é a toa que as modalidades de interconexão pagas (paid peering) tem se popularizado, em particular para lidar com as questões de capacidade e custos que em alguns casos poderiam justificar um de-peer de um ou mais participantes.<br /> <br /> ==== EAQ ====<br /> Acrônimo: ''Entidade Aferidora de Qualidade''<br /> <br /> A Entidade Aferidora da Qualidade (EAQ) foi criada em atendimento às Resoluções da Anatel 574 e 575 de 28 de outubro de 2011. A EAQ é parte do processo de aferição dos indicadores de qualidade das redes de telecomunicações que suportam o acesso à internet em Banda Larga fixa e móvel no Brasil, e a seleção desta entidade é feita de forma a garantir o cumprimento do Regulamento de Gestão da Qualidade do Serviço de Comunicação Multimídia - RGQ-SCM, aprovado pela Resolução nº 574, de 28 de outubro de 2011 e do Regulamento de Gestão da Qualidade da Prestação do Serviço Móvel Pessoal - RGQ-SMP, aprovado pela Resolução nº 575, de 28 de outubro de 2011.<br /> <br /> ==== eNodeB ====<br /> O Nó B do E-UTRAN, também conhecido como Evolved Node B ou eNodeB ou eNB, é o elemento no E-UTRA do LTE que é a evolução do elemento Nó B no UTRA do UMTS. É o hardware conectado à rede de telefonia móvel que se comunica diretamente sem fio com os telefones móveis (UEs), como uma estação base de transceptores (BTS) nas redes GSM. Tradicionalmente, um Nó B tem funcionalidade mínima e é controlado por um Radio Network Controller (RNC). No entanto, com um eNB, não há elemento controlador separado. Isso simplifica a arquitetura e permite menores tempos de resposta.<br /> <br /> ==== Ethernet ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O Ethernet é uma arquitetura de interconexão para redes de computadores, originalmente pensada para os ambientes de Redes de Áreas Locais (LAN), pois, naquele tempo, o Ethernet não era funcional para comunicações a longa distância, tais como circuitos de WAN e redes Metropolitanas (MAN). A tecnologia de transmissão do Ethernet é por regime estatístico e baseada no encaminhamento de quadros (''frames''). O Ethernet é especificado para velocidades de operação selecionadas entre 10 Mbps e 400 Gbps, usando uma especificação comum de controle de acesso ao meio físico (''Media Access Control'' ou MAC). O mecanismo de contenção para o compartilhamento do meio físico no Ethernet é feito por um procedimento denominado ''Carrier Sense Multiple Access with Detection Collision Detection'' (CSMA / CD), definindo tanto a operação de mídia compartilhada (half duplex), bem como a operação em full duplex. Ao longo dos anos o Ethernet sofreu vários aditivos para acomodar novas funcionalidades e capacidades, dentre as quais posso destacar aqui os padrões DCBX para o funcionamento do Ethernet em ambientes de Data Center críticos, por exemplo, permitindo transportar o ''Fibre Channel'' diretamente sobre o Ethernet (FCoE), e também os padrões Metro Ethernet / Carrier Ethernet que fizeram com que o Ethernet aos poucos fosse evoluindo e sendo adotado pelos operadores de rede / service providers / ISP, a ponto de hoje ser a tecnologia de enlace predominante neste setor. Os principais atrativos do Ethernet incluem a flexibilidade e excelente relação custo x benefício, especialmente quando comparado às tecnologias de transmissão determinísticas (ex: SDH), sendo este fator econômico o principal motivo quanto a expansão do Ethernet para os ISPs.<br /> <br /> ==== EVPN ====<br /> Acrônimo: ''Ethernet Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> Tecnologia de transporte de serviços de Camada 2 (L2) sobre infraestrutura MPLS ou VxLAN, ou seja, L2VPN, em especial buscando, através da evolução tecnológica e pela qualidade de suas ferramentas, cumprir com os mesmos objetivos da soluções L2VPN MPLS tradicionais, tais como o VPLS, H-VPLS e VPWS, sejam estes em implementação Martini ou Kompella, porém sem incorrer nas mesmas dificuldades e complexidades associadas a estes tecnologias clássicas. Em outras palavras, o EVPN é a legítima evolução da tecnologias L2VPN tradicionais, pois resolve muitos dos conhecidos desafios dos setups típicos de L2VPN. O EVPN tem como principal proposta a implementação de uma diversidade muito ampla de serviços L2 sobre infraestruturas baseadas no IP/MPLS e em regimes ponto-a-ponto e multiponto, sendo ideal para atendermos às demandas por L2VPN dos dias atuais e com maior flexibilidade e elasticidade. Como benefícios, o EVPN não exige um protocolo adicional como ocorre no L2VPN MPLS clássico (em especial a implementação Martini), e também não exige o emprego de Pseudowires. O EVPN usa o MP-BGP (mais precisamente o AFI 25 e SAFI 70) para trocar rotas específicas para esta família de endereços, promove maior eficiência no aprendizado e distribuição de endereços MAC, e com aprendizado destes ocorrendo no plano de controle, e não no plano de dados, permite redundância &quot;''All-Active''&quot;, além de outras interessantíssimas capacidades e recursos.<br /> <br /> ==== FlowSpec ====<br /> Acrônimo: ''BGP Flow Specification''.<br /> <br /> O recurso ou tecnologia BGP ''flow specification'' (flowspec) permite definir procedimentos para codificar regras de especificação de fluxo na forma de BGP ''Network Layer Reachability Information'' (NLRI) que podem ser usadas em diversas situações, sendo que a sua principal proposta é viabilizar o filtro de pacotes com o objetivo de mitigação de ataques de negação de serviços do tipo DDoS. Para se ter uma idéia, nos métodos tradicionais de mitigação de DDoS, como é o caso do RTBH (''Remotely Triggered Black Hole Filtering'' ou &quot;buraco negro disparado remotamente&quot;), uma rota BGP é injetada anunciando o endereço do site sob ataque juntamente com uma community BGP específica para este propósito de proteção. Essa community especial nos roteadores de borda serve para definir o próximo salto para um próximo salto especial - ou seja, uma modificação proposital do atributo &quot;NEXT_HOP&quot; da referida rota BGP - para descartar ou anular pacotes destinados àquele alvo, ou seja, permitindo que o tráfego de ataque destinado ao endereço IP/alvo seja descartado no backbone do ISP. Mesmo que isto permita oferecer boa proteção, a estratégia com o uso do RTBH torna o servidor ou host configurado com aquele endereço IP completamente inacessível. Por outro lado, o BGP flowpecpec permite uma abordagem mais granular e permite ainda que você efetivamente construa instruções para combinar um fluxo específico com a origem, destino, parâmetros L4 e especificações de pacotes, como comprimento, fragmento etc., possibilitando uma instalação dinâmica de uma ação nos roteadores de borda para: a) descartar o tráfego lançado contra o alvo. b) injetar o tráfego em uma VRF específica para uma análise mais detalhada. c) policiamento da taxa deste tráfego identificado pelo flowspec. Portanto, em vez de associar uma rota com uma community especial (RTBH) para que os roteadores de borda façam o descarte &quot;cru e nu&quot; do pacote, o BGP flowspec envia um formato de fluxo específico aos roteadores de borda, instruindo-os a criar uma espécie de ACL para que seja possível construir uma política com uma ação que você desejar (os casos &quot;a&quot;, &quot;b&quot; e &quot;c&quot; citados previamente). Para conseguir isso, o BGP flowspec adiciona um novo NLRI ao protocolo BGP, possibilitando fornecer detalhes sobre especificações de fluxos, critérios de correspondência (&quot;matching&quot;) suportados e ação de filtragem de tráfego.<br /> <br /> O BGP Flowspec é um aditivo muito sofisticado para as intenções dos ISPs na questão de mitigação de ataques DDoS em suas infraestruturas.<br /> <br /> ==== FTTH ====<br /> Acrônimo: ''Fiber-to-the-Home''.<br /> <br /> O &quot;''Fiber To The Home''&quot; (FTTH), também chamado de &quot;''Fiber To The Premises''&quot; (FTTP) ou ''&quot;Fiber To The Building''&quot; (FTTB), é o conceito de projeto, instalação o uso de fibra ópticas a partir de um ponto central diretamente para edifícios individuais, como residências, edifícios de apartamentos e empresas, para fornecer acesso à Internet em alta velocidade. O ''Fiber to the Home'' (FTTH) em si é um tipo de rede de acesso que oferece a alta velocidade de conexão à Internet, usando fibra óptica que é executada diretamente na casa, no prédio ou no escritório do assinante/cliente. O FTTH oferece aos consumidores acesso a uma grande variedade de aplicativos interativos, como comunicação por vídeo, jogos, vídeo sob demanda, teletrabalho e eSaúde, dentre uma diversidade muito grande aplicações que são possíveis com o uso de uma rede relativamente muito simples, porém bastante efetiva, e com ótima relação custo/benefício.<br /> <br /> ==== GGSN ====<br /> Acrônimo: ''Gateway GPRS Support Node''.<br /> <br /> O ''Gateway GPRS Support Node'' (GGSN) é um dos dois componentes do domínio ''Packet-Switched'' (PS) ''General Packet Radio Services'' (GPRS). O GGSN, juntamente com o SGSN (''Serving GPRS Support Node'', que entrega pacotes de dados de e para as estações móveis dentro de sua área de serviço), lida com transmissões de pacotes entre a rede GPRS e redes externas de baseadas em comutação de pacotes, como a Internet ou até mesmo de infraestruturas mais legadas baseadas em pacotes, como é o caso de uma rede X.25. Do ponto de vista de uma rede externa, o GGSN é um roteador para uma subrede, porque o GGSN acaba por &quot;ocultar&quot; a infraestrutura GPRS da rede externa. Quando o GGSN recebe dados endereçados a um usuário específico, verifica se o usuário está ativo. Caso afirmativo, o GGSN encaminha os dados para o SGSN que atende o usuário móvel, mas, caso o usuário móvel estiver inativo, os dados serão descartados. Na outra direção, os pacotes de origem móvel são roteados para a rede correta pelo GGSN, que é o ponto de ancoragem que permite a mobilidade do terminal do usuário nas redes GPRS / UMTS, onde, essencialmente, ele desempenha o papel no GPRS equivalente ao agente doméstico no IP móvel, e mantém o roteamento necessário para encapsular as unidades de dados de protocolo (PDUs) para o SGSN que atende uma determinada estação móvel (MS).<br /> <br /> ==== GPON ====<br /> Acrônimo: ''Gigabit Passive Optical Network''.<br /> <br /> ==== H-VPLS ====<br /> Acrônimo: ''Hierarchical Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN MPLS orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. A diferença primária entre H-VPLS e VPLS é que o H-VPLS procura promover uma hierarquia para o estabelecimento dos pseudowires e a efetiva troca de tráfego L2 entre os sites participantes, e com o objetivo de aprimoramos a escalabilidade e a eficiência da solução VPLS. Um dos maiores benefícios do H-VPLS é a redução do overhead de sinalização e também dos requerimentos de replicação de pacotes sobre os roteadores provider edge (PE). No H-VPLS, dois tipos de dispositivos PE são definidos: o u-PE e n-PE. O u-PE recebe o tráfego L2 nativo do cliente e faz as funções L2 locais, agrega o tráfego e o encaminha até o roteador n-PE, que é onde, de fato, ocorre o encaminhamento do tráfego pelo VPLS e com base no ''Virtual Switching Instance'' (VSI).<br /> <br /> ==== Hub-and-Spoke ====<br /> <br /> ==== IPFIX ====<br /> Acrônimo: ''Internet Protocol Flow Information Export''.<br /> <br /> O ''IP Flow Information Export'' (IPFIX), é um protocolo que especifica um método para que engenheiros de redes consigam exportar dados analíticos referentes aos fluxos de tráfego que percorrem em suas redes ou sistemas autônomos para estações coletoras, devidamente equipadas com soluções específicas baseadas em software, para fins de compreenderem com clareza as matrizes de comunicação referentes aos endereços IP de origem, endereços IP de destino, ordenamento de protocolos detectados ou registrados nestas conversações, portas de origem e destino (para o caso de TCP e UDP), marcações de QoS indicadas (ex: DSCP), sistemas autônomos envolvidos, volumetria destes fluxos que representam estas conversações, &quot;''top talkers''&quot;, dentre outros dados extremamente úteis. O IPFIX é um protocolo de padrão aberto que visa promover maior flexibilidade se comparado ao NetFlow da Cisco, seja na versão &quot;10&quot;, 9 ou 5, ao Juniper JFLOW, que é bastante similar ao NetFlow v5 da Cisco, e ao CFLOW. Comparativamente, o IPFIX contém os mesmos 79 campos do NetFlow v9, mas vai além e acomoda até 238 campos, o que possibilita uma lista bastante extensa de informações para atender a muitas das necessidades dos engenheiros de redes, e estando um passo à frente para inovações futuras. Assim como NetFlow/CFLOW/JFLOW, o IPFIX tem como proposta primária auxiliar profissionais de redes e empresas no planejamento de capacidades, bilhetagem e tarifação de tráfego, detecção e prevenção de incidentes de segurança, resposta automática a ataques de negação de serviço com acionamento de RTBH, dentre outras conhecidas aplicações. Vide &lt;nowiki&gt;RFC 7011&lt;/nowiki&gt; (''Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information'') para maiores informações.<br /> <br /> ==== IPoE ====<br /> Acrônimo: ''IP over Ethernet.''<br /> <br /> O ''Internet Protocol (IP) over Ethernet'' (IPoE) é uma das soluções adotadas para a disseminação do produto de Internet banda larga nas redes dos provedores de acesso à Internet. É basicamente uma forma de fornecer tráfego de Internet banda larga sem o encapsulamento PPP sobre o Ethernet. Atualmente, a tecnologia predominante para a autenticação e autorização de assinantes de Internet banda larga é o ''Point-to-Point Protocol over Ethernet'' (PPPoE), que, apesar de estar presente na grande maioria das instalações, possui alguns desafios e diversas limitações. O IPoE entra nesta seara justamente para substituir o PPPoE nos concentradores de assinantes (conhecidos por plataformas BNG ou BRAS), ou seja, para conquistarmos maior flexibilidade com a oferta de serviços para os assinantes sem incorrermos nos problemas e desafios associados ao uso massivo do PPPoE nestes equipamentos concentradores, dentre outras características, vantagens e benefícios. Dentre as principais vantagens em substituir o PPPoE pelo IPoE está na eliminação de um protocolo específico para o procedimento (PPP), consequentemente havendo uma redução bastante satisfatória do processamento dos equipamentos concentradores, pois, um dos principais &quot;problemas&quot; do PPPoE é que este introduz um cabeçalho adicional de 8 bytes de comprimento para cada pacote entre o dispositivo CPE/CE (assinante) e o concentrador onde a sessão do usuário foi autenticada e está estabelecida. E os concentradores de assinantes precisam manter o estado destas sessões para realizar diversos procedimentos para a manutenção do serviço do assinante. Outro &quot;problema&quot; do PPPoE está em sua dificuldade em lidar eficientemente com o tráfego Multicast, sendo que este problema não está presente o IPoE, o que pode ser um fator determinante para optar pelo IPoE para assinantes de Internet banda larga com o produto IPTV. O IPoE não é o &quot;the new kid on the block&quot;, e está por aí desde os primórdios do &lt;nowiki&gt;RFC 894&lt;/nowiki&gt;, sendo inclusive suportado há muitos anos pelos principais produtos concentradores do mercado.<br /> <br /> ==== IPv4 ====<br /> Acrônimo: ''Internet Protocol version 4''.<br /> <br /> ==== IPv6 ====<br /> Acrônimo: ''Internet Protocol version 6''.<br /> <br /> ==== IRR ====<br /> Acrônimo: ''Internet Routing Registry''.<br /> <br /> O ''Internet Routing Registry'' (IRR) é um banco de dados que possui objetos inseridos e mantidos através de uma linguagem própria denominada ''Routing Policy Specification Language'' (RPSL). Estas construções RPSL são expressas em diversos tipos de objetos dos bancos de dados que estão registrados em Registros Regionais da Internet (RIRs), os quais podem ser consultados pelo serviço Whois. Cada tipo de objeto de uma base de dados IRR pode representar um determinado tipo de informação, tal como um prefixo de propriedade ou alocado para um ISP, um objeto que divulgue a sua política de roteamento, ou um objeto que represente informações de contato administrativo e de suporte técnico, dentre outros tipos de objetos. O uso correto dos recursos de uma base IRR é amplamente estimulado entre os provedores de acesso à Internet para que cada um publique corretamente os seus prefixos (a título de objetos &quot;''route''&quot; e &quot;''route6''&quot;), os seus grupos representando, cada qual, seus upstreams de trânsito, peerings, e cones de clientes (por meios de objetos &quot;''as-set''&quot;), a divulgação da intenção em termos de política de roteamento (por meios de objetos &quot;''aut-num''&quot;, com campos &quot;''import''&quot;, &quot;''export''&quot;, &quot;''mp-import''&quot; e &quot;''mp-export''&quot;), além de objetos representando ações administrativas, tais como pessoal de contato para suporte (objetos &quot;''person''&quot; e &quot;''role''&quot;). A manutenção dos objetos em uma base IRR por um ISP é fundamental para que haja um consenso na Internet sobre como os filtros de anúncios devem ser construídos pelos Sistemas Autônomos, assim como fornecer a devida visibilidade para o acionamento dos times de suporte quando problemas ocorrerem com o roteamento de Internet envolvendo um determinado Sistema Autônomo. O ''Mutually Agreed Norms for Routing Security'' (MANRS) inclusive estabelece como dois dos seus principais objetivos a &quot;Coordenação&quot; e &quot;Validação Global&quot; entre os ISPs, cujas as ações são bastante centradas nos registros de objetos nas bases de dados de IRR, e com a divulgação do objeto &quot;''as-set''&quot; principal do ASN em seu cadastro no site PeeringDB. É importante salientar que muitos ISPs produzem filtros automaticamente com base nos registros de um sistema autônomo especificados numa base conhecida de IRR, daí a importância em certificar-se que o seu AS tenha os dados corretos inseridos na base de dados de um IRR, pois, a qualquer momento, algum ISP upstream poderá simplesmente recusar o recebimento de anúncios que tiverem sido originados no seu ASN, justamente por não haver consistência destas informações nos registros de uma base IRR.<br /> <br /> ==== IRU ====<br /> Acrônimo: ''Indefeasible Right of Use''.<br /> <br /> O direito de uso indefiável (IRU) é um tipo de contrato permanente de locação de telecomunicações, que não pode ser desfeito, entre os proprietários de um sistema de comunicações e um cliente desse sistema. A palavra &quot;indefiável&quot; significa &quot;incapaz de ser anulado ou desfeito&quot;. O IRU é o arrendamento efetivo de longo prazo (propriedade temporária) de uma parte da capacidade de um cabo submarino ou de outra infraestrutura de telecomunicações. Um exemplo deste tipo de arrendamento seria um IRU especificando um determinado número de canais de uma determinada largura de banda por um período bastante prolongado de uso. Neste caso, o IRU é concedido pela empresa ou consórcio de empresas que construíram o cabo, oferecendo a um provedor de serviços de Internet a capacidade de garantir à seus próprios clientes o trânsito internacional sobre este referido cabo, na capacidade assegurada pelo IRU, e por um período de prazo bastante prolongado.<br /> <br /> ==== IX ====<br /> Acrônimo: ''Internet Exchange''.<br /> <br /> Vide Ponto de Troca de Tráfego (PTT).<br /> <br /> ==== Jitter ====<br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> <br /> O jitter é a variação de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das &quot;especificações biológicas&quot; (auditivas e/ou visuais) do ser humano, que é o indivíduo que está interagindo com a aplicação através da rede com transmissões com níveis de jitter acima dos padrões aceitáveis.<br /> [[Arquivo:Bpf-qos-6.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Jitter]]<br /> <br /> ==== L2VPN ====<br /> Acrônimo: ''Layer 2 Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> O ''Layer 2 Virtual Private Network'' (L2VPN) consiste em um conceito que representa um conjunto de tecnologias orientadas ao transporte de serviços L2 sobre uma infraestrutura baseada no IP, com ou sem o auxílio do MPLS. Enquadram-se neste caso as tecnologias que obviamente exigem o MPLS para operar, como é o caso do ''Virtual Private LAN Service'' (VPLS), para a construção e transporte de redes L2 em regime multiponto, e o ''Virtual Private Wire Service'' (VPWS), para a construção e transporte de redes L2 em regime ponto-a-ponto, sendo que ambos operam sobre uma infraestrutura MPLS.<br /> <br /> Tecnologias de &quot;''tunneling''&quot; não deixam de ser também soluções de L2VPN, pelo menos no que diz respeito à privacidade e a segregação de serviços L2 de assinantes distintos sobre uma rede IP. Outro exemplo clássico de solução para este propósito é o ''Virtual Extensible LAN'' (VxLAN), muito utilizado em ambientes de data center como cenário centrado na elasticidade de domínios L2 e excelente mobilidade de workloads/VMs. E também, mais recentemente, a evolução das soluções L2VPN tradicionais para o ''Ethernet VPN'' (EVPN).<br /> <br /> No entanto, quando utilizando o termo &quot;L2VPN&quot;, estamos quase sempre nos referindo aos clássicos modelos VPLS e VPWS empregados nas redes MPLS dos operadores de rede, e estes serviços são provisionados com o auxílio de ''pseudowires'' com o protocolo LDP em vizinhança direcionada (T-LDP) entre os roteadores participantes de um determinado serviço, o que seria a proposta de implementação ''Martini'', ou então com o protocolo BGP, para a descoberta de vizinhos e também para o procedimento de sinalização, o que seria a proposta de implementação ''Kompella''.<br /> <br /> O principal objetivo da L2VPN é viabilizar o transporte de serviços L2, primariamente o Ethernet, através de uma rede completamente baseada no IP+MPLS, e sem que seja necessário estender as VLANs destes clientes atendidos através do backbone do operador de redes ou ISP. Ganha-se muito na questão operacional, além de aprimoramentos de indicadores importantes tais como a escalabilidade, confiabilidade, resiliência e melhor facilidade para o provisionamento e manutenção destes serviços. Os operadores de redes encontram no L2VPN uma forma bem adequada de fornecer serviços atraentes para seus clientes, tais como LAN-to-LAN, ''Data Center Interconnect'', &quot;''Clear Channel''&quot;, dentre outros, sem incorrer nas complexidades e riscos associados ao emprego das tecnologias L2 básicas em suas infraestruturas, tais como o entroncamento excessivo de VLANs de clientes nos uplinks do backbone, no provisionamento e manutenção de instâncias de protocolos de resiliência L2 (que são pouco escaláveis e um tanto inseguros em redes grandes), os riscos eminentes de ocorrerem ''bridging loops'' em função das extensões destas VLANs de clientes e respectivos protocolos de resiliência L2 no backbone do ISP, dentre outros argumentos muito sólidos.<br /> <br /> As L2VPNs podem ser utilizadas também para o transporte de tecnologias legadas sobre uma infraestrutura IP+MPLS, conforme tipificado pela solução ''Any Transport over MPLS'' (AToM) como um todo, permitindo, além do próprio Ethernet, o transporte de redes ''Asynchronous Transfer Mode'' (ATM), ''Frame Relay'', enlaces ponto a ponto ''High-Level Data Link Control'' (HDLC) e ''Point-to-Point Protocol'' (PPP), e até mesmo de outras tecnologias de transmissão digital, porém de natureza determinística (e não estatística, como seria o caso do Ethernet e do IP!), tais como ''Plesiochronous Digital Hierarchy'' (PDH) e ''Synchronous Digital Hierarchy'' (SDH)! Ou seja, soluções tais como o HDLCoMPLS, PPPoMPLS, FRoMPLS, CESoPSN, SAToP, TDMoIP, procedimentos GFP + LCAS + VCAT, etc. Para entender melhor estes casos, um tanto atípicos para os dias atuais, consulte o RFC 3985 (''Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture'') e outros RFCs. <br /> [[Arquivo:Bpf-enciclopedia-l2vpn.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN]]<br /> <br /> ==== L3VPN ====<br /> Acrônimo: ''Layer 3 Virtual Private Network''.<br /> <br /> ==== Latência ====<br /> Latência de rede é o termo usado para indicar qualquer tipo de atraso que ocorra na comunicação de dados em uma rede. As conexões de rede nas quais ocorrem pequenos atrasos são chamadas de redes de baixa latência, enquanto as conexões de rede que sofrem de longos atrasos são chamadas de redes de alta latência. A alta latência cria gargalos em qualquer comunicação de rede e impede que os dados tirem proveito máximo do canal de rede, diminuindo efetivamente a largura de banda de comunicação, além de apresentae aquela sensação de &quot;rede lenta&quot;. O impacto da latência na largura de banda da rede pode ser temporário ou persistente, com base na origem destes atrasos. Em termos práticos, a latência pode ser definida pelo tempo que leva para uma solicitação viajar do remetente para o destinatário e para o destinatário processar essa solicitação e fornecer a resposta para o remetente. Em outras palavras, o tempo de ida e volta do seu navegador para um servidor. Obviamente, é desejável que esse tempo permaneça o mais próximo possível de 0, no entanto, pode haver muitas coisas em jogo para impedir que os tempos de latência de um determinado serviço permaneçam baixos. Diversos elementos fatoram para o aumento da latência, dentre eles os atrasos de natureza fixa (serialização, transmissão e propagação) e os de natureza variável (processamento e enfileiramento/queueing), sendo que todos estes atrasos são adicionados por cada elemento de rede ativo que existir no caminho entre o cliente e o servidor. A latência pode e deve ser objeto de estudos e trabalhos de reestruturações tanto do aparato tecnológico em si (categoria dos elementos ativos, tais como roteadores, switches e concentradores) quanto das ações de engenharia de rede (organização topológica, emprego efetivo de recursos nos locais certos, etc.) e engenharia de tráfego (políticas consistentes de QoS, engenharia de tráfego MPLS, engenharia de tráfego do BGP, escolha e aquisição de enlaces com latências reportadas mais baixas, etc.). Em uma rede Ethernet, IP ou MPLS, a latência sempre existirá; é inevitável. O seu trabalho deverá saber projetar a rede, escolher bem seus componentes e dimensionar adequadamente seus recursos para que os índices de latência não sejam percebidos ou prejudiciais para a experiência de navegação e usabilidade de seus clientes.<br /> [[Arquivo:Bpf-qos-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: latência]]<br /> <br /> ==== MPLS ====<br /> Acrônimo: ''Multiprotocol Label Switching''.<br /> <br /> Conheça mais: [[Redes MPLS para Provedores]].<br /> <br /> Tecnologia de encaminhamento de pacotes cujas as operações não envolvem a consulta do cabeçalho IP. Numa rede completamente MPLS, o objetivo é fazer com que as consultas para a determinação de caminhos e o efetivo encaminhamento de pacotes ocorram por meios de instruções e operações mais simplificadas, denominadas &quot;''labels''&quot;, os quais são especificados em cabeçalhos enxutos chamados de &quot;''shim header''&quot;, e em três simples operações: imposição (push), troca (swap), e disposição (pop). O MPLS surgiu inicialmente como tecnologia visando atenuar o processamento dos roteadores de backbone dos grandes operadores de redes, pois as operações com ''labels'' tinham como apelo serem mais simplificadas e desprenderem menos esforços computacionais do que as operações com os cabeçalhos IP. Atualmente este argumento, ou motivador inicial quanto ao surgimento do MPLS, é praticamente nulo, em função da sofisticação das arquiteturas de roteadores dos dias atuais, pois os novos processadores conseguem sustentar ótimas taxas de encaminhamento de pacotes e independentemente se estes possuem ''labels'' ou não, e com múltiplos serviços concorrentes. No entanto, o MPLS como um todo evoluiu muito, e uma gama de funcionalidades excepcionais foram agregadas para rodar no topo das infraestruturas MPLS, obviamente exigindo o ''label switching'' para isto, assegurando qualidade, flexibilidade e elasticidade para quase tudo o que temos de bom nas infraestruturas de redes dos ISPs. Exemplos de soluções que rodam e/ou que dependem do MPLS para funcionar incluem L3VPN MPLS, L2VPN MPLS, MPLS TE, MPLS QoS, GMPLS. Algumas destas tecnologias que rodam no topo do MPLS surgiram para resolver problemas bastante conhecidos existentes em ambientes legados, tais como escalabilidade, confiabilidade, convergência e afins (ex: L2VPN MPLS visando sanear os desafios das redes L2 clássicas; MPLS TE visando resolver os desafios de engenharia de tráfego IP, etc.), e isto ao mesmo tempo em que outros conceitos foram surgindo para fomentar ainda mais a escalabilidade, flexibilidade e redução de custos (BGP-Free Core, 6PE/6VPE, e Unified MPLS são exemplos clássicos). O MPLS pode ser considerado como um marco, um verdadeiro divisor de águas, para todo o segmento de telecomunicações.<br /> <br /> ==== MPLS Traffic Engineering ====<br /> Conheça mais: [[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]].<br /> <br /> O MPLS-TE é uma solução que embarca duas propostas principais: a) engenharia de tráfego, b) proteção e recuperação contra falhas de enlaces e roteadores. Embora frequentemente combinado com os projetos MPLS clássicos (sem TE), o MPLS-TE não depende dos procedimentos do MPLS LDP. Para a parte de engenharia de tráfego, o MPLS-TE propõe-se a sanar algumas deficiências que são inerentes do próprio roteamento IP, os quais incluem congestionamentos decorrentes do mapeamento ineficiente dos fluxos de tráfego sobre os recursos da rede (interfaces, enlaces e roteadores), e fazendo isso com um bom arranjo de ferramentas que permite flexibilidade para a manipulação dos fluxos de tráfego através da rede do ISP e sem que isto exija modificações complexas nas propriedades do roteamento IP, tais como distância administrativa e métricas de rotas IGP, políticas de roteamento no backbone, rotas estáticas e afins. Já para a questão da rápida recuperação de falhas, o MPLS-TE fornece um recurso denominado Fast Reroute (FRR), o qual, através de uma estratégia conhecida por &quot;''Make-before-Break''&quot;, viabiliza a construção de LSPs de contingência para pronto uso em caso de falhas do next hop ou do nexto hop do next hop, promovendo índices de recuperação de falhas aproximados em 50 milissegundos.<br /> <br /> ==== Multi-CDN ====<br /> <br /> ==== Multi-tenant ====<br /> <br /> ==== NAT ====<br /> Acrônimo: ''Network Address Translation''.<br /> <br /> Tecnologia que realiza a tradução de endereços IP especificados nos cabeçalho IP dos pacotes em trânsito em um roteador. O NAT foi concebido originalmente como uma das iniciativas de soluções para conter o &quot;desmatamento&quot; do endereçamento IPv4, ou seja, sendo usado para conter ou desacelerar o rápido esgotamento da disponibilidade de endereços IP públicos. Há muitos anos iniciativas tais como o ''Classless Interdomain Routing'' (CIDR), ''Variable Length Subnet Masking'' (VLSM), endereçamento IPv4 privativo (IANA RFC 1918 [rfc:1918 - Address Allocation for Private Internets]), e ''Network Address Translation'' (NAT) foram introduzidas nos conceitos de projetos de redes para que tivéssemos a sobrevida do espaço de endereços IPv4 públicos até os dias atuais. Estima-se que, sem estas iniciativas, o esgotamento destes endereços teria ocorrido há muito tempo. Falando especificamente de NAT, esta solução anda lado a lado, como &quot;unha e carne&quot;, com os endereços IP privativos. Redes corporativas e domésticas/residenciais inteiras são endereçadas com endereços IP privativos (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16), e não há rotas no backbone da Internet para estes prefixos. Para que um usuário portando um endereço IP privativo destes possa navegar pela Internet, torna-se necessário realizar a tradução de seu endereço IP de origem para um endereço IP público disponível através desta configuração de NAT. Há vários tipos de cenários envolvendo o NAT, tais como o NAT dinâmico (numa relação ''one-to-one''), o ''Port Address Translation'' (também dinâmico, mas numa relação ''many-to-one''), NAT estático (relação 1:1) e NAT estático por portas (relação 1:1 com portas), sendo que o PAT ou &quot;''masquerading''&quot; é um dos cenários mais amplamente difundidos. Para os ISPs ou operadores de rede, no que diz respeito à conectividade de Internet de assinantes residenciais com endereços IPv4, no entanto, não utiliza-se o NAT &quot;convencional&quot;, e sim uma extensão funcional denominada ''Carrier Grade NAT'' (CGN ou CGNAT), já citada em nossa Enciclopédia, em combinação com outra faixa de endereços IPv4 privativos, a 100.64.0.0/10 (conforme [rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]). Para finalizar, entenda que o NAT pode ser usado também para a tradução de endereços IP de destino, mas fica à critério de cada projeto técnico e de suas particularidades.<br /> <br /> ==== NETCONF/Yang ====<br /> Acrônimo: ''Network Configuration''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no &lt;nowiki&gt;RFC 6241&lt;/nowiki&gt;. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações. Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração &quot;na mão&quot;. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, &quot;automatizados&quot;, é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho. O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, e é tido por muitos como a melhor interface southbound para ambientes de orquestração atualmente.<br /> <br /> O YANG por sua vez é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.<br /> <br /> ==== NetFlow ====<br /> A tecnologia como um todo é composta por caches de fluxo, coletores de fluxo e analisadores de dados. O NetFlow, quando foi criado há muitos anos, surgiu inicialmente como uma proposta para ''switching path'', mas rapidamente evoluiu para aquilo que muitos dos profissionais de redes compreendem sobre ele. O NetFlow é atualmente e há muitos anos uma tecnologia que visa fornecer excepcional visibilidade na rede e em resposta aos constantemente evoluídos requisitos para que os operadores de redes saibam como as suas redes estão se comportando, e fornecendo respostas para situações tais como: mapa de uso de aplicativos e redes, produtividade e utilização de recursos de rede, impacto das alterações na rede, detecção de anomalias na rede, assim como a identificação de vulnerabilidades de segurança, e problemas de conformidade a longo prazo. Para estas e outras necessidades, os engenheiros de redes passam a possuir ferramentas para entender quem, o que, quando, onde e como o tráfego da rede está fluindo, fomentando melhor entendimento sobre como as tecnologias empregadas na rede estão funcionando em alinhamento com os negócios da empresa; trilha de auditoria de como a rede é utilizada, aumento da conscientização quanto aos investimentos e uso da rede como um todo, redução de vulnerabilidades da rede, redução dos índices de downtime e distúrbios gerais, redução de custos, etc. O NetFlow pode ser usado como uma ferramenta &quot;simples&quot; para o gerenciamento de performance da rede, ou para situações bem mais ousadas, incluindo ações de planejamento de capacidades, engenharia de rede, engenharia de tráfego, bilhetagem e tarifação de tráfego, e detecção e mitigação de malware e de ataques DDoS sobre a rede, para citar alguns casos. Em termos práticos, o NetFlow é configurado em roteadores e switches, onde estiver disponível/suportado, podendo ser customizável em alguns casos, e, após isto, o equipamento exportará os bilhetes de fluxos de tráfego por NetFlow até uma estação coletora, a qual processará e consumirá estes dados, de acordo com os exemplos de soluções e casos citados anteriormente, e podendo interagir de volta com a rede para que ações sejam executadas pelos dispositivos da rede.<br /> <br /> O NetFlow é um protocolo proprietário da Cisco, mas que está disponível em outros fabricantes do mercado. O seu equivalente em termos de padrão aberto é o protocolo ''Internet Protocol Flow Information eXport'' (IPFIX).<br /> <br /> ==== NFV ====<br /> Acrônimo: ''Network Functions Virtualization''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware &quot;''commodity''&quot;. Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado. Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. <br /> <br /> ==== NodeB ====<br /> Um Node B é um termo para denotar uma estação base na terminologia WCDMA/UMTS, e é responsável pelo enlace de rádio entre o usuário da rede móvel e a parte fixa da rede ''UMTS Terrestrial Radio Access Network'' (UTRAN), conforme definido pelo 3GPP, ou seja, fornecendo a cobertura de rádio e conversão de dados entre esta rede de rádio e os ''Radio Network Controllers'' (RNCs).<br /> <br /> ==== OM ====<br /> OM1 - <br /> <br /> OM2 - 62,5/125 microns<br /> <br /> OM4 - 50/125 microns<br /> <br /> ==== Open/R ====<br /> (IGP virtualizado)<br /> <br /> ==== OSPF ====<br /> Acrônimo: ''Open Shortest Path First''.<br /> <br /> Conheça mais: [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas práticas para a implantação do OSPF em ambientes de ISP]]<br /> <br /> Protocolo de roteamento dinâmico do tipo interior e por definição de estado de enlaces (Link-State). O OSPF é um dos principais componentes das infraestruturas de redes dos provedores de acesso à Internet, sendo indispensável para viabilizar o roteamento necessário para o transporte das sessões BGP, resolução de roteamento recursivo referente ao atributo NEXT_HOP das rotas BGP mantidas nos Sistema Autônomo do ISP, além de atuar também para funções de roteamento de alguns serviços internos específicos do ISP. Muito frequentemente o OSPF é utilizado, também, em alinhamento com a tecnologia para fins de engenharia de tráfego com o MPLS TE, sendo, neste caso, inclusive, um componente obrigatório para este tipo de projeto. O OSPF destaca-se pela eficiência nas ações de rápida convergência, rápida recuperação de falhas e escalabilidade. Alternativamente ao OSPF, os operadores de redes podem optar pelo protocolo de roteamento IS-IS.<br /> <br /> ==== PCC ====<br /> Acrônimo: ''Path Computation Client.'' <br /> <br /> O PCC é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), o próprio cliente PCC (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCE ====<br /> Acrônimo: ''Path Computation Element''.<br /> <br /> O PCE é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCEP ====<br /> Acrônimo: ''Path Computation Element Communication Protocol''.<br /> <br /> O PCEP é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client'' (PCC)), o próprio protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)). O novo paradigma de redes programáveis orientadas a aplicações foi o que impulsionou as extensões PCEP, as quais possuem definições nos ''drafts draft-ietf-pce-stateful-pce'', ''draft-crabbe-pce-pce-initiated-lsp'', ''draft-ali-pce-remote-initiated-gmpls-lsp'', e outros.<br /> <br /> ==== Peering ====<br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Peering ou Troca de tráfego é uma relação comercial e técnica entre duas redes. É um acordo em que as redes admitem trocar tráfego entre os clientes uns dos outros, desde que o relacionamento seja '''mutuamente benéfico''', e nem sempre os acordos são isentos de custo ou trocas comerciais. Para garantir que cada lado do acordo tenha benefícios similares, as redes podem precisar atender aos requisitos pré-definidos para serem elegíveis. Por exemplo, uma rede pode precisar manter uma certa proporção de troca de tráfego, presença geográfica ou capacidade de backbone. A implantação real dessas relações de Peering, geralmente ocorre em locais comuns, como os NAPs e IXs estabelecidos pelo mundo (''Public'' Peering), ou através de links dedicados pagos pelas redes envolvidas (PNI-''Private network Interconnect'').<br /> <br /> ==== PGW ====<br /> Acrônimo: ''Packet Data Network Gateway''.<br /> <br /> ==== PNI ====<br /> Acrônimo: ''Private Network Interconnection''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> O famoso Private Peering ou Interconexão Privada em português - é aquele que normalmente não envolve quaisquer pontos de troca pública, ou seja, são portas de roteadores ''back-to-back'' normalmente interligadas por um ''cross-connect'' ou &quot;''golden jumper''&quot; ou até por capacidade em redes de transporte ''LAN-to-LAN''.<br /> <br /> ==== PPPoE ====<br /> Acrônimo: ''Point-to-Point Protocol over Ethernet''.<br /> <br /> O PPPoE é um protocolo utilizado para encapsular quadros PPP dentro de quadros Ethernet, tendo surgido no final dos anos 90 juntamente com a proliferação da Internet banda larga proporcionada com a entrada das tecnologias de transmissão baseadas no DSL. O PPPoE servia então como uma solução de tunelamento dos pacotes sobre a conexão DSL. Atualmente, com a predominância das redes FTTH, o PPPoE continua sendo utilizado nas redes dos ISPs, mas primariamente como mecanismo de autenticação e autorização de assinantes dos produtos de Internet banda larga dos ISPs, sendo o principal procedimento utilizado para este propósito, e a sua operação neste modelo ocorre entre o equipamento do assinante (CPE/CE) e o concentrador de assinantes (BNG ou BRAS), cuja a separação poderá ser uma rede Metro Ethernet (L2) clássica, ou L2 sobre MPLS (L2VPN), ou xPON.<br /> [[Arquivo:Bpf-protecao-roteadores-7.png|centro|miniaturadaimagem|600x600px|Enciclopédia: PPPoE]]<br /> <br /> ==== PTT ====<br /> Acrônimo: ''Ponto de Troca de Tráfego''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Ponto de Troca de Tráfego (PTT), em inglês ''Internet Exchange Point'' (IXP), é um modelo de interconexão de redes entre os provedores de Internet e redes de fornecimento de conteúdo. Os Pontos de Troca de Tráfego (PTT) funcionam como hubs em que provedores podem conectar seus sistemas autônomos (AS), facilitando o tráfego de informações entre si. No Brasil, o IX.br é um projeto de PTTs locais gerido pelo Núcleo de Informação e Coordenação do Ponto Br (NIC.br) e pelo Comitê Gestor da Internet no Brasil (CGI.br), que facilita o fluxo de informações entre provedores de Internet e conteúdo online em diversas regiões no país. Na prática, quanto maior e melhor for um PTT, mais dados os provedores conseguem trocar, melhorando a eficiência da rede e encurtando o caminho da conexão entre os computadores, pois projetos de PTTs como o do IX.br proporcionam a ligação direta entre os participantes, permitindo que muitos Sistemas Autonômos (AS) troquem tráfego diretamente. A interligação de diversos AS em um IX, ou Ponto de Troca de Tráfego (PTT), simplifica o trânsito da Internet e diminui o número de redes até um determinado destino. Isso melhora a qualidade, reduz custos e aumenta a resiliência da rede. Também é possível oferecer ou contratar outros serviços a partir da conexão do seu ISP em um IX, como, por exemplo, serviços de trânsito de Internet.<br /> <br /> ==== QoS ====<br /> Acrônimo: ''Quality of Service''.<br /> <br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]].<br /> <br /> O ''Quality of Service'' (QoS) não deve ser compreendido como uma única tecnologia apenas, e sim um conjunto de tecnologias, ferramentas e práticas que, devidamente arrendadas, buscam sanear algumas das deficiências típicas de transmissão presentes em ambientes de redes de natureza estatística, especialmente o controle de latência, jitter, e perda de pacotes, decorrentes da insuficiência de recursos para a transmissão de pacotes nestes ambientes, como, por exemplo, os conhecidos gargalos/congestionamentos, esgotamento de buffers, e outros. Com a convergência de praticamente todo o tipo de aplicação e serviço para o transporte sobre redes baseadas no protocolo IP, soluções estas tais como Voice over IP (VoIP), Comunicações Unificadas (aka &quot;Telefonia IP e/ou Colaboração&quot;), Vídeo-conferência (em regime específico para tal, ou em conjunto com uma solução de Colaboração), etc., os engenheiros de redes precisam acomodar adaptações que permitam com que estes tipos de tráfego fluam de acordo com os padrões aceitáveis para uma boa interação humana através destas redes - em particular a audição e a visão. Anteriormente as soluções de vídeo e voz funcionavam sobre infraestruturas de redes digitais, ou seja, baseadas em transmissão deterministica, as quais não sofriam dos mesmos problemas das redes de transmissão estatísticas e baseadas em pacotes (congestionamentos; gargalos, descartes de pacotes devido a insuficiência temporária de buffers, etc.), como é o caso do Ethernet, IP e MPLS. Os requerimentos para o transporte de voz são bem mais agressivos nas questões de latência, jitter e perda de pacotes, se comparados com as transmissões de aplicações puramente de dados. As transmissões de vídeo podem ser extremamente agressivas, pois possuem os mesmos requisitos de latência, jitter e perda de pacotes das transmissões de voz, só que comportam-se em grande parte como uma aplicações de dados com elevada taxa de transmissão e consumo de recursos da rede. Para que a experiência de uma comunicação entre duas pessoas através de um serviço de VoIP/Telefonia IP/Colaboração/Vídeo fique isenta de picotes na voz, metalização da voz, ecos, atrasos excessivos, congelamento de imagens, perda de sincronismo entre vídeo e áudio, dentre outros, torna-se necessário priorizar estes tipos de transmissão com auxílio de políticas e configurações específicas. E é exatamente para isto que o QoS precisa ser adotado nas redes nos dias atuais. O mesmo é válido quando tratando-se de transmissões na rede envolvendo uma aplicação de dados crítica (um sistema ERP ou CRM) e uma navegação usual ou recreativa de Internet, onde, nestes casos, é muito desejável que a prioridade de transmissão seja de uma aplicação mais importante quando houver insuficiência de recursos para acomodar ambos os tipos de tráfego em um determinado momento. <br /> <br /> O QoS especifica uma diversidade de ferramentas e técnicas devidamente categorizadas em Classificação, Marcação, Gerenciamento de Congestionamentos, Controle de Congestionamentos, Policiamento, Moldagem e Eficiência de Links. <br /> [[Arquivo:Bpf-qos-9.png|centro|miniaturadaimagem|600x600px|Enciclopédia: QoS]]<br /> <br /> ==== QSFP ====<br /> Acrônimo: ''Quad Small Form Factor Pluggable''.<br /> <br /> ==== RADIUS ====<br /> Acrônimo: ''Remote Authentication Dial In User Service''.<br /> <br /> ==== RGI Classe V da Anatel para SCM ====<br /> <br /> ==== RNC ====<br /> Acrônimo: ''Radio Network Controller''.<br /> <br /> ==== Roteador ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== Route-policy ====<br /> Uma route policy é uma ferramenta que &quot;materializa&quot; ou &quot;instrumentaliza&quot;, através de conceitos de sintaxe e semântica de uma interface de linha de comando (CLI), que é parte integrante do sistema operacional de roteadores, a política de roteamento idealizada pelo administrador ou engenheiro de uma rede para o seu projeto ou o atendimento de uma necessidade específica. Enquanto uma &quot;política de roteamento&quot; é o conceito projetado para uma interpretação mais humana da palavra, pois especifica a idéia, intenção ou interesse; é a &quot;política no papel&quot;, como, por exemplo, na perspectiva de cada roteador BGP vizinho ao seu roteador, quais prefixos importar, quais prefixos exportar, quais atributos deverão ser modificados, e sobre quais prefixos/rotas estas modificações devem ser feitas, para conceber quaisquer que sejam as necessidades em termos de engenharia de rede e de tráfego do projeto técnico idealizado pelo engenheiro da rede, contemplando ainda questões associadas à segurança do roteamento de Internet (prevenção de ''route leaks'', ''prefix hijacks'', supressão do recebimento e envio de ''bogons''/''martians''/''unallocated'', etc.). A '''''route policy''''', por sua vez, já é a efetiva instrumentação propriamente dita desta política de roteamento. É a &quot;policy&quot; na sua forma de configuração na linguagem suportada pelo sistema de seu roteador. Ou seja, &quot;os comandos&quot; da CLI, a sintaxe, a semântica. O termo route policy em si serve para o generalizar um conjunto de ferramentas que são encontradas nos roteadores e utilizadas para definirmos &quot;na forma de CLI&quot; as nossas políticas de roteamento, as quais deverão ser aplicadas nos sentidos &quot;entrada&quot; (''import'' ou &quot;''in''&quot;) e &quot;saída&quot; (''export'' ou &quot;''out''&quot;) de nossas vizinhanças BGP. Cada plataforma de roteador e de cada fabricante tem o seu conjunto próprio de ferramentas, capacidades, sintaxes, recursos suportados (e não suportados), etc. Por exemplo, roteadores Juniper (software &quot;JUNOS&quot;) implementam as suas facilidades por meios do ''Routing Policy Framework'', que consiste de termos (&quot;''terms''&quot;) definidos na forma de um ou mais ''policy-statement'', com sofisticadas e variadas opções de incidência de classificação (''match'') e ações a serem adotadas em cada incidência (''accept'', ''reject'', modificar atributos, etc.), e podendo ainda acionar outras ferramentas e recursos periféricos para uma classificação mais refinada dos prefixos (ex: ''route-filter-list'', ''community'', etc). Roteadores Cisco equipados como Cisco IOS XR Software, por sua vez, possuem um sistema periférico muito robusto denominado ''Routing Policy Language'' (RPL), que combina diversos tipos de objetos (''prefix-set'', ''as-path-set'', ''community-set'', ''extcommunity-set'', dentre outros), para definir uma sofisticada, porém de simples interpretação, política de roteamento na forma de &quot;''route-policy''&quot;, com operações intuitivas na forma de &quot;''if'' / ''else'' / ''then'' / ''set'' / ''pass'' / ''drop'' / ''done'' / ''endif'', etc.&quot;. Já os roteadores da Cisco baseados no Cisco IOS e IOS XE Software apresentam as conhecidas e pioneiras &quot;''Route Maps''&quot;, as quais atuam em conjunto com outros recursos disponíveis na plataforma, tais como ''prefix-lists'', ''community-lists'', ''ip as-path access-lists'', e outras. Já os roteadores da Huawei no geral implementam recursos similares em termos de implementação aos do Cisco IOS / IOS XE, tais como ''route-policy'', ''ip-prefix'', ''community-filter'' e outros, enquanto equipamentos mais recentes deste fabricante já implementam uma solução diferente denominada ''eXtended routing-Policy Language'' (XPL), inspirada no RPL do Cisco IOS XR. Independentemente do &quot;vendor&quot; ou do equipamento, o fato é que route policies são indispensáveis, pois são usadas cotidianamente para o cumprimento de diversos objetivos relacionados ao roteamento de Internet ou de qualquer projeto de infraestrutura IP onde o BGP seja utilizado para fornecer segurança e engenharia de tráfego.<br /> <br /> ==== RPKI ====<br /> Acrônimo: ''Resource Public Key Infrastructure (RPKI)''.<br /> <br /> ==== RTBH ====<br /> Acrônimo: ''Remotely Triggered Black Hole (RTBH)''.<br /> <br /> ==== RUM ====<br /> <br /> ==== SBI ====<br /> Acrônimo: ''Settlement Based Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão também conhecido como Peering Pago (Paid Peering), onde uma das redes paga a outra pela troca de tráfego.<br /> <br /> ==== SCM ====<br /> Acrônimo: ''Serviço de Comunicação Multimídia''.<br /> <br /> ==== SDN ====<br /> Acrônimo: ''Software-Defined Networking''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.<br /> [[Arquivo:Bpf-prog-sdn3.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SDN]]<br /> <br /> ==== SeAC ====<br /> Acrônimo: ''Serviço de Acesso Condicionado''.<br /> <br /> ==== SFI ====<br /> Acrônimo: ''Settlement-free Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão onde nenhuma das partes paga a outra pela troca de tráfego entre ambas.<br /> <br /> ==== SFP ====<br /> Acrônimo: ''Small Form Factor Pluggable''.<br /> <br /> ==== Segment Routing (SR) ====<br /> <br /> ==== Segment Routing v6 (SRv6) ====<br /> <br /> ==== SGSN ====<br /> Acrônimo: ''Serving GPRS Support Node''.<br /> <br /> ==== STFC ====<br /> Acrônimo: ''Serviço Telefônico Fixo Comutado''.<br /> <br /> ==== SMP ====<br /> <br /> ==== SNMP ====<br /> Acrônimo: ''Simple Network Management Protocol''.<br /> [[Arquivo:Bpf-protecao-roteadores-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SNMP]]<br /> <br /> ==== SSH ====<br /> Acrônimo: ''Secure Shell''.<br /> <br /> ==== Switch ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== SyncE ====<br /> Acrônimo: ''Synchronous Ethernet''.<br /> <br /> O SyncE é uma das quatro soluções de ''timing'' sobre redes de transmissão baseadas em pacotes, juntamente com o ''Precision Time Protocol'' (PTP), ''Network Time Protocol'' (NTP) e ''Timing over IP Connection and Transfer of Clock BOF'' (TICTOC). O SyncE é ao mesmo tempo um protocolo e um método de sincronismo para instruções de ''timing'' operando diretamente sobre o Ethernet, ou seja, sem o envolvimento de protocolos de camadas superiores (ex: IP, UDP ou TCP), e possui um procedimento que remonta ao que as redes SDH fazem. O SyncE é utilizado especialmente para o sincronismo de frequência, sendo inclusive muito preciso quanto a isto, mas não provê sincronismo de data e hora, pois este tipo de distribuição de informação (data/hora) precisa ou deve ser feita por outro protocolo (ex: NTP ou PTP). Diversos padrões regem o SyncE, dentre eles o ITU-T G.8261, G.8262, G.8264 e G.781. Em termos de eficácia, o SyncE é a referência de frequência mais estável e a mais precisa disponível atualmente, após as opções por PRC, BITS e GPS, e operadores de telefonia móvel estão avançando no suporte ao SyncE em suas redes como medida de redução de custos e sem o comprometimento da qualidade, ou seja, evitando instalações de GPS em cada estação da rede móvel.<br /> <br /> ==== TACACS+ ====<br /> Acrônimo: ''Terminal Access Controller Access-Control System Plus''.<br /> <br /> ==== Telnet ====<br /> <br /> ==== Trânsito ====<br /> <br /> ==== uRPF ====<br /> Acrônimo: ''Unicast Reverse Path Forwarding''.<br /> <br /> O ''Unicast Reverse Path Forwarding'' (uRPF) é um recurso disponível no software dos roteadores que é utilizado primariamente como mecanismo de &quot;antispoofing&quot;, ou seja, serve para a validação do endereço IP de origem sobre os pacotes recebidos nas interfaces do roteadores. A outra funcionalidade do uRPF é atuar como mecanismo de prevenção de ''routing loops'', em especial em situações relacionadas ao IP Multicasting. No que concerne ao mecanismo de &quot;antispoofing&quot; de endereços IP de origem em tráfego unicast em si, o uRPF é a ferramenta mais indicada para ser adotada nas interfaces que apontam diretamente para as conexões do cone de clientes (downstreams) do provedor de acesso à Internet (ISP), sendo ali o ponto correto de posicionamento e configuração deste mecanismo. Quanto as razões para a utilização do uRPF, o principal e mais forte argumento é a eliminação ou redução dos vetores de ataques DDoS, pois, para que este tipo de ataque possa ser bem sucedido, torna-se necessário que os hosts infectados (&quot;zumbis&quot;), que, neste caso, seriam os clientes do seu ISP, e de outros ISPs também, controlados por uma botnet, encaminhem pacotes com endereços IP de origem &quot;spoofados&quot; (forjados) para que aparentem terem sido enviados a partir do host ou rede que será a vítima deste ataque (cujo seu(s) endereço(s) IP foi (foram) forjado(s)/spoofado(s) por dezenas de milhares de outros hosts na Internet), o que promoverá, consequentemente, e infelizmente, o êxito deste ataque DDoS. Ou seja, sem o spoofing de endereços IP de origem, conceber ataques DDoS na Internet fica uma tarefa praticamente impossível - ou até que outras formas de ataques de negação de serviço sejam idealizadas pelos malfeitores da Internet. Por estas e outras razões que o &quot;Antispoofing&quot;, que inclusive é um dos objetivos estipulados pelo ''Mutually Agreed Norms for Routing Security'' (MANRS), deve ser projetado e configurado corretamente em todas as interfaces que admitem os clientes de um ISP, ou seja, em todo o seu &quot;downstream&quot;. Se todos os ISPs fizessem isso, simplesmente não haveria ataques DDoS na Internet. Ou pelo menos não nos moldes em que estes ataques são concebidos atualmente. Há algumas formas ou modalidades de implementação do uRPF, sendo eles o &quot;''Strict''&quot;, &quot;''Feasible''&quot; e &quot;''Loose''&quot;. Alternativamente ao uRPF, há outras ferramentas que podem ser consideradas para este propósito de antispoofing, incluindo Access Control Lists e IP Source Guard, mas, no caso de service providers / ISPs, o uRPF é o mecanismo mais indicado. Faça a sua parte e contribua para uma Internet mais segura: siga as recomendações do BCP 38 (''Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing''), que é citado no objetivo &quot;Antispoofing&quot; do MANRS, e ajude a reduzirmos substancialmente os ataques DDoS que assolam a Internet!<br /> <br /> ==== VPLS ====<br /> Acrônimo: ''Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. <br /> [[Arquivo:Bpf-enciclopedia-vpls.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN multiponto (VPLS)]]<br /> <br /> ==== VPNv4 ====<br /> Acrônimo: ''Virtual Private Network version 4''.<br /> <br /> O VPNv4 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv4 é definido como uma extensão para o suporte mulitprotocolo do BGP (&lt;nowiki&gt;RFC 4364&lt;/nowiki&gt; e &lt;nowiki&gt;RFC 4659&lt;/nowiki&gt;), e é representado pelo ''Address Family Identifiers'' (AFI) número 1 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. O endereço VPNv4 possui 96 bits de comprimento, sendo 64 bits composto pelo ''Route Distinguisher'' e os 32 bits restantes sendo o prefixo IPv4 da rota original (ex: envidada do roteador CE para o roteador PE, antes da conversão desta rota IPv4 unicast para uma rota VPNv4 pelo roteador PE). Roteadores ''Provider Edge'' (PE) de um backbone de operadora de telecomunicações ou ISP são configurados para trocar rotas VPNv4 através de sessões MP-BGP entre si, as quais são devidamente estabelecidas sobre uma rede MPLS para viabilizar a comunicação entre os sites participantes de uma determinada VPN, usando outros atributos associados aos anúncios destas rotas VPNv4 (ex: extended communities denominadas ''Route Targets'', dentre outros parâmetros e atributos).<br /> <br /> ==== VPNv6 ====<br /> Acrônimo: ''Virtual Private Network version 6''.<br /> <br /> O VPNv6 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv6 é representado pelo ''Address Family Identifiers'' (AFI) número 2 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. Um endereço VPNv6 possui 64 bits de comprimento, sendo 8 octetos o &quot;''Route Distinguisher''&quot; e 16 octetos o endereço IPv6 unicast. À exemplo do VPNv4, o VPNv6 é trocado entre roteadores PE com o auxílio do protocolo BGP (MP-BGP) para o estabelecimento de L3VPN MPLS funcionais com o IPv6 dos sites atendidos/conectados. Para estas L3VPN com IPv6, as sessões IBGP entre os roteadores PE participantes poderá ser feita em IPv4 ou IPv6, e a codificação do atributo NEXT_HOP será distinta para cada caso (&quot;''BGP speaker requesting IPv6 transport''&quot; ou &quot;''BGP speaker requesting IPv4 transport''&quot;). Sobre a codificação do atributo Next Hop, um draft recente está propondo a modificação de alguns destes procedimentos (draft-litkowski-bess-vpnv4-ipv6-nh-handling-00).<br /> <br /> ==== VPWS ====<br /> Acrônimo: ''Virtual Private Wire Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços ponto-a-ponto, ou seja, onde envolve-se apenas dois sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. As diferenças principais entre o VPLS e o VPWS é que, no caso do VPWS, não há aprendizado de endereços MAC, e a solução comporta-se como um ''clear channel'' mesmo.<br /> [[Arquivo:Bpf-enciclopedia-vpws.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN ponto-a-ponto (VPWS)]]<br /> <br /> ==== VxLAN ====<br /> Acrônimo: ''Virtual Extensible LAN''.<br /> <br /> Historicamente a segmentação de uma rede L2 tradicional tem sido fornecida por VLANs padronizadas conforme o IEEE 802.1Q, onde VLANs são criadas e distribuídas nos switches da rede para fornecer a segmentação lógica desejada para as funções de camada 2 em seus domínios de broadcast. No entanto, devido ao uso ineficiente dos links de rede disponíveis com o uso de VLAN, aos requisitos rígidos de posicionamento de dispositivos em redes de missão crítica como datacenters, e à escalabilidade limitada a um máximo de 4094 VLANs, o uso de VLANs tornou-se um fator limitante para muitas redes e de diversas empresas, especialmente data centers e provedores de acesso à Internet. Os ISPs já possuem uma solução baseada no Flexible VLAN Tagging ou Ethernet Flow Point em combinação com soluções L2VPN clássicas, mas este tipo de solução não atende os requisitos de conectividade com alta densidade e elasticidade de multitenantes. Alguns fabricantes líderes de mercado, incluindo a Cisco, Cumulus Networks, Arista, Broadcom, VMware, Intel e Red Hat, uniram-se para propor ao IETF uma solução para sanear os desafios de rede L2 mencionados previamente, e daí surgiu o VXLAN. O VXLAN fornece o posicionamento elástico da carga de trabalho (workload) e maior escalabilidade da segmentação da Camada 2, exigidas pelas demandas de aplicativos atuais, provendo os mesmos serviços Ethernet / camada 2 que VLANs demandam nos dias atuais, só que com maior extensibilidade, flexibilidade e escalabilidade. Em termos mais técnicos, o VXLAN é um esquema de sobreposição (overlay) da camada 2 em uma rede da camada 3. A tecnologia usa o encapsulamento MAC-in-User Datagram Protocol (MAC-in-UDP) para fornecer um meio de estender os segmentos da Camada 2 através da rede do data center, compondo uma solução formidável para oferecer suporte a um ambiente multitenant flexível e em larga escala através de uma infraestrutura física comum compartilhada. O protocolo de transporte na rede física do datacenter inclui o IP e o UDP. Para este procedimento, o VXLAN define um esquema de encapsulamento MAC-in-UDP em que o quadro original da camada 2 possui um cabeçalho VXLAN adicionado e é então colocado em um pacote UDP-IP. Com esse encapsulamento MAC-in-UDP, o VXLAN encapsula a rede da Camada 2 pela rede da Camada 3, fazendo as extensões desejadas das VLANs através da rede, mas, no entanto, sem incorrer nas mesmas limitações de flexibilidade, escalabilidade e diâmetro das redes L2 tradicionais.<br /> <br /> === Desciclopédia ===<br /> <br /> ==== Ajuste Fino ====<br /> Ajuste Fino descreve medidas paliativas ou &quot;''worarounds''&quot; para a superação de deficiências e limitações apresentadas ou impostas por algumas plataformas de equipamentos quando falham ao cumprir com as diretivas e configurações definidas pelos administradores, e cujas as falhas geralmente são acompanhadas de sentimentos de bastante frustração. Para exemplificar um dos tantos casos aqui, há um bocado de relatos onde um equipamento, que supostamente deveria possuir um bom suporte ao protocolo de roteamento BGP, com tabelas de Internet completas (full routes), &quot;trava&quot; rotineiramente ao apresentar ciclos de processamento elevados, bastando que apenas um de seus muitos núcleos disponíveis para esta finalidade fique engargalado para que o referido problema seja notado, consequentemente exigindo a reinicialização (&quot;reboot&quot;) do equipamento para a restauração da normalidade. Para mitigar este problema, dois argumentos possíveis são praticados pelos consultores: a) &quot;''você que não sabe configurar''&quot;, ou seja, na prática, como a quantidade de casos é um tanto grande, entendemos, portanto, que ninguém sabe configurar. b) &quot;''isto é fácil, é só mexer aqui, aqui, aqui e ali, e fazer isso, que você não terá mais o problema''&quot;. O argumento &quot;b&quot; é o que chamamos de Ajuste Fino. Quais tipos de manobras são consideradas ajuste finos? Vejamos: agendamento de reinicialização ou boot automático em intervalos periódicos, podendo ser diário ou semanal + upgrade de memória + publicação das full routes em uma VRF + balanceamento do tráfego através de múltiplos dispositivos, visando diminuir a carga + deixar na tabela principal apenas a rota padrão. Na verdade, fica até complicado definir os ajustes finos, pois são segredos comerciais guardados a sete chaves! O termo acabou generalizando e atualmente todo o workaround empregado para fugirmos de alguma restrição tecnológica ou de algum bug de software é chamado de &quot;Ajuste Fino&quot;, e isto independente do fabricante, modelo e marca do equipamento. Ajuste Fino pode ser considerado um workaround ou gambiarra para qualquer situação onde você teve que fazer algumas manobras esquisitas e fora do que usualmente precisamos fazer para as coisas funcionarem conforme &quot;by the books&quot;.<br /> [[Arquivo:Bpf-desc-ajustefino.png|centro|miniaturadaimagem|494x494px|Ajuste Fino!]]<br /> <br /> ==== Balance Soma-Link ====<br /> Clássica gambiarra que predominou em muitos ISPs pequenos e por muitos anos. A estratégia consistia em contratar dezenas de links banda larga ADSL para desempenharem a função de Trânsito IP do provedor, e fazer uma configuração com roteadores Mikrotik ou de classe similar para executar o balanceamento do tráfego através destas conexões, e sob o pretexto de que este tipo de &quot;solução&quot; somava a capacidade dos links e ainda por cima promovia uma distribuição simétrica ou bem uniforme do tráfego. Alguns consultores, por falta de opções ou recursos, ou despreparados tecnicamente, ou, em alguns casos, malandros mesmo, militavam abertamente nas redes sociais sobre estas façanhas. Desnecessário comentar aqui que tal gambiarra é completamente equivocada nos pontos de vista legal e ético, além de tecnicamente bastante frágil. Felizmente caiu em desuso, mas ainda assim é possível encontrar estas maluquices por aí. Nem o próprio MacGyver, ícone do famoso seriado dos anos 80, especializado em promover gambiarras incríveis para todo e qualquer tipo de situação, teria sido tão &quot;genial&quot; quanto os malandros que inventaram o &quot;Balance Soma-Link&quot;! A diferença é que as gambiarras do MacGyver funcionam e são quase sempre éticas, já essa gambiarra aí...<br /> [[Arquivo:Bpf-desc-loadbalance.png|centro|miniaturadaimagem|600x600px|Gambiarra do Balance Soma-Link]]<br /> <br /> ==== Bridge Roteada ====<br /> <br /> ==== IP Confinado ====<br /> Conheça mais: [[CDN Peering e PNI - Brasil|https://wiki.brasilpeeringforum.org/w/CDN_Peering_e_PNI_-_Brasil]]<br /> <br /> O &quot;IP Confinado&quot; é um produto ofertado por alguns provedores com a proposta de fornecer conteúdo de &quot;CDNs apenas&quot; para clientes interessados neste tipo de serviço. O que justifica o &quot;IP Confinado&quot; estar sendo listado em nossa desciclopédia não é a parte técnica da &quot;solução&quot; em si, e sim as diversas violações contratuais associadas com a prática. Muitos destes ISPs promovem algumas práticas que não são permitidas conforme os contratos que são estabelecidos entre ISPs e as detentoras das CDNs. Por exemplo, não é permitido que o ISP mencione que &quot;vende tráfego de CDN&quot;, muito menos destacando ou citando os nomes das empresas/CDNs envolvidas na &quot;oferta&quot;; incorporar logotipos/logomarcas destas empresas em qualquer tipo de propaganda ou material publicitário, expor as fotos dos equipamentos/servidores de CDN implantados em seus data centers, etc. Ou seja, o &quot;IP Confinado&quot; está frequentemente associado a abusos por parte de ISPs, tais como violações de direitos autorais, direitos de propriedade intelectual, direitos de imagem e afins. <br /> <br /> Entenda: é permitido que o ISP venda &quot;implicitamente&quot; o conteúdo de CDNs como parte de uma oferta de &quot;Trânsito IP Parcial&quot; e similares, mas desde que mantendo sob sigilo as informações que possam identificar as empresas que fornecem as CDNs para o ISP. A venda de conteúdo de CDN em si é tida como uma prática ilegal.<br /> [[Arquivo:Ipconfinado.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Confinado]]<br /> <br /> ==== IP Ilegal ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Puro ====<br /> O &quot;IP Puro&quot; nada mais é que uma proposta de fornecimento de um serviço de trânsito para um cliente-ISP final e que exclua deste link todo o tráfego de CDNs que por ventura estiver presente na infraestrutura do ISP contratado, muitas das vezes até mesmo excluindo tráfego originado de sessões de peering privado (PNI). Ou seja, tráfego exclusivamente obtido por upstreams de trânsito IP. Muitos ISPs contam com infraestruturas de CDNs em seus ambientes, juntamente com as sessões de trânsito IP com seus upstreams e também os pontos de troca de tráfego, sejam estes privativos, compartilhados ou bilaterais. Quando um ISP contrata um serviço de trânsito IP junto a outro ISP, neste link escoará todo o tipo de tráfego que existir na infraestrutura do ISP contratado, ou seja, tráfego proveniente dos peerings (ex: IX.br, PNI com Google, Facebook, etc.), trânsito (os upstreams daquele ISP contratado), e, claro, o tráfego das CDNs que existirem no ISP contratado. <br /> <br /> O que alguns ISPs-clientes fazem é exigir que o tráfego destas CDNs (e de peerings também, em muitos casos) não seja fornecido no link de trânsito IP contratado. As discussões acerca deste tipo de necessidade um tanto curiosa ou inusitada são tantas as vezes que um produto denominado &quot;IP Puro&quot; acaba sendo informalmente definido entre os participantes do meio. As vantagens e benefícios alegados por alguns são bastante questionáveis, pois entendemos que o ISP-cliente tem muito mais a perder do que a ganhar com esta preferência. O &quot;IP Puro&quot; é um exemplo clássico de nossa Desciclopédia!<br /> [[Arquivo:Ippuro.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Puro]]<br /> <br /> ==== IP Real ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Válido ====<br /> Endereços IP &quot;válidos&quot;, na mente de muitos profissionais da área, são aqueles endereços IP cuja conectividade com a Internet é plenamente funcional, justamente por não estarem contidos nas faixas especificadas pelo &lt;nowiki&gt;RFC 1918&lt;/nowiki&gt; (''Address Allocation for Private Internets'') ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt; (''IANA-Reserved IPv4 Prefix for Shared Address Space''). Ou seja, a verdade é que IP válido é qualquer endereço IP que não seja privativo.<br /> <br /> Na verdade, todo endereço IP é válido! O correto seria diferenciar o endereço IP em &quot;público&quot; e &quot;privado&quot;, e não em válido ou inválido (quando o endereço for privativo). <br /> [[Arquivo:Bpf-desc-ipvalido.png|centro|miniaturadaimagem|421x421px|Desciclopédia: o que seria um IP &quot;inválido&quot;...]]<br /> <br /> ==== IX Confinado ====<br /> <br /> ==== Link Dedicado Full Duplex ====<br /> <br /> ==== Link Semi-Dedicado ====<br /> O &quot;Link Semi-Dedicado&quot; é algo que expressa muito bem a cultura do brasileiro! Para resumir ou antecipar aqui, isto é basicamente uma gambiarra comercial.<br /> <br /> Para explicar isto melhor, vejamos o serviço de um link dedicado. Serviços de links dedicados são e devem ser tipicamente fornecidos através de uma infraestrutura Metro Ethernet, a qual disponibiliza recursos mais exclusivos e dedicados para o assinante/cliente, tais como uma porta dedicada em um switch Metro para aquele cliente, o enlace da fibra óptica é dedicado na última milha para a conexão do equipamento CPE/CE do cliente, a banda contratada é absolutamente simétrica e pode ser ajustada para até a capacidade máxima suportada pela porta (ex: 200 Mbps sobre porta 1 Gbps, 500 Mbps sobre porta 1 Gbps, ou 1 Gbps direto na porta). Ou seja, um Link Dedicado reúne componentes e arranjos tecnológicos mais caros e especializados para maximizar a experiência do cliente quanto à contratação do serviço. Novamente, é uma tecnologia mais cara, mas o cliente que contrata este serviço sabe exatamente o que e por que está contratando.<br /> <br /> Por outro lado, temos as tecnologias de Internet banda larga, inicialmente lá atrás com tecnologias baseadas no DSL (empregando DSLAMs e/ou MSANs, por exemplo), e nos últimos anos, o FTTH com xPON (principalmente o GPON), que operam especialmente sobre uma rede de acesso completamente compartilhada e com banda assimétrica Up e Down para as taxas mais elevadas.<br /> <br /> O GPON todos nós sabemos que é uma rede óptica passiva de natureza compartilhada, e toda a infraestrutura GPON é indiscutivelmente mais barata que uma rede Metro Ethernet; a diferença é muito expressiva neste sentido. Enquanto isto, é de amplo conhecimento que serviços de Internet banda larga são bem mais baratos (e viáveis para muitas pequenas empresas) que serviços de Internet com link dedicado, certo?<br /> <br /> O que alguns ISPs fazem, inclusive isto começou com um grande operador de redes: o &quot;meio-termo&quot;. Basicamente estas empresas tem vendido links de Internet banda larga com taxas um pouco mais elevadas, mas compatíveis com a característica assimétrica do projeto da rede GPON para a região onde o cliente está localizado, e suprimem, na cara de pau, o termo &quot;banda larga&quot;, usando o termo &quot;dedicado ou semi-dedicado&quot; para promover ou fornecer o serviço. Nada contra o GPON, muito pelo contrário! É uma tecnologia que permitiu baratear bastante os custos de construção de redes e a difundir melhor a Internet banda larga para muitos segmentos de pequenos negócios. Quando confrontados por clientes na questão de simetria da banda, os consultores do ISP procuram &quot;driblar&quot;, evitando mencionar que a rede é compartilhada (e que tem essa questão de restrições envolvendo a simetria Up e Down), e, quando sofrem o ultimato, informam que o serviço é &quot;Semi Dedicado&quot; (ou seja, nunca fazem menção ao aspecto compartilhado ou ao próprio GPON).<br /> <br /> Uma gambiarra estritamente comercial! É que nem você falar que mora num bairro adjacente ao seu, ao invés de citar o nome real conforme o seu CEP, porque seu bairro tem uma má fama. Ou que nem você ter vergonha de assumir a sua namoradinha(o) em público!<br /> [[Arquivo:Bpf-enciclopedia-semidedicado.jpg|centro|miniaturadaimagem|500x500px|Desciclopédia: Link Semi-Dedicado]]<br /> <br /> ==== Lupebequi ====<br /> <br /> ==== Rota Presa ====<br /> O termo &quot;rota presa&quot; ganhou tração há alguns anos, juntamente com o impulsionamento do crescimento de provedores de acesso à Internet de pequeno porte. Na ocasião, muitos ISPs de pequeno porte, a maioria destes, na verdade, contavam com classes de equipamentos roteadores equipados com arquiteturas de processamento de pacotes baseadas em software (''soft routers''). Com o crescimento da empresa no que diz respeito à base de assinantes, consumo de recursos de rede (banda, enlaces de trânsito IP, sessões, traduções de endereços, etc.), diversos ISPs passaram a experimentar rotineiramente problemas com o BGP, em particular com rotas ficando &quot;presas&quot; na tabela BGP e/ou RIB, mesmo com a sessão BGP correspondente ao recebimento daquelas rotas estando indisponível. Como as situações reportadas por profissionais e consultores da área eram um tanto frequentes, o termo &quot;Rota Presa&quot; acabou generalizando e tornando-se versátil para descrever o óbvio: para tudo há limites. Mesmo que um equipamento ''soft router'' possa ser bastante atraente na relação custo x benefício, e ser capaz de agregar muitos recursos e facilidades interessantes, uma arquitetura de roteamento baseada em processamento de pacotes por interrupções de software frequentemente possui problemas de escalabilidade. Na medida em que aumenta-se o consumo de recursos de rede (banda, sessões, traduções simultâneas de NAT, etc.), o processamento será aumentado proporcionalmente. Até que isto comece a provocar problemas de desempenho e outros incidentes. Isto porque a combinação de classe de hardware de alguns equipamentos conhecidos do mercado, e a arquitetura de soft router, possui limitações nas questões de desempenho e escalabilidade, algo que é igualmente e rotineiramente negligenciado por ISPs e consultores. Mesmo após esta constatação, muitos ISPs continuavam apostando nesta abordagem em termos de arquitetura de roteador para a função de borda, ou seja, postergando o inevitável: já estava na hora de migrar aquela arquitetura para plataformas mais especializadas para esta missão.<br /> <br /> O interessante é que há uma relação muito íntima entre a &quot;Rota Presa&quot; e o &quot;Ajuste Fino&quot;! Para alguns, o problema de &quot;rotas presas&quot; e sintomas similares somente pode ser saneado com a migração de arquitetura (trocando o roteador), enquanto, para outros, especialmente os &quot;magos da telecom&quot;, o problema de &quot;rota presa&quot; é provocado pela incompetência de quem configura o equipamento, pois basta o sujeito executar alguns procedimentos secretos (&quot;Ajuste Fino&quot;) para que este problema não ocorra. :-)<br /> [[Arquivo:Bpf-desc-rotapresa.png|centro|miniaturadaimagem|518x518px|Desciclopédia: Rota Presa<br /> <br /> Fonte: Consultores da Depressão]]<br /> <br /> ==== SkyGato ====<br /> <br /> ==== Terraplanistas da Telecom ====<br /> O que seriam &quot;terraplanistas da telecom&quot;? Analogia aos terraplanistas &quot;originais&quot;: indivíduos que se acham superiores a gerações inteiras de verdadeiros gênios inspiradores, dos quais incluo aqui Eratóstenes, Galileo Galilei, Isaac Newton, Albert Einstein, Johannes Kepler, Arthur Eddington, Edwin Powell Hubble, Milton L. Humason, Tycho Brahe, Michael Faraday, Stephen Hawking, Steven Weinberg, James Clerk Maxwell, Peter Higgs, Edward Witten, Freeman Dyson, Werner Heisenberg, Erwin Schrodinger, Alan Guthm, Ernest Rutherford, Paul Dirac, Niels Bohr.... fora Anaximandro, Arquimedes, e tantos outros, dentre gênios e perseguidos. Todo um esforço gigantesco e desde os tempos mais remotos para que evoluíssemos humana e tecnologicamente e nas áreas de física e astrofísica, construíssemos coisas incríveis, compreendêssemos o universo próximo, mesmo que faltando ainda tantas perguntas sem respostas, para termos uma classe de indivíduos em franca expansão (&quot;terraplanistas&quot;) usando a tecnologia, todo o aparato tecnológico à seu favor para, nas redes sociais, bradarem aos 4 ventos: &quot;A TERRA É PLANA!&quot;. Surreal!<br /> <br /> Na mesma moeda, analogias aqui, os &quot;''terraplanistas da telecom''&quot; são aqueles indivíduos que atuam na área e que tentam refutar o irrefutável. Literalmente '''''&lt;u&gt;rasgam&lt;/u&gt;''''' RFCs, BCOPs, padrões/standards, e frameworks. Não somente isto: acidentalmente ou propositalmente quase que rasgam também os trabalhos dos &quot;gênios da nossa área&quot;; Radia Joy Perlman, John Moy, Yakov Rekhter, Kirk Lougheed, Vint Cerf, Robert Kahn, Robert Metcalfe, David Boggs, W. David Sincoskie, Ali Sajassi, dentre tantos caras que criaram tudo o que usamos nas redes hoje, fora os grupos de trabalho incluindo IETF, IEEE, IANA, RIPE, NIC.br, LACNOG, NANOG, GPF, e, porque não, as recomendações do BPF, e o escambáu. As BCOPs e RFC são literalmente '''&lt;u&gt;nada&lt;/u&gt;''' para alguns destes indivíduos (sim, eu atestei isto! Eu li e conferi isso numa discussão!). O que um Job Snijders falaria no ouvido desses caras, entraria por um lado e sairia pelo outro!<br /> <br /> Parece exagero, mas tem surgido uma classe de indivíduos que tenta refutar uma diversidade de fatos irrefutáveis sobre as características, disponibilidades e aplicabilidades de tecnologias associadas à redes, telecomunicações no geral; a Internet. Dentre os absurdos que vemos por aí, temos: &quot;''é mentira que o IPv4 está se esgotando!''&quot;, &quot;''o OSPF está morrendo!''&quot;, &quot;''operadoras estão deixando de usar o MPLS''&quot;, &quot;''a navegação por IPv6 prejudica a performance da minha Internet&quot;'', &quot;''não preciso implantar o IPv6, porque o IPv6 ainda não é usado&quot;'', ''&quot;blackhole é mitigação de DDoS''&quot;, &quot;''trânsito sem PTT é melhor''&quot;, &quot;''existe trânsito IP puro''&quot;, &quot;''sessão de peering com IX Europeu melhora a performance porque a lista de AS_PATH é menor''&quot;, dentre outras coisas engraçadas. Note que não são apenas &quot;opiniões&quot;: essas situações fazem parte de recomendações de fato que os &quot;terraplanistas da telecom&quot; promovem!<br /> <br /> O meu termo aqui de &quot;terraplanistas da telecom&quot; não faz julgamento de quanto o indivíduo sabe ou não sabe sobre estas tecnologias. Realmente não compete a mim julgar o nível de conhecimento de qualquer um que seja, e isto está absolutamente fora de questão. O que me cabe a fazer, obviamente, é questionar porque eles falam mal de certas coisas que eles mesmos não compreendem ou dominam? Não seria mais prudente pesquisar, informar-se, praticar, exercitar, questionar, etc., a ponto do indivíduo ser fluente o suficiente nesse ou naquele tema (protocolo, tecnologias), antes de tentar influenciar as outras pessoas?<br /> <br /> Uma coisa é você falar que não sabe ou não domina uma tecnologia, por isso que você não a quer ou prefere evitá-la. Uma coisa é você falar que determinada tecnologia não é compatível com os seus planos e pelas razões X, Y e Z. Em ambos os exemplos, argumentos e justificativas válidos. Agora, falar que &quot;''é mentira que o IPv4 está se esgotando''&quot; e coisas deste tipo é um verdadeiro desserviço para a comunidade!<br /> [[Arquivo:Bpf-enciclopedia-terraplanistas.png|centro|miniaturadaimagem|600x600px|Desciclopédia: terraplanistas da telecom]]<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Geral]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Bpf-desc-rotapresa.png&diff=2520 2020-06-15T19:46:01Z

<p>Leonardo.furtado: </p> <hr /> <div>Desciclopédia: Rota Presa<br /> Fonte: Consultores da Depressão</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Bpf-desc-ipvalido.png&diff=2519 2020-06-15T19:43:26Z

<p>Leonardo.furtado: </p> <hr /> <div>Desciclopédia: o que seria um IP &quot;inválido&quot;...</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Enciclopedia_e_desciclopedia_da_telecom&diff=2518 2020-06-15T19:37:38Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Enciclopédia e &quot;Desciclopédia&quot; da Telecom ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Este artigo sofrerá adições de termos, acrônimos e expressões, um tanto frequentemente! Será a nossa Enciclopédia para descrever e, sempre que possível, exemplificar cada um dos termos usados pelas empresas e profissionais das áreas de telecomunicações e redes! Da mesma forma, este artigo fornecerá, e buscará deixar destacado, juntamente a cada termo, onde aplicável, uma &quot;Desciclopédia&quot; (nada melhor que uma dose de humor, certo?) para comentar situações que são verdadeiras gambiarras encontradas no setor de telecomunicações. <br /> <br /> A Enciclopédia reúne as expressões legítimas e corretas. Já a Desciclopédia, reúne situações um tanto controversas que surgiram na cabeça altamente criativa dos profissionais da área; as gambiarras! <br /> <br /> OBS: a prioridade de edição do artigo será o fornecimento das explicações referentes aos termos e, em segundo momento, a inclusão de algum tipo de exemplo ou referência. Se algum termo não contiver um exemplo ou uma referência, simplesmente aguarde, pois isto será realizado posteriormente. <br /> <br /> Desde já, solicito para que você siga acompanhando os trabalhos do '''''Brasil Peering Forum (BPF)''''', faça o bom e sensato uso de boas práticas, e diga não às gambiarras!<br /> [[Arquivo:Bpf-enciclopedia-cover.png|centro|miniaturadaimagem|700x700px]]<br /> <br /> ==== Como consultar este artigo ou buscar os termos e expressões desejadas ====<br /> Para este procedimento, sugiro:<br /> * Todos os acrônimos, termos ou expressões estão listados em ordem alfabética. Você poderá navegar pelo índice remissivo, clicar no acrônimo ou termo desejado, e ser direcionado diretamente para ele. Ou;<br /> * Faça uma pesquisa diretamente através de seu navegador (ex: CTRL-F)!<br /> Aprecie sem moderação!<br /> <br /> === Enciclopédia ===<br /> <br /> ==== 6PE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS (6PE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6PE é um cenário de transição para a adoção do roteamento IPv6 onde, no Core do operador da rede (ISP), não há endereçamento IPv6 (ainda), e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. Para maior eficiência, flexibilidade, e redução de custos, o 6PE pode ser projetado em um ambiente de backone (Core) isento de BGP, num cenário denominado &quot;''6PE com BGP-Free Core''&quot; mas, no entanto, são coisas distintas, e uma coisa não depende da outra, embora a combinação de ambas as estratégias tende a agregar muitos benefícios.<br /> [[Arquivo:Bpf-enciclopedia-6pe.png|centro|miniaturadaimagem|600x600px|Enciclopedia: 6PE]]<br /> <br /> ==== 6VPE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS VPN (6VPE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6VPE é um cenário de transição para a adoção do roteamento IPv6 na relação entre o ISP e clientes corporativos de serviços L3VPN MPLS, onde, no Core do operador da rede (ISP), não há endereçamento IPv6, e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. A diferença primária entre o 6PE e o 6VPE é que o 6PE lida com o roteamento IPv6 unicast sobre uma infraestrutura de backbone IPv4 em uma rede MPLS, enquanto o 6VPE lida com a troca de prefixos IPv6 unicast sobre uma infraestrutura L3VPN MPLS com sessões IBGP em IPv4 e com o suporte VPNv6 entre os roteadores PE. O BGP-Free Core não é um requisito para 6VPE ou 6PE, mas poderá agregar maior flexibilidade e promover redução de custos para o operador de redes.<br /> [[Arquivo:Bpf-enciclopedia-6vpe.png|centro|miniaturadaimagem|600x600px|Enciclopédia: 6VPE]]<br /> <br /> ==== AAA ====<br /> Acrônimo: ''Authentication, Authorization, Accounting''.<br /> <br /> O AAA pode ser tratado como um framework ou um conjunto de especificações tecnológicas e recursos para a concepção de mecanismos mais seguros visando a admissão de usuários e endpoints (dispositivos) em uma rede. O AAA, além de representar um conjunto de procedimentos, é usado geralmente em combinação com protocolos e serviços tais como RADIUS, TACACS+ e Diameter. Como o próprio nome sugere, a proposta é a de fornecer métodos seguros visando a autenticação de usuário e/ou dispositivo (ex: computador, roteador CPE, ou outro tipo de dispositivo), a posterior autorização, o que, por sua vez, ditará propriedades para o acesso concedido, tais como a atribuição dinâmica de VLAN, uma ACL dinâmica, um ''Scalable Group Tag'' (SGT), atribuição de endereçamento IPv4 e IPv6 (muito comum no caso do PPPoE), dentre uma diversidade de outras variáveis que podem ser associadas ao usuário e/ou ao seu dispositivo. E, por último, a manutenção de registros de atividades para fins de auditoria daquele acesso, ou seja, o ''Accounting''.<br /> <br /> &lt;u&gt;Exemplos de cenários onde o AAA é empregado:&lt;/u&gt; controle de acesso centralizado aos equipamentos da rede por parte de operadores/administradores, e com autorização e registros de comandos na CLI, autenticação de portas de switches com o protocolo 802.1X (conhecido também como solução IBNS), controle de acesso e admissão à rede (uma evolução do IBNS conhecida por ''Network Access Control'' (NAC)), autenticação de assinantes PPPoE e IPoE em concentradores de serviços de Internet banda larga (BNG/BRAS), autenticação de usuários e dispositivos móveis em redes WLAN, dentre outros casos.<br /> <br /> ==== Access-List ====<br /> Uma Lista de Acesso (Access-List ou ACL) é uma ferramenta absolutamente versátil disponível em roteadores e switches, e também em outros tipos de equipamentos de redes, e que tem como principal proposta a de atuar como mecanismo de classificação de pacotes ou, alternativamente, em muitos casos, para classificação de rotas. Após a classificação de pacotes ou de rotas, dependendo de como e para que uma ACL estiver sendo utilizada, uma ação pode ser vinculada para o pacote ou para a rota, e conforme diretivas imputadas pelo administrador da rede.<br /> <br /> &lt;u&gt;Exemplos de cenários onde uma ACL é empregada:&lt;/u&gt; filtro ''stateless'' de pacotes (''stateless packet filtering''), filtro ''stateful'' de pacotes (''stateful packet filtering'', quando a ACL é vinculada em um roteador com suporte a firewall stateful), classificação de tráfego que deverá ou não sofrer tradução de endereços IP (em ambiente NAT e CGNAT), classificação de pacotes que deverão sofrer uma política de roteamento diferenciada para encaminhamento de tráfego &quot;bypassando&quot; a tabela de roteamento (uma PBR, ABF, e similares), classificação de pacotes para o posicionamento destes em classes de tráfego e posterior tratamento de qualidade de serviço (QoS), classificação de pacotes autorizados para serviços de gerenciamento do equipamento (acesso remoto à CLI por SSH, acesso remoto ao equipamento via SNMP, NETCONF, etc.), classificação dos pacotes de servidores NTP autorizados a sincronizar data/hora com o seu equipamento, classificação de rotas que deverão ser invocadas por um filtro de rotas ou por uma política de roteamento (para ''accept'' ou ''drop'', com ou sem modificação de atributos), e muitos outros.<br /> <br /> Uma ACL pode ser considerada um verdadeiro &quot;canivete suíço&quot;! No entanto, para algumas necessidades, há ferramentas melhores ou mais versáteis que uma ACL. Por exemplo, uma ''prefix-list'' ou ''prefix-set'' é mais flexível e adequada para filtrar rotas em uma policy de roteamento, do que usar uma ACL para este mesmo propósito.<br /> <br /> ==== AS ====<br /> Acrônimo: ''Autonomous System''.<br /> <br /> Conheça mais: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]].<br /> <br /> Um (o) sistema autônomo representa a coletânea de dispositivos de rede sob uma administração comum, e o termo é geralmente empregado para representar uma rede inteira de uma determinada empresa, seja ela um provedor de acesso à Internet (ISP), uma empresa do segmento corporativo, ou uma instituição qualquer. Em um primeiro momento, o AS tipifica exatamente isto: a &quot;rede&quot; daquela empresa, os seus equipamentos, as suas diretivas e políticas; ou seja, uma coisa mais abstrata. No entanto, algumas tecnologias levam o termo AS para as suas próprias funcionalidades, capacidades e propriedades, dando uma expedição bem mais tangível ao termo, e em sua forma mais prática e real. Uma desta tecnologias é o protocolo de roteamento BGP, como todo profissional de ISP sabe.<br /> <br /> No caso do BGP, o Sistema Autônomo (AS) não é apenas algo teórico, e sim o componente principal e real do próprio protocolo de roteamento. Você, de fato, define/configura o AS no BGP dos seus roteadores, juntamente com uma série de propriedades e parâmetros (tais como sessões, anúncios, filtros, políticas de roteamento, recursos adicionais/periféricos do BGP, etc.) para representar aquela rede e as suas respectivas políticas de roteamento, ou seja, havendo uma relação muito íntima e tangível com esta definição de AS. A Internet é composta por dezenas de milhares de sistemas autônomos, obviamente interconectados pelo protocolo de roteamento BGP.<br /> [[Arquivo:Bpf-enciclopedia-as.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Autonomous System (AS)]]<br /> <br /> ==== BGP ====<br /> Acrônimo: ''Border Gateway Protocol.''<br /> <br /> Conheça mais aqui: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]] e [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O BGP ou BGP-4 é um protocolo de roteamento do tipo vetor de caminhos e exterior (''path vector'' e EGP), e pode ser considerado como a base de todo o roteamento de Internet. Todo o funcionamento da Internet depende da boa operação do BGP e, sem ele, simplesmente não há a Internet. Obviamente que a Internet depende de muito mais coisas que o protocolo de roteamento BGP para funcionar, mas, sem dúvidas, ele é um componente tido como central.<br /> <br /> O protocolo de roteamento BGP tem sofrido muitos aditivos ao longo dos anos, com a adição de novas funcionalidades e recursos, dentre os quais convém destacar aqui o suporte às diversas famílias de endereços, tais como IPv4 Unicast, IPv6 Unicast, IPv4 Multicast, IPv6 Multicast, VPNv4, VPNv6, L2VPN, EVPN, Labeled Unicast, Traffic Engineering, e outros. Confira alguns destes recursos aqui:<br /> * [https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Border Gateway Protocol (BGP) Parameters], [https://www.iana.org/assignments/capability-codes/capability-codes.xhtml Capability Codes], [rfc:7606 Multiprotocol Extensions for BGP-4], [https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml Subsequent Address Family Identifiers (SAFI) Parameters], e há muitos outros.<br /> <br /> ==== BNG ====<br /> Acrônimo: ''Broadband Network Gateway''.<br /> <br /> Conheça mais: [[Concentradores PPPoE com IPv6]].<br /> <br /> O BNG substitui outro nome/termo, mais defasado, chamado BRAS, ou seja, apesar de serem termos intercambiáveis, recomenda-se, nos dias atuais, referenciá-lo como BNG. O BNG é essencialmente uma plataforma de roteamento equipada com funcionalidades, recursos, protocolos e serviços primários e periféricos orientados para a solução de conectividade de Internet banda larga, atendendo primariamente os assinantes residenciais, embora nada impeça que seja utilizado também para produto de Internet banda larga voltada ao segmento corporativo. O roteador BNG atua como dispositivo roteador (gateway) para as sessões autenticadas de usuários mantidas por ele (daí o termo &quot;concentrador BNG&quot;). O BNG é geralmente usado em combinação com outros componentes e procedimentos, sendo alguns destes mandatórios, enquanto outros são opcionais, variando conforme as definições de cada projeto técnico. Exemplos de tecnologias e procedimentos que &quot;casam&quot; com uma solução BNG: RADIUS, Diameter, PPPoE, IPoE, sejam estes arranjados sobre uma rede puramente Metro Ethernet + IP, ou FTTH/GPON + Metro + IP.<br /> <br /> ==== BRAS ====<br /> Acrônimo: ''Broadband Remote Access Server''.<br /> <br /> Vide o acrônimo BNG (Broadband Network Gateway).<br /> <br /> ==== Caches Enter-Deep ou Bring-Home ====<br /> O Enter-Deep Cache possui como estratégia estar profundamente fincado nas redes de acesso dos provedores de acesso à Internet (ISP), geralmente sendo adotados na forma de clusters implantados nas redes do ISP ao redor do mundo. Esta filosofia de cache foi introduzida pela Akamai e é usada por muitas empresas que seguiram na mesma filosofia. In a &quot;nutshell&quot;, e explicando isto de forma bem simplista e minimalista, como a coisa funciona, usando um exemplo simples envolvendo o Google: todos estes inúmeros ou quase incontáveis clusters localizados nas redes dos ISPs e nos data centers desta empresa no mundo compõem uma rede privada do Google. Sendo assim, quando um usuário faz uma requisição ou consulta de pesquisa, esta consulta tende a ser encaminhada primeiramente pelo provedor de acesso (ISP) local para um cache local próximo, de onde deverão sair conteúdos estáticos para o cliente enquanto este cache local, ao mesmo tempo, encaminha uma consulta pela rede privada do Google para um de seus data centers, de onde deverão sair os dados e resultados de pesquisa personalizadas para o cliente. Em um exemplo envolvendo um vídeo do YouTube, este vídeo poderá ser recuperado diretamente do cache local do ISP, se este possuir a arquitetura e se este conteúdo puder ser fornecido das proximidades deste enter-deep cache, enquanto os anúncios associados ao vídeo são recuperados a partir dos data centers do Google. Em geral, os serviços de nuvem do Google são fornecidos por uma infraestrutura de rede privada independente da Internet pública, daí as excepcionais vantagens dos ISPs em poderem contar, quando autorizados e sobre forte regime de contrato e NDA, com estas soluções baseadas enter-deep cache. Ganha o usuário, com acesso com latência mais baixa aos conteúdos, e ganha o ISP, com previsibilidade no tráfego e redução de custos com os enlaces de trânsito IP.<br /> <br /> Já a estratégia Bring Home (&quot;trazer para casa&quot;), é uma segunda filosofia de design adotada por muitas empresas de CDN. A proposta aqui é trazer os ISPs para &quot;casa&quot;, conectando clusters em pontos de presença (PoPs) construídos através de uma rede privada de alta velocidade, ao invés de implantar estes clusters diretamente nas infraestruturas de redes dos ISPs. Estes pontos de presença (PoPs) geralmente ficam mais próximos aos operadores de redes Tier-1, podendo estender-se para além destes em alguns casos. Comparado com o enter-deep cache em termos de filosofia de design, o Bring Home normalmente resulta em menores custos de manutenção, mas é menos interessante no ponto de vista de latência e taxas de transferências de dados para os usuários finais, quando comparando estes benefícios com a filosofia do Enter-Deep cache.<br /> <br /> ==== CDN ====<br /> Acrônimo: ''Content Delivery Network''.<br /> <br /> Conheça mais: [[CDN Peering e PNI - Brasil]].<br /> <br /> Ou Rede de Fornecimento de Conteúdo. Uma CDN é um sistema de servidores amplamente distribuídos que fornece acesso à páginas e à diversos tipos de conteúdos para os usuários da Internet, e com base em uma diversidade de métricas e procedimentos, tais como a geolocalização do assinante/usuário, local de origem dos conteúdos, e centros de distribuição de dados (que hospedam uma CDN) em melhores condições de fornecerem o conteúdo para o usuário requisitante, para citar algumas destas métricas e procedimentos.<br /> <br /> Como principais benefícios, as CDN asseguram menores índices de latência no fornecimento de conteúdo para os usuários requisitantes, um benefício percebido pelos próprios usuários finais, pois estes terão uma melhor experiência de consumo destes conteúdos, e permite excelentes capacidades de engenharia de rede e de tráfego para os serviços de trânsito; melhor cenário financeiro na questão de despesas operacionais de médio e longo prazos, o que seria um ótimo benefício para os ISPs que contarem com as CDNs de diversos fornecedores de conteúdos. Ou seja, ganha o usuário, com maior fluidez e experiência de consumo de conteúdos, e ganha o ISP, com seus clientes mais satisfeitos com a experiência de navegação, além dos resultados com as despesas operacionais de médio e longo prazos.<br /> <br /> ==== CFP ====<br /> Acrônimo: ''C form-factor pluggable (CFP)''.<br /> <br /> O CFP é resultante de um acordo do tipo ''multi-source agreement'' estabelecido entre os principais fabricantes de soluções da indústria para a produção de um transceptor ótico para transmissão de sinais de alta velocidade. O CFP foi desenvolvido primariamente para redes Ethernet em 100 Gbps, operando nas em 10 vias a 10 Gbps em cada sentido (Tx e Rx), ou 4 vias a 25 Gbps, também em cada sentido. As variações existentes:<br /> <br /> &lt;u&gt;CFP&lt;/u&gt; (82 mm × 13.6 mm × 144.8 mm, conexão elétrica de 148 pinos, consumo inferior a 24 W, 10×10G ou 4×25G vias). &lt;u&gt;CFP2&lt;/u&gt; (41.5 mm × 12.4 mm × 107.5 mm, conexão elétrica de 104 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 12 W, 10×10G, 4×25G, 8×25G, ou 8×50G vias, Analog Coherent Optics (ACO)). &lt;u&gt;CFP4&lt;/u&gt; (21.5 mm × 9.5 mm × 92 mm, conexão elétrica de 56 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 6 W, 4×10G ou 4×25G vias). &lt;u&gt;CFP8&lt;/u&gt; (40 mm × 9.5 mm × 102 mm, conexão elétrica de 124 pinos, sem DSP, consumo máximo de 24 W, 16×25G vias (25.78125 ou 26.5625 GBd) ou 8×50G vias). &lt;u&gt;MSA 5″×7″ (Gen 1)&lt;/u&gt; (conexão elétrica de 168 pinos, embarca DSP, consumo inferir a 80 W). &lt;u&gt;MSA 4″×5″ (Gen 2)&lt;/u&gt; (conexão elétrica de 168 pinos, DSP, consumo elétrico inferior a 40 W).<br /> <br /> ==== CGNAT ====<br /> Acrônimo: ''Carrier-Grade Network Address Translation (CGNAT ou CGN).''<br /> <br /> O CGNAT é ao mesmo tempo uma solução e um mal necessário, sempre requerido quando não há endereços IPv4 públicos suficientes para atender toda a base de clientes de um ISP. Em termos mais técnicos, o CGNAT é essencialmente uma tecnologia que realiza a tradução dos endereços IPv4 de origem dos assinantes/clientes/usuários, onde estes são geralmente endereçados com endereços IP da faixa 100.64.0.0/10 ([rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]), e não com os endereços IPv4 privativos previstos pelo RFC 1918, como alguns acreditam, para um endereço IPv4 público. O CGNAT difere da solução NAT tradicional por sofrer algumas modificações para viabilizar a tradução de endereços em larga escala e atendendo, dependendo da plataforma, a dezenas de milhares de usuários, daí o termo &quot;''carrier grade''&quot;. A principal diferença entre CGNAT e NAT é que o CGNAT é configurado para fazer a tradução do endereço IP de origem e respectivas portas usadas na conversação, mas &lt;u&gt;sem&lt;/u&gt; manter quaisquer informações referentes aos endereços IP e portas de destino, sendo isto, inclusive, um dos principais motivos pelos quais o CGNAT escala para milhões de traduções simultâneas de endereços. Há diversas abordagens de CGNAT, tanto ''stateful'' quanto ''stateless'', tais como NAT44, NAT444 / Double NAT 44, em regime determinístico ou pré-definido, ou ainda em alocação de portas em massa (Bulk Port Allocation (BPA)), ou ainda em combinação com técnicas de transição para IPv6 de assinantes com NAT 64SL, NAT64SF, IPv6 Rapid Deployment (6rd), Dual-Stack Lite (DS-Lite), e MAP-T/E<br /> <br /> Como boa prática, o CGNAT não deve substituir a necessidade pela adoção do protocolo IPv6 nas redes dos ISPs. Aliás, inclusive, estimulamos que o IPv6 seja adotado o mais rapidamente possível para a sua infraestrutura ficar cada vez menos refém do CGNAT, pois há limitações e aborrecimentos associados a esta tecnologia. Quanto mais IPv6 você possuir em sua rede, menor será a dependência por CGNAT!<br /> <br /> ==== Control Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Controle. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, que é responsável por hospedar diversos dos protocolos e serviços para funções de redes nas Camadas 2 e 3, assim como as respectivas estruturas de dados mantidas pelos processos de cada um destes protocolos e serviços.<br /> <br /> Exemplos de protocolos que atuam nesta área do equipamento: Spanning Tree Protocol (STP), Resilient Ethernet Protocol (REP), Ethernet Automatic Protection Switching (EAPS), G.8032 Ethernet Ring Protection Switching, Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP), Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP), Resource Reservation Protocol for Traffic Engineering (RSVP-TE), Address Resolution Protocol (ARP), e muitos outros, lembrando que estes protocolos mantém as suas estruturas de dados, tais como LSDB (OSPF), LIB (LDP), BGP Table (BGP), ARP Cache (ARP), etc. A tabela de roteamento, também conhecida por RIB, é mantida no plano de controle dos roteadores.<br /> [[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]<br /> <br /> ==== CPAK ====<br /> <br /> ==== Data Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Dados. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, e que mantém as estruturas de dados relacionadas às ações de processamento de quadros (no L2) e pacotes (no L3). Estruturas de dados tais como a Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), Adjacency Table, Content Addressable Table (CAM ou MAC Table), são exemplos de estruturas de dados mantidas no Data Plane. As arquiteturas modernas de roteadores e switches tendem a combinar múltiplas estruturas de dados primárias e periféricas, geralmente mantidas em componentes de hardware especializados do equipamento, para construir e programar o ''pipeline'' de processamento de pacotes, para que, além da óbvia comutação do quadro ou o roteamento do pacote, outras ações possam ser executadas sobre os pacotes, tais como a determinação se um determinado pacote deverá ser tratado como L2 ou L3, consulta ou lookup de endereços IP, consulta à listas de controle de acesso (ACL), policiamento de taxa, queueing e prioridades, manipulação de cabeçalhos L2 e L3 (marcação, tradução de endereços, operações com tags de VLAN, operações com labels MPLS), etc. Exemplos de estruturas assim são as Ternary Content Addressable Memory (TCAM) e arranjos Tree-Bitmap (TBM) e M-trie.<br /> [[Arquivo:Bpf-protecao-roteadores-8.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Control Plane e Data Plane]]<br /> <br /> ==== DDoS ====<br /> Acrônimo: ''Distributed Denial of Service''.<br /> <br /> Conheça mais: [[O Minimo que voce precisa saber sobre DDoS|O Mínimo que você precisa saber sobre DDoS]] e [https://youtu.be/l2tVyz1Ba1A &lt;nowiki&gt;[BPF] Entrevista com o Thiago Ayub sobre ataques e mitigação DDoS&lt;/nowiki&gt;].<br /> <br /> Atividade criminosa que tem por objetivo promover a interrupção das operações de uma infraestrutura de redes através da sua incapacidade de continuidade de prestação dos serviços. Ou seja, como o próprio nome sugere, é um ataque de negação de serviços, porém distribuída, no sentido que milhares de dispositivos na Internet são controlados de forma maliciosa para lançarem ataques contra uma rede. Redes que são vitimadas sofrem dois padrões de distúrbios primários, sendo o primeiro o esgotamento de recursos computacionais dos equipamentos da rede, e, o segundo, a saturação dos enlaces de trânsito IP. Em qualquer uma das circunstâncias, os efeitos são muito negativos e percebidos pelos clientes do ISP afetado pela atividade criminosa. Os motivadores dos ataques de DDoS tem sido cada vez mais preocupantes, e são cada vez mais frequentes as situações envolvendo competidores inescrupulosos de um ISP que está sendo vítima de um ataque, mas há também muitos casos de criminosos que atacam ISPs por &quot;profissão e esporte&quot;, exigindo quantias em - sempre por pagamentos em criptomoedas, tais como o Bitcoin - para encerrar os ataques.<br /> <br /> ==== De-Peering ====<br /> Como o próprio nome sugere, é uma ação de desfeita de peering entre dois participantes ou entre um participante principal e múltiplos (dezenas) de outros participantes. O de-peer significa o encerramento da relação e a respectiva desconexão do acordo de peering entre dois sistemas autônomos. Mesmo que, de certa forma, um tanto raros, as motivações de um &quot;de-peer&quot; ou &quot;de-peering&quot; frequentemente estão associadas a mudanças na política de peering da organização principal, ou quando uma das duas partes envolvidas naquela relação de peering viola algum termo do acordo, algo que costuma promover o que chamamos de &quot;network clean-up&quot;. Algumas situações que tipificam e até mesmo justificam um de-peering: uma das duas partes está recebendo tráfego malicioso (ex: DDoS) excessivamente, e o acordo de peering pode ser interrompido em função disto. Violação da política de roteamento, onde um dos participantes injeta informações errôneas através desta sessão de peering (ex: route leak, hijack de prefixos, e &quot;vacilos&quot; similares), e isto é agravado quando a parte é reincidente, o que poderia justificar o cancelamento do acordo de peering. Mudanças na política de roteamento e peering de um dos participantes, e o entendimento que o referido acordo entre ambas as partes não é mais necessário ou interessante, ou ainda que a outra parte não mais atende os pré-requisitos para a manutenção deste acordo. E, para finalizar, possíveis problemas envolvendo capacidades e custos. Não é a toa que as modalidades de interconexão pagas (paid peering) tem se popularizado, em particular para lidar com as questões de capacidade e custos que em alguns casos poderiam justificar um de-peer de um ou mais participantes.<br /> <br /> ==== EAQ ====<br /> Acrônimo: ''Entidade Aferidora de Qualidade''<br /> <br /> A Entidade Aferidora da Qualidade (EAQ) foi criada em atendimento às Resoluções da Anatel 574 e 575 de 28 de outubro de 2011. A EAQ é parte do processo de aferição dos indicadores de qualidade das redes de telecomunicações que suportam o acesso à internet em Banda Larga fixa e móvel no Brasil, e a seleção desta entidade é feita de forma a garantir o cumprimento do Regulamento de Gestão da Qualidade do Serviço de Comunicação Multimídia - RGQ-SCM, aprovado pela Resolução nº 574, de 28 de outubro de 2011 e do Regulamento de Gestão da Qualidade da Prestação do Serviço Móvel Pessoal - RGQ-SMP, aprovado pela Resolução nº 575, de 28 de outubro de 2011.<br /> <br /> ==== eNodeB ====<br /> O Nó B do E-UTRAN, também conhecido como Evolved Node B ou eNodeB ou eNB, é o elemento no E-UTRA do LTE que é a evolução do elemento Nó B no UTRA do UMTS. É o hardware conectado à rede de telefonia móvel que se comunica diretamente sem fio com os telefones móveis (UEs), como uma estação base de transceptores (BTS) nas redes GSM. Tradicionalmente, um Nó B tem funcionalidade mínima e é controlado por um Radio Network Controller (RNC). No entanto, com um eNB, não há elemento controlador separado. Isso simplifica a arquitetura e permite menores tempos de resposta.<br /> <br /> ==== Ethernet ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O Ethernet é uma arquitetura de interconexão para redes de computadores, originalmente pensada para os ambientes de Redes de Áreas Locais (LAN), pois, naquele tempo, o Ethernet não era funcional para comunicações a longa distância, tais como circuitos de WAN e redes Metropolitanas (MAN). A tecnologia de transmissão do Ethernet é por regime estatístico e baseada no encaminhamento de quadros (''frames''). O Ethernet é especificado para velocidades de operação selecionadas entre 10 Mbps e 400 Gbps, usando uma especificação comum de controle de acesso ao meio físico (''Media Access Control'' ou MAC). O mecanismo de contenção para o compartilhamento do meio físico no Ethernet é feito por um procedimento denominado ''Carrier Sense Multiple Access with Detection Collision Detection'' (CSMA / CD), definindo tanto a operação de mídia compartilhada (half duplex), bem como a operação em full duplex. Ao longo dos anos o Ethernet sofreu vários aditivos para acomodar novas funcionalidades e capacidades, dentre as quais posso destacar aqui os padrões DCBX para o funcionamento do Ethernet em ambientes de Data Center críticos, por exemplo, permitindo transportar o ''Fibre Channel'' diretamente sobre o Ethernet (FCoE), e também os padrões Metro Ethernet / Carrier Ethernet que fizeram com que o Ethernet aos poucos fosse evoluindo e sendo adotado pelos operadores de rede / service providers / ISP, a ponto de hoje ser a tecnologia de enlace predominante neste setor. Os principais atrativos do Ethernet incluem a flexibilidade e excelente relação custo x benefício, especialmente quando comparado às tecnologias de transmissão determinísticas (ex: SDH), sendo este fator econômico o principal motivo quanto a expansão do Ethernet para os ISPs.<br /> <br /> ==== EVPN ====<br /> Acrônimo: ''Ethernet Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> Tecnologia de transporte de serviços de Camada 2 (L2) sobre infraestrutura MPLS ou VxLAN, ou seja, L2VPN, em especial buscando, através da evolução tecnológica e pela qualidade de suas ferramentas, cumprir com os mesmos objetivos da soluções L2VPN MPLS tradicionais, tais como o VPLS, H-VPLS e VPWS, sejam estes em implementação Martini ou Kompella, porém sem incorrer nas mesmas dificuldades e complexidades associadas a estes tecnologias clássicas. Em outras palavras, o EVPN é a legítima evolução da tecnologias L2VPN tradicionais, pois resolve muitos dos conhecidos desafios dos setups típicos de L2VPN. O EVPN tem como principal proposta a implementação de uma diversidade muito ampla de serviços L2 sobre infraestruturas baseadas no IP/MPLS e em regimes ponto-a-ponto e multiponto, sendo ideal para atendermos às demandas por L2VPN dos dias atuais e com maior flexibilidade e elasticidade. Como benefícios, o EVPN não exige um protocolo adicional como ocorre no L2VPN MPLS clássico (em especial a implementação Martini), e também não exige o emprego de Pseudowires. O EVPN usa o MP-BGP (mais precisamente o AFI 25 e SAFI 70) para trocar rotas específicas para esta família de endereços, promove maior eficiência no aprendizado e distribuição de endereços MAC, e com aprendizado destes ocorrendo no plano de controle, e não no plano de dados, permite redundância &quot;''All-Active''&quot;, além de outras interessantíssimas capacidades e recursos.<br /> <br /> ==== FlowSpec ====<br /> Acrônimo: ''BGP Flow Specification''.<br /> <br /> O recurso ou tecnologia BGP ''flow specification'' (flowspec) permite definir procedimentos para codificar regras de especificação de fluxo na forma de BGP ''Network Layer Reachability Information'' (NLRI) que podem ser usadas em diversas situações, sendo que a sua principal proposta é viabilizar o filtro de pacotes com o objetivo de mitigação de ataques de negação de serviços do tipo DDoS. Para se ter uma idéia, nos métodos tradicionais de mitigação de DDoS, como é o caso do RTBH (''Remotely Triggered Black Hole Filtering'' ou &quot;buraco negro disparado remotamente&quot;), uma rota BGP é injetada anunciando o endereço do site sob ataque juntamente com uma community BGP específica para este propósito de proteção. Essa community especial nos roteadores de borda serve para definir o próximo salto para um próximo salto especial - ou seja, uma modificação proposital do atributo &quot;NEXT_HOP&quot; da referida rota BGP - para descartar ou anular pacotes destinados àquele alvo, ou seja, permitindo que o tráfego de ataque destinado ao endereço IP/alvo seja descartado no backbone do ISP. Mesmo que isto permita oferecer boa proteção, a estratégia com o uso do RTBH torna o servidor ou host configurado com aquele endereço IP completamente inacessível. Por outro lado, o BGP flowpecpec permite uma abordagem mais granular e permite ainda que você efetivamente construa instruções para combinar um fluxo específico com a origem, destino, parâmetros L4 e especificações de pacotes, como comprimento, fragmento etc., possibilitando uma instalação dinâmica de uma ação nos roteadores de borda para: a) descartar o tráfego lançado contra o alvo. b) injetar o tráfego em uma VRF específica para uma análise mais detalhada. c) policiamento da taxa deste tráfego identificado pelo flowspec. Portanto, em vez de associar uma rota com uma community especial (RTBH) para que os roteadores de borda façam o descarte &quot;cru e nu&quot; do pacote, o BGP flowspec envia um formato de fluxo específico aos roteadores de borda, instruindo-os a criar uma espécie de ACL para que seja possível construir uma política com uma ação que você desejar (os casos &quot;a&quot;, &quot;b&quot; e &quot;c&quot; citados previamente). Para conseguir isso, o BGP flowspec adiciona um novo NLRI ao protocolo BGP, possibilitando fornecer detalhes sobre especificações de fluxos, critérios de correspondência (&quot;matching&quot;) suportados e ação de filtragem de tráfego.<br /> <br /> O BGP Flowspec é um aditivo muito sofisticado para as intenções dos ISPs na questão de mitigação de ataques DDoS em suas infraestruturas.<br /> <br /> ==== FTTH ====<br /> Acrônimo: ''Fiber-to-the-Home''.<br /> <br /> O &quot;''Fiber To The Home''&quot; (FTTH), também chamado de &quot;''Fiber To The Premises''&quot; (FTTP) ou ''&quot;Fiber To The Building''&quot; (FTTB), é o conceito de projeto, instalação o uso de fibra ópticas a partir de um ponto central diretamente para edifícios individuais, como residências, edifícios de apartamentos e empresas, para fornecer acesso à Internet em alta velocidade. O ''Fiber to the Home'' (FTTH) em si é um tipo de rede de acesso que oferece a alta velocidade de conexão à Internet, usando fibra óptica que é executada diretamente na casa, no prédio ou no escritório do assinante/cliente. O FTTH oferece aos consumidores acesso a uma grande variedade de aplicativos interativos, como comunicação por vídeo, jogos, vídeo sob demanda, teletrabalho e eSaúde, dentre uma diversidade muito grande aplicações que são possíveis com o uso de uma rede relativamente muito simples, porém bastante efetiva, e com ótima relação custo/benefício.<br /> <br /> ==== GGSN ====<br /> Acrônimo: ''Gateway GPRS Support Node''.<br /> <br /> O ''Gateway GPRS Support Node'' (GGSN) é um dos dois componentes do domínio ''Packet-Switched'' (PS) ''General Packet Radio Services'' (GPRS). O GGSN, juntamente com o SGSN (''Serving GPRS Support Node'', que entrega pacotes de dados de e para as estações móveis dentro de sua área de serviço), lida com transmissões de pacotes entre a rede GPRS e redes externas de baseadas em comutação de pacotes, como a Internet ou até mesmo de infraestruturas mais legadas baseadas em pacotes, como é o caso de uma rede X.25. Do ponto de vista de uma rede externa, o GGSN é um roteador para uma subrede, porque o GGSN acaba por &quot;ocultar&quot; a infraestrutura GPRS da rede externa. Quando o GGSN recebe dados endereçados a um usuário específico, verifica se o usuário está ativo. Caso afirmativo, o GGSN encaminha os dados para o SGSN que atende o usuário móvel, mas, caso o usuário móvel estiver inativo, os dados serão descartados. Na outra direção, os pacotes de origem móvel são roteados para a rede correta pelo GGSN, que é o ponto de ancoragem que permite a mobilidade do terminal do usuário nas redes GPRS / UMTS, onde, essencialmente, ele desempenha o papel no GPRS equivalente ao agente doméstico no IP móvel, e mantém o roteamento necessário para encapsular as unidades de dados de protocolo (PDUs) para o SGSN que atende uma determinada estação móvel (MS).<br /> <br /> ==== GPON ====<br /> Acrônimo: ''Gigabit Passive Optical Network''.<br /> <br /> ==== H-VPLS ====<br /> Acrônimo: ''Hierarchical Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN MPLS orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. A diferença primária entre H-VPLS e VPLS é que o H-VPLS procura promover uma hierarquia para o estabelecimento dos pseudowires e a efetiva troca de tráfego L2 entre os sites participantes, e com o objetivo de aprimoramos a escalabilidade e a eficiência da solução VPLS. Um dos maiores benefícios do H-VPLS é a redução do overhead de sinalização e também dos requerimentos de replicação de pacotes sobre os roteadores provider edge (PE). No H-VPLS, dois tipos de dispositivos PE são definidos: o u-PE e n-PE. O u-PE recebe o tráfego L2 nativo do cliente e faz as funções L2 locais, agrega o tráfego e o encaminha até o roteador n-PE, que é onde, de fato, ocorre o encaminhamento do tráfego pelo VPLS e com base no ''Virtual Switching Instance'' (VSI).<br /> <br /> ==== Hub-and-Spoke ====<br /> <br /> ==== IPFIX ====<br /> Acrônimo: ''Internet Protocol Flow Information Export''.<br /> <br /> O ''IP Flow Information Export'' (IPFIX), é um protocolo que especifica um método para que engenheiros de redes consigam exportar dados analíticos referentes aos fluxos de tráfego que percorrem em suas redes ou sistemas autônomos para estações coletoras, devidamente equipadas com soluções específicas baseadas em software, para fins de compreenderem com clareza as matrizes de comunicação referentes aos endereços IP de origem, endereços IP de destino, ordenamento de protocolos detectados ou registrados nestas conversações, portas de origem e destino (para o caso de TCP e UDP), marcações de QoS indicadas (ex: DSCP), sistemas autônomos envolvidos, volumetria destes fluxos que representam estas conversações, &quot;''top talkers''&quot;, dentre outros dados extremamente úteis. O IPFIX é um protocolo de padrão aberto que visa promover maior flexibilidade se comparado ao NetFlow da Cisco, seja na versão &quot;10&quot;, 9 ou 5, ao Juniper JFLOW, que é bastante similar ao NetFlow v5 da Cisco, e ao CFLOW. Comparativamente, o IPFIX contém os mesmos 79 campos do NetFlow v9, mas vai além e acomoda até 238 campos, o que possibilita uma lista bastante extensa de informações para atender a muitas das necessidades dos engenheiros de redes, e estando um passo à frente para inovações futuras. Assim como NetFlow/CFLOW/JFLOW, o IPFIX tem como proposta primária auxiliar profissionais de redes e empresas no planejamento de capacidades, bilhetagem e tarifação de tráfego, detecção e prevenção de incidentes de segurança, resposta automática a ataques de negação de serviço com acionamento de RTBH, dentre outras conhecidas aplicações. Vide &lt;nowiki&gt;RFC 7011&lt;/nowiki&gt; (''Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information'') para maiores informações.<br /> <br /> ==== IPoE ====<br /> Acrônimo: ''IP over Ethernet.''<br /> <br /> O ''Internet Protocol (IP) over Ethernet'' (IPoE) é uma das soluções adotadas para a disseminação do produto de Internet banda larga nas redes dos provedores de acesso à Internet. É basicamente uma forma de fornecer tráfego de Internet banda larga sem o encapsulamento PPP sobre o Ethernet. Atualmente, a tecnologia predominante para a autenticação e autorização de assinantes de Internet banda larga é o ''Point-to-Point Protocol over Ethernet'' (PPPoE), que, apesar de estar presente na grande maioria das instalações, possui alguns desafios e diversas limitações. O IPoE entra nesta seara justamente para substituir o PPPoE nos concentradores de assinantes (conhecidos por plataformas BNG ou BRAS), ou seja, para conquistarmos maior flexibilidade com a oferta de serviços para os assinantes sem incorrermos nos problemas e desafios associados ao uso massivo do PPPoE nestes equipamentos concentradores, dentre outras características, vantagens e benefícios. Dentre as principais vantagens em substituir o PPPoE pelo IPoE está na eliminação de um protocolo específico para o procedimento (PPP), consequentemente havendo uma redução bastante satisfatória do processamento dos equipamentos concentradores, pois, um dos principais &quot;problemas&quot; do PPPoE é que este introduz um cabeçalho adicional de 8 bytes de comprimento para cada pacote entre o dispositivo CPE/CE (assinante) e o concentrador onde a sessão do usuário foi autenticada e está estabelecida. E os concentradores de assinantes precisam manter o estado destas sessões para realizar diversos procedimentos para a manutenção do serviço do assinante. Outro &quot;problema&quot; do PPPoE está em sua dificuldade em lidar eficientemente com o tráfego Multicast, sendo que este problema não está presente o IPoE, o que pode ser um fator determinante para optar pelo IPoE para assinantes de Internet banda larga com o produto IPTV. O IPoE não é o &quot;the new kid on the block&quot;, e está por aí desde os primórdios do &lt;nowiki&gt;RFC 894&lt;/nowiki&gt;, sendo inclusive suportado há muitos anos pelos principais produtos concentradores do mercado.<br /> <br /> ==== IPv4 ====<br /> Acrônimo: ''Internet Protocol version 4''.<br /> <br /> ==== IPv6 ====<br /> Acrônimo: ''Internet Protocol version 6''.<br /> <br /> ==== IRR ====<br /> Acrônimo: ''Internet Routing Registry''.<br /> <br /> O ''Internet Routing Registry'' (IRR) é um banco de dados que possui objetos inseridos e mantidos através de uma linguagem própria denominada ''Routing Policy Specification Language'' (RPSL). Estas construções RPSL são expressas em diversos tipos de objetos dos bancos de dados que estão registrados em Registros Regionais da Internet (RIRs), os quais podem ser consultados pelo serviço Whois. Cada tipo de objeto de uma base de dados IRR pode representar um determinado tipo de informação, tal como um prefixo de propriedade ou alocado para um ISP, um objeto que divulgue a sua política de roteamento, ou um objeto que represente informações de contato administrativo e de suporte técnico, dentre outros tipos de objetos. O uso correto dos recursos de uma base IRR é amplamente estimulado entre os provedores de acesso à Internet para que cada um publique corretamente os seus prefixos (a título de objetos &quot;''route''&quot; e &quot;''route6''&quot;), os seus grupos representando, cada qual, seus upstreams de trânsito, peerings, e cones de clientes (por meios de objetos &quot;''as-set''&quot;), a divulgação da intenção em termos de política de roteamento (por meios de objetos &quot;''aut-num''&quot;, com campos &quot;''import''&quot;, &quot;''export''&quot;, &quot;''mp-import''&quot; e &quot;''mp-export''&quot;), além de objetos representando ações administrativas, tais como pessoal de contato para suporte (objetos &quot;''person''&quot; e &quot;''role''&quot;). A manutenção dos objetos em uma base IRR por um ISP é fundamental para que haja um consenso na Internet sobre como os filtros de anúncios devem ser construídos pelos Sistemas Autônomos, assim como fornecer a devida visibilidade para o acionamento dos times de suporte quando problemas ocorrerem com o roteamento de Internet envolvendo um determinado Sistema Autônomo. O ''Mutually Agreed Norms for Routing Security'' (MANRS) inclusive estabelece como dois dos seus principais objetivos a &quot;Coordenação&quot; e &quot;Validação Global&quot; entre os ISPs, cujas as ações são bastante centradas nos registros de objetos nas bases de dados de IRR, e com a divulgação do objeto &quot;''as-set''&quot; principal do ASN em seu cadastro no site PeeringDB. É importante salientar que muitos ISPs produzem filtros automaticamente com base nos registros de um sistema autônomo especificados numa base conhecida de IRR, daí a importância em certificar-se que o seu AS tenha os dados corretos inseridos na base de dados de um IRR, pois, a qualquer momento, algum ISP upstream poderá simplesmente recusar o recebimento de anúncios que tiverem sido originados no seu ASN, justamente por não haver consistência destas informações nos registros de uma base IRR.<br /> <br /> ==== IRU ====<br /> Acrônimo: ''Indefeasible Right of Use''.<br /> <br /> O direito de uso indefiável (IRU) é um tipo de contrato permanente de locação de telecomunicações, que não pode ser desfeito, entre os proprietários de um sistema de comunicações e um cliente desse sistema. A palavra &quot;indefiável&quot; significa &quot;incapaz de ser anulado ou desfeito&quot;. O IRU é o arrendamento efetivo de longo prazo (propriedade temporária) de uma parte da capacidade de um cabo submarino ou de outra infraestrutura de telecomunicações. Um exemplo deste tipo de arrendamento seria um IRU especificando um determinado número de canais de uma determinada largura de banda por um período bastante prolongado de uso. Neste caso, o IRU é concedido pela empresa ou consórcio de empresas que construíram o cabo, oferecendo a um provedor de serviços de Internet a capacidade de garantir à seus próprios clientes o trânsito internacional sobre este referido cabo, na capacidade assegurada pelo IRU, e por um período de prazo bastante prolongado.<br /> <br /> ==== IX ====<br /> Acrônimo: ''Internet Exchange''.<br /> <br /> Vide Ponto de Troca de Tráfego (PTT).<br /> <br /> ==== Jitter ====<br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> <br /> O jitter é a variação de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das &quot;especificações biológicas&quot; (auditivas e/ou visuais) do ser humano, que é o indivíduo que está interagindo com a aplicação através da rede com transmissões com níveis de jitter acima dos padrões aceitáveis.<br /> [[Arquivo:Bpf-qos-6.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Jitter]]<br /> <br /> ==== L2VPN ====<br /> Acrônimo: ''Layer 2 Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> O ''Layer 2 Virtual Private Network'' (L2VPN) consiste em um conceito que representa um conjunto de tecnologias orientadas ao transporte de serviços L2 sobre uma infraestrutura baseada no IP, com ou sem o auxílio do MPLS. Enquadram-se neste caso as tecnologias que obviamente exigem o MPLS para operar, como é o caso do ''Virtual Private LAN Service'' (VPLS), para a construção e transporte de redes L2 em regime multiponto, e o ''Virtual Private Wire Service'' (VPWS), para a construção e transporte de redes L2 em regime ponto-a-ponto, sendo que ambos operam sobre uma infraestrutura MPLS.<br /> <br /> Tecnologias de &quot;''tunneling''&quot; não deixam de ser também soluções de L2VPN, pelo menos no que diz respeito à privacidade e a segregação de serviços L2 de assinantes distintos sobre uma rede IP. Outro exemplo clássico de solução para este propósito é o ''Virtual Extensible LAN'' (VxLAN), muito utilizado em ambientes de data center como cenário centrado na elasticidade de domínios L2 e excelente mobilidade de workloads/VMs. E também, mais recentemente, a evolução das soluções L2VPN tradicionais para o ''Ethernet VPN'' (EVPN).<br /> <br /> No entanto, quando utilizando o termo &quot;L2VPN&quot;, estamos quase sempre nos referindo aos clássicos modelos VPLS e VPWS empregados nas redes MPLS dos operadores de rede, e estes serviços são provisionados com o auxílio de ''pseudowires'' com o protocolo LDP em vizinhança direcionada (T-LDP) entre os roteadores participantes de um determinado serviço, o que seria a proposta de implementação ''Martini'', ou então com o protocolo BGP, para a descoberta de vizinhos e também para o procedimento de sinalização, o que seria a proposta de implementação ''Kompella''.<br /> <br /> O principal objetivo da L2VPN é viabilizar o transporte de serviços L2, primariamente o Ethernet, através de uma rede completamente baseada no IP+MPLS, e sem que seja necessário estender as VLANs destes clientes atendidos através do backbone do operador de redes ou ISP. Ganha-se muito na questão operacional, além de aprimoramentos de indicadores importantes tais como a escalabilidade, confiabilidade, resiliência e melhor facilidade para o provisionamento e manutenção destes serviços. Os operadores de redes encontram no L2VPN uma forma bem adequada de fornecer serviços atraentes para seus clientes, tais como LAN-to-LAN, ''Data Center Interconnect'', &quot;''Clear Channel''&quot;, dentre outros, sem incorrer nas complexidades e riscos associados ao emprego das tecnologias L2 básicas em suas infraestruturas, tais como o entroncamento excessivo de VLANs de clientes nos uplinks do backbone, no provisionamento e manutenção de instâncias de protocolos de resiliência L2 (que são pouco escaláveis e um tanto inseguros em redes grandes), os riscos eminentes de ocorrerem ''bridging loops'' em função das extensões destas VLANs de clientes e respectivos protocolos de resiliência L2 no backbone do ISP, dentre outros argumentos muito sólidos.<br /> <br /> As L2VPNs podem ser utilizadas também para o transporte de tecnologias legadas sobre uma infraestrutura IP+MPLS, conforme tipificado pela solução ''Any Transport over MPLS'' (AToM) como um todo, permitindo, além do próprio Ethernet, o transporte de redes ''Asynchronous Transfer Mode'' (ATM), ''Frame Relay'', enlaces ponto a ponto ''High-Level Data Link Control'' (HDLC) e ''Point-to-Point Protocol'' (PPP), e até mesmo de outras tecnologias de transmissão digital, porém de natureza determinística (e não estatística, como seria o caso do Ethernet e do IP!), tais como ''Plesiochronous Digital Hierarchy'' (PDH) e ''Synchronous Digital Hierarchy'' (SDH)! Ou seja, soluções tais como o HDLCoMPLS, PPPoMPLS, FRoMPLS, CESoPSN, SAToP, TDMoIP, procedimentos GFP + LCAS + VCAT, etc. Para entender melhor estes casos, um tanto atípicos para os dias atuais, consulte o RFC 3985 (''Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture'') e outros RFCs. <br /> [[Arquivo:Bpf-enciclopedia-l2vpn.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN]]<br /> <br /> ==== L3VPN ====<br /> Acrônimo: ''Layer 3 Virtual Private Network''.<br /> <br /> ==== Latência ====<br /> Latência de rede é o termo usado para indicar qualquer tipo de atraso que ocorra na comunicação de dados em uma rede. As conexões de rede nas quais ocorrem pequenos atrasos são chamadas de redes de baixa latência, enquanto as conexões de rede que sofrem de longos atrasos são chamadas de redes de alta latência. A alta latência cria gargalos em qualquer comunicação de rede e impede que os dados tirem proveito máximo do canal de rede, diminuindo efetivamente a largura de banda de comunicação, além de apresentae aquela sensação de &quot;rede lenta&quot;. O impacto da latência na largura de banda da rede pode ser temporário ou persistente, com base na origem destes atrasos. Em termos práticos, a latência pode ser definida pelo tempo que leva para uma solicitação viajar do remetente para o destinatário e para o destinatário processar essa solicitação e fornecer a resposta para o remetente. Em outras palavras, o tempo de ida e volta do seu navegador para um servidor. Obviamente, é desejável que esse tempo permaneça o mais próximo possível de 0, no entanto, pode haver muitas coisas em jogo para impedir que os tempos de latência de um determinado serviço permaneçam baixos. Diversos elementos fatoram para o aumento da latência, dentre eles os atrasos de natureza fixa (serialização, transmissão e propagação) e os de natureza variável (processamento e enfileiramento/queueing), sendo que todos estes atrasos são adicionados por cada elemento de rede ativo que existir no caminho entre o cliente e o servidor. A latência pode e deve ser objeto de estudos e trabalhos de reestruturações tanto do aparato tecnológico em si (categoria dos elementos ativos, tais como roteadores, switches e concentradores) quanto das ações de engenharia de rede (organização topológica, emprego efetivo de recursos nos locais certos, etc.) e engenharia de tráfego (políticas consistentes de QoS, engenharia de tráfego MPLS, engenharia de tráfego do BGP, escolha e aquisição de enlaces com latências reportadas mais baixas, etc.). Em uma rede Ethernet, IP ou MPLS, a latência sempre existirá; é inevitável. O seu trabalho deverá saber projetar a rede, escolher bem seus componentes e dimensionar adequadamente seus recursos para que os índices de latência não sejam percebidos ou prejudiciais para a experiência de navegação e usabilidade de seus clientes.<br /> [[Arquivo:Bpf-qos-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: latência]]<br /> <br /> ==== MPLS ====<br /> Acrônimo: ''Multiprotocol Label Switching''.<br /> <br /> Conheça mais: [[Redes MPLS para Provedores]].<br /> <br /> Tecnologia de encaminhamento de pacotes cujas as operações não envolvem a consulta do cabeçalho IP. Numa rede completamente MPLS, o objetivo é fazer com que as consultas para a determinação de caminhos e o efetivo encaminhamento de pacotes ocorram por meios de instruções e operações mais simplificadas, denominadas &quot;''labels''&quot;, os quais são especificados em cabeçalhos enxutos chamados de &quot;''shim header''&quot;, e em três simples operações: imposição (push), troca (swap), e disposição (pop). O MPLS surgiu inicialmente como tecnologia visando atenuar o processamento dos roteadores de backbone dos grandes operadores de redes, pois as operações com ''labels'' tinham como apelo serem mais simplificadas e desprenderem menos esforços computacionais do que as operações com os cabeçalhos IP. Atualmente este argumento, ou motivador inicial quanto ao surgimento do MPLS, é praticamente nulo, em função da sofisticação das arquiteturas de roteadores dos dias atuais, pois os novos processadores conseguem sustentar ótimas taxas de encaminhamento de pacotes e independentemente se estes possuem ''labels'' ou não, e com múltiplos serviços concorrentes. No entanto, o MPLS como um todo evoluiu muito, e uma gama de funcionalidades excepcionais foram agregadas para rodar no topo das infraestruturas MPLS, obviamente exigindo o ''label switching'' para isto, assegurando qualidade, flexibilidade e elasticidade para quase tudo o que temos de bom nas infraestruturas de redes dos ISPs. Exemplos de soluções que rodam e/ou que dependem do MPLS para funcionar incluem L3VPN MPLS, L2VPN MPLS, MPLS TE, MPLS QoS, GMPLS. Algumas destas tecnologias que rodam no topo do MPLS surgiram para resolver problemas bastante conhecidos existentes em ambientes legados, tais como escalabilidade, confiabilidade, convergência e afins (ex: L2VPN MPLS visando sanear os desafios das redes L2 clássicas; MPLS TE visando resolver os desafios de engenharia de tráfego IP, etc.), e isto ao mesmo tempo em que outros conceitos foram surgindo para fomentar ainda mais a escalabilidade, flexibilidade e redução de custos (BGP-Free Core, 6PE/6VPE, e Unified MPLS são exemplos clássicos). O MPLS pode ser considerado como um marco, um verdadeiro divisor de águas, para todo o segmento de telecomunicações.<br /> <br /> ==== MPLS Traffic Engineering ====<br /> Conheça mais: [[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]].<br /> <br /> O MPLS-TE é uma solução que embarca duas propostas principais: a) engenharia de tráfego, b) proteção e recuperação contra falhas de enlaces e roteadores. Embora frequentemente combinado com os projetos MPLS clássicos (sem TE), o MPLS-TE não depende dos procedimentos do MPLS LDP. Para a parte de engenharia de tráfego, o MPLS-TE propõe-se a sanar algumas deficiências que são inerentes do próprio roteamento IP, os quais incluem congestionamentos decorrentes do mapeamento ineficiente dos fluxos de tráfego sobre os recursos da rede (interfaces, enlaces e roteadores), e fazendo isso com um bom arranjo de ferramentas que permite flexibilidade para a manipulação dos fluxos de tráfego através da rede do ISP e sem que isto exija modificações complexas nas propriedades do roteamento IP, tais como distância administrativa e métricas de rotas IGP, políticas de roteamento no backbone, rotas estáticas e afins. Já para a questão da rápida recuperação de falhas, o MPLS-TE fornece um recurso denominado Fast Reroute (FRR), o qual, através de uma estratégia conhecida por &quot;''Make-before-Break''&quot;, viabiliza a construção de LSPs de contingência para pronto uso em caso de falhas do next hop ou do nexto hop do next hop, promovendo índices de recuperação de falhas aproximados em 50 milissegundos.<br /> <br /> ==== Multi-CDN ====<br /> <br /> ==== Multi-tenant ====<br /> <br /> ==== NAT ====<br /> Acrônimo: ''Network Address Translation''.<br /> <br /> Tecnologia que realiza a tradução de endereços IP especificados nos cabeçalho IP dos pacotes em trânsito em um roteador. O NAT foi concebido originalmente como uma das iniciativas de soluções para conter o &quot;desmatamento&quot; do endereçamento IPv4, ou seja, sendo usado para conter ou desacelerar o rápido esgotamento da disponibilidade de endereços IP públicos. Há muitos anos iniciativas tais como o ''Classless Interdomain Routing'' (CIDR), ''Variable Length Subnet Masking'' (VLSM), endereçamento IPv4 privativo (IANA RFC 1918 [rfc:1918 - Address Allocation for Private Internets]), e ''Network Address Translation'' (NAT) foram introduzidas nos conceitos de projetos de redes para que tivéssemos a sobrevida do espaço de endereços IPv4 públicos até os dias atuais. Estima-se que, sem estas iniciativas, o esgotamento destes endereços teria ocorrido há muito tempo. Falando especificamente de NAT, esta solução anda lado a lado, como &quot;unha e carne&quot;, com os endereços IP privativos. Redes corporativas e domésticas/residenciais inteiras são endereçadas com endereços IP privativos (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16), e não há rotas no backbone da Internet para estes prefixos. Para que um usuário portando um endereço IP privativo destes possa navegar pela Internet, torna-se necessário realizar a tradução de seu endereço IP de origem para um endereço IP público disponível através desta configuração de NAT. Há vários tipos de cenários envolvendo o NAT, tais como o NAT dinâmico (numa relação ''one-to-one''), o ''Port Address Translation'' (também dinâmico, mas numa relação ''many-to-one''), NAT estático (relação 1:1) e NAT estático por portas (relação 1:1 com portas), sendo que o PAT ou &quot;''masquerading''&quot; é um dos cenários mais amplamente difundidos. Para os ISPs ou operadores de rede, no que diz respeito à conectividade de Internet de assinantes residenciais com endereços IPv4, no entanto, não utiliza-se o NAT &quot;convencional&quot;, e sim uma extensão funcional denominada ''Carrier Grade NAT'' (CGN ou CGNAT), já citada em nossa Enciclopédia, em combinação com outra faixa de endereços IPv4 privativos, a 100.64.0.0/10 (conforme [rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]). Para finalizar, entenda que o NAT pode ser usado também para a tradução de endereços IP de destino, mas fica à critério de cada projeto técnico e de suas particularidades.<br /> <br /> ==== NETCONF/Yang ====<br /> Acrônimo: ''Network Configuration''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no &lt;nowiki&gt;RFC 6241&lt;/nowiki&gt;. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações. Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração &quot;na mão&quot;. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, &quot;automatizados&quot;, é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho. O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, e é tido por muitos como a melhor interface southbound para ambientes de orquestração atualmente.<br /> <br /> O YANG por sua vez é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.<br /> <br /> ==== NetFlow ====<br /> A tecnologia como um todo é composta por caches de fluxo, coletores de fluxo e analisadores de dados. O NetFlow, quando foi criado há muitos anos, surgiu inicialmente como uma proposta para ''switching path'', mas rapidamente evoluiu para aquilo que muitos dos profissionais de redes compreendem sobre ele. O NetFlow é atualmente e há muitos anos uma tecnologia que visa fornecer excepcional visibilidade na rede e em resposta aos constantemente evoluídos requisitos para que os operadores de redes saibam como as suas redes estão se comportando, e fornecendo respostas para situações tais como: mapa de uso de aplicativos e redes, produtividade e utilização de recursos de rede, impacto das alterações na rede, detecção de anomalias na rede, assim como a identificação de vulnerabilidades de segurança, e problemas de conformidade a longo prazo. Para estas e outras necessidades, os engenheiros de redes passam a possuir ferramentas para entender quem, o que, quando, onde e como o tráfego da rede está fluindo, fomentando melhor entendimento sobre como as tecnologias empregadas na rede estão funcionando em alinhamento com os negócios da empresa; trilha de auditoria de como a rede é utilizada, aumento da conscientização quanto aos investimentos e uso da rede como um todo, redução de vulnerabilidades da rede, redução dos índices de downtime e distúrbios gerais, redução de custos, etc. O NetFlow pode ser usado como uma ferramenta &quot;simples&quot; para o gerenciamento de performance da rede, ou para situações bem mais ousadas, incluindo ações de planejamento de capacidades, engenharia de rede, engenharia de tráfego, bilhetagem e tarifação de tráfego, e detecção e mitigação de malware e de ataques DDoS sobre a rede, para citar alguns casos. Em termos práticos, o NetFlow é configurado em roteadores e switches, onde estiver disponível/suportado, podendo ser customizável em alguns casos, e, após isto, o equipamento exportará os bilhetes de fluxos de tráfego por NetFlow até uma estação coletora, a qual processará e consumirá estes dados, de acordo com os exemplos de soluções e casos citados anteriormente, e podendo interagir de volta com a rede para que ações sejam executadas pelos dispositivos da rede.<br /> <br /> O NetFlow é um protocolo proprietário da Cisco, mas que está disponível em outros fabricantes do mercado. O seu equivalente em termos de padrão aberto é o protocolo ''Internet Protocol Flow Information eXport'' (IPFIX).<br /> <br /> ==== NFV ====<br /> Acrônimo: ''Network Functions Virtualization''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware &quot;''commodity''&quot;. Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado. Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. <br /> <br /> ==== NodeB ====<br /> Um Node B é um termo para denotar uma estação base na terminologia WCDMA/UMTS, e é responsável pelo enlace de rádio entre o usuário da rede móvel e a parte fixa da rede ''UMTS Terrestrial Radio Access Network'' (UTRAN), conforme definido pelo 3GPP, ou seja, fornecendo a cobertura de rádio e conversão de dados entre esta rede de rádio e os ''Radio Network Controllers'' (RNCs).<br /> <br /> ==== OM ====<br /> OM1 - <br /> <br /> OM2 - 62,5/125 microns<br /> <br /> OM4 - 50/125 microns<br /> <br /> ==== Open/R ====<br /> (IGP virtualizado)<br /> <br /> ==== OSPF ====<br /> Acrônimo: ''Open Shortest Path First''.<br /> <br /> Conheça mais: [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas práticas para a implantação do OSPF em ambientes de ISP]]<br /> <br /> Protocolo de roteamento dinâmico do tipo interior e por definição de estado de enlaces (Link-State). O OSPF é um dos principais componentes das infraestruturas de redes dos provedores de acesso à Internet, sendo indispensável para viabilizar o roteamento necessário para o transporte das sessões BGP, resolução de roteamento recursivo referente ao atributo NEXT_HOP das rotas BGP mantidas nos Sistema Autônomo do ISP, além de atuar também para funções de roteamento de alguns serviços internos específicos do ISP. Muito frequentemente o OSPF é utilizado, também, em alinhamento com a tecnologia para fins de engenharia de tráfego com o MPLS TE, sendo, neste caso, inclusive, um componente obrigatório para este tipo de projeto. O OSPF destaca-se pela eficiência nas ações de rápida convergência, rápida recuperação de falhas e escalabilidade. Alternativamente ao OSPF, os operadores de redes podem optar pelo protocolo de roteamento IS-IS.<br /> <br /> ==== PCC ====<br /> Acrônimo: ''Path Computation Client.'' <br /> <br /> O PCC é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), o próprio cliente PCC (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCE ====<br /> Acrônimo: ''Path Computation Element''.<br /> <br /> O PCE é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCEP ====<br /> Acrônimo: ''Path Computation Element Communication Protocol''.<br /> <br /> O PCEP é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client'' (PCC)), o próprio protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)). O novo paradigma de redes programáveis orientadas a aplicações foi o que impulsionou as extensões PCEP, as quais possuem definições nos ''drafts draft-ietf-pce-stateful-pce'', ''draft-crabbe-pce-pce-initiated-lsp'', ''draft-ali-pce-remote-initiated-gmpls-lsp'', e outros.<br /> <br /> ==== Peering ====<br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Peering ou Troca de tráfego é uma relação comercial e técnica entre duas redes. É um acordo em que as redes admitem trocar tráfego entre os clientes uns dos outros, desde que o relacionamento seja '''mutuamente benéfico''', e nem sempre os acordos são isentos de custo ou trocas comerciais. Para garantir que cada lado do acordo tenha benefícios similares, as redes podem precisar atender aos requisitos pré-definidos para serem elegíveis. Por exemplo, uma rede pode precisar manter uma certa proporção de troca de tráfego, presença geográfica ou capacidade de backbone. A implantação real dessas relações de Peering, geralmente ocorre em locais comuns, como os NAPs e IXs estabelecidos pelo mundo (''Public'' Peering), ou através de links dedicados pagos pelas redes envolvidas (PNI-''Private network Interconnect'').<br /> <br /> ==== PGW ====<br /> Acrônimo: ''Packet Data Network Gateway''.<br /> <br /> ==== PNI ====<br /> Acrônimo: ''Private Network Interconnection''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> O famoso Private Peering ou Interconexão Privada em português - é aquele que normalmente não envolve quaisquer pontos de troca pública, ou seja, são portas de roteadores ''back-to-back'' normalmente interligadas por um ''cross-connect'' ou &quot;''golden jumper''&quot; ou até por capacidade em redes de transporte ''LAN-to-LAN''.<br /> <br /> ==== PPPoE ====<br /> Acrônimo: ''Point-to-Point Protocol over Ethernet''.<br /> <br /> O PPPoE é um protocolo utilizado para encapsular quadros PPP dentro de quadros Ethernet, tendo surgido no final dos anos 90 juntamente com a proliferação da Internet banda larga proporcionada com a entrada das tecnologias de transmissão baseadas no DSL. O PPPoE servia então como uma solução de tunelamento dos pacotes sobre a conexão DSL. Atualmente, com a predominância das redes FTTH, o PPPoE continua sendo utilizado nas redes dos ISPs, mas primariamente como mecanismo de autenticação e autorização de assinantes dos produtos de Internet banda larga dos ISPs, sendo o principal procedimento utilizado para este propósito, e a sua operação neste modelo ocorre entre o equipamento do assinante (CPE/CE) e o concentrador de assinantes (BNG ou BRAS), cuja a separação poderá ser uma rede Metro Ethernet (L2) clássica, ou L2 sobre MPLS (L2VPN), ou xPON.<br /> [[Arquivo:Bpf-protecao-roteadores-7.png|centro|miniaturadaimagem|600x600px|Enciclopédia: PPPoE]]<br /> <br /> ==== PTT ====<br /> Acrônimo: ''Ponto de Troca de Tráfego''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Ponto de Troca de Tráfego (PTT), em inglês ''Internet Exchange Point'' (IXP), é um modelo de interconexão de redes entre os provedores de Internet e redes de fornecimento de conteúdo. Os Pontos de Troca de Tráfego (PTT) funcionam como hubs em que provedores podem conectar seus sistemas autônomos (AS), facilitando o tráfego de informações entre si. No Brasil, o IX.br é um projeto de PTTs locais gerido pelo Núcleo de Informação e Coordenação do Ponto Br (NIC.br) e pelo Comitê Gestor da Internet no Brasil (CGI.br), que facilita o fluxo de informações entre provedores de Internet e conteúdo online em diversas regiões no país. Na prática, quanto maior e melhor for um PTT, mais dados os provedores conseguem trocar, melhorando a eficiência da rede e encurtando o caminho da conexão entre os computadores, pois projetos de PTTs como o do IX.br proporcionam a ligação direta entre os participantes, permitindo que muitos Sistemas Autonômos (AS) troquem tráfego diretamente. A interligação de diversos AS em um IX, ou Ponto de Troca de Tráfego (PTT), simplifica o trânsito da Internet e diminui o número de redes até um determinado destino. Isso melhora a qualidade, reduz custos e aumenta a resiliência da rede. Também é possível oferecer ou contratar outros serviços a partir da conexão do seu ISP em um IX, como, por exemplo, serviços de trânsito de Internet.<br /> <br /> ==== QoS ====<br /> Acrônimo: ''Quality of Service''.<br /> <br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]].<br /> <br /> O ''Quality of Service'' (QoS) não deve ser compreendido como uma única tecnologia apenas, e sim um conjunto de tecnologias, ferramentas e práticas que, devidamente arrendadas, buscam sanear algumas das deficiências típicas de transmissão presentes em ambientes de redes de natureza estatística, especialmente o controle de latência, jitter, e perda de pacotes, decorrentes da insuficiência de recursos para a transmissão de pacotes nestes ambientes, como, por exemplo, os conhecidos gargalos/congestionamentos, esgotamento de buffers, e outros. Com a convergência de praticamente todo o tipo de aplicação e serviço para o transporte sobre redes baseadas no protocolo IP, soluções estas tais como Voice over IP (VoIP), Comunicações Unificadas (aka &quot;Telefonia IP e/ou Colaboração&quot;), Vídeo-conferência (em regime específico para tal, ou em conjunto com uma solução de Colaboração), etc., os engenheiros de redes precisam acomodar adaptações que permitam com que estes tipos de tráfego fluam de acordo com os padrões aceitáveis para uma boa interação humana através destas redes - em particular a audição e a visão. Anteriormente as soluções de vídeo e voz funcionavam sobre infraestruturas de redes digitais, ou seja, baseadas em transmissão deterministica, as quais não sofriam dos mesmos problemas das redes de transmissão estatísticas e baseadas em pacotes (congestionamentos; gargalos, descartes de pacotes devido a insuficiência temporária de buffers, etc.), como é o caso do Ethernet, IP e MPLS. Os requerimentos para o transporte de voz são bem mais agressivos nas questões de latência, jitter e perda de pacotes, se comparados com as transmissões de aplicações puramente de dados. As transmissões de vídeo podem ser extremamente agressivas, pois possuem os mesmos requisitos de latência, jitter e perda de pacotes das transmissões de voz, só que comportam-se em grande parte como uma aplicações de dados com elevada taxa de transmissão e consumo de recursos da rede. Para que a experiência de uma comunicação entre duas pessoas através de um serviço de VoIP/Telefonia IP/Colaboração/Vídeo fique isenta de picotes na voz, metalização da voz, ecos, atrasos excessivos, congelamento de imagens, perda de sincronismo entre vídeo e áudio, dentre outros, torna-se necessário priorizar estes tipos de transmissão com auxílio de políticas e configurações específicas. E é exatamente para isto que o QoS precisa ser adotado nas redes nos dias atuais. O mesmo é válido quando tratando-se de transmissões na rede envolvendo uma aplicação de dados crítica (um sistema ERP ou CRM) e uma navegação usual ou recreativa de Internet, onde, nestes casos, é muito desejável que a prioridade de transmissão seja de uma aplicação mais importante quando houver insuficiência de recursos para acomodar ambos os tipos de tráfego em um determinado momento. <br /> <br /> O QoS especifica uma diversidade de ferramentas e técnicas devidamente categorizadas em Classificação, Marcação, Gerenciamento de Congestionamentos, Controle de Congestionamentos, Policiamento, Moldagem e Eficiência de Links. <br /> [[Arquivo:Bpf-qos-9.png|centro|miniaturadaimagem|600x600px|Enciclopédia: QoS]]<br /> <br /> ==== QSFP ====<br /> Acrônimo: ''Quad Small Form Factor Pluggable''.<br /> <br /> ==== RADIUS ====<br /> Acrônimo: ''Remote Authentication Dial In User Service''.<br /> <br /> ==== RGI Classe V da Anatel para SCM ====<br /> <br /> ==== RNC ====<br /> Acrônimo: ''Radio Network Controller''.<br /> <br /> ==== Roteador ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== Route-policy ====<br /> Uma route policy é uma ferramenta que &quot;materializa&quot; ou &quot;instrumentaliza&quot;, através de conceitos de sintaxe e semântica de uma interface de linha de comando (CLI), que é parte integrante do sistema operacional de roteadores, a política de roteamento idealizada pelo administrador ou engenheiro de uma rede para o seu projeto ou o atendimento de uma necessidade específica. Enquanto uma &quot;política de roteamento&quot; é o conceito projetado para uma interpretação mais humana da palavra, pois especifica a idéia, intenção ou interesse; é a &quot;política no papel&quot;, como, por exemplo, na perspectiva de cada roteador BGP vizinho ao seu roteador, quais prefixos importar, quais prefixos exportar, quais atributos deverão ser modificados, e sobre quais prefixos/rotas estas modificações devem ser feitas, para conceber quaisquer que sejam as necessidades em termos de engenharia de rede e de tráfego do projeto técnico idealizado pelo engenheiro da rede, contemplando ainda questões associadas à segurança do roteamento de Internet (prevenção de ''route leaks'', ''prefix hijacks'', supressão do recebimento e envio de ''bogons''/''martians''/''unallocated'', etc.). A '''''route policy''''', por sua vez, já é a efetiva instrumentação propriamente dita desta política de roteamento. É a &quot;policy&quot; na sua forma de configuração na linguagem suportada pelo sistema de seu roteador. Ou seja, &quot;os comandos&quot; da CLI, a sintaxe, a semântica. O termo route policy em si serve para o generalizar um conjunto de ferramentas que são encontradas nos roteadores e utilizadas para definirmos &quot;na forma de CLI&quot; as nossas políticas de roteamento, as quais deverão ser aplicadas nos sentidos &quot;entrada&quot; (''import'' ou &quot;''in''&quot;) e &quot;saída&quot; (''export'' ou &quot;''out''&quot;) de nossas vizinhanças BGP. Cada plataforma de roteador e de cada fabricante tem o seu conjunto próprio de ferramentas, capacidades, sintaxes, recursos suportados (e não suportados), etc. Por exemplo, roteadores Juniper (software &quot;JUNOS&quot;) implementam as suas facilidades por meios do ''Routing Policy Framework'', que consiste de termos (&quot;''terms''&quot;) definidos na forma de um ou mais ''policy-statement'', com sofisticadas e variadas opções de incidência de classificação (''match'') e ações a serem adotadas em cada incidência (''accept'', ''reject'', modificar atributos, etc.), e podendo ainda acionar outras ferramentas e recursos periféricos para uma classificação mais refinada dos prefixos (ex: ''route-filter-list'', ''community'', etc). Roteadores Cisco equipados como Cisco IOS XR Software, por sua vez, possuem um sistema periférico muito robusto denominado ''Routing Policy Language'' (RPL), que combina diversos tipos de objetos (''prefix-set'', ''as-path-set'', ''community-set'', ''extcommunity-set'', dentre outros), para definir uma sofisticada, porém de simples interpretação, política de roteamento na forma de &quot;''route-policy''&quot;, com operações intuitivas na forma de &quot;''if'' / ''else'' / ''then'' / ''set'' / ''pass'' / ''drop'' / ''done'' / ''endif'', etc.&quot;. Já os roteadores da Cisco baseados no Cisco IOS e IOS XE Software apresentam as conhecidas e pioneiras &quot;''Route Maps''&quot;, as quais atuam em conjunto com outros recursos disponíveis na plataforma, tais como ''prefix-lists'', ''community-lists'', ''ip as-path access-lists'', e outras. Já os roteadores da Huawei no geral implementam recursos similares em termos de implementação aos do Cisco IOS / IOS XE, tais como ''route-policy'', ''ip-prefix'', ''community-filter'' e outros, enquanto equipamentos mais recentes deste fabricante já implementam uma solução diferente denominada ''eXtended routing-Policy Language'' (XPL), inspirada no RPL do Cisco IOS XR. Independentemente do &quot;vendor&quot; ou do equipamento, o fato é que route policies são indispensáveis, pois são usadas cotidianamente para o cumprimento de diversos objetivos relacionados ao roteamento de Internet ou de qualquer projeto de infraestrutura IP onde o BGP seja utilizado para fornecer segurança e engenharia de tráfego.<br /> <br /> ==== RPKI ====<br /> Acrônimo: ''Resource Public Key Infrastructure (RPKI)''.<br /> <br /> ==== RTBH ====<br /> Acrônimo: ''Remotely Triggered Black Hole (RTBH)''.<br /> <br /> ==== RUM ====<br /> <br /> ==== SBI ====<br /> Acrônimo: ''Settlement Based Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão também conhecido como Peering Pago (Paid Peering), onde uma das redes paga a outra pela troca de tráfego.<br /> <br /> ==== SCM ====<br /> Acrônimo: ''Serviço de Comunicação Multimídia''.<br /> <br /> ==== SDN ====<br /> Acrônimo: ''Software-Defined Networking''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.<br /> [[Arquivo:Bpf-prog-sdn3.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SDN]]<br /> <br /> ==== SeAC ====<br /> Acrônimo: ''Serviço de Acesso Condicionado''.<br /> <br /> ==== SFI ====<br /> Acrônimo: ''Settlement-free Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão onde nenhuma das partes paga a outra pela troca de tráfego entre ambas.<br /> <br /> ==== SFP ====<br /> Acrônimo: ''Small Form Factor Pluggable''.<br /> <br /> ==== Segment Routing (SR) ====<br /> <br /> ==== Segment Routing v6 (SRv6) ====<br /> <br /> ==== SGSN ====<br /> Acrônimo: ''Serving GPRS Support Node''.<br /> <br /> ==== STFC ====<br /> Acrônimo: ''Serviço Telefônico Fixo Comutado''.<br /> <br /> ==== SMP ====<br /> <br /> ==== SNMP ====<br /> Acrônimo: ''Simple Network Management Protocol''.<br /> [[Arquivo:Bpf-protecao-roteadores-5.png|centro|miniaturadaimagem|600x600px|Enciclopédia: SNMP]]<br /> <br /> ==== SSH ====<br /> Acrônimo: ''Secure Shell''.<br /> <br /> ==== Switch ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== SyncE ====<br /> Acrônimo: ''Synchronous Ethernet''.<br /> <br /> O SyncE é uma das quatro soluções de ''timing'' sobre redes de transmissão baseadas em pacotes, juntamente com o ''Precision Time Protocol'' (PTP), ''Network Time Protocol'' (NTP) e ''Timing over IP Connection and Transfer of Clock BOF'' (TICTOC). O SyncE é ao mesmo tempo um protocolo e um método de sincronismo para instruções de ''timing'' operando diretamente sobre o Ethernet, ou seja, sem o envolvimento de protocolos de camadas superiores (ex: IP, UDP ou TCP), e possui um procedimento que remonta ao que as redes SDH fazem. O SyncE é utilizado especialmente para o sincronismo de frequência, sendo inclusive muito preciso quanto a isto, mas não provê sincronismo de data e hora, pois este tipo de distribuição de informação (data/hora) precisa ou deve ser feita por outro protocolo (ex: NTP ou PTP). Diversos padrões regem o SyncE, dentre eles o ITU-T G.8261, G.8262, G.8264 e G.781. Em termos de eficácia, o SyncE é a referência de frequência mais estável e a mais precisa disponível atualmente, após as opções por PRC, BITS e GPS, e operadores de telefonia móvel estão avançando no suporte ao SyncE em suas redes como medida de redução de custos e sem o comprometimento da qualidade, ou seja, evitando instalações de GPS em cada estação da rede móvel.<br /> <br /> ==== TACACS+ ====<br /> Acrônimo: ''Terminal Access Controller Access-Control System Plus''.<br /> <br /> ==== Telnet ====<br /> <br /> ==== Trânsito ====<br /> <br /> ==== uRPF ====<br /> Acrônimo: ''Unicast Reverse Path Forwarding''.<br /> <br /> O ''Unicast Reverse Path Forwarding'' (uRPF) é um recurso disponível no software dos roteadores que é utilizado primariamente como mecanismo de &quot;antispoofing&quot;, ou seja, serve para a validação do endereço IP de origem sobre os pacotes recebidos nas interfaces do roteadores. A outra funcionalidade do uRPF é atuar como mecanismo de prevenção de ''routing loops'', em especial em situações relacionadas ao IP Multicasting. No que concerne ao mecanismo de &quot;antispoofing&quot; de endereços IP de origem em tráfego unicast em si, o uRPF é a ferramenta mais indicada para ser adotada nas interfaces que apontam diretamente para as conexões do cone de clientes (downstreams) do provedor de acesso à Internet (ISP), sendo ali o ponto correto de posicionamento e configuração deste mecanismo. Quanto as razões para a utilização do uRPF, o principal e mais forte argumento é a eliminação ou redução dos vetores de ataques DDoS, pois, para que este tipo de ataque possa ser bem sucedido, torna-se necessário que os hosts infectados (&quot;zumbis&quot;), que, neste caso, seriam os clientes do seu ISP, e de outros ISPs também, controlados por uma botnet, encaminhem pacotes com endereços IP de origem &quot;spoofados&quot; (forjados) para que aparentem terem sido enviados a partir do host ou rede que será a vítima deste ataque (cujo seu(s) endereço(s) IP foi (foram) forjado(s)/spoofado(s) por dezenas de milhares de outros hosts na Internet), o que promoverá, consequentemente, e infelizmente, o êxito deste ataque DDoS. Ou seja, sem o spoofing de endereços IP de origem, conceber ataques DDoS na Internet fica uma tarefa praticamente impossível - ou até que outras formas de ataques de negação de serviço sejam idealizadas pelos malfeitores da Internet. Por estas e outras razões que o &quot;Antispoofing&quot;, que inclusive é um dos objetivos estipulados pelo ''Mutually Agreed Norms for Routing Security'' (MANRS), deve ser projetado e configurado corretamente em todas as interfaces que admitem os clientes de um ISP, ou seja, em todo o seu &quot;downstream&quot;. Se todos os ISPs fizessem isso, simplesmente não haveria ataques DDoS na Internet. Ou pelo menos não nos moldes em que estes ataques são concebidos atualmente. Há algumas formas ou modalidades de implementação do uRPF, sendo eles o &quot;''Strict''&quot;, &quot;''Feasible''&quot; e &quot;''Loose''&quot;. Alternativamente ao uRPF, há outras ferramentas que podem ser consideradas para este propósito de antispoofing, incluindo Access Control Lists e IP Source Guard, mas, no caso de service providers / ISPs, o uRPF é o mecanismo mais indicado. Faça a sua parte e contribua para uma Internet mais segura: siga as recomendações do BCP 38 (''Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing''), que é citado no objetivo &quot;Antispoofing&quot; do MANRS, e ajude a reduzirmos substancialmente os ataques DDoS que assolam a Internet!<br /> <br /> ==== VPLS ====<br /> Acrônimo: ''Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. <br /> [[Arquivo:Bpf-enciclopedia-vpls.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN multiponto (VPLS)]]<br /> <br /> ==== VPNv4 ====<br /> Acrônimo: ''Virtual Private Network version 4''.<br /> <br /> O VPNv4 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv4 é definido como uma extensão para o suporte mulitprotocolo do BGP (&lt;nowiki&gt;RFC 4364&lt;/nowiki&gt; e &lt;nowiki&gt;RFC 4659&lt;/nowiki&gt;), e é representado pelo ''Address Family Identifiers'' (AFI) número 1 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. O endereço VPNv4 possui 96 bits de comprimento, sendo 64 bits composto pelo ''Route Distinguisher'' e os 32 bits restantes sendo o prefixo IPv4 da rota original (ex: envidada do roteador CE para o roteador PE, antes da conversão desta rota IPv4 unicast para uma rota VPNv4 pelo roteador PE). Roteadores ''Provider Edge'' (PE) de um backbone de operadora de telecomunicações ou ISP são configurados para trocar rotas VPNv4 através de sessões MP-BGP entre si, as quais são devidamente estabelecidas sobre uma rede MPLS para viabilizar a comunicação entre os sites participantes de uma determinada VPN, usando outros atributos associados aos anúncios destas rotas VPNv4 (ex: extended communities denominadas ''Route Targets'', dentre outros parâmetros e atributos).<br /> <br /> ==== VPNv6 ====<br /> Acrônimo: ''Virtual Private Network version 6''.<br /> <br /> O VPNv6 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv6 é representado pelo ''Address Family Identifiers'' (AFI) número 2 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. Um endereço VPNv6 possui 64 bits de comprimento, sendo 8 octetos o &quot;''Route Distinguisher''&quot; e 16 octetos o endereço IPv6 unicast. À exemplo do VPNv4, o VPNv6 é trocado entre roteadores PE com o auxílio do protocolo BGP (MP-BGP) para o estabelecimento de L3VPN MPLS funcionais com o IPv6 dos sites atendidos/conectados. Para estas L3VPN com IPv6, as sessões IBGP entre os roteadores PE participantes poderá ser feita em IPv4 ou IPv6, e a codificação do atributo NEXT_HOP será distinta para cada caso (&quot;''BGP speaker requesting IPv6 transport''&quot; ou &quot;''BGP speaker requesting IPv4 transport''&quot;). Sobre a codificação do atributo Next Hop, um draft recente está propondo a modificação de alguns destes procedimentos (draft-litkowski-bess-vpnv4-ipv6-nh-handling-00).<br /> <br /> ==== VPWS ====<br /> Acrônimo: ''Virtual Private Wire Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços ponto-a-ponto, ou seja, onde envolve-se apenas dois sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. As diferenças principais entre o VPLS e o VPWS é que, no caso do VPWS, não há aprendizado de endereços MAC, e a solução comporta-se como um ''clear channel'' mesmo.<br /> [[Arquivo:Bpf-enciclopedia-vpws.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN ponto-a-ponto (VPWS)]]<br /> <br /> ==== VxLAN ====<br /> Acrônimo: ''Virtual Extensible LAN''.<br /> <br /> Historicamente a segmentação de uma rede L2 tradicional tem sido fornecida por VLANs padronizadas conforme o IEEE 802.1Q, onde VLANs são criadas e distribuídas nos switches da rede para fornecer a segmentação lógica desejada para as funções de camada 2 em seus domínios de broadcast. No entanto, devido ao uso ineficiente dos links de rede disponíveis com o uso de VLAN, aos requisitos rígidos de posicionamento de dispositivos em redes de missão crítica como datacenters, e à escalabilidade limitada a um máximo de 4094 VLANs, o uso de VLANs tornou-se um fator limitante para muitas redes e de diversas empresas, especialmente data centers e provedores de acesso à Internet. Os ISPs já possuem uma solução baseada no Flexible VLAN Tagging ou Ethernet Flow Point em combinação com soluções L2VPN clássicas, mas este tipo de solução não atende os requisitos de conectividade com alta densidade e elasticidade de multitenantes. Alguns fabricantes líderes de mercado, incluindo a Cisco, Cumulus Networks, Arista, Broadcom, VMware, Intel e Red Hat, uniram-se para propor ao IETF uma solução para sanear os desafios de rede L2 mencionados previamente, e daí surgiu o VXLAN. O VXLAN fornece o posicionamento elástico da carga de trabalho (workload) e maior escalabilidade da segmentação da Camada 2, exigidas pelas demandas de aplicativos atuais, provendo os mesmos serviços Ethernet / camada 2 que VLANs demandam nos dias atuais, só que com maior extensibilidade, flexibilidade e escalabilidade. Em termos mais técnicos, o VXLAN é um esquema de sobreposição (overlay) da camada 2 em uma rede da camada 3. A tecnologia usa o encapsulamento MAC-in-User Datagram Protocol (MAC-in-UDP) para fornecer um meio de estender os segmentos da Camada 2 através da rede do data center, compondo uma solução formidável para oferecer suporte a um ambiente multitenant flexível e em larga escala através de uma infraestrutura física comum compartilhada. O protocolo de transporte na rede física do datacenter inclui o IP e o UDP. Para este procedimento, o VXLAN define um esquema de encapsulamento MAC-in-UDP em que o quadro original da camada 2 possui um cabeçalho VXLAN adicionado e é então colocado em um pacote UDP-IP. Com esse encapsulamento MAC-in-UDP, o VXLAN encapsula a rede da Camada 2 pela rede da Camada 3, fazendo as extensões desejadas das VLANs através da rede, mas, no entanto, sem incorrer nas mesmas limitações de flexibilidade, escalabilidade e diâmetro das redes L2 tradicionais.<br /> <br /> === Desciclopédia ===<br /> <br /> ==== Ajuste Fino ====<br /> Ajuste Fino descreve medidas paliativas ou &quot;''worarounds''&quot; para a superação de deficiências e limitações apresentadas ou impostas por algumas plataformas de equipamentos quando falham ao cumprir com as diretivas e configurações definidas pelos administradores, e cujas as falhas geralmente são acompanhadas de sentimentos de bastante frustração. Para exemplificar um dos tantos casos aqui, há um bocado de relatos onde um equipamento, que supostamente deveria possuir um bom suporte ao protocolo de roteamento BGP, com tabelas de Internet completas (full routes), &quot;trava&quot; rotineiramente ao apresentar ciclos de processamento elevados, bastando que apenas um de seus muitos núcleos disponíveis para esta finalidade fique engargalado para que o referido problema seja notado, consequentemente exigindo a reinicialização (&quot;reboot&quot;) do equipamento para a restauração da normalidade. Para mitigar este problema, dois argumentos possíveis são praticados pelos consultores: a) &quot;''você que não sabe configurar''&quot;, ou seja, na prática, como a quantidade de casos é um tanto grande, entendemos, portanto, que ninguém sabe configurar. b) &quot;''isto é fácil, é só mexer aqui, aqui, aqui e ali, e fazer isso, que você não terá mais o problema''&quot;. O argumento &quot;b&quot; é o que chamamos de Ajuste Fino. Quais tipos de manobras são consideradas ajuste finos? Vejamos: agendamento de reinicialização ou boot automático em intervalos periódicos, podendo ser diário ou semanal + upgrade de memória + publicação das full routes em uma VRF + balanceamento do tráfego através de múltiplos dispositivos, visando diminuir a carga + deixar na tabela principal apenas a rota padrão. Na verdade, fica até complicado definir os ajustes finos, pois são segredos comerciais guardados a sete chaves! O termo acabou generalizando e atualmente todo o workaround empregado para fugirmos de alguma restrição tecnológica ou de algum bug de software é chamado de &quot;Ajuste Fino&quot;, e isto independente do fabricante, modelo e marca do equipamento. Ajuste Fino pode ser considerado um workaround ou gambiarra para qualquer situação onde você teve que fazer algumas manobras esquisitas e fora do que usualmente precisamos fazer para as coisas funcionarem conforme &quot;by the books&quot;.<br /> [[Arquivo:Bpf-desc-ajustefino.png|centro|miniaturadaimagem|494x494px|Ajuste Fino!]]<br /> <br /> ==== Balance Soma-Link ====<br /> Clássica gambiarra que predominou em muitos ISPs pequenos e por muitos anos. A estratégia consistia em contratar dezenas de links banda larga ADSL para desempenharem a função de Trânsito IP do provedor, e fazer uma configuração com roteadores Mikrotik ou de classe similar para executar o balanceamento do tráfego através destas conexões, e sob o pretexto de que este tipo de &quot;solução&quot; somava a capacidade dos links e ainda por cima promovia uma distribuição simétrica ou bem uniforme do tráfego. Alguns consultores, por falta de opções ou recursos, ou despreparados tecnicamente, ou, em alguns casos, malandros mesmo, militavam abertamente nas redes sociais sobre estas façanhas. Desnecessário comentar aqui que tal gambiarra é completamente equivocada nos pontos de vista legal e ético, além de tecnicamente bastante frágil. Felizmente caiu em desuso, mas ainda assim é possível encontrar estas maluquices por aí. Nem o próprio MacGyver, ícone do famoso seriado dos anos 80, especializado em promover gambiarras incríveis para todo e qualquer tipo de situação, teria sido tão &quot;genial&quot; quanto os malandros que inventaram o &quot;Balance Soma-Link&quot;! A diferença é que as gambiarras do MacGyver funcionam e são quase sempre éticas, já essa gambiarra aí...<br /> [[Arquivo:Bpf-desc-loadbalance.png|centro|miniaturadaimagem|600x600px|Gambiarra do Balance Soma-Link]]<br /> <br /> ==== Bridge Roteada ====<br /> <br /> ==== IP Confinado ====<br /> Conheça mais: [[CDN Peering e PNI - Brasil|https://wiki.brasilpeeringforum.org/w/CDN_Peering_e_PNI_-_Brasil]]<br /> <br /> O &quot;IP Confinado&quot; é um produto ofertado por alguns provedores com a proposta de fornecer conteúdo de &quot;CDNs apenas&quot; para clientes interessados neste tipo de serviço. O que justifica o &quot;IP Confinado&quot; estar sendo listado em nossa desciclopédia não é a parte técnica da &quot;solução&quot; em si, e sim as diversas violações contratuais associadas com a prática. Muitos destes ISPs promovem algumas práticas que não são permitidas conforme os contratos que são estabelecidos entre ISPs e as detentoras das CDNs. Por exemplo, não é permitido que o ISP mencione que &quot;vende tráfego de CDN&quot;, muito menos destacando ou citando os nomes das empresas/CDNs envolvidas na &quot;oferta&quot;; incorporar logotipos/logomarcas destas empresas em qualquer tipo de propaganda ou material publicitário, expor as fotos dos equipamentos/servidores de CDN implantados em seus data centers, etc. Ou seja, o &quot;IP Confinado&quot; está frequentemente associado a abusos por parte de ISPs, tais como violações de direitos autorais, direitos de propriedade intelectual, direitos de imagem e afins. <br /> <br /> Entenda: é permitido que o ISP venda &quot;implicitamente&quot; o conteúdo de CDNs como parte de uma oferta de &quot;Trânsito IP Parcial&quot; e similares, mas desde que mantendo sob sigilo as informações que possam identificar as empresas que fornecem as CDNs para o ISP. A venda de conteúdo de CDN em si é tida como uma prática ilegal.<br /> [[Arquivo:Ipconfinado.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Confinado]]<br /> <br /> ==== IP Ilegal ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Puro ====<br /> O &quot;IP Puro&quot; nada mais é que uma proposta de fornecimento de um serviço de trânsito para um cliente-ISP final e que exclua deste link todo o tráfego de CDNs que por ventura estiver presente na infraestrutura do ISP contratado, muitas das vezes até mesmo excluindo tráfego originado de sessões de peering privado (PNI). Ou seja, tráfego exclusivamente obtido por upstreams de trânsito IP. Muitos ISPs contam com infraestruturas de CDNs em seus ambientes, juntamente com as sessões de trânsito IP com seus upstreams e também os pontos de troca de tráfego, sejam estes privativos, compartilhados ou bilaterais. Quando um ISP contrata um serviço de trânsito IP junto a outro ISP, neste link escoará todo o tipo de tráfego que existir na infraestrutura do ISP contratado, ou seja, tráfego proveniente dos peerings (ex: IX.br, PNI com Google, Facebook, etc.), trânsito (os upstreams daquele ISP contratado), e, claro, o tráfego das CDNs que existirem no ISP contratado. <br /> <br /> O que alguns ISPs-clientes fazem é exigir que o tráfego destas CDNs (e de peerings também, em muitos casos) não seja fornecido no link de trânsito IP contratado. As discussões acerca deste tipo de necessidade um tanto curiosa ou inusitada são tantas as vezes que um produto denominado &quot;IP Puro&quot; acaba sendo informalmente definido entre os participantes do meio. As vantagens e benefícios alegados por alguns são bastante questionáveis, pois entendemos que o ISP-cliente tem muito mais a perder do que a ganhar com esta preferência. O &quot;IP Puro&quot; é um exemplo clássico de nossa Desciclopédia!<br /> [[Arquivo:Ippuro.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Puro]]<br /> <br /> ==== IP Real ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Válido ====<br /> Endereços IP &quot;válidos&quot;, na mente de muitos profissionais da área, são aqueles endereços IP cuja conectividade com a Internet é plenamente funcional, justamente por não estarem contidos nas faixas especificadas pelo &lt;nowiki&gt;RFC 1918&lt;/nowiki&gt; (''Address Allocation for Private Internets'') ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt; (''IANA-Reserved IPv4 Prefix for Shared Address Space''). Ou seja, a verdade é que IP válido é qualquer endereço IP que não seja privativo.<br /> <br /> Na verdade, todo endereço IP é válido! O correto seria diferenciar o endereço IP em &quot;público&quot; e &quot;privado&quot;, e não em válido ou inválido (quando o endereço for privativo). <br /> <br /> ==== IX Confinado ====<br /> <br /> ==== Link Dedicado Full Duplex ====<br /> <br /> ==== Link Semi-Dedicado ====<br /> O &quot;Link Semi-Dedicado&quot; é algo que expressa muito bem a cultura do brasileiro! Para resumir ou antecipar aqui, isto é basicamente uma gambiarra comercial.<br /> <br /> Para explicar isto melhor, vejamos o serviço de um link dedicado. Serviços de links dedicados são e devem ser tipicamente fornecidos através de uma infraestrutura Metro Ethernet, a qual disponibiliza recursos mais exclusivos e dedicados para o assinante/cliente, tais como uma porta dedicada em um switch Metro para aquele cliente, o enlace da fibra óptica é dedicado na última milha para a conexão do equipamento CPE/CE do cliente, a banda contratada é absolutamente simétrica e pode ser ajustada para até a capacidade máxima suportada pela porta (ex: 200 Mbps sobre porta 1 Gbps, 500 Mbps sobre porta 1 Gbps, ou 1 Gbps direto na porta). Ou seja, um Link Dedicado reúne componentes e arranjos tecnológicos mais caros e especializados para maximizar a experiência do cliente quanto à contratação do serviço. Novamente, é uma tecnologia mais cara, mas o cliente que contrata este serviço sabe exatamente o que e por que está contratando.<br /> <br /> Por outro lado, temos as tecnologias de Internet banda larga, inicialmente lá atrás com tecnologias baseadas no DSL (empregando DSLAMs e/ou MSANs, por exemplo), e nos últimos anos, o FTTH com xPON (principalmente o GPON), que operam especialmente sobre uma rede de acesso completamente compartilhada e com banda assimétrica Up e Down para as taxas mais elevadas.<br /> <br /> O GPON todos nós sabemos que é uma rede óptica passiva de natureza compartilhada, e toda a infraestrutura GPON é indiscutivelmente mais barata que uma rede Metro Ethernet; a diferença é muito expressiva neste sentido. Enquanto isto, é de amplo conhecimento que serviços de Internet banda larga são bem mais baratos (e viáveis para muitas pequenas empresas) que serviços de Internet com link dedicado, certo?<br /> <br /> O que alguns ISPs fazem, inclusive isto começou com um grande operador de redes: o &quot;meio-termo&quot;. Basicamente estas empresas tem vendido links de Internet banda larga com taxas um pouco mais elevadas, mas compatíveis com a característica assimétrica do projeto da rede GPON para a região onde o cliente está localizado, e suprimem, na cara de pau, o termo &quot;banda larga&quot;, usando o termo &quot;dedicado ou semi-dedicado&quot; para promover ou fornecer o serviço. Nada contra o GPON, muito pelo contrário! É uma tecnologia que permitiu baratear bastante os custos de construção de redes e a difundir melhor a Internet banda larga para muitos segmentos de pequenos negócios. Quando confrontados por clientes na questão de simetria da banda, os consultores do ISP procuram &quot;driblar&quot;, evitando mencionar que a rede é compartilhada (e que tem essa questão de restrições envolvendo a simetria Up e Down), e, quando sofrem o ultimato, informam que o serviço é &quot;Semi Dedicado&quot; (ou seja, nunca fazem menção ao aspecto compartilhado ou ao próprio GPON).<br /> <br /> Uma gambiarra estritamente comercial! É que nem você falar que mora num bairro adjacente ao seu, ao invés de citar o nome real conforme o seu CEP, porque seu bairro tem uma má fama. Ou que nem você ter vergonha de assumir a sua namoradinha(o) em público!<br /> [[Arquivo:Bpf-enciclopedia-semidedicado.jpg|centro|miniaturadaimagem|500x500px|Desciclopédia: Link Semi-Dedicado]]<br /> <br /> ==== Lupebequi ====<br /> <br /> ==== Rota Presa ====<br /> <br /> ==== SkyGato ====<br /> <br /> ==== Terraplanistas da Telecom ====<br /> O que seriam &quot;terraplanistas da telecom&quot;? Analogia aos terraplanistas &quot;originais&quot;: indivíduos que se acham superiores a gerações inteiras de verdadeiros gênios inspiradores, dos quais incluo aqui Eratóstenes, Galileo Galilei, Isaac Newton, Albert Einstein, Johannes Kepler, Arthur Eddington, Edwin Powell Hubble, Milton L. Humason, Tycho Brahe, Michael Faraday, Stephen Hawking, Steven Weinberg, James Clerk Maxwell, Peter Higgs, Edward Witten, Freeman Dyson, Werner Heisenberg, Erwin Schrodinger, Alan Guthm, Ernest Rutherford, Paul Dirac, Niels Bohr.... fora Anaximandro, Arquimedes, e tantos outros, dentre gênios e perseguidos. Todo um esforço gigantesco e desde os tempos mais remotos para que evoluíssemos humana e tecnologicamente e nas áreas de física e astrofísica, construíssemos coisas incríveis, compreendêssemos o universo próximo, mesmo que faltando ainda tantas perguntas sem respostas, para termos uma classe de indivíduos em franca expansão (&quot;terraplanistas&quot;) usando a tecnologia, todo o aparato tecnológico à seu favor para, nas redes sociais, bradarem aos 4 ventos: &quot;A TERRA É PLANA!&quot;. Surreal!<br /> <br /> Na mesma moeda, analogias aqui, os &quot;''terraplanistas da telecom''&quot; são aqueles indivíduos que atuam na área e que tentam refutar o irrefutável. Literalmente '''''&lt;u&gt;rasgam&lt;/u&gt;''''' RFCs, BCOPs, padrões/standards, e frameworks. Não somente isto: acidentalmente ou propositalmente quase que rasgam também os trabalhos dos &quot;gênios da nossa área&quot;; Radia Joy Perlman, John Moy, Yakov Rekhter, Kirk Lougheed, Vint Cerf, Robert Kahn, Robert Metcalfe, David Boggs, W. David Sincoskie, Ali Sajassi, dentre tantos caras que criaram tudo o que usamos nas redes hoje, fora os grupos de trabalho incluindo IETF, IEEE, IANA, RIPE, NIC.br, LACNOG, NANOG, GPF, e, porque não, as recomendações do BPF, e o escambáu. As BCOPs e RFC são literalmente '''&lt;u&gt;nada&lt;/u&gt;''' para alguns destes indivíduos (sim, eu atestei isto! Eu li e conferi isso numa discussão!). O que um Job Snijders falaria no ouvido desses caras, entraria por um lado e sairia pelo outro!<br /> <br /> Parece exagero, mas tem surgido uma classe de indivíduos que tenta refutar uma diversidade de fatos irrefutáveis sobre as características, disponibilidades e aplicabilidades de tecnologias associadas à redes, telecomunicações no geral; a Internet. Dentre os absurdos que vemos por aí, temos: &quot;''é mentira que o IPv4 está se esgotando!''&quot;, &quot;''o OSPF está morrendo!''&quot;, &quot;''operadoras estão deixando de usar o MPLS''&quot;, &quot;''a navegação por IPv6 prejudica a performance da minha Internet&quot;'', &quot;''não preciso implantar o IPv6, porque o IPv6 ainda não é usado&quot;'', ''&quot;blackhole é mitigação de DDoS''&quot;, &quot;''trânsito sem PTT é melhor''&quot;, &quot;''existe trânsito IP puro''&quot;, &quot;''sessão de peering com IX Europeu melhora a performance porque a lista de AS_PATH é menor''&quot;, dentre outras coisas engraçadas. Note que não são apenas &quot;opiniões&quot;: essas situações fazem parte de recomendações de fato que os &quot;terraplanistas da telecom&quot; promovem!<br /> <br /> O meu termo aqui de &quot;terraplanistas da telecom&quot; não faz julgamento de quanto o indivíduo sabe ou não sabe sobre estas tecnologias. Realmente não compete a mim julgar o nível de conhecimento de qualquer um que seja, e isto está absolutamente fora de questão. O que me cabe a fazer, obviamente, é questionar porque eles falam mal de certas coisas que eles mesmos não compreendem ou dominam? Não seria mais prudente pesquisar, informar-se, praticar, exercitar, questionar, etc., a ponto do indivíduo ser fluente o suficiente nesse ou naquele tema (protocolo, tecnologias), antes de tentar influenciar as outras pessoas?<br /> <br /> Uma coisa é você falar que não sabe ou não domina uma tecnologia, por isso que você não a quer ou prefere evitá-la. Uma coisa é você falar que determinada tecnologia não é compatível com os seus planos e pelas razões X, Y e Z. Em ambos os exemplos, argumentos e justificativas válidos. Agora, falar que &quot;''é mentira que o IPv4 está se esgotando''&quot; e coisas deste tipo é um verdadeiro desserviço para a comunidade!<br /> [[Arquivo:Bpf-enciclopedia-terraplanistas.png|centro|miniaturadaimagem|600x600px|Desciclopédia: terraplanistas da telecom]]<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Geral]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Ippuro.png&diff=2517 2020-06-15T19:36:45Z

<p>Leonardo.furtado: </p> <hr /> <div>Desciclopédia: IP Puro</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Enciclopedia_e_desciclopedia_da_telecom&diff=2516 2020-06-15T19:01:33Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Enciclopédia e &quot;Desciclopédia&quot; da Telecom ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Este artigo sofrerá adições de termos, acrônimos e expressões, um tanto frequentemente! Será a nossa Enciclopédia para descrever e, sempre que possível, exemplificar cada um dos termos usados pelas empresas e profissionais das áreas de telecomunicações e redes! Da mesma forma, este artigo fornecerá, e buscará deixar destacado, juntamente a cada termo, onde aplicável, uma &quot;Desciclopédia&quot; (nada melhor que uma dose de humor, certo?) para comentar situações que são verdadeiras gambiarras encontradas no setor de telecomunicações. <br /> <br /> A Enciclopédia reúne as expressões legítimas e corretas. Já a Desciclopédia, reúne situações um tanto controversas que surgiram na cabeça altamente criativa dos profissionais da área; as gambiarras! <br /> <br /> OBS: a prioridade de edição do artigo será o fornecimento das explicações referentes aos termos e, em segundo momento, a inclusão de algum tipo de exemplo ou referência. Se algum termo não contiver um exemplo ou uma referência, simplesmente aguarde, pois isto será realizado posteriormente. <br /> <br /> Desde já, solicito para que você siga acompanhando os trabalhos do '''''Brasil Peering Forum (BPF)''''', faça o bom e sensato uso de boas práticas, e diga não as gambiarras!<br /> [[Arquivo:Bpf-enciclopedia-cover.png|centro|miniaturadaimagem|700x700px]]<br /> <br /> ==== Como consultar este artigo ou buscar os termos e expressões desejadas ====<br /> Para este procedimento, sugiro:<br /> * Todos os acrônimos, termos ou expressões estão listados em ordem alfabética. Você poderá navegar pelo índice remissivo, clicar no acrônimo ou termo desejado, e ser direcionado diretamente para ele. Ou;<br /> * Faça uma pesquisa diretamente através de seu navegador (ex: CTRL-F)!<br /> Aprecie sem moderação!<br /> <br /> === Enciclopédia ===<br /> <br /> ==== 6PE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS (6PE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6PE é um cenário de transição para a adoção do roteamento IPv6 onde, no Core do operador da rede (ISP), não há endereçamento IPv6 (ainda), e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. Para maior eficiência, flexibilidade, e redução de custos, o 6PE pode ser projetado em um ambiente de backone (Core) isento de BGP, num cenário denominado &quot;''6PE com BGP-Free Core''&quot; mas, no entanto, são coisas distintas, e uma coisa não depende da outra, embora a combinação de ambas as estratégias tende a agregar muitos benefícios.<br /> [[Arquivo:Bpf-enciclopedia-6pe.png|centro|miniaturadaimagem|600x600px|Enciclopedia: 6PE]]<br /> <br /> ==== 6VPE ====<br /> Acrônimo: ''IPv6 Provider Edge over MPLS VPN (6VPE)''.<br /> <br /> Conheça mais aqui: ''[[Introducao ao IPv6 Provider Edge over MPLS e 6VPE]]''<br /> <br /> O 6VPE é um cenário de transição para a adoção do roteamento IPv6 na relação entre o ISP e clientes corporativos de serviços L3VPN MPLS, onde, no Core do operador da rede (ISP), não há endereçamento IPv6, e toda a comunicação através dos roteadores de backbone se dá com endereçamento IPv4. A diferença primária entre o 6PE e o 6VPE é que o 6PE lida com o roteamento IPv6 unicast sobre uma infraestrutura de backbone IPv4 em uma rede MPLS, enquanto o 6VPE lida com a troca de prefixos IPv6 unicast sobre uma infraestrutura L3VPN MPLS com sessões IBGP em IPv4 e com o suporte VPNv6 entre os roteadores PE. O BGP-Free Core não é um requisito para 6VPE ou 6PE, mas poderá agregar maior flexibilidade e promover redução de custos para o operador de redes.<br /> [[Arquivo:Bpf-enciclopedia-6vpe.png|centro|miniaturadaimagem|600x600px|Enciclopédia: 6VPE]]<br /> <br /> ==== AAA ====<br /> Acrônimo: ''Authentication, Authorization, Accounting''.<br /> <br /> O AAA pode ser tratado como um framework ou um conjunto de especificações tecnológicas e recursos para a concepção de mecanismos mais seguros visando a admissão de usuários e endpoints (dispositivos) em uma rede. O AAA, além de representar um conjunto de procedimentos, é usado geralmente em combinação com protocolos e serviços tais como RADIUS, TACACS+ e Diameter. Como o próprio nome sugere, a proposta é a de fornecer métodos seguros visando a autenticação de usuário e/ou dispositivo (ex: computador, roteador CPE, ou outro tipo de dispositivo), a posterior autorização, o que, por sua vez, ditará propriedades para o acesso concedido, tais como a atribuição dinâmica de VLAN, uma ACL dinâmica, um ''Scalable Group Tag'' (SGT), atribuição de endereçamento IPv4 e IPv6 (muito comum no caso do PPPoE), dentre uma diversidade de outras variáveis que podem ser associadas ao usuário e/ou ao seu dispositivo. E, por último, a manutenção de registros de atividades para fins de auditoria daquele acesso, ou seja, o ''Accounting''.<br /> <br /> &lt;u&gt;Exemplos de cenários onde o AAA é empregado:&lt;/u&gt; controle de acesso centralizado aos equipamentos da rede por parte de operadores/administradores, e com autorização e registros de comandos na CLI, autenticação de portas de switches com o protocolo 802.1X (conhecido também como solução IBNS), controle de acesso e admissão à rede (uma evolução do IBNS conhecida por ''Network Access Control'' (NAC)), autenticação de assinantes PPPoE e IPoE em concentradores de serviços de Internet banda larga (BNG/BRAS), autenticação de usuários e dispositivos móveis em redes WLAN, dentre outros casos.<br /> <br /> ==== Access-List ====<br /> Uma Lista de Acesso (Access-List ou ACL) é uma ferramenta absolutamente versátil disponível em roteadores e switches, e também em outros tipos de equipamentos de redes, e que tem como principal proposta a de atuar como mecanismo de classificação de pacotes ou, alternativamente, em muitos casos, para classificação de rotas. Após a classificação de pacotes ou de rotas, dependendo de como e para que uma ACL estiver sendo utilizada, uma ação pode ser vinculada para o pacote ou para a rota, e conforme diretivas imputadas pelo administrador da rede.<br /> <br /> &lt;u&gt;Exemplos de cenários onde uma ACL é empregada:&lt;/u&gt; filtro ''stateless'' de pacotes (''stateless packet filtering''), filtro ''stateful'' de pacotes (''stateful packet filtering'', quando a ACL é vinculada em um roteador com suporte a firewall stateful), classificação de tráfego que deverá ou não sofrer tradução de endereços IP (em ambiente NAT e CGNAT), classificação de pacotes que deverão sofrer uma política de roteamento diferenciada para encaminhamento de tráfego &quot;bypassando&quot; a tabela de roteamento (uma PBR, ABF, e similares), classificação de pacotes para o posicionamento destes em classes de tráfego e posterior tratamento de qualidade de serviço (QoS), classificação de pacotes autorizados para serviços de gerenciamento do equipamento (acesso remoto à CLI por SSH, acesso remoto ao equipamento via SNMP, NETCONF, etc.), classificação dos pacotes de servidores NTP autorizados a sincronizar data/hora com o seu equipamento, classificação de rotas que deverão ser invocadas por um filtro de rotas ou por uma política de roteamento (para ''accept'' ou ''drop'', com ou sem modificação de atributos), e muitos outros.<br /> <br /> Uma ACL pode ser considerada um verdadeiro &quot;canivete suíço&quot;! No entanto, para algumas necessidades, há ferramentas melhores ou mais versáteis que uma ACL. Por exemplo, uma ''prefix-list'' ou ''prefix-set'' é mais flexível e adequada para filtrar rotas em uma policy de roteamento, do que usar uma ACL para este mesmo propósito.<br /> <br /> ==== AS ====<br /> Acrônimo: ''Autonomous System''.<br /> <br /> Conheça mais: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]].<br /> <br /> Um (o) sistema autônomo representa a coletânea de dispositivos de rede sob uma administração comum, e o termo é geralmente empregado para representar uma rede inteira de uma determinada empresa, seja ela um provedor de acesso à Internet (ISP), uma empresa do segmento corporativo, ou uma instituição qualquer. Em um primeiro momento, o AS tipifica exatamente isto: a &quot;rede&quot; daquela empresa, os seus equipamentos, as suas diretivas e políticas; ou seja, uma coisa mais abstrata. No entanto, algumas tecnologias levam o termo AS para as suas próprias funcionalidades, capacidades e propriedades, dando uma expedição bem mais tangível ao termo, e em sua forma mais prática e real. Uma desta tecnologias é o protocolo de roteamento BGP, como todo profissional de ISP sabe.<br /> <br /> No caso do BGP, o Sistema Autônomo (AS) não é apenas algo teórico, e sim o componente principal e real do próprio protocolo de roteamento. Você, de fato, define/configura o AS no BGP dos seus roteadores, juntamente com uma série de propriedades e parâmetros (tais como sessões, anúncios, filtros, políticas de roteamento, recursos adicionais/periféricos do BGP, etc.) para representar aquela rede e as suas respectivas políticas de roteamento, ou seja, havendo uma relação muito íntima e tangível com esta definição de AS. A Internet é composta por dezenas de milhares de sistemas autônomos, obviamente interconectados pelo protocolo de roteamento BGP.<br /> [[Arquivo:Bpf-enciclopedia-as.png|centro|miniaturadaimagem|600x600px|Enciclopédia: Autonomous System (AS)]]<br /> <br /> ==== BGP ====<br /> Acrônimo: ''Border Gateway Protocol.''<br /> <br /> Conheça mais aqui: [[O Minimo que Voce precisa saber sobre o BGP|O mínimo que você precisa saber sobre o BGP]] e [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O BGP ou BGP-4 é um protocolo de roteamento do tipo vetor de caminhos e exterior (''path vector'' e EGP), e pode ser considerado como a base de todo o roteamento de Internet. Todo o funcionamento da Internet depende da boa operação do BGP e, sem ele, simplesmente não há a Internet. Obviamente que a Internet depende de muito mais coisas que o protocolo de roteamento BGP para funcionar, mas, sem dúvidas, ele é um componente tido como central.<br /> <br /> O protocolo de roteamento BGP tem sofrido muitos aditivos ao longo dos anos, com a adição de novas funcionalidades e recursos, dentre os quais convém destacar aqui o suporte às diversas famílias de endereços, tais como IPv4 Unicast, IPv6 Unicast, IPv4 Multicast, IPv6 Multicast, VPNv4, VPNv6, L2VPN, EVPN, Labeled Unicast, Traffic Engineering, e outros. Confira alguns destes recursos aqui:<br /> * [https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Border Gateway Protocol (BGP) Parameters], [https://www.iana.org/assignments/capability-codes/capability-codes.xhtml Capability Codes], [rfc:7606 Multiprotocol Extensions for BGP-4], [https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml Subsequent Address Family Identifiers (SAFI) Parameters], e há muitos outros.<br /> <br /> ==== BNG ====<br /> Acrônimo: ''Broadband Network Gateway''.<br /> <br /> Conheça mais: [[Concentradores PPPoE com IPv6]].<br /> <br /> O BNG substitui outro nome/termo, mais defasado, chamado BRAS, ou seja, apesar de serem termos intercambiáveis, recomenda-se, nos dias atuais, referenciá-lo como BNG. O BNG é essencialmente uma plataforma de roteamento equipada com funcionalidades, recursos, protocolos e serviços primários e periféricos orientados para a solução de conectividade de Internet banda larga, atendendo primariamente os assinantes residenciais, embora nada impeça que seja utilizado também para produto de Internet banda larga voltada ao segmento corporativo. O roteador BNG atua como dispositivo roteador (gateway) para as sessões autenticadas de usuários mantidas por ele (daí o termo &quot;concentrador BNG&quot;). O BNG é geralmente usado em combinação com outros componentes e procedimentos, sendo alguns destes mandatórios, enquanto outros são opcionais, variando conforme as definições de cada projeto técnico. Exemplos de tecnologias e procedimentos que &quot;casam&quot; com uma solução BNG: RADIUS, Diameter, PPPoE, IPoE, sejam estes arranjados sobre uma rede puramente Metro Ethernet + IP, ou FTTH/GPON + Metro + IP.<br /> <br /> ==== BRAS ====<br /> Acrônimo: ''Broadband Remote Access Server''.<br /> <br /> Vide o acrônimo BNG (Broadband Network Gateway).<br /> <br /> ==== Caches Enter-Deep ou Bring-Home ====<br /> O Enter-Deep Cache possui como estratégia estar profundamente fincado nas redes de acesso dos provedores de acesso à Internet (ISP), geralmente sendo adotados na forma de clusters implantados nas redes do ISP ao redor do mundo. Esta filosofia de cache foi introduzida pela Akamai e é usada por muitas empresas que seguiram na mesma filosofia. In a &quot;nutshell&quot;, e explicando isto de forma bem simplista e minimalista, como a coisa funciona, usando um exemplo simples envolvendo o Google: todos estes inúmeros ou quase incontáveis clusters localizados nas redes dos ISPs e nos data centers desta empresa no mundo compõem uma rede privada do Google. Sendo assim, quando um usuário faz uma requisição ou consulta de pesquisa, esta consulta tende a ser encaminhada primeiramente pelo provedor de acesso (ISP) local para um cache local próximo, de onde deverão sair conteúdos estáticos para o cliente enquanto este cache local, ao mesmo tempo, encaminha uma consulta pela rede privada do Google para um de seus data centers, de onde deverão sair os dados e resultados de pesquisa personalizadas para o cliente. Em um exemplo envolvendo um vídeo do YouTube, este vídeo poderá ser recuperado diretamente do cache local do ISP, se este possuir a arquitetura e se este conteúdo puder ser fornecido das proximidades deste enter-deep cache, enquanto os anúncios associados ao vídeo são recuperados a partir dos data centers do Google. Em geral, os serviços de nuvem do Google são fornecidos por uma infraestrutura de rede privada independente da Internet pública, daí as excepcionais vantagens dos ISPs em poderem contar, quando autorizados e sobre forte regime de contrato e NDA, com estas soluções baseadas enter-deep cache. Ganha o usuário, com acesso com latência mais baixa aos conteúdos, e ganha o ISP, com previsibilidade no tráfego e redução de custos com os enlaces de trânsito IP.<br /> <br /> Já a estratégia Bring Home (&quot;trazer para casa&quot;), é uma segunda filosofia de design adotada por muitas empresas de CDN. A proposta aqui é trazer os ISPs para &quot;casa&quot;, conectando clusters em pontos de presença (PoPs) construídos através de uma rede privada de alta velocidade, ao invés de implantar estes clusters diretamente nas infraestruturas de redes dos ISPs. Estes pontos de presença (PoPs) geralmente ficam mais próximos aos operadores de redes Tier-1, podendo estender-se para além destes em alguns casos. Comparado com o enter-deep cache em termos de filosofia de design, o Bring Home normalmente resulta em menores custos de manutenção, mas é menos interessante no ponto de vista de latência e taxas de transferências de dados para os usuários finais, quando comparando estes benefícios com a filosofia do Enter-Deep cache.<br /> <br /> ==== CDN ====<br /> Acrônimo: ''Content Delivery Network''.<br /> <br /> Conheça mais: [[CDN Peering e PNI - Brasil]].<br /> <br /> Ou Rede de Fornecimento de Conteúdo. Uma CDN é um sistema de servidores amplamente distribuídos que fornece acesso à páginas e à diversos tipos de conteúdos para os usuários da Internet, e com base em uma diversidade de métricas e procedimentos, tais como a geolocalização do assinante/usuário, local de origem dos conteúdos, e centros de distribuição de dados (que hospedam uma CDN) em melhores condições de fornecerem o conteúdo para o usuário requisitante, para citar algumas destas métricas e procedimentos.<br /> <br /> Como principais benefícios, as CDN asseguram menores índices de latência no fornecimento de conteúdo para os usuários requisitantes, um benefício percebido pelos próprios usuários finais, pois estes terão uma melhor experiência de consumo destes conteúdos, e permite excelentes capacidades de engenharia de rede e de tráfego para os serviços de trânsito; melhor cenário financeiro na questão de despesas operacionais de médio e longo prazos, o que seria um ótimo benefício para os ISPs que contarem com as CDNs de diversos fornecedores de conteúdos. Ou seja, ganha o usuário, com maior fluidez e experiência de consumo de conteúdos, e ganha o ISP, com seus clientes mais satisfeitos com a experiência de navegação, além dos resultados com as despesas operacionais de médio e longo prazos.<br /> <br /> ==== CFP ====<br /> Acrônimo: ''C form-factor pluggable (CFP)''.<br /> <br /> O CFP é resultante de um acordo do tipo ''multi-source agreement'' estabelecido entre os principais fabricantes de soluções da indústria para a produção de um transceptor ótico para transmissão de sinais de alta velocidade. O CFP foi desenvolvido primariamente para redes Ethernet em 100 Gbps, operando nas em 10 vias a 10 Gbps em cada sentido (Tx e Rx), ou 4 vias a 25 Gbps, também em cada sentido. As variações existentes:<br /> <br /> &lt;u&gt;CFP&lt;/u&gt; (82 mm × 13.6 mm × 144.8 mm, conexão elétrica de 148 pinos, consumo inferior a 24 W, 10×10G ou 4×25G vias). &lt;u&gt;CFP2&lt;/u&gt; (41.5 mm × 12.4 mm × 107.5 mm, conexão elétrica de 104 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 12 W, 10×10G, 4×25G, 8×25G, ou 8×50G vias, Analog Coherent Optics (ACO)). &lt;u&gt;CFP4&lt;/u&gt; (21.5 mm × 9.5 mm × 92 mm, conexão elétrica de 56 pinos, não embarca Digital Signal Processor (DSP), dependendo da placa ou módulo hospedeiro para isto, consumo inferior a 6 W, 4×10G ou 4×25G vias). &lt;u&gt;CFP8&lt;/u&gt; (40 mm × 9.5 mm × 102 mm, conexão elétrica de 124 pinos, sem DSP, consumo máximo de 24 W, 16×25G vias (25.78125 ou 26.5625 GBd) ou 8×50G vias). &lt;u&gt;MSA 5″×7″ (Gen 1)&lt;/u&gt; (conexão elétrica de 168 pinos, embarca DSP, consumo inferir a 80 W). &lt;u&gt;MSA 4″×5″ (Gen 2)&lt;/u&gt; (conexão elétrica de 168 pinos, DSP, consumo elétrico inferior a 40 W).<br /> <br /> ==== CGNAT ====<br /> Acrônimo: ''Carrier-Grade Network Address Translation (CGNAT ou CGN).''<br /> <br /> O CGNAT é ao mesmo tempo uma solução e um mal necessário, sempre requerido quando não há endereços IPv4 públicos suficientes para atender toda a base de clientes de um ISP. Em termos mais técnicos, o CGNAT é essencialmente uma tecnologia que realiza a tradução dos endereços IPv4 de origem dos assinantes/clientes/usuários, onde estes são geralmente endereçados com endereços IP da faixa 100.64.0.0/10 ([rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]), e não com os endereços IPv4 privativos previstos pelo RFC 1918, como alguns acreditam, para um endereço IPv4 público. O CGNAT difere da solução NAT tradicional por sofrer algumas modificações para viabilizar a tradução de endereços em larga escala e atendendo, dependendo da plataforma, a dezenas de milhares de usuários, daí o termo &quot;''carrier grade''&quot;. A principal diferença entre CGNAT e NAT é que o CGNAT é configurado para fazer a tradução do endereço IP de origem e respectivas portas usadas na conversação, mas &lt;u&gt;sem&lt;/u&gt; manter quaisquer informações referentes aos endereços IP e portas de destino, sendo isto, inclusive, um dos principais motivos pelos quais o CGNAT escala para milhões de traduções simultâneas de endereços. Há diversas abordagens de CGNAT, tanto ''stateful'' quanto ''stateless'', tais como NAT44, NAT444 / Double NAT 44, em regime determinístico ou pré-definido, ou ainda em alocação de portas em massa (Bulk Port Allocation (BPA)), ou ainda em combinação com técnicas de transição para IPv6 de assinantes com NAT 64SL, NAT64SF, IPv6 Rapid Deployment (6rd), Dual-Stack Lite (DS-Lite), e MAP-T/E<br /> <br /> Como boa prática, o CGNAT não deve substituir a necessidade pela adoção do protocolo IPv6 nas redes dos ISPs. Aliás, inclusive, estimulamos que o IPv6 seja adotado o mais rapidamente possível para a sua infraestrutura ficar cada vez menos refém do CGNAT, pois há limitações e aborrecimentos associados a esta tecnologia. Quanto mais IPv6 você possuir em sua rede, menor será a dependência por CGNAT!<br /> <br /> ==== Control Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Controle. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, que é responsável por hospedar diversos dos protocolos e serviços para funções de redes nas Camadas 2 e 3, assim como as respectivas estruturas de dados mantidas pelos processos de cada um destes protocolos e serviços.<br /> <br /> Exemplos de protocolos que atuam nesta área do equipamento: Spanning Tree Protocol (STP), Resilient Ethernet Protocol (REP), Ethernet Automatic Protection Switching (EAPS), G.8032 Ethernet Ring Protection Switching, Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP), Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP), Resource Reservation Protocol for Traffic Engineering (RSVP-TE), Address Resolution Protocol (ARP), e muitos outros, lembrando que estes protocolos mantém as suas estruturas de dados, tais como LSDB (OSPF), LIB (LDP), BGP Table (BGP), ARP Cache (ARP), etc. A tabela de roteamento, também conhecida por RIB, é mantida no plano de controle dos roteadores.<br /> <br /> ==== CPAK ====<br /> <br /> ==== Data Plane ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Ou Plano de Dados. É a área sistêmica de dispositivos ativos de rede, incluindo roteadores e switches, e que mantém as estruturas de dados relacionadas às ações de processamento de quadros (no L2) e pacotes (no L3). Estruturas de dados tais como a Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), Adjacency Table, Content Addressable Table (CAM ou MAC Table), são exemplos de estruturas de dados mantidas no Data Plane. As arquiteturas modernas de roteadores e switches tendem a combinar múltiplas estruturas de dados primárias e periféricas, geralmente mantidas em componentes de hardware especializados do equipamento, para construir e programar o ''pipeline'' de processamento de pacotes, para que, além da óbvia comutação do quadro ou o roteamento do pacote, outras ações possam ser executadas sobre os pacotes, tais como a determinação se um determinado pacote deverá ser tratado como L2 ou L3, consulta ou lookup de endereços IP, consulta à listas de controle de acesso (ACL), policiamento de taxa, queueing e prioridades, manipulação de cabeçalhos L2 e L3 (marcação, tradução de endereços, operações com tags de VLAN, operações com labels MPLS), etc. Exemplos de estruturas assim são as Ternary Content Addressable Memory (TCAM) e arranjos Tree-Bitmap (TBM) e M-trie.<br /> <br /> ==== DDoS ====<br /> Acrônimo: ''Distributed Denial of Service''.<br /> <br /> Conheça mais: [[O Minimo que voce precisa saber sobre DDoS|O Mínimo que você precisa saber sobre DDoS]] e [https://youtu.be/l2tVyz1Ba1A &lt;nowiki&gt;[BPF] Entrevista com o Thiago Ayub sobre ataques e mitigação DDoS&lt;/nowiki&gt;].<br /> <br /> Atividade criminosa que tem por objetivo promover a interrupção das operações de uma infraestrutura de redes através da sua incapacidade de continuidade de prestação dos serviços. Ou seja, como o próprio nome sugere, é um ataque de negação de serviços, porém distribuída, no sentido que milhares de dispositivos na Internet são controlados de forma maliciosa para lançarem ataques contra uma rede. Redes que são vitimadas sofrem dois padrões de distúrbios primários, sendo o primeiro o esgotamento de recursos computacionais dos equipamentos da rede, e, o segundo, a saturação dos enlaces de trânsito IP. Em qualquer uma das circunstâncias, os efeitos são muito negativos e percebidos pelos clientes do ISP afetado pela atividade criminosa. Os motivadores dos ataques de DDoS tem sido cada vez mais preocupantes, e são cada vez mais frequentes as situações envolvendo competidores inescrupulosos de um ISP que está sendo vítima de um ataque, mas há também muitos casos de criminosos que atacam ISPs por &quot;profissão e esporte&quot;, exigindo quantias em - sempre por pagamentos em criptomoedas, tais como o Bitcoin - para encerrar os ataques.<br /> <br /> ==== De-Peering ====<br /> Como o próprio nome sugere, é uma ação de desfeita de peering entre dois participantes ou entre um participante principal e múltiplos (dezenas) de outros participantes. O de-peer significa o encerramento da relação e a respectiva desconexão do acordo de peering entre dois sistemas autônomos. Mesmo que, de certa forma, um tanto raros, as motivações de um &quot;de-peer&quot; ou &quot;de-peering&quot; frequentemente estão associadas a mudanças na política de peering da organização principal, ou quando uma das duas partes envolvidas naquela relação de peering viola algum termo do acordo, algo que costuma promover o que chamamos de &quot;network clean-up&quot;. Algumas situações que tipificam e até mesmo justificam um de-peering: uma das duas partes está recebendo tráfego malicioso (ex: DDoS) excessivamente, e o acordo de peering pode ser interrompido em função disto. Violação da política de roteamento, onde um dos participantes injeta informações errôneas através desta sessão de peering (ex: route leak, hijack de prefixos, e &quot;vacilos&quot; similares), e isto é agravado quando a parte é reincidente, o que poderia justificar o cancelamento do acordo de peering. Mudanças na política de roteamento e peering de um dos participantes, e o entendimento que o referido acordo entre ambas as partes não é mais necessário ou interessante, ou ainda que a outra parte não mais atende os pré-requisitos para a manutenção deste acordo. E, para finalizar, possíveis problemas envolvendo capacidades e custos. Não é a toa que as modalidades de interconexão pagas (paid peering) tem se popularizado, em particular para lidar com as questões de capacidade e custos que em alguns casos poderiam justificar um de-peer de um ou mais participantes.<br /> <br /> ==== EAQ ====<br /> Acrônimo: ''Entidade Aferidora de Qualidade''<br /> <br /> A Entidade Aferidora da Qualidade (EAQ) foi criada em atendimento às Resoluções da Anatel 574 e 575 de 28 de outubro de 2011. A EAQ é parte do processo de aferição dos indicadores de qualidade das redes de telecomunicações que suportam o acesso à internet em Banda Larga fixa e móvel no Brasil, e a seleção desta entidade é feita de forma a garantir o cumprimento do Regulamento de Gestão da Qualidade do Serviço de Comunicação Multimídia - RGQ-SCM, aprovado pela Resolução nº 574, de 28 de outubro de 2011 e do Regulamento de Gestão da Qualidade da Prestação do Serviço Móvel Pessoal - RGQ-SMP, aprovado pela Resolução nº 575, de 28 de outubro de 2011.<br /> <br /> ==== eNodeB ====<br /> O Nó B do E-UTRAN, também conhecido como Evolved Node B ou eNodeB ou eNB, é o elemento no E-UTRA do LTE que é a evolução do elemento Nó B no UTRA do UMTS. É o hardware conectado à rede de telefonia móvel que se comunica diretamente sem fio com os telefones móveis (UEs), como uma estação base de transceptores (BTS) nas redes GSM. Tradicionalmente, um Nó B tem funcionalidade mínima e é controlado por um Radio Network Controller (RNC). No entanto, com um eNB, não há elemento controlador separado. Isso simplifica a arquitetura e permite menores tempos de resposta.<br /> <br /> ==== Ethernet ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> O Ethernet é uma arquitetura de interconexão para redes de computadores, originalmente pensada para os ambientes de Redes de Áreas Locais (LAN), pois, naquele tempo, o Ethernet não era funcional para comunicações a longa distância, tais como circuitos de WAN e redes Metropolitanas (MAN). A tecnologia de transmissão do Ethernet é por regime estatístico e baseada no encaminhamento de quadros (''frames''). O Ethernet é especificado para velocidades de operação selecionadas entre 10 Mbps e 400 Gbps, usando uma especificação comum de controle de acesso ao meio físico (''Media Access Control'' ou MAC). O mecanismo de contenção para o compartilhamento do meio físico no Ethernet é feito por um procedimento denominado ''Carrier Sense Multiple Access with Detection Collision Detection'' (CSMA / CD), definindo tanto a operação de mídia compartilhada (half duplex), bem como a operação em full duplex. Ao longo dos anos o Ethernet sofreu vários aditivos para acomodar novas funcionalidades e capacidades, dentre as quais posso destacar aqui os padrões DCBX para o funcionamento do Ethernet em ambientes de Data Center críticos, por exemplo, permitindo transportar o ''Fibre Channel'' diretamente sobre o Ethernet (FCoE), e também os padrões Metro Ethernet / Carrier Ethernet que fizeram com que o Ethernet aos poucos fosse evoluindo e sendo adotado pelos operadores de rede / service providers / ISP, a ponto de hoje ser a tecnologia de enlace predominante neste setor. Os principais atrativos do Ethernet incluem a flexibilidade e excelente relação custo x benefício, especialmente quando comparado às tecnologias de transmissão determinísticas (ex: SDH), sendo este fator econômico o principal motivo quanto a expansão do Ethernet para os ISPs.<br /> <br /> ==== EVPN ====<br /> Acrônimo: ''Ethernet Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> Tecnologia de transporte de serviços de Camada 2 (L2) sobre infraestrutura MPLS ou VxLAN, ou seja, L2VPN, em especial buscando, através da evolução tecnológica e pela qualidade de suas ferramentas, cumprir com os mesmos objetivos da soluções L2VPN MPLS tradicionais, tais como o VPLS, H-VPLS e VPWS, sejam estes em implementação Martini ou Kompella, porém sem incorrer nas mesmas dificuldades e complexidades associadas a estes tecnologias clássicas. Em outras palavras, o EVPN é a legítima evolução da tecnologias L2VPN tradicionais, pois resolve muitos dos conhecidos desafios dos setups típicos de L2VPN. O EVPN tem como principal proposta a implementação de uma diversidade muito ampla de serviços L2 sobre infraestruturas baseadas no IP/MPLS e em regimes ponto-a-ponto e multiponto, sendo ideal para atendermos às demandas por L2VPN dos dias atuais e com maior flexibilidade e elasticidade. Como benefícios, o EVPN não exige um protocolo adicional como ocorre no L2VPN MPLS clássico (em especial a implementação Martini), e também não exige o emprego de Pseudowires. O EVPN usa o MP-BGP (mais precisamente o AFI 25 e SAFI 70) para trocar rotas específicas para esta família de endereços, promove maior eficiência no aprendizado e distribuição de endereços MAC, e com aprendizado destes ocorrendo no plano de controle, e não no plano de dados, permite redundância &quot;''All-Active''&quot;, além de outras interessantíssimas capacidades e recursos.<br /> <br /> ==== FlowSpec ====<br /> Acrônimo: ''BGP Flow Specification''.<br /> <br /> O recurso ou tecnologia BGP ''flow specification'' (flowspec) permite definir procedimentos para codificar regras de especificação de fluxo na forma de BGP ''Network Layer Reachability Information'' (NLRI) que podem ser usadas em diversas situações, sendo que a sua principal proposta é viabilizar o filtro de pacotes com o objetivo de mitigação de ataques de negação de serviços do tipo DDoS. Para se ter uma idéia, nos métodos tradicionais de mitigação de DDoS, como é o caso do RTBH (''Remotely Triggered Black Hole Filtering'' ou &quot;buraco negro disparado remotamente&quot;), uma rota BGP é injetada anunciando o endereço do site sob ataque juntamente com uma community BGP específica para este propósito de proteção. Essa community especial nos roteadores de borda serve para definir o próximo salto para um próximo salto especial - ou seja, uma modificação proposital do atributo &quot;NEXT_HOP&quot; da referida rota BGP - para descartar ou anular pacotes destinados àquele alvo, ou seja, permitindo que o tráfego de ataque destinado ao endereço IP/alvo seja descartado no backbone do ISP. Mesmo que isto permita oferecer boa proteção, a estratégia com o uso do RTBH torna o servidor ou host configurado com aquele endereço IP completamente inacessível. Por outro lado, o BGP flowpecpec permite uma abordagem mais granular e permite ainda que você efetivamente construa instruções para combinar um fluxo específico com a origem, destino, parâmetros L4 e especificações de pacotes, como comprimento, fragmento etc., possibilitando uma instalação dinâmica de uma ação nos roteadores de borda para: a) descartar o tráfego lançado contra o alvo. b) injetar o tráfego em uma VRF específica para uma análise mais detalhada. c) policiamento da taxa deste tráfego identificado pelo flowspec. Portanto, em vez de associar uma rota com uma community especial (RTBH) para que os roteadores de borda façam o descarte &quot;cru e nu&quot; do pacote, o BGP flowspec envia um formato de fluxo específico aos roteadores de borda, instruindo-os a criar uma espécie de ACL para que seja possível construir uma política com uma ação que você desejar (os casos &quot;a&quot;, &quot;b&quot; e &quot;c&quot; citados previamente). Para conseguir isso, o BGP flowspec adiciona um novo NLRI ao protocolo BGP, possibilitando fornecer detalhes sobre especificações de fluxos, critérios de correspondência (&quot;matching&quot;) suportados e ação de filtragem de tráfego.<br /> <br /> O BGP Flowspec é um aditivo muito sofisticado para as intenções dos ISPs na questão de mitigação de ataques DDoS em suas infraestruturas.<br /> <br /> ==== FTTH ====<br /> Acrônimo: ''Fiber-to-the-Home''.<br /> <br /> O &quot;''Fiber To The Home''&quot; (FTTH), também chamado de &quot;''Fiber To The Premises''&quot; (FTTP) ou ''&quot;Fiber To The Building''&quot; (FTTB), é o conceito de projeto, instalação o uso de fibra ópticas a partir de um ponto central diretamente para edifícios individuais, como residências, edifícios de apartamentos e empresas, para fornecer acesso à Internet em alta velocidade. O ''Fiber to the Home'' (FTTH) em si é um tipo de rede de acesso que oferece a alta velocidade de conexão à Internet, usando fibra óptica que é executada diretamente na casa, no prédio ou no escritório do assinante/cliente. O FTTH oferece aos consumidores acesso a uma grande variedade de aplicativos interativos, como comunicação por vídeo, jogos, vídeo sob demanda, teletrabalho e eSaúde, dentre uma diversidade muito grande aplicações que são possíveis com o uso de uma rede relativamente muito simples, porém bastante efetiva, e com ótima relação custo/benefício.<br /> <br /> ==== GGSN ====<br /> Acrônimo: ''Gateway GPRS Support Node''.<br /> <br /> O ''Gateway GPRS Support Node'' (GGSN) é um dos dois componentes do domínio ''Packet-Switched'' (PS) ''General Packet Radio Services'' (GPRS). O GGSN, juntamente com o SGSN (''Serving GPRS Support Node'', que entrega pacotes de dados de e para as estações móveis dentro de sua área de serviço), lida com transmissões de pacotes entre a rede GPRS e redes externas de baseadas em comutação de pacotes, como a Internet ou até mesmo de infraestruturas mais legadas baseadas em pacotes, como é o caso de uma rede X.25. Do ponto de vista de uma rede externa, o GGSN é um roteador para uma subrede, porque o GGSN acaba por &quot;ocultar&quot; a infraestrutura GPRS da rede externa. Quando o GGSN recebe dados endereçados a um usuário específico, verifica se o usuário está ativo. Caso afirmativo, o GGSN encaminha os dados para o SGSN que atende o usuário móvel, mas, caso o usuário móvel estiver inativo, os dados serão descartados. Na outra direção, os pacotes de origem móvel são roteados para a rede correta pelo GGSN, que é o ponto de ancoragem que permite a mobilidade do terminal do usuário nas redes GPRS / UMTS, onde, essencialmente, ele desempenha o papel no GPRS equivalente ao agente doméstico no IP móvel, e mantém o roteamento necessário para encapsular as unidades de dados de protocolo (PDUs) para o SGSN que atende uma determinada estação móvel (MS).<br /> <br /> ==== GPON ====<br /> Acrônimo: ''Gigabit Passive Optical Network''.<br /> <br /> ==== H-VPLS ====<br /> Acrônimo: ''Hierarchical Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN MPLS orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. A diferença primária entre H-VPLS e VPLS é que o H-VPLS procura promover uma hierarquia para o estabelecimento dos pseudowires e a efetiva troca de tráfego L2 entre os sites participantes, e com o objetivo de aprimoramos a escalabilidade e a eficiência da solução VPLS. Um dos maiores benefícios do H-VPLS é a redução do overhead de sinalização e também dos requerimentos de replicação de pacotes sobre os roteadores provider edge (PE). No H-VPLS, dois tipos de dispositivos PE são definidos: o u-PE e n-PE. O u-PE recebe o tráfego L2 nativo do cliente e faz as funções L2 locais, agrega o tráfego e o encaminha até o roteador n-PE, que é onde, de fato, ocorre o encaminhamento do tráfego pelo VPLS e com base no ''Virtual Switching Instance'' (VSI).<br /> <br /> ==== Hub-and-Spoke ====<br /> <br /> ==== IPFIX ====<br /> Acrônimo: ''Internet Protocol Flow Information Export''.<br /> <br /> O ''IP Flow Information Export'' (IPFIX), é um protocolo que especifica um método para que engenheiros de redes consigam exportar dados analíticos referentes aos fluxos de tráfego que percorrem em suas redes ou sistemas autônomos para estações coletoras, devidamente equipadas com soluções específicas baseadas em software, para fins de compreenderem com clareza as matrizes de comunicação referentes aos endereços IP de origem, endereços IP de destino, ordenamento de protocolos detectados ou registrados nestas conversações, portas de origem e destino (para o caso de TCP e UDP), marcações de QoS indicadas (ex: DSCP), sistemas autônomos envolvidos, volumetria destes fluxos que representam estas conversações, &quot;''top talkers''&quot;, dentre outros dados extremamente úteis. O IPFIX é um protocolo de padrão aberto que visa promover maior flexibilidade se comparado ao NetFlow da Cisco, seja na versão &quot;10&quot;, 9 ou 5, ao Juniper JFLOW, que é bastante similar ao NetFlow v5 da Cisco, e ao CFLOW. Comparativamente, o IPFIX contém os mesmos 79 campos do NetFlow v9, mas vai além e acomoda até 238 campos, o que possibilita uma lista bastante extensa de informações para atender a muitas das necessidades dos engenheiros de redes, e estando um passo à frente para inovações futuras. Assim como NetFlow/CFLOW/JFLOW, o IPFIX tem como proposta primária auxiliar profissionais de redes e empresas no planejamento de capacidades, bilhetagem e tarifação de tráfego, detecção e prevenção de incidentes de segurança, resposta automática a ataques de negação de serviço com acionamento de RTBH, dentre outras conhecidas aplicações. Vide &lt;nowiki&gt;RFC 7011&lt;/nowiki&gt; (''Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information'') para maiores informações.<br /> <br /> ==== IPoE ====<br /> Acrônimo: ''IP over Ethernet.''<br /> <br /> O ''Internet Protocol (IP) over Ethernet'' (IPoE) é uma das soluções adotadas para a disseminação do produto de Internet banda larga nas redes dos provedores de acesso à Internet. É basicamente uma forma de fornecer tráfego de Internet banda larga sem o encapsulamento PPP sobre o Ethernet. Atualmente, a tecnologia predominante para a autenticação e autorização de assinantes de Internet banda larga é o ''Point-to-Point Protocol over Ethernet'' (PPPoE), que, apesar de estar presente na grande maioria das instalações, possui alguns desafios e diversas limitações. O IPoE entra nesta seara justamente para substituir o PPPoE nos concentradores de assinantes (conhecidos por plataformas BNG ou BRAS), ou seja, para conquistarmos maior flexibilidade com a oferta de serviços para os assinantes sem incorrermos nos problemas e desafios associados ao uso massivo do PPPoE nestes equipamentos concentradores, dentre outras características, vantagens e benefícios. Dentre as principais vantagens em substituir o PPPoE pelo IPoE está na eliminação de um protocolo específico para o procedimento (PPP), consequentemente havendo uma redução bastante satisfatória do processamento dos equipamentos concentradores, pois, um dos principais &quot;problemas&quot; do PPPoE é que este introduz um cabeçalho adicional de 8 bytes de comprimento para cada pacote entre o dispositivo CPE/CE (assinante) e o concentrador onde a sessão do usuário foi autenticada e está estabelecida. E os concentradores de assinantes precisam manter o estado destas sessões para realizar diversos procedimentos para a manutenção do serviço do assinante. Outro &quot;problema&quot; do PPPoE está em sua dificuldade em lidar eficientemente com o tráfego Multicast, sendo que este problema não está presente o IPoE, o que pode ser um fator determinante para optar pelo IPoE para assinantes de Internet banda larga com o produto IPTV. O IPoE não é o &quot;the new kid on the block&quot;, e está por aí desde os primórdios do &lt;nowiki&gt;RFC 894&lt;/nowiki&gt;, sendo inclusive suportado há muitos anos pelos principais produtos concentradores do mercado.<br /> <br /> ==== IPv4 ====<br /> Acrônimo: ''Internet Protocol version 4''.<br /> <br /> ==== IPv6 ====<br /> Acrônimo: ''Internet Protocol version 6''.<br /> <br /> ==== IRR ====<br /> Acrônimo: ''Internet Routing Registry''.<br /> <br /> O ''Internet Routing Registry'' (IRR) é um banco de dados que possui objetos inseridos e mantidos através de uma linguagem própria denominada ''Routing Policy Specification Language'' (RPSL). Estas construções RPSL são expressas em diversos tipos de objetos dos bancos de dados que estão registrados em Registros Regionais da Internet (RIRs), os quais podem ser consultados pelo serviço Whois. Cada tipo de objeto de uma base de dados IRR pode representar um determinado tipo de informação, tal como um prefixo de propriedade ou alocado para um ISP, um objeto que divulgue a sua política de roteamento, ou um objeto que represente informações de contato administrativo e de suporte técnico, dentre outros tipos de objetos. O uso correto dos recursos de uma base IRR é amplamente estimulado entre os provedores de acesso à Internet para que cada um publique corretamente os seus prefixos (a título de objetos &quot;''route''&quot; e &quot;''route6''&quot;), os seus grupos representando, cada qual, seus upstreams de trânsito, peerings, e cones de clientes (por meios de objetos &quot;''as-set''&quot;), a divulgação da intenção em termos de política de roteamento (por meios de objetos &quot;''aut-num''&quot;, com campos &quot;''import''&quot;, &quot;''export''&quot;, &quot;''mp-import''&quot; e &quot;''mp-export''&quot;), além de objetos representando ações administrativas, tais como pessoal de contato para suporte (objetos &quot;''person''&quot; e &quot;''role''&quot;). A manutenção dos objetos em uma base IRR por um ISP é fundamental para que haja um consenso na Internet sobre como os filtros de anúncios devem ser construídos pelos Sistemas Autônomos, assim como fornecer a devida visibilidade para o acionamento dos times de suporte quando problemas ocorrerem com o roteamento de Internet envolvendo um determinado Sistema Autônomo. O ''Mutually Agreed Norms for Routing Security'' (MANRS) inclusive estabelece como dois dos seus principais objetivos a &quot;Coordenação&quot; e &quot;Validação Global&quot; entre os ISPs, cujas as ações são bastante centradas nos registros de objetos nas bases de dados de IRR, e com a divulgação do objeto &quot;''as-set''&quot; principal do ASN em seu cadastro no site PeeringDB. É importante salientar que muitos ISPs produzem filtros automaticamente com base nos registros de um sistema autônomo especificados numa base conhecida de IRR, daí a importância em certificar-se que o seu AS tenha os dados corretos inseridos na base de dados de um IRR, pois, a qualquer momento, algum ISP upstream poderá simplesmente recusar o recebimento de anúncios que tiverem sido originados no seu ASN, justamente por não haver consistência destas informações nos registros de uma base IRR.<br /> <br /> ==== IRU ====<br /> Acrônimo: ''Indefeasible Right of Use''.<br /> <br /> O direito de uso indefiável (IRU) é um tipo de contrato permanente de locação de telecomunicações, que não pode ser desfeito, entre os proprietários de um sistema de comunicações e um cliente desse sistema. A palavra &quot;indefiável&quot; significa &quot;incapaz de ser anulado ou desfeito&quot;. O IRU é o arrendamento efetivo de longo prazo (propriedade temporária) de uma parte da capacidade de um cabo submarino ou de outra infraestrutura de telecomunicações. Um exemplo deste tipo de arrendamento seria um IRU especificando um determinado número de canais de uma determinada largura de banda por um período bastante prolongado de uso. Neste caso, o IRU é concedido pela empresa ou consórcio de empresas que construíram o cabo, oferecendo a um provedor de serviços de Internet a capacidade de garantir à seus próprios clientes o trânsito internacional sobre este referido cabo, na capacidade assegurada pelo IRU, e por um período de prazo bastante prolongado.<br /> <br /> ==== IX ====<br /> Acrônimo: ''Internet Exchange''.<br /> <br /> Vide Ponto de Troca de Tráfego (PTT).<br /> <br /> ==== Jitter ====<br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]]<br /> <br /> O jitter é a variação de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das &quot;especificações biológicas&quot; (auditivas e/ou visuais) do ser humano, que é o indivíduo que está interagindo com a aplicação através da rede com transmissões com níveis de jitter acima dos padrões aceitáveis.<br /> <br /> ==== L2VPN ====<br /> Acrônimo: ''Layer 2 Virtual Private Network''.<br /> <br /> Conheça mais: [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]]<br /> <br /> O ''Layer 2 Virtual Private Network'' (L2VPN) consiste em um conceito que representa um conjunto de tecnologias orientadas ao transporte de serviços L2 sobre uma infraestrutura baseada no IP, com ou sem o auxílio do MPLS. Enquadram-se neste caso as tecnologias que obviamente exigem o MPLS para operar, como é o caso do ''Virtual Private LAN Service'' (VPLS), para a construção e transporte de redes L2 em regime multiponto, e o ''Virtual Private Wire Service'' (VPWS), para a construção e transporte de redes L2 em regime ponto-a-ponto, sendo que ambos operam sobre uma infraestrutura MPLS.<br /> <br /> Tecnologias de &quot;''tunneling''&quot; não deixam de ser também soluções de L2VPN, pelo menos no que diz respeito à privacidade e a segregação de serviços L2 de assinantes distintos sobre uma rede IP. Outro exemplo clássico de solução para este propósito é o ''Virtual Extensible LAN'' (VxLAN), muito utilizado em ambientes de data center como cenário centrado na elasticidade de domínios L2 e excelente mobilidade de workloads/VMs. E também, mais recentemente, a evolução das soluções L2VPN tradicionais para o ''Ethernet VPN'' (EVPN).<br /> <br /> No entanto, quando utilizando o termo &quot;L2VPN&quot;, estamos quase sempre nos referindo aos clássicos modelos VPLS e VPWS empregados nas redes MPLS dos operadores de rede, e estes serviços são provisionados com o auxílio de ''pseudowires'' com o protocolo LDP em vizinhança direcionada (T-LDP) entre os roteadores participantes de um determinado serviço, o que seria a proposta de implementação ''Martini'', ou então com o protocolo BGP, para a descoberta de vizinhos e também para o procedimento de sinalização, o que seria a proposta de implementação ''Kompella''.<br /> <br /> O principal objetivo da L2VPN é viabilizar o transporte de serviços L2, primariamente o Ethernet, através de uma rede completamente baseada no IP+MPLS, e sem que seja necessário estender as VLANs destes clientes atendidos através do backbone do operador de redes ou ISP. Ganha-se muito na questão operacional, além de aprimoramentos de indicadores importantes tais como a escalabilidade, confiabilidade, resiliência e melhor facilidade para o provisionamento e manutenção destes serviços. Os operadores de redes encontram no L2VPN uma forma bem adequada de fornecer serviços atraentes para seus clientes, tais como LAN-to-LAN, ''Data Center Interconnect'', &quot;''Clear Channel''&quot;, dentre outros, sem incorrer nas complexidades e riscos associados ao emprego das tecnologias L2 básicas em suas infraestruturas, tais como o entroncamento excessivo de VLANs de clientes nos uplinks do backbone, no provisionamento e manutenção de instâncias de protocolos de resiliência L2 (que são pouco escaláveis e um tanto inseguros em redes grandes), os riscos eminentes de ocorrerem ''bridging loops'' em função das extensões destas VLANs de clientes e respectivos protocolos de resiliência L2 no backbone do ISP, dentre outros argumentos muito sólidos.<br /> <br /> As L2VPNs podem ser utilizadas também para o transporte de tecnologias legadas sobre uma infraestrutura IP+MPLS, conforme tipificado pela solução ''Any Transport over MPLS'' (AToM) como um todo, permitindo, além do próprio Ethernet, o transporte de redes ''Asynchronous Transfer Mode'' (ATM), ''Frame Relay'', enlaces ponto a ponto ''High-Level Data Link Control'' (HDLC) e ''Point-to-Point Protocol'' (PPP), e até mesmo de outras tecnologias de transmissão digital, porém de natureza determinística (e não estatística, como seria o caso do Ethernet e do IP!), tais como ''Plesiochronous Digital Hierarchy'' (PDH) e ''Synchronous Digital Hierarchy'' (SDH)! Ou seja, soluções tais como o HDLCoMPLS, PPPoMPLS, FRoMPLS, CESoPSN, SAToP, TDMoIP, procedimentos GFP + LCAS + VCAT, etc. Para entender melhor estes casos, um tanto atípicos para os dias atuais, consulte o RFC 3985 (''Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture'') e outros RFCs. <br /> [[Arquivo:Bpf-enciclopedia-l2vpn.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN]]<br /> <br /> ==== L3VPN ====<br /> Acrônimo: ''Layer 3 Virtual Private Network''.<br /> <br /> ==== Latência ====<br /> Latência de rede é o termo usado para indicar qualquer tipo de atraso que ocorra na comunicação de dados em uma rede. As conexões de rede nas quais ocorrem pequenos atrasos são chamadas de redes de baixa latência, enquanto as conexões de rede que sofrem de longos atrasos são chamadas de redes de alta latência. A alta latência cria gargalos em qualquer comunicação de rede e impede que os dados tirem proveito máximo do canal de rede, diminuindo efetivamente a largura de banda de comunicação, além de apresentae aquela sensação de &quot;rede lenta&quot;. O impacto da latência na largura de banda da rede pode ser temporário ou persistente, com base na origem destes atrasos. Em termos práticos, a latência pode ser definida pelo tempo que leva para uma solicitação viajar do remetente para o destinatário e para o destinatário processar essa solicitação e fornecer a resposta para o remetente. Em outras palavras, o tempo de ida e volta do seu navegador para um servidor. Obviamente, é desejável que esse tempo permaneça o mais próximo possível de 0, no entanto, pode haver muitas coisas em jogo para impedir que os tempos de latência de um determinado serviço permaneçam baixos. Diversos elementos fatoram para o aumento da latência, dentre eles os atrasos de natureza fixa (serialização, transmissão e propagação) e os de natureza variável (processamento e enfileiramento/queueing), sendo que todos estes atrasos são adicionados por cada elemento de rede ativo que existir no caminho entre o cliente e o servidor. A latência pode e deve ser objeto de estudos e trabalhos de reestruturações tanto do aparato tecnológico em si (categoria dos elementos ativos, tais como roteadores, switches e concentradores) quanto das ações de engenharia de rede (organização topológica, emprego efetivo de recursos nos locais certos, etc.) e engenharia de tráfego (políticas consistentes de QoS, engenharia de tráfego MPLS, engenharia de tráfego do BGP, escolha e aquisição de enlaces com latências reportadas mais baixas, etc.). Em uma rede Ethernet, IP ou MPLS, a latência sempre existirá; é inevitável. O seu trabalho deverá saber projetar a rede, escolher bem seus componentes e dimensionar adequadamente seus recursos para que os índices de latência não sejam percebidos ou prejudiciais para a experiência de navegação e usabilidade de seus clientes.<br /> <br /> ==== MPLS ====<br /> Acrônimo: ''Multiprotocol Label Switching''.<br /> <br /> Conheça mais: [[Redes MPLS para Provedores]].<br /> <br /> Tecnologia de encaminhamento de pacotes cujas as operações não envolvem a consulta do cabeçalho IP. Numa rede completamente MPLS, o objetivo é fazer com que as consultas para a determinação de caminhos e o efetivo encaminhamento de pacotes ocorram por meios de instruções e operações mais simplificadas, denominadas &quot;''labels''&quot;, os quais são especificados em cabeçalhos enxutos chamados de &quot;''shim header''&quot;, e em três simples operações: imposição (push), troca (swap), e disposição (pop). O MPLS surgiu inicialmente como tecnologia visando atenuar o processamento dos roteadores de backbone dos grandes operadores de redes, pois as operações com ''labels'' tinham como apelo serem mais simplificadas e desprenderem menos esforços computacionais do que as operações com os cabeçalhos IP. Atualmente este argumento, ou motivador inicial quanto ao surgimento do MPLS, é praticamente nulo, em função da sofisticação das arquiteturas de roteadores dos dias atuais, pois os novos processadores conseguem sustentar ótimas taxas de encaminhamento de pacotes e independentemente se estes possuem ''labels'' ou não, e com múltiplos serviços concorrentes. No entanto, o MPLS como um todo evoluiu muito, e uma gama de funcionalidades excepcionais foram agregadas para rodar no topo das infraestruturas MPLS, obviamente exigindo o ''label switching'' para isto, assegurando qualidade, flexibilidade e elasticidade para quase tudo o que temos de bom nas infraestruturas de redes dos ISPs. Exemplos de soluções que rodam e/ou que dependem do MPLS para funcionar incluem L3VPN MPLS, L2VPN MPLS, MPLS TE, MPLS QoS, GMPLS. Algumas destas tecnologias que rodam no topo do MPLS surgiram para resolver problemas bastante conhecidos existentes em ambientes legados, tais como escalabilidade, confiabilidade, convergência e afins (ex: L2VPN MPLS visando sanear os desafios das redes L2 clássicas; MPLS TE visando resolver os desafios de engenharia de tráfego IP, etc.), e isto ao mesmo tempo em que outros conceitos foram surgindo para fomentar ainda mais a escalabilidade, flexibilidade e redução de custos (BGP-Free Core, 6PE/6VPE, e Unified MPLS são exemplos clássicos). O MPLS pode ser considerado como um marco, um verdadeiro divisor de águas, para todo o segmento de telecomunicações.<br /> <br /> ==== MPLS Traffic Engineering ====<br /> Conheça mais: [[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]].<br /> <br /> O MPLS-TE é uma solução que embarca duas propostas principais: a) engenharia de tráfego, b) proteção e recuperação contra falhas de enlaces e roteadores. Embora frequentemente combinado com os projetos MPLS clássicos (sem TE), o MPLS-TE não depende dos procedimentos do MPLS LDP. Para a parte de engenharia de tráfego, o MPLS-TE propõe-se a sanar algumas deficiências que são inerentes do próprio roteamento IP, os quais incluem congestionamentos decorrentes do mapeamento ineficiente dos fluxos de tráfego sobre os recursos da rede (interfaces, enlaces e roteadores), e fazendo isso com um bom arranjo de ferramentas que permite flexibilidade para a manipulação dos fluxos de tráfego através da rede do ISP e sem que isto exija modificações complexas nas propriedades do roteamento IP, tais como distância administrativa e métricas de rotas IGP, políticas de roteamento no backbone, rotas estáticas e afins. Já para a questão da rápida recuperação de falhas, o MPLS-TE fornece um recurso denominado Fast Reroute (FRR), o qual, através de uma estratégia conhecida por &quot;''Make-before-Break''&quot;, viabiliza a construção de LSPs de contingência para pronto uso em caso de falhas do next hop ou do nexto hop do next hop, promovendo índices de recuperação de falhas aproximados em 50 milissegundos.<br /> <br /> ==== Multi-CDN ====<br /> <br /> ==== Multi-tenant ====<br /> <br /> ==== NAT ====<br /> Acrônimo: ''Network Address Translation''.<br /> <br /> Tecnologia que realiza a tradução de endereços IP especificados nos cabeçalho IP dos pacotes em trânsito em um roteador. O NAT foi concebido originalmente como uma das iniciativas de soluções para conter o &quot;desmatamento&quot; do endereçamento IPv4, ou seja, sendo usado para conter ou desacelerar o rápido esgotamento da disponibilidade de endereços IP públicos. Há muitos anos iniciativas tais como o ''Classless Interdomain Routing'' (CIDR), ''Variable Length Subnet Masking'' (VLSM), endereçamento IPv4 privativo (IANA RFC 1918 [rfc:1918 - Address Allocation for Private Internets]), e ''Network Address Translation'' (NAT) foram introduzidas nos conceitos de projetos de redes para que tivéssemos a sobrevida do espaço de endereços IPv4 públicos até os dias atuais. Estima-se que, sem estas iniciativas, o esgotamento destes endereços teria ocorrido há muito tempo. Falando especificamente de NAT, esta solução anda lado a lado, como &quot;unha e carne&quot;, com os endereços IP privativos. Redes corporativas e domésticas/residenciais inteiras são endereçadas com endereços IP privativos (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16), e não há rotas no backbone da Internet para estes prefixos. Para que um usuário portando um endereço IP privativo destes possa navegar pela Internet, torna-se necessário realizar a tradução de seu endereço IP de origem para um endereço IP público disponível através desta configuração de NAT. Há vários tipos de cenários envolvendo o NAT, tais como o NAT dinâmico (numa relação ''one-to-one''), o ''Port Address Translation'' (também dinâmico, mas numa relação ''many-to-one''), NAT estático (relação 1:1) e NAT estático por portas (relação 1:1 com portas), sendo que o PAT ou &quot;''masquerading''&quot; é um dos cenários mais amplamente difundidos. Para os ISPs ou operadores de rede, no que diz respeito à conectividade de Internet de assinantes residenciais com endereços IPv4, no entanto, não utiliza-se o NAT &quot;convencional&quot;, e sim uma extensão funcional denominada ''Carrier Grade NAT'' (CGN ou CGNAT), já citada em nossa Enciclopédia, em combinação com outra faixa de endereços IPv4 privativos, a 100.64.0.0/10 (conforme [rfc:6598 RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space]). Para finalizar, entenda que o NAT pode ser usado também para a tradução de endereços IP de destino, mas fica à critério de cada projeto técnico e de suas particularidades.<br /> <br /> ==== NETCONF/Yang ====<br /> Acrônimo: ''Network Configuration''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no &lt;nowiki&gt;RFC 6241&lt;/nowiki&gt;. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações. Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração &quot;na mão&quot;. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, &quot;automatizados&quot;, é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho. O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, e é tido por muitos como a melhor interface southbound para ambientes de orquestração atualmente.<br /> <br /> O YANG por sua vez é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.<br /> <br /> ==== NetFlow ====<br /> A tecnologia como um todo é composta por caches de fluxo, coletores de fluxo e analisadores de dados. O NetFlow, quando foi criado há muitos anos, surgiu inicialmente como uma proposta para ''switching path'', mas rapidamente evoluiu para aquilo que muitos dos profissionais de redes compreendem sobre ele. O NetFlow é atualmente e há muitos anos uma tecnologia que visa fornecer excepcional visibilidade na rede e em resposta aos constantemente evoluídos requisitos para que os operadores de redes saibam como as suas redes estão se comportando, e fornecendo respostas para situações tais como: mapa de uso de aplicativos e redes, produtividade e utilização de recursos de rede, impacto das alterações na rede, detecção de anomalias na rede, assim como a identificação de vulnerabilidades de segurança, e problemas de conformidade a longo prazo. Para estas e outras necessidades, os engenheiros de redes passam a possuir ferramentas para entender quem, o que, quando, onde e como o tráfego da rede está fluindo, fomentando melhor entendimento sobre como as tecnologias empregadas na rede estão funcionando em alinhamento com os negócios da empresa; trilha de auditoria de como a rede é utilizada, aumento da conscientização quanto aos investimentos e uso da rede como um todo, redução de vulnerabilidades da rede, redução dos índices de downtime e distúrbios gerais, redução de custos, etc. O NetFlow pode ser usado como uma ferramenta &quot;simples&quot; para o gerenciamento de performance da rede, ou para situações bem mais ousadas, incluindo ações de planejamento de capacidades, engenharia de rede, engenharia de tráfego, bilhetagem e tarifação de tráfego, e detecção e mitigação de malware e de ataques DDoS sobre a rede, para citar alguns casos. Em termos práticos, o NetFlow é configurado em roteadores e switches, onde estiver disponível/suportado, podendo ser customizável em alguns casos, e, após isto, o equipamento exportará os bilhetes de fluxos de tráfego por NetFlow até uma estação coletora, a qual processará e consumirá estes dados, de acordo com os exemplos de soluções e casos citados anteriormente, e podendo interagir de volta com a rede para que ações sejam executadas pelos dispositivos da rede.<br /> <br /> O NetFlow é um protocolo proprietário da Cisco, mas que está disponível em outros fabricantes do mercado. O seu equivalente em termos de padrão aberto é o protocolo ''Internet Protocol Flow Information eXport'' (IPFIX).<br /> <br /> ==== NFV ====<br /> Acrônimo: ''Network Functions Virtualization''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware &quot;''commodity''&quot;. Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado. Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. <br /> <br /> ==== NodeB ====<br /> Um Node B é um termo para denotar uma estação base na terminologia WCDMA/UMTS, e é responsável pelo enlace de rádio entre o usuário da rede móvel e a parte fixa da rede ''UMTS Terrestrial Radio Access Network'' (UTRAN), conforme definido pelo 3GPP, ou seja, fornecendo a cobertura de rádio e conversão de dados entre esta rede de rádio e os ''Radio Network Controllers'' (RNCs).<br /> <br /> ==== OM ====<br /> OM1 - <br /> <br /> OM2 - 62,5/125 microns<br /> <br /> OM4 - 50/125 microns<br /> <br /> ==== Open/R ====<br /> (IGP virtualizado)<br /> <br /> ==== OSPF ====<br /> Acrônimo: ''Open Shortest Path First''.<br /> <br /> Conheça mais: [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas práticas para a implantação do OSPF em ambientes de ISP]]<br /> <br /> Protocolo de roteamento dinâmico do tipo interior e por definição de estado de enlaces (Link-State). O OSPF é um dos principais componentes das infraestruturas de redes dos provedores de acesso à Internet, sendo indispensável para viabilizar o roteamento necessário para o transporte das sessões BGP, resolução de roteamento recursivo referente ao atributo NEXT_HOP das rotas BGP mantidas nos Sistema Autônomo do ISP, além de atuar também para funções de roteamento de alguns serviços internos específicos do ISP. Muito frequentemente o OSPF é utilizado, também, em alinhamento com a tecnologia para fins de engenharia de tráfego com o MPLS TE, sendo, neste caso, inclusive, um componente obrigatório para este tipo de projeto. O OSPF destaca-se pela eficiência nas ações de rápida convergência, rápida recuperação de falhas e escalabilidade. Alternativamente ao OSPF, os operadores de redes podem optar pelo protocolo de roteamento IS-IS.<br /> <br /> ==== PCC ====<br /> Acrônimo: ''Path Computation Client.'' <br /> <br /> O PCC é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), o próprio cliente PCC (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCE ====<br /> Acrônimo: ''Path Computation Element''.<br /> <br /> O PCE é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client''), o protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)).<br /> <br /> ==== PCEP ====<br /> Acrônimo: ''Path Computation Element Communication Protocol''.<br /> <br /> O PCEP é parte integrante do PCE (''Path Computation Element''), que é um modelo de computação centralizado para redes MPLS, a qual foi criada originalmente para computar caminhos em um controlador centralizado e visando a engenharia de tráfego Inter-AS, embora não esteja limitado apenas a este cenário. A solução inclui um ou mais servidores (''PCE Server'' (PCS)), clientes (''Path Computation Client'' (PCC)), o próprio protocolo ''PCE Protocol'' (PCEP), e um banco de dados contendo todas as informações e propriedades para a engenharia de tráfego da rede, tais como as informações de recursos e topologias (''Traffic Engineering Database'' (TED)). O novo paradigma de redes programáveis orientadas a aplicações foi o que impulsionou as extensões PCEP, as quais possuem definições nos ''drafts draft-ietf-pce-stateful-pce'', ''draft-crabbe-pce-pce-initiated-lsp'', ''draft-ali-pce-remote-initiated-gmpls-lsp'', e outros.<br /> <br /> ==== Peering ====<br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Peering ou Troca de tráfego é uma relação comercial e técnica entre duas redes. É um acordo em que as redes admitem trocar tráfego entre os clientes uns dos outros, desde que o relacionamento seja '''mutuamente benéfico''', e nem sempre os acordos são isentos de custo ou trocas comerciais. Para garantir que cada lado do acordo tenha benefícios similares, as redes podem precisar atender aos requisitos pré-definidos para serem elegíveis. Por exemplo, uma rede pode precisar manter uma certa proporção de troca de tráfego, presença geográfica ou capacidade de backbone. A implantação real dessas relações de Peering, geralmente ocorre em locais comuns, como os NAPs e IXs estabelecidos pelo mundo (''Public'' Peering), ou através de links dedicados pagos pelas redes envolvidas (PNI-''Private network Interconnect'').<br /> <br /> ==== PGW ====<br /> Acrônimo: ''Packet Data Network Gateway''.<br /> <br /> ==== PNI ====<br /> Acrônimo: ''Private Network Interconnection''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> O famoso Private Peering ou Interconexão Privada em português - é aquele que normalmente não envolve quaisquer pontos de troca pública, ou seja, são portas de roteadores ''back-to-back'' normalmente interligadas por um ''cross-connect'' ou &quot;''golden jumper''&quot; ou até por capacidade em redes de transporte ''LAN-to-LAN''.<br /> <br /> ==== PPPoE ====<br /> Acrônimo: ''Point-to-Point Protocol over Ethernet''.<br /> <br /> O PPPoE é um protocolo utilizado para encapsular quadros PPP dentro de quadros Ethernet, tendo surgido no final dos anos 90 juntamente com a proliferação da Internet banda larga proporcionada com a entrada das tecnologias de transmissão baseadas no DSL. O PPPoE servia então como uma solução de tunelamento dos pacotes sobre a conexão DSL. Atualmente, com a predominância das redes FTTH, o PPPoE continua sendo utilizado nas redes dos ISPs, mas primariamente como mecanismo de autenticação e autorização de assinantes dos produtos de Internet banda larga dos ISPs, sendo o principal procedimento utilizado para este propósito, e a sua operação neste modelo ocorre entre o equipamento do assinante (CPE/CE) e o concentrador de assinantes (BNG ou BRAS), cuja a separação poderá ser uma rede Metro Ethernet (L2) clássica, ou L2 sobre MPLS (L2VPN), ou xPON.<br /> <br /> ==== PTT ====<br /> Acrônimo: ''Ponto de Troca de Tráfego''.<br /> <br /> Conheça mais: [[Modelos Interconexão]] e [[CDN Peering e PNI - Brasil]].<br /> <br /> Ponto de Troca de Tráfego (PTT), em inglês ''Internet Exchange Point'' (IXP), é um modelo de interconexão de redes entre os provedores de Internet e redes de fornecimento de conteúdo. Os Pontos de Troca de Tráfego (PTT) funcionam como hubs em que provedores podem conectar seus sistemas autônomos (AS), facilitando o tráfego de informações entre si. No Brasil, o IX.br é um projeto de PTTs locais gerido pelo Núcleo de Informação e Coordenação do Ponto Br (NIC.br) e pelo Comitê Gestor da Internet no Brasil (CGI.br), que facilita o fluxo de informações entre provedores de Internet e conteúdo online em diversas regiões no país. Na prática, quanto maior e melhor for um PTT, mais dados os provedores conseguem trocar, melhorando a eficiência da rede e encurtando o caminho da conexão entre os computadores, pois projetos de PTTs como o do IX.br proporcionam a ligação direta entre os participantes, permitindo que muitos Sistemas Autonômos (AS) troquem tráfego diretamente. A interligação de diversos AS em um IX, ou Ponto de Troca de Tráfego (PTT), simplifica o trânsito da Internet e diminui o número de redes até um determinado destino. Isso melhora a qualidade, reduz custos e aumenta a resiliência da rede. Também é possível oferecer ou contratar outros serviços a partir da conexão do seu ISP em um IX, como, por exemplo, serviços de trânsito de Internet.<br /> <br /> ==== QoS ====<br /> Acrônimo: ''Quality of Service''.<br /> <br /> Conheça mais: [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]].<br /> <br /> O ''Quality of Service'' (QoS) não deve ser compreendido como uma única tecnologia apenas, e sim um conjunto de tecnologias, ferramentas e práticas que, devidamente arrendadas, buscam sanear algumas das deficiências típicas de transmissão presentes em ambientes de redes de natureza estatística, especialmente o controle de latência, jitter, e perda de pacotes, decorrentes da insuficiência de recursos para a transmissão de pacotes nestes ambientes, como, por exemplo, os conhecidos gargalos/congestionamentos, esgotamento de buffers, e outros. Com a convergência de praticamente todo o tipo de aplicação e serviço para o transporte sobre redes baseadas no protocolo IP, soluções estas tais como Voice over IP (VoIP), Comunicações Unificadas (aka &quot;Telefonia IP e/ou Colaboração&quot;), Vídeo-conferência (em regime específico para tal, ou em conjunto com uma solução de Colaboração), etc., os engenheiros de redes precisam acomodar adaptações que permitam com que estes tipos de tráfego fluam de acordo com os padrões aceitáveis para uma boa interação humana através destas redes - em particular a audição e a visão. Anteriormente as soluções de vídeo e voz funcionavam sobre infraestruturas de redes digitais, ou seja, baseadas em transmissão deterministica, as quais não sofriam dos mesmos problemas das redes de transmissão estatísticas e baseadas em pacotes (congestionamentos; gargalos, descartes de pacotes devido a insuficiência temporária de buffers, etc.), como é o caso do Ethernet, IP e MPLS. Os requerimentos para o transporte de voz são bem mais agressivos nas questões de latência, jitter e perda de pacotes, se comparados com as transmissões de aplicações puramente de dados. As transmissões de vídeo podem ser extremamente agressivas, pois possuem os mesmos requisitos de latência, jitter e perda de pacotes das transmissões de voz, só que comportam-se em grande parte como uma aplicações de dados com elevada taxa de transmissão e consumo de recursos da rede. Para que a experiência de uma comunicação entre duas pessoas através de um serviço de VoIP/Telefonia IP/Colaboração/Vídeo fique isenta de picotes na voz, metalização da voz, ecos, atrasos excessivos, congelamento de imagens, perda de sincronismo entre vídeo e áudio, dentre outros, torna-se necessário priorizar estes tipos de transmissão com auxílio de políticas e configurações específicas. E é exatamente para isto que o QoS precisa ser adotado nas redes nos dias atuais. O mesmo é válido quando tratando-se de transmissões na rede envolvendo uma aplicação de dados crítica (um sistema ERP ou CRM) e uma navegação usual ou recreativa de Internet, onde, nestes casos, é muito desejável que a prioridade de transmissão seja de uma aplicação mais importante quando houver insuficiência de recursos para acomodar ambos os tipos de tráfego em um determinado momento. <br /> <br /> O QoS especifica uma diversidade de ferramentas e técnicas devidamente categorizadas em Classificação, Marcação, Gerenciamento de Congestionamentos, Controle de Congestionamentos, Policiamento, Moldagem e Eficiência de Links. <br /> <br /> ==== QSFP ====<br /> Acrônimo: ''Quad Small Form Factor Pluggable''.<br /> <br /> ==== RADIUS ====<br /> Acrônimo: ''Remote Authentication Dial In User Service''.<br /> <br /> ==== RGI Classe V da Anatel para SCM ====<br /> <br /> ==== RNC ====<br /> Acrônimo: ''Radio Network Controller''.<br /> <br /> ==== Roteador ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== Route-policy ====<br /> Uma route policy é uma ferramenta que &quot;materializa&quot; ou &quot;instrumentaliza&quot;, através de conceitos de sintaxe e semântica de uma interface de linha de comando (CLI), que é parte integrante do sistema operacional de roteadores, a política de roteamento idealizada pelo administrador ou engenheiro de uma rede para o seu projeto ou o atendimento de uma necessidade específica. Enquanto uma &quot;política de roteamento&quot; é o conceito projetado para uma interpretação mais humana da palavra, pois especifica a idéia, intenção ou interesse; é a &quot;política no papel&quot;, como, por exemplo, na perspectiva de cada roteador BGP vizinho ao seu roteador, quais prefixos importar, quais prefixos exportar, quais atributos deverão ser modificados, e sobre quais prefixos/rotas estas modificações devem ser feitas, para conceber quaisquer que sejam as necessidades em termos de engenharia de rede e de tráfego do projeto técnico idealizado pelo engenheiro da rede, contemplando ainda questões associadas à segurança do roteamento de Internet (prevenção de ''route leaks'', ''prefix hijacks'', supressão do recebimento e envio de ''bogons''/''martians''/''unallocated'', etc.). A '''''route policy''''', por sua vez, já é a efetiva instrumentação propriamente dita desta política de roteamento. É a &quot;policy&quot; na sua forma de configuração na linguagem suportada pelo sistema de seu roteador. Ou seja, &quot;os comandos&quot; da CLI, a sintaxe, a semântica. O termo route policy em si serve para o generalizar um conjunto de ferramentas que são encontradas nos roteadores e utilizadas para definirmos &quot;na forma de CLI&quot; as nossas políticas de roteamento, as quais deverão ser aplicadas nos sentidos &quot;entrada&quot; (''import'' ou &quot;''in''&quot;) e &quot;saída&quot; (''export'' ou &quot;''out''&quot;) de nossas vizinhanças BGP. Cada plataforma de roteador e de cada fabricante tem o seu conjunto próprio de ferramentas, capacidades, sintaxes, recursos suportados (e não suportados), etc. Por exemplo, roteadores Juniper (software &quot;JUNOS&quot;) implementam as suas facilidades por meios do ''Routing Policy Framework'', que consiste de termos (&quot;''terms''&quot;) definidos na forma de um ou mais ''policy-statement'', com sofisticadas e variadas opções de incidência de classificação (''match'') e ações a serem adotadas em cada incidência (''accept'', ''reject'', modificar atributos, etc.), e podendo ainda acionar outras ferramentas e recursos periféricos para uma classificação mais refinada dos prefixos (ex: ''route-filter-list'', ''community'', etc). Roteadores Cisco equipados como Cisco IOS XR Software, por sua vez, possuem um sistema periférico muito robusto denominado ''Routing Policy Language'' (RPL), que combina diversos tipos de objetos (''prefix-set'', ''as-path-set'', ''community-set'', ''extcommunity-set'', dentre outros), para definir uma sofisticada, porém de simples interpretação, política de roteamento na forma de &quot;''route-policy''&quot;, com operações intuitivas na forma de &quot;''if'' / ''else'' / ''then'' / ''set'' / ''pass'' / ''drop'' / ''done'' / ''endif'', etc.&quot;. Já os roteadores da Cisco baseados no Cisco IOS e IOS XE Software apresentam as conhecidas e pioneiras &quot;''Route Maps''&quot;, as quais atuam em conjunto com outros recursos disponíveis na plataforma, tais como ''prefix-lists'', ''community-lists'', ''ip as-path access-lists'', e outras. Já os roteadores da Huawei no geral implementam recursos similares em termos de implementação aos do Cisco IOS / IOS XE, tais como ''route-policy'', ''ip-prefix'', ''community-filter'' e outros, enquanto equipamentos mais recentes deste fabricante já implementam uma solução diferente denominada ''eXtended routing-Policy Language'' (XPL), inspirada no RPL do Cisco IOS XR. Independentemente do &quot;vendor&quot; ou do equipamento, o fato é que route policies são indispensáveis, pois são usadas cotidianamente para o cumprimento de diversos objetivos relacionados ao roteamento de Internet ou de qualquer projeto de infraestrutura IP onde o BGP seja utilizado para fornecer segurança e engenharia de tráfego.<br /> <br /> ==== RPKI ====<br /> Acrônimo: ''Resource Public Key Infrastructure (RPKI)''.<br /> <br /> ==== RTBH ====<br /> Acrônimo: ''Remotely Triggered Black Hole (RTBH)''.<br /> <br /> ==== RUM ====<br /> <br /> ==== SBI ====<br /> Acrônimo: ''Settlement Based Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão também conhecido como Peering Pago (Paid Peering), onde uma das redes paga a outra pela troca de tráfego.<br /> <br /> ==== SCM ====<br /> Acrônimo: ''Serviço de Comunicação Multimídia''.<br /> <br /> ==== SDN ====<br /> Acrônimo: ''Software-Defined Networking''.<br /> <br /> Conheça mais: [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]].<br /> <br /> Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.<br /> <br /> ==== SeAC ====<br /> Acrônimo: ''Serviço de Acesso Condicionado''.<br /> <br /> ==== SFI ====<br /> Acrônimo: ''Settlement-free Interconnect''.<br /> <br /> Conheça mais: [[Modelos Interconexão]].<br /> <br /> Modalidade de interconexão onde nenhuma das partes paga a outra pela troca de tráfego entre ambas.<br /> <br /> ==== SFP ====<br /> Acrônimo: ''Small Form Factor Pluggable''.<br /> <br /> ==== Segment Routing (SR) ====<br /> <br /> ==== Segment Routing v6 (SRv6) ====<br /> <br /> ==== SGSN ====<br /> Acrônimo: ''Serving GPRS Support Node''.<br /> <br /> ==== STFC ====<br /> Acrônimo: ''Serviço Telefônico Fixo Comutado''.<br /> <br /> ==== SMP ====<br /> <br /> ==== SNMP ====<br /> Acrônimo: ''Simple Network Management Protocol''.<br /> <br /> ==== SSH ====<br /> Acrônimo: ''Secure Shell''.<br /> <br /> ==== Switch ====<br /> Conheça mais: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> ==== SyncE ====<br /> Acrônimo: ''Synchronous Ethernet''.<br /> <br /> O SyncE é uma das quatro soluções de ''timing'' sobre redes de transmissão baseadas em pacotes, juntamente com o ''Precision Time Protocol'' (PTP), ''Network Time Protocol'' (NTP) e ''Timing over IP Connection and Transfer of Clock BOF'' (TICTOC). O SyncE é ao mesmo tempo um protocolo e um método de sincronismo para instruções de ''timing'' operando diretamente sobre o Ethernet, ou seja, sem o envolvimento de protocolos de camadas superiores (ex: IP, UDP ou TCP), e possui um procedimento que remonta ao que as redes SDH fazem. O SyncE é utilizado especialmente para o sincronismo de frequência, sendo inclusive muito preciso quanto a isto, mas não provê sincronismo de data e hora, pois este tipo de distribuição de informação (data/hora) precisa ou deve ser feita por outro protocolo (ex: NTP ou PTP). Diversos padrões regem o SyncE, dentre eles o ITU-T G.8261, G.8262, G.8264 e G.781. Em termos de eficácia, o SyncE é a referência de frequência mais estável e a mais precisa disponível atualmente, após as opções por PRC, BITS e GPS, e operadores de telefonia móvel estão avançando no suporte ao SyncE em suas redes como medida de redução de custos e sem o comprometimento da qualidade, ou seja, evitando instalações de GPS em cada estação da rede móvel.<br /> <br /> ==== TACACS+ ====<br /> Acrônimo: ''Terminal Access Controller Access-Control System Plus''.<br /> <br /> ==== Telnet ====<br /> <br /> ==== Trânsito ====<br /> <br /> ==== uRPF ====<br /> Acrônimo: ''Unicast Reverse Path Forwarding''.<br /> <br /> O ''Unicast Reverse Path Forwarding'' (uRPF) é um recurso disponível no software dos roteadores que é utilizado primariamente como mecanismo de &quot;antispoofing&quot;, ou seja, serve para a validação do endereço IP de origem sobre os pacotes recebidos nas interfaces do roteadores. A outra funcionalidade do uRPF é atuar como mecanismo de prevenção de ''routing loops'', em especial em situações relacionadas ao IP Multicasting. No que concerne ao mecanismo de &quot;antispoofing&quot; de endereços IP de origem em tráfego unicast em si, o uRPF é a ferramenta mais indicada para ser adotada nas interfaces que apontam diretamente para as conexões do cone de clientes (downstreams) do provedor de acesso à Internet (ISP), sendo ali o ponto correto de posicionamento e configuração deste mecanismo. Quanto as razões para a utilização do uRPF, o principal e mais forte argumento é a eliminação ou redução dos vetores de ataques DDoS, pois, para que este tipo de ataque possa ser bem sucedido, torna-se necessário que os hosts infectados (&quot;zumbis&quot;), que, neste caso, seriam os clientes do seu ISP, e de outros ISPs também, controlados por uma botnet, encaminhem pacotes com endereços IP de origem &quot;spoofados&quot; (forjados) para que aparentem terem sido enviados a partir do host ou rede que será a vítima deste ataque (cujo seu(s) endereço(s) IP foi (foram) forjado(s)/spoofado(s) por dezenas de milhares de outros hosts na Internet), o que promoverá, consequentemente, e infelizmente, o êxito deste ataque DDoS. Ou seja, sem o spoofing de endereços IP de origem, conceber ataques DDoS na Internet fica uma tarefa praticamente impossível - ou até que outras formas de ataques de negação de serviço sejam idealizadas pelos malfeitores da Internet. Por estas e outras razões que o &quot;Antispoofing&quot;, que inclusive é um dos objetivos estipulados pelo ''Mutually Agreed Norms for Routing Security'' (MANRS), deve ser projetado e configurado corretamente em todas as interfaces que admitem os clientes de um ISP, ou seja, em todo o seu &quot;downstream&quot;. Se todos os ISPs fizessem isso, simplesmente não haveria ataques DDoS na Internet. Ou pelo menos não nos moldes em que estes ataques são concebidos atualmente. Há algumas formas ou modalidades de implementação do uRPF, sendo eles o &quot;''Strict''&quot;, &quot;''Feasible''&quot; e &quot;''Loose''&quot;. Alternativamente ao uRPF, há outras ferramentas que podem ser consideradas para este propósito de antispoofing, incluindo Access Control Lists e IP Source Guard, mas, no caso de service providers / ISPs, o uRPF é o mecanismo mais indicado. Faça a sua parte e contribua para uma Internet mais segura: siga as recomendações do BCP 38 (''Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing''), que é citado no objetivo &quot;Antispoofing&quot; do MANRS, e ajude a reduzirmos substancialmente os ataques DDoS que assolam a Internet!<br /> <br /> ==== VPLS ====<br /> Acrônimo: ''Virtual Private LAN Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços multiponto, ou seja, onde envolve-se dois ou mais sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. <br /> [[Arquivo:Bpf-enciclopedia-vpls.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN multiponto (VPLS)]]<br /> <br /> ==== VPNv4 ====<br /> Acrônimo: ''Virtual Private Network version 4''.<br /> <br /> O VPNv4 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv4 é definido como uma extensão para o suporte mulitprotocolo do BGP (&lt;nowiki&gt;RFC 4364&lt;/nowiki&gt; e &lt;nowiki&gt;RFC 4659&lt;/nowiki&gt;), e é representado pelo ''Address Family Identifiers'' (AFI) número 1 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. O endereço VPNv4 possui 96 bits de comprimento, sendo 64 bits composto pelo ''Route Distinguisher'' e os 32 bits restantes sendo o prefixo IPv4 da rota original (ex: envidada do roteador CE para o roteador PE, antes da conversão desta rota IPv4 unicast para uma rota VPNv4 pelo roteador PE). Roteadores ''Provider Edge'' (PE) de um backbone de operadora de telecomunicações ou ISP são configurados para trocar rotas VPNv4 através de sessões MP-BGP entre si, as quais são devidamente estabelecidas sobre uma rede MPLS para viabilizar a comunicação entre os sites participantes de uma determinada VPN, usando outros atributos associados aos anúncios destas rotas VPNv4 (ex: extended communities denominadas ''Route Targets'', dentre outros parâmetros e atributos).<br /> <br /> ==== VPNv6 ====<br /> Acrônimo: ''Virtual Private Network version 6''.<br /> <br /> O VPNv6 é uma família de endereços específica para projetos de Redes Virtuais Privativas de Camada 3 (L3VPN) baseadas no MPLS, ou seja, L3VPN MPLS. O VPNv6 é representado pelo ''Address Family Identifiers'' (AFI) número 2 e ''Subsequent Address Family Identifiers'' (SAFI) número 128. Um endereço VPNv6 possui 64 bits de comprimento, sendo 8 octetos o &quot;''Route Distinguisher''&quot; e 16 octetos o endereço IPv6 unicast. À exemplo do VPNv4, o VPNv6 é trocado entre roteadores PE com o auxílio do protocolo BGP (MP-BGP) para o estabelecimento de L3VPN MPLS funcionais com o IPv6 dos sites atendidos/conectados. Para estas L3VPN com IPv6, as sessões IBGP entre os roteadores PE participantes poderá ser feita em IPv4 ou IPv6, e a codificação do atributo NEXT_HOP será distinta para cada caso (&quot;''BGP speaker requesting IPv6 transport''&quot; ou &quot;''BGP speaker requesting IPv4 transport''&quot;). Sobre a codificação do atributo Next Hop, um draft recente está propondo a modificação de alguns destes procedimentos (draft-litkowski-bess-vpnv4-ipv6-nh-handling-00).<br /> <br /> ==== VPWS ====<br /> Acrônimo: ''Virtual Private Wire Service''.<br /> <br /> Modalidade de cenário L2VPN orientado preferencialmente a serviços ponto-a-ponto, ou seja, onde envolve-se apenas dois sites de um determinado cliente ou serviço para a troca de tráfego L2, e independentemente de quais tenham sido as marcações de VLANs definidas para cada um destes sites participantes. Esta solução de L2VPN é estabelecida e transportada sobre uma infraestrutura de redes turbinada pelo MPLS. As diferenças principais entre o VPLS e o VPWS é que, no caso do VPWS, não há aprendizado de endereços MAC, e a solução comporta-se como um ''clear channel'' mesmo.<br /> [[Arquivo:Bpf-enciclopedia-vpws.png|centro|miniaturadaimagem|600x600px|Enciclopédia: L2VPN ponto-a-ponto (VPWS)]]<br /> <br /> ==== VxLAN ====<br /> Acrônimo: ''Virtual Extensible LAN''.<br /> <br /> Historicamente a segmentação de uma rede L2 tradicional tem sido fornecida por VLANs padronizadas conforme o IEEE 802.1Q, onde VLANs são criadas e distribuídas nos switches da rede para fornecer a segmentação lógica desejada para as funções de camada 2 em seus domínios de broadcast. No entanto, devido ao uso ineficiente dos links de rede disponíveis com o uso de VLAN, aos requisitos rígidos de posicionamento de dispositivos em redes de missão crítica como datacenters, e à escalabilidade limitada a um máximo de 4094 VLANs, o uso de VLANs tornou-se um fator limitante para muitas redes e de diversas empresas, especialmente data centers e provedores de acesso à Internet. Os ISPs já possuem uma solução baseada no Flexible VLAN Tagging ou Ethernet Flow Point em combinação com soluções L2VPN clássicas, mas este tipo de solução não atende os requisitos de conectividade com alta densidade e elasticidade de multitenantes. Alguns fabricantes líderes de mercado, incluindo a Cisco, Cumulus Networks, Arista, Broadcom, VMware, Intel e Red Hat, uniram-se para propor ao IETF uma solução para sanear os desafios de rede L2 mencionados previamente, e daí surgiu o VXLAN. O VXLAN fornece o posicionamento elástico da carga de trabalho (workload) e maior escalabilidade da segmentação da Camada 2, exigidas pelas demandas de aplicativos atuais, provendo os mesmos serviços Ethernet / camada 2 que VLANs demandam nos dias atuais, só que com maior extensibilidade, flexibilidade e escalabilidade. Em termos mais técnicos, o VXLAN é um esquema de sobreposição (overlay) da camada 2 em uma rede da camada 3. A tecnologia usa o encapsulamento MAC-in-User Datagram Protocol (MAC-in-UDP) para fornecer um meio de estender os segmentos da Camada 2 através da rede do data center, compondo uma solução formidável para oferecer suporte a um ambiente multitenant flexível e em larga escala através de uma infraestrutura física comum compartilhada. O protocolo de transporte na rede física do datacenter inclui o IP e o UDP. Para este procedimento, o VXLAN define um esquema de encapsulamento MAC-in-UDP em que o quadro original da camada 2 possui um cabeçalho VXLAN adicionado e é então colocado em um pacote UDP-IP. Com esse encapsulamento MAC-in-UDP, o VXLAN encapsula a rede da Camada 2 pela rede da Camada 3, fazendo as extensões desejadas das VLANs através da rede, mas, no entanto, sem incorrer nas mesmas limitações de flexibilidade, escalabilidade e diâmetro das redes L2 tradicionais.<br /> <br /> === Desciclopédia ===<br /> <br /> ==== Ajuste Fino ====<br /> Ajuste Fino descreve medidas paliativas ou &quot;''worarounds''&quot; para a superação de deficiências e limitações apresentadas ou impostas por algumas plataformas de equipamentos quando falham ao cumprir com as diretivas e configurações definidas pelos administradores, e cujas as falhas geralmente são acompanhadas de sentimentos de bastante frustração. Para exemplificar um dos tantos casos aqui, há um bocado de relatos onde um equipamento, que supostamente deveria possuir um bom suporte ao protocolo de roteamento BGP, com tabelas de Internet completas (full routes), &quot;trava&quot; rotineiramente ao apresentar ciclos de processamento elevados, bastando que apenas um de seus muitos núcleos disponíveis para esta finalidade fique engargalado para que o referido problema seja notado, consequentemente exigindo a reinicialização (&quot;reboot&quot;) do equipamento para a restauração da normalidade. Para mitigar este problema, dois argumentos possíveis são praticados pelos consultores: a) &quot;''você que não sabe configurar''&quot;, ou seja, na prática, como a quantidade de casos é um tanto grande, entendemos, portanto, que ninguém sabe configurar. b) &quot;''isto é fácil, é só mexer aqui, aqui, aqui e ali, e fazer isso, que você não terá mais o problema''&quot;. O argumento &quot;b&quot; é o que chamamos de Ajuste Fino. Quais tipos de manobras são consideradas ajuste finos? Vejamos: agendamento de reinicialização ou boot automático em intervalos periódicos, podendo ser diário ou semanal + upgrade de memória + publicação das full routes em uma VRF + balanceamento do tráfego através de múltiplos dispositivos, visando diminuir a carga + deixar na tabela principal apenas a rota padrão. Na verdade, fica até complicado definir os ajustes finos, pois são segredos comerciais guardados a sete chaves! O termo acabou generalizando e atualmente todo o workaround empregado para fugirmos de alguma restrição tecnológica ou de algum bug de software é chamado de &quot;Ajuste Fino&quot;, e isto independente do fabricante, modelo e marca do equipamento. Ajuste Fino pode ser considerado um workaround ou gambiarra para qualquer situação onde você teve que fazer algumas manobras esquisitas e fora do que usualmente precisamos fazer para as coisas funcionarem conforme &quot;by the books&quot;.<br /> [[Arquivo:Bpf-desc-ajustefino.png|centro|miniaturadaimagem|494x494px|Ajuste Fino!]]<br /> <br /> ==== Balance Soma-Link ====<br /> Clássica gambiarra que predominou em muitos ISPs pequenos e por muitos anos. A estratégia consistia em contratar dezenas de links banda larga ADSL para desempenharem a função de Trânsito IP do provedor, e fazer uma configuração com roteadores Mikrotik ou de classe similar para executar o balanceamento do tráfego através destas conexões, e sob o pretexto de que este tipo de &quot;solução&quot; somava a capacidade dos links e ainda por cima promovia uma distribuição simétrica ou bem uniforme do tráfego. Alguns consultores, por falta de opções ou recursos, ou despreparados tecnicamente, ou, em alguns casos, malandros mesmo, militavam abertamente nas redes sociais sobre estas façanhas. Desnecessário comentar aqui que tal gambiarra é completamente equivocada nos pontos de vista legal e ético, além de tecnicamente bastante frágil. Felizmente caiu em desuso, mas ainda assim é possível encontrar estas maluquices por aí. Nem o próprio MacGyver, ícone do famoso seriado dos anos 80, especializado em promover gambiarras incríveis para todo e qualquer tipo de situação, teria sido tão &quot;genial&quot; quanto os malandros que inventaram o &quot;Balance Soma-Link&quot;! A diferença é que as gambiarras do MacGyver funcionam e são quase sempre éticas, já essa gambiarra aí...<br /> [[Arquivo:Bpf-desc-loadbalance.png|centro|miniaturadaimagem|600x600px|Gambiarra do Balance Soma-Link]]<br /> <br /> ==== Bridge Roteada ====<br /> <br /> ==== IP Confinado ====<br /> Conheça mais: [[CDN Peering e PNI - Brasil|https://wiki.brasilpeeringforum.org/w/CDN_Peering_e_PNI_-_Brasil]]<br /> <br /> O &quot;IP Confinado&quot; é um produto ofertado por alguns provedores com a proposta de fornecer conteúdo de &quot;CDNs apenas&quot; para clientes interessados neste tipo de serviço. O que justifica o &quot;IP Confinado&quot; estar sendo listado em nossa desciclopédia não é a parte técnica da &quot;solução&quot; em si, e sim as diversas violações contratuais associadas com a prática. Muitos destes ISPs promovem algumas práticas que não são permitidas conforme os contratos que são estabelecidos entre ISPs e as detentoras das CDNs. Por exemplo, não é permitido que o ISP mencione que &quot;vende tráfego de CDN&quot;, muito menos destacando ou citando os nomes das empresas/CDNs envolvidas na &quot;oferta&quot;; incorporar logotipos/logomarcas destas empresas em qualquer tipo de propaganda ou material publicitário, expor as fotos dos equipamentos/servidores de CDN implantados em seus data centers, etc. Ou seja, o &quot;IP Confinado&quot; está frequentemente associado a abusos por parte de ISPs, tais como violações de direitos autorais, direitos de propriedade intelectual, direitos de imagem e afins. <br /> <br /> Entenda: é permitido que o ISP venda &quot;implicitamente&quot; o conteúdo de CDNs como parte de uma oferta de &quot;Trânsito IP Parcial&quot; e similares, mas desde que mantendo sob sigilo as informações que possam identificar as empresas que fornecem as CDNs para o ISP. A venda de conteúdo de CDN em si é tida como uma prática ilegal.<br /> [[Arquivo:Ipconfinado.png|centro|miniaturadaimagem|600x600px|Desciclopédia: IP Confinado]]<br /> <br /> ==== IP Ilegal ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Puro ====<br /> O &quot;IP Puro&quot; nada mais é que uma proposta de fornecimento de um serviço de trânsito para um cliente-ISP final e que exclua deste link todo o tráfego de CDNs que por ventura estiver presente na infraestrutura do ISP contratado. Muitos ISPs contam com infraestruturas de CDNs em seus ambientes, juntamente com as sessões de trânsito IP com seus upstreams e também os pontos de troca de tráfego, sejam estes privativos, compartilhados ou bilaterais. Quando um ISP contrata um serviço de trânsito IP junto a outro ISP, neste link escoará todo o tipo de tráfego que existir na infraestrutura do ISP contratado, ou seja, tráfego proveniente dos peerings (ex: IX.br, PNI com Google, Facebook, etc.), trânsito (os upstreams daquele ISP contratado), e, claro, o tráfego das CDNs que existirem no ISP contratado. <br /> <br /> O que alguns ISPs-clientes fazem é exigir que o tráfego destas CDNs não seja fornecido no link de trânsito IP contratado. As discussões acerca deste tipo de necessidade um tanto curiosa ou inusitada são tantas as vezes que um produto denominado &quot;IP Puro&quot; acaba sendo informalmente definido entre os participantes do meio. As vantagens e benefícios alegados por alguns são bastante questionáveis, pois entendemos que o ISP-cliente tem muito mais a perder do que a ganhar com esta preferência. O &quot;IP Puro&quot; é um exemplo clássico de nossa Desciclopédia!<br /> <br /> ==== IP Real ====<br /> Vide &quot;IP Válido&quot;.<br /> <br /> Uma tentativa do profissional de citar que o endereço IP em questão não é privativo (da faixa especificada pelo RFC 1918 ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt;).<br /> <br /> ==== IP Válido ====<br /> Endereços IP &quot;válidos&quot;, na mente de muitos profissionais da área, são aqueles endereços IP cuja conectividade com a Internet é plenamente funcional, justamente por não estarem contidos nas faixas especificadas pelo &lt;nowiki&gt;RFC 1918&lt;/nowiki&gt; (''Address Allocation for Private Internets'') ou &lt;nowiki&gt;RFC 6598&lt;/nowiki&gt; (''IANA-Reserved IPv4 Prefix for Shared Address Space''). Ou seja, a verdade é que IP válido é qualquer endereço IP que não seja privativo.<br /> <br /> Na verdade, todo endereço IP é válido! O correto seria diferenciar o endereço IP em &quot;público&quot; e &quot;privado&quot;, e não em válido ou inválido (quando o endereço for privativo). <br /> <br /> ==== IX Confinado ====<br /> <br /> ==== Link Dedicado Full Duplex ====<br /> <br /> ==== Link Semi-Dedicado ====<br /> O &quot;Link Semi-Dedicado&quot; é algo que expressa muito bem a cultura do brasileiro! Para resumir ou antecipar aqui, isto é basicamente uma gambiarra comercial.<br /> <br /> Para explicar isto melhor, vejamos o serviço de um link dedicado. Serviços de links dedicados são e devem ser tipicamente fornecidos através de uma infraestrutura Metro Ethernet, a qual disponibiliza recursos mais exclusivos e dedicados para o assinante/cliente, tais como uma porta dedicada em um switch Metro para aquele cliente, o enlace da fibra óptica é dedicado na última milha para a conexão do equipamento CPE/CE do cliente, a banda contratada é absolutamente simétrica e pode ser ajustada para até a capacidade máxima suportada pela porta (ex: 200 Mbps sobre porta 1 Gbps, 500 Mbps sobre porta 1 Gbps, ou 1 Gbps direto na porta). Ou seja, um Link Dedicado reúne componentes e arranjos tecnológicos mais caros e especializados para maximizar a experiência do cliente quanto à contratação do serviço. Novamente, é uma tecnologia mais cara, mas o cliente que contrata este serviço sabe exatamente o que e por que está contratando.<br /> <br /> Por outro lado, temos as tecnologias de Internet banda larga, inicialmente lá atrás com tecnologias baseadas no DSL (empregando DSLAMs e/ou MSANs, por exemplo), e nos últimos anos, o FTTH com xPON (principalmente o GPON), que operam especialmente sobre uma rede de acesso completamente compartilhada e com banda assimétrica Up e Down para as taxas mais elevadas.<br /> <br /> O GPON todos nós sabemos que é uma rede óptica passiva de natureza compartilhada, e toda a infraestrutura GPON é indiscutivelmente mais barata que uma rede Metro Ethernet; a diferença é muito expressiva neste sentido. Enquanto isto, é de amplo conhecimento que serviços de Internet banda larga são bem mais baratos (e viáveis para muitas pequenas empresas) que serviços de Internet com link dedicado, certo?<br /> <br /> O que alguns ISPs fazem, inclusive isto começou com um grande operador de redes: o &quot;meio-termo&quot;. Basicamente estas empresas tem vendido links de Internet banda larga com taxas um pouco mais elevadas, mas compatíveis com a característica assimétrica do projeto da rede GPON para a região onde o cliente está localizado, e suprimem, na cara de pau, o termo &quot;banda larga&quot;, usando o termo &quot;dedicado ou semi-dedicado&quot; para promover ou fornecer o serviço. Nada contra o GPON, muito pelo contrário! É uma tecnologia que permitiu baratear bastante os custos de construção de redes e a difundir melhor a Internet banda larga para muitos segmentos de pequenos negócios. Quando confrontados por clientes na questão de simetria da banda, os consultores do ISP procuram &quot;driblar&quot;, evitando mencionar que a rede é compartilhada (e que tem essa questão de restrições envolvendo a simetria Up e Down), e, quando sofrem o ultimato, informam que o serviço é &quot;Semi Dedicado&quot; (ou seja, nunca fazem menção ao aspecto compartilhado ou ao próprio GPON).<br /> <br /> Uma gambiarra estritamente comercial! É que nem você falar que mora num bairro adjacente ao seu, ao invés de citar o nome real conforme o seu CEP, porque seu bairro tem uma má fama. Ou que nem você ter vergonha de assumir a sua namoradinha(o) em público!<br /> [[Arquivo:Bpf-enciclopedia-semidedicado.jpg|centro|miniaturadaimagem|500x500px|Desciclopédia: Link Semi-Dedicado]]<br /> <br /> ==== Lupebequi ====<br /> <br /> ==== Rota Presa ====<br /> <br /> ==== SkyGato ====<br /> <br /> ==== Terraplanistas da Telecom ====<br /> O que seriam &quot;terraplanistas da telecom&quot;? Analogia aos terraplanistas &quot;originais&quot;: indivíduos que se acham superiores a gerações inteiras de verdadeiros gênios inspiradores, dos quais incluo aqui Eratóstenes, Galileo Galilei, Isaac Newton, Albert Einstein, Johannes Kepler, Arthur Eddington, Edwin Powell Hubble, Milton L. Humason, Tycho Brahe, Michael Faraday, Stephen Hawking, Steven Weinberg, James Clerk Maxwell, Peter Higgs, Edward Witten, Freeman Dyson, Werner Heisenberg, Erwin Schrodinger, Alan Guthm, Ernest Rutherford, Paul Dirac, Niels Bohr.... fora Anaximandro, Arquimedes, e tantos outros, dentre gênios e perseguidos. Todo um esforço gigantesco e desde os tempos mais remotos para que evoluíssemos humana e tecnologicamente e nas áreas de física e astrofísica, construíssemos coisas incríveis, compreendêssemos o universo próximo, mesmo que faltando ainda tantas perguntas sem respostas, para termos uma classe de indivíduos em franca expansão (&quot;terraplanistas&quot;) usando a tecnologia, todo o aparato tecnológico à seu favor para, nas redes sociais, bradarem aos 4 ventos: &quot;A TERRA É PLANA!&quot;. Surreal!<br /> <br /> Na mesma moeda, analogias aqui, os &quot;''terraplanistas da telecom''&quot; são aqueles indivíduos que atuam na área e que tentam refutar o irrefutável. Literalmente '''''&lt;u&gt;rasgam&lt;/u&gt;''''' RFCs, BCOPs, padrões/standards, e frameworks. Não somente isto: acidentalmente ou propositalmente quase que rasgam também os trabalhos dos &quot;gênios da nossa área&quot;; Radia Joy Perlman, John Moy, Yakov Rekhter, Kirk Lougheed, Vint Cerf, Robert Kahn, Robert Metcalfe, David Boggs, W. David Sincoskie, Ali Sajassi, dentre tantos caras que criaram tudo o que usamos nas redes hoje, fora os grupos de trabalho incluindo IETF, IEEE, IANA, RIPE, NIC.br, LACNOG, NANOG, GPF, e, porque não, as recomendações do BPF, e o escambáu. As BCOPs e RFC são literalmente '''&lt;u&gt;nada&lt;/u&gt;''' para alguns destes indivíduos (sim, eu atestei isto! Eu li e conferi isso numa discussão!). O que um Job Snijders falaria no ouvido desses caras, entraria por um lado e sairia pelo outro!<br /> <br /> Parece exagero, mas tem surgido uma classe de indivíduos que tenta refutar uma diversidade de fatos irrefutáveis sobre as características, disponibilidades e aplicabilidades de tecnologias associadas à redes, telecomunicações no geral; a Internet. Dentre os absurdos que vemos por aí, temos: &quot;''é mentira que o IPv4 está se esgotando!''&quot;, &quot;''o OSPF está morrendo!''&quot;, &quot;''operadoras estão deixando de usar o MPLS''&quot;, &quot;''a navegação por IPv6 prejudica a performance da minha Internet&quot;'', &quot;''não preciso implantar o IPv6, porque o IPv6 ainda não é usado&quot;'', ''&quot;blackhole é mitigação de DDoS''&quot;, &quot;''trânsito sem PTT é melhor''&quot;, &quot;''existe trânsito IP puro''&quot;, &quot;''sessão de peering com IX Europeu melhora a performance porque a lista de AS_PATH é menor''&quot;, dentre outras coisas engraçadas. Note que não são apenas &quot;opiniões&quot;: essas situações fazem parte de recomendações de fato que os &quot;terraplanistas da telecom&quot; promovem!<br /> <br /> O meu termo aqui de &quot;terraplanistas da telecom&quot; não faz julgamento de quanto o indivíduo sabe ou não sabe sobre estas tecnologias. Realmente não compete a mim julgar o nível de conhecimento de qualquer um que seja, e isto está absolutamente fora de questão. O que me cabe a fazer, obviamente, é questionar porque eles falam mal de certas coisas que eles mesmos não compreendem ou dominam? Não seria mais prudente pesquisar, informar-se, praticar, exercitar, questionar, etc., a ponto do indivíduo ser fluente o suficiente nesse ou naquele tema (protocolo, tecnologias), antes de tentar influenciar as outras pessoas?<br /> <br /> Uma coisa é você falar que não sabe ou não domina uma tecnologia, por isso que você não a quer ou prefere evitá-la. Uma coisa é você falar que determinada tecnologia não é compatível com os seus planos e pelas razões X, Y e Z. Em ambos os exemplos, argumentos e justificativas válidos. Agora, falar que &quot;''é mentira que o IPv4 está se esgotando''&quot; e coisas deste tipo é um verdadeiro desserviço para a comunidade!<br /> [[Arquivo:Bpf-enciclopedia-terraplanistas.png|centro|miniaturadaimagem|700x700px|Desciclopédia: terraplanistas da telecom]]<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Geral]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Ipconfinado.png&diff=2515 2020-06-15T18:48:34Z

<p>Leonardo.furtado: </p> <hr /> <div>Desciclopédia: IP Confinado</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Introducao_aos_conceitos_de_programabilidade_de_infraestruturas_de_redes&diff=2514 2020-06-14T22:47:34Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Este artigo apresentará fundamentos importantes acerca do gerenciamento de redes, em especial a disciplina de configurações, e pavimentará a sua jornada, caro leitor da Wiki do BPF, para as questões de programabilidade de infraestruturas de redes e com foco aos ambientes de ISP. Este é mais um daqueles artigos que publico na Wiki do BPF onde a principal intenção ou motivação é '''''ensinar, educar, e capacitar''''' e, portanto, o artigo não vai direto ao ponto: conto uma história primeiro, volto no tempo para mostrar algumas coisas e eventos importantes e, lá para o final, é que comento com mais propriedade sobre os aspectos de programabilidade pretendidos por este artigo. Esta abordagem mais didática poderá ser melhor apreciada por leitores mais &quot;leigos&quot;.<br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo!<br /> [[Arquivo:Bpf-prog-cover.png|centro|miniaturadaimagem|800x800px|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes: comparando a rede ideal versus os modelos tradicionais]]<br /> <br /> === Pré-requisitos ===<br /> A leitura deste artigo fará muito mais sentido caso você reúna determinados pré-requisitos em termos de conhecimentos técnicos. Recomendo que certifique-se de possuir os conhecimentos equivalentes aos temas discutidos nos seguintes artigos, já publicados na Wiki do Brasil Peering Forum (BPF).<br /> * [[Fundamentos de Roteamento para Provedores]]<br /> * [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> * [[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> <br /> === Precisamos evoluir: continuar configurando e operando ambientes de redes complexos da mesma forma em que temos feito por décadas, pra que? ===<br /> Você já parou para pensar que, toda a vez que você recebe uma solicitação para a ativação de serviço, uma série de cuidados precisam ser observados? Você precisa gerir a demanda através de várias ações estritamente manuais, incluindo a projeção da mudança, produção do roteiro de configurações, classificação dos impactos, revisão de capacidades, reserva de recursos, a efetiva aplicação de blocos inteiros de configurações sobre um ou mais elementos de rede, além de fazer o arquivamento daquela mudança, acompanhamento, monitoramento e, eventualmente, o suporte. Você provavelmente deve ter uma noção que há muitos riscos e complicações durante todo este processo, mas que, de certa forma, estamos mais que habituados a isso. É uma questão cultural, algo que nos acompanha por muitos e muitos anos. Quanto a esta evolução proposta, eu passarei a fornecer algumas boas justificativas para que você possa compreender melhor a minha visão, e também o direcionamento de mercado, sobre esta redefinição de nossas práticas operacionais:<br /> {| class=&quot;wikitable&quot;<br /> |+Como a programabilidade de redes poderá ajudar a superar os principais desafios dos modelos de operação tradicionais<br /> !Situação<br /> !Descrição<br /> |-<br /> |'''Atenuação da complexidade operacional'''<br /> |Embora não seja exatamente a realidade de todas as empresas, talvez nem da sua, neste caso, o fato é que há muitos ambientes computacionais verdadeiramente complexos, repletos de muitos componentes.<br /> &quot;Abarrotados&quot; de equipamentos tais como roteadores, switches, firewalls, balanceadores de carga, filtros de conteúdo, appliances de segurança, servidores, storage, além de bancos de dados, aplicações, desktops, unidades de vídeo-conferência, sistemas de comunicação multimídia diversos, controladores WiFi, pontos de acesso, etc.!<br /> <br /> Cada um destes exigindo configurações, muitas! E todos estes componentes e dispositivos necessitando se comunicar através de uma diversidade muito grande de tecnologias, incluindo protocolos, serviços de infraestrutura e de transporte, computação, storage, aplicação e afins.<br /> <br /> Na grande maioria das empresas as manobras de configuração são conduzidas por processos completamente manuais, mesmo que, em alguns ou muitos casos, de forma organizada e pautada, ou seja, seguindo processos, boas práticas, modelos funcionais, documentações, etc.<br /> <br /> No entanto, na medida em que estas redes crescem, seja em quantidades de desktops/usuários ou de servidores, ou, principalmente, a diversidade de soluções tecnológicas presentes, todo o ambiente começa a ficar realmente bem mais complicado para se manter.<br /> <br /> Toda esta complexidade operacional pode ser brutalmente atenuada com tecnologias de programabilidade de infraestruturas.<br /> |-<br /> |'''Redução massiva do tempo de provisionamento de serviços'''<br /> |Uma realidade para praticamente qualquer empresa, mas, certamente, um dos principais indicadores de performance do negócio dos provedores de acesso à Internet e também dos provedores de conteúdo: o tempo requerido para provisionar e ativar um serviço contratado por um cliente.<br /> Geralmente todo um fluxo de trabalho precisa ser cumprido para que a demanda possa ser devidamente compreendida, e uma cadeia de aprovação da mudança é estabelecida para que times específicos produzam os roteiros de configurações necessários, e isto tende a ser executado em horários específicos, ou seja, sempre levando um longo tempo entre a iniciação, ou solicitação da demanda, e a sua execução/conclusão.<br /> <br /> Infraestruturas ágeis, que contam com amplas capacidades de orquestração e automação, conseguem provisionar serviços muito mais rapidamente do que estes ambientes tradicionais e estáticos, podendo ser até mesmo instantaneamente, dependendo dos processos que estiverem estabelecidos pela organização.<br /> |-<br /> |'''Redução drástica dos esforços operacionais associados às tarefas de configuração e provisionamento'''<br /> |Não é simplesmente uma questão de &quot;configurar alguma coisa na rede&quot;, mas sim de compreender o que precisa ser configurado, quais recursos ou funcionalidades, quais elementos, dispositivos e sistemas precisam ser modificados para a viabilidade da ativação daquele serviço, interpretar características de sintaxe e semântica, compatibilidades, integração; se há ou não um padrão ou modelo homologado para cumprir com estas tarefas de provisionamento, etc.<br /> Isto sem dúvida alguma exige mais que apenas esforço, tempo ou prazo: exige conhecimento; o domínio destas tecnologias, e a compreensão das relações e interdependências de cada caso, o que acentua ainda mais a necessidade por maior conhecimento e domínio das tecnologias utilizadas.<br /> <br /> E todo o trabalho executado nestas manobras desprende algum esforço, pouco ou muito, não me atreverei a mensurar por aqui, pois há casos e casos.<br /> <br /> Indiscutivelmente redes programáveis nos moldes sugeridos por este artigo reduzem em pelo menos 90% dos esforços operacionais que normalmente são exigidos ou desprendidos em ambientes de redes tradicionais.<br /> |-<br /> |'''Redução drástica dos riscos de negócios associados aos possíveis e frequentes downtimes'''<br /> |Como se não bastasse a complexidade e esforços operacionais, além do tempo/prazo, temos ainda que nos preocupar com possíveis impactos que são frequentemente decorrentes de erros provocados por falha humana durante as ações de configuração e provisionamento de serviços.<br /> É verdade que muitos destes riscos podem ser reduzidos com o auxílio de processos e práticas consistentes de gestão de mudanças (vide recomendações do COBIT/ITIL).<br /> <br /> Mas nada superará a confiabilidade de um provisionamento executado por meios de tecnologias e ferramentas de orquestração e automação, sendo isto um dos maiores atrativos da programabilidade de infraestruturas.<br /> |-<br /> |'''Maior agilidade e elasticidade para a disponibilidade e oferta de soluções mais complexas sobre a infraestrutura'''<br /> |O tempo que se gasta &quot;remando contra a maré&quot; e conduzindo extensas e monótonas configurações manuais pode muito bem ser empregado para &quot;destravar&quot; muitas oportunidades para a incorporação de soluções mais atraentes e de alto valor agregado para os seus clientes.<br /> A combinação de múltiplas ofertas de produtos e serviços para os clientes de um ISP frequentemente exige a integração de sofisticadas e complexas plataformas e soluções tecnológicas, o que tende a impulsionar ainda mais os casos citados anteriormente nesta tabela, ou seja, maior complexidade, maior esforço, maiores custos operacionais, maior prazo para go-to-market, maiores riscos de indisponibilidades, etc.<br /> <br /> Quando pensamos em infraestruturas altamente programáveis, conseguimos estender as capacidades de orquestração e automação para contemplar, além da rede, a parte de computação, incluindo servidores, storage e aplicações, e isto promove um salto tecnológico tremendo para os anseios de competitividade e atratividade da empresa.<br /> |}<br /> <br /> === Prepare-se para tornar-se um NetDevOps! ===<br /> Eu explico. Há uma diferença muito grande entre o dinamismo presente nos ambientes computacionais envolvendo servidores virtuais, containers, aplicações, e a infraestrutura de redes. As redes que costumamos ver por aí geralmente possuem características operacionais muito mais estáticas do que esta área de servidores, desenvolvimento de software e aplicações, mas não em todos os casos, claro. Para fornecer um exemplo, por anos temos conseguido disponibilizar workloads inteiros em ambientes virtualizados em questão de minutos e com apenas alguns cliques, e, enquanto isso, as manobras necessárias sobre a infraestrutura da rede para acomodarmos estes workloads são geralmente feitas seguindo modelos estáticos de configuração, repletos de procedimentos manuais, caixa por caixa, CLI por CLI. Obviamente, há exceções à regra. Mas dá tranquilamente para generalizar desta forma.<br /> <br /> Toda a vez que novas aplicações ou serviços são disponibilizadas para usuários internos e/ou externos, o que não é muito complicado de fazermos em função da versatilidade das ferramentas usadas hoje em dia, a rede precisa acompanhar o roteiro e &quot;acomodar, compatibilizar e viabilizar&quot; aquele serviço, ou seja, sofrer as configurações necessárias incluindo a VLAN, entroncamento da VLAN, roteamento IP, ACL, QoS e o que mais tiver que ser feito. Pois bem, novamente, a diferença é que na camada de computação as coisas são usualmente mais dinâmicas, enquanto a rede, na maioria das empresas, ainda precisa ser tratada de forma bem estática e manual.<br /> <br /> Você provavelmente já ouviu falar de ''DevOps'', mas, caso não saiba, o ''DevOps'' pode ser tratado como uma cultura de desenvolvimento de aplicações de TI, uma revolução na questão de processos de desenvolvimento de software, fazendo com que equipes de desenvolvimento (Dev) e equipes de operações (Ops) trabalhem juntas e em regime de estreita colaboração. Consequentemente, a adoção ágil por meios de implementação contínua e melhorias da infraestrutura de desenvolvimento promove uma oferta bem mais acelerada dos serviços de TI.<br /> <br /> Nesta seara de ''DevOps'' é que notamos um monte de coisas relacionadas ao ''Agile'', automação por pipelines de CI/CD (''Continuous Integration / Continuous Delivery'') e CI/CD/CD (''Continuous Integration/Continuous Delivery/Continuous Deployment''), coisas que provavelmente você já ouviu falar por aí. Pois, então, note que normalmente há um desvio muito expressivo entre estas práticas de agilidade dos times de desenvolvimento de software e as práticas adotadas pelos times de engenharia e operação de redes. Para exemplificar aqui, quaisquer alterações inadequadas que por ventura forem realizadas sobre as configurações de equipamentos de rede podem resultar em muitos problemas desnecessários, afetando negativamente aplicações e times de desenvolvimento, e tornando a situação mais complexa para estas equipes poderem lidar. E é a partir daí que os pipelines citados, ''Agile'', ''DevOps'', CI/CD e testes de unidade automatizados ajudam a superar esses desafios. O que até então era uma exclusividade dos times de desenvolvimento de software passou a ser portado para atender, também, os times responsáveis pela engenharia e operação de redes. E aí nasceu um novo paradigma chamado '''''NetDevOps'''''.<br /> <br /> Em curtas palavras, o '''''NetDevOps''''' pode ser definido como uma interseção de ''Rede'' e ''DevOps'', por meios de uma comunicação aberta e feita através da automação, e usando princípios de '''''Infraestrutura como Código''''' (IaC) ou &quot;''Infrastructure as Code''&quot;.<br /> <br /> Caso você ainda não faça a menor idéia do que eu esteja dissertando por aqui, quem sabe uma representação visual destes conceitos não vá esclarecer melhor?<br /> [[Arquivo:Bpf-prog-agiledevops.png|centro|miniaturadaimagem|800x800px|Agile, DevOps (Fonte: Cisco Live)]]<br /> Ao trazermos para os times de engenharia e operações de redes estas consagradas culturas e práticas utilizadas pelos times de desenvolvimento de software e, ao portarmos as nossas habituais tarefas de configuração de dispositivos - normalmente feitos, conforme já comentado, por CLI ou interface GUI/WebUI - para ''&lt;u&gt;código&lt;/u&gt;'', conseguimos viabilizar excepcionais capacidades de automação e orquestração, que são responsáveis por fornecer as almejadas agilidade, eficiência e confiabilidade para lidarmos com maestria com os serviços de TI em ambientes críticos. Consequentemente, conseguimos eliminar as barreiras entre os times de TI da organização (desenvolvimento de software, servidores, bancos de dados, redes), promover maior fluidez para a entrega de serviços de TI, e tudo isto exigindo muito menos prazo e esforço para a entrega destes serviços, e sem contar com a maior confiabilidade das operações, redução de riscos e impactos para os negócios, e tão cobiçada redução de custos.<br /> <br /> Para preparar o seu prato de '''''NetDevOps''''', misture numa panela o Agile, CI/CD, infraestrutura como código (IaC), ferramentas e soluções de automação e orquestração, mas não se esqueça de alguns ingredientes consagrados (boas práticas do COBIT/ITIL, lifecycle e outros frameworks funcionais necessários), tempere tudo com &quot;Sazón&quot;, mexa bem, e estará pronto para servir. Você terá a oportunidade de experimentar um universo completamente novo de programabilidade de infraestruturas de redes e usufruirá de resultados indiscutivelmente melhores.<br /> <br /> ==== Por que não usar ambos o CLI com scripting e o protocolo SNMP para realizar as configurações da rede? ====<br /> Antes que você me faça essa pergunta, permita-me antecipar os seguintes pontos:<br /> * O scripting por CLI requer um bom esforço para comunicar particularidades de sintaxes e semânticas em ambientes heterogêneos, e a revisão e manutenção destes scripts é um trabalho igualmente estático e manual.<br /> ** Não que scripts sejam ruins, não é isso! Mas a proposta do artigo aqui é tratamos da evolução de certos procedimentos operacionais, certo?<br /> * O scripting por CLI peca muito por outra razão até mais importante ainda: a ausência de gerenciamento de transações.<br /> ** Quando você for provisionar, quais scripts você precisa invocar, quais equipamentos estes scripts acionarão, como você tratará as diferentes sintaxes?<br /> ** Apesar de você estar usando um script, ou vários, todo o trabalho tende a ser manual neste sentido, quando indicando quais equipamentos precisarão receber e quais configurações,<br /> ** E se alguma coisa der errado, qualquer coisa, inclusive algo que pode parar a sua rede ou provocar distúrbios graves, como os seus scripts lidarão com isso? <br /> ** Esta ausência de gerenciamento de transações dificulta muito contarmos com um controle decente de revisões de configuração, auditoria de quem fez, quando e onde, o que de fato foi modificado nestas configurações, e não possui facilidades de ''rollback'', para simplificar aqui o meu ponto de vista.<br /> * O scripting por CLI também carece de um gerenciamento estruturado de falhas que por ventura possam acontecer quando aplicando os comandos na CLI dos equipamentos, seja por questões de sintaxe, semântica, ou outros. <br /> ** Isto é muito fácil de acontecer principalmente após a atualização de software dos equipamento, e o seu script muito provavelmente não saberá lidar com isto e não saberá desfazer a configuração parcial que foi implementada, o que poderá ser desastroso em alguns casos.<br /> * O scripting por CLI apresenta um desafio relacionado as eventuais mudanças nas sintaxes do software de um determinado equipamento, o que poderá ser preocupante, agora imagine isto em um ambiente multivendor.<br /> ** Você terá dificuldades em manter e certificar-se que seus scripts invoquem as sintaxes corretas para todos os equipamentos e em suas respectivas versões de software.<br /> * O protocolo SNMP, se comparado ao CLI, com ou sem scripting, é ainda mais deficiente: embora o SNMP tenha sido projetado para realizar o gerenciamento com suporte à escrita (communities com permissão &quot;Write&quot;), ele só é eficiente mesmo para o gerenciamento de falhas e para o gerenciamento de desempenho. Para o gerenciamento de configurações, é um tanto desastroso.<br /> * O protocolo SNMP não fornece capacidades legítimas de auto-descoberta capazes de localizar as MIBs corretas dos dispositivos gerenciados, e isto significa que você, o administrador da rede, é quem terá o trabalho manual de identificar quais MIBs são compatíveis e para quais finalidades, e fazendo isso para todo o tipo de equipamento da sua rede.<br /> ** Se para o gerenciamento de falhas e de desempenho isto já dá um trabalho, você talvez não queira imaginar o quanto isto é custoso para o gerenciamento de configurações.<br /> * As MIBs do protocolo SNMP frequentemente não possuem os OIDs que necessitamos para configurarmos um monte de coisas ou recursos nos equipamentos da rede.<br /> * Esta complexidade toda e várias limitações são os principais motivos pelos quais os administradores de redes terem abandonado por completo o SNMP para fins de gerenciamento de configurações.<br /> * O protocolo SNMP também não é diferente da CLI no que diz respeito à ausência de gerenciamento de transações. Logo, portanto, as mesmas situações discutidas no caso do CLI também são válidas para o SNMP.<br /> * O protocolo SNMP é transportado pelo UDP, e isto significa que está suscetível a perda de mensagens na rede. Dependendo do caso, operações parciais podem ser implementadas, deixando um lastro de manobras incompletas durante um provisionamento de serviços, o que não seria nada bom para os nossos propósitos de consistência de configurações e disponibilidade da rede.<br /> Sobre o meme a seguir: não vista a carapuça!<br /> [[Arquivo:Bpf-prog-cover2.png|centro|miniaturadaimagem|800x800px|&quot;Deuzulivre&quot;!]]<br /> <br /> === Revisão dos principais conceitos e componentes de uma infraestrutura de redes Metro e IP ===<br /> Para falarmos melhor sobre programabilidade, automação e orquestração, especialmente se você, leitor, estiver começando nesta área de redes, talvez seja prudente regredirmos um tanto e esmiuçarmos como as coisas acontecem de fato no modelo tradicional de operação de redes. Pensando assim, que tal fazermos uma boa revisão sobre os principais componentes e conceitos presentes em uma infraestrutura de redes? Ao término do artigo, talvez esta seção tenha sido bastante útil para você entender melhor as complicações no que diz respeito à manutenção das infraestruturas de redes, e como as tecnologias e ferramentas de programabilidade poderão drasticamente atenuar os esforços, prazos, complexidades e custos operacionais.<br /> <br /> ==== Dispositivos de rede ====<br /> Em uma rede de ambiente ISP (aka &quot;''service provider''&quot;) é comum encontrarmos os seguintes tipos de equipamentos ou elementos ativos, que são referências aos dispositivos de rede:<br /> * '''Roteadores:''' devidamente categorizados por suas funções e missões, em especial em alinhamento com uma infraestrutura de redes hierárquica, modular e estruturada, ou seja roteadores de Acesso, Pré-Agregação, Agregação, Core, Borda de Serviços e Borda de Internet, e também os roteadores de clientes, sejam estes de propriedade do ISP (comodato) ou mantidos e gerenciados pelo próprio cliente. Aqui entram os conhecidos termos '''''CE''''' ou '''''CPE''''' (''Customer Premises Equipment''), '''''PE''''' (''Provider Edge''), '''''P''''' (''Provider''), e cada um destes, além de seu respectivo posicionamento na hierarquia topológica física e lógica da rede, desempenhando funções tais como ''LSR'' (''Label Switch Router''), ''LER'' (''Label Edge Router''), ''BNG'' (''Broadband Network Gateway''), dentre outros casos.<br /> * '''Switches:''' praticamente a mesma coisa com relação aos roteadores no que diz respeito ao seus posicionamentos em uma rede, hierarquia e afins. Podendo ser elementos ativos desempenhando funções de encaminhamento de dados puramente de Camada 2 (L2), neste caso o processamento dos quadros (''frames''), ou multicamadas (L3), neste caso o processamento de pacotes, em ambientes Ethernet ou Ethernet + IP nativos, ou ainda em ambientes MPLS.<br /> * '''GPON''': sumarizando aqui os dispositivos desta infraestrutura, incluindo '''''OLT''''' (''Optical Line Terminal''), '''''ONU''''' (''Optical Network Unit''), '''''ONT''''' (''Optical Network Terminal''), e, por que não, toda a parte passiva (leia-se: não ativa) da infraestrutura, denominada ''Optical Distribution Network'' (ODN), e que abrange as fibras ópticas e passivos ópticos, como splitters, conectores, cordões, extensões, caixas de emenda e terminação.<br /> [[Arquivo:Bpf-prog-routers.jpg|centro|miniaturadaimagem|800x800px|Dispositivos de rede Metro Ethernet, IP, MPLS: roteadores e switches]]<br /> <br /> ==== Protocolos e serviços de infraestruturas de redes ====<br /> Uma coisa são os dispositivos de redes mencionados anteriormente, outra coisa são as tecnologias (embarcadas nestes dispositivos) que viabilizam o funcionamento de uma rede, em especial no que diz respeito à comunicação e convergência necessária entre os elementos ativos para o transporte efetivo do tráfego da rede e dos serviços contratados por seus usuários. Nem de longe atreverei-me a listar tudo, pois isto seria completamente inviável! Elencarei apenas alguns exemplos, pois uma listagem completa mencionando todas as tecnologias produziria um artigo quilométrico!<br /> <br /> O arranjo destas tecnologias, devidamente organizadas em suas respectivas categorias funcionais, é o que costumo chamar de &quot;'''''Salada de Tecnologias'''''&quot;!<br /> * '''Protocolos e serviços de camada 2 (L2):''' como menção ao modelo de referência OSI (RM-OSI) ou ao modelo de referência TCP/IP, são tecnologias primariamente envolvidas com a construção e manutenção de uma infraestrutura redundante (com foco na maior disponibilidade) isenta de ''bridging loops'', e com capacidades de recuperação de falhas envolvendo enlaces de transmissão ou dos próprios elementos de rede. Exemplos de tecnologias assim: ''Spanning Tree Protocol'' (e suas variações, 802.1d ('''''STP'''''), 802.1w ('''''RSTP'''''), 802.1s ('''''MSTP'''''), 802.1aq (''Shortest Path Bridging'' ('''''SPB'''''), e revisões incorporadas ao '''''802.1Q-2014''''', ''Resilient Ethernet Protocol'' ('''''REP''''', proprietário), ''Ethernet Automatic Protection Switching'' ('''''EAPS''''', proprietário), '''''G.8032''''' (''Ethernet Ring Protection (ERP) protocol''), coexistência de ''Inter-Chassis Communication Protocol'' ('''''ICCP''''') e STP, etc. E, claro, não poderia deixar de mencionar aqui o mais óbvio, que são tecnologias mais básicas e elementares tais como o próprio endereçamento físico (''Media Access Control'' ('''''MAC''''')) dos dispositivos, ''Virtual LAN'' ('''''VLAN'''''), entroncamento '''''802.1q''''' e '''''802.1ad''''' (''Q-in-Q''), operações flexíveis com tags de VLAN (''Flexible VLAN Tags'', ''Ethernet Flow Point ('''EFP''')''), circuitos Ethernet Virtuais (''Ethernet Virtual Circuit'' ('''''EVC''')''), etc. E isto focando apenas no óbvio, pois há uma gama muito grande de tecnologias e serviços que implementam funções ou que atuam na camada 2. E, para concluir, '''''L2VPN''''' (VPLS, VPWS, EVPN) também são exemplos de tecnologias para o transporte de tráfego/serviços L2 em uma rede MPLS (VPLS/VPWS/EVPN) ou VxLAN (''EVPN''). ''Generic Routing Encapsulation'' ('''''GRE'''''), ''Layer 2 Tunneling Protocol'' ('''''L2TP'''''), ''Layer 2 Protocol Tunneling'' ('''''L2PT'''''), ''Point-to-Point Tunneling Protocol'' ('''''PPTP''''') são outros exemplos clássicos e que empregam conceitos de túneis.<br /> * '''Protocolos e serviços de camada 3 (L3):''' também em alinhamento ao RM-OSI, são tecnologias que tem como propósito a construção e manutenção de uma rede IP &quot;roteada&quot;, convergida e isenta de ''routing loops''. Enquadram-se aqui o endereçamento '''''IPv4''''' e '''''IPv6''''', protocolos de roteamento dinâmicos (ex: '''''OSPF''''', '''''IS-IS''''', '''''EIGRP''''', '''''BGP''''', '''''RIPv2''''' para IPv4, e '''''RIPng''''', '''''OSPFv3''''', '''''IS-IS for IPv6''''', '''''EIGRP for IPv6''''', '''''BGP''''' para o IPv6), além de rotas conectadas, rotas estáticas, serviços de roteamento por políticas ('''''PBR''''', ABF ou nome similar usado pelo seu fabricante de equipamento). Enquadram-se também, à título de serviços L3, mas com algumas destas tecnologias implementando funções também em outras camadas, os seguintes: ''Network Address Translation'' ('''''NAT'''''), ''Carrier Grade NAT'' ('''''CGN'''''), ''Broadband Network Gateway'' ('''''BNG''''', como concentrador PPPoE e/ou IPoE).<br /> * '''Protocolos e serviços orientados à confiabilidade, resiliência e disponibilidade:''' compreenda estes como serviços periféricos e pensados para melhorarmos a confiabilidade geral da infraestrutura, seja em cenários L2 ou L3, ou ainda ambos. Exemplos de tecnologias que enquadram-se aqui temos o ''Unidirectional Link Detection'' ('''''UDLD'''''), ''Bidirectional Forwarding Detection'' ('''''BFD'''''), ''In-Service Software Upgrade'' ('''''ISSU'''''), ''Online Insertion and Removal'' ('''''OIR'''''), ''Stateful Switchover'' ('''''SSO'''''), ''Nonstop Forwarding'' ('''''NSF''''') ou ''Graceful Restart'' ('''''GR'''''), ''Non Stop Routing'' ('''''NSR'''''), ''MPLS Traffic Engineering Fast Reroute'' ('''''FRR'''''), ''Topology Independent LFA'' ('''''TI-LFA''''') e RLFA, ''Segment Routing TI-LFA'' ('''''SRTILFA'''''), ''Link Aggregation Control Protocol'' ('''''LACP'''''), enfim, são exemplos clássicos. Outros exemplos aqui incluem os protocolos de resiliência de primeiro salto ou de default gateway, conhecidos por FHRP (''First Hop Redundancy Protocol''), tais como o '''''HSRP''''' (''Hot Standby Router Protocol''), '''''VRRP''''' (''Virtual Router Redundancy Protocol'') e '''''GLBP''''' (''Gateway Load Balancing Protocol''). Isto para não mencionar os mecanismos periféricos presentes em outros protocolos já apresentados, como, por exemplo, o '''''OSPF LSA e SPF Throttling''''', '''''BGP Prefix Independent Convergence (PIC)''''', etc.<br /> * '''Protocolos e serviços de suporte à infraestrutura:''' enquadram-se aqui protocolos e serviços incluindo o '''''PPPoE''''' (''Point-to-Point Protocol over Ethernet''), '''''IPoE''''' (''Internet Protocol over Ethernet''), '''''DHCP''''' (''Dynamic Host Configuration Protocol''), '''''DNS''''' (''Domain Name System)'', '''AAA''' (''Authentication, Authorization, Accounting''), '''''RADIUS''''' (''Remote Authentication Dial In User Service''), '''''TACACS+''''' (''Terminal Access Controller Access-Control System''), '''''Diameter''''', '''''NTP''''' (''Network Time Protocol''), '''''PTP''''' (''Precision Time Protocol''), '''''SyncE''''' (''Synchronous Ethernet''), e tantos outros. As tecnologias com foco no ''Quality of Service'' ('''''QoS''''') também podem ser descritas aqui.<br /> * '''''Protocolos e serviços de gerenciamento:''''' figuram aqui, dentre tantos, o ''Simple Network Management Protocol'' ('''''SNMP'''''), ''Remote Network MONitoring'' ('''''RMON''''') ''MIB'', '''''Netflow''''', ''Internet Protocol Flow Information Export'' ('''''IPFIX'''''), ''Telnet'', ''Secure Shell'' ('''''SSH'''''), ''SSH File Transfer Protocol'' ('''''SFTP'''''), ''Operations, Administration and Maintenance'' ('''OAM''') incluindo ''Ethernet OAM Link Fault Management'' ('''''EOAM LFM'''''), ''802.1ag Connectivity Fault Management'' ('''''CFM'''''), ''Ethernet Local Management Interface'' ('''''E-LMI'''''), ''Ethernet Performance Management'', '''''MPLS OAM'''''; ''Network Configuration'' e modelos Yang ('''''NETCONF/Yang'''''), interface ''RESTful'' para a modelagem ''Yang'' com '''''RESTCONF''''', ''Technical Report 069'' ('''''TR-69''''') e substitutos, dentre tantos outros protocolos, serviços e procedimentos.<br /> * '''Protocolos e serviços de segurança da infraestrutura:''' há tantos casos para citar aqui, tentarei ser bem prático. '''''Port Security''''', '''''802.1X IBNS''''', '''''MACsec''''', ''Network Admission Control'' ('''''NAC'''''), '''''Private VLAN''''', ''Dynamic ARP Inspection'' ('''''DAI'''''), '''''DHCP Snooping''''', ''IP Source Guard'' ('''''IPSG'''''), '''''Root Guard''''', '''''BPDU Guard''''', '''''BPDU Filtering''''', ''mecanismos de autenticação dos protocolos de roteamento'', ''mecanismos de autenticação de protocolos MPLS'' (LDP e RSVP-TE), ''filtros e políticas de roteamento'', '''''BGP Flowspec''''', ''Remotely Triggered Black Hole'' ('''''RTBH'''''), '''''stateful packet filtering''''', ''BGP Resource Public Key Infrastructure'' ('''''RPKI'''''), ''Control Plane Policing'' ('''''CoPP/dCoPP'''''), ''Broadcast, Unicast and Multicast'' (BUM) '''''Storm Control''''', ''limitação de prefixos mantidos em tabelas de roteamento'', ''Unicast Reverse Path Forwarding'' ('''''uRPF'''''), e muitos outros. E isto com relação às tecnologias apenas, sem considerar os ''appliances'' (dispositivos) de segurança que embarcam estas tecnologias e serviços, tais como firewalls, UTMs, etc.<br /> [[Arquivo:Bpf-prog-tecnologias-isp.png|centro|miniaturadaimagem|1235x1235px|Que &quot;salada&quot; de tecnologias! É tanta coisa que temos que nos preocupar em fazer funcionar corretamente e conforme as boas práticas!]]<br /> <br /> ==== Sistemas e serviços de suporte à infraestrutura ====<br /> A lista de situações aqui é mais simples, mas não menos complexa:<br /> * Sistemas de Suporte ao Negócio ('''''BSS''''')<br /> * Sistemas de Suporte à Operação ('''''OSS''''')<br /> * Serviços de Diretório (ex: '''''LDAP''''', '''''Active Directory''''')<br /> * Infraestrutura ''Public Key Infrastructure'' ('''''PKI''''')<br /> * Sistemas específicos de serviços de segurança ('''''RADIUS''''', '''''TACACS+''''', '''''AAA''''', '''''NAC''''' e afins)<br /> * Sistema de ''IP Address Management'' ('''''IPAM''''')<br /> * Sistemas específicos para fins de gerenciamento de elementos e de infraestrutura ('''''EMS''''' e '''''NMS'''''), com baixa ou parcial aderência aos padrões OSS.<br /> * Etc.<br /> [[Arquivo:IBM CDOMS-00.png|centro|miniaturadaimagem|1024x1024px|Exemplo de integrações de sistemas OSS e BSS, demonstrando a solução IBM Catalog Driven Order Management Solution. Note o &quot;SID&quot;, um dos frameworks do TM Forum Frameworx!]]<br /> OBS: no segmento de ISPs regionais de pequeno e médio portes é onde compreendemos, também, uma diferença bastante acentuada entre os padrões de sistemas empregados por estes quando comparados aos sistemas de gestão operacional e de negócios dos operadores de redes &quot;grandes&quot;. Nos ISPs regionais, é muito mais comum o uso de sistemas para missões bem específicas e que operam de forma completamente independente e com nenhuma ou mínima troca ou compartilhamento de dados entre si, mesmo que funcionais para a realidade desta empresas. No entanto, a ausência das devidas e desejadas integrações entre estes sistemas (vide ''Frameworx'' (''eTOM BPF, SID, TAM, TNA'')) tende a dificultar a adoção de capacidades de orquestração mais completas para o provisionamento de serviços fim a fim.<br /> <br /> ==== Áreas sistêmicas das arquiteturas de roteadores e switches ====<br /> Tantos destes protocolos e serviços de rede precisam ser selecionados e configurados por você, um por um, e conforme diretivas do seu projeto técnico (ex: configurações homologadas, boas práticas, validação de sintaxe e semântica, etc.) para que possam convergir e fornecer o transporte e a efetiva viabilidade dos serviços e produtos contratados pelos clientes. Para fazer toda a coisa acontecer, há um determinado arranjo de dependências entre as tecnologias necessárias onde, em muitos casos, para que uma determinada tecnologia que você configurou possa funcionar, são necessários o suporte e o funcionamento de outras tecnologias e serviços, as quais, por sua vez, precisarão ser também pensadas, projetadas, e configuradas por... você! Para exemplificar aqui, para que o BGP de seu AS possa operar é necessário o roteamento recursivo para o transporte das sessões IBGP e a devida resolução do atributo NEXT_HOP das rotas mantidas pelo BGP, e isto significa que você precisará adotar um protocolo de roteamento interior (IGP), provavelmente o OSPF aqui, o qual, por sua vez, depende de endereçamento IP, definição das tecnologias de enlace (VLANs, entroncamentos, etc.) e das tecnologias de transmissão (L1). Ou seja, uma coisa depende da outra.<br /> <br /> Em particular, roteadores e switches em uma rede mantém áreas sistêmicas e funcionais para os propósitos de conectividade e de serviços:<br /> * '''Plano de Controle:''' área sistêmica responsável por hospedar protocolos que forneçam entendimento e convergência para fins de encaminhamento de tráfego L2 (ex: STP, REP, EAPS...) e L3 (ex: OSPF, IS-IS, BGP, etc.), e até mesmo &quot;L2.5&quot; (ex: MPLS). Não somente os protocolos são mantidos nesta área, mas também as suas respectivas estruturas de dados, tais como o ''Link-State Database'' (LSDB) do OSPF, o ''Label Information Base'' (LIB) do MPLS LDP, a ''BGP Table'' do BGP, e a própria tabela de roteamento IP (''Routing Information Base'' ou RIB) do roteador, protocolos adicionais tipo o ''PCEP'', etc.<br /> * '''Plano de Dados:''' área sistêmica responsável por hospedar as estruturas de dados especificamente orientadas ao processamento e efetivo encaminhamento de pacotes, tais como a ''Forwarding Information Base'' (FIB) ou ''Forwarding Table'', ''Label Forwarding Information Table'' (LFIB), ''Adjacency Table'' (ADJ) ou similar, isto no caso dos roteadores, e ''Content Addressable Memory'' (CAM) ou ''MAC Table'', no caso dos switches, além de outras estruturas de dados que possam servir para funções adicionais da cadeia de processamento de pacotes, geralmente organizadas em TCAMs (''Ternary Content Addressable Memory''), para o acionamento de manipulações de cabeçalhos, QoS, ACL, etc. <br /> * '''Plano de Gerenciamento:''' responsável por hospedar e manter os serviços de gerenciamento do dispositivo, tais como ''Telnet'', ''SSH'', ''SNMP'', ''NETCONF'', ''HTTP server'', ''Syslog'', ''NTP'', etc.<br /> * '''Plano de Serviços:''' responsável por manter processos relacionados ao ''RADIUS'', ''TACACS+'', ''PPPoE'', ''IPoE'', ''IPsec'', ''NAT'', ''QoS'', ''Stateful Firewall'', ''AVC'', etc.<br /> É importante salientar que o modelo de computação em rede tradicional é completamente distribuído, ou seja, que estas áreas sistêmicas supracitadas são independentes e localmente significantes para cada dispositivo. Isto significa que o estado de informação de cada processo de software referente a um destes protocolos e serviços é mantido por cada equipamento, independentemente, podendo haver, em algumas situações, alguma integração entre equipamentos distintos para um determinado componente. <br /> <br /> ==== Projeto técnico compatível com o plano de negócios ====<br /> Você deve ter notado a quantidade brutal de componentes e recursos tecnológicos listados até agora! No que tange aos tipos de equipamentos que você precisa utilizar, como deverão ser feitas as conexões físicas e lógicas, quais protocolos e serviços deverão ser projetados e empregados (configurados, ativados...), e tudo mais, enfim, isto dependerá muito de como o seu projeto técnico for construído, e este projeto precisa &quot;casar&quot; com o seu plano de negócios. A dissertação disto está fora do escopo deste artigo e por razões bem óbvias, pois seria um baita ''off-topic''. Isto será tema para futuros artigos aqui na Wiki do BPF. Todavia, caso tenha curiosidade de saber um pouco mais sobre o tema, talvez estes dois vídeos possam ser úteis neste sentido, pois, neles, tento apresentar de forma bem objetiva estes conceitos:<br /> * [https://youtu.be/8yAGzNuerFg &lt;nowiki&gt;[BPF] Conceitos e análises de investimentos tecnológicos para o ISP&lt;/nowiki&gt;]<br /> * [https://youtu.be/rnABNk26pZk &lt;nowiki&gt;[BPF] Caracterização das funcionalidades e recursos para projetos de redes no ISP&lt;/nowiki&gt;]<br /> É importante salientar que há muita redundância entre as tecnologias citadas previamente, particularmente no que concerne às aplicabilidades, cenários e casos de uso. Por exemplo, você não irá realmente rodar o protocolo de roteamento EIGRP no backbone do seu provedor, pois será óbvia e natural a escolha pelo protocolo de roteamento OSPF (as razões quanto a isto podem ser estudadas no artigo [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]), embora ambos sejam protocolos de roteamento, e muito bons por sinal. Assim como, caso a sua rede de Acesso seja L2, será muito provável que você vá optar por tecnologias de resiliência Ethernet mais sofisticadas, preferindo o G.8032 ou EAPS, ao invés do protocolo Spanning Tree, mesmo que ambos sejam protocolos de resiliência destinados ao mesmo propósito (vide artigo [[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]] para saber o por que). Assim como você optará pelo IPoE ou PPPoE, ou ainda rodando os dois serviços simultaneamente por um tempo em caráter de transição tecnológica, mas, no final das contas, é provável que você vá manter apenas o IPoE, embora ambos PPPoE e IPoE tenham como proposta a mesma missão (apenas a cumprem de formas distintas). Quanto aos protocolos FHRP, é bem provável que você vá optar pelo VRRP (até mesmo pela provável natureza ''multivendor'' da sua rede), e não pelo HSRP, por se tratar de uma tecnologia proprietária. A maioria absoluta das instalações de rede de Internet residencial emprega o protocolo/serviço RADIUS como um dos componentes de integração requeridos, mas a tendência é que, com o passar do tempo, vejamos cada vez mais instalações operando com o protocolo Diameter. Enfim, acho que você conseguiu me entender aqui.<br /> <br /> Para tudo isto que escrevi acima, o que escolher, o que adotar, &quot;o que comer, o que vestir&quot;, enfim, tudo isto requer amplo planejamento e boas práticas para a manutenção do '''''ciclo de vida do projeto''''' (Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento). Isto será discutido futuramente em outros artigos aqui em nossa Wiki.<br /> <br /> === Qual é a relação entre a &quot;seção de revisão de componentes tecnológicos&quot; deste artigo e os objetivos propostos pelo mesmo? ===<br /> Talvez você esteja se perguntando: &quot;''Tá, Leonardo, mas.... o que tem isso a ver?''&quot;.<br /> <br /> Em primeiro momento, informo que nem todos os leitores de nossa Wiki são profissionais altamente experientes quanto você, nobre leitor! Há indivíduos que nos visitam aqui que já reportaram dificuldades em absorver conhecimentos mais avançados ou complexos, ou que estejam em processo de aperfeiçoamento de carreira. Para este perfil de nosso público, tenho certeza que as informações apresentadas na seção anterior são tidas como muito úteis e, portanto, achei prudente lembra-los da magnitude em termos de quantidade e diversidade de componentes, recursos, conceitos, procedimentos e especificações tipicamente encontrados nas redes de ''service providers'', e tudo isso pode ser tratado como componentes que são ou que devam ser configurados em uma rede, seja pelo modelo tradicional (CLI, WebUI) ou por meios da automação por ferramentas de programabilidade.<br /> <br /> &lt;u&gt;A pergunta que faço agora:&lt;/u&gt; '''''como você projeta, implementa (as tecnologias, protocolos, serviços, etc.), opera (a manutenção geral), suporta (diagnóstico, troubleshooting), e provisiona clientes e seus respectivos produtos contratados?'''''<br /> <br /> Sabemos que na grande maioria dos casos a coisa não funciona por pura e simples &quot;''mágica''&quot;, e quase tudo depende de ações e intervenções humanas. Aposto que hoje, no seu ambiente, mais de 95% de tudo o que a sua rede precisa fazer é fruto de alguma configuração realizada inteiramente pelas mãos de um operador da sua rede, um profissional de operações (NOC), provisionamento ou da engenharia! O camarada foi lá e configurou elemento por elemento, &quot;na mão&quot;, pela linha de comando (CLI) ou por alguma interface gráfica tipo ''Device Manager'' (gerenciador de dispositivo, específico para aquele e cada equipamento), e todo o ambiente é mantido assim, desta forma.<br /> <br /> Cada vez que você tiver que adicionar um novo elemento/equipamento na sua rede, como você faz? Cada vez que você precisa suportar novos prefixos IP, como você lida com as modificações nas suas políticas de roteamento? Cada vez que você precisa ativar um cliente corporativo para um produto do seu ISP, como você faz para provisionar este serviço? Ativar uma L2VPN ponto a ponto ou multiponto, ou uma extensão entre data centers (''Data Center Interconnect''), ou uma L3VPN (''simple, complex, managed services,'' e ''Internet''), ou um serviço SD-WAN gerenciado e em combinação com proteção de DNS e outros &quot;mimos&quot;? E com relação ao assinante residencial, como você faz? Tenho quase certeza que hoje, no seu caso, a maior parte destes processos, pra não citar &quot;todos&quot;, é manual ou, no melhor caso, requer uma ação humana realizada sobre algum tipo de ferramenta que atenua estes esforços, mas que, mesmo assim, precisa ser realizada sobre diversos equipamentos da infraestrutura. <br /> <br /> &lt;u&gt;Para efeitos comparativos aqui:&lt;/u&gt; nos melhores casos e envolvendo grandes empresas do setor de tecnologia, quando você contrata uma plataforma como serviço (''PaaS'') ou uma infraestrutura como serviço (''IaaS'') de uma destas consagradas empresas globais, você realmente acredita que alguém recebe um email (referente a sua solicitação) e o encaminha internamente para as áreas técnicas para que estes mobilizem qualquer atividade de ativação manualmente, tais como a instalação de equipamentos, instalação e atualização de software, configuração de dispositivos e serviços? Claro que não! Nestes perfis de organizações, tudo isso é orquestrado e automatizado a partir do momento em que você passa o seu cartão de crédito durante o procedimento de subscrição ou de contratação do serviço!<br /> <br /> E é justamente sobre este tema é que passaremos a dissertar a partir de agora neste artigo, sendo este o nosso foco.<br /> <br /> === A relação entre este artigo e os frameworks e modelos de gerenciamento de infraestruturas de ambientes ISP ===<br /> Não dissertarei detalhadamente sobre os frameworks em questão, pois haverá oportunidades de você conhecer mais sobre este tema em outros artigos do Brasil Peering Forum. Irei ao ponto logo ao término dessa seção.<br /> <br /> Talvez você queira aprofundar-se um pouco mais sobre esta área com a leitura do artigo [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]], caso não tenha feito isso ainda.<br /> <br /> Há muitos anos o [https://www.itu.int/en/ITU-T/publications/Pages/default.aspx ITU-T] introduziu o termo ''Telecommunications Management Network'' (TMN) para a descrição de uma rede dedicada com interfaces orientadas ao gerenciamento de redes de telecomunicações, e buscando definir os pontos de interconexão entre as duas redes, além de especificar as diversas funcionalidades de gerenciamento. A proposta deste framework foi ilustrar as áreas funcionais distintas e como estas deveriam interoperar. E isto foi originalmente especificado pelo ITU-T M.3400 e X.700, em especial a classificação das funcionalidades de gerenciamento, mas sem a descrição detalhada dos componentes destas funções, algo que foi tratado mais apropriadamente por outros padrões periféricos mais específicos e que nasceram mais ou menos no mesmo período.<br /> <br /> Por sua vez, o FCAPS é um modelo de gerenciamento de redes produzido pela ISO, e não pelo ITU-T, descrito inicialmente como ''Working Drafts'' (N1719) da norma ISO 10040, e com o intuito de definir cinco padrões de protocolos distintos, sendo cada um para uma área funcional específica. Posteriormente, dadas as similaridades entre muitas funções pretendidas por estes protocolos, os cinco foram consolidados em um só (''Common Management Information Protocol'' ou CMIP). No entanto, a coisa não parou por aí, e muitas evoluções ocorreram, até que o próprio ITU-T, nos anos 90, passasse a integrar o FCAPS como parte de seu framework TMN. Esta integração entre TMN e FCAPS está mostrada na ilustração logo abaixo.<br /> <br /> Posteriormente, o FCAPS evoluiu para o que chamamos de FAB (''Fulfillment, Assurance, Billing''), conforme definido pelo framework ''Business Process Framework'' (BPF), que foi bem esclarecido no mapa ''eTOM'' apresentado no artigo &quot;''Frameworks de Indústria para a Reestruturação e Profissionalização do ISP''&quot;, publicado em nossa Wiki. Ou seja, resumindo aqui, tanto a ISO quanto o ITU-T tinham propostas e modelos bastante interessantes para compreendermos as questões associadas ao gerenciamento de infraestruturas, e houve este esforço ou intenção de ambas as partes para que o melhor dos dois mundos pudessem se encontrar, promover uma certa unificação e direcionamento para os melhores resultados para a indústria. No que concerne ao FCAPS em si, para todos os efeitos mais práticos, as classificações das funções de gerenciamento para cada uma das áreas de negócios e funcionais de um ISP foram inicialmente especificadas pelo FCAPS da ISO, posteriormente integradas pelo TMN da ITU-T, e aprimoradas e portadas para o eTOM BPF. Atualmente, o framework BPF é um dos frameworks do ''[https://www.tmforum.org/frameworx-homepage/ Frameworx],'' criado e mantido pelo [https://www.tmforum.org/ TM Forum].<br /> [[Arquivo:Bpf-prog-fcaps.png|centro|miniaturadaimagem|800x800px|Visualização da integração entre TMN e FCAPS, e a ênfase no conceito de Configuration, que será o foco do artigo a partir deste ponto]]<br /> A relação entre eTOM BPF ou FAB ou FCAPS, enfim, e este artigo, é buscar capacitá-los com informações fundamentais sobre o '''''Gerenciamento de Configurações''''' de uma rede de ISP. <br /> <br /> Por que o FCAPS é útil, inclusive para o nosso artigo aqui? Assim como temos o hábito de usarmos frequentemente o modelo de referência OSI (RM-OSI), ou seja, aquelas 7 camadas (Física, Enlace de Dados, Rede, Transporte, Sessão, Apresentação e Aplicação) para ensinarmos os fundamentos de redes para profissionais da área ou indivíduos que estejam começando nela, usamos também o FCAPS para este mesmo propósito, que é o de ensinar e capacitar, só que, neste caso, sobre os conceitos e fundamentos de gerenciamento de infraestruturas!<br /> <br /> O FCAPS, mesmo que o &quot;original&quot; esteja um pouco defasado (pois hoje está incorporado, mais amplo e melhor especificado no eTOM BPF), '''&lt;u&gt;''é uma excelente ferramenta de aprendizado!''&lt;/u&gt;''' Por este motivo decidi escrever um pouco a respeito dele nesta seção do artigo. Quer ensinar redes para alguém? O modelo de referência OSI é ótimo para isso! &lt;u&gt;Quer ensinar fundamentos de gerenciamento de redes para alguém? O FCAPS é certamente um dos recursos mais interessantes e úteis para concebermos estes ensinamentos!&lt;/u&gt;<br /> <br /> Para concluir, a sequência deste artigo estará centrada no '''''&lt;u&gt;Gerenciamento de Configurações&lt;/u&gt;''''' (o &quot;'''C'''&quot; do modelo FCAPS). Além do artigo, você talvez tenha interesse em consultar a recomendação [https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=14005&amp;lang=en ITU-T G.7710/Y.1701 (08/2019) - Common Equipment Management Function Requirements] para ampliar seus horizontes.<br /> <br /> === Como o gerenciamento de configurações é realizado pela maioria dos ISPs regionais de pequeno e médio portes ===<br /> É de amplo conhecimento que, em parâmetros tecnológicos, os provedores de acesso à Internet de pequeno e médio portes evoluíram muito de uns anos para cá. Em termos de sofisticação de equipamentos e tecnologias, estes ISPs tem &quot;encostado&quot; nos grandes operadores de rede, geralmente ficando as principais diferenças entre ambos os perfis nas questões associadas ao porte dos equipamentos utilizados (capacidade, densidade, quantidade, volume), tamanhos das áreas de concessão, tamanho da base de assinantes, sendo estas diferenças até bastante expressivas, mas não no tipo ou na qualidade da tecnologias empregadas. E, nas questões administrativas, claro, a quantidade de colaboradores, os orçamentos, áreas internas do negócio, e diversos outros casos que não convém elencar no momento. <br /> <br /> Mas há uma diferença muito significativa, importantíssima, e que tem a ver com o que este artigo propõe-se a discutir: o &lt;u&gt;''gerenciamento da infraestrutura como um todo''&lt;/u&gt;, incluindo frameworks, processos, procedimentos, metodologias, sistemas, integrações entre sistemas e infraestruturas, o tanto de programabilidade, automação e orquestração, os respectivos padrões de ferramentas empregadas... e isto são algumas das principais comparações operacionais e procedurais que faço quando analisando um operador de redes de grande porte e um ISP regional de pequeno ou médio porte, quanto a estes quesitos.<br /> <br /> No que diz respeito ao '''''gerenciamento de configurações''''', mais especificamente quando um ISP regional de menor porte precisa ativar ou provisionar um novo serviço, geralmente são necessários os seguintes procedimentos (estou generalizando aqui):<br /> # Se a manobra tiver que incluir a instalação física de um novo equipamento em um site/Pop do ISP, conduzir e documentar um ''Projeto Provisório de Instalação'' (PPI) ou ''Projeto Definitivo de Instalação'' (PDI), juntamente com os demais procedimentos homologados pela Engenharia da empresa, tais como ''Plano de Instalação e Ativação'', etc.<br /> ## Sejamos realistas: a instalação física de um equipamento não pode ser automatizada! (exceto, talvez, por robôs, o que não será o caso tão cedo)<br /> # Configuração de equipamento para a sua efetiva integração com a rede, o que, por sua vez, normalmente, ou quase sempre, exige a condução de outros procedimentos aprovados pela Engenharia da empresa, em particular a atualização do software para a versão homologada e a condução de um extenso roteiro/script contendo os parâmetros de configuração, apoiados por artefatos tais como um ''Plano de Instalação e Configuração Lógica''.<br /> ## Aqui temos a primeira oportunidade de automação e orquestração, via métodos de provisionamento tais como o de zero toque ou &quot;''Zero Touch Provisioning''&quot; ou tecnologia similar, os quais propõem-se a simplesmente exigir do profissional lá no site/Pop apenas as manobras de energização e cabeamento/conectorização das portas do equipamento, que a rede automaticamente se encarregará de todo o resto e fornecerá a configuração definitiva do equipamento.<br /> # Em seguida, o provisionamento do serviço do cliente! É aqui que você terá que &quot;visitar&quot; a CLI (linha de comando) ou WebUI de vários equipamentos para realização das configurações necessárias para a viabilidade fim-a-fim do serviço contratado pelo assinante, e geralmente apoiado por um formato pré-estabelecido para aquele tipo de produto/configuração. Ou seja, definir as VLANs, entroncamentos de VLAN, os mecanismos de controle de admissão à rede, recursos de segurança, endereços IP, roteamento, QoS, policies, etc., e fazendo isto para as tecnologias requeridas, caso a caso, sobre todo e qualquer dispositivo exigido para a viabilidade quanto à &quot;ativação&quot; (fim a fim) daquele produto que aquele assinante contratou.<br /> ## Talvez uma das áreas operacionais mais frágeis da organização seja exatamente esta baixa aderência quanto às boas práticas regidas pelo &quot;'''''C'''''&quot; do FCAPS, ou seja, da disciplina de '''''gerenciamento de configurações'''''! Muito frequentemente, para não dizer &quot;quase sempre&quot;, é um processo estritamente manual e associado a custos mais elevados, maiores esforços e complexidades operacionais, maiores riscos de incidentes e downtime (decorrentes de falha humana durante o processo de configuração de elementos de rede), dentre muitas situações eventual e obviamente indesejadas.<br /> ## E é aqui que enxergo mais uma excelente oportunidade para os ISPs regionais poderem se modernizar!<br /> # O serviço que foi ativado (produto + assinante) é testado e validado, e posicionado para produção em caráter definitivo. A partir deste ponto, a Operação da rede (ex: NOC) deverá ficar responsável por assegurar que as métricas do SLA contratado sejam respeitadas, tais como capacidade, consumo de banda dentro do perfil, latência, jitter, perda de pacotes, disponibilidade/uptime, etc.<br /> ## Outra seara repleta de procedimentos manuais e ferramentas dissimilares que não &quot;conversam&quot; entre si, não compartilham dados, e fica bem mais difícil encontrar uma utilidade real para os sistemas de gerenciamento de elementos (EMS) e de rede (NMS) da organização, como partes integrantes ou isoladamente dos sistemas de suporte a operação (OSS).<br /> ## Aqui é onde enxergo outra excelente oportunidade para a modernização das infraestruturas e processos dos ISPs regionais!<br /> [[Arquivo:Bpf-prog-2.png|centro|miniaturadaimagem|800x800px|O roteiro tradicional de implantação e provisionamento de serviços de um ISP]]<br /> <br /> === Introdução aos conceitos da disciplina de configurações ===<br /> Realmente pretendo pular a parte referente aos conceitos de ''IT Service Management'' (ITSM), e um tanto do que a versão 3 do ITIL (''Information Technology Infrastructure Library'') aborda neste sentido. Voltaremos aqui ao que importa, e o FCAPS é mais apropriado para dissertarmos a respeito disto.<br /> <br /> Na questão de &quot;Configurações&quot;, o FCAPS é centrado em um bocado de coisas, mas dá para sumarizar suas principais funções e objetivos da seguinte forma:<br /> # '''''Inicialização do Serviço'''''<br /> # '''''Provisionamento do Serviço'''''<br /> # '''''Auto-descoberta''''' (de elementos e suas capacidades e propriedades, topologias, etc.)<br /> # '''''Backup e restauração''''' (obviamente incluindo muitas capacidades e facilidades aqui, tais como diff-check, dry-run, etc.)<br /> # '''''Desligamento de recursos''''' (quando não são mais necessários, ou por mudança de perfil de assinante (ex: bloqueado, cancelado))<br /> # '''''Gestão de mudanças''''' (os processos e ferramentas para a &quot;GMUD&quot;).<br /> # '''''Pré-provisionamento'''''<br /> # '''''Gerenciamento de inventário''''' (não somente a parte do hardware inteiro, mais também os módulos, acessórios, software, licenças, etc.)<br /> # '''''Cópia de configurações'''''<br /> # '''''Configuração remota'''''<br /> # '''''Atualização automática de software''''' (incluindo funcionalidades que maximizem a disponibilidade dos dispositivos, compliance de software, etc.)<br /> # '''''Iniciação, rastreamento e execução de job'''''<br /> Ou seja, tudo para viabilizar os controles necessários para implementar a configuração inicial dos elementos da rede e seus respectivos componentes, sincronismo e monitoramento dos parâmetros de configuração empregados; distribuição de tarefas de configuração com o auxílio de templates, configuração de propriedades avançadas sobre os elementos da rede (proteção e resiliência, VLANs, entroncamentos, endereçamento IP, roteamento, QoS, etc.), manutenção e auditoria de configurações, e tantos outros. <br /> <br /> A arquitetura ''Equipment Management Function'' (EMF) proposta pelo ITU-T com relação ao FCAPS fornece as recomendações sobre como os sistemas de gerenciamento de elementos (EMS) gerenciam as funções de elementos de redes (NEF), ao interagir com funções atômicas da camada de transporte e sincronização (AF), e fazendo isto através da troca de informações de gerenciamento (MI) sobre os pontos de gerenciamento (MP); esse &quot;tequiniquês&quot; é abordado no ITU-T G.806, ITU-T X.701 e ITU-T X.720, enfim, suprimamos isso aqui. Talvez eu deva ao menos fornecer uma noção visual destes conceitos:<br /> [[Arquivo:Bpf-prog-fcapscm.png|centro|miniaturadaimagem|800x800px|Ilustração de conceitos FCAPS tais como NEF, EMF, MAF, MCF, MI e MP (Fonte: ITU-T)]]<br /> Em termos mais práticos, isto significa que você precisa considerar para a sua infraestrutura as devidas funções de gerenciamento para cada uma áreas recomendadas pelo FCAPS (ou eTOM BPF, neste caso), observando como os sistemas de negócios da empresa estão mapeados para os sistemas mais técnicos e operacionais, e como estes sistemas mais técnicos-operacionais interagem com a infraestrutura para aditivar as tecnologias, as quais, por sua vez, darão apoio direto aos resultados tanto técnicos quando os de negócios. Aquela tão desejada aderência...<br /> <br /> Você basicamente possui dois caminhos possíveis, dependendo do perfil do seu ambiente em termos de &quot;vendor&quot; (fabricante de escolha dos seus equipamentos):<br /> * '''Rede homogênea:''' se a sua rede contiver dispositivos e soluções de apenas um fabricante, você muito provavelmente poderá utilizar as ferramentas/sistemas ou soluções daquele fabricante para as necessidades de gerenciamento de configurações. Aliás, não somente configurações, mas também a parte de desempenho, falhas/incidente, segurança, etc. Ou seja, as plataformas de gerenciamento desenvolvidas pelo fabricante para aquela classe de produtos que você tem na sua rede. Desnecessário comentar que são soluções proprietárias, certo? Não que isto seja algo ruim, mas é bom deixar isto bem claro.<br /> * '''Rede heterogênea:''' se a sua rede contiver um mix de soluções e de vários fabricantes, você terá bem mais dificuldades. Na maioria dos casos, você terá que rodar múltiplos sistemas de gerenciamento para acomodar cada uma das áreas funcionais previstas pelo FCAPS através deste cenário multivendor. É muito improvável que a plataforma de gerenciamento de um determinado fabricante vá suportar bem os equipamentos de outros fabricantes, principalmente quando o assunto for ''&lt;u&gt;gerenciamento de configurações&lt;/u&gt;''. E, caso haja esse suporte, ele quase sempre ou fatalmente será limitado, ou possuirá algumas chatas restrições.<br /> Em muitos casos, nos vemos forçados a usar uma solução para gerenciar os elementos da marca &quot;A&quot;, outra solução de gerenciamento para os elementos da marca &quot;B&quot;, mais uma solução para gerenciar os elementos da marca &quot;C&quot;, e uma ou mais soluções open source (ou não) para monitorar componentes em comum das marcas &quot;A&quot;, &quot;B&quot; e &quot;C&quot;, como ocorre frequentemente para a parte de gerenciamento de desempenho e gerenciamento de falhas/incidentes, onde soluções tais como PRTG, Zabbix, Libre NMS, Observium, Nagios, Cacti, etc., são bastante populares. Eu particularmente vejo muita fragilidade e inconvenientes aqui, pois raramente estes sistemas integram bem com sistemas de outros fabricantes, exceto, talvez, e dependendo do caso, via extensas e complexas integrações por ''Common Object Request Broker Architecture'' (CORBA), do ''Object Management Group'' (OMG), algo que já vi acontecer um bocado em ambientes de telecom. Um porre! Não é a toa que o TM Forum tem buscado impulsionar bastante o Frameworx como forma de padronização, interoperabilidade e integração entre os sistemas BSS e OSS.<br /> <br /> Que tal darmos uma praticidade para estes argumentos?<br /> * O '''Winbox''' da Mikrotik não vai gerenciar configurações de um equipamento Cisco, Juniper ou Huawei ('''''pelo menos não que eu saiba! KKKKKKK''''').<br /> * O '''Cisco Prime LAN Management Solution''' não vai gerenciar configurações de elementos de rede de classe corporativa não-Cisco.<br /> * O '''Cisco Application Policy Infrastructure Controller (APIC)''' possui alguma integração com soluções específicas (Check Point, Palo Alto Networks, Fortinet Inc, Radware – DefensePro, A10 Networks, Avi Networks, Citrix Systems, F5 Networks, Radware – Alteon VA e VX), mas não para todos os recursos e funções que talvez você necessite para o seu projeto.<br /> * O '''Cisco Adaptive Security Device Manager (ASDM)''' só serve para gerenciar dispositivos de segurança ASA da Cisco.<br /> * O '''Cisco Network Services Orchestrator (NSO)''' não é orientado para funções de gerenciamento de falhas ou desempenho, e sim para o gerenciamento de configurações, e talvez seja uma das poucas soluções comerciais que conseguem orquestrar o provisionamento de serviços fim a fim sobre qualquer equipamento e de qualquer vendor (a não ser que o seu equipamento não seja realmente lá grandes coisas...), e compete com vantagens contra o '''''Ansible Tower'''''.<br /> * O '''Junos Space Network Management Platform''' da Juniper consegue integrar alguns dispositivos de terceiros como elementos gerenciados, mas, &quot;''guess what?''&quot;, há restrições de funcionalidades.<br /> * O '''HPE Intelligent Management Center Enterprise''' da HP permite adicionar alguns elementos externos/de terceiros, tais como o switch Cisco Nexus, e integrações com Aruba Airwave (faz sentido, pois houve a aquisição aqui), ClearPass e HPE OneView. O que exatamente é suportado ou quais são as restrições aqui, eu desconheço no momento. <br /> * O '''Zabbix''' pode ser ótimo para necessidades de gerenciamento de falhas/incidentes e de performance/desempenho, até mesmo porque é amplamente customizável. Agora experimente conduzir a disciplina de gerenciamento de configurações com esta ferramenta, e você verá que é simplesmente inviável e contra-indicado.<br /> * O '''Libre NMS''' é outro exemplo clássico, idêntico ao caso do Zabbix, assim como as outras ferramentas bem conhecidas do mercado citadas anteriormente.<br /> * O '''ManageEngine''' ou o '''PRTG''' são outros ótimos exemplos para as questões de gerenciamento de falhas e de desempenho, mas não são funcionais para o gerenciamento de configurações.<br /> Como você pode notar, muito frequentemente os sistemas que nós utilizamos não atendem bem a todas as nossas necessidades, e nos vemos forçados a contar com 3 ou 4 soluções de gerenciamento para manter a infraestrutura funcionando. Sistemas, estes, que funcionam de forma completamente independente, como &quot;ilhas&quot; mesmo, isolados, e com mínima ou zero troca de dados entre si. Para ''falhas'' e ''desempenho'', isto é até &quot;aceitável&quot;, embora, ainda assim, indesejável. Mas, para o '''''gerenciamento de configurações''''', isto é inaceitável! Meus &quot;''2 cents''&quot; aqui.<br /> <br /> A ilustração a seguir fornece exemplos de soluções mapeadas para as áreas do FCAPS, para que você tenha essa noção de que alguns fabricantes procuram especificar as funções de suas soluções de gerenciamento para ficarem mais &quot;alinhadas&quot; com as recomendações do FCAPS. Os exemplos não são completos e tampouco estão atualizados 100%, mas acho que você compreenderá a essência.<br /> [[Arquivo:Bfp-network management.png|centro|miniaturadaimagem|600x600px|(Fonte: snmpcenter.com)]]<br /> E é por esta razão que a indústria está convergindo cada vez mais para os princípios de programabilidade, pois os modelos de gerenciamento tradicionais não mais correspondem às nossas expectativas, e pelas tantas razões e situações comentadas até este momento!<br /> <br /> Agora, há uma terceira opção aqui, que seria considerar soluções comerciais (destes mesmos fabricantes ou de terceiros) em combinação com outras iniciativas que entendam melhor as nossas necessidades e que sejam capazes de promover melhor aderência. Muitos destes sistemas &quot;fechados&quot; podem não atender integralmente as nossas necessidades, principalmente quando estes possuem baixas capacidades e recursos de integração com outros sistemas. E é nessa hora onde ferramentas e soluções de programabilidade poderão ser bem mais efetivas para os nossos propósitos. É nessa hora que pensamos em Ansible / Ansible Tower, Chef, Puppet, Salt, Cisco NSO e outras ferramentas de programabilidade, integradas a controladores SDN ou não.<br /> <br /> === Agora que você já está &quot;anestesiado&quot; e a par de todas as situações e pré-requisitos, vamos à programabilidade de infraestruturas ===<br /> Tentarei ser muito objetivo ao explicar logo a seguir algumas verdades, assim como aproveitar a oportunidade para esclarecer algumas &quot;inverdades&quot;, sobre este universo envolvendo programabilidade, orquestração, automação, provisionamento, SDN, NFV, etc. Vamos lá?<br /> * O &lt;u&gt;'''''provisionamento'''''&lt;/u&gt; é essencialmente a intenção de ativação de um serviço para o ISP ou, bem mais frequentemente, para seus clientes. <br /> ** Este provisionamento de um serviço (ex: um L2VPN &quot;LAN-to-LAN&quot; ou &quot;DCI&quot;, uma L3VPN, um serviço de Internet, etc.) pode ser realizado manualmente (como é feito normalmente na maioria dos casos envolvendo os ISPs regionais, assim como empresas do setor corporativo) ou de forma bem mais &quot;''programável''&quot;; orquestrada e automatizada.<br /> ** Geralmente referimos o conceito à ativação de um serviço fim-a-fim e que vá envolver diversas tecnologias (L2, L3, e outros) e em vários dispositivos de rede, homogêneos (mesmo padrão de sintaxe e semântica) ou heterogêneos (diferentes vendors, ou CLIs, sintaxes, etc.). <br /> ** O provisionamento pode ser também uma coisa bem mais específica e pontual (um pequeno bloco de configuração a ser programado em um único dispositivo, por exemplo).<br /> * A ''&lt;u&gt;'''orquestração'''&lt;/u&gt;'' é a capacidade tecnológica de habilitar serviços envolvendo ações de provisionamento sobre a infraestrutura, que poderá abranger ou contemplar somente a rede, ou, então, por exemplo, rede + computação + storage + plataforma/apps, frequentemente tocando em componentes multivendor, para a ativação de um determinado produto ou serviço desejado, seja este para atender uma necessidade interna, do próprio ISP, ou para atender a uma solicitação ou contratação por parte de um cliente/assinante.<br /> ** As tecnologias que fomentam a orquestração precisam ou devem operar sobre um regime de abstração entre as funções lógicas pretendidas e os componentes da infraestrutura de rede física. A solução preferencialmente deve suportar, além da abstração, o modelo de operações por transações. Quais equipamentos precisarão ser configurados? Ou quais equipamentos precisam receber quais configurações para a ativação deste serviço? E isto independente do vendor ou da sintaxe da CLI, sendo este o principal propósito desta abstração requerida. E, caso haja algum problema com a ativação, as devidas facilidades de ''rollback'' automático.<br /> ** A orquestração é muito desejada em qualquer tipo de situação, mas, sem sombra de dúvidas, é mais desejável ainda em ambientes heretogêneos (ex: multivendor).<br /> * A &lt;u&gt;'''''automação'''''&lt;/u&gt; é o estado operacional desejado para que estas ações de configuração e provisionamento de serviços (e até mesmo nos casos de diagnósticos ou suporte a falhas) na infraestrutura envolvam &quot;zero&quot; ou o mínimo possível de ações humanas.<br /> ** Desejavelmente, a automação deve estar contida na orquestração, pois, por exemplo, do contrário, não fará muito sentido &quot;juntar as peças de sistemas dissimilares&quot; (alçada da orquestração) se você tiver que executar os blocos do contrato manualmente depois, na CLI, GUI/WebUI ou por scripts, em vários equipamentos.<br /> ** A orquestração e automação devem andar lado a lado. <br /> *** Em muitos casos, o contrato do serviço pode ser desenhado na forma de templates e acionados por ações nos sistemas da companhia, onde, num simples ''frontend'', os parâmetros são preenchidos/fornecidos para que, no ''backend'', a rede seja acionada para receber as configurações devidas e concluir todo o provisionamento. Neste cenário, não há o envolvimento de analistas na linha de comando (CLI) ou em plataformas específicas de provisionamento (EMS/GUI/WebUI).<br /> *** Em outros casos, o provisionamento é feito em sistemas específicos para este propósito e poderá exigir algum padrão de intervenção técnica, por exemplo, a execução de scripts ou acionamentos de funções mais técnicas em sistemas específicos, mas exigindo pouco ou nada em termos de uma intervenção por CLI ou GUI/WebUI dos dispositivos.<br /> * A '''''&lt;u&gt;programabilidade&lt;/u&gt;''''' tem relação com a afinidade de tecnologias, processos, ferramentas e soluções técnicas compatíveis que são empregadas para as orquestrações automatizadas de serviços. <br /> ** Isto é, idealmente, o seu aparato tecnológico, incluindo hardware, software e sistemas utilizados em seu ambiente, tudo isto precisa ser compatível com o suporte à tecnologias que fomentam a orquestração e automação para a programabilidade do provisionamento fim a fim de serviços com maior fluidez, menor tempo/prazo, &quot;zero&quot; ou menor esforço de implementação, e menores riscos para a rede e para o negócio. <br /> * Praticamente em todos os casos a orquestração envolve automação, mas não o contrário: nem toda automação tem relação com orquestração.<br /> ** Scripts customizados por você podem não ter qualquer relação com ações de orquestração, além de serem isentos de capacidades de abstração, ou seja, scripts montados para aplicar configurações com sintaxes específicas e com acionamento caso a caso.<br /> * Programabilidade e &lt;u&gt;'''''Software-Defined Networking'' (SDN)'''&lt;/u&gt;, apesar de andarem lado a lado constantemente, são coisas completamente '''&lt;u&gt;distintas&lt;/u&gt;'''.<br /> * Orquestração e ''Software-Defined Networking (SDN)'' são coisas '''&lt;u&gt;distintas&lt;/u&gt;'''. Nem toda orquestração ocorre em um ambiente SDN (ex: com controladoras e soluções específicas de SDN), mas quase sempre o inverso é verdadeiro.<br /> * ''Software-Defined Networking'' (SDN) e ''&lt;u&gt;'''Network Functions Virtualization'''&lt;/u&gt;'' (NFV) são coisas completamente '''&lt;u&gt;distintas&lt;/u&gt;'''.<br /> * As capacidades de programabilidade da infraestrutura estão condicionadas à disponibilidade e suporte de tecnologias, recursos e ferramentas específicas, e isto valendo para cada equipamento.<br /> ** Não adiantará muito controladoras SDN em um projeto com suporte ao OpenFlow na sua rede se os seus elementos de rede (equipamentos) forem incompatíveis com este protocolo. Ou, ao invés do OpenFlow, não adiantará muito (ou pelo menos ficará bem mais complicado) fazer a orquestração de serviços na rede se os seus equipamentos não suportarem o protocolo NETCONF.<br /> * Redes mais sofisticadas utilizam ferramentas e recursos mais arrojados para estas finalidades de programabilidade.<br /> A ilustração a seguir mostra exemplos de recursos de programabilidade representados por funcionalidades suportadas por um determinado equipamento, assim como mostra alguns casos de tecnologias mais apropriadas para que se tenha uma rede mais programática e versátil neste sentido.<br /> [[Arquivo:Bpf-prog-1.png|centro|miniaturadaimagem|800x800px|Exemplos de componentes fomentadores da programabilidade de infraestruturas]]<br /> <br /> ==== Identificando as principais soluções, ferramentas e componentes orientados aos princípios de programabilidade ====<br /> Caso você tenha ficado impressionado com a &quot;salada de tecnologias&quot; ilustrada no início deste artigo, isto porque você talvez desconheça o turbilhão de ferramentas empregadas para fins de programabilidade, incluindo orquestração e automação! Como realmente não dá para listar todas as opções de código aberto e comercial, fornecerei aqui alguns exemplos, talvez os principais, além de citar algumas ferramentas e os principais componentes usados por estas, tais como protocolos, procedimentos e formatos de dados, onde for viável comentar neste nível. Aliás, a intenção a seguir não é realmente esmiuçar como são de fato implementadas ou inseridas nas infraestruturas. Outro aspecto importante a ser comentado é que os exemplos a seguir não funcionam &quot;sozinhos&quot;, no sentido que, em uma rede, você precisará combinar diversas destas soluções, linguagens, modelos, ferramentas e procedimentos; e que nem tudo o que está citado a seguir depende de controladoras SDN para acontecer. Há casos e casos, e cenários para tudo.<br /> <br /> A ilustração a seguir mostra algumas áreas relacionadas aos princípios de programabilidade:<br /> [[Arquivo:Bpf-prog-contextos.png|centro|miniaturadaimagem|800x800px|Algumas áreas do conceito de programabilidade de infraestruturas]]<br /> {| class=&quot;wikitable&quot;<br /> |+Descrição das principais soluções, ferramentas, modelos, procedimentos e componentes de programabilidade<br /> !Ferramenta<br /> !Descrição<br /> |-<br /> | colspan=&quot;2&quot; |'''Soluções Comerciais'''<br /> |-<br /> |'''VMware vSphere'''<br /> |O vSphere é provavelmente a solução de virtualização de servidores mais utilizada do mercado. Ele ajuda você a executar, gerenciar, conectar e proteger os aplicativos em um ambiente operacional comum entre nuvens. Esta solução é amplamente utilizada no mundo todo e em todo e qualquer tipo de ambiente, mesmo aqueles ambiente mais estáticos ou isentos de componentes de orquestração. Possui excepcionais capacidades de integração com regimes de orquestração e provisionamento completos de servidores virtuais.<br /> |-<br /> |'''VMware vRealize'''<br /> |VMware vRealize Suite, conhecido anteriormente pelo nome vCenter Operations Management Suite, é uma plataforma de software projetada para a construção de nuvens heterogêneas híbridas, e apresenta excepcionais capacidades de integração.<br /> |-<br /> |'''Cisco APIC-EM'''<br /> |O Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) é a solução de controladora SDN da Cisco para redes corporativas, atendendo tanto a LAN quanto a WAN.<br /> <br /> A sua proposta é a de fornecer uma plataforma elástica para a automação, simplificação e abstração da rede, acomodando aplicações que usam padrões abertos, e com suporte a northbound Representational State Transfer (REST) APIs.<br /> |-<br /> |'''Cisco DNA Center'''<br /> |O Cisco DNA Center é uma solução que reúne componentes focados na construção de ambientes intuitivos (Intent-based Networking), em compatibilidade com as arquiteturas SDN da Cisco.<br /> Reúne excepcionais facilidades para Projeto, Policy, Provisionamento, Assurance e integração com outras plataformas, e com foco em ambientes corporativos.<br /> |-<br /> |'''Cisco Application Centric Infrastructure (ACI)'''<br /> |O Cisco Application Policy Infrastructure Controller (Cisco APIC) é o principal componente arquitetural da solução Cisco ACI. Ele é o ponto unificado de automação e gerenciamento para a estrutura, a aplicação de políticas e o monitoramento de integridade da solução. O controlador otimiza o desempenho e a gestão, além de operar uma estrutura multiusuário escalonável da Cisco ACI. A solução como um todo embarca outros componentes tais como a própria controladora (Cisco APIC), Cisco Cloud ACI, Cisco Virtual ACI, swiches Cisco Nexus 9000 Series, Cisco ACI Multisite Orchestrator, Cisco ACI App Center, além de ótimas integrações com outras soluções tais como AppDynamics, DNA Center e ISE. <br /> O foco do ACI está para os ambientes de data center.<br /> |-<br /> |'''Cisco Crosswork Network Automation'''<br /> |O Cisco Crosswork Network Automation é uma solução voltada especificamente para service providers / ISPs e que reúne uma diversidade muito grande de recursos para o gerenciamento proativo fim a fim das redes. <br /> Embarca uma suite de componentes de machine-learning, intent-based networking, e outros, viabilizando ampla orquestração de redes plenamente automatizadas.<br /> |-<br /> |'''Cisco Network Services Orchestrator'''<br /> |O Cisco NSO é uma solução muito robusta de orquestração com abstração de infraestruturas físicas e virtuais, fornecendo excepcionais capacidades de orquestração de serviços fim a fim, e muitas facilidades de integração com APIs northbound e southbound, suportando ambientes completamente heterogêneos (multivendor).<br /> <br /> O Cisco NSO pode funcionar sozinho ou em combinação ao Cisco Crosswork Network Automation.<br /> |-<br /> |'''Cisco Open SDN Controller'''<br /> |O Cisco OSC é uma distribuição comercial do OpenDaylight para o fornecimento de agilidade e automação de infraestruturas, fazendo a abstração de ambientes de redes heterogêneas para a entrega de serviços.<br /> |-<br /> |'''Microsoft System Center'''<br /> |O Microsoft Systems Management Server é uma solução para o gerenciamento de grandes grupos de sistemas baseados no Microsoft Windows.<br /> |-<br /> |'''BMC Software'''<br /> |A BMC é uma empresa americana bastante especializada em soluções para o gerenciamento de TI, oferecendo suporte a 92 das 100 empresas listadas na Forbes Global.<br /> <br /> A BMC possui sofisticadas soluções para o grenciamento multi-cloud, automação e DevOps, segurança e conformidade, otimização de TI, inteligência artificial e machine learning, e gerenciamento de serviços.<br /> <br /> Suas soluções são frequentemente encontradas em grandes e bem sucedidos empreendimentos, e possui ótimas capacidades de integração com infraestruturas de redes.<br /> |-<br /> |'''Juniper Contrail'''<br /> |A solução Contrail Controller da Juniper Networks é um produto de automação tipo open cloud que implementa tecnologias SDN para a orquestração e criação de redes virtuais altamente escaláveis. É fruto da aquisição da Contrail em dezembro de 2010.<br /> <br /> O Contrail pode ser utilizado por service providers / ISPs para agilizar o provisionamento de serviços, e também atende a muitos casos e necessidades de empresas do segmento corporativo.<br /> <br /> A solução é projetada para operar em uma máquina virtual (VM) que possui integração com Kubernetes, OpenShift, Mesos, OpenStack, VMware vSphere, e facilidades de integração com sistemas OSS e BSS.<br /> |-<br /> |'''Huawei Agile SDN Controller'''<br /> |O controlador Agile para campus é a última geração de controladores da Huawei para redes LAN e WAN. <br /> É utilizado em diversas soluções inovadoras, como implantação de rede automática, automação de políticas e SD-WAN.<br /> |-<br /> | colspan=&quot;2&quot; |'''Soluções de Código Aberto, Ferramentas, Sistemas, Linguagens, Protocolos, Procedimentos e Formatos de Dados'''<br /> |-<br /> |'''Ansible'''<br /> |O Ansible é uma ferramenta de provisionamento, gerenciamento de configurações e implantação de aplicativos de software livre. <br /> <br /> O Ansible pode automatizar três tipos de tarefas: provisionamento, gerenciamento de configurações, automação de aplicações. É bastante utilizado tanto em projetos de infraestruturas de redes quanto nas questões relacionadas a servidores e aplicações.<br /> <br /> O Ansible não usa agentes e nenhuma infraestrutura de segurança personalizada adicional, apenas uma linguagem muito simples (YAML, na forma de Ansible Playbooks) que permite descrever seus trabalhos de automação de uma maneira que se aproxima bastante do inglês comum. É uma ferramenta bastante popular!<br /> |-<br /> |'''Chef'''<br /> |Chef é uma ferramenta de gerenciamento de configurações escrita em Ruby e Erlang. O Chef usa uma linguagem específica de domínio, pura em Ruby, para escrever &quot;receitas&quot; na configuração do sistema. <br /> <br /> O Chef transforma a infraestrutura em código, onde você pode automatizar a criação, implantação e gerenciamento da sua infraestrutura, e de forma bastante versátil, testável e repetível. O servidor Chef armazena suas receitas e outros dados de configuração. <br /> <br /> O cliente Chef fica instalado em cada servidor, máquina virtual, container ou dispositivo de rede que você gerencia, chamados de &quot;nodes&quot;. O cliente consulta periodicamente a política e o estado mais recente da sua rede do servidor Chef. Se algo no nó estiver desatualizado, o cliente o atualizará.<br /> |-<br /> |'''Puppet'''<br /> |O Puppet é uma excepcional solução de DevOps para a automação de workloads de infraestrutura e aplicativos, e o gerenciamento contínuo destes. Muito frequentemente o Puppet é usado como ferramenta para gerenciamento de configurações, operando através de uma sofisticada arquitetura Master x Slave.<br /> Em curtas palavras, é composto de uma linguagem declarativa para expressar a configuração do sistema, um cliente e servidor para distribuí-lo, e uma biblioteca para realizar a tarefa de configuração pretendida.<br /> |-<br /> |'''SaltStack'''<br /> |O SaltStack ou &quot;Salt&quot; é uma ferramenta de gerenciamento e orquestração de configurações, fornecendo um repositório central para provisionar novos servidores e outras infraestruturas de TI, incluindo a instalação de software em servidores físicos, virtuais e cloud.<br /> <br /> O SaltStack automatiza tarefas repetidas de implementação administrativa e de código do sistema, eliminando processos manuais de maneira a reduzir os erros que ocorrem quando as organizações de TI configuram e disponibilizam seus sistemas. O Salt é bastante usado por times de DevOps porque extrai o código do desenvolvedor e as informações de configuração de um repositório de código central, como o GitHub ou o Subversion, e envia esse conteúdo remotamente para os servidores.<br /> <br /> Os usuários do Salt podem escrever seus próprios scripts e programas e fazer o download de configurações pré-construídas que outros usuários contribuíram para um repositório público.<br /> |-<br /> |'''CFEngine'''<br /> |CFEngine é um sistema de gerenciamento de configuração de código aberto, e a sua principal função é fornecer facilidades de configuração e manutenção automatizadas de sistemas de computadores em larga escala, incluindo o gerenciamento unificado de servidores, desktops, dispositivos industriais e de consumidor, dispositivos de rede incorporados, smartphones móveis e tablets.<br /> |-<br /> |'''GitLab'''<br /> |O GitLab é uma ótima ferramenta de ciclo de vida de DevOps que fornece um gerenciador de repositório Git, recursos de wiki, rastreamento de problemas e pipeline de CI/CD. Há um artigo em nossa Wiki demonstrando o gerenciamento de configurações de rede com ele.<br /> |-<br /> |'''OpenConfig'''<br /> |OpenConfig é um workgroup e também modelo de comunicação de rede que busca padronizar interfaces de gerenciamento de rede e APIs entre os principais fornecedores/vendors. O OpenConfig segue bem a proposta do que estamos discutindo neste artigo, que é a filosofia do afastamento natural dos administradores das ações de configuração por linha de comando (CLI), onde, cada vez mais, estes profissionais buscam promover configurações baseadas em códigos/programas e indo em direção às redes definidas por software (SDN).<br /> |-<br /> |'''OpenStack'''<br /> |O OpenStack é um sistema operacional que controla grandes pools de recursos de computação, armazenamento e rede em um datacenter, todos gerenciados e provisionados por meio de APIs com mecanismos de autenticação comuns. É impossível citar o termo &quot;SDN&quot; sem que o nome OpenStack seja lembrado, sendo, indiscutivelmente, a solução mais popular para este propósito.<br /> |-<br /> |'''OpenDaylight'''<br /> |O OpenDaylight (ODL) é uma plataforma aberta e modular para a customização e automação de redes de qualquer tamanho, porte e escala. O Projeto OpenDaylight surgiu do movimento SDN, com um foco claro na programação da rede. Foi desenvolvido desde o início como base para soluções comerciais que abordam uma variedade de casos de uso em ambientes de rede existentes, onde o Cisco OSC é um exemplo claro disto.<br /> |-<br /> |'''OpenContrail''' '''(Tungsten Fabric)'''<br /> |O Tungsten Fabric é uma solução de SDN para redes multicloud e automação multi-stack, e de código aberto. Utilizado para fornecer conectividade segura para workloads virtuais, containers ou bare-metal. Possui ótima integração com OpenStack, VMware vCenter, Kubernetes e Redhat Openshift.<br /> |-<br /> |'''Kubernetes'''<br /> |Kubernetes é um formidável sistema de orquestração de containers open source que automatiza a implantação, o dimensionamento e a gestão de aplicações em containers. Foi originalmente projetado pelo Google, e agora é mantido pela Cloud Native Computing Foundation. É um &quot;must have&quot; em ambientes onde containers são fundamentais para os projetos de infraestrutura.<br /> |-<br /> |'''Docker, Jails, LXC, LXD, etc.'''<br /> |FreeBSD Jails, Solaris Zones, LXC, Docker, Rkt, OpenVZ e LXD, enfim, são soluções para containers, cada qual com suas particularidades, propósitos, prós e contras. Está fora do escopo dissertar sobre containers aqui, exceto reforçar que são bastante utilizados em ambientes onde a elasticidade dos ambientes computacionais é cada vez mais exigida, assim como a cada vez maior necessidade por redução de tempo, esforços e custos.<br /> |-<br /> |'''Recursos proprietários de equipamentos'''<br /> |Saiba que o software de seu próprio equipamento de rede (roteador, switch, etc.), tipo o IOS, JUNOS e outros, possui recursos ou funcionalidades que servem para automatizar algum tipo de necessidade ou situação. Citarei alguns exemplos aqui:<br /> Generic Online Diagnostic (GOLD), Cisco Smart Call Home, Cisco Auto Smartports, Cisco IOS Embedded Event Manager (EEM), Zero Touch Provisioning (ZTP), PoAP, Scheduler, TCLsh, dentre muitos outros recursos, são exemplos clássicos de ferramentas/funcionalidades orientadas a algum tipo de automação de tarefa ou procedimento.<br /> <br /> Em combinação com outras tecnologias, soluções ou ferramentas, das tantas citadas nesta tabela, você poderá conquistar ótimos níveis de automação para uma diversidade impressionante de casos e situações.<br /> <br /> OBS: antes que você me questione ou reclame por eu ter citado apenas tecnologias &quot;Cisco&quot; aqui, relaxe: consulte a documentação de &lt;u&gt;'''SEU'''&lt;/u&gt; fabricante, pois é provável que você vá encontrar recursos similares para o seu equipamento! E sem chororô!<br /> |-<br /> |'''OpenFlow'''<br /> |O OpenFlow não é uma &quot;solução&quot; em si, mas sim uma combinação de especificações e protocolo que permite que os controladores de rede determinem o caminho os pacotes em uma rede, e operando no regime de separação entre os planos de controle e de dados, além de permitir o acionamento de ações periféricas tais como listas de controle de acesso (ACLs), protocolos de roteamento, QoS e outros.<br /> <br /> O OpenFlow permite que equipamentos de diferentes fabricantes (ex: switches e roteadores), sendo que cada qual com suas próprias interfaces proprietárias e linguagens de script, sejam gerenciados remotamente usando um único protocolo aberto. Os inventores do protocolo consideram o OpenFlow como um facilitador de redes definidas por software (SDN).<br /> <br /> Dentre outras coisas, o OpenFlow permite a administração remota de tabelas de encaminhamento de pacotes de roteadores, adicionando, modificando e removendo regras e ações de correspondência ou de incidência de pacotes. Dessa forma, as decisões de roteamento podem ser tomadas periodicamente ou por ad hoc pelo controlador, e traduzidas em regras e ações com uma lifecycle configurável, que são, então, aplicadas automaticamente nas tabelas dos equipamentos.<br /> <br /> Apesar de bastante promissor e muito interessante no ponto de vista de pesquisas e estudos, o OpenFlow nunca &quot;deslanchou&quot; como pensávamos que isto fosse acontecer um dia e, para falar a verdade, cada vez mais nos vemos mais distantes de implementá-lo em nossas infraestruturas!<br /> |-<br /> |'''Python'''<br /> |Python é uma linguagem de programação interpretada, orientada a objetos e de alto nível, com uma semântica dinâmica, e sintaxe simples e fácil de aprender. O Python suporta módulos e pacotes, o que incentiva a modularidade do programa e a reutilização de códigos. <br /> É certamente um dos &quot;queridinhos&quot; dos times de DevOps para as necessidades de automação de infraestruturas de redes.<br /> |-<br /> |'''Ruby'''<br /> |Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem dinâmica e forte e com gerenciamento de memória automático, e frequentemente utilizado como linguagem de script. <br /> Seu criador (Yukihiro “Matz” Matsumoto) juntou o &quot;melhor dos mundos&quot; de suas linguagens favoritas (Perl, Smalltalk, Eiffel, Ada, and Lisp) para a criação do Ruby. Muitos projetos bastante atraentes são baseados no Ruby, entre eles o The Metasploit Framework, Sass, Rails, Sinatra, Homebrew, Dicourse, Jekyll, Vagrant e Chef, para citar alguns exemplos.<br /> |-<br /> |'''Application Programming Interface (API)'''<br /> |Um conjunto de requisitos que governa como um aplicativo pode ser usado por outro. Uma API expõe funções internas ao mundo externo, ou seja, permite que outros aplicativos externos utilizem a funcionalidade dentro do aplicativo. O API não é um conceito novo, já que a maioria dos aplicativos modernos tem algum tipo de API. Frequentemente usa autenticação, enquanto a comunicação geralmente usa scripts Java, Python, XML ou HTTP simples, para exemplificar alguns casos. <br /> <br /> As APIs são extremamente fundamentais para ambientes de programabilidade, pois fornecem a devida modularidade, onde os aplicativos podem ser construídos em módulos que podem se comunicar com outros módulos por meio de uma API. Além disto, a abstração, pois permite expor parte das bibliotecas de um programa e ferramentas externas, na condição de orquestradores, os quais podem ser automatizados em um aplicativo ou infraestrutura de forma mais consistente e sem a necessidade de entender as implementações dos dispositivos da infraestrutura. <br /> <br /> E, por fim, a automação, pois as APIs são muito importantes para as tecnologias em nuvem, assim como projetos de infraestruturas de redes bem dinâmicas e elásticas, já que permitem que os recursos e o provisionamento sejam orquestrados por meios destas.<br /> |-<br /> |'''REST / RESTCONF'''<br /> |REST significa &quot;Representational State Transfer&quot;, um estilo de arquitetura para projetar aplicativos em rede que usa HTTP/S para fazer chamadas entre entidades. O REST opera em representações de recursos, cada qual identificado por uma URL, sendo crucial para projetos de infraestrutura prevendo ampla automação de praticamente todas as suas funções. Por exemplo, APIs northbound em SDN são geralmente ou preferencialmente SDN RESTful APIs usadas para a comunicação entre a controladora SDN e os tantos serviços e aplicativos em execução na rede. Essas APIs podem ser usadas para facilitar a orquestração e automação eficientes da rede para o alinhamento com as necessidades de diferentes aplicações, e fazendo isto via esta capacidade de programabilidade da rede SDN.<br /> O RESTCONF é um draft do IETF que procura descrever como mapear uma especificação Yang para uma interface RESTful. Os dados de resposta podem ser em formato JSON ou XML, cujas as estruturas, nestes casos, seguem de acordo com o JSON-YANG e XML-YANG, respectivamente.<br /> |-<br /> |'''NETCONF'''<br /> |O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no &lt;nowiki&gt;RFC 6241&lt;/nowiki&gt;. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações.<br /> <br /> Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração &quot;na mão&quot;. <br /> <br /> Basicamente dependíamos de algumas (ou várias!) gambiarras envolvendo scripts para o lançamento de configurações nos elementos de rede. Em alguns casos, para os mais afortunados, equipados com algumas soluções e componentes proprietários, tais como interfaces Linux embarcadas nos equipamento (tipo guestshell), CLI scraping, dentre outros casos, conseguíamos resultados interessantes. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, &quot;automatizados&quot;, é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho.<br /> <br /> O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, que será apresentado logo a seguir.<br /> <br /> O NETCONF é o que de fato promoveu excepcional capacidade de configuração de elementos de rede para os padrões atuais, em especial a instalação, configuração e manipulação de configurações em uma rede, e é considerado por muitos (inclusive por mim) como a melhor abordagem &quot;interface para o sul&quot; disponível atualmente.<br /> |-<br /> |'''Yang'''<br /> |O YANG é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.<br /> |-<br /> |'''XML'''<br /> |O XML significa &quot;Extensible Markup Language&quot;, e é uma linguagem de marcação muito parecida com HTML, projetada para transportar dados, enquanto o HTML concentra-se mais com a aparência destes dados. O XML requer que você defina suas próprias tags, além de ser projetado para ser auto-descritivo. Note que a natureza de transporte dados do XML o torna um dos formatos mais populares para a troca de dados numa infraestrutura prevendo a programabilidade. O protocolo NETCONF citado anteriormente utiliza este formato de dados.<br /> |-<br /> |'''JSON'''<br /> |JSON significa &quot;JavaScript Object Notation&quot;, que é um formato de dados que usa texto facilmente legível ou interpretável por nós, humanos, para transmitir objetos de dados que consistem em pares de atributo-valor. O JSON é relativamente bem fácil para que máquinas consigam analisar e gerar seu formato, e é construído com base em duas estruturas: pares de nome / valor, e lista ordenada de valores. Assim como o XML, o JSON é bastante popular por ser um formato de dados de fácil leitura e parsing, e é o formato de representação de dados mais usado em REST APIs.<br /> |-<br /> |'''Northbound APIs'''<br /> |Northbound APIs (&quot;APIs para o norte&quot;) são o elo entre os aplicações de TI, tais como os sistemas OSS e BSS, e o controlador SDN. Estas aplicações podem informar à rede sobre o que necessitam, incluindo parâmetros tais como dados, armazenamento, largura de banda, planos de produto, políticas de admissão, etc., fazendo com que a rede então possa fornecer estes recursos ou comunicar o que possui.<br /> <br /> Essas APIs northbound suportam uma ampla variedade de aplicativos, sendo geralmente os componentes mais moldáveis existentes em um ambiente SDN, pois existem muitas interfaces possíveis em diferentes locais das pilhas para controlar diferentes tipos de serviços por meio de uma controladora SDN. Ambientes SDN muito bem sucedidos (leia-se: funcionais de verdade, pra valer!) são aqueles que fazem as melhores integrações entre os sistemas da empresa e os controladores, por meios destas interfaces para o norte.<br /> <br /> Exemplos de serviços de rede que podem ser otimizados via interfaces norte incluem roteadores, switches, concentradores de assinantes de Internet banda larga, firewalls, balanceadores de carga, serviços de segurança definidos por software ou aplicativos de orquestração de recursos da nuvem, etc.<br /> <br /> As APIs Northbound também são usadas para integrar a controladora SDN com pilhas de automação, tais como Puppet, Chef, SaltStack, Ansible e CFEngine, além de plataformas de orquestração, como OpenStack, vCloudDirector da VMware ou CloudStack, de código aberto do Apache, e Cisco NSO. <br /> <br /> Nestes casos, o objetivo é abstrair o funcionamento interno da rede, para que os desenvolvedores de aplicações possam conectar-se à rede visando fazer alterações para acomodar as necessidades da aplicação.<br /> <br /> O maior e melhor exemplo de interface norte aqui seria por Representational State Transfer (REST) API, o qual é baseado em URIs (Uniform Resource Identifier, ou seja, URLs de tipo específico), transportados por protocolo HTTP/S e utilizando rotineiramente o formato de dados em JSON. Há muitas vantagens ao considerar este tipo de interface norte. Outros casos menos conhecidos incluem SMASH, IPMI, WSMAN, e SOAP, mas a lista não para por aí.<br /> |-<br /> |'''Southbound APIs'''<br /> |Equanto uma API Northbound (ou interface para o norte) é uma interface que permite que um componente específico de uma rede se comunique com um componente de nível superior, a API Southbound (ou interface para o sul), por sua vez, permite que um componente de rede específico se comunique com um componente de nível inferior.<br /> <br /> Apenas para constar: ambas as APIs northbound e southbound frequentemente existem em qualquer tipo de infraestrutura de rede ou ambiente computacionai, e não necessariamente, ou não apenas, em ambientes SDN, embora a popularização da SDNs tenha aumentado essa ligação destas APIs para si.<br /> <br /> Um exemplo clássico de API Southbound envolve as especificações para o funcionamento do protocolo OpenFlow, já apresentado previamente. Mas, conforme citado anteriormente, o OpenFlow de fato nunca deslanchou como achávamos que fosse acontecer, então citarei aqui um exemplo melhor: NETCONF! Nada melhor que citar o NETCONF/Yang para ilustrar o conceito de APIs Southbound! Outro exemplo um tanto conhecido disto é o Cisco OnePK.<br /> <br /> Exemplo mais &quot;pobres&quot; (ou menos sofisticados e flexíveis que o NETCONF, por exemplo) de interfaces para o sul seria invocação por procedimentos SSH e SNMP, mas, sabemos, há limitações em usar o SNMP para transportar dados de configuração, por exemplo, e por isto que sou fã incondicional do NETCONF.<br /> |-<br /> |'''Software-Defined Networking (SDN)'''<br /> |Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.<br /> |-<br /> |'''Network Functions Virtualization (NFV)'''<br /> |Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware &quot;''commodity''&quot;. Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado.<br /> |}<br /> Ufa, hein!<br /> <br /> Que tal ilustrarmos alguns destes (principais) componentes?[[Arquivo:Bpf-prog-tools.png|centro|miniaturadaimagem|814x814px|Alguns exemplos ou casos de ferramentas e soluções orientadas aos princípios de programabilidade]]De todas as coisas citadas na &quot;mega-tabela anterior&quot;, focaremos a seguir somente nos componentes que possuem relação direta com '''''&lt;u&gt;infraestrutura de redes&lt;/u&gt;''','' ou seja, dispensando situações envolvendo servidores, máquinas virtuais, containers e aplicações.<br /> <br /> ==== A integração entre dispositivos de redes, gerenciamento de configurações e pilhas de orquestração ====<br /> Já que o artigo tem como principal proposta falarmos de programabilidade e com foco no gerenciamento de configurações, talvez seja prudente comentar aqui as principais diferenças entre algumas das conhecidas soluções para esta necessidade. Lembra que eu comentei anteriormente que, em muitos casos, as plataformas de gerenciamento não atendem integralmente às nossas necessidades, especialmente no que diz respeito ao gerenciamento de configurações? Pois bem, é nessa hora que vale a pena considerar ótimas soluções para administrarmos isto. As mais conhecidas são o Chef, Puppet, Ansible e Salt. A tabela a seguir fornece um comparativo superficial entre eles.<br /> {| class=&quot;wikitable&quot;<br /> |+<br /> Comparativos entre as soluções de gerenciamento de configurações mais populares<br /> !<br /> !Chef<br /> !Puppet<br /> !Ansible<br /> !Salt<br /> |-<br /> |'''Template'''<br /> |Cookbook/Recipe<br /> |Manifest<br /> |Playbook<br /> |States/Pillars<br /> |-<br /> |'''Linguagem'''<br /> |Extensão do Ruby<br /> |Linguagem customizada semelhante ao JSON com opção Ruby<br /> |YAML<br /> |YAML<br /> |-<br /> |'''Licença'''<br /> |Apache<br /> |Apache<br /> |GPL<br /> |Apache<br /> |-<br /> |'''Agente'''<br /> |Requerido<br /> |Requerido<br /> |Não requerido<br /> |Não requerido, porém recomendado (&quot;Minions&quot;)<br /> |-<br /> | colspan=&quot;5&quot; |Confira os comparativos entre as diversas soluções deste tipo aqui:<br /> |-<br /> | colspan=&quot;5&quot; |https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software<br /> |}<br /> Os principais benefícios destas soluções são:<br /> * Automação do provisionamento<br /> * Consistência nas configurações dos elementos de rede<br /> * Controle de versões das configurações, onde a infraestrutura pode ser representada como código<br /> * Código aberto<br /> * Redução dos riscos de indisponibilidade da rede provocados por falha humana<br /> * Redução drástica do tempo de provisionamento de serviços<br /> [[Arquivo:Bpf-prog-puppervsansible.png|centro|miniaturadaimagem|800x800px|Comparativos superficiais entre Puppet e Ansible (Fonte: Cisco)]]<br /> De todas as soluções mostradas na tabela acima, o Ansible possui algumas vantagens a seu favor, incluindo o fato de não requerer agentes nos dispositivos, de ser escrito em Python (uma linguagem de fácil interpretação), de ser simples e fácil de começar a usar, suporte a rede, servidores e aplicações, por possuir uma taxonomia descomplicada, e por ser código aberto. Quanto a taxonomia do Ansible:<br /> * '''''Role''''': um conjunto de Playbooks<br /> * '''''Playbook''''': um padrão de configurações repetitivas<br /> * '''''Play''''': um conjunto de tarefas<br /> * '''''Task''''': uma única ação que é referenciada em um módulo<br /> * '''''Module''''': scripts standalone reusáveis<br /> [[Arquivo:Bpg-prog-ansible.png|centro|miniaturadaimagem|1024x1024px|Visão geral dos principais componentes do Ansible, em um exemplo envolvendo Cisco IOS/IOS XE]]<br /> Como o artigo é introdutório, não detalharei mais sobre o Ansible, e nem sobre outras ferramentas e soluções. Isto será feito naturalmente em futuros artigos aqui no BPF.<br /> <br /> Todavia. já recebemos uma colaboração recente neste sentido: [[Orquestrando sua rede com Ansible e Gitlab]], publicado pelo Renato Oliveira.<br /> <br /> Para finalizar, dependendo das suas necessidades em termos de projetos, facilidades e objetivos a serem conquistados, no que diz respeito ao Ansible, talvez você queira optar pelo [https://www.ansible.com/products/tower Ansible Tower].<br /> <br /> ==== O que é e o que não é o Software-Defined Networking (SDN) ====<br /> Conforme antecipado em outras ocasiões neste artigo, por incrível que possa parecer, não há uma dependência direta entre automação e SDN, neste exato sentido, pois, por exemplo, é possível instrumentar uma rede com bons padrões de automação usando ferramentas e recursos embarcados nos dispositivos da rede, e até mesmo com o auxílio de várias ferramentas, e sem que isto vá exigir controladoras SDN como um OpenStack, por exemplo. Por outro lado, em termos de eficiência de automação com muito foco na orquestração, o SDN possui uma relação direta com toda essa cadeia de programabilidade. Curioso, não? Para automatizar e até mesmo contar com padrões razoáveis de programabilidade na sua rede, o SDN não está necessariamente &quot;presente&quot;, mas, ao considerarmos o SDN, este promoverá um padrão de orquestração e automação incomparáveis, e isto é um fato!<br /> <br /> A propósito, você compreende o mínimo de SDN? Para os mais leigos, isto será bastante apropriado:<br /> * O SDN &lt;u&gt;não&lt;/u&gt; pode ser representado como se fosse um simples &quot;botão&quot;, onde clica-se e temos um ambiente pronto, rodando! Não é bem por aí... e está longe de ser algo deste tipo.<br /> * O SDN tem como uma de suas principais propostas a atenuação drástica dos esforços e complexidades operacionais associados com a &lt;u&gt;''orquestração''&lt;/u&gt;, provisionamento e manutenção de infraestruturas de redes.<br /> * O SDN é um esforço da indústria para a caracterização de redes mais automatizadas, ágeis, elásticas, e empregando menos esforços e custos operacionais, assim como a diminuição de riscos para os negócios das empresas.<br /> * O SDN &lt;u&gt;não&lt;/u&gt; obrigará que você torne-se um programador do dia para a noite, mas saber o essencial de lógica de programação e algumas linguagens de programação será muito útil para você poder destravar potenciais incríveis de seu ambiente!<br /> * O SDN &lt;u&gt;não&lt;/u&gt; substituirá a necessidade da sua empresa em continuar contando com engenheiros e operadores de NOC, muito pelo contrário! Todavia, a tendência é que consolidem-se no setor os profissionais mais especializados e diferenciados. Os negócios precisam evoluir (sempre para melhor), e por que você não pode fazer o mesmo com a sua carreira? <br /> ** Que tal levar a minha sugestão de '''''NetDevOps''''' mais a sério? A hora é essa!<br /> * O SDN originalmente busca promover uma abordagem de arquitetura que realiza uma separação bem legítima entre os planos de controle e de dados (''control plane'' e ''data plane''), levando o estado de informações, juntamente com a inteligência para tomadas de decisões, para um conceito logicamente centralizado. Ou seja, a centralização do estado de informações em uma zona estratégica da infraestrutura, enquanto os dispositivos de redes ficam mais dedicados e especializados em executar o processamento de pacotes e afins.<br /> * O SDN promove excepcional abstração entre a infraestrutura de rede (a qual possui seus serviços mais íntimos, tipo o IGP da infraestrutura, o MPLS, o QoS do backbone, etc.) e as aplicações e demais serviços da rede. E pode oferecer uma separação bastante interessante entre redes '''''underlay''''' e '''''overlay'''''.<br /> * O SDN pode ser representado como um conceito de interfaces programáticas que permitem que sistemas externos influenciem no provisionamento de serviços, controle e operações da rede.<br /> * O SDN fornece novas formas de interação com os equipamentos e serviços da rede via controladoras e APIs (''Application Programming Interface''). Neste caso, por interfaces ''northbound'' e ''southbound''.<br /> * O SDN permite formidáveis capacidades de provisionamento, orquestração, automação e normalização de equipamentos e serviços.<br /> * O SDN pode destravar diversas barreiras do seu negócio ao permitir que agentes externos - devidamente integrados à rede - consigam influenciar nas características de seu projeto e na sua operação, promovendo melhor alinhamento entre as tecnologias empregadas e os resultados almejados pelos modelos de negócios.<br /> * Os cenários de redes SDN podem ser:<br /> ** Uma rede onde os dispositivos retém os seus próprios planos de controle, mas que uma controladora SDN também mantém o estado de informação de protocolos e serviços, podendo influenciar e provisionar serviços sobre a rede. Isto seria o exemplo de uma abordagem híbrida.<br /> ** Uma rede onde todo o plano de controle é centralizado na(s) controladora(s) SDN, enquanto os equipamentos ficam dedicados para as funções de processamento de pacotes. O que seria o caso de uma abordagem SDN &quot;pura&quot;.<br /> ** Uma rede (tipificada como ''Underlay'') onde outras redes completamente distintas e abstraídas são provisionadas sobre ela, o que seria o caso típico das soluções para redes ''Overlay''.<br /> A ilustração a seguir mostra um excelente comparativo entre redes tradicionais e SDN, &quot;''for dummies''&quot; (para os leigos).[[Arquivo:Bpf-prog-sdn-tradicional.png|centro|miniaturadaimagem|800x800px|Comparativos entre redes tradicionais e SDN, para os leigos]]Já a próxima ilustração mostra de forma um tanto simplificada como um ambiente SDN pode ser representado em termos de seus principais componentes:<br /> [[Arquivo:Bpf-prog-sdn2.jpg|centro|miniaturadaimagem|800x800px|Exemplificando um ambiente SDN]]<br /> Exatamente qual ou quais controladoras você consideraria para o seu projeto (OpenStack, OpenDaylight, Contrail/Tungsten Fabric, Cisco OSC, ou algo mais específico (Cisco ACI, Huawei Agile, etc.)), assim como quais interfaces ''Northbound'' você deveria considerar (meus &quot;2 cents&quot;: eu recomendaria sempre que possível por REST API) e quais interfaces Southbound (recomendo sempre que viável o NETCONF/Yang), isto dependerá muito do seu projeto técnico, arquiteturas necessárias, integrações a serem realizadas, customizações, desenvolvimentos adicionais, etc., o que está completamente fora do escopo de um artigo introdutório. <br /> <br /> Para ser bem franco e honesto aqui, é bem factível que num primeiro momento você sequer necessite de um ambiente SDN puro, e talvez uma solução de orquestração devidamente integrada e implementada vá resolver a maior parte dos seus problemas e desafios, se não todos, mas isso, novamente, dependerá do seu projeto e do que se espera para a sua organização. A sua empresa realmente se beneficiaria muito se adotasse, por exemplo, o OpenStack juntamente com o OpenFlow? Você ou o seu time tem ''expertise'' para saber lidar com este padrão de arquitetura e essas soluções?<br /> <br /> Quem sabe uma solução de orquestração de configurações bem integrada à sua rede e sistemas não consiga fazer exatamente aquilo que você esteja buscando para a sua infraestrutura, sem exigir a complexidade de adoção de um OpenStack e OpenFlow? Por exemplo, eu particularmente considero o Cisco NSO excepcional, pois pode ou não ser integrado com controladoras SDN, standalone, ou integrado diretamente para os sistemas OSS e BSS da sua empresa via interfaces ''Northbound'', além de oferecer suporte absoluto multivendor, desde que seus equipamentos suportem NETCONF, o que seria bem razoável para plataformas de primeira linha, e sem que isto fosse necessitar da complexidade das controladoras SDN e do OpenFlow. Inclusive, caso você já possua o Ansible em seu ambiente, é possível integrar um módulo do Cisco NSO no Ansible via uma interface REST para JSON-RPC para que o NSO faça o ''parsing'' dos dados YAML dos Playbooks do Ansible em CDB do NSO, e conduza, na sequência, toda a orquestração pelas interfaces ''Southbound'' (ex: NETCONF/Yang) com os dispositivos da rede, mantendo todo os seus diferenciais e modelos de transações; ''commit dry-run'', ''rollback upon failure'', ''commit'', ''rollback'', relatórios de compliance de configurações, e tantos outros benefícios.<br /> [[Arquivo:Bpf-prog-nso.png|centro|miniaturadaimagem|800x800px|A solução Cisco NSO (Fonte: Cisco)]]<br /> [[Arquivo:Bpf-prog-nso2.png|centro|miniaturadaimagem|800x800px|A solução Cisco NSO integrada à ambientes mais complexos envolvendo Virtualização, Rede e Computação (Fonte: Cisco)]]<br /> Alternativamente ao Cisco NSO, você poderá partir para o Ansible Tower, se preferir, ou para o GitLab, ou as outras sugestões comentadas anteriormente, cada qual com suas vantagens, benefícios, prós e contras. Mas, no final das contas, você inevitavelmente terá que especificar todas as funcionalidades e processos desejados para as suas necessidades de orquestração e automação para poder, depois, selecionar melhor a arquitetura e soluções ideais para o seu projeto, e isto é um fato!<br /> <br /> E, para concluir, a ilustração a seguir mostra os possíveis cenários de SDN.<br /> [[Arquivo:Bpf-prog-sdn3.png|centro|miniaturadaimagem|1024x1024px|Cenários típicos de redes SDN]]<br /> <br /> === Conclusão do artigo ===<br /> O que era para ser um artigo, tornou-se quase um livro! Isto que dá escrever &quot;pelos cotovelos&quot; e sem um roteiro combinado! Sim... muito do que eu publico as vezes aqui na Wiki do BPF são &quot;estalos&quot;, inspirações, que me fazem quase que imediatamente a vir até aqui e sair digitando a torto e a direito, pois, do contrário, a inspiração &quot;esfria&quot;. Aí, durante o processo, um assunto vai puxando o outro e eu não sou muito fã de deixar as coisas incompletas ou mal esclarecidas, o que justifica meus artigos um tanto extensos. Apesar dessa dinâmica um tanto improvisada que tenho as vezes, é a minha &quot;cachaça&quot;! Estou perdoado?<br /> <br /> Espero que as informações apresentadas aqui tenham sido úteis para ajudá-lo a se interessar pelo tema e a embarcar no universo ''NetDevOps''!<br /> <br /> Propositalmente deixei de fora vários exemplos e detalhamentos acerca de algumas coisas muito importantes envolvendo o NETCONF/Yang, RESTCONF, XML e JSON, etc., e até mesmo das soluções citadas, tipo o Ansible, Puppet, Cisco NSO, e outras, pois isto tornaria o artigo realmente muito gigantesco. Mas, fique tranquilo, produzir artigos sobre estes temas, fornecendo demonstrações e tudo mais, está definitivamente no radar do Comitê de Programa do Brasil Peering Forum (BPF)!<br /> <br /> Obrigado por acompanhar o nosso trabalho, e contamos com você para promover e divulgar cada vez mais os conteúdos de nossa Wiki. Compartilhe sem dó nem piedade! Desejamos continuar contribuindo para o desenvolvimento dos provedores de acesso à Internet e, por tabela, tanto quanto, de qualquer empresa e de qualquer segmento que esteja buscando em nossa Wiki os conhecimentos necessários para a transformação de suas infraestruturas.<br /> <br /> Um abraço!<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Infraestrutura]]<br /> [[Categoria:SDN]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Introducao_aos_conceitos_de_programabilidade_de_infraestruturas_de_redes&diff=2513 2020-06-14T22:31:49Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Este artigo apresentará fundamentos importantes acerca do gerenciamento de redes, em especial a disciplina de configurações, e pavimentará a sua jornada, caro leitor da Wiki do BPF, para as questões de programabilidade de infraestruturas de redes e com foco aos ambientes de ISP. Este é mais um daqueles artigos que publico na Wiki do BPF onde a principal intenção ou motivação é '''''ensinar, educar, e capacitar''''' e, portanto, o artigo não vai direto ao ponto: conto uma história primeiro, volto no tempo para mostrar algumas coisas e eventos importantes e, lá para o final, é que comento com mais propriedade sobre os aspectos de programabilidade pretendidos por este artigo. Esta abordagem mais didática poderá ser melhor apreciada por leitores mais &quot;leigos&quot;.<br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo!<br /> [[Arquivo:Bpf-prog-cover.png|centro|miniaturadaimagem|800x800px|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes: comparando a rede ideal versus os modelos tradicionais]]<br /> <br /> === Pré-requisitos ===<br /> A leitura deste artigo fará muito mais sentido caso você reúna determinados pré-requisitos em termos de conhecimentos técnicos. Recomendo que certifique-se de possuir os conhecimentos equivalentes aos temas discutidos nos seguintes artigos, já publicados na Wiki do Brasil Peering Forum (BPF).<br /> * [[Fundamentos de Roteamento para Provedores]]<br /> * [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]<br /> * [[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]]<br /> <br /> === Precisamos evoluir: continuar configurando e operando ambientes de redes complexos da mesma forma em que temos feito por décadas, pra que? ===<br /> Você já parou para pensar que, toda a vez que você recebe uma solicitação para a ativação de serviço, uma série de cuidados precisam ser observados? Você precisa gerir a demanda através de várias ações estritamente manuais, incluindo a projeção da mudança, produção do roteiro de configurações, classificação dos impactos, revisão de capacidades, reserva de recursos, a efetiva aplicação de blocos inteiros de configurações sobre um ou mais elementos de rede, além de fazer o arquivamento daquela mudança, acompanhamento, monitoramento e, eventualmente, o suporte. Você provavelmente deve ter uma noção que há muitos riscos e complicações durante todo este processo, mas que, de certa forma, estamos mais que habituados a isso. É uma questão cultural, algo que nos acompanha por muitos e muitos anos. Quanto a esta evolução proposta, eu passarei a fornecer algumas boas justificativas para que você possa compreender melhor a minha visão, e também o direcionamento de mercado, sobre esta redefinição de nossas práticas operacionais:<br /> {| class=&quot;wikitable&quot;<br /> |+Como a programabilidade de redes poderá ajudar a superar os principais desafios dos modelos de operação tradicionais<br /> !Situação<br /> !Descrição<br /> |-<br /> |'''Atenuação da complexidade operacional'''<br /> |Embora não seja exatamente a realidade de todas as empresas, talvez nem da sua, neste caso, o fato é que há muitos ambientes computacionais verdadeiramente complexos, repletos de muitos componentes.<br /> &quot;Abarrotados&quot; de equipamentos tais como roteadores, switches, firewalls, balanceadores de carga, filtros de conteúdo, appliances de segurança, servidores, storage, além de bancos de dados, aplicações, desktops, unidades de vídeo-conferência, sistemas de comunicação multimídia diversos, controladores WiFi, pontos de acesso, etc.!<br /> <br /> Cada um destes exigindo configurações, muitas! E todos estes componentes e dispositivos necessitando se comunicar através de uma diversidade muito grande de tecnologias, incluindo protocolos, serviços de infraestrutura e de transporte, computação, storage, aplicação e afins.<br /> <br /> Na grande maioria das empresas as manobras de configuração são conduzidas por processos completamente manuais, mesmo que, em alguns ou muitos casos, de forma organizada e pautada, ou seja, seguindo processos, boas práticas, modelos funcionais, documentações, etc.<br /> <br /> No entanto, na medida em que estas redes crescem, seja em quantidades de desktops/usuários ou de servidores, ou, principalmente, a diversidade de soluções tecnológicas presentes, todo o ambiente começa a ficar realmente bem mais complicado para se manter.<br /> <br /> Toda esta complexidade operacional pode ser brutalmente atenuada com tecnologias de programabilidade de infraestruturas.<br /> |-<br /> |'''Redução massiva do tempo de provisionamento de serviços'''<br /> |Uma realidade para praticamente qualquer empresa, mas, certamente, um dos principais indicadores de performance do negócio dos provedores de acesso à Internet e também dos provedores de conteúdo: o tempo requerido para provisionar e ativar um serviço contratado por um cliente.<br /> Geralmente todo um fluxo de trabalho precisa ser cumprido para que a demanda possa ser devidamente compreendida, e uma cadeia de aprovação da mudança é estabelecida para que times específicos produzam os roteiros de configurações necessários, e isto tende a ser executado em horários específicos, ou seja, sempre levando um longo tempo entre a iniciação, ou solicitação da demanda, e a sua execução/conclusão.<br /> <br /> Infraestruturas ágeis, que contam com amplas capacidades de orquestração e automação, conseguem provisionar serviços muito mais rapidamente do que estes ambientes tradicionais e estáticos, podendo ser até mesmo instantaneamente, dependendo dos processos que estiverem estabelecidos pela organização.<br /> |-<br /> |'''Redução drástica dos esforços operacionais associados às tarefas de configuração e provisionamento'''<br /> |Não é simplesmente uma questão de &quot;configurar alguma coisa na rede&quot;, mas sim de compreender o que precisa ser configurado, quais recursos ou funcionalidades, quais elementos, dispositivos e sistemas precisam ser modificados para a viabilidade da ativação daquele serviço, interpretar características de sintaxe e semântica, compatibilidades, integração; se há ou não um padrão ou modelo homologado para cumprir com estas tarefas de provisionamento, etc.<br /> Isto sem dúvida alguma exige mais que apenas esforço, tempo ou prazo: exige conhecimento; o domínio destas tecnologias, e a compreensão das relações e interdependências de cada caso, o que acentua ainda mais a necessidade por maior conhecimento e domínio das tecnologias utilizadas.<br /> <br /> E todo o trabalho executado nestas manobras desprende algum esforço, pouco ou muito, não me atreverei a mensurar por aqui, pois há casos e casos.<br /> <br /> Indiscutivelmente redes programáveis nos moldes sugeridos por este artigo reduzem em pelo menos 90% dos esforços operacionais que normalmente são exigidos ou desprendidos em ambientes de redes tradicionais.<br /> |-<br /> |'''Redução drástica dos riscos de negócios associados aos possíveis e frequentes downtimes'''<br /> |Como se não bastasse a complexidade e esforços operacionais, além do tempo/prazo, temos ainda que nos preocuparmos com possíveis impactos que são frequentemente decorrentes de erros provocados por falha humana durante as ações de configuração e provisionamento de serviços.<br /> É verdade que muitos destes riscos podem ser reduzidos com o auxílio de processos e práticas consistentes de gestão de mudanças (vide recomendações do COBIT/ITIL).<br /> <br /> Mas nada superará a confiabilidade de um provisionamento executado por meios de tecnologias e ferramentas de orquestração e automação, sendo isto um dos maiores atrativos da programabilidade de infraestruturas.<br /> |-<br /> |'''Maior agilidade e elasticidade para a disponibilidade e oferta de soluções mais complexas sobre a infraestrutura'''<br /> |O tempo que se gasta &quot;remando contra a maré&quot; e conduzindo extensas e monótonas configurações manuais pode muito bem ser empregado para &quot;destravar&quot; muitas oportunidades para a incorporação de soluções mais atraentes e de alto valor agregado para os seus clientes.<br /> A combinação de múltiplas ofertas de produtos e serviços para os clientes de um ISP frequentemente exige a integração de sofisticadas e complexas plataformas e soluções tecnológicas, o que tende a impulsionar ainda mais os casos citados anteriormente nesta tabela, ou seja, maior complexidade, maior esforço, maiores custos operacionais, maior prazo para go-to-market, maiores riscos de indisponibilidades, etc.<br /> <br /> Quando pensamos em infraestruturas altamente programáveis, conseguimos estender as capacidades de orquestração e automação para contemplar, além da rede, a parte de computação, incluindo servidores, storage e aplicações, e isto promove um salto tecnológico tremendo para os anseios de competitividade e atratividade da empresa.<br /> |}<br /> <br /> === Prepare-se para tornar-se um NetDevOps! ===<br /> Eu explico. Há uma diferença muito grande entre o dinamismo presente nos ambientes computacionais envolvendo servidores virtuais, containers, aplicações, e a infraestrutura de redes. As redes que costumamos ver por aí geralmente possuem características operacionais muito mais estáticas do que esta área de servidores, desenvolvimento de software e aplicações, mas não em todos os casos, claro. Para fornecer um exemplo, por anos temos conseguido disponibilizar workloads inteiros em ambientes virtualizados em questão de minutos e com apenas alguns cliques, e, enquanto isso, as manobras necessárias sobre a infraestrutura da rede para acomodarmos estes workloads são geralmente feitas seguindo modelos estáticos de configuração, repletos de procedimentos manuais, caixa por caixa, CLI por CLI. Obviamente, há exceções à regra. Mas dá tranquilamente para generalizar desta forma.<br /> <br /> Toda a vez que novas aplicações ou serviços são disponibilizadas para usuários internos e/ou externos, o que não é muito complicado de fazermos em função da versatilidade das ferramentas usadas hoje em dia, a rede precisa acompanhar o roteiro e &quot;acomodar, compatibilizar e viabilizar&quot; aquele serviço, ou seja, sofrer as configurações necessárias incluindo a VLAN, entroncamento da VLAN, roteamento IP, ACL, QoS e o que mais tiver que ser feito. Pois bem, novamente, a diferença é que na camada de computação as coisas são usualmente mais dinâmicas, enquanto a rede, na maioria das empresas, ainda precisa ser tratada de forma bem estática e manual.<br /> <br /> Você provavelmente já ouviu falar de ''DevOps'', mas, caso não saiba, o ''DevOps'' pode ser tratado como uma cultura de desenvolvimento de aplicações de TI, uma revolução na questão de processos de desenvolvimento de software, fazendo com que equipes de desenvolvimento (Dev) e equipes de operações (Ops) trabalhem juntas e em regime de estreita colaboração. Consequentemente, a adoção ágil por meios de implementação contínua e melhorias da infraestrutura de desenvolvimento promove uma oferta bem mais acelerada dos serviços de TI.<br /> <br /> Nesta seara de ''DevOps'' é que notamos um monte de coisas relacionadas ao ''Agile'', automação por pipelines de CI/CD (''Continuous Integration / Continuous Delivery'') e CI/CD/CD (''Continuous Integration/Continuous Delivery/Continuous Deployment''), coisas que provavelmente você já ouviu falar por aí. Pois, então, note que normalmente há um desvio muito expressivo entre estas práticas de agilidade dos times de desenvolvimento de software e as práticas adotadas pelos times de engenharia e operação de redes. Para exemplificar aqui, quaisquer alterações inadequadas que por ventura forem realizadas sobre as configurações de equipamentos de rede podem resultar em muitos problemas desnecessários, afetando negativamente aplicações e times de desenvolvimento, e tornando a situação mais complexa para estas equipes poderem lidar. E é a partir daí que os pipelines citados, ''Agile'', ''DevOps'', CI/CD e testes de unidade automatizados ajudam a superar esses desafios. O que até então era uma exclusividade dos times de desenvolvimento de software passou a ser portado para atender, também, os times responsáveis pela engenharia e operação de redes. E aí nasceu um novo paradigma chamado '''''NetDevOps'''''.<br /> <br /> Em curtas palavras, o '''''NetDevOps''''' pode ser definido como uma interseção de ''Rede'' e ''DevOps'', por meios de uma comunicação aberta e feita através da automação, e usando princípios de '''''Infraestrutura como Código''''' (IaC) ou &quot;''Infrastructure as Code''&quot;.<br /> <br /> Caso você ainda não faça a menor idéia do que eu esteja dissertando por aqui, quem sabe uma representação visual destes conceitos não vá esclarecer melhor?<br /> [[Arquivo:Bpf-prog-agiledevops.png|centro|miniaturadaimagem|800x800px|Agile, DevOps (Fonte: Cisco Live)]]<br /> Ao trazermos para os times de engenharia e operações de redes estas consagradas culturas e práticas utilizadas pelos times de desenvolvimento de software e, ao portarmos as nossas habituais tarefas de configuração de dispositivos - normalmente feitos, conforme já comentado, por CLI ou interface GUI/WebUI - para ''&lt;u&gt;código&lt;/u&gt;'', conseguimos viabilizar excepcionais capacidades de automação e orquestração, que são responsáveis por fornecer as almejadas agilidade, eficiência e confiabilidade para lidarmos com maestria com os serviços de TI em ambientes críticos. Consequentemente, conseguimos eliminar as barreiras entre os times de TI da organização (desenvolvimento de software, servidores, bancos de dados, redes), promover maior fluidez para a entrega de serviços de TI, e tudo isto exigindo muito menos prazo e esforço para a entrega destes serviços, e sem contar com a maior confiabilidade das operações, redução de riscos e impactos para os negócios, e tão cobiçada redução de custos.<br /> <br /> Para preparar o seu prato de '''''NetDevOps''''', misture numa panela o Agile, CI/CD, infraestrutura como código (IaC), ferramentas e soluções de automação e orquestração, mas não se esqueça de alguns ingredientes consagrados (boas práticas do COBIT/ITIL, lifecycle e outros frameworks funcionais necessários), tempere tudo com &quot;Sazón&quot;, mexa bem, e estará pronto para servir. Você terá a oportunidade de experimentar um universo completamente novo de programabilidade de infraestruturas de redes e usufruirá de resultados indiscutivelmente melhores.<br /> <br /> ==== Por que não usar ambos o CLI com scripting e o protocolo SNMP para realizar as configurações da rede? ====<br /> Antes que você me faça essa pergunta, permita-me antecipar os seguintes pontos:<br /> * O scripting por CLI requer um bom esforço para comunicar particularidades de sintaxes e semânticas em ambientes heterogêneos, e a revisão e manutenção destes scripts é um trabalho igualmente estático e manual.<br /> ** Não que scripts sejam ruins, não é isso! Mas a proposta do artigo aqui é tratamos da evolução de certos procedimentos operacionais, certo?<br /> * O scripting por CLI peca muito por outra razão até mais importante ainda: a ausência de gerenciamento de transações.<br /> ** Quando você for provisionar, quais scripts você precisa invocar, quais equipamentos estes scripts acionarão, como você tratará as diferentes sintaxes?<br /> ** Apesar de você estar usando um script, ou vários, todo o trabalho tende a ser manual neste sentido, quando indicando quais equipamentos precisarão receber e quais configurações,<br /> ** E se alguma coisa der errado, qualquer coisa, inclusive algo que pode parar a sua rede ou provocar distúrbios graves, como os seus scripts lidarão com isso? <br /> ** Esta ausência de gerenciamento de transações dificulta muito contarmos com um controle decente de revisões de configuração, auditoria de quem fez, quando e onde, o que de fato foi modificado nestas configurações, e não possui facilidades de ''rollback'', para simplificar aqui o meu ponto de vista.<br /> * O scripting por CLI também carece de um gerenciamento estruturado de falhas que por ventura possam acontecer quando aplicando os comandos na CLI dos equipamentos, seja por questões de sintaxe, semântica, ou outros. <br /> ** Isto é muito fácil de acontecer principalmente após a atualização de software dos equipamento, e o seu script muito provavelmente não saberá lidar com isto e não saberá desfazer a configuração parcial que foi implementada, o que poderá ser desastroso em alguns casos.<br /> * O scripting por CLI apresenta um desafio relacionado as eventuais mudanças nas sintaxes do software de um determinado equipamento, o que poderá ser preocupante, agora imagine isto em um ambiente multivendor.<br /> ** Você terá dificuldades em manter e certificar-se que seus scripts invoquem as sintaxes corretas para todos os equipamentos e em suas respectivas versões de software.<br /> * O protocolo SNMP, se comparado ao CLI, com ou sem scripting, é ainda mais deficiente: embora o SNMP tenha sido projetado para realizar o gerenciamento com suporte à escrita (communities com permissão &quot;Write&quot;), ele só é eficiente mesmo para o gerenciamento de falhas e para o gerenciamento de desempenho. Para o gerenciamento de configurações, é um tanto desastroso.<br /> * O protocolo SNMP não fornece capacidades legítimas de auto-descoberta capazes de localizar as MIBs corretas dos dispositivos gerenciados, e isto significa que você, o administrador da rede, é quem terá o trabalho manual de identificar quais MIBs são compatíveis e para quais finalidades, e fazendo isso para todo o tipo de equipamento da sua rede.<br /> ** Se para o gerenciamento de falhas e de desempenho isto já dá um trabalho, você talvez não queira imaginar o quanto isto é custoso para o gerenciamento de configurações.<br /> * As MIBs do protocolo SNMP frequentemente não possuem os OIDs que necessitamos para configurarmos um monte de coisas ou recursos nos equipamentos da rede.<br /> * Esta complexidade toda e várias limitações são os principais motivos pelos quais os administradores de redes terem abandonado por completo o SNMP para fins de gerenciamento de configurações.<br /> * O protocolo SNMP também não é diferente da CLI no que diz respeito à ausência de gerenciamento de transações. Logo, portanto, as mesmas situações discutidas no caso do CLI também são válidas para o SNMP.<br /> * O protocolo SNMP é transportado pelo UDP, e isto significa que está suscetível a perda de mensagens na rede. Dependendo do caso, operações parciais podem ser implementadas, deixando um lastro de manobras incompletas durante um provisionamento de serviços, o que não seria nada bom para os nossos propósitos de consistência de configurações e disponibilidade da rede.<br /> Sobre o meme a seguir: não vista a carapuça!<br /> [[Arquivo:Bpf-prog-cover2.png|centro|miniaturadaimagem|800x800px|&quot;Deuzulivre&quot;!]]<br /> <br /> === Revisão dos principais conceitos e componentes de uma infraestrutura de redes Metro e IP ===<br /> Para falarmos melhor sobre programabilidade, automação e orquestração, especialmente se você, leitor, estiver começando nesta área de redes, talvez seja prudente regredirmos um tanto e esmiuçarmos como as coisas acontecem de fato no modelo tradicional de operação de redes. Pensando assim, que tal fazermos uma boa revisão sobre os principais componentes e conceitos presentes em uma infraestrutura de redes? Ao término do artigo, talvez esta seção tenha sido bastante útil para você entender melhor as complicações no que diz respeito à manutenção das infraestruturas de redes, e como as tecnologias e ferramentas de programabilidade poderão drasticamente atenuar os esforços, prazos, complexidades e custos operacionais.<br /> <br /> ==== Dispositivos de rede ====<br /> Em uma rede de ambiente ISP (aka &quot;''service provider''&quot;) é comum encontrarmos os seguintes tipos de equipamentos ou elementos ativos, que são referências aos dispositivos de rede:<br /> * '''Roteadores:''' devidamente categorizados por suas funções e missões, em especial em alinhamento com uma infraestrutura de redes hierárquica, modular e estruturada, ou seja roteadores de Acesso, Pré-Agregação, Agregação, Core, Borda de Serviços e Borda de Internet, e também os roteadores de clientes, sejam estes de propriedade do ISP (comodato) ou mantidos e gerenciados pelo próprio cliente. Aqui entram os conhecidos termos '''''CE''''' ou '''''CPE''''' (''Customer Premises Equipment''), '''''PE''''' (''Provider Edge''), '''''P''''' (''Provider''), e cada um destes, além de seu respectivo posicionamento na hierarquia topológica física e lógica da rede, desempenhando funções tais como ''LSR'' (''Label Switch Router''), ''LER'' (''Label Edge Router''), ''BNG'' (''Broadband Network Gateway''), dentre outros casos.<br /> * '''Switches:''' praticamente a mesma coisa com relação aos roteadores no que diz respeito ao seus posicionamentos em uma rede, hierarquia e afins. Podendo ser elementos ativos desempenhando funções de encaminhamento de dados puramente de Camada 2 (L2), neste caso o processamento dos quadros (''frames''), ou multicamadas (L3), neste caso o processamento de pacotes, em ambientes Ethernet ou Ethernet + IP nativos, ou ainda em ambientes MPLS.<br /> * '''GPON''': sumarizando aqui os dispositivos desta infraestrutura, incluindo '''''OLT''''' (''Optical Line Terminal''), '''''ONU''''' (''Optical Network Unit''), '''''ONT''''' (''Optical Network Terminal''), e, por que não, toda a parte passiva (leia-se: não ativa) da infraestrutura, denominada ''Optical Distribution Network'' (ODN), e que abrange as fibras ópticas e passivos ópticos, como splitters, conectores, cordões, extensões, caixas de emenda e terminação.<br /> [[Arquivo:Bpf-prog-routers.jpg|centro|miniaturadaimagem|800x800px|Dispositivos de rede Metro Ethernet, IP, MPLS: roteadores e switches]]<br /> <br /> ==== Protocolos e serviços de infraestruturas de redes ====<br /> Uma coisa são os dispositivos de redes mencionados anteriormente, outra coisa são as tecnologias (embarcadas nestes dispositivos) que viabilizam o funcionamento de uma rede, em especial no que diz respeito à comunicação e convergência necessária entre os elementos ativos para o transporte efetivo do tráfego da rede e dos serviços contratados por seus usuários. Nem de longe atreverei-me a listar tudo, pois isto seria completamente inviável! Elencarei apenas alguns exemplos, pois uma listagem completa mencionando todas as tecnologias produziria um artigo quilométrico!<br /> <br /> O arranjo destas tecnologias, devidamente organizadas em suas respectivas categorias funcionais, é o que costumo chamar de &quot;'''''Salada de Tecnologias'''''&quot;!<br /> * '''Protocolos e serviços de camada 2 (L2):''' como menção ao modelo de referência OSI (RM-OSI) ou ao modelo de referência TCP/IP, são tecnologias primariamente envolvidas com a construção e manutenção de uma infraestrutura redundante (com foco na maior disponibilidade) isenta de ''bridging loops'', e com capacidades de recuperação de falhas envolvendo enlaces de transmissão ou dos próprios elementos de rede. Exemplos de tecnologias assim: ''Spanning Tree Protocol'' (e suas variações, 802.1d ('''''STP'''''), 802.1w ('''''RSTP'''''), 802.1s ('''''MSTP'''''), 802.1aq (''Shortest Path Bridging'' ('''''SPB'''''), e revisões incorporadas ao '''''802.1Q-2014''''', ''Resilient Ethernet Protocol'' ('''''REP''''', proprietário), ''Ethernet Automatic Protection Switching'' ('''''EAPS''''', proprietário), '''''G.8032''''' (''Ethernet Ring Protection (ERP) protocol''), coexistência de ''Inter-Chassis Communication Protocol'' ('''''ICCP''''') e STP, etc. E, claro, não poderia deixar de mencionar aqui o mais óbvio, que são tecnologias mais básicas e elementares tais como o próprio endereçamento físico (''Media Access Control'' ('''''MAC''''')) dos dispositivos, ''Virtual LAN'' ('''''VLAN'''''), entroncamento '''''802.1q''''' e '''''802.1ad''''' (''Q-in-Q''), operações flexíveis com tags de VLAN (''Flexible VLAN Tags'', ''Ethernet Flow Point ('''EFP''')''), circuitos Ethernet Virtuais (''Ethernet Virtual Circuit'' ('''''EVC''')''), etc. E isto focando apenas no óbvio, pois há uma gama muito grande de tecnologias e serviços que implementam funções ou que atuam na camada 2. E, para concluir, '''''L2VPN''''' (VPLS, VPWS, EVPN) também são exemplos de tecnologias para o transporte de tráfego/serviços L2 em uma rede MPLS (VPLS/VPWS/EVPN) ou VxLAN (''EVPN''). ''Generic Routing Encapsulation'' ('''''GRE'''''), ''Layer 2 Tunneling Protocol'' ('''''L2TP'''''), ''Layer 2 Protocol Tunneling'' ('''''L2PT'''''), ''Point-to-Point Tunneling Protocol'' ('''''PPTP''''') são outros exemplos clássicos e que empregam conceitos de túneis.<br /> * '''Protocolos e serviços de camada 3 (L3):''' também em alinhamento ao RM-OSI, são tecnologias que tem como propósito a construção e manutenção de uma rede IP &quot;roteada&quot;, convergida e isenta de ''routing loops''. Enquadram-se aqui o endereçamento '''''IPv4''''' e '''''IPv6''''', protocolos de roteamento dinâmicos (ex: '''''OSPF''''', '''''IS-IS''''', '''''EIGRP''''', '''''BGP''''', '''''RIPv2''''' para IPv4, e '''''RIPng''''', '''''OSPFv3''''', '''''IS-IS for IPv6''''', '''''EIGRP for IPv6''''', '''''BGP''''' para o IPv6), além de rotas conectadas, rotas estáticas, serviços de roteamento por políticas ('''''PBR''''', ABF ou nome similar usado pelo seu fabricante de equipamento). Enquadram-se também, à título de serviços L3, mas com algumas destas tecnologias implementando funções também em outras camadas, os seguintes: ''Network Address Translation'' ('''''NAT'''''), ''Carrier Grade NAT'' ('''''CGN'''''), ''Broadband Network Gateway'' ('''''BNG''''', como concentrador PPPoE e/ou IPoE).<br /> * '''Protocolos e serviços orientados à confiabilidade, resiliência e disponibilidade:''' compreenda estes como serviços periféricos e pensados para melhorarmos a confiabilidade geral da infraestrutura, seja em cenários L2 ou L3, ou ainda ambos. Exemplos de tecnologias que enquadram-se aqui temos o ''Unidirectional Link Detection'' ('''''UDLD'''''), ''Bidirectional Forwarding Detection'' ('''''BFD'''''), ''In-Service Software Upgrade'' ('''''ISSU'''''), ''Online Insertion and Removal'' ('''''OIR'''''), ''Stateful Switchover'' ('''''SSO'''''), ''Nonstop Forwarding'' ('''''NSF''''') ou ''Graceful Restart'' ('''''GR'''''), ''Non Stop Routing'' ('''''NSR'''''), ''MPLS Traffic Engineering Fast Reroute'' ('''''FRR'''''), ''Topology Independent LFA'' ('''''TI-LFA''''') e RLFA, ''Segment Routing TI-LFA'' ('''''SRTILFA'''''), ''Link Aggregation Control Protocol'' ('''''LACP'''''), enfim, são exemplos clássicos. Outros exemplos aqui incluem os protocolos de resiliência de primeiro salto ou de default gateway, conhecidos por FHRP (''First Hop Redundancy Protocol''), tais como o '''''HSRP''''' (''Hot Standby Router Protocol''), '''''VRRP''''' (''Virtual Router Redundancy Protocol'') e '''''GLBP''''' (''Gateway Load Balancing Protocol''). Isto para não mencionar os mecanismos periféricos presentes em outros protocolos já apresentados, como, por exemplo, o '''''OSPF LSA e SPF Throttling''''', '''''BGP Prefix Independent Convergence (PIC)''''', etc.<br /> * '''Protocolos e serviços de suporte à infraestrutura:''' enquadram-se aqui protocolos e serviços incluindo o '''''PPPoE''''' (''Point-to-Point Protocol over Ethernet''), '''''IPoE''''' (''Internet Protocol over Ethernet''), '''''DHCP''''' (''Dynamic Host Configuration Protocol''), '''''DNS''''' (''Domain Name System)'', '''AAA''' (''Authentication, Authorization, Accounting''), '''''RADIUS''''' (''Remote Authentication Dial In User Service''), '''''TACACS+''''' (''Terminal Access Controller Access-Control System''), '''''Diameter''''', '''''NTP''''' (''Network Time Protocol''), '''''PTP''''' (''Precision Time Protocol''), '''''SyncE''''' (''Synchronous Ethernet''), e tantos outros. As tecnologias com foco no ''Quality of Service'' ('''''QoS''''') também podem ser descritas aqui.<br /> * '''''Protocolos e serviços de gerenciamento:''''' figuram aqui, dentre tantos, o ''Simple Network Management Protocol'' ('''''SNMP'''''), ''Remote Network MONitoring'' ('''''RMON''''') ''MIB'', '''''Netflow''''', ''Internet Protocol Flow Information Export'' ('''''IPFIX'''''), ''Telnet'', ''Secure Shell'' ('''''SSH'''''), ''SSH File Transfer Protocol'' ('''''SFTP'''''), ''Operations, Administration and Maintenance'' ('''OAM''') incluindo ''Ethernet OAM Link Fault Management'' ('''''EOAM LFM'''''), ''802.1ag Connectivity Fault Management'' ('''''CFM'''''), ''Ethernet Local Management Interface'' ('''''E-LMI'''''), ''Ethernet Performance Management'', '''''MPLS OAM'''''; ''Network Configuration'' e modelos Yang ('''''NETCONF/Yang'''''), interface ''RESTful'' para a modelagem ''Yang'' com '''''RESTCONF''''', ''Technical Report 069'' ('''''TR-69''''') e substitutos, dentre tantos outros protocolos, serviços e procedimentos.<br /> * '''Protocolos e serviços de segurança da infraestrutura:''' há tantos casos para citar aqui, tentarei ser bem prático. '''''Port Security''''', '''''802.1X IBNS''''', '''''MACsec''''', ''Network Admission Control'' ('''''NAC'''''), '''''Private VLAN''''', ''Dynamic ARP Inspection'' ('''''DAI'''''), '''''DHCP Snooping''''', ''IP Source Guard'' ('''''IPSG'''''), '''''Root Guard''''', '''''BPDU Guard''''', '''''BPDU Filtering''''', ''mecanismos de autenticação dos protocolos de roteamento'', ''mecanismos de autenticação de protocolos MPLS'' (LDP e RSVP-TE), ''filtros e políticas de roteamento'', '''''BGP Flowspec''''', ''Remotely Triggered Black Hole'' ('''''RTBH'''''), '''''stateful packet filtering''''', ''BGP Resource Public Key Infrastructure'' ('''''RPKI'''''), ''Control Plane Policing'' ('''''CoPP/dCoPP'''''), ''Broadcast, Unicast and Multicast'' (BUM) '''''Storm Control''''', ''limitação de prefixos mantidos em tabelas de roteamento'', ''Unicast Reverse Path Forwarding'' ('''''uRPF'''''), e muitos outros. E isto com relação às tecnologias apenas, sem considerar os ''appliances'' (dispositivos) de segurança que embarcam estas tecnologias e serviços, tais como firewalls, UTMs, etc.<br /> [[Arquivo:Bpf-prog-tecnologias-isp.png|centro|miniaturadaimagem|1235x1235px|Que &quot;salada&quot; de tecnologias! É tanta coisa que temos que nos preocupar em fazer funcionar corretamente e conforme as boas práticas!]]<br /> <br /> ==== Sistemas e serviços de suporte à infraestrutura ====<br /> A lista de situações aqui é mais simples, mas não menos complexa:<br /> * Sistemas de Suporte ao Negócio ('''''BSS''''')<br /> * Sistemas de Suporte à Operação ('''''OSS''''')<br /> * Serviços de Diretório (ex: '''''LDAP''''', '''''Active Directory''''')<br /> * Infraestrutura ''Public Key Infrastructure'' ('''''PKI''''')<br /> * Sistemas específicos de serviços de segurança ('''''RADIUS''''', '''''TACACS+''''', '''''AAA''''', '''''NAC''''' e afins)<br /> * Sistema de ''IP Address Management'' ('''''IPAM''''')<br /> * Sistemas específicos para fins de gerenciamento de elementos e de infraestrutura ('''''EMS''''' e '''''NMS'''''), com baixa ou parcial aderência aos padrões OSS.<br /> * Etc.<br /> [[Arquivo:IBM CDOMS-00.png|centro|miniaturadaimagem|1024x1024px|Exemplo de integrações de sistemas OSS e BSS, demonstrando a solução IBM Catalog Driven Order Management Solution. Note o &quot;SID&quot;, um dos frameworks do TM Forum Frameworx!]]<br /> OBS: no segmento de ISPs regionais de pequeno e médio portes é onde compreendemos, também, uma diferença bastante acentuada entre os padrões de sistemas empregados por estes quando comparados aos sistemas de gestão operacional e de negócios dos operadores de redes &quot;grandes&quot;. Nos ISPs regionais, é muito mais comum o uso de sistemas para missões bem específicas e que operam de forma completamente independente e com nenhuma ou mínima troca ou compartilhamento de dados entre si, mesmo que funcionais para a realidade desta empresas. No entanto, a ausência das devidas e desejadas integrações entre estes sistemas (vide ''Frameworx'' (''eTOM BPF, SID, TAM, TNA'')) tende a dificultar a adoção de capacidades de orquestração mais completas para o provisionamento de serviços fim a fim.<br /> <br /> ==== Áreas sistêmicas das arquiteturas de roteadores e switches ====<br /> Tantos destes protocolos e serviços de rede precisam ser selecionados e configurados por você, um por um, e conforme diretivas do seu projeto técnico (ex: configurações homologadas, boas práticas, validação de sintaxe e semântica, etc.) para que possam convergir e fornecer o transporte e a efetiva viabilidade dos serviços e produtos contratados pelos clientes. Para fazer toda a coisa acontecer, há um determinado arranjo de dependências entre as tecnologias necessárias onde, em muitos casos, para que uma determinada tecnologia que você configurou possa funcionar, são necessários o suporte e o funcionamento de outras tecnologias e serviços, as quais, por sua vez, precisarão ser também pensadas, projetadas, e configuradas por... você! Para exemplificar aqui, para que o BGP de seu AS possa operar é necessário o roteamento recursivo para o transporte das sessões IBGP e a devida resolução do atributo NEXT_HOP das rotas mantidas pelo BGP, e isto significa que você precisará adotar um protocolo de roteamento interior (IGP), provavelmente o OSPF aqui, o qual, por sua vez, depende de endereçamento IP, definição das tecnologias de enlace (VLANs, entroncamentos, etc.) e das tecnologias de transmissão (L1). Ou seja, uma coisa depende da outra.<br /> <br /> Em particular, roteadores e switches em uma rede mantém áreas sistêmicas e funcionais para os propósitos de conectividade e de serviços:<br /> * '''Plano de Controle:''' área sistêmica responsável por hospedar protocolos que forneçam entendimento e convergência para fins de encaminhamento de tráfego L2 (ex: STP, REP, EAPS...) e L3 (ex: OSPF, IS-IS, BGP, etc.), e até mesmo &quot;L2.5&quot; (ex: MPLS). Não somente os protocolos são mantidos nesta área, mas também as suas respectivas estruturas de dados, tais como o ''Link-State Database'' (LSDB) do OSPF, o ''Label Information Base'' (LIB) do MPLS LDP, a ''BGP Table'' do BGP, e a própria tabela de roteamento IP (''Routing Information Base'' ou RIB) do roteador, protocolos adicionais tipo o ''PCEP'', etc.<br /> * '''Plano de Dados:''' área sistêmica responsável por hospedar as estruturas de dados especificamente orientadas ao processamento e efetivo encaminhamento de pacotes, tais como a ''Forwarding Information Base'' (FIB) ou ''Forwarding Table'', ''Label Forwarding Information Table'' (LFIB), ''Adjacency Table'' (ADJ) ou similar, isto no caso dos roteadores, e ''Content Addressable Memory'' (CAM) ou ''MAC Table'', no caso dos switches, além de outras estruturas de dados que possam servir para funções adicionais da cadeia de processamento de pacotes, geralmente organizadas em TCAMs (''Ternary Content Addressable Memory''), para o acionamento de manipulações de cabeçalhos, QoS, ACL, etc. <br /> * '''Plano de Gerenciamento:''' responsável por hospedar e manter os serviços de gerenciamento do dispositivo, tais como ''Telnet'', ''SSH'', ''SNMP'', ''NETCONF'', ''HTTP server'', ''Syslog'', ''NTP'', etc.<br /> * '''Plano de Serviços:''' responsável por manter processos relacionados ao ''RADIUS'', ''TACACS+'', ''PPPoE'', ''IPoE'', ''IPsec'', ''NAT'', ''QoS'', ''Stateful Firewall'', ''AVC'', etc.<br /> É importante salientar que o modelo de computação em rede tradicional é completamente distribuído, ou seja, que estas áreas sistêmicas supracitadas são independentes e localmente significantes para cada dispositivo. Isto significa que o estado de informação de cada processo de software referente a um destes protocolos e serviços é mantido por cada equipamento, independentemente, podendo haver, em algumas situações, alguma integração entre equipamentos distintos para um determinado componente. <br /> <br /> ==== Projeto técnico compatível com o plano de negócios ====<br /> Você deve ter notado a quantidade brutal de componentes e recursos tecnológicos listados até agora! No que tange aos tipos de equipamentos que você precisa utilizar, como deverão ser feitas as conexões físicas e lógicas, quais protocolos e serviços deverão ser projetados e empregados (configurados, ativados...), e tudo mais, enfim, isto dependerá muito de como o seu projeto técnico for construído, e este projeto precisa &quot;casar&quot; com o seu plano de negócios. A dissertação disto está fora do escopo deste artigo e por razões bem óbvias, pois seria um baita ''off-topic''. Isto será tema para futuros artigos aqui na Wiki do BPF. Todavia, caso tenha curiosidade de saber um pouco mais sobre o tema, talvez estes dois vídeos possam ser úteis neste sentido, pois, neles, tento apresentar de forma bem objetiva estes conceitos:<br /> * [https://youtu.be/8yAGzNuerFg &lt;nowiki&gt;[BPF] Conceitos e análises de investimentos tecnológicos para o ISP&lt;/nowiki&gt;]<br /> * [https://youtu.be/rnABNk26pZk &lt;nowiki&gt;[BPF] Caracterização das funcionalidades e recursos para projetos de redes no ISP&lt;/nowiki&gt;]<br /> É importante salientar que há muita redundância entre as tecnologias citadas previamente, particularmente no que concerne às aplicabilidades, cenários e casos de uso. Por exemplo, você não irá realmente rodar o protocolo de roteamento EIGRP no backbone do seu provedor, pois será óbvia e natural a escolha pelo protocolo de roteamento OSPF (as razões quanto a isto podem ser estudadas no artigo [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]), embora ambos sejam protocolos de roteamento, e muito bons por sinal. Assim como, caso a sua rede de Acesso seja L2, será muito provável que você vá optar por tecnologias de resiliência Ethernet mais sofisticadas, preferindo o G.8032 ou EAPS, ao invés do protocolo Spanning Tree, mesmo que ambos sejam protocolos de resiliência destinados ao mesmo propósito (vide artigo [[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]] para saber o por que). Assim como você optará pelo IPoE ou PPPoE, ou ainda rodando os dois serviços simultaneamente por um tempo em caráter de transição tecnológica, mas, no final das contas, é provável que você vá manter apenas o IPoE, embora ambos PPPoE e IPoE tenham como proposta a mesma missão (apenas a cumprem de formas distintas). Quanto aos protocolos FHRP, é bem provável que você vá optar pelo VRRP (até mesmo pela provável natureza ''multivendor'' da sua rede), e não pelo HSRP, por se tratar de uma tecnologia proprietária. A maioria absoluta das instalações de rede de Internet residencial emprega o protocolo/serviço RADIUS como um dos componentes de integração requeridos, mas a tendência é que, com o passar do tempo, vejamos cada vez mais instalações operando com o protocolo Diameter. Enfim, acho que você conseguiu me entender aqui.<br /> <br /> Para tudo isto que escrevi acima, o que escolher, o que adotar, &quot;o que comer, o que vestir&quot;, enfim, tudo isto requer amplo planejamento e boas práticas para a manutenção do '''''ciclo de vida do projeto''''' (Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento). Isto será discutido futuramente em outros artigos aqui em nossa Wiki.<br /> <br /> === Qual é a relação entre a &quot;seção de revisão de componentes tecnológicos&quot; deste artigo e os objetivos propostos pelo mesmo? ===<br /> Talvez você esteja se perguntando: &quot;''Tá, Leonardo, mas.... o que tem isso a ver?''&quot;.<br /> <br /> Em primeiro momento, informo que nem todos os leitores de nossa Wiki são profissionais altamente experientes quanto você, nobre leitor! Há indivíduos que nos visitam aqui que já reportaram dificuldades em absorver conhecimentos mais avançados ou complexos, ou que estejam em processo de aperfeiçoamento de carreira. Para este perfil de nosso público, tenho certeza que as informações apresentadas na seção anterior são tidas como muito úteis e, portanto, achei prudente lembra-los da magnitude em termos de quantidade e diversidade de componentes, recursos, conceitos, procedimentos e especificações tipicamente encontrados nas redes de ''service providers'', e tudo isso pode ser tratado como componentes que são ou que devam ser configurados em uma rede, seja pelo modelo tradicional (CLI, WebUI) ou por meios da automação por ferramentas de programabilidade.<br /> <br /> &lt;u&gt;A pergunta que faço agora:&lt;/u&gt; '''''como você projeta, implementa (as tecnologias, protocolos, serviços, etc.), opera (a manutenção geral), suporta (diagnóstico, troubleshooting), e provisiona clientes e seus respectivos produtos contratados?'''''<br /> <br /> Sabemos que na grande maioria dos casos a coisa não funciona por pura e simples &quot;''mágica''&quot;, e quase tudo depende de ações e intervenções humanas. Aposto que hoje, no seu ambiente, mais de 95% de tudo o que a sua rede precisa fazer é fruto de alguma configuração realizada inteiramente pelas mãos de um operador da sua rede, um profissional de operações (NOC), provisionamento ou da engenharia! O camarada foi lá e configurou elemento por elemento, &quot;na mão&quot;, pela linha de comando (CLI) ou por alguma interface gráfica tipo ''Device Manager'' (gerenciador de dispositivo, específico para aquele e cada equipamento), e todo o ambiente é mantido assim, desta forma.<br /> <br /> Cada vez que você tiver que adicionar um novo elemento/equipamento na sua rede, como você faz? Cada vez que você precisa suportar novos prefixos IP, como você lida com as modificações nas suas políticas de roteamento? Cada vez que você precisa ativar um cliente corporativo para um produto do seu ISP, como você faz para provisionar este serviço? Ativar uma L2VPN ponto a ponto ou multiponto, ou uma extensão entre data centers (''Data Center Interconnect''), ou uma L3VPN (''simple, complex, managed services,'' e ''Internet''), ou um serviço SD-WAN gerenciado e em combinação com proteção de DNS e outros &quot;mimos&quot;? E com relação ao assinante residencial, como você faz? Tenho quase certeza que hoje, no seu caso, a maior parte destes processos, pra não citar &quot;todos&quot;, é manual ou, no melhor caso, requer uma ação humana realizada sobre algum tipo de ferramenta que atenua estes esforços, mas que, mesmo assim, precisa ser realizada sobre diversos equipamentos da infraestrutura. <br /> <br /> &lt;u&gt;Para efeitos comparativos aqui:&lt;/u&gt; nos melhores casos e envolvendo grandes empresas do setor de tecnologia, quando você contrata uma plataforma como serviço (''PaaS'') ou uma infraestrutura como serviço (''IaaS'') de uma destas consagradas empresas globais, você realmente acredita que alguém recebe um email (referente a sua solicitação) e o encaminha internamente para as áreas técnicas para que estes mobilizem qualquer atividade de ativação manualmente, tais como a instalação de equipamentos, instalação e atualização de software, configuração de dispositivos e serviços? Claro que não! Nestes perfis de organizações, tudo isso é orquestrado e automatizado a partir do momento em que você passa o seu cartão de crédito durante o procedimento de subscrição ou de contratação do serviço!<br /> <br /> E é justamente sobre este tema é que passaremos a dissertar a partir de agora neste artigo, sendo este o nosso foco.<br /> <br /> === A relação entre este artigo e os frameworks e modelos de gerenciamento de infraestruturas de ambientes ISP ===<br /> Não dissertarei detalhadamente sobre os frameworks em questão, pois haverá oportunidades de você conhecer mais sobre este tema em outros artigos do Brasil Peering Forum. Irei ao ponto logo ao término dessa seção.<br /> <br /> Talvez você queira aprofundar-se um pouco mais sobre esta área com a leitura do artigo [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]], caso não tenha feito isso ainda.<br /> <br /> Há muitos anos o [https://www.itu.int/en/ITU-T/publications/Pages/default.aspx ITU-T] introduziu o termo ''Telecommunications Management Network'' (TMN) para a descrição de uma rede dedicada com interfaces orientadas ao gerenciamento de redes de telecomunicações, e buscando definir os pontos de interconexão entre as duas redes, além de especificar as diversas funcionalidades de gerenciamento. A proposta deste framework foi ilustrar as áreas funcionais distintas e como estas deveriam interoperar. E isto foi originalmente especificado pelo ITU-T M.3400 e X.700, em especial a classificação das funcionalidades de gerenciamento, mas sem a descrição detalhada dos componentes destas funções, algo que foi tratado mais apropriadamente por outros padrões periféricos mais específicos e que nasceram mais ou menos no mesmo período.<br /> <br /> Por sua vez, o FCAPS é um modelo de gerenciamento de redes produzido pela ISO, e não pelo ITU-T, descrito inicialmente como ''Working Drafts'' (N1719) da norma ISO 10040, e com o intuito de definir cinco padrões de protocolos distintos, sendo cada um para uma área funcional específica. Posteriormente, dadas as similaridades entre muitas funções pretendidas por estes protocolos, os cinco foram consolidados em um só (''Common Management Information Protocol'' ou CMIP). No entanto, a coisa não parou por aí, e muitas evoluções ocorreram, até que o próprio ITU-T, nos anos 90, passasse a integrar o FCAPS como parte de seu framework TMN. Esta integração entre TMN e FCAPS está mostrada na ilustração logo abaixo.<br /> <br /> Posteriormente, o FCAPS evoluiu para o que chamamos de FAB (''Fulfillment, Assurance, Billing''), conforme definido pelo framework ''Business Process Framework'' (BPF), que foi bem esclarecido no mapa ''eTOM'' apresentado no artigo &quot;''Frameworks de Indústria para a Reestruturação e Profissionalização do ISP''&quot;, publicado em nossa Wiki. Ou seja, resumindo aqui, tanto a ISO quanto o ITU-T tinham propostas e modelos bastante interessantes para compreendermos as questões associadas ao gerenciamento de infraestruturas, e houve este esforço ou intenção de ambas as partes para que o melhor dos dois mundos pudessem se encontrar, promover uma certa unificação e direcionamento para os melhores resultados para a indústria. No que concerne ao FCAPS em si, para todos os efeitos mais práticos, as classificações das funções de gerenciamento para cada uma das áreas de negócios e funcionais de um ISP foram inicialmente especificadas pelo FCAPS da ISO, posteriormente integradas pelo TMN da ITU-T, e aprimoradas e portadas para o eTOM BPF. Atualmente, o framework BPF é um dos frameworks do ''[https://www.tmforum.org/frameworx-homepage/ Frameworx],'' criado e mantido pelo [https://www.tmforum.org/ TM Forum].<br /> [[Arquivo:Bpf-prog-fcaps.png|centro|miniaturadaimagem|800x800px|Visualização da integração entre TMN e FCAPS, e a ênfase no conceito de Configuration, que será o foco do artigo a partir deste ponto]]<br /> A relação entre eTOM BPF ou FAB ou FCAPS, enfim, e este artigo, é buscar capacitá-los com informações fundamentais sobre o '''''Gerenciamento de Configurações''''' de uma rede de ISP. <br /> <br /> Por que o FCAPS é útil, inclusive para o nosso artigo aqui? Assim como temos o hábito de usarmos frequentemente o modelo de referência OSI (RM-OSI), ou seja, aquelas 7 camadas (Física, Enlace de Dados, Rede, Transporte, Sessão, Apresentação e Aplicação) para ensinarmos os fundamentos de redes para profissionais da área ou indivíduos que estejam começando nela, usamos também o FCAPS para este mesmo propósito, que é o de ensinar e capacitar, só que, neste caso, sobre os conceitos e fundamentos de gerenciamento de infraestruturas!<br /> <br /> O FCAPS, mesmo que o &quot;original&quot; esteja um pouco defasado (pois hoje está incorporado, mais amplo e melhor especificado no eTOM BPF), '''&lt;u&gt;''é uma excelente ferramenta de aprendizado!''&lt;/u&gt;''' Por este motivo decidi escrever um pouco a respeito dele nesta seção do artigo. Quer ensinar redes para alguém? O modelo de referência OSI é ótimo para isso! &lt;u&gt;Quer ensinar fundamentos de gerenciamento de redes para alguém? O FCAPS é certamente um dos recursos mais interessantes e úteis para concebermos estes ensinamentos!&lt;/u&gt;<br /> <br /> Para concluir, a sequência deste artigo estará centrada no '''''&lt;u&gt;Gerenciamento de Configurações&lt;/u&gt;''''' (o &quot;'''C'''&quot; do modelo FCAPS). Além do artigo, você talvez tenha interesse em consultar a recomendação [https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=14005&amp;lang=en ITU-T G.7710/Y.1701 (08/2019) - Common Equipment Management Function Requirements] para ampliar seus horizontes.<br /> <br /> === Como o gerenciamento de configurações é realizado pela maioria dos ISPs regionais de pequeno e médio portes ===<br /> É de amplo conhecimento que, em parâmetros tecnológicos, os provedores de acesso à Internet de pequeno e médio portes evoluíram muito de uns anos para cá. Em termos de sofisticação de equipamentos e tecnologias, estes ISPs tem &quot;encostado&quot; nos grandes operadores de rede, geralmente ficando as principais diferenças entre ambos os perfis nas questões associadas ao porte dos equipamentos utilizados (capacidade, densidade, quantidade, volume), tamanhos das áreas de concessão, tamanho da base de assinantes, sendo estas diferenças até bastante expressivas, mas não no tipo ou na qualidade da tecnologias empregadas. E, nas questões administrativas, claro, a quantidade de colaboradores, os orçamentos, áreas internas do negócio, e diversos outros casos que não convém elencar no momento. <br /> <br /> Mas há uma diferença muito significativa, importantíssima, e que tem a ver com o que este artigo propõe-se a discutir: o &lt;u&gt;''gerenciamento da infraestrutura como um todo''&lt;/u&gt;, incluindo frameworks, processos, procedimentos, metodologias, sistemas, integrações entre sistemas e infraestruturas, o tanto de programabilidade, automação e orquestração, os respectivos padrões de ferramentas empregadas... e isto são algumas das principais comparações operacionais e procedurais que faço quando analisando um operador de redes de grande porte e um ISP regional de pequeno ou médio porte, quanto a estes quesitos.<br /> <br /> No que diz respeito ao '''''gerenciamento de configurações''''', mais especificamente quando um ISP regional de menor porte precisa ativar ou provisionar um novo serviço, geralmente são necessários os seguintes procedimentos (estou generalizando aqui):<br /> # Se a manobra tiver que incluir a instalação física de um novo equipamento em um site/Pop do ISP, conduzir e documentar um ''Projeto Provisório de Instalação'' (PPI) ou ''Projeto Definitivo de Instalação'' (PDI), juntamente com os demais procedimentos homologados pela Engenharia da empresa, tais como ''Plano de Instalação e Ativação'', etc.<br /> ## Sejamos realistas: a instalação física de um equipamento não pode ser automatizada! (exceto, talvez, por robôs, o que não será o caso tão cedo)<br /> # Configuração de equipamento para a sua efetiva integração com a rede, o que, por sua vez, normalmente, ou quase sempre, exige a condução de outros procedimentos aprovados pela Engenharia da empresa, em particular a atualização do software para a versão homologada e a condução de um extenso roteiro/script contendo os parâmetros de configuração, apoiados por artefatos tais como um ''Plano de Instalação e Configuração Lógica''.<br /> ## Aqui temos a primeira oportunidade de automação e orquestração, via métodos de provisionamento tais como o de zero toque ou &quot;''Zero Touch Provisioning''&quot; ou tecnologia similar, os quais propõem-se a simplesmente exigir do profissional lá no site/Pop apenas as manobras de energização e cabeamento/conectorização das portas do equipamento, que a rede automaticamente se encarregará de todo o resto e fornecerá a configuração definitiva do equipamento.<br /> # Em seguida, o provisionamento do serviço do cliente! É aqui que você terá que &quot;visitar&quot; a CLI (linha de comando) ou WebUI de vários equipamentos para realização das configurações necessárias para a viabilidade fim-a-fim do serviço contratado pelo assinante, e geralmente apoiado por um formato pré-estabelecido para aquele tipo de produto/configuração. Ou seja, definir as VLANs, entroncamentos de VLAN, os mecanismos de controle de admissão à rede, recursos de segurança, endereços IP, roteamento, QoS, policies, etc., e fazendo isto para as tecnologias requeridas, caso a caso, sobre todo e qualquer dispositivo exigido para a viabilidade quanto à &quot;ativação&quot; (fim a fim) daquele produto que aquele assinante contratou.<br /> ## Talvez uma das áreas operacionais mais frágeis da organização seja exatamente esta baixa aderência quanto às boas práticas regidas pelo &quot;'''''C'''''&quot; do FCAPS, ou seja, da disciplina de '''''gerenciamento de configurações'''''! Muito frequentemente, para não dizer &quot;quase sempre&quot;, é um processo estritamente manual e associado a custos mais elevados, maiores esforços e complexidades operacionais, maiores riscos de incidentes e downtime (decorrentes de falha humana durante o processo de configuração de elementos de rede), dentre muitas situações eventual e obviamente indesejadas.<br /> ## E é aqui que enxergo mais uma excelente oportunidade para os ISPs regionais poderem se modernizar!<br /> # O serviço que foi ativado (produto + assinante) é testado e validado, e posicionado para produção em caráter definitivo. A partir deste ponto, a Operação da rede (ex: NOC) deverá ficar responsável por assegurar que as métricas do SLA contratado sejam respeitadas, tais como capacidade, consumo de banda dentro do perfil, latência, jitter, perda de pacotes, disponibilidade/uptime, etc.<br /> ## Outra seara repleta de procedimentos manuais e ferramentas dissimilares que não &quot;conversam&quot; entre si, não compartilham dados, e fica bem mais difícil encontrar uma utilidade real para os sistemas de gerenciamento de elementos (EMS) e de rede (NMS) da organização, como partes integrantes ou isoladamente dos sistemas de suporte a operação (OSS).<br /> ## Aqui é onde enxergo outra excelente oportunidade para a modernização das infraestruturas e processos dos ISPs regionais!<br /> [[Arquivo:Bpf-prog-2.png|centro|miniaturadaimagem|800x800px|O roteiro tradicional de implantação e provisionamento de serviços de um ISP]]<br /> <br /> === Introdução aos conceitos da disciplina de configurações ===<br /> Realmente pretendo pular a parte referente aos conceitos de ''IT Service Management'' (ITSM), e um tanto do que a versão 3 do ITIL (''Information Technology Infrastructure Library'') aborda neste sentido. Voltaremos aqui ao que importa, e o FCAPS é mais apropriado para dissertarmos a respeito disto.<br /> <br /> Na questão de &quot;Configurações&quot;, o FCAPS é centrado em um bocado de coisas, mas dá para sumarizar suas principais funções e objetivos da seguinte forma:<br /> # '''''Inicialização do Serviço'''''<br /> # '''''Provisionamento do Serviço'''''<br /> # '''''Auto-descoberta''''' (de elementos e suas capacidades e propriedades, topologias, etc.)<br /> # '''''Backup e restauração''''' (obviamente incluindo muitas capacidades e facilidades aqui, tais como diff-check, dry-run, etc.)<br /> # '''''Desligamento de recursos''''' (quando não são mais necessários, ou por mudança de perfil de assinante (ex: bloqueado, cancelado))<br /> # '''''Gestão de mudanças''''' (os processos e ferramentas para a &quot;GMUD&quot;).<br /> # '''''Pré-provisionamento'''''<br /> # '''''Gerenciamento de inventário''''' (não somente a parte do hardware inteiro, mais também os módulos, acessórios, software, licenças, etc.)<br /> # '''''Cópia de configurações'''''<br /> # '''''Configuração remota'''''<br /> # '''''Atualização automática de software''''' (incluindo funcionalidades que maximizem a disponibilidade dos dispositivos, compliance de software, etc.)<br /> # '''''Iniciação, rastreamento e execução de job'''''<br /> Ou seja, tudo para viabilizar os controles necessários para implementar a configuração inicial dos elementos da rede e seus respectivos componentes, sincronismo e monitoramento dos parâmetros de configuração empregados; distribuição de tarefas de configuração com o auxílio de templates, configuração de propriedades avançadas sobre os elementos da rede (proteção e resiliência, VLANs, entroncamentos, endereçamento IP, roteamento, QoS, etc.), manutenção e auditoria de configurações, e tantos outros. <br /> <br /> A arquitetura ''Equipment Management Function'' (EMF) proposta pelo ITU-T com relação ao FCAPS fornece as recomendações sobre como os sistemas de gerenciamento de elementos (EMS) gerenciam as funções de elementos de redes (NEF), ao interagir com funções atômicas da camada de transporte e sincronização (AF), e fazendo isto através da troca de informações de gerenciamento (MI) sobre os pontos de gerenciamento (MP); esse &quot;tequiniquês&quot; é abordado no ITU-T G.806, ITU-T X.701 e ITU-T X.720, enfim, suprimamos isso aqui. Talvez eu deva ao menos fornecer uma noção visual destes conceitos:<br /> [[Arquivo:Bpf-prog-fcapscm.png|centro|miniaturadaimagem|800x800px|Ilustração de conceitos FCAPS tais como NEF, EMF, MAF, MCF, MI e MP (Fonte: ITU-T)]]<br /> Em termos mais práticos, isto significa que você precisa considerar para a sua infraestrutura as devidas funções de gerenciamento para cada uma áreas recomendadas pelo FCAPS (ou eTOM BPF, neste caso), observando como os sistemas de negócios da empresa estão mapeados para os sistemas mais técnicos e operacionais, e como estes sistemas mais técnicos-operacionais interagem com a infraestrutura para aditivar as tecnologias, as quais, por sua vez, darão apoio direto aos resultados tanto técnicos quando os de negócios. Aquela tão desejada aderência...<br /> <br /> Você basicamente possui dois caminhos possíveis, dependendo do perfil do seu ambiente em termos de &quot;vendor&quot; (fabricante de escolha dos seus equipamentos):<br /> * '''Rede homogênea:''' se a sua rede contiver dispositivos e soluções de apenas um fabricante, você muito provavelmente poderá utilizar as ferramentas/sistemas ou soluções daquele fabricante para as necessidades de gerenciamento de configurações. Aliás, não somente configurações, mas também a parte de desempenho, falhas/incidente, segurança, etc. Ou seja, as plataformas de gerenciamento desenvolvidas pelo fabricante para aquela classe de produtos que você tem na sua rede. Desnecessário comentar que são soluções proprietárias, certo? Não que isto seja algo ruim, mas é bom deixar isto bem claro.<br /> * '''Rede heterogênea:''' se a sua rede contiver um mix de soluções e de vários fabricantes, você terá bem mais dificuldades. Na maioria dos casos, você terá que rodar múltiplos sistemas de gerenciamento para acomodar cada uma das áreas funcionais previstas pelo FCAPS através deste cenário multivendor. É muito improvável que a plataforma de gerenciamento de um determinado fabricante vá suportar bem os equipamentos de outros fabricantes, principalmente quando o assunto for ''&lt;u&gt;gerenciamento de configurações&lt;/u&gt;''. E, caso haja esse suporte, ele quase sempre ou fatalmente será limitado, ou possuirá algumas chatas restrições.<br /> Em muitos casos, nos vemos forçados a usar uma solução para gerenciar os elementos da marca &quot;A&quot;, outra solução de gerenciamento para os elementos da marca &quot;B&quot;, mais uma solução para gerenciar os elementos da marca &quot;C&quot;, e uma ou mais soluções open source (ou não) para monitorar componentes em comum das marcas &quot;A&quot;, &quot;B&quot; e &quot;C&quot;, como ocorre frequentemente para a parte de gerenciamento de desempenho e gerenciamento de falhas/incidentes, onde soluções tais como PRTG, Zabbix, Libre NMS, Observium, Nagios, Cacti, etc., são bastante populares. Eu particularmente vejo muita fragilidade e inconvenientes aqui, pois raramente estes sistemas integram bem com sistemas de outros fabricantes, exceto, talvez, e dependendo do caso, via extensas e complexas integrações por ''Common Object Request Broker Architecture'' (CORBA), do ''Object Management Group'' (OMG), algo que já vi acontecer um bocado em ambientes de telecom. Um porre! Não é a toa que o TM Forum tem buscado impulsionar bastante o Frameworx como forma de padronização, interoperabilidade e integração entre os sistemas BSS e OSS.<br /> <br /> Que tal darmos uma praticidade para estes argumentos?<br /> * O '''Winbox''' da Mikrotik não vai gerenciar configurações de um equipamento Cisco, Juniper ou Huawei ('''''pelo menos não que eu saiba! KKKKKKK''''').<br /> * O '''Cisco Prime LAN Management Solution''' não vai gerenciar configurações de elementos de rede de classe corporativa não-Cisco.<br /> * O '''Cisco Application Policy Infrastructure Controller (APIC)''' possui alguma integração com soluções específicas (Check Point, Palo Alto Networks, Fortinet Inc, Radware – DefensePro, A10 Networks, Avi Networks, Citrix Systems, F5 Networks, Radware – Alteon VA e VX), mas não para todos os recursos e funções que talvez você necessite para o seu projeto.<br /> * O '''Cisco Adaptive Security Device Manager (ASDM)''' só serve para gerenciar dispositivos de segurança ASA da Cisco.<br /> * O '''Cisco Network Services Orchestrator (NSO)''' não é orientado para funções de gerenciamento de falhas ou desempenho, e sim para o gerenciamento de configurações, e talvez seja uma das poucas soluções comerciais que conseguem orquestrar o provisionamento de serviços fim a fim sobre qualquer equipamento e de qualquer vendor (a não ser que o seu equipamento não seja realmente lá grandes coisas...), e compete com vantagens contra o '''''Ansible Tower'''''.<br /> * O '''Junos Space Network Management Platform''' da Juniper consegue integrar alguns dispositivos de terceiros como elementos gerenciados, mas, &quot;''guess what?''&quot;, há restrições de funcionalidades.<br /> * O '''HPE Intelligent Management Center Enterprise''' da HP permite adicionar alguns elementos externos/de terceiros, tais como o switch Cisco Nexus, e integrações com Aruba Airwave (faz sentido, pois houve a aquisição aqui), ClearPass e HPE OneView. O que exatamente é suportado ou quais são as restrições aqui, eu desconheço no momento. <br /> * O '''Zabbix''' pode ser ótimo para necessidades de gerenciamento de falhas/incidentes e de performance/desempenho, até mesmo porque é amplamente customizável. Agora experimente conduzir a disciplina de gerenciamento de configurações com esta ferramenta, e você verá que é simplesmente inviável e contra-indicado.<br /> * O '''Libre NMS''' é outro exemplo clássico, idêntico ao caso do Zabbix, assim como as outras ferramentas bem conhecidas do mercado citadas anteriormente.<br /> * O '''ManageEngine''' ou o '''PRTG''' são outros ótimos exemplos para as questões de gerenciamento de falhas e de desempenho, mas não são funcionais para o gerenciamento de configurações.<br /> Como você pode notar, muito frequentemente os sistemas que nós utilizamos não atendem bem a todas as nossas necessidades, e nos vemos forçados a contar com 3 ou 4 soluções de gerenciamento para manter a infraestrutura funcionando. Sistemas, estes, que funcionam de forma completamente independente, como &quot;ilhas&quot; mesmo, isolados, e com mínima ou zero troca de dados entre si. Para ''falhas'' e ''desempenho'', isto é até &quot;aceitável&quot;, embora, ainda assim, indesejável. Mas, para o '''''gerenciamento de configurações''''', isto é inaceitável! Meus &quot;''2 cents''&quot; aqui.<br /> <br /> A ilustração a seguir fornece exemplos de soluções mapeadas para as áreas do FCAPS, para que você tenha essa noção de que alguns fabricantes procuram especificar as funções de suas soluções de gerenciamento para ficarem mais &quot;alinhadas&quot; com as recomendações do FCAPS. Os exemplos não são completos e tampouco estão atualizados 100%, mas acho que você compreenderá a essência.<br /> [[Arquivo:Bfp-network management.png|centro|miniaturadaimagem|600x600px|(Fonte: snmpcenter.com)]]<br /> E é por esta razão que a indústria está convergindo cada vez mais para os princípios de programabilidade, pois os modelos de gerenciamento tradicionais não mais correspondem às nossas expectativas, e pelas tantas razões e situações comentadas até este momento!<br /> <br /> Agora, há uma terceira opção aqui, que seria considerar soluções comerciais (destes mesmos fabricantes ou de terceiros) em combinação com outras iniciativas que entendam melhor as nossas necessidades e que sejam capazes de promover melhor aderência. Muitos destes sistemas &quot;fechados&quot; podem não atender integralmente as nossas necessidades, principalmente quando estes possuem baixas capacidades e recursos de integração com outros sistemas. E é nessa hora onde ferramentas e soluções de programabilidade poderão ser bem mais efetivas para os nossos propósitos. É nessa hora que pensamos em Ansible / Ansible Tower, Chef, Puppet, Salt, Cisco NSO e outras ferramentas de programabilidade, integradas a controladores SDN ou não.<br /> <br /> === Agora que você já está &quot;anestesiado&quot; e a par de todas as situações e pré-requisitos, vamos à programabilidade de infraestruturas ===<br /> Tentarei ser muito objetivo ao explicar logo a seguir algumas verdades, assim como aproveitar a oportunidade para esclarecer algumas &quot;inverdades&quot;, sobre este universo envolvendo programabilidade, orquestração, automação, provisionamento, SDN, NFV, etc. Vamos lá?<br /> * O &lt;u&gt;'''''provisionamento'''''&lt;/u&gt; é essencialmente a intenção de ativação de um serviço para o ISP ou, bem mais frequentemente, para seus clientes. <br /> ** Este provisionamento de um serviço (ex: um L2VPN &quot;LAN-to-LAN&quot; ou &quot;DCI&quot;, uma L3VPN, um serviço de Internet, etc.) pode ser realizado manualmente (como é feito normalmente na maioria dos casos envolvendo os ISPs regionais, assim como empresas do setor corporativo) ou de forma bem mais &quot;''programável''&quot;; orquestrada e automatizada.<br /> ** Geralmente referimos o conceito à ativação de um serviço fim-a-fim e que vá envolver diversas tecnologias (L2, L3, e outros) e em vários dispositivos de rede, homogêneos (mesmo padrão de sintaxe e semântica) ou heterogêneos (diferentes vendors, ou CLIs, sintaxes, etc.). <br /> ** O provisionamento pode ser também uma coisa bem mais específica e pontual (um pequeno bloco de configuração a ser programado em um único dispositivo, por exemplo).<br /> * A ''&lt;u&gt;'''orquestração'''&lt;/u&gt;'' é a capacidade tecnológica de habilitar serviços envolvendo ações de provisionamento sobre a infraestrutura, que poderá abranger ou contemplar somente a rede, ou, então, por exemplo, rede + computação + storage + plataforma/apps, frequentemente tocando em componentes multivendor, para a ativação de um determinado produto ou serviço desejado, seja este para atender uma necessidade interna, do próprio ISP, ou para atender a uma solicitação ou contratação por parte de um cliente/assinante.<br /> ** As tecnologias que fomentam a orquestração precisam ou devem operar sobre um regime de abstração entre as funções lógicas pretendidas e os componentes da infraestrutura de rede física. A solução preferencialmente deve suportar, além da abstração, o modelo de operações por transações. Quais equipamentos precisarão ser configurados? Ou quais equipamentos precisam receber quais configurações para a ativação deste serviço? E isto independente do vendor ou da sintaxe da CLI, sendo este o principal propósito desta abstração requerida. E, caso haja algum problema com a ativação, as devidas facilidades de ''rollback'' automático.<br /> ** A orquestração é muito desejada em qualquer tipo de situação, mas, sem sombra de dúvidas, é mais desejável ainda em ambientes heretogêneos (ex: multivendor).<br /> * A &lt;u&gt;'''''automação'''''&lt;/u&gt; é o estado operacional desejado para que estas ações de configuração e provisionamento de serviços (e até mesmo nos casos de diagnósticos ou suporte a falhas) na infraestrutura envolvam &quot;zero&quot; ou o mínimo possível de ações humanas.<br /> ** Desejavelmente, a automação deve estar contida na orquestração, pois, por exemplo, do contrário, não fará muito sentido &quot;juntar as peças de sistemas dissimilares&quot; (alçada da orquestração) se você tiver que executar os blocos do contrato manualmente depois, na CLI, GUI/WebUI ou por scripts, em vários equipamentos.<br /> ** A orquestração e automação devem andar lado a lado. <br /> *** Em muitos casos, o contrato do serviço pode ser desenhado na forma de templates e acionados por ações nos sistemas da companhia, onde, num simples ''frontend'', os parâmetros são preenchidos/fornecidos para que, no ''backend'', a rede seja acionada para receber as configurações devidas e concluir todo o provisionamento. Neste cenário, não há o envolvimento de analistas na linha de comando (CLI) ou em plataformas específicas de provisionamento (EMS/GUI/WebUI).<br /> *** Em outros casos, o provisionamento é feito em sistemas específicos para este propósito e poderá exigir algum padrão de intervenção técnica, por exemplo, a execução de scripts ou acionamentos de funções mais técnicas em sistemas específicos, mas exigindo pouco ou nada em termos de uma intervenção por CLI ou GUI/WebUI dos dispositivos.<br /> * A '''''&lt;u&gt;programabilidade&lt;/u&gt;''''' tem relação com a afinidade de tecnologias, processos, ferramentas e soluções técnicas compatíveis que são empregadas para as orquestrações automatizadas de serviços. <br /> ** Isto é, idealmente, o seu aparato tecnológico, incluindo hardware, software e sistemas utilizados em seu ambiente, tudo isto precisa ser compatível com o suporte à tecnologias que fomentam a orquestração e automação para a programabilidade do provisionamento fim a fim de serviços com maior fluidez, menor tempo/prazo, &quot;zero&quot; ou menor esforço de implementação, e menores riscos para a rede e para o negócio. <br /> * Praticamente em todos os casos a orquestração envolve automação, mas não o contrário: nem toda automação tem relação com orquestração.<br /> ** Scripts customizados por você podem não ter qualquer relação com ações de orquestração, além de serem isentos de capacidades de abstração, ou seja, scripts montados para aplicar configurações com sintaxes específicas e com acionamento caso a caso.<br /> * Programabilidade e &lt;u&gt;'''''Software-Defined Networking'' (SDN)'''&lt;/u&gt;, apesar de andarem lado a lado constantemente, são coisas completamente '''&lt;u&gt;distintas&lt;/u&gt;'''.<br /> * Orquestração e ''Software-Defined Networking (SDN)'' são coisas '''&lt;u&gt;distintas&lt;/u&gt;'''. Nem toda orquestração ocorre em um ambiente SDN (ex: com controladoras e soluções específicas de SDN), mas quase sempre o inverso é verdadeiro.<br /> * ''Software-Defined Networking'' (SDN) e ''&lt;u&gt;'''Network Functions Virtualization'''&lt;/u&gt;'' (NFV) são coisas completamente '''&lt;u&gt;distintas&lt;/u&gt;'''.<br /> * As capacidades de programabilidade da infraestrutura estão condicionadas à disponibilidade e suporte de tecnologias, recursos e ferramentas específicas, e isto valendo para cada equipamento.<br /> ** Não adiantará muito controladoras SDN em um projeto com suporte ao OpenFlow na sua rede se os seus elementos de rede (equipamentos) forem incompatíveis com este protocolo. Ou, ao invés do OpenFlow, não adiantará muito (ou pelo menos ficará bem mais complicado) fazer a orquestração de serviços na rede se os seus equipamentos não suportarem o protocolo NETCONF.<br /> * Redes mais sofisticadas utilizam ferramentas e recursos mais arrojados para estas finalidades de programabilidade.<br /> A ilustração a seguir mostra exemplos de recursos de programabilidade representados por funcionalidades suportadas por um determinado equipamento, assim como mostra alguns casos de tecnologias mais apropriadas para que se tenha uma rede mais programática e versátil neste sentido.<br /> [[Arquivo:Bpf-prog-1.png|centro|miniaturadaimagem|800x800px|Exemplos de componentes fomentadores da programabilidade de infraestruturas]]<br /> <br /> ==== Identificando as principais soluções, ferramentas e componentes orientados aos princípios de programabilidade ====<br /> Caso você tenha ficado impressionado com a &quot;salada de tecnologias&quot; ilustrada no início deste artigo, isto porque você talvez desconheça o turbilhão de ferramentas empregadas para fins de programabilidade, incluindo orquestração e automação! Como realmente não dá para listar todas as opções de código aberto e comercial, fornecerei aqui alguns exemplos, talvez os principais, além de citar algumas ferramentas e os principais componentes usados por estas, tais como protocolos, procedimentos e formatos de dados, onde for viável comentar neste nível. Aliás, a intenção a seguir não é realmente esmiuçar como são de fato implementadas ou inseridas nas infraestruturas. Outro aspecto importante a ser comentado é que os exemplos a seguir não funcionam &quot;sozinhos&quot;, no sentido que, em uma rede, você precisará combinar diversas destas soluções, linguagens, modelos, ferramentas e procedimentos; e que nem tudo o que está citado a seguir depende de controladoras SDN para acontecer. Há casos e casos, e cenários para tudo.<br /> <br /> A ilustração a seguir mostra algumas áreas relacionadas aos princípios de programabilidade:<br /> [[Arquivo:Bpf-prog-contextos.png|centro|miniaturadaimagem|800x800px|Algumas áreas do conceito de programabilidade de infraestruturas]]<br /> {| class=&quot;wikitable&quot;<br /> |+Descrição das principais soluções, ferramentas, modelos, procedimentos e componentes de programabilidade<br /> !Ferramenta<br /> !Descrição<br /> |-<br /> | colspan=&quot;2&quot; |'''Soluções Comerciais'''<br /> |-<br /> |'''VMware vSphere'''<br /> |O vSphere é provavelmente a solução de virtualização de servidores mais utilizada do mercado. Ele ajuda você a executar, gerenciar, conectar e proteger os aplicativos em um ambiente operacional comum entre nuvens. Esta solução é amplamente utilizada no mundo todo e em todo e qualquer tipo de ambiente, mesmo aqueles ambiente mais estáticos ou isentos de componentes de orquestração. Possui excepcionais capacidades de integração com regimes de orquestração e provisionamento completos de servidores virtuais.<br /> |-<br /> |'''VMware vRealize'''<br /> |VMware vRealize Suite, conhecido anteriormente pelo nome vCenter Operations Management Suite, é uma plataforma de software projetada para a construção de nuvens heterogêneas híbridas, e apresenta excepcionais capacidades de integração.<br /> |-<br /> |'''Cisco APIC-EM'''<br /> |O Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) é a solução de controladora SDN da Cisco para redes corporativas, atendendo tanto a LAN quanto a WAN.<br /> <br /> A sua proposta é a de fornecer uma plataforma elástica para a automação, simplificação e abstração da rede, acomodando aplicações que usam padrões abertos, e com suporte a northbound Representational State Transfer (REST) APIs.<br /> |-<br /> |'''Cisco DNA Center'''<br /> |O Cisco DNA Center é uma solução que reúne componentes focados na construção de ambientes intuitivos (Intent-based Networking), em compatibilidade com as arquiteturas SDN da Cisco.<br /> Reúne excepcionais facilidades para Projeto, Policy, Provisionamento, Assurance e integração com outras plataformas, e com foco em ambientes corporativos.<br /> |-<br /> |'''Cisco Application Centric Infrastructure (ACI)'''<br /> |O Cisco Application Policy Infrastructure Controller (Cisco APIC) é o principal componente arquitetural da solução Cisco ACI. Ele é o ponto unificado de automação e gerenciamento para a estrutura, a aplicação de políticas e o monitoramento de integridade da solução. O controlador otimiza o desempenho e a gestão, além de operar uma estrutura multiusuário escalonável da Cisco ACI. A solução como um todo embarca outros componentes tais como a própria controladora (Cisco APIC), Cisco Cloud ACI, Cisco Virtual ACI, swiches Cisco Nexus 9000 Series, Cisco ACI Multisite Orchestrator, Cisco ACI App Center, além de ótimas integrações com outras soluções tais como AppDynamics, DNA Center e ISE. <br /> O foco do ACI está para os ambientes de data center.<br /> |-<br /> |'''Cisco Crosswork Network Automation'''<br /> |O Cisco Crosswork Network Automation é uma solução voltada especificamente para service providers / ISPs e que reúne uma diversidade muito grande de recursos para o gerenciamento proativo fim a fim das redes. <br /> Embarca uma suite de componentes de machine-learning, intent-based networking, e outros, viabilizando ampla orquestração de redes plenamente automatizadas.<br /> |-<br /> |'''Cisco Network Services Orchestrator'''<br /> |O Cisco NSO é uma solução muito robusta de orquestração com abstração de infraestruturas físicas e virtuais, fornecendo excepcionais capacidades de orquestração de serviços fim a fim, e muitas facilidades de integração com APIs northbound e southbound, suportando ambientes completamente heterogêneos (multivendor).<br /> <br /> O Cisco NSO pode funcionar sozinho ou em combinação ao Cisco Crosswork Network Automation.<br /> |-<br /> |'''Cisco Open SDN Controller'''<br /> |O Cisco OSC é uma distribuição comercial do OpenDaylight para o fornecimento de agilidade e automação de infraestruturas, fazendo a abstração de ambientes de redes heterogêneas para a entrega de serviços.<br /> |-<br /> |'''Microsoft System Center'''<br /> |O Microsoft Systems Management Server é uma solução para o gerenciamento de grandes grupos de sistemas baseados no Microsoft Windows.<br /> |-<br /> |'''BMC Software'''<br /> |A BMC é uma empresa americana bastante especializada em soluções para o gerenciamento de TI, oferecendo suporte a 92 das 100 empresas listadas na Forbes Global.<br /> <br /> A BMC possui sofisticadas soluções para o grenciamento multi-cloud, automação e DevOps, segurança e conformidade, otimização de TI, inteligência artificial e machine learning, e gerenciamento de serviços.<br /> <br /> Suas soluções são frequentemente encontradas em grandes e bem sucedidos empreendimentos, e possui ótimas capacidades de integração com infraestruturas de redes.<br /> |-<br /> |'''Juniper Contrail'''<br /> |A solução Contrail Controller da Juniper Networks é um produto de automação tipo open cloud que implementa tecnologias SDN para a orquestração e criação de redes virtuais altamente escaláveis. É fruto da aquisição da Contrail em dezembro de 2010.<br /> <br /> O Contrail pode ser utilizado por service providers / ISPs para agilizar o provisionamento de serviços, e também atende a muitos casos e necessidades de empresas do segmento corporativo.<br /> <br /> A solução é projetada para operar em uma máquina virtual (VM) que possui integração com Kubernetes, OpenShift, Mesos, OpenStack, VMware vSphere, e facilidades de integração com sistemas OSS e BSS.<br /> |-<br /> |'''Huawei Agile SDN Controller'''<br /> |O controlador Agile para campus é a última geração de controladores da Huawei para redes LAN e WAN. <br /> É utilizado em diversas soluções inovadoras, como implantação de rede automática, automação de políticas e SD-WAN.<br /> |-<br /> | colspan=&quot;2&quot; |'''Soluções de Código Aberto, Ferramentas, Sistemas, Linguagens, Protocolos, Procedimentos e Formatos de Dados'''<br /> |-<br /> |'''Ansible'''<br /> |O Ansible é uma ferramenta de provisionamento, gerenciamento de configurações e implantação de aplicativos de software livre. <br /> <br /> O Ansible pode automatizar três tipos de tarefas: provisionamento, gerenciamento de configurações, automação de aplicações. É bastante utilizado tanto em projetos de infraestruturas de redes quanto nas questões relacionadas a servidores e aplicações.<br /> <br /> O Ansible não usa agentes e nenhuma infraestrutura de segurança personalizada adicional, apenas uma linguagem muito simples (YAML, na forma de Ansible Playbooks) que permite descrever seus trabalhos de automação de uma maneira que se aproxima bastante do inglês comum. É uma ferramenta bastante popular!<br /> |-<br /> |'''Chef'''<br /> |Chef é uma ferramenta de gerenciamento de configurações escrita em Ruby e Erlang. O Chef usa uma linguagem específica de domínio, pura em Ruby, para escrever &quot;receitas&quot; na configuração do sistema. <br /> <br /> O Chef transforma a infraestrutura em código, onde você pode automatizar a criação, implantação e gerenciamento da sua infraestrutura, e de forma bastante versátil, testável e repetível. O servidor Chef armazena suas receitas e outros dados de configuração. <br /> <br /> O cliente Chef fica instalado em cada servidor, máquina virtual, container ou dispositivo de rede que você gerencia, chamados de &quot;nodes&quot;. O cliente consulta periodicamente a política e o estado mais recente da sua rede do servidor Chef. Se algo no nó estiver desatualizado, o cliente o atualizará.<br /> |-<br /> |'''Puppet'''<br /> |O Puppet é uma excepcional solução de DevOps para a automação de workloads de infraestrutura e aplicativos, e o gerenciamento contínuo destes. Muito frequentemente o Puppet é usado como ferramenta para gerenciamento de configurações, operando através de uma sofisticada arquitetura Master x Slave.<br /> Em curtas palavras, é composto de uma linguagem declarativa para expressar a configuração do sistema, um cliente e servidor para distribuí-lo, e uma biblioteca para realizar a tarefa de configuração pretendida.<br /> |-<br /> |'''SaltStack'''<br /> |O SaltStack ou &quot;Salt&quot; é uma ferramenta de gerenciamento e orquestração de configurações, fornecendo um repositório central para provisionar novos servidores e outras infraestruturas de TI, incluindo a instalação de software em servidores físicos, virtuais e cloud.<br /> <br /> O SaltStack automatiza tarefas repetidas de implementação administrativa e de código do sistema, eliminando processos manuais de maneira a reduzir os erros que ocorrem quando as organizações de TI configuram e disponibilizam seus sistemas. O Salt é bastante usado por times de DevOps porque extrai o código do desenvolvedor e as informações de configuração de um repositório de código central, como o GitHub ou o Subversion, e envia esse conteúdo remotamente para os servidores.<br /> <br /> Os usuários do Salt podem escrever seus próprios scripts e programas e fazer o download de configurações pré-construídas que outros usuários contribuíram para um repositório público.<br /> |-<br /> |'''CFEngine'''<br /> |CFEngine é um sistema de gerenciamento de configuração de código aberto, e a sua principal função é fornecer facilidades de configuração e manutenção automatizadas de sistemas de computadores em larga escala, incluindo o gerenciamento unificado de servidores, desktops, dispositivos industriais e de consumidor, dispositivos de rede incorporados, smartphones móveis e tablets.<br /> |-<br /> |'''GitLab'''<br /> |O GitLab é uma ótima ferramenta de ciclo de vida de DevOps que fornece um gerenciador de repositório Git, recursos de wiki, rastreamento de problemas e pipeline de CI/CD. Há um artigo em nossa Wiki demonstrando o gerenciamento de configurações de rede com ele.<br /> |-<br /> |'''OpenConfig'''<br /> |OpenConfig é um workgroup e também modelo de comunicação de rede que busca padronizar interfaces de gerenciamento de rede e APIs entre os principais fornecedores/vendors. O OpenConfig segue bem a proposta do que estamos discutindo neste artigo, que é a filosofia do afastamento natural dos administradores das ações de configuração por linha de comando (CLI), onde, cada vez mais, estes profissionais buscam promover configurações baseadas em códigos/programas e indo em direção às redes definidas por software (SDN).<br /> |-<br /> |'''OpenStack'''<br /> |O OpenStack é um sistema operacional que controla grandes pools de recursos de computação, armazenamento e rede em um datacenter, todos gerenciados e provisionados por meio de APIs com mecanismos de autenticação comuns. É impossível citar o termo &quot;SDN&quot; sem que o nome OpenStack seja lembrado, sendo, indiscutivelmente, a solução mais popular para este propósito.<br /> |-<br /> |'''OpenDaylight'''<br /> |O OpenDaylight (ODL) é uma plataforma aberta e modular para a customização e automação de redes de qualquer tamanho, porte e escala. O Projeto OpenDaylight surgiu do movimento SDN, com um foco claro na programação da rede. Foi desenvolvido desde o início como base para soluções comerciais que abordam uma variedade de casos de uso em ambientes de rede existentes, onde o Cisco OSC é um exemplo claro disto.<br /> |-<br /> |'''OpenContrail''' '''(Tungsten Fabric)'''<br /> |O Tungsten Fabric é uma solução de SDN para redes multicloud e automação multi-stack, e de código aberto. Utilizado para fornecer conectividade segura para workloads virtuais, containers ou bare-metal. Possui ótima integração com OpenStack, VMware vCenter, Kubernetes e Redhat Openshift.<br /> |-<br /> |'''Kubernetes'''<br /> |Kubernetes é um formidável sistema de orquestração de containers open source que automatiza a implantação, o dimensionamento e a gestão de aplicações em containers. Foi originalmente projetado pelo Google, e agora é mantido pela Cloud Native Computing Foundation. É um &quot;must have&quot; em ambientes onde containers são fundamentais para os projetos de infraestrutura.<br /> |-<br /> |'''Docker, Jails, LXC, LXD, etc.'''<br /> |FreeBSD Jails, Solaris Zones, LXC, Docker, Rkt, OpenVZ e LXD, enfim, são soluções para containers, cada qual com suas particularidades, propósitos, prós e contras. Está fora do escopo dissertar sobre containers aqui, exceto reforçar que são bastante utilizados em ambientes onde a elasticidade dos ambientes computacionais é cada vez mais exigida, assim como a cada vez maior necessidade por redução de tempo, esforços e custos.<br /> |-<br /> |'''Recursos proprietários de equipamentos'''<br /> |Saiba que o software de seu próprio equipamento de rede (roteador, switch, etc.), tipo o IOS, JUNOS e outros, possui recursos ou funcionalidades que servem para automatizar algum tipo de necessidade ou situação. Citarei alguns exemplos aqui:<br /> Generic Online Diagnostic (GOLD), Cisco Smart Call Home, Cisco Auto Smartports, Cisco IOS Embedded Event Manager (EEM), Zero Touch Provisioning (ZTP), PoAP, Scheduler, TCLsh, dentre muitos outros recursos, são exemplos clássicos de ferramentas/funcionalidades orientadas a algum tipo de automação de tarefa ou procedimento.<br /> <br /> Em combinação com outras tecnologias, soluções ou ferramentas, das tantas citadas nesta tabela, você poderá conquistar ótimos níveis de automação para uma diversidade impressionante de casos e situações.<br /> <br /> OBS: antes que você me questione ou reclame por eu ter citado apenas tecnologias &quot;Cisco&quot; aqui, relaxe: consulte a documentação de &lt;u&gt;'''SEU'''&lt;/u&gt; fabricante, pois é provável que você vá encontrar recursos similares para o seu equipamento! E sem chororô!<br /> |-<br /> |'''OpenFlow'''<br /> |O OpenFlow não é uma &quot;solução&quot; em si, mas sim uma combinação de especificações e protocolo que permite que os controladores de rede determinem o caminho os pacotes em uma rede, e operando no regime de separação entre os planos de controle e de dados, além de permitir o acionamento de ações periféricas tais como listas de controle de acesso (ACLs), protocolos de roteamento, QoS e outros.<br /> <br /> O OpenFlow permite que equipamentos de diferentes fabricantes (ex: switches e roteadores), sendo que cada qual com suas próprias interfaces proprietárias e linguagens de script, sejam gerenciados remotamente usando um único protocolo aberto. Os inventores do protocolo consideram o OpenFlow como um facilitador de redes definidas por software (SDN).<br /> <br /> Dentre outras coisas, o OpenFlow permite a administração remota de tabelas de encaminhamento de pacotes de roteadores, adicionando, modificando e removendo regras e ações de correspondência ou de incidência de pacotes. Dessa forma, as decisões de roteamento podem ser tomadas periodicamente ou por ad hoc pelo controlador, e traduzidas em regras e ações com uma lifecycle configurável, que são, então, aplicadas automaticamente nas tabelas dos equipamentos.<br /> <br /> Apesar de bastante promissor e muito interessante no ponto de vista de pesquisas e estudos, o OpenFlow nunca &quot;deslanchou&quot; como pensávamos que isto fosse acontecer um dia e, para falar a verdade, cada vez mais nos vemos mais distantes de implementá-lo em nossas infraestruturas!<br /> |-<br /> |'''Python'''<br /> |Python é uma linguagem de programação interpretada, orientada a objetos e de alto nível, com uma semântica dinâmica, e sintaxe simples e fácil de aprender. O Python suporta módulos e pacotes, o que incentiva a modularidade do programa e a reutilização de códigos. <br /> É certamente um dos &quot;queridinhos&quot; dos times de DevOps para as necessidades de automação de infraestruturas de redes.<br /> |-<br /> |'''Ruby'''<br /> |Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem dinâmica e forte e com gerenciamento de memória automático, e frequentemente utilizado como linguagem de script. <br /> Seu criador (Yukihiro “Matz” Matsumoto) juntou o &quot;melhor dos mundos&quot; de suas linguagens favoritas (Perl, Smalltalk, Eiffel, Ada, and Lisp) para a criação do Ruby. Muitos projetos bastante atraentes são baseados no Ruby, entre eles o The Metasploit Framework, Sass, Rails, Sinatra, Homebrew, Dicourse, Jekyll, Vagrant e Chef, para citar alguns exemplos.<br /> |-<br /> |'''Application Programming Interface (API)'''<br /> |Um conjunto de requisitos que governa como um aplicativo pode ser usado por outro. Uma API expõe funções internas ao mundo externo, ou seja, permite que outros aplicativos externos utilizem a funcionalidade dentro do aplicativo. O API não é um conceito novo, já que a maioria dos aplicativos modernos tem algum tipo de API. Frequentemente usa autenticação, enquanto a comunicação geralmente usa scripts Java, Python, XML ou HTTP simples, para exemplificar alguns casos. <br /> <br /> As APIs são extremamente fundamentais para ambientes de programabilidade, pois fornecem a devida modularidade, onde os aplicativos podem ser construídos em módulos que podem se comunicar com outros módulos por meio de uma API. Além disto, a abstração, pois permite expor parte das bibliotecas de um programa e ferramentas externas, na condição de orquestradores, os quais podem ser automatizados em um aplicativo ou infraestrutura de forma mais consistente e sem a necessidade de entender as implementações dos dispositivos da infraestrutura. <br /> <br /> E, por fim, a automação, pois as APIs são muito importantes para as tecnologias em nuvem, assim como projetos de infraestruturas de redes bem dinâmicas e elásticas, já que permitem que os recursos e o provisionamento sejam orquestrados por meios destas.<br /> |-<br /> |'''REST / RESTCONF'''<br /> |REST significa &quot;Representational State Transfer&quot;, um estilo de arquitetura para projetar aplicativos em rede que usa HTTP/S para fazer chamadas entre entidades. O REST opera em representações de recursos, cada qual identificado por uma URL, sendo crucial para projetos de infraestrutura prevendo ampla automação de praticamente todas as suas funções. Por exemplo, APIs northbound em SDN são geralmente ou preferencialmente SDN RESTful APIs usadas para a comunicação entre a controladora SDN e os tantos serviços e aplicativos em execução na rede. Essas APIs podem ser usadas para facilitar a orquestração e automação eficientes da rede para o alinhamento com as necessidades de diferentes aplicações, e fazendo isto via esta capacidade de programabilidade da rede SDN.<br /> O RESTCONF é um draft do IETF que procura descrever como mapear uma especificação Yang para uma interface RESTful. Os dados de resposta podem ser em formato JSON ou XML, cujas as estruturas, nestes casos, seguem de acordo com o JSON-YANG e XML-YANG, respectivamente.<br /> |-<br /> |'''NETCONF'''<br /> |O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no &lt;nowiki&gt;RFC 6241&lt;/nowiki&gt;. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações.<br /> <br /> Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando. Usando scripts, ou fazendo a configuração &quot;na mão&quot;. <br /> <br /> Basicamente dependíamos de algumas (ou várias!) gambiarras envolvendo scripts para o lançamento de configurações nos elementos de rede. Em alguns casos, para os mais afortunados, equipados com algumas soluções e componentes proprietários, tais como interfaces Linux embarcadas nos equipamento (tipo guestshell), CLI scraping, dentre outros casos, conseguíamos resultados interessantes. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, &quot;automatizados&quot;, é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF resolve o problema e dá um banho.<br /> <br /> O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, que será apresentado logo a seguir.<br /> <br /> O NETCONF é o que de fato promoveu excepcional capacidade de configuração de elementos de rede para os padrões atuais, em especial a instalação, configuração e manipulação de configurações em uma rede, e é considerado por muitos (inclusive por mim) como a melhor abordagem &quot;interface para o sul&quot; disponível atualmente.<br /> |-<br /> |'''Yang'''<br /> |O YANG é uma linguagem de modelagem de dados para o protocolo NETCONF, definindo uma hierarquia de dados que pode ser usada para operações baseadas em NETCONF, incluindo a configuração, dados de estado, RPCs e notificações. Em termos mais práticos, combinado ao protocolo NETCONF, o YANG fornece a linguagem de modelagem para a implementação de configurações sobre a rede, enquanto o NETCONF é o protocolo que efetivamente aplica estas configurações nos repositórios de dados relevantes sobre os dispositivos da rede.<br /> |-<br /> |'''XML'''<br /> |O XML significa &quot;Extensible Markup Language&quot;, e é uma linguagem de marcação muito parecida com HTML, projetada para transportar dados, enquanto o HTML concentra-se mais com a aparência destes dados. O XML requer que você defina suas próprias tags, além de ser projetado para ser auto-descritivo. Note que a natureza de transporte dados do XML o torna um dos formatos mais populares para a troca de dados numa infraestrutura prevendo a programabilidade. O protocolo NETCONF citado anteriormente utiliza este formato de dados.<br /> |-<br /> |'''JSON'''<br /> |JSON significa &quot;JavaScript Object Notation&quot;, que é um formato de dados que usa texto facilmente legível ou interpretável por nós, humanos, para transmitir objetos de dados que consistem em pares de atributo-valor. O JSON é relativamente bem fácil para que máquinas consigam analisar e gerar seu formato, e é construído com base em duas estruturas: pares de nome / valor, e lista ordenada de valores. Assim como o XML, o JSON é bastante popular por ser um formato de dados de fácil leitura e parsing, e é o formato de representação de dados mais usado em REST APIs.<br /> |-<br /> |'''Northbound APIs'''<br /> |Northbound APIs (&quot;APIs para o norte&quot;) são o elo entre os aplicações de TI, tais como os sistemas OSS e BSS, e o controlador SDN. Estas aplicações podem informar à rede sobre o que necessitam, incluindo parâmetros tais como dados, armazenamento, largura de banda, planos de produto, políticas de admissão, etc., fazendo com que a rede então possa fornecer estes recursos ou comunicar o que possui.<br /> <br /> Essas APIs northbound suportam uma ampla variedade de aplicativos, sendo geralmente os componentes mais moldáveis existentes em um ambiente SDN, pois existem muitas interfaces possíveis em diferentes locais das pilhas para controlar diferentes tipos de serviços por meio de uma controladora SDN. Ambientes SDN muito bem sucedidos (leia-se: funcionais de verdade, pra valer!) são aqueles que fazem as melhores integrações entre os sistemas da empresa e os controladores, por meios destas interfaces para o norte.<br /> <br /> Exemplos de serviços de rede que podem ser otimizados via interfaces norte incluem roteadores, switches, concentradores de assinantes de Internet banda larga, firewalls, balanceadores de carga, serviços de segurança definidos por software ou aplicativos de orquestração de recursos da nuvem, etc.<br /> <br /> As APIs Northbound também são usadas para integrar a controladora SDN com pilhas de automação, tais como Puppet, Chef, SaltStack, Ansible e CFEngine, além de plataformas de orquestração, como OpenStack, vCloudDirector da VMware ou CloudStack, de código aberto do Apache, e Cisco NSO. <br /> <br /> Nestes casos, o objetivo é abstrair o funcionamento interno da rede, para que os desenvolvedores de aplicações possam conectar-se à rede visando fazer alterações para acomodar as necessidades da aplicação.<br /> <br /> O maior e melhor exemplo de interface norte aqui seria por Representational State Transfer (REST) API, o qual é baseado em URIs (Uniform Resource Identifier, ou seja, URLs de tipo específico), transportados por protocolo HTTP/S e utilizando rotineiramente o formato de dados em JSON. Há muitas vantagens ao considerar este tipo de interface norte. Outros casos menos conhecidos incluem SMASH, IPMI, WSMAN, e SOAP, mas a lista não para por aí.<br /> |-<br /> |'''Southbound APIs'''<br /> |Equanto uma API Northbound (ou interface para o norte) é uma interface que permite que um componente específico de uma rede se comunique com um componente de nível superior, a API Southbound (ou interface para o sul), por sua vez, permite que um componente de rede específico se comunique com um componente de nível inferior.<br /> <br /> Apenas para constar: ambas as APIs northbound e southbound frequentemente existem em qualquer tipo de infraestrutura de rede ou ambiente computacionai, e não necessariamente, ou não apenas, em ambientes SDN, embora a popularização da SDNs tenha aumentado essa ligação destas APIs para si.<br /> <br /> Um exemplo clássico de API Southbound envolve as especificações para o funcionamento do protocolo OpenFlow, já apresentado previamente. Mas, conforme citado anteriormente, o OpenFlow de fato nunca deslanchou como achávamos que fosse acontecer, então citarei aqui um exemplo melhor: NETCONF! Nada melhor que citar o NETCONF/Yang para ilustrar o conceito de APIs Southbound! Outro exemplo um tanto conhecido disto é o Cisco OnePK.<br /> <br /> Exemplo mais &quot;pobres&quot; (ou menos sofisticados e flexíveis que o NETCONF, por exemplo) de interfaces para o sul seria invocação por procedimentos SSH e SNMP, mas, sabemos, há limitações em usar o SNMP para transportar dados de configuração, por exemplo, e por isto que sou fã incondicional do NETCONF.<br /> |-<br /> |'''Software-Defined Networking (SDN)'''<br /> |Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas principais: a camada de aplicação, a camada de controle e a camada de infraestrutura.<br /> |-<br /> |'''Network Functions Virtualization (NFV)'''<br /> |Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware &quot;''commodity''&quot;. Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado.<br /> |}<br /> Ufa, hein!<br /> <br /> Que tal ilustrarmos alguns destes (principais) componentes?[[Arquivo:Bpf-prog-tools.png|centro|miniaturadaimagem|814x814px|Alguns exemplos ou casos de ferramentas e soluções orientadas aos princípios de programabilidade]]De todas as coisas citadas na &quot;mega-tabela anterior&quot;, focaremos a seguir somente nos componentes que possuem relação direta com '''''&lt;u&gt;infraestrutura de redes&lt;/u&gt;''','' ou seja, dispensando situações envolvendo servidores, máquinas virtuais, containers e aplicações.<br /> <br /> ==== A integração entre dispositivos de redes, gerenciamento de configurações e pilhas de orquestração ====<br /> Já que o artigo tem como principal proposta falarmos de programabilidade e com foco no gerenciamento de configurações, talvez seja prudente comentar aqui as principais diferenças entre algumas das conhecidas soluções para esta necessidade. Lembra que eu comentei anteriormente que, em muitos casos, as plataformas de gerenciamento não atendem integralmente às nossas necessidades, especialmente no que diz respeito ao gerenciamento de configurações? Pois bem, é nessa hora que vale a pena considerar ótimas soluções para administrarmos isto. As mais conhecidas são o Chef, Puppet, Ansible e Salt. A tabela a seguir fornece um comparativo superficial entre eles.<br /> {| class=&quot;wikitable&quot;<br /> |+<br /> Comparativos entre as soluções de gerenciamento de configurações mais populares<br /> !<br /> !Chef<br /> !Puppet<br /> !Ansible<br /> !Salt<br /> |-<br /> |'''Template'''<br /> |Cookbook/Recipe<br /> |Manifest<br /> |Playbook<br /> |States/Pillars<br /> |-<br /> |'''Linguagem'''<br /> |Extensão do Ruby<br /> |Linguagem customizada semelhante ao JSON com opção Ruby<br /> |YAML<br /> |YAML<br /> |-<br /> |'''Licença'''<br /> |Apache<br /> |Apache<br /> |GPL<br /> |Apache<br /> |-<br /> |'''Agente'''<br /> |Requerido<br /> |Requerido<br /> |Não requerido<br /> |Não requerido, porém recomendado (&quot;Minions&quot;)<br /> |-<br /> | colspan=&quot;5&quot; |Confira os comparativos entre as diversas soluções deste tipo aqui:<br /> |-<br /> | colspan=&quot;5&quot; |https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software<br /> |}<br /> Os principais benefícios destas soluções são:<br /> * Automação do provisionamento<br /> * Consistência nas configurações dos elementos de rede<br /> * Controle de versões das configurações, onde a infraestrutura pode ser representada como código<br /> * Código aberto<br /> * Redução dos riscos de indisponibilidade da rede provocados por falha humana<br /> * Redução drástica do tempo de provisionamento de serviços<br /> [[Arquivo:Bpf-prog-puppervsansible.png|centro|miniaturadaimagem|800x800px|Comparativos superficiais entre Puppet e Ansible (Fonte: Cisco)]]<br /> De todas as soluções mostradas na tabela acima, o Ansible possui algumas vantagens a seu favor, incluindo o fato de não requerer agentes nos dispositivos, de ser escrito em Python (uma linguagem de fácil interpretação), de ser simples e fácil de começar a usar, suporte a rede, servidores e aplicações, por possuir uma taxonomia descomplicada, e por ser código aberto. Quanto a taxonomia do Ansible:<br /> * '''''Role''''': um conjunto de Playbooks<br /> * '''''Playbook''''': um padrão de configurações repetitivas<br /> * '''''Play''''': um conjunto de tarefas<br /> * '''''Task''''': uma única ação que é referenciada em um módulo<br /> * '''''Module''''': scripts standalone reusáveis<br /> [[Arquivo:Bpg-prog-ansible.png|centro|miniaturadaimagem|1024x1024px|Visão geral dos principais componentes do Ansible, em um exemplo envolvendo Cisco IOS/IOS XE]]<br /> Como o artigo é introdutório, não detalharei mais sobre o Ansible, e nem sobre outras ferramentas e soluções. Isto será feito naturalmente em futuros artigos aqui no BPF.<br /> <br /> Todavia. já recebemos uma colaboração recente neste sentido: [[Orquestrando sua rede com Ansible e Gitlab]], publicado pelo Renato Oliveira.<br /> <br /> Para finalizar, dependendo das suas necessidades em termos de projetos, facilidades e objetivos a serem conquistados, no que diz respeito ao Ansible, talvez você queira optar pelo [https://www.ansible.com/products/tower Ansible Tower].<br /> <br /> ==== O que é e o que não é o Software-Defined Networking (SDN) ====<br /> Conforme antecipado em outras ocasiões neste artigo, por incrível que possa parecer, não há uma dependência direta entre automação e SDN, neste exato sentido, pois, por exemplo, é possível instrumentar uma rede com bons padrões de automação usando ferramentas e recursos embarcados nos dispositivos da rede, e até mesmo com o auxílio de várias ferramentas, e sem que isto vá exigir controladoras SDN como um OpenStack, por exemplo. Por outro lado, em termos de eficiência de automação com muito foco na orquestração, o SDN possui uma relação direta com toda essa cadeia de programabilidade. Curioso, não? Para automatizar e até mesmo contar com padrões razoáveis de programabilidade na sua rede, o SDN não está necessariamente &quot;presente&quot;, mas, ao considerarmos o SDN, este promoverá um padrão de orquestração e automação incomparáveis, e isto é um fato!<br /> <br /> A propósito, você compreende o mínimo de SDN? Para os mais leigos, isto será bastante apropriado:<br /> * O SDN &lt;u&gt;não&lt;/u&gt; pode ser representado como se fosse um simples &quot;botão&quot;, onde clica-se e temos um ambiente pronto, rodando! Não é bem por aí... e está longe de ser algo deste tipo.<br /> * O SDN tem como uma de suas principais propostas a atenuação drástica dos esforços e complexidades operacionais associados com a &lt;u&gt;''orquestração''&lt;/u&gt;, provisionamento e manutenção de infraestruturas de redes.<br /> * O SDN é um esforço da indústria para a caracterização de redes mais automatizadas, ágeis, elásticas, e empregando menos esforços e custos operacionais, assim como a diminuição de riscos para os negócios das empresas.<br /> * O SDN &lt;u&gt;não&lt;/u&gt; obrigará que você torne-se um programador do dia para a noite, mas saber o essencial de lógica de programação e algumas linguagens de programação será muito útil para você poder destravar potenciais incríveis de seu ambiente!<br /> * O SDN &lt;u&gt;não&lt;/u&gt; substituirá a necessidade da sua empresa em continuar contando com engenheiros e operadores de NOC, muito pelo contrário! Todavia, a tendência é que consolidem-se no setor os profissionais mais especializados e diferenciados. Os negócios precisam evoluir (sempre para melhor), e por que você não pode fazer o mesmo com a sua carreira? <br /> ** Que tal levar a minha sugestão de '''''NetDevOps''''' mais a sério? A hora é essa!<br /> * O SDN originalmente busca promover uma abordagem de arquitetura que realiza uma separação bem legítima entre os planos de controle e de dados (''control plane'' e ''data plane''), levando o estado de informações, juntamente com a inteligência para tomadas de decisões, para um conceito logicamente centralizado. Ou seja, a centralização do estado de informações em uma zona estratégica da infraestrutura, enquanto os dispositivos de redes ficam mais dedicados e especializados em executar o processamento de pacotes e afins.<br /> * O SDN promove excepcional abstração entre a infraestrutura de rede (a qual possui seus serviços mais íntimos, tipo o IGP da infraestrutura, o MPLS, o QoS do backbone, etc.) e as aplicações e demais serviços da rede. E pode oferecer uma separação bastante interessante entre redes '''''underlay''''' e '''''overlay'''''.<br /> * O SDN pode ser representado como um conceito de interfaces programáticas que permitem que sistemas externos influenciem no provisionamento de serviços, controle e operações da rede.<br /> * O SDN fornece novas formas de interação com os equipamentos e serviços da rede via controladoras e APIs (''Application Programming Interface''). Neste caso, por interfaces ''northbound'' e ''southbound''.<br /> * O SDN permite formidáveis capacidades de provisionamento, orquestração, automação e normalização de equipamentos e serviços.<br /> * O SDN pode destravar diversas barreiras do seu negócio ao permitir que agentes externos - devidamente integrados à rede - consigam influenciar nas características de seu projeto e na sua operação, promovendo melhor alinhamento entre as tecnologias empregadas e os resultados almejados pelos modelos de negócios.<br /> * Os cenários de redes SDN podem ser:<br /> ** Uma rede onde os dispositivos retém os seus próprios planos de controle, mas que uma controladora SDN também mantém o estado de informação de protocolos e serviços, podendo influenciar e provisionar serviços sobre a rede. Isto seria o exemplo de uma abordagem híbrida.<br /> ** Uma rede onde todo o plano de controle é centralizado na(s) controladora(s) SDN, enquanto os equipamentos ficam dedicados para as funções de processamento de pacotes. O que seria o caso de uma abordagem SDN &quot;pura&quot;.<br /> ** Uma rede (tipificada como ''Underlay'') onde outras redes completamente distintas e abstraídas são provisionadas sobre ela, o que seria o caso típico das soluções para redes ''Overlay''.<br /> A ilustração a seguir mostra um excelente comparativo entre redes tradicionais e SDN, &quot;''for dummies''&quot; (para os leigos).[[Arquivo:Bpf-prog-sdn-tradicional.png|centro|miniaturadaimagem|800x800px|Comparativos entre redes tradicionais e SDN, para os leigos]]Já a próxima ilustração mostra de forma um tanto simplificada como um ambiente SDN pode ser representado em termos de seus principais componentes:<br /> [[Arquivo:Bpf-prog-sdn2.jpg|centro|miniaturadaimagem|800x800px|Exemplificando um ambiente SDN]]<br /> Exatamente qual ou quais controladoras você consideraria para o seu projeto (OpenStack, OpenDaylight, Contrail/Tungsten Fabric, Cisco OSC, ou algo mais específico (Cisco ACI, Huawei Agile, etc.)), assim como quais interfaces ''Northbound'' você deveria considerar (meus &quot;2 cents&quot;: eu recomendaria sempre que possível por REST API) e quais interfaces Southbound (recomendo sempre que viável o NETCONF/Yang), isto dependerá muito do seu projeto técnico, arquiteturas necessárias, integrações a serem realizadas, customizações, desenvolvimentos adicionais, etc., o que está completamente fora do escopo de um artigo introdutório. <br /> <br /> Para ser bem franco e honesto aqui, é bem factível que num primeiro momento você sequer necessite de um ambiente SDN puro, e talvez uma solução de orquestração devidamente integrada e implementada vá resolver a maior parte dos seus problemas e desafios, se não todos, mas isso, novamente, dependerá do seu projeto e do que se espera para a sua organização. A sua empresa realmente se beneficiaria muito se adotasse, por exemplo, o OpenStack juntamente com o OpenFlow? Você ou o seu time tem ''expertise'' para saber lidar com este padrão de arquitetura e essas soluções?<br /> <br /> Quem sabe uma solução de orquestração de configurações bem integrada à sua rede e sistemas não consiga fazer exatamente aquilo que você esteja buscando para a sua infraestrutura, sem exigir a complexidade de adoção de um OpenStack e OpenFlow? Por exemplo, eu particularmente considero o Cisco NSO excepcional, pois pode ou não ser integrado com controladoras SDN, standalone, ou integrado diretamente para os sistemas OSS e BSS da sua empresa via interfaces ''Northbound'', além de oferecer suporte absoluto multivendor, desde que seus equipamentos suportem NETCONF, o que seria bem razoável para plataformas de primeira linha, e sem que isto fosse necessitar da complexidade das controladoras SDN e do OpenFlow. Inclusive, caso você já possua o Ansible em seu ambiente, é possível integrar um módulo do Cisco NSO no Ansible via uma interface REST para JSON-RPC para que o NSO faça o ''parsing'' dos dados YAML dos Playbooks do Ansible em CDB do NSO, e conduza, na sequência, toda a orquestração pelas interfaces ''Southbound'' (ex: NETCONF/Yang) com os dispositivos da rede, mantendo todo os seus diferenciais e modelos de transações; ''commit dry-run'', ''rollback upon failure'', ''commit'', ''rollback'', relatórios de compliance de configurações, e tantos outros benefícios.<br /> [[Arquivo:Bpf-prog-nso.png|centro|miniaturadaimagem|800x800px|A solução Cisco NSO (Fonte: Cisco)]]<br /> [[Arquivo:Bpf-prog-nso2.png|centro|miniaturadaimagem|800x800px|A solução Cisco NSO integrada à ambientes mais complexos envolvendo Virtualização, Rede e Computação (Fonte: Cisco)]]<br /> Alternativamente ao Cisco NSO, você poderá partir para o Ansible Tower, se preferir, ou para o GitLab, ou as outras sugestões comentadas anteriormente, cada qual com suas vantagens, benefícios, prós e contras. Mas, no final das contas, você inevitavelmente terá que especificar todas as funcionalidades e processos desejados para as suas necessidades de orquestração e automação para poder, depois, selecionar melhor a arquitetura e soluções ideais para o seu projeto, e isto é um fato!<br /> <br /> E, para concluir, a ilustração a seguir mostra os possíveis cenários de SDN.<br /> [[Arquivo:Bpf-prog-sdn3.png|centro|miniaturadaimagem|1024x1024px|Cenários típicos de redes SDN]]<br /> <br /> === Conclusão do artigo ===<br /> O que era para ser um artigo, tornou-se quase um livro! Isto que dá escrever &quot;pelos cotovelos&quot; e sem um roteiro combinado! Sim... muito do que eu publico as vezes aqui na Wiki do BPF são &quot;estalos&quot;, inspirações, que me fazem quase que imediatamente a vir até aqui e sair digitando a torto e a direito, pois, do contrário, a inspiração &quot;esfria&quot;. Aí, durante o processo, um assunto vai puxando o outro e eu não sou muito fã de deixar as coisas incompletas ou mal esclarecidas, o que justifica meus artigos um tanto extensos. Apesar dessa dinâmica um tanto improvisada que tenho as vezes, é a minha &quot;cachaça&quot;! Estou perdoado?<br /> <br /> Espero que as informações apresentadas aqui tenham sido úteis para ajudá-lo a se interessar pelo tema e a embarcar no universo ''NetDevOps''!<br /> <br /> Propositalmente deixei de fora vários exemplos e detalhamentos acerca de algumas coisas muito importantes envolvendo o NETCONF/Yang, RESTCONF, XML e JSON, etc., e até mesmo das soluções citadas, tipo o Ansible, Puppet, Cisco NSO, e outras, pois isto tornaria o artigo realmente muito gigantesco. Mas, fique tranquilo, produzir artigos sobre estes temas, fornecendo demonstrações e tudo mais, está definitivamente no radar do Comitê de Programa do Brasil Peering Forum (BPF)!<br /> <br /> Obrigado por acompanhar o nosso trabalho, e contamos com você para promover e divulgar cada vez mais os conteúdos de nossa Wiki. Compartilhe sem dó nem piedade! Desejamos continuar contribuindo para o desenvolvimento dos provedores de acesso à Internet e, por tabela, tanto quanto, de qualquer empresa e de qualquer segmento que esteja buscando em nossa Wiki os conhecimentos necessários para a transformação de suas infraestruturas.<br /> <br /> Um abraço!<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Infraestrutura]]<br /> [[Categoria:SDN]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=O_Minimo_que_Voce_precisa_saber_sobre_o_BGP&diff=2509 2020-06-06T00:59:43Z

<p>Leonardo.furtado: </p> <hr /> <div>=== O mínimo que você precisa saber sobre o BGP ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Em minhas andanças Brasil afora e também nos grupos de discussão e nas redes sociais, com muita frequência, me deparo com a seguinte situação: indivíduos que precisam conceber políticas de roteamento com o BGP para o cumprimento de algum objetivo em seu Sistema Autônomo envolvendo a engenharia da rede ou a engenharia de tráfego. Por exemplo:<br /> <br /> &quot;''Preciso preferir rotas oriundas do AS 'X' a partir do IX em São Paulo. Como faço?'' &quot;<br /> <br /> &quot;Preciso ''influenciar o tráfego de entrada (download) de determinado serviço de conteúdo a partir do meu trânsito contratado com a 'xpto'? Alguém me ajuda?''&quot;<br /> <br /> &quot;''Como faço para influenciar o tráfego de saída (upload) por determinada sessão de peering 'xyz'?''&quot;<br /> <br /> &quot;''Qual é a melhor maneira de promover uma simetria mais proporcional sobre a ocupação dos enlaces com os meus upstreams?''&quot;<br /> <br /> E situações deste tipo.<br /> <br /> Ai eu analiso as tantas contribuições e ajudas que a comunidade fornece para esses requisitantes. Algumas ajudas são bem válidas, sem dúvidas, e outras um tanto desconexas. O que eu percebo é que muito frequentemente quem solicita a ajuda precisa em primeiro momento compreender como o BGP de fato funciona. O básico. O fundamental. E, em alguns casos, as almas boas que propõem-se a ajudar também deixam implícito que não conhecem tanto do BGP assim, mas que, de certa forma, habituaram-se a trabalhar com as ferramentas de manipulação do tráfego do BGP por pura e simples osmose. &quot;Um consultor veio aqui e fez isso, e desde então eu venho mantendo assim&quot;. Aquela famosa expressão &quot;papagaio de pirata&quot;.<br /> <br /> Por que estou escrevendo este artigo? Sinceramente? Porque eu entendo que lidar com políticas de roteamento para influenciar o envio e recebimento de rotas, manipulação do tráfego upload/download, engenharia de tráfego por BGP e afins, tudo isto, deve ser uma das últimas coisas que você de fato precisa se preocupar e dominar no BGP. Você primeiro precisa conhecer o funcionamento do BGP antes mesmo de querer implementar coisas mais sofisticadas. E é justamente isto que vejo faltando em muitos profissionais excessivamente preocupados com assuntos de políticas de roteamento do BGP.<br /> <br /> Muito do que fazemos ou do que precisa ser feito exige conhecimentos em diversas áreas fundamentais do BGP! Estou sendo bem honesto aqui: muitos realmente não dominam o básico do BGP e, por este motivo, possuem dificuldades em conceber determinados cenários envolvendo suas políticas de roteamento e outras coisas.<br /> <br /> Esta &quot;''palinha''&quot; que acompanha a ilustração/topologia mostrada a seguir tem um conceito que venho abordando há alguns anos para orientar profissionais que atuam em ISP sobre o funcionamento básico do BGP. Espero que seja igualmente útil para os frequentadores da Wiki do Brasil Peering Forum (BPF)!<br /> <br /> '''''&lt;u&gt;A estratégia de abordagem para este artigo será padrão &quot;bullets&quot;&lt;/u&gt;'''''. Isto é, sentenças curtas e bem objetivos para tentar mostrar o meu ponto de vista e o que eu estou tentando contribuir para estes profissionais e interessados.Considere como um livro compactado na forma de &quot;bullets&quot;!<br /> <br /> Confesso que muitos ainda assim terão dificuldades em compreender o BGP. Eu prometi que eu comentaria o básico e de forma objetiva. Eu não prometi o &quot;fácil&quot;: prometi apenas o fundamental!<br /> <br /> Caso você realmente precise de uma &quot;escovada&quot; mais básica nos temas de redes, posso sugerir aqui um artigo muito útil: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Mas, realmente, recomendo que você faça vários (e bons!) cursos na área. Está na hora de você fazer este investimento na sua carreira, não?<br /> <br /> Vamos lá?<br /> [[Arquivo:Photo 2019-11-05 14-23-30.jpg|centro|miniaturadaimagem|900x900px|O básico do BGP mostrado em uma única página!]]<br /> <br /> === Revisão de alguns conceitos bem básicos do BGP-4 ===<br /> Para todos os efeitos - e até mesmo para facilitar o seu entendimento sobre os fundamentos do BGP - considere a topologia a seguir. E vá acompanhando &quot;texto + topologia&quot; para melhorar o seu entendimento.<br /> [[Arquivo:Bpf-bgpfund-1.png|centro|miniaturadaimagem|900x900px|Uma topologia básica envolvendo o BGP]]<br /> <br /> ==== Por que preciso um protocolo de roteamento IGP tipo o OSPF na minha rede? Não poderia ter apenas o BGP rodando no meu AS? ====<br /> A resposta direta, crua e nua, é &quot;não!&quot;. O BGP depende de roteamento unicast para o seu funcionamento. Os &quot;bullets&quot; a seguir sintetizam os motivos disto:<br /> * O protocolo de roteamento BGP-4 não funciona “sozinho”, ou seja, numa rede (Autonomous System) não pode operar sem o auxílio do roteamento unicast do tipo IGP. O BGP depende diretamente das rotas IGP (não importa o tipo, podendo ser conectada, estática, OSPF, etc., mas desde que seja IGP) na tabela de roteamento do equipamento para realizar duas funções básicas:<br /> ** Transportar as sessões BGP entre os roteadores de uma determinada sessão.<br /> ** Validar o atributo NEXT_HOP do BGP num procedimento que chamamos de roteamento recursivo.<br /> <br /> ==== Não compreendo as diferenças entre IBGP e EBGP. Pensei que fossem apenas nomes a serem decorados. Quais são as diferenças funcionais? ====<br /> O que todos sabem é que há sessões &quot;internas&quot; e &quot;externas&quot;, ou seja, IBGP e EBGP. A primeira envolve sessões estabelecidas entre roteadores do mesmo AS, e a segunda, obviamente, entre roteadores em ASs distintos. As diferenças vão bem além dos simples termos &quot;EBGP&quot; e &quot;IBGP&quot; como muitos sugerem. A questão é funcional mesmo:<br /> # Há diferenças nos requerimentos para a formação de sessões BGP internas e externas. Por exemplo, sessões EBGP precisam ser estabelecidas através da mesma subrede IP (&quot;diretamente conectados no L2+IP&quot;), exceto quando fazendo isto por ''EBGP Multihop''. Enquanto isto, para as sessões IBGP, normalmente assumimos que os roteadores a serem vizinhos estejam de fato distantes entre si.<br /> # Há diferenças no que tange ao repasse de anúncios nos dois casos (ex: Split Horizon no IBGP, e até mesmo o descontinuado &quot;Synchronization&quot; do IBGP).<br /> # Há diferenças na preferência por rotas. Dependendo da disposição de atributos e estágios &quot;mais fortes&quot;, roteadores tendem a preferir rotas recebidas de sessões externas do que rotas para os mesmos prefixos recebidos por sessões internas.<br /> Agora, voltemos aos &quot;bullets&quot; aqui:<br /> * Para sessões EBGP, assumimos que os neighbors estejam diretamente conectados (mandatório = default), inclusive o TTL do cabeçalho IP é igual a “1” nos pacotes de uma sessão EBGP. Porém, quando os roteadores de AS distintos precisam formar uma sessão, e caso estejam separados por outros roteadores, você poderá configurar o ''ebgp-multihop'' para viabilizar esta sessão.<br /> * Para sessões IBGP, ao contrário das sessões EBGP, assumimos que os neighbors normalmente estejam distantes entre si dentro do AS (isto é, não estejam diretamente conectados).<br /> Para provar que BGP não funciona sem o auxílio de rotas IGP:<br /> * Não há mecanismos de descoberta de vizinhos BGP (um “''neighbor discovery''&quot; da vida), ao contrário do que ocorre com os protocolos de roteamento IGP. No caso do BGP, é mandatório configurar as vizinhanças (neighbors) manualmente.<br /> * O BGP não funciona por multicast com os endereços do escopo ''Local Network Control Block'' (224.0.0.0 - 224.0.0.255 (224.0.0/24)), como seria o caso de um protocolo de roteamento interior (OSPF, RIPv2, EIGRP) e sim por unicast (TCP porta 179). Uma sessão BGP não é muito diferente de, por exemplo, uma conexão com um serviço Web por transmissão unicast. É sério!<br /> ** Por ser uma transmissão Unicast, há obviamente os endereços de origem e destino no cabeçalho IP. Assim como teria num HTTP para o site do Facebook, por exemplo.<br /> * Numa sessão IBGP, como os neighbors frequentemente estão distantes entre si, é necessário haver uma rota IGP para se chegar até o referido neighbor e estabelecer a conexão TCP com este.<br /> ** O endereço IP de origem a ser utilizado no cabeçalho IP será aquele associado à interface de saída da rota IGP encontrada para a conexão com o vizinho BGP pretendido. Portanto, quando o roteador “10.1.1.1” da topologia acima desejar estabelecer uma sessão BGP com o roteador “10.4.4.4”, o que ele faz?<br /> *** O roteador “10.1.1.1” consultará a sua tabela de roteamento e buscará por uma rota unicast (pode ser diretamente conectada, OSPF, RIP, estática...) mais específica referente ao endereço IP de destino pretendido, que, neste caso, é o &quot;10.4.4.4&quot;.<br /> *** Determinará o next hop e a interface de saída associada a esta rota '''''IGP''''' que ele encontrar.<br /> *** O PDU da camada “Rede” (cabeçalho IP) conterá como endereço IP de origem o IP da interface de saída associada à rota IGP que aponta na tabela de roteamento para a rota mais específica encontrada satisfazendo o critério ao “10.4.4.4”. E, quanto ao endereço IP de destino deste cabeçalho IP, será obviamente o &quot;10.4.4.4&quot;. <br /> *** Só que isto poderá causar problemas, e explico o por que logo abaixo.<br /> ** Como os neighbors precisam estar pré-configurados, e podendo haver múltiplos caminhos internos no seu AS entre eles, poderá ser necessário &quot;amarrar&quot; isto numa interface loopback, usando-se o mecanismo &quot;''update-source loopback x''&quot; (ou procedimento similar no equipamento do seu fabricante). <br /> *** Isto significa que recomenda-se estabelecer as sessões IBGP utilizando-se os endereços IP das interfaces Loopback que, diga-se de passagem, deverão estar participando do IGP da rede.<br /> *** Portanto, usamos as interfaces loopback dos roteadores (tanto para a origem quanto para o destino) para estabelecer as sessões IBGP. Isto porque, na topologia acima, “10.1.1.1” espera pacotes da sessão BGP vindas de “10.4.4.4”, e vice-versa, e não de quaisquer outros endereços IP. Uma vez que múltiplos caminhos internos poderão existir e frequentemente existem entre A e B, poderá haver divergências quanto ao endereço IP de origem a ser especificado nos cabeçalhos IP.<br /> ** O não cumprimento disto fatalmente resultará na falha do estabelecimento da sessão BGP entre os dois vizinhos IBGP, pois o endereço IP de origem da transmissão poderá ser o de uma interface local ao router cujo endereço não é reconhecido como vizinho/neighbor IBGP no equipamento remoto o qual desejamos formar a sessão IBGP.<br /> * Em tempo, isto portanto isto reforça novamente o argumento que não há como BGP operar/funcionar sem o auxílio do roteamento unicast devidamente alimentado por rotas IGP.<br /> * Outra informação importante é que, de todas as rotas publicadas em uma tabela de roteamento, as únicas que não possuem interface de saída associada são justamente a rotas BGP, ao contrário do que ocorre com rotas IGP.<br /> ** Isto porque o BGP não é habilitado e não funciona diretamente sobre as interfaces dos roteadores, pois é um processo completamente &quot;global&quot; no equipamento. Ao oposto do que ocorre nos protocolos IGP, que são configurados globalmente, mas que, ainda assim, são ativados diretamente sobre as interfaces desejadas.<br /> *** O que ocorre aqui neste caso, dentre outras coisas, é o chamado &quot;''recursive routing lookup''&quot; (roteamento recursivo). Há alguns processos/threads relacionadas ao BGP no software dos roteadores, e um deles é responsável por realizar periodicamente, dentre outras funções importantes, um &quot;walking&quot; sobre a tabela BGP para a validação dos next-hops BGP, se os mesmos encontram-se alcançáveis através da tabela de roteamento com rotas IGP. <br /> **** Portanto precisamos do IGP para: a) transportar as sessões BGP. b) para validação e recursivo do atributo NEXT_HOP associado a cada uma das rotas mantidas na tabela BGP do roteador.<br /> A propósito, caso você tenha curiosidade, os protocolos de roteamento implementam um conceito chamado de ''Finite State Machine''. Que são justamente os estágios de formação de vizinhança. No caso do BGP, os estados são:<br /> * Idle<br /> * Active<br /> * Connect<br /> * Open Sent<br /> * Open Confirm<br /> * Established<br /> Compreender exatamente o que ocorre em cada um desses estágios é fundamental para que você consiga resolver problemas com formação de vizinhanças no BGP, sejam estas internas ou externas!<br /> [[Arquivo:BGP FSM.svg|centro|miniaturadaimagem|640x640px|Finite State Machine (FSM) do BGP]]<br /> <br /> ==== Alguns conceitos fundamentais sobre os atributos do BGP e o processo de seleção de caminhos ====<br /> * As “métricas” do BGP são bastante diferentes das métricas de outros protocolo de roteamento. O protocolo RIP por exemplo implementa o “''hop count''” (contagem de saltos). O OSPF por sua vez implementa o “''cost''” (custo, que é a banda de referência globalmente definida pelo OSPF - em muitos casos é 100 Mbps por padrão - dividida pela banda da interface), etc. Já o BGP é muito mais amplo que isto, por tratar-se de um protocolo vetor de caminhos (''path vecto''r). Não há na verdade “métricas”, e sim os chamados atributos de caminhos (''path attributes'').<br /> * Os atributos do BGP são categorizados nos seguintes: '''''Well-known Mandatory''''', '''''Well-Known Discretionary''''', '''''Optional Transitive''''' e '''''Optional Non-transitive'''''. Em particular, os atributos &quot;mandatórios” são: ''AS_PATH'', ''ORIGIN'' e o ''NEXT_HOP''. Estes atributos são chamados de mandatórios porque precisam constar em todas as mensagens ''Update'' do BGP (por onde ocorrem o envio e o recebimento de prefixos (“anúncios”)). <br /> Resumindo aqui:<br /> * Atributos &quot;''Well-Known''&quot;: todo roteador que se preze e que suporte o BGP precisa por obrigação compreender aquele atributo recebido, caso seja um ''Well-Known''.<br /> ** ''Mandatory'': obrigatório ser incluído em todas as mensagens ''Update''.<br /> ** ''Discretionary'': a presença do atributo nas mensagens Update é facultativa. Mas, se um atributo desse for incluído, o roteador que o receber precisará compreendê-lo.<br /> * Atributos &quot;''Optional''&quot;: o roteador não é &quot;obrigado&quot; a compreender o atributo. Vai que não suporta (ainda) no seu código?<br /> ** ''Transitive'': caso o roteador suporte, fará uso do atributo e o repassará adiante para outros peers. Caso não suporte o referido atributo, passará adiante da mesma forma.<br /> ** ''Non-Transitive'': o atributo não é repassado para outros peers, sendo reconhecido ou não.<br /> A ilustração a seguir mostra os '''&lt;u&gt;principais&lt;/u&gt;''', ou, melhor, os mais '''&lt;u&gt;conhecidos&lt;/u&gt;''' atributos do BGP, sendo que a maioria deles sequer é utilizada para o processo (natural) de seleção das melhores rotas na tabela BGP.<br /> [[Arquivo:Bpf-bgpfund-4.png|centro|miniaturadaimagem|900x900px|Os principais (ou mais conhecidos) atributos do BGP]]<br /> Mas a lista de atributos do BGP é bastante extensa! A tabela a seguir dá uma noção do quanto o profissional precisa estar preparado para conhecer as aplicabilidades de cada um destes tantos atributos.<br /> <br /> OBS: a lista é mantida e atualizada pelo IANA na URL [https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2 Border Gateway Protocol (BGP) Parameters].<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |Valor<br /> |Código<br /> |Referência<br /> |-<br /> |0<br /> |Reserved<br /> |<br /> |-<br /> |1<br /> |ORIGIN<br /> |[RFC4271]<br /> |-<br /> |2<br /> |AS_PATH<br /> |[RFC4271]<br /> |-<br /> |3<br /> |NEXT_HOP<br /> |[RFC4271]<br /> |-<br /> |4<br /> |MULTI_EXIT_DISC<br /> |[RFC4271]<br /> |-<br /> |5<br /> |LOCAL_PREF<br /> |[RFC4271]<br /> |-<br /> |6<br /> |ATOMIC_AGGREGATE<br /> |[RFC4271]<br /> |-<br /> |7<br /> |AGGREGATOR<br /> |[RFC4271]<br /> |-<br /> |8<br /> |COMMUNITY<br /> |[RFC1997]<br /> |-<br /> |9<br /> |ORIGINATOR_ID<br /> |[RFC4456]<br /> |-<br /> |10<br /> |CLUSTER_LIST<br /> |[RFC4456]<br /> |-<br /> |11<br /> |DPA (deprecated)<br /> |[Chen, E., Bates, T., &quot;Destination Preference Attribute for BGP&quot;, Work in progress, March 1996.][RFC6938]<br /> |-<br /> |12<br /> |ADVERTISER (historic) (deprecated)<br /> |[RFC1863][RFC4223][RFC6938]<br /> |-<br /> |13<br /> |RCID_PATH / CLUSTER_ID (Historic) (deprecated)<br /> |[RFC1863][RFC4223][RFC6938]<br /> |-<br /> |14<br /> |MP_REACH_NLRI<br /> |[RFC4760]<br /> |-<br /> |15<br /> |MP_UNREACH_NLRI<br /> |[RFC4760]<br /> |-<br /> |16<br /> |EXTENDED COMMUNITIES<br /> |[Eric_Rosen][draft-ramachandra-bgp-ext-communities-00][RFC4360]<br /> |-<br /> |17<br /> |AS4_PATH<br /> |[RFC6793]<br /> |-<br /> |18<br /> |AS4_AGGREGATOR<br /> |[RFC6793]<br /> |-<br /> |19<br /> |SAFI Specific Attribute (SSA) (deprecated)<br /> |[Gargi_Nalawade][draft-kapoor-nalawade-idr-bgp-ssa-00][draft-nalawade-idr-mdt-safi-00][draft-wijnands-mt-discovery-00]<br /> |-<br /> |20<br /> |Connector Attribute (deprecated)<br /> |[RFC6037]<br /> |-<br /> |21<br /> |AS_PATHLIMIT (deprecated)<br /> |[draft-ietf-idr-as-pathlimit]<br /> |-<br /> |22<br /> |PMSI_TUNNEL<br /> |[RFC6514]<br /> |-<br /> |23<br /> |Tunnel Encapsulation Attribute<br /> |[RFC5512]<br /> |-<br /> |24<br /> |Traffic Engineering<br /> |[RFC5543]<br /> |-<br /> |25<br /> |IPv6 Address Specific Extended Community<br /> |[RFC5701]<br /> |-<br /> |26<br /> |AIGP<br /> |[RFC7311]<br /> |-<br /> |27<br /> |PE Distinguisher Labels<br /> |[RFC6514]<br /> |-<br /> |28<br /> |BGP Entropy Label Capability Attribute (deprecated)<br /> |[RFC6790][RFC7447]<br /> |-<br /> |29<br /> |BGP-LS Attribute<br /> |[RFC7752]<br /> |-<br /> |30<br /> |Deprecated<br /> |[RFC8093]<br /> |-<br /> |31<br /> |Deprecated<br /> |[RFC8093]<br /> |-<br /> |32<br /> |LARGE_COMMUNITY<br /> |[RFC8092]<br /> |-<br /> |33<br /> |BGPsec_Path<br /> |[RFC8205]<br /> |-<br /> |34<br /> |BGP Community Container Attribute (TEMPORARY - registered 2017-07-28, extension registered 2018-08-10, expires 2019-07-28)<br /> |[draft-ietf-idr-wide-bgp-communities]<br /> |-<br /> |35<br /> |Internal Only To Customer (TEMPORARY - registered 2018-03-29, extension registered 2019-03-18, expires 2020-03-29)<br /> |[draft-ietf-idr-bgp-open-policy]<br /> |-<br /> |36<br /> |BGP Domain Path (D-PATH) (TEMPORARY - registered 2019-07-08, expires 2020-07-08)<br /> |[draft-ietf-bess-evpn-ipvpn-interworking]<br /> |-<br /> |37-39<br /> |Unassigned<br /> |<br /> |-<br /> |40<br /> |BGP Prefix-SID<br /> |[RFC-ietf-idr-bgp-prefix-sid-27]<br /> |-<br /> |41-127<br /> |Unassigned<br /> |<br /> |-<br /> |128<br /> |ATTR_SET<br /> |[RFC6368]<br /> |-<br /> |129<br /> |Deprecated<br /> |[RFC8093]<br /> |-<br /> |130-240<br /> |Unassigned<br /> |<br /> |-<br /> |241<br /> |Deprecated<br /> |[RFC8093]<br /> |-<br /> |242<br /> |Deprecated<br /> |[RFC8093]<br /> |-<br /> |243<br /> |Deprecated<br /> |[RFC8093]<br /> |-<br /> |244-254<br /> |Unassigned<br /> |<br /> |-<br /> |255<br /> |Reserved for development<br /> |[RFC2042]<br /> |}<br /> Voltando aqui para a linha de raciocínio com os &quot;bullets&quot;! Vejamos:<br /> * O BGP emprega, em ordem linear, 11 (onze) critérios para a seleção de caminhos, e isto pode ser um pouco diferente dependendo da plataforma/fabricante. Por exemplo, o conhecido &quot;''Weight''&quot; não é na verdade um atributo, pois não navega nas mensagens ''Update'' e, sim, é um mecanismo local no roteador. E é proprietário (Cisco), portanto não é fatorado no processo de seleção de rotas BGP em roteadores não Cisco.<br /> * Eu costumo citar especialmente aqui que o critério &quot;zero&quot; é: &quot;''um router BGP só considera durante o processo de seleção de best paths de rotas BGP somente aquelas cujo o atributo NEXT_HOP for conhecido ou 'alcançável' por rotas IGP na tabela de roteamento''&quot;.<br /> ** Portanto, novamente, reforçamos aqui o conceito de &quot;''recursive routing''&quot; efetuado pelo BGP.<br /> Falando do processo de seleção de rotas do BGP, que tal visualizarmos isto com maior amplitude? Fique atento ao processo suportado/executado pelo &lt;u&gt;seu&lt;/u&gt; roteador/fabricante, pois alguns conceitos poderão ser diferentes dos mostrados a seguir. Outra informação importante: comparados à extensa lista acima, são poucos (mesmo) os atributos usados para manipular o tráfego através de uma política de roteamento no BGP.<br /> [[Arquivo:Bpf-bgpfund-2.png|centro|miniaturadaimagem|900x900px|Processo de seleção de rotas do BGP]]<br /> <br /> ==== Quais roteadores do meu AS precisam de fato rodar o BGP? ====<br /> Quanto ao &quot;rodar ou não rodar&quot; BGP em todos os routers no AS&quot;, esclareço que:<br /> <br /> a) Em um AS &quot;corporativo&quot; ou &quot;''Non Transit AS''&quot;, na maioria dos casos não é necessário sessões IBGP em todos os roteadores no AS. Geralmente fazemos o EBGP nos routers de borda com as operadoras/ISP, e uma sessão IBGP entre estes routers na borda. Estes roteadores BGP tipicamente geram uma rota default (0.0.0.0/0) via protocolo IGP (OSPF ou outro) que for suportado dentro do AS, para os demais roteadores (não BGP) poderem encaminhar o tráfego de saída através desta rota default para os destinos de Internet.<br /> <br /> b) No entanto, em um AS de Trânsito, é &quot;obrigatório&quot; rodar o IBGP em todos os roteadores no AS que estiverem no meio do caminho do tráfego que precisa transitar pelo AS, e devido a limitações do IBGP, sendo as seguintes:<br /> * Uma rota BGP não sofre quaisquer modificações de seus atributos dentro do AS entre as sessões IBGP. Isto é, uma vez a rota tiver sido injetada no AS e repassada para os neighbors IBGP, ela não sofrerá quaisquer modificações em seus atributos.<br /> * Portanto, uma vez que a rota BGP, quando repassada por IBGP, não sofre qualquer modificação de atributos, seria relativamente muito plausível que pudesse ocorrer um &quot;''routing loop''&quot; no AS, já que não haveria controle de diâmetro (saltos) ou incremento de &quot;custos&quot; (que são inexistentes na arquitetura do BGP), etc.<br /> ** Por este motivo, há uma regra imposta para as sessões IBGP: rotas recebidas via IBGP não poderão ser repassadas para outros neighbors IBGP. É o que chamamos de &quot;'''''Split Horizon'''''&quot; do BGP. Isto é o comportamento padrão envolvendo as sessões IBGP.<br /> ** Portanto isto significa que é mandatório possuir sessões IBGP em formação FULL MESH. Ou seja, todos os routers IBGP sendo neighbors entre si.<br /> *** Obviamente em redes maiores isto poderá limitar um tanto a escalabilidade do AS, pois muitas sessões IBGP seriam requeridas dentro do AS, conforme regra &quot;'''''N*(N-1)/2'''''&quot;.<br /> *** No entanto, há soluções para a mitigação o relaxamento das exigências por full mesh das sessões IBGP, e estas soluções seriam o '''''Route Reflector''''' ou '''''cluster de Rote Reflectors''''' (para maior redundância e disponibilidade) ou ainda o '''''Intra-AS Confederation''''', ou ainda a mistura das duas coisas. Cada projeto de BGP é um projeto distinto e com necessidades únicas.<br /> * Caso o IBGP seja utilizado somente entre os routers de borda conforme ilustrado no AS 200, o pacote morreria no meio do caminho (dentro do AS 200) devido ao problema do ''Split Horizon'' do BGP.<br /> ** Por exemplo, o router &quot;10.1.1.1&quot; da topologia mostrada no início desse artigo possui a rota BGP para a rede &quot;50.50.50.0/24&quot; via Next-Hop 192.168.0.2, que está no AS 100. Ele considera esta rota válida porque o roteamento recursivo neste roteador encontrará uma rota diretamente conectada (192.168.0.0/30) para este atributo NEXT_HOP citado na rota BGP. <br /> ** Em seguida, o roteador “10.1.1.1” repassará este anúncio (50.50.50.0/24) para os roteadores “10.2.2.2” e “10.3.3.3” através das sessões IBGP que mantém com estes dois roteadores. <br /> ** Estes dois roteadores por sua vez '''&lt;u&gt;não&lt;/u&gt;''' repassarão este anúncio para o roteador “10.4.4.4” porque isto fere a regra do ''Split Horizon'' do BGP (“''não repassar para peers IBGP quaisquer rotas que tenham sido aprendidas através de uma sessão IBGP''&quot;).<br /> *** Isto poderia evitado de duas formas:<br /> **** Configuração das sessões IBGP em regime &quot;''full mesh''&quot;, ou seja, todos são neighbors IBGP entre si.<br /> **** Configuração de um roteador como ''Router Reflector'', ou ainda dois ou mais roteadores em uma disposição de &quot;cluster&quot; de Route ''Reflectors''. Ou então por ''Confederation''.<br /> ***** Na topologia fornecida nesta artigo, os roteadores &quot;10.1.1.1&quot; e &quot;10.4.4.4&quot; estão configurados como ''Route Reflectors'' e no mesmo ''Cluster''. Isto significa que todos os roteadores do AS 200 precisariam de sessões IBGP com apenas estes dois roteadores do Cluster.<br /> ****** Lembro novamente que ''Route Reflectors'' &quot;quebram&quot; a exigência por full mesh das sessões IBGP em um AS, e roteadores configurados com este mecanismo podem refletir rotas recebidas por sessões IBGP para outros roteadores IBGP que sejam seus cientes de RR.<br /> c) OK, temos aqui a solução para um AS de Trânsito: rodar o BGP em todos os roteadores que estiverem &quot;in-line&quot; com o tráfego. E, para fugirmos do requerimento por sessões em ''full-mesh'', construímos as sessões com o auxílio de ''Route Reflectors'' ou ''Confederation''. Mas, calma, há uma forma mais interessante de conduzirmos isto, vide logo a seguir.<br /> <br /> ==== Sobre rodar o BGP em toda a rede do AS, especialmente nos roteadores de Core (P-routers) ====<br /> Na prática ou em tese todos os roteadores que estiverem no mesmo caminho do tráfego em trânsito em um AS precisam rodar o BGP, certo? Há uma solução “mais elegante” para esta questão, e ela está amplamente e bem difundida em um artigo disponível na Wiki do BPF: '''''BGP-Free Service Provider Core'''''.<br /> <br /> Não detalharei essa solução aqui porque tudo isto já está bem esclarecido no artigo [[Redes MPLS para Provedores]].<br /> <br /> ==== Um ponto final na questão do roteamento recursivo ====<br /> No cenário em que o roteador &quot;10.1.1.1&quot; recebe a rota para a rede 50.50.50.0/24 via a sessão EBGP que possui com o AS 100. Este roteador reconheceria esta rota como válida (pelas validações dos atributos mandatórios) e pelo fato de ser capaz de efetuar o roteamento recursivo referente ao atributo NEXT_HOP desta rota, que seria o endereço IP 192.168.0.2. Afinal de contas, este roteador possui uma rota diretamente conectada para este next hop.<br /> <br /> No entanto, ao repassar este anúncio (50.50.50.0/24) para os demais roteadores do AS 200 (&quot;10.2.2.2&quot;, &quot;10.3.3.3&quot;, &quot;10.4.4.4&quot;), seja em regime ''full-mesh'' ou em regime com ''Route Reflectors'', teríamos outro desafio aqui. Com a exceção do próprio roteador &quot;10.1.1.1&quot;, nenhum dos demais roteadores seria capaz de concluir o recursivo referente ao atributo NEXT_HOP, pois o endereço IP especificado (192.168.0.2) não pode ser encontrado em uma rota IGP do AS 200. E isto é fato na grande maioria das implementações do BGP. A solução para este desafio poderá ser um das três sugestões apresentadas a seguir:<br /> # Configurar o IGP da rede (ex: OSPF) para incluir a conexão externa entre os AS 100 e 200, porém definindo a interface do roteador &quot;10.1.1.1&quot; com o AS 200 como ''Passive''. <br /> # No roteador &quot;10.1.1.1&quot;, redistribuir a interface que conecta o AS 100 ao AS 200 para o IGP (ex: OSPF) do AS 200.<br /> # Modificar o atributo NEXT_HOP &lt;u&gt;antes&lt;/u&gt; de repassar o anúncio para as sessões IBGP. Que inclusive é o método mais utilizado por aí.<br /> ## Agora você compreende o significado do recurso '''''&quot;next-hop-self'''''&quot; na configuração das vizinhanças IBGP do seu roteador. Certo?<br /> <br /> ==== Uma observação quanto a manipulação de tráfego com o BGP ====<br /> Sintetizando aqui e bastante, pois a expectativa é que tenhamos um artigo no BPF para tratarmos única e exclusivamente disto:<br /> <br /> ===== Manipulação do tráfego da saída (upload) do seu AS =====<br /> Você tem três alternativas aqui:<br /> # Em equipamentos Cisco ou outros vendors que suportarem um recurso similar, usar o recurso ''Weight'' para preferir a rota recebida daquele peer acima de todas as demais opções (maior ''Weight''). O ''Weight'' é um recurso local ao router, e &lt;u&gt;não&lt;/u&gt; um atributo! Logo, não acompanha as mensagens Update (ou seja, os anúncios).<br /> # Implementar uma política de roteamento que aplique o atributo ''LOCAL_PREF'' correto (maior valor de ''LOCAL_PREF'') para promover a preferência de rotas recebidas a partir de um peering ou trânsito, podendo classificá-las (estes prefixos/rotas) por vários métodos possíveis e cabíveis aqui, incluindo Communities, prefixos, AS_PATH, etc.<br /> # Controlar o recebimento de anúncios mais específicos vs. menos específicos nas suas saída com a Internet. O que seria uma ação mais difícil.<br /> <br /> ====== Entendimento sobre o uso do atributo LOCAL_PREF ======<br /> O ''Local Preference'' é um atributo do tipo ''Well-Known Discretionary'', ou seja, o roteador poderá ou não incluir este atributo em seus anúncios, mas, caso inclua, o roteador que o receber deverá compreender o atributo, e isto é obrigatório aqui. Onde e como usar o ''LOCAL_PREF''?<br /> <br /> O ''LOCAL_PREF'' deve ser usado (aplicado) &lt;u&gt;apenas&lt;/u&gt; sobre rotas recebidas de sessões EBGP para que possa ser devidamente repassado para os seus peers &lt;u&gt;IBGP&lt;/u&gt; (ou seja, no seu AS), ou quando você estiver gerando ou agregando rotas pelo BGP dentro do seu AS. O ''LOCAL_PREF'' tem utilidade e somente funciona &lt;u&gt;dentro do seu sistema autônomo (AS)&lt;/u&gt;. É inútil configurá-lo para anúncios entre sessões EBGP! &lt;u&gt;Você não pode influenciar um AS vizinho com o LOCAL_PREF&lt;/u&gt;!<br /> <br /> Cada vez que eu vejo isso configurado numa policy OUT para fins de anúncios para um peer EBGP, eu realmente fico sem palavras pra me expressar - brincadeiras à parte aqui. Com as minhas próprias palavras, isto seria tipo o maior '''placebo''' que há na questão envolvendo atributos. Dessa forma, não funciona para coisa alguma, mas também não causa mal algum. Por mim, o software dos roteadores deveria recusar essa configuração no ''commit'' por violação de semântica, mas talvez isto não ocorra (a recusa de commit da configuração) porque o LOCAL_PREF excepcionalmente pode ser encaminhado entre sessões EBGP em um cenário de ''Confederations'' &lt;u&gt;apenas&lt;/u&gt;.<br /> <br /> Isto está nem documentado pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt; seção 5.1.5.<br /> [[Arquivo:Bpf-bgpfund-lp.png|centro|miniaturadaimagem|899x899px|&lt;nowiki&gt;RFC 4271&lt;/nowiki&gt; seção 5.1.5 (sobre o LOCAL_PREF)]]<br /> <br /> ===== Manipulação do tráfego de entrada (download) do seu AS =====<br /> Você tem três alternativas aqui:<br /> # Manipular o atributo ''AS_PATH'' para realizar o prepend quando repassando o prefixo para peering ou trânsito &quot;x&quot;. Você poderá classificar os prefixos de interesse por vários métodos possíveis e suportados, tais como os próprios prefixos diretamente, ou atributo ''AS_PATH'', ou com Communities, etc., e fazer o prepend de acordo.<br /> # Alternar o repasse de anúncios menos específicos vs. mais específicos para os peers desejados. E a classificação disto podendo ser feita pelos mesmos métodos supracitados.<br /> # Caso você possua duas ou mais saídas para um mesmo AS vizinho, você poderá utilizar o atributo ''Multi-Exit Discriminator'' (MED), também conhecido por &quot;''metric''&quot;, informando um valor menor desejado (no caso do MED, menor = melhor) quando repassando seus anúncios para este AS vizinho, e fazendo isto no intuito de tentar influenciar o tráfego entrante. O MED é um atributo tido como &quot;fraco&quot; e muito frequentemente não funciona bem para este propósito. A implementação do MED em saídas com dois ou mais AS distintos por meios de ''always-compare-med'' é uma possibilidade que pode ser estudada nos acordos de tráfego entre os sistemas autônomos envolvidos.<br /> <br /> ====== Entendimento sobre o uso do atributo MED ======<br /> O ''Multi-Exit Discriminator'' (MED) é um atributo ''Optional Non-Transitive'' e o mesmo deve ser utilizado (apenas!) para '''&lt;u&gt;tentarmos&lt;/u&gt;''' influenciar o tráfego de entrada do AS quando havendo duas ou mais sessões EBGP (cenário ''dual-homed'', etc.) com um &lt;u&gt;mesmo&lt;/u&gt; sistema autônomo vizinho. O MED funciona &lt;u&gt;apenas&lt;/u&gt; para anúncios realizados entre sessões &lt;u&gt;EBGP&lt;/u&gt;! E o fato do atributo ser &quot;''Non-Transitive''&quot; significa que ele (o atributo apenas) não é repassado para além do sistema autônomo (AS) vizinho que recebeu o anúncio contendo este atributo. Ou seja, o seu AS vizinho não repassará o MED para outros AS. Isto está bem documentado pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt;, seção 5.1.4.<br /> [[Arquivo:Bpf-bgpfund-med.png|centro|miniaturadaimagem|898x898px|&lt;nowiki&gt;RFC 4271&lt;/nowiki&gt; seção 5.1.4 (sobre o MED)]]<br /> Para concluir, o MED é tido como um atributo &quot;fraco&quot; e que frequentemente não atinge o objetivo proposto, e isto por se tratar do sexto (ou quinto, dependendo da plataforma) critério de seleção de uma &quot;''best path''&quot; do BGP. O MED também é menos funcional ainda quando precisa ser comparado em anúncios oriundos de dois ou mais sistemas autônomos distintos - o que por só já exige configurações e cooperações adicionais - pois isto não é suportado pelas vias normais.<br /> <br /> A única forma de manipulação de tráfego de entrada com a consequente seleção de caminhos (ou vice-versa) entre o seu AS e dois ou mais AS vizinhos é com o recurso de prepend de atributo AS_PATH e as estratégias de alternância entre &quot;anúncios menos específicos&quot; versus &quot;anúncios mais específicos&quot;.<br /> <br /> OBS: o MED pode ser utilizado para codificar métricas de rotas IGP eventualmente redistribuídas para o BGP e de forma a possibilitar algum controle sobre o tráfego ou para fins de manutenção da transparência (ou não) da métrica das rotas IGP originais, fim-a-fim, quando redistribuindo novamente de BGP para IGP. Isto seria o caso de setups de L3VPN MPLS. No entanto, isto está fora do escopo deste artigo.<br /> <br /> ===== Conclusões finais sobre manipulação de tráfego de entrada e de saída =====<br /> Não existe &quot;mágica&quot;! É exatamente isto. Em ambos os casos (download e upload) você precisará de uma '''&lt;u&gt;matriz de tráfego&lt;/u&gt;'''! Como projetar políticas de roteamento efetivas se você sequer compreende como as conversações fluem no seu Sistema Autônomo? Quais são os volumes de tráfego por endereços IP ou blocos de endereços IP de origem e destino, quais são os sistemas autônomos e seus respectivos registros de consumo de tráfego IN e OUT, top talkers por tipo de protocolo, etc.<br /> <br /> Mas discutiremos este tema com bastante detalhes em futuro artigo aqui no BPF. Fique antenado!<br /> <br /> Em tempo, confira um pouco deste tema neste artigo aqui: [[Como fazer com que um determinado conteudo saia por um link especifico|Como fazer com que um determinado conteúdo saia por um link específico]] , caso você tenha pressa em fazer alguma coisa acontecer!<br /> <br /> === Uma observação quanto à segurança do roteamento de Internet ===<br /> Fora do escopo do artigo, mas preciso deixar bem claro. As políticas de roteamento BGP não servem apenas para você influenciar o upload ou o download da rede, ou para descartar o envio e recebimento de anúncios indesejados por quaisquer razões que sejam. As políticas de roteamento do BGP, em combinação com diversos (outros) procedimentos complementares, são indispensáveis para promover a segurança e disponibilidade do roteamento de '''&lt;u&gt;toda&lt;/u&gt;''' a Internet! Ou seja, evitar vazamentos de rotas impróprias em sistemas autônomos, sequestro de prefixos, congestionamento/gargalos, indisponibilidades massivas, dentre outras graves complicações.<br /> <br /> Fique atento quanto aos muitos controles e cuidados propostos/sugeridos pelo ''Mutually Agreed Norms for Routing Security'' (MANRS) ou Normas de Acordo Mútuo para Segurança de Roteamento! E siga as boas práticas para a proteção do seu Sistema Autônomo e, consequentemente, de toda a Internet!&lt;blockquote&gt;'''&quot;A disposição de cada um é a segurança de todos!&quot;'''&lt;/blockquote&gt;Felizmente o BPF está tratando de divulgar estes temas, e já contamos com ótimos artigos sobre o assunto. E outros virão com o tempo. Confira os artigos já publicados aqui:<br /> * [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para Proteção de Roteadores e Switches]]<br /> * [[Boas Praticas para Melhorar a Seguranca de seu Provedor|Boas Práticas para Melhorar a Segurança de seu Provedor]]<br /> * [[MANRS]]<br /> <br /> === Coisas que você não deveria fazer no seu ambiente BGP ===<br /> '''(Eventualmente esta seção do artigo será reeditada com o tempo, pois sempre surgirão motivos para &quot;documentar&quot; aqui!)'''<br /> [[Arquivo:Bpf-bgpfund-meme.jpg|centro|miniaturadaimagem|979x979px|Verdades dóem!]]<br /> <br /> Aqui eu relaciono algumas boas &quot;verdades&quot; com relação a diversas (más) práticas que vejo na questão de BGP de muitos ISPs. Seja um bom profissional e '''&lt;u&gt;não&lt;/u&gt;''' cometa os deslizes comentados abaixo:<br /> # '''PTT não é trânsito.''' Saiba dimensionar o seu trânsito para ter capacidade de escoamento de tráfego quando ocorrerem falhas nas sessões de peering.<br /> # '''Não existe &quot;link puro&quot;.''' Trânsito é trânsito, e vem tudo ali dentro (tráfego de CDNs do seu upstream, de PNIs dos AS upstreams, peerings dos upstreams, além do trânsito do trânsito, etc.).<br /> # '''Você escolhe o seu trânsito por preço apenas?''' Jura que não olha/valida os mapas de emparelhamentos e as relações dos demais ASs conectados nos upstreams, assim como os ASs do ASs?<br /> # '''O roteamento pelo BGP é &lt;u&gt;assimétrico&lt;/u&gt; por natureza e em grande parte.''' Você pode até tentar conceber alguma simetria do tráfego por meios de políticas, mas não há quaisquer garantias de êxito quanto a isso.<br /> # '''O atributo LOCAL_PREF só funciona dentro do seu AS.''' Por favor, não configure-o para anúncios através de sessões EBGP. É inútil, não funciona, não serve para coisa alguma, e deixa claro o quanto você não conhece do básico do BGP.<br /> # '''Não configure o MED para anúncios entre sessões IBGP se a intenção for manipular o tráfego de entrada.''' Isto só funciona entre sessões EBGP e entre dois Sistemas Autônomos ''dual'' ou ''multi-homed''. Saiba para que serve o MED e como isto funciona antes de querer usá-lo.<br /> # '''O Weight (Cisco) não é um atributo.''' Não espere mesmo influenciar o ponto de saída para todo o seu AS usando o Weight numa policy para seus peers IBGP!<br /> # '''&quot;Toda vez que subo um trânsito X, o meu PTT sofre paralisação&quot;.''' Olhe o seu &quot;umbigo&quot; antes de subir um trânsito ou um peering. Não é uma questão apenas de configurar uma simples sessão!<br /> # '''Compreenda e saiba identificar os tipos de situações que provocam indesejáveis e malditos Route Leaks, e como evitá-los:''' informe-se sobre o RFC 7908 (''Problem Definition and Classification of BGP Route Leaks'').<br /> ## '''Não repasse quaisquer rotas recebidas de uma sessão de trânsito para outra sessão de trânsito ou de peering.''' Pelo amor de Deus. N ã o f a ç a i s s o.<br /> ## '''Não repasse quaisquer rotas recebidas de uma sessão de peering para outra sessão de peering ou de trânsito.''' Pelo amor de Deus. N ã o f a ç a i s s o.<br /> ## '''Não gere como se fossem do seu ASN quaisquer prefixos que não sejam seus!''' Isto tipifica um sequestro de prefixo e não um route leak, mas os danos podem ser severos. Pelo amor de Deus. N ã o f a ç a i s s o.<br /> ## '''Não repasse para upstreams quaisquer prefixos que contenham um lista de AS_PATH irregular. Ou, melhor, rejeite o recebimento destes anúncios vindos de seu cone de clientes.'''<br /> ### Route Leaks provocados por isto são facilmente evitáveis nas políticas de ''import'' de rotas recebidas de clientes, além das garantias das suas policies de ''export'' com os upstreams. Não seja tolo!<br /> ### <br /> # '''Repasse para o trânsito apenas rotas do seu AS e rotas de seus clientes.''' E descarte o repasse de todo o resto.<br /> # '''Ao receber do trânsito, certifique-se de descartar ''martians'', ''bogons'', seus próprios blocos, e tudo aquilo tratado como &quot;mazelas&quot; da Internet.''' Não me diga que você não faz isso?<br /> # '''Você não tem uma política de roteamento.''' Você tem um punhado de configurações com nomes de &quot;policies&quot; vinculadas nas sessões para o ''in'' e o ''out''. Confesse!<br /> # '''Você por acaso não cadastra os seus objetos no IRR, né?''' Você espera que realmente o seu upstream faça isso por você (a título de proxy). Você adora varrer poeira para debaixo do tapete dos outros, né? Seu malvadão!<br /> # '''Você é fã do &quot;IP Confinado&quot; e/ou vende tráfego de CDN (ainda) descarada e impunemente:''' saiba que isto é uma prática ilegal. Você não pode: a) vender tráfego de CDN. b) promover comercialmente a prática disto. c) expor as logomarcas das CDNs no seu produto &quot;IP confinado&quot; em seu material comercial/publicitário. d) expor fotos dos servidores de CDN de seu datacenter na Internet e/ou redes sociais. Quem disse isso, o Leonardo Furtado? Não!<br /> ## Leia os contratos dos acordos e certifique-se do que pode ou não ser feito. A propósito, não existe um produto &quot;IP Confinado&quot; como vemos em muitos casos por aí que não seja uma gambiarra associada a uma clara violação de contratos.<br /> ## Não reclame quando você perder as suas CDNs ou quando for processado! <br /> ## Em suma: você pode vender produtos diferenciados tais como &quot;Trânsito Parcial&quot; e similares, repassando os anúncios dos seus clientes para as CDNs, mas não pode e não deve anunciar um produto tipo &quot;vendo tráfego das CDNs X, Y e Z&quot;'.<br /> ## O tráfego de CDN é um benefício para o ISP e seus assinantes e que reduz a latência nos acessos aos conteúdos e que também contribui para economizar bem no trânsito - principalmente o internacional. CDN é benefício e não produto de prateleira.<br /> <br /> === O que eu realmente preciso saber para ser considerado um expert em BGP? ===<br /> Pedir a minha opinião quanto a isso é desejar receber uma resposta inusitada, mas bem humorada! Sendo honesto e humano com o leitor aqui, eu me contentaria muito se você ao menos puder sinalizar &quot;fluência&quot; nos seguintes temas, todos básicos:<br /> <br /> ==== Para ser um expert, domine o essencial e o efetivo primeiro! ====<br /> # '''Conhecimentos sólidos de redes L2 e L3:''' o BGP, apesar de ser um protocolo de roteamento, comporta-se ou opera como se fosse uma aplicação. Muita coisa é requerida (L2/L3) para o seu funcionamento.<br /> # '''Compreensão dos conceitos fundamentais''' '''do BGP:''' PDU/mensagens, FSM, conceitos de sessões, atributos, roteamento recursivo, processo de seleção dos melhores caminhos.<br /> # '''Conhecimentos de boas práticas para a configuração do BGP:''' autenticação MD5, GTSM, limitação de prefixos recebidos, e afins.<br /> # '''Conhecimentos básicos de filtros de rotas:''' saber o que filtrar no recebimento e o que filtrar no envio, no tocante a anúncios/prefixos.<br /> # '''Conhecimentos básicos de como influenciar a seleção de caminhos ''in'' e ''out'':''' quais atributos, métodos e procedimentos utilizar para manipular o download e o upload, e em quais circunstâncias.<br /> # '''Conhecimentos sobre como manter uma política de roteamento básica:''' que seja apenas funcional, simples até, mas bem feita.<br /> # '''Faça o seu dever de casa:''' nas questões associadas ao cadastros/registros no ''IRR'' e ''PeeringDB'', além da segurança, filtros e policies.<br /> # '''Compreensão sobre o essencial a respeito de interconexões e como estas devem funcionar:''' peering, trânsito, CDNs, e outros. O que são? Como funcionam? Pra que servem? O que comem? Como vivem?<br /> &lt;u&gt;O Comitê de Programa do BPF está engajado em disseminar conhecimentos acerca destes oito pontos acima. Fique atento a futuras publicações do BPF, e convocamos a sua contribuição também!&lt;/u&gt;<br /> <br /> ==== Não seja um &quot;assassino de BGP&quot;! ====<br /> Uma coisa é compreender o BGP em sua forma mais acadêmica, e outra é saber conduzir ou &quot;pilotar&quot; o BGP corretamente em um Sistema Autônomo &quot;pra valer&quot;! Dentre os diversos absurdos que vemos por aí, posso citar alguns casos ou situações de coisas que realmente deixam a Internet estarrecida:<br /> # '''Políticas de roteamento cujos os filtros são construídos com camada de validação minimalista:''' sem os devidos cuidados de validação da origem do prefixo por IRR e RPKI; o que dá margem para route leaks e hijacks.<br /> # '''Provedores que em alguns casos repassaram rotas aprendidas a partir de uma sessão de trânsito para outras sessões de trânsito e/ou de peering:''' algo que provoca muitos distúrbios em muitos ASNs e seus clientes.<br /> # '''Provedores que em alguns casos repassaram rotas aprendidas a partir de uma sessão de peering para outras sessões de peering e/ou de trânsito:''' outro tipo de route leak, com péssimas consequências para todos!<br /> # '''Provedores que não validam a lista de ASNs indicada pelo atributo AS_PATH das rotas recebidas de sessões com o seu cone de clientes:'''<br /> ## Route leaks desta natureza são facilmente evitáveis com configurações simples nas políticas de importação de rotas vinculadas às sessões de clientes.<br /> ## Infelizmente ''BGPSEC'' (RFC 8205) e ''Route-Leak Protection'' (RLP) (draft-ietf-idr-route-leak-detection-mitigation-11) ainda não são uma realidade.<br /> # '''Provedores que em alguns casos anunciaram prefixos indicando como origem destes o seu próprio ASN:''' sim, um sequestro de prefixos na cara-de-pau!<br /> ## Embora isto seja um &quot;hijack&quot; e não um route leak, as consequências são severas!<br /> # '''Provedores que fornecem o mínimo de visibilidade para os demais ASNs e que não contribuem - nem um pouco - com transparência para a segurança da Internet:''' <br /> ## Sem quaisquer informações sobre a empresa, ferramentas e política de roteamento no PeeringDB, ou sem qualquer cadastro/registro no PeeringDB.<br /> ## Sem registros quaisquer de route/route6, as-set e aut-num nas bases de IRR.<br /> ### Ou com registros inconsistentes destes objetos, tais como a ausência de objetos route/route6 de prefixos mais específicos, as-sets, e regras RPSL de import/mp-import e export/mp-export em seus objetos aut-num, ou dados incorretos, etc.<br /> ## Que não disponibilizam quaisquer informações sobre as suas políticas de roteamento, seja na descrição do objeto aut-num, ou no PeeringDB, ou no website da empresa. Ou em qualquer lugar público e visível.<br /> ## Embora isto não seja um &quot;crime&quot;, não está tão longe assim de ser: que diabos passa na cabeça de provedores que não disponibilizam ferramentas básicas para auxiliar de forma bem autônoma e independente outros Sistemas Autônomos no diagnóstico de problemas com o roteamento de/para aquele ASN. Por exemplo, &lt;u&gt;não disponibilizam um LOOKING GLASS sequer!&lt;/u&gt; Isso é muito frustrante!<br /> # '''Provedores que não removem os ASN privativos quando repassando os anúncios seus e/ou de seu cone de clientes para sessões de peering e trânsito.'''<br /> # '''Provedores que injetam route leaks associados aos seus próprios prefixos ou prefixos de seus clientes.'''<br /> # '''Provedores que repassam anúncios bogons, martians e unallocated para peering e trânsito.'''<br /> # '''Provedores que não se preocupam nem um pouco em combater o principal vetor de ataques de DDoS contra todos os ASN na Internet:''' não buscam implementar mecanismos de ''anti-spoofing'' (ex: uRPF) de endereços IP de origem em suas próprias redes, incluindo o seu cone de clientes.<br /> # Dentre outros absurdos.<br /> Esses &quot;profissionais&quot; são que nem motoristas que dirigem alcoolizados: acham que suas ações altamente imprudentes não afetarão a vida de terceiros! Esses &quot;bêbados da Internet&quot; tendem a provocar distúrbios severos, impactando outros Sistemas Autônomos e milhares de usuários de Internet. Entenda: route leaks, prefix hijacks, anúncios bogons/martians/unallocated, dentre outros tipos de incidentes, causam distúrbios para grande parte da Internet, e não ficam restritos apenas no ASN do irresponsável. Reflita!<br /> <br /> '''Para concluir:''' considerando as necessidades, objetivos, circunstâncias, realidades e situações dos dias atuais, eu, particularmente, considero &lt;u&gt;inconcebível&lt;/u&gt; um profissional de redes lidar com o protocolo BGP em um ambiente de ISP sem que este indivíduo tenha no mínimo, além do próprio BGP, os conhecimentos de boas práticas de segurança necessários conforme descritos pelos seguintes:<br /> * '''&lt;nowiki&gt;RFC 4272&lt;/nowiki&gt;''' (''BGP Security Vulnerabilities Analysis'')<br /> * '''&lt;nowiki&gt;RFC 7132&lt;/nowiki&gt;''' (''Threat Model for BGP Path Security'')<br /> * '''&lt;nowiki&gt;RFC 7454&lt;/nowiki&gt; / BCP 194''' (''BGP Operations and Security'')<br /> * '''BCP 38''' (''Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing'')<br /> * '''&lt;nowiki&gt;RFC 7353&lt;/nowiki&gt;''' (''Security Requirements for BGP Path Validation'')<br /> * '''BCP 185''' (''Origin Validation Operation Based on the Resource Public Key Infrastructure'' (''RPKI''))<br /> * '''&lt;nowiki&gt;RFC 7908&lt;/nowiki&gt;''' (''Problem Definition and Classification of BGP Route Leaks'')<br /> * '''&lt;nowiki&gt;RFC 7948&lt;/nowiki&gt;''' (''Internet Exchange BGP Route Server Operations'')<br /> * '''RFC 7999''' (''BLACKHOLE Community'')<br /> * E os arranjos de propostas e boas práticas citadas pelo ''Mutually Agreed Norms for Routing Security'' ('''MANRS''') <br /> Isto é o mínimo que se espera de um profissional que vá lidar como BGP nos dias atuais em ambientes ''Service Provider''. Não duvide disto! Ou pague o preço.<br /> <br /> '''Em nome do BPF, suplico:''' NÃO SEJA UM &quot;'''BGP KILLER'''&quot;!<br /> <br /> [[Arquivo:Bpf-bgpfund-bgpkiller.png|centro|miniaturadaimagem|690x690px|Não seja um &quot;BGP KILLER&quot;: faça a sua parte para uma Internet segura, rápida, e bem disponível!]]<br /> <br /> ==== Avance os seus conhecimentos para o último degrau! ====<br /> Alguns projetos com o BGP podem ser extremamente complexos no ponto de vista de objetivos e concepções! Felizmente as arquiteturas de roteadores sofisticados oferecem uma gama enorme de recursos e facilidades, muitas delas de natureza proprietária, mas também muitas coisas orientadas aos padrões abertos. Não raramente engenheiros de rede se vêem forçados a intervir com alguma facilidade/recurso para fazer a coisa funcionar do jeito que deve. Fornecerei &lt;u&gt;alguns&lt;/u&gt; exemplos de recursos relacionados aos serviços de roteamento &lt;u&gt;unicast&lt;/u&gt; apenas!<br /> <br /> Estude estas tecnologias, estes recursos, procure se interessar melhor pelas arquiteturas de roteadores, faça cursos, leia os manuais, etc.! Não fique limitado apenas ao que está mencionado abaixo. Procure em primeiro momento compreender o que você precisa fazer para depois estudar qual recurso promove aderência e para qual objetivo ou necessidade.<br /> {| class=&quot;wikitable&quot;<br /> |+<br /> |BGP Dual-homed e Dual Multihomed em cenário Primary/Backup e em cenário Load sharing<br /> |BGP FlowSpec<br /> |BGP Dual AS e AS Number Translation<br /> |-<br /> |BGP 4-byte AS (AS4_AGGREGATOR e AS4_PATH) e coexistência com 2-byte AS<br /> |IBGP Full Mesh e Peer Groups / Neighbor Groups / Session Groups / Address Family Groups e similares<br /> |IBGP com Route Reflectors e Confederation<br /> |-<br /> |EBGP Multihop<br /> |EBGP Multipath e Load Sharing<br /> |EBGP TTL Security Check<br /> |-<br /> |BGP DMZ Aggregate Bandwidth ou recurso similar suportado pelo seu fabricante<br /> |BGP MD5 Authentication<br /> |Redistribuição de Rotas de/para o BGP<br /> |-<br /> |Agregação de Rotas BGP por Static e por Atomic Aggregate<br /> |BGP Conditional Route Injection<br /> |Aggregate com ferramentas tais como suppress-map, AS-set e attribute-map, ou equivalentes suportados em seu equipamento<br /> |-<br /> |BGP Soft Reconfiguration Inbound, Route Refresh, Enhanced Route Refresh e ORF<br /> |Manipulação de tráfego de saída com Local Preference (e/ou Weight, proprietário)<br /> |Manipulação de tráfego de entrada com MED, deterministic-MED, always-compare-MED<br /> |-<br /> |Manipulação de tráfego de entrada com AS-path Prepending<br /> |Alteração do BGP bestpath compare-routerid e as-path<br /> |Implementação de Communities no BGP, Route Tagging e ferramentas periféricas<br /> |-<br /> |Filtros de rotas in e out por prefixos e atributos<br /> |BGP Cost Community<br /> |BGP NEXT_HOP Tracking ou recurso similar suportado no seu equipamento<br /> |-<br /> |BGP Route Dampening<br /> |BGP Prefix Independent Convergence (PIC) para RIB e FIB<br /> |BGP-RIB Feedback Mechanism<br /> |-<br /> |BGP Routing Domain Confederation<br /> |QoS Policy Propagation via BGP (QPPB) ou similar<br /> |Remotely Triggered Blackhole Filtering (RTBH)<br /> |-<br /> |BGP Nonstop Routing (NSR) e Nonstop Forwarding (NSF)<br /> |BGP Additional Paths, iBGP Multipath Load Sharing, BGP Selective Multipath<br /> |Accumulated Interior Gateway Protocol Attribute (AIGP)<br /> |-<br /> |IPv4 BGP Policy Accounting <br /> |BFD Multihop Support para BGP<br /> |BGP Accept Own<br /> |-<br /> |BGP Multi-Instance e Multi-AS<br /> |BGP Prefix Origin Validation baseado no RPKI<br /> |Etc.! a lista é quase que interminável!<br /> |}<br /> Impressionado com o tamanho do artigo? Eu disse que seria aquilo que eu considero como básico/fundamental - PORQUE DE FATO É! - e não afirmei em momento algum que o texto seria minimalista ou fácil! Eu alertei!!!<br /> <br /> Espero que tenha curtido este artigo. E nos vemos no próximo. Até!!<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Roteamento]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=CDN_Peering_e_PNI_-_Brasil&diff=2506 2020-06-02T22:52:10Z

<p>Leonardo.furtado: </p> <hr /> <div><br /> ===Introdução===<br /> Esta página contém informações úteis para operadores de redes e ISPs com relação à solicitação de servidores de CDNs, estabelecimento de uma sessão Bilateral em algum dos IXs ou para a solicitação de PNIs nos Datacenters aonde ASNs, geralmente grandes geradores de conteúdos, estão presentes.<br /> <br /> É importante destacar que as informações aqui apresentadas (ex: tráfego necessário para solicitar servidores de CDN) mudam de forma bastante dinâmica e de acordo com as regras próprias estabelecidas pelos próprios geradores de conteúdo, portanto este guia serve como referência para o momento que ele foi escrito ou atualizado pela última vez.<br /> <br /> Um recomendação importante a ser feita é que antes de fazer a solicitação de servidores de CDN ou de um PNI por exemplo, é importante realizar uma avaliação detalhada do tráfego que o seu ASN troca com os ASNs desses geradores de conteúdo. Ferramentas como NetFlow e [https://www.peeringdb.com/ PeeringDB] auxiliam bastante. Cerifique-se que você atende à &lt;u&gt;TODOS os requisitos&lt;/u&gt; antes de fazer a solicitação, principalmente se possui a quantidade de mínima de tráfego para ser elegível. Esses servidores somente são enviados aos ISPs no caso das empresas de CDN verificarem que eles trazem benefícios para &lt;u&gt;ambos CDN e ISP&lt;/u&gt;, caso contrário dificilmente serão enviados. Hospedar e manter um servidor de CDN é algo que demanda recursos do provedor como espaço em rack, portas de switch e principalmente um consumo razoável de energia elétrica por isso uma avaliação criteriosa é bastante importante antes de realizar a solicitação.<br /> <br /> Outro detalhe imprescindível na hora de solicitar um servidor de CDN, Peering por Sessão Bilateral ou PNI &lt;u&gt;é o IPv6&lt;/u&gt;. Devido à crescente importância deste protocolo algumas CDNs hoje em dia tem colocado restrições caso você não seja capaz de estabelecer uma sessão IPv6 com eles.Além disso caso você possua IPv6 em seu backbone porém ainda não está distribuindo para os usuários residencias e possui apenas CGNAT44 &lt;u&gt;a maioria das grandes CDNs já possuem suporte completo à IPv6&lt;/u&gt; portanto uma parte significativa do seu tráfego poderia estar fluindo preferencialmente em IPv6 ao invés de estar passando por equipamentos que fazem o GGNAT a um custo computacional maior além de ter a identificação do usuário facilitada em caso de uma solicitação baseada no Marco Civil da Internet.<br /> <br /> A maioria das CDNs exigem que as informações sobre o ASN solicitante estejam atualizadas no PeeringDB portanto antes de solicitar é uma boa prática conferi-las.<br /> <br /> Você pode acessar a URL a seguir para entender melhor o funcionamento de sessões Peering: [[Modelos_Interconexão]]<br /> <br /> ''Última atualização - '''11/05/2020'''''<br /> <br /> === Informações importantes sobre termos de contrato, NDA, propriedade intelectual, uso impróprio de logomarcas, e outras práticas que devem ser abolidas pelo ISP ===<br /> Atenção senhores provedores de acesso à Internet (ISP). Esta seção do presente documento visa esclarecer algumas informações importantes sobre a legitimidade de certas práticas que tem sido detectadas entre os ISPs, generalizando aqui, em particular no que diz respeito ao uso impróprio de recursos providos pelas redes de fornecimento de conteúdo (CDN), e também de algumas violações graves dos termos estabelecidos em regime de contrato entre a detentora da tecnologia (empresa de conteúdo que fornece a CDN) e o ISP. Mas, antes, permita-nos explicar-lhes o que são CDNs, suas características e benefícios gerais:<br /> <br /> Como é de conhecimento comum entre os ISPs, há basicamente dois tipos de arquiteturas ou abordagens no que diz respeito às CDNs: ''Bring-Home'' e ''Enter-Deep Cache''. Foquemos no segundo caso (''Enter-Deep''), que é o tipo que mais se assemelha às CDNs que os ISPs qualificados podem solicitar e receber. A arquitetura ''Enter-Deep Cache'' possui como estratégia estar profundamente fincada dentro do ambiente de redes do ISP, geralmente sendo adotados na forma de clusters. Os benefícios proporcionados pelas CDNs são indiscutíveis:<br /> * Fornecimento de conteúdo de baixa latência, o que, por sua vez, promove uma experiência bem fluída de navegação e interação dos usuários/clientes do ISP.<br /> * Em combinação com sessões de peering privado (PNI) e peering público (IX), a arquitetura Enter-Deep promove economias bastante significativas nos custos operacionais do ISP, e em diversas áreas, especialmente o dimensionamento de recursos e manutenção de custos recorrentes com a contratação de links de trânsito IP.<br /> * Combinada com outras boas práticas de engenharia de redes, engenharia de tráfego, e segurança geral do ASN, as redes de fornecimento de conteúdo contribuem muito substancialmente para aprimoramentos de diversos KPIs do negócio.<br /> * O assinante (cliente) é beneficiado por contar com uma Internet &quot;mais fluida&quot;, e o ISP é beneficiado por poder fornecer uma experiência mais atraente de interação de seus clientes com a Internet, além da redução de custos aliada ao aprimoramento de indicadores-chave importantes do negócio.<br /> No entanto, o ISP precisa entender uma realidade: apesar dos benefícios mútuos para cliente e ISP, e até mesmo para a detentora da tecnologia (empresa de conteúdo), que consegue engajar e monetizar melhor seus (também) clientes, ter uma CDN é na verdade um '''&lt;u&gt;privilégio&lt;/u&gt;'''. O que muitos ISPs fazem é tratar a CDN como um &quot;direito&quot; deles, e isto é completamente equivocado. Mesmo que o ISP reúna os requisitos para a solicitação e obtenção de CDN - aliás, mal sabem, a solicitação não é para &quot;obter uma CDN&quot;, e sim para participar do programa de afiliados da empresa de conteúdo - a resposta/decisão será sempre por conta da detentora da tecnologia, que avaliará diversas métricas para determinar se é vantajoso ou não para ela disponibilizar a sua tecnologia para aquele ISP. Ou seja, há uma relação mútua entre os beneficiados diretos &quot;ISP e CDN&quot; (generalizando o termo aqui); assim como é vantajoso (e sempre será!) para o ISP, tem que ser vantajoso, também, para a empresa dona daquela CDN. Repetindo: CDN não é direito, é privilégio.<br /> <br /> '''Práticas ilegais exercitadas por alguns ISPs:'''<br /> * Amplificar e manipular artificialmente o tráfego via práticas escusas, recheadas de alguns desvios éticos, com o intuito de atingir o requerimento mínimo de consumo exigido pela detentora da CDN.<br /> * Promover abertamente na sua cesta de produtos e soluções que aquele ISP &quot;vende tráfego de CDNs&quot;. O ISP não pode vender tráfego de CDN direta ou abertamente, mas poderá costurar um produto que contemple isto de forma correta e legítima. O ISP poderá fornecer tráfego de CDNs dentro de um produto de &quot;Trânsito IP Parcial&quot; ou nome qualquer, desde que não divulgue que &quot;vende CDN&quot; e muito menos expondo logomarcas, fotos dos servidores, etc.<br /> * Não somente vender abertamente o tráfego de CDNs, as vezes usando nomes um tanto criativos, como &quot;IP Confinado&quot; e similares, mas ainda expor as logomarcas das empresas (ex: Netflix, Facebook, Google, Akamai, etc.). Isto é completamente ilegal.<br /> * Publicam fotos de seus data centers com o propósito de expor aos seus clientes e prospecções que possuem &quot;servidores de CDN da empresa X, Y e Z&quot;. Isto é igualmente não permitido.<br /> Com a exceção do primeiro caso (manipulação artificial do tráfego), os demais casos não tem relação com aspectos mais técnicos envolvendo redes, e sim com outras questões que passam completamente despercebidas por estes indivíduos e empresas. Os contratos que são estabelecidos entre empresas fornecedoras de conteúdo e os ISPs vão um tanto além das questões puramente técnicas, pois há uma preocupação enorme envolvendo uma cadeia inteira de partes interessadas no capital que flui com estes conteúdos, do produtor, passando pelo distribuidor, depois pelo ISP, e, por último, para os clientes. Ou seja, questões relacionadas à proteção de marcas (branding), uso inadequado de logomarcas e afins, propriedade intelectual, pagamento de royalties, e os acordos milionários entre as produtoras de conteúdos e as distribuidoras de conteúdo. A questão toda vai bem além do &quot;tequiniquês&quot;.<br /> <br /> Quando um ISP viola estes termos, ele estará desafiando uma cadeia inteira de partes interessadas que podem tomar ações contra o ISP. Na melhor das hipóteses, o ISP é alertado. Frequentemente, o ISP perde e tem as CDNs recolhidas de sua rede, além de ser banido permanentemente do programa. Há ainda o risco de outras ações serem executadas contra o ISP por uso indevido de imagem, violação de direitos autorais e/ou de propriedade intelectual. <br /> <br /> Esperamos que estas informações sejam úteis para todos vocês, e colocamo-nos à disposição para esclarecermos suas dúvidas. Utilizem as nossas listas de discussão!<br /> <br /> ===CDNs===<br /> As CDNs, baseadas em critérios próprios, definem condições em que um servidor pode ser enviado para ser instalado dentro do backbone de um ISP para otimizar a entrega de conteúdo para o usuário final. Isso é vantajoso para a CDN que melhora a qualidade na entrega do conteúdo, para o usuário final e também para ISP pois além de economizar no uso dos links de upstream são capazes de prover uma melhor experiência para seus usuários.<br /> <br /> O tráfego atual de referência para solicitação de servidores de algumas CDN está na faixa dos 2 a 5 Gbps, porém existem condições que isso pode ser flexibilizado à depender da região e da disponibilidade de outros Trânsitos IP presentes serem capazes de distribuir aquele conteúdo. Via de regra em uma grande cidade ou região populosa com acesso à IX que já possui servidores de cache ou uma quantidade razoável de Trânsitos IP é bastante provável que o valor de referência não seja flexibilizado pelas CDNs.<br /> ====Akamai (AANP)====<br /> *Banda mínima: 10 Gbps<br /> *Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp<br /> *Documentação: https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> ====Apple====<br /> *Banda mínima: 25 Gbps<br /> *Informações: https://cache.edge.apple/<br /> *Solicitação: https://cache.edge.apple/inquire<br /> *PeeringDB: https://peeringdb.com/asn/714<br /> *Nota: Como exigem uma quantidade de banda alta para o cache, evite entrar em contato caso seu tráfego não esteja ao menos com previsão de chegar ao mínimo nos próximos 12 meses. Como a Apple ainda não está no IX.Br SP, dê preferencia por entrar em contato sugerindo que eles mantenham pontos de presença no Brasil, será muito mais eficiente. <br /> ====Facebook (FNA)====<br /> *Banda mínima: 5 Gbps<br /> *Email: fna@fb.com<br /> *PeeringDB: https://www.peeringdb.com/net/979<br /> *Nota: O Facebook analisa apenas o tráfego trocado com o ASN solicitante e não de seus respectivos clientes de trânsito (demais ASNs). Também não considera possibilidade da soma do tráfego trocado com os ASNs desejando compartilhar um FNA em um IX Privado ou interconexão bilateral, independente de um contrato existente entre as partes.<br /> *Prefixos CGNAT: Não suportados oficialmente. Considere uso de IPv6.<br /> ====Google (GGC)====<br /> *Banda mínima: 3 Gbps<br /> *Informações: https://peering.google.com/#/options/google-global-cache<br /> *Solicitação: http://isp.google.com/iwantpeering<br /> *Instalação: https://www.gstatic.com/isp/docs/ggc-installation.pdf<br /> *Troubleshooting: https://cloud.google.com/cdn/docs/support<br /> *Portal: https://isp.google.com/dashboard/<br /> * PeeringDB: https://www.peeringdb.com/net/433&lt;nowiki/&gt;https://www.peeringdb.com/net/4319<br /> * Prefixos CGNAT: Aceitos com community. Acess&lt;nowiki/&gt;e a documentação no portal.<br /> <br /> ====Edgecast Verizon Digital Media (EC)====<br /> *Banda mínima: 10 Gbps<br /> *Email: peering@verizondigitalmedia.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/ <br /> *Solicitação: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt; <br /> <br /> *<br /> ====Netflix (OCA)====<br /> *Banda mínima: 5 Gbps (SP, RJ, RS e CE) e 2 Gbps (demais Estados)<br /> *Solicitação: https://openconnect.netflix.com/en/request/<br /> *Instalação: https://openconnect.netflix.com/deploymentguide.pdf<br /> *Troubleshooting: https://openconnect.netflix.com/en/faq/<br /> *Portal: https://my.oc.netflix.com/<br /> *PeeringDB: https://www.peeringdb.com/net/457<br /> *Prefixos CGNAT: Não suportado oficialmente. Considere uso de IPv6.<br /> <br /> ==== Azion (ANA) ====<br /> * Banda mínima: 4 Gbps (Seletiva)<br /> * Email: cdn@azion.com / peering@azion.com<br /> * Informações: https://www.azion.com.br/developers/peering/<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> <br /> ==== SourceForge.Net ====<br /> * Banda mínima: 150Mbps<br /> * Hardware por conta do provedor, com 8TB de disco no mínimo.<br /> * Email: staff@sourceforge.net<br /> * Informações: https://sourceforge.net/p/forge/documentation/Join%20as%20a%20Mirror/<br /> <br /> ==== Microsoft ====<br /> * Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo)<br /> * Email: ispnode@microsoft.com<br /> * Informações: https://peering.azurewebsites.net/Peering/Caching<br /> * PeeringDB: http://as8075.peeringdb.com/<br /> <br /> ===Peerings - Sessões Bilaterais===<br /> É possível também solicitar diretamente à alguns ASNs o estabelecimento de uma sessão bilateral através de algum dos IX onde ambos os ASNs estejam presentes (para saber mais consulte [[Modelos_Interconexão]]). Em alguns casos existe um tráfego mínimo para estabelecimento desta sessão, portanto sempre que possível verifique através de sistemas de monitoramento internos a quantidade de tráfego trocada entre ambos ASNs antes de fazer contato para solicitação de peering.<br /> <br /> Na maioria dos casos os prefixos anunciados para os Route Servers são os mesmos anunciados na sessão bilateral, porém existem também casos onde isso pode ser diferente o que justifica o estabelecimento da sessão ou ainda para permitir ao ASN um melhor controle sobre os anúncios para cada um desses ASNs.Por padrão a sessão é estabelecida na mesma VLAN do ATM v4 e v6, a não ser que exista alguma motivação para que seja estabelecida através de uma VLAN Bilateral.<br /> <br /> Também existem casos de conteúdos como a Microsoft que anunciou recentemente a saída dos Route Servers, portanto em casos como esses é necessário estabelecer uma sessão bilateral para que exista troca de tráfego direta entre ambos os ASNs.<br /> <br /> Antes de solicitar o estabelecimento de uma sessão bilateral através do IX recomenda-se deixar a configuração pronta no seu roteador para agilizar o processo.<br /> <br /> A listagem não exaustiva abaixo apresenta alguns ASNs que são conhecidos por estabelecerem sessões bilaterais no IX-SP:<br /> ====Akamai====<br /> *Email: peering@akamai.com e peering-tix@akamai.com<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> ====Edgecast Verizon Digital Media====<br /> *Email: peering@verizondigitalmedia.com<br /> *Solicitação: peering@verizondigitalmedia.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt;<br /> ====Microsoft====<br /> *Email: peering@microsoft.com<br /> *Solicitação: http://www.microsoft.com/peering<br /> *PeeringDB: [https://www.peeringdb.com/net/694 http://as8075.peeringdb.com/]<br /> <br /> ==== Hurricane Electric ====<br /> * Email: peering@he.net<br /> * Email NOC: noc@he.net (após sessão estar ativada)<br /> * Informações: http://he.net/peering.html<br /> * PeeringDB: https://www.peeringdb.com/net/291<br /> A Hurricane Electric oferece também Trânsito IPv6 gratuito através de sessão bilateral. Para solicitar envie um email para ipv6@he.net<br /> <br /> ====LinkedIn====<br /> *Email: peering@linkedin.com<br /> *PeeringDB: https://www.peeringdb.com/net/4231<br /> ====CloudFlare====<br /> *Email: peering@cloudflare.com<br /> *PeeringDB: https://www.peeringdb.com/net/4224<br /> ====CDNetworks====<br /> *Email: peering@cdnetworks.com<br /> *PeeringDB: https://www.peeringdb.com/net/1372<br /> <br /> ==== Azion ====<br /> * Banda mínima: 150 Mbps (Seletiva)<br /> * Email: peering@azion.com / noc@azion.com<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> <br /> ==== Twitch TV ====<br /> * Email: noc@twitch.tv / peering@twitch.tv<br /> * Contato: https://noc.twitch.tv/<br /> * PeeringDB: https://www.peeringdb.com/asn/46489<br /> * Política: Seletiva<br /> <br /> ==== Oath/Yahoo ====<br /> * Email: peering-requests@oath.com<br /> * Informações: https://peering.oath.com/policy<br /> * PeeringDB: https://www.peeringdb.com/asn/10310/<br /> * Política: Seletiva<br /> <br /> ==== Netflix ====<br /> * Banda Minima: 3Gbps<br /> * Email: peering@netflix.com<br /> * PeeringDB: https://www.peeringdb.com/net/457<br /> * Nota: De acordo com informação publicada no PeeringDB o Netflix anuncia os mesmos prefixos para os Route Servers do ATM e para as Sessões Bilaterais. Por isso não costumam fechar Sessões Bilaterais via IX a não ser em casos complexos de engenharia de tráfego e orientam os participantes a utilizarem as communities disponibilizadas pelo IX.br para manobrarem o tráfego.<br /> <br /> ==== Google ====<br /> * Email: noc@google.com<br /> * Solicitação: &lt;nowiki&gt;https://isp.google.com/iwantpeering&lt;/nowiki&gt;<br /> * PeeringDB: https://www.peeringdb.com/net/433<br /> <br /> ==== Facebook ====<br /> * Email: peering@fb.com / noc@fb.com<br /> * Informação: https://www.facebook.com/peering/<br /> * PeeringDB: https://www.peeringdb.com/net/979<br /> * Política: Seletiva<br /> * Nota: O estabelecimento das sessões bilaterais é sempre através da Vlan do ATM.<br /> <br /> ==== Amazon ====<br /> * Email: peering@amazon.com<br /> * PeeringDB: https://www.peeringdb.com/net/1418<br /> * Política: Seletiva<br /> <br /> ==== SoftLayer ====<br /> * Email: peering@softlayer.com<br /> * PeeringDB: https://www.peeringdb.com/asn/36351<br /> * Política: Seletiva<br /> <br /> ==== RiotGames ====<br /> * Email: peering@riotgames.com<br /> * PeeringDB: https://www.peeringdb.com/asn/6507<br /> * Política: Seletiva<br /> <br /> ==== i3D.net / Ubisoft ====<br /> * Email: peering@i3d.net<br /> * PeeringDB: https://www.peeringdb.com/asn/49544<br /> * Política: Seletiva<br /> <br /> ==== Twitter ====<br /> * Banda mínima: 100 Mbps<br /> * Email: peering@twitter.com<br /> * PeeringDB: https://www.peeringdb.com/asn/13414<br /> * Política: Seletiva<br /> <br /> ==== Globo ====<br /> * Email: peering@peering.globo<br /> * Informações: https://peering.globo<br /> * PeeringDB: https://www.peeringdb.com/net/5703<br /> <br /> ==== Tencent ====<br /> * Email: peering@tencent.com<br /> * Informações: [https://peering.tencent.com/peering/peering_form &lt;nowiki&gt;https://peering.tencent.com/peering/&lt;/nowiki&gt;peering_form]<br /> * PeeringDB: https://www.peeringdb.com/asn/132203<br /> <br /> ===PNIs - Private Network Interconnection===<br /> PNIs são interconexões privadas realizadas diretamente entre dois ASNs sem o intermédio de um terceiro (entenda PNI em: [[Modelos_Interconexão]]). Geralmente é um ''cross-connect'' ou ''golden-jumper'' entre os racks das duas empresas em um mesmo Datacenter onde ambas estejam presentes.No [https://www.peeringdb.com/ PeeringDB] é possível verificar os Datacenters que as CDNs estão presentes e onde existe possibilidade de solicitar um PNI olhando na seção &quot;Private Peering Facilities&quot;.<br /> <br /> Uma das vantagens de um PNI é a de por se tratar de uma conexão direta não esta suscetível à possíveis problemas causados por exemplo na matriz de um IX aonde ambos ASN já trocam tráfego. Além disso por se tratar de uma conexão dedicada a banda toda disponível na porta é dedicada àquele tráfego entre os dois ASNs aliviando assim outras portas de peering para outros tipos de tráfegos.<br /> <br /> Algumas CDNs embora grandes optam por não disponibilizar a modalidade de interconexão através de PNI restringindo assim à troca de tráfego através do IX ou através de um servidor de CDN que é instalado dentro do backbone do ISP.<br /> <br /> Normalmente envolve um custo que é o do ''cross-connect'' ou ''golden-jumper'' que pode ser pago por uma das partes ou dividido igualmente entre ambas. Para que o parceiro ou você possa solicitar este cross, será necessário o envio de um LoA (Letter of Authorization) indicando que a parte remota está autorizando a passado do cabeamento em sua rack, caso você não saiba como criar esse LoA, verifique a sessão download do portal do parceiro ou solicite a seu parceiro um modelo, você também pode se basear neste exemplo fornecido pelo Google https://isp.google.com/static/downloads/LOA.pdf.<br /> <br /> A listagem abaixo contém as informações em quais Datacenters é possível ter um PNI com algumas dessas CDNs:<br /> ====Facebook====<br /> *Banda mínima: 1 Gbps<br /> *Email: peering@fb.com<br /> *Datacenters: Equinix-SP2, Equinix-SP4 e Equinix-RJ1<br /> *PeeringDB: https://www.peeringdb.com/net/979<br /> *Informações: https://wiki.brasilpeeringforum.org/images/4/4e/Peer-pni-parameters-facebook.pdf<br /> ====Google====<br /> *Informações: https://peering.google.com/#/options/peering<br /> *Solicitação: http://isp.google.com/iwantpeering<br /> *Datacenters: Equinix-SP2 (através de transporte), Equinix-SP4, Level 3 - Cotia e Level 3 - Rio de Janeiro.<br /> *PeeringDB: https://www.peeringdb.com/net/433&lt;nowiki/&gt;https://www.peeringdb.com/net/4319<br /> *Modelo LoA: [https://isp.google.com/static/downloads/LOA.pdf https://isp.google.com/static/do]&lt;nowiki/&gt;[https://isp.google.com/static/downloads/LOA.pdf wnloads/LOA.pdf] <br /> ====Edgecast Verizon Digital Media====<br /> *Banda mínima: 1 Gbps<br /> *Email: peering@verizondigitalmedia.com<br /> *Solicitação: peering@verizondigitalmedia.com / CarrierRelations@edgecast.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt;<br /> *Datacenters: Equinix-SP4, Equinix-RJ2<br /> ==== Netflix ====<br /> * Banda Mínima: 3 Gbps<br /> * Email: peering@netflix.com<br /> * Informações: https://openconnect.netflix.com/en/guidelines/<br /> * Datacenters: Equinix-SP2, Equinix-RJ1, NIC-JD, Commcorp Porto Alegre-PAE1, ETICE-Fortaleza<br /> * PeeringDB: https://www.peeringdb.com/net/457<br /> <br /> ==== Akamai ====<br /> * Banda Mínima: 5 Gbps<br /> * Email: netsupport-tix@akamai.com<br /> * Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> *Datacenters: Equinix-SP4, Teleporto-RJ <br /> <br /> ==== Azion ====<br /> * Banda mínima: 5 Gbps<br /> * Email: peering@azion.com / noc@azion.com<br /> * Informações: https://www.azion.com.br/developers/peering/<br /> * Datacenters: Ascenty Campinas, Commcorp-BSA2, Commcorp-FNS1, Commcorp-PAE1, Equinix-SP3, Level 3 - Cotia, GVT - Curitiba, Globenet - Fortaleza, NIC-JD, PIX Adylnet-PAE, PIX G8 - São Paulo, PIX Vogel - Porto Alegre, Tascom - Salvador<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> ==== Twitch TV ====<br /> * Banda mínima: 2.5 Gbps<br /> * Email: noc@twitch.tv / interconnection@twitch.tv<br /> * Contato: https://noc.twitch.tv/<br /> * Datacenters: Equinix-SP2, Level 3 - Cotia, Level 3 - Rio de Janeiro<br /> * PeeringDB: https://www.peeringdb.com/asn/46489<br /> ==== Globo ====<br /> * Email: peering@peering.globo<br /> * Informações: https://peering.globo<br /> * PeeringDB: https://www.peeringdb.com/net/5703<br /> * Locais: Rio de Janeiro: Jacarepaguá, São Paulo: Alameda Santos, Fortaleza: Datacenter Angola Cables<br /> [[Categoria:Interconexão]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=CDN_Peering_e_PNI_-_Brasil&diff=2505 2020-06-02T22:43:16Z

<p>Leonardo.furtado: </p> <hr /> <div><br /> ===Introdução===<br /> Esta página contém informações úteis para operadores de redes e ISPs com relação à solicitação de servidores de CDNs, estabelecimento de uma sessão Bilateral em algum dos IXs ou para a solicitação de PNIs nos Datacenters aonde ASNs, geralmente grandes geradores de conteúdos, estão presentes.<br /> <br /> É importante destacar que as informações aqui apresentadas (ex: tráfego necessário para solicitar servidores de CDN) mudam de forma bastante dinâmica e de acordo com as regras próprias estabelecidas pelos próprios geradores de conteúdo, portanto este guia serve como referência para o momento que ele foi escrito ou atualizado pela última vez.<br /> <br /> Um recomendação importante a ser feita é que antes de fazer a solicitação de servidores de CDN ou de um PNI por exemplo, é importante realizar uma avaliação detalhada do tráfego que o seu ASN troca com os ASNs desses geradores de conteúdo. Ferramentas como NetFlow e [https://www.peeringdb.com/ PeeringDB] auxiliam bastante. Cerifique-se que você atende à &lt;u&gt;TODOS os requisitos&lt;/u&gt; antes de fazer a solicitação, principalmente se possui a quantidade de mínima de tráfego para ser elegível. Esses servidores somente são enviados aos ISPs no caso das empresas de CDN verificarem que eles trazem benefícios para &lt;u&gt;ambos CDN e ISP&lt;/u&gt;, caso contrário dificilmente serão enviados. Hospedar e manter um servidor de CDN é algo que demanda recursos do provedor como espaço em rack, portas de switch e principalmente um consumo razoável de energia elétrica por isso uma avaliação criteriosa é bastante importante antes de realizar a solicitação.<br /> <br /> Outro detalhe imprescindível na hora de solicitar um servidor de CDN, Peering por Sessão Bilateral ou PNI &lt;u&gt;é o IPv6&lt;/u&gt;. Devido à crescente importância deste protocolo algumas CDNs hoje em dia tem colocado restrições caso você não seja capaz de estabelecer uma sessão IPv6 com eles.Além disso caso você possua IPv6 em seu backbone porém ainda não está distribuindo para os usuários residencias e possui apenas CGNAT44 &lt;u&gt;a maioria das grandes CDNs já possuem suporte completo à IPv6&lt;/u&gt; portanto uma parte significativa do seu tráfego poderia estar fluindo preferencialmente em IPv6 ao invés de estar passando por equipamentos que fazem o GGNAT a um custo computacional maior além de ter a identificação do usuário facilitada em caso de uma solicitação baseada no Marco Civil da Internet.<br /> <br /> A maioria das CDNs exigem que as informações sobre o ASN solicitante estejam atualizadas no PeeringDB portanto antes de solicitar é uma boa prática conferi-las.<br /> <br /> Você pode acessar a URL a seguir para entender melhor o funcionamento de sessões Peering: [[Modelos_Interconexão]]<br /> <br /> ''Última atualização - '''11/05/2020'''''<br /> <br /> === Informações importantes sobre termos de contrato, NDA, propriedade intelectual, uso impróprio de logomarcas, e outras práticas que devem ser abolidas pelo ISP ===<br /> Atenção senhores provedores de acesso à Internet (ISP). Esta seção do presente documento visa esclarecer algumas informações importantes sobre a legitimidade de certas práticas que tem sido detectadas entre os ISPs, generalizando aqui, em particular no que diz respeito ao uso impróprio de recursos providos pelas redes de fornecimento de conteúdo (CDN), e também de algumas violações graves dos termos estabelecidos em regime de contrato entre a detentora da tecnologia (empresa de conteúdo que fornece a CDN) e o ISP. Mas, antes, permita-nos explicar-lhes o que são CDNs, suas características e benefícios gerais:<br /> <br /> Como é de conhecimento comum entre os ISPs, há basicamente dois tipos de arquiteturas ou abordagens no que diz respeito às CDNs: ''Bring-Home'' e ''Enter-Deep Cache''. Foquemos no segundo caso (''Enter-Deep''), que é o tipo que mais se assemelha às CDNs que os ISPs qualificados podem solicitar e receber. A arquitetura ''Enter-Deep Cache'' possui como estratégia estar profundamente fincada dentro do ambiente de redes do ISP, geralmente sendo adotados na forma de clusters. Os benefícios proporcionados pelas CDNs são indiscutíveis:<br /> * Fornecimento de conteúdo de baixa latência, o que, por sua vez, promove uma experiência bem fluída de navegação e interação dos usuários/clientes do ISP.<br /> * Em combinação com sessões de peering privado (PNI) e peering público (IX), a arquitetura Enter-Deep promove economias bastante significativas nos custos operacionais do ISP, e em diversas áreas, especialmente o dimensionamento de recursos e manutenção de custos recorrentes com a contratação de links de trânsito IP.<br /> * Combinada com outras boas práticas de engenharia de redes, engenharia de tráfego, e segurança geral do ASN, as redes de fornecimento de conteúdo contribuem muito substancialmente para aprimoramentos de diversos KPIs do negócio.<br /> * O assinante (cliente) é beneficiado por contar com uma Internet &quot;mais fluida&quot;, e o ISP é beneficiado por poder fornecer uma experiência mais atraente de interação de seus clientes com a Internet, além da redução de custos aliada ao aprimoramento de indicadores-chave importantes do negócio.<br /> No entanto, o ISP precisa entender uma realidade: apesar dos benefícios mútuos para cliente e ISP, e até mesmo para a detentora da tecnologia (empresa de conteúdo), que consegue engajar e monetizar melhor seus (também) clientes, ter uma CDN é na verdade um '''&lt;u&gt;privilégio&lt;/u&gt;'''. O que muitos ISPs fazem é tratar a CDN como um &quot;direito&quot; deles, e isto é completamente equivocado. Mesmo que o ISP reúna os requisitos para a solicitação e obtenção de CDN - aliás, mal sabem, a solicitação não é para &quot;obter uma CDN&quot;, e sim para participar do programa de afiliados da empresa de conteúdo - a resposta/decisão será sempre por conta da detentora da tecnologia, que avaliará diversas métricas para determinar se é vantajoso ou não para ela disponibilizar a sua tecnologia para aquele ISP. Ou seja, há uma relação mútua entre os beneficiados diretos &quot;ISP e CDN&quot; (generalizando o termo aqui); assim como é vantajoso (e sempre será!) para o ISP, tem que ser vantajoso, também, para a empresa dona daquela CDN. Repetindo: CDN não é direito, é privilégio.<br /> <br /> '''Práticas ilegais exercitadas por alguns ISPs:'''<br /> * Amplificar e manipular artificialmente o tráfego via práticas escusas, recheadas de alguns desvios éticos, com o intuito de atingir o requerimento mínimo de consumo exigido pela detentora da CDN.<br /> * Promover abertamente na sua cesta de produtos e soluções que aquele ISP &quot;vende tráfego de CDNs&quot;. O ISP não pode vender tráfego de CDN direta ou abertamente, mas poderá costurar um produto que contemple isto de forma correta e legítima. O ISP poderá fornecer tráfego de CDNs dentro de um produto de &quot;Trânsito IP Parcial&quot; ou nome qualquer, desde que não divulgue que &quot;vende CDN&quot; e muito menos expondo logomarcas, fotos dos servidores, etc.<br /> * Não somente vender abertamente o tráfego de CDNs, as vezes usando nomes um tanto criativos, como &quot;IP Confinado&quot; e similares, mas ainda expor as logomarcas das empresas (ex: Netflix, Facebook, Google, Akamai, etc.). Isto é completamente ilegal.<br /> * Publicam fotos de seus data centers com o propósito de expor aos seus clientes e prospecções que possuem &quot;servidores de CDN da empresa X, Y e Z&quot;. Isto é igualmente não permitido.<br /> Com a exceção do primeiro caso (manipulação artificial do tráfego), os demais casos não tem relação com aspectos mais técnicos envolvendo redes, e sim com outras questões que passam completamente despercebidas por estes indivíduos e empresas. Os contratos que são estabelecidos entre empresas fornecedoras de conteúdo e os ISPs vão um tanto além das questões puramente técnicas, pois há uma preocupação enorme envolvendo uma cadeia inteira de partes interessadas no capital que flui com estes conteúdos, do produtor, passando pelo distribuidor, depois pelo ISP, e, por último, para os clientes. Ou seja, questões relacionadas à proteção de marcas (branding), uso inadequado de logomarcas e afins, propriedade intelectual, pagamento de royalties, e os acordos milionários entre as produtoras de conteúdos e as distribuidoras de conteúdo. A questão toda vai bem além do &quot;tequiniquês&quot;.<br /> <br /> Quando um ISP viola estes termos, ele estará desafiando uma cadeia inteira de partes interessadas que podem tomar ações contra o ISP. Na melhor das hipóteses, o ISP é alertado. Frequentemente, o ISP perde e tem as CDNs recolhidas de sua rede, além de ser banido permanentemente do programa. Há ainda o risco de outras ações serem executadas contra o ISP por uso indevido de imagem, violação de direitos autorais e/ou de propriedade intelectual. <br /> <br /> Esperamos que estas informações sejam úteis para todos vocês, e colocamo-nos à disposição para esclarecer suas dúvidas. Utilizem as nossas listas de discussão!<br /> <br /> ===CDNs===<br /> As CDNs, baseadas em critérios próprios, definem condições em que um servidor pode ser enviado para ser instalado dentro do backbone de um ISP para otimizar a entrega de conteúdo para o usuário final. Isso é vantajoso para a CDN que melhora a qualidade na entrega do conteúdo, para o usuário final e também para ISP pois além de economizar no uso dos links de upstream são capazes de prover uma melhor experiência para seus usuários.<br /> <br /> O tráfego atual de referência para solicitação de servidores de algumas CDN está na faixa dos 2 a 5 Gbps, porém existem condições que isso pode ser flexibilizado à depender da região e da disponibilidade de outros Trânsitos IP presentes serem capazes de distribuir aquele conteúdo. Via de regra em uma grande cidade ou região populosa com acesso à IX que já possui servidores de cache ou uma quantidade razoável de Trânsitos IP é bastante provável que o valor de referência não seja flexibilizado pelas CDNs.<br /> ====Akamai (AANP)====<br /> *Banda mínima: 10 Gbps<br /> *Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp<br /> *Documentação: https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> ====Apple====<br /> *Banda mínima: 25 Gbps<br /> *Informações: https://cache.edge.apple/<br /> *Solicitação: https://cache.edge.apple/inquire<br /> *PeeringDB: https://peeringdb.com/asn/714<br /> *Nota: Como exigem uma quantidade de banda alta para o cache, evite entrar em contato caso seu tráfego não esteja ao menos com previsão de chegar ao mínimo nos próximos 12 meses. Como a Apple ainda não está no IX.Br SP, dê preferencia por entrar em contato sugerindo que eles mantenham pontos de presença no Brasil, será muito mais eficiente. <br /> ====Facebook (FNA)====<br /> *Banda mínima: 5 Gbps<br /> *Email: fna@fb.com<br /> *PeeringDB: https://www.peeringdb.com/net/979<br /> *Nota: O Facebook analisa apenas o tráfego trocado com o ASN solicitante e não de seus respectivos clientes de trânsito (demais ASNs). Também não considera possibilidade da soma do tráfego trocado com os ASNs desejando compartilhar um FNA em um IX Privado ou interconexão bilateral, independente de um contrato existente entre as partes.<br /> *Prefixos CGNAT: Não suportados oficialmente. Considere uso de IPv6.<br /> ====Google (GGC)====<br /> *Banda mínima: 3 Gbps<br /> *Informações: https://peering.google.com/#/options/google-global-cache<br /> *Solicitação: http://isp.google.com/iwantpeering<br /> *Instalação: https://www.gstatic.com/isp/docs/ggc-installation.pdf<br /> *Troubleshooting: https://cloud.google.com/cdn/docs/support<br /> *Portal: https://isp.google.com/dashboard/<br /> * PeeringDB: https://www.peeringdb.com/net/433&lt;nowiki/&gt;https://www.peeringdb.com/net/4319<br /> * Prefixos CGNAT: Aceitos com community. Acess&lt;nowiki/&gt;e a documentação no portal.<br /> <br /> ====Edgecast Verizon Digital Media (EC)====<br /> *Banda mínima: 10 Gbps<br /> *Email: peering@verizondigitalmedia.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/ <br /> *Solicitação: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt; <br /> <br /> *<br /> ====Netflix (OCA)====<br /> *Banda mínima: 5 Gbps (SP, RJ, RS e CE) e 2 Gbps (demais Estados)<br /> *Solicitação: https://openconnect.netflix.com/en/request/<br /> *Instalação: https://openconnect.netflix.com/deploymentguide.pdf<br /> *Troubleshooting: https://openconnect.netflix.com/en/faq/<br /> *Portal: https://my.oc.netflix.com/<br /> *PeeringDB: https://www.peeringdb.com/net/457<br /> *Prefixos CGNAT: Não suportado oficialmente. Considere uso de IPv6.<br /> <br /> ==== Azion (ANA) ====<br /> * Banda mínima: 4 Gbps (Seletiva)<br /> * Email: cdn@azion.com / peering@azion.com<br /> * Informações: https://www.azion.com.br/developers/peering/<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> <br /> ==== SourceForge.Net ====<br /> * Banda mínima: 150Mbps<br /> * Hardware por conta do provedor, com 8TB de disco no mínimo.<br /> * Email: staff@sourceforge.net<br /> * Informações: https://sourceforge.net/p/forge/documentation/Join%20as%20a%20Mirror/<br /> <br /> ==== Microsoft ====<br /> * Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo)<br /> * Email: ispnode@microsoft.com<br /> * Informações: https://peering.azurewebsites.net/Peering/Caching<br /> * PeeringDB: http://as8075.peeringdb.com/<br /> <br /> ===Peerings - Sessões Bilaterais===<br /> É possível também solicitar diretamente à alguns ASNs o estabelecimento de uma sessão bilateral através de algum dos IX onde ambos os ASNs estejam presentes (para saber mais consulte [[Modelos_Interconexão]]). Em alguns casos existe um tráfego mínimo para estabelecimento desta sessão, portanto sempre que possível verifique através de sistemas de monitoramento internos a quantidade de tráfego trocada entre ambos ASNs antes de fazer contato para solicitação de peering.<br /> <br /> Na maioria dos casos os prefixos anunciados para os Route Servers são os mesmos anunciados na sessão bilateral, porém existem também casos onde isso pode ser diferente o que justifica o estabelecimento da sessão ou ainda para permitir ao ASN um melhor controle sobre os anúncios para cada um desses ASNs.Por padrão a sessão é estabelecida na mesma VLAN do ATM v4 e v6, a não ser que exista alguma motivação para que seja estabelecida através de uma VLAN Bilateral.<br /> <br /> Também existem casos de conteúdos como a Microsoft que anunciou recentemente a saída dos Route Servers, portanto em casos como esses é necessário estabelecer uma sessão bilateral para que exista troca de tráfego direta entre ambos os ASNs.<br /> <br /> Antes de solicitar o estabelecimento de uma sessão bilateral através do IX recomenda-se deixar a configuração pronta no seu roteador para agilizar o processo.<br /> <br /> A listagem não exaustiva abaixo apresenta alguns ASNs que são conhecidos por estabelecerem sessões bilaterais no IX-SP:<br /> ====Akamai====<br /> *Email: peering@akamai.com e peering-tix@akamai.com<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> ====Edgecast Verizon Digital Media====<br /> *Email: peering@verizondigitalmedia.com<br /> *Solicitação: peering@verizondigitalmedia.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt;<br /> ====Microsoft====<br /> *Email: peering@microsoft.com<br /> *Solicitação: http://www.microsoft.com/peering<br /> *PeeringDB: [https://www.peeringdb.com/net/694 http://as8075.peeringdb.com/]<br /> <br /> ==== Hurricane Electric ====<br /> * Email: peering@he.net<br /> * Email NOC: noc@he.net (após sessão estar ativada)<br /> * Informações: http://he.net/peering.html<br /> * PeeringDB: https://www.peeringdb.com/net/291<br /> A Hurricane Electric oferece também Trânsito IPv6 gratuito através de sessão bilateral. Para solicitar envie um email para ipv6@he.net<br /> <br /> ====LinkedIn====<br /> *Email: peering@linkedin.com<br /> *PeeringDB: https://www.peeringdb.com/net/4231<br /> ====CloudFlare====<br /> *Email: peering@cloudflare.com<br /> *PeeringDB: https://www.peeringdb.com/net/4224<br /> ====CDNetworks====<br /> *Email: peering@cdnetworks.com<br /> *PeeringDB: https://www.peeringdb.com/net/1372<br /> <br /> ==== Azion ====<br /> * Banda mínima: 150 Mbps (Seletiva)<br /> * Email: peering@azion.com / noc@azion.com<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> <br /> ==== Twitch TV ====<br /> * Email: noc@twitch.tv / peering@twitch.tv<br /> * Contato: https://noc.twitch.tv/<br /> * PeeringDB: https://www.peeringdb.com/asn/46489<br /> * Política: Seletiva<br /> <br /> ==== Oath/Yahoo ====<br /> * Email: peering-requests@oath.com<br /> * Informações: https://peering.oath.com/policy<br /> * PeeringDB: https://www.peeringdb.com/asn/10310/<br /> * Política: Seletiva<br /> <br /> ==== Netflix ====<br /> * Banda Minima: 3Gbps<br /> * Email: peering@netflix.com<br /> * PeeringDB: https://www.peeringdb.com/net/457<br /> * Nota: De acordo com informação publicada no PeeringDB o Netflix anuncia os mesmos prefixos para os Route Servers do ATM e para as Sessões Bilaterais. Por isso não costumam fechar Sessões Bilaterais via IX a não ser em casos complexos de engenharia de tráfego e orientam os participantes a utilizarem as communities disponibilizadas pelo IX.br para manobrarem o tráfego.<br /> <br /> ==== Google ====<br /> * Email: noc@google.com<br /> * Solicitação: &lt;nowiki&gt;https://isp.google.com/iwantpeering&lt;/nowiki&gt;<br /> * PeeringDB: https://www.peeringdb.com/net/433<br /> <br /> ==== Facebook ====<br /> * Email: peering@fb.com / noc@fb.com<br /> * Informação: https://www.facebook.com/peering/<br /> * PeeringDB: https://www.peeringdb.com/net/979<br /> * Política: Seletiva<br /> * Nota: O estabelecimento das sessões bilaterais é sempre através da Vlan do ATM.<br /> <br /> ==== Amazon ====<br /> * Email: peering@amazon.com<br /> * PeeringDB: https://www.peeringdb.com/net/1418<br /> * Política: Seletiva<br /> <br /> ==== SoftLayer ====<br /> * Email: peering@softlayer.com<br /> * PeeringDB: https://www.peeringdb.com/asn/36351<br /> * Política: Seletiva<br /> <br /> ==== RiotGames ====<br /> * Email: peering@riotgames.com<br /> * PeeringDB: https://www.peeringdb.com/asn/6507<br /> * Política: Seletiva<br /> <br /> ==== i3D.net / Ubisoft ====<br /> * Email: peering@i3d.net<br /> * PeeringDB: https://www.peeringdb.com/asn/49544<br /> * Política: Seletiva<br /> <br /> ==== Twitter ====<br /> * Banda mínima: 100 Mbps<br /> * Email: peering@twitter.com<br /> * PeeringDB: https://www.peeringdb.com/asn/13414<br /> * Política: Seletiva<br /> <br /> ==== Globo ====<br /> * Email: peering@peering.globo<br /> * Informações: https://peering.globo<br /> * PeeringDB: https://www.peeringdb.com/net/5703<br /> <br /> ==== Tencent ====<br /> * Email: peering@tencent.com<br /> * Informações: [https://peering.tencent.com/peering/peering_form &lt;nowiki&gt;https://peering.tencent.com/peering/&lt;/nowiki&gt;peering_form]<br /> * PeeringDB: https://www.peeringdb.com/asn/132203<br /> <br /> ===PNIs - Private Network Interconnection===<br /> PNIs são interconexões privadas realizadas diretamente entre dois ASNs sem o intermédio de um terceiro (entenda PNI em: [[Modelos_Interconexão]]). Geralmente é um ''cross-connect'' ou ''golden-jumper'' entre os racks das duas empresas em um mesmo Datacenter onde ambas estejam presentes.No [https://www.peeringdb.com/ PeeringDB] é possível verificar os Datacenters que as CDNs estão presentes e onde existe possibilidade de solicitar um PNI olhando na seção &quot;Private Peering Facilities&quot;.<br /> <br /> Uma das vantagens de um PNI é a de por se tratar de uma conexão direta não esta suscetível à possíveis problemas causados por exemplo na matriz de um IX aonde ambos ASN já trocam tráfego. Além disso por se tratar de uma conexão dedicada a banda toda disponível na porta é dedicada àquele tráfego entre os dois ASNs aliviando assim outras portas de peering para outros tipos de tráfegos.<br /> <br /> Algumas CDNs embora grandes optam por não disponibilizar a modalidade de interconexão através de PNI restringindo assim à troca de tráfego através do IX ou através de um servidor de CDN que é instalado dentro do backbone do ISP.<br /> <br /> Normalmente envolve um custo que é o do ''cross-connect'' ou ''golden-jumper'' que pode ser pago por uma das partes ou dividido igualmente entre ambas. Para que o parceiro ou você possa solicitar este cross, será necessário o envio de um LoA (Letter of Authorization) indicando que a parte remota está autorizando a passado do cabeamento em sua rack, caso você não saiba como criar esse LoA, verifique a sessão download do portal do parceiro ou solicite a seu parceiro um modelo, você também pode se basear neste exemplo fornecido pelo Google https://isp.google.com/static/downloads/LOA.pdf.<br /> <br /> A listagem abaixo contém as informações em quais Datacenters é possível ter um PNI com algumas dessas CDNs:<br /> ====Facebook====<br /> *Banda mínima: 1 Gbps<br /> *Email: peering@fb.com<br /> *Datacenters: Equinix-SP2, Equinix-SP4 e Equinix-RJ1<br /> *PeeringDB: https://www.peeringdb.com/net/979<br /> *Informações: https://wiki.brasilpeeringforum.org/images/4/4e/Peer-pni-parameters-facebook.pdf<br /> ====Google====<br /> *Informações: https://peering.google.com/#/options/peering<br /> *Solicitação: http://isp.google.com/iwantpeering<br /> *Datacenters: Equinix-SP2 (através de transporte), Equinix-SP4, Level 3 - Cotia e Level 3 - Rio de Janeiro.<br /> *PeeringDB: https://www.peeringdb.com/net/433&lt;nowiki/&gt;https://www.peeringdb.com/net/4319<br /> *Modelo LoA: [https://isp.google.com/static/downloads/LOA.pdf https://isp.google.com/static/do]&lt;nowiki/&gt;[https://isp.google.com/static/downloads/LOA.pdf wnloads/LOA.pdf] <br /> ====Edgecast Verizon Digital Media====<br /> *Banda mínima: 1 Gbps<br /> *Email: peering@verizondigitalmedia.com<br /> *Solicitação: peering@verizondigitalmedia.com / CarrierRelations@edgecast.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt;<br /> *Datacenters: Equinix-SP4, Equinix-RJ2<br /> ==== Netflix ====<br /> * Banda Mínima: 3 Gbps<br /> * Email: peering@netflix.com<br /> * Informações: https://openconnect.netflix.com/en/guidelines/<br /> * Datacenters: Equinix-SP2, Equinix-RJ1, NIC-JD, Commcorp Porto Alegre-PAE1, ETICE-Fortaleza<br /> * PeeringDB: https://www.peeringdb.com/net/457<br /> <br /> ==== Akamai ====<br /> * Banda Mínima: 5 Gbps<br /> * Email: netsupport-tix@akamai.com<br /> * Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> *Datacenters: Equinix-SP4, Teleporto-RJ <br /> <br /> ==== Azion ====<br /> * Banda mínima: 5 Gbps<br /> * Email: peering@azion.com / noc@azion.com<br /> * Informações: https://www.azion.com.br/developers/peering/<br /> * Datacenters: Ascenty Campinas, Commcorp-BSA2, Commcorp-FNS1, Commcorp-PAE1, Equinix-SP3, Level 3 - Cotia, GVT - Curitiba, Globenet - Fortaleza, NIC-JD, PIX Adylnet-PAE, PIX G8 - São Paulo, PIX Vogel - Porto Alegre, Tascom - Salvador<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> ==== Twitch TV ====<br /> * Banda mínima: 2.5 Gbps<br /> * Email: noc@twitch.tv / interconnection@twitch.tv<br /> * Contato: https://noc.twitch.tv/<br /> * Datacenters: Equinix-SP2, Level 3 - Cotia, Level 3 - Rio de Janeiro<br /> * PeeringDB: https://www.peeringdb.com/asn/46489<br /> ==== Globo ====<br /> * Email: peering@peering.globo<br /> * Informações: https://peering.globo<br /> * PeeringDB: https://www.peeringdb.com/net/5703<br /> * Locais: Rio de Janeiro: Jacarepaguá, São Paulo: Alameda Santos, Fortaleza: Datacenter Angola Cables<br /> [[Categoria:Interconexão]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=CDN_Peering_e_PNI_-_Brasil&diff=2504 2020-06-02T22:37:57Z

<p>Leonardo.furtado: </p> <hr /> <div><br /> ===Introdução===<br /> Esta página contém informações úteis para operadores de redes e ISPs com relação à solicitação de servidores de CDNs, estabelecimento de uma sessão Bilateral em algum dos IXs ou para a solicitação de PNIs nos Datacenters aonde ASNs, geralmente grandes geradores de conteúdos, estão presentes.<br /> <br /> É importante destacar que as informações aqui apresentadas (ex: tráfego necessário para solicitar servidores de CDN) mudam de forma bastante dinâmica e de acordo com as regras próprias estabelecidas pelos próprios geradores de conteúdo, portanto este guia serve como referência para o momento que ele foi escrito ou atualizado pela última vez.<br /> <br /> Um recomendação importante a ser feita é que antes de fazer a solicitação de servidores de CDN ou de um PNI por exemplo, é importante realizar uma avaliação detalhada do tráfego que o seu ASN troca com os ASNs desses geradores de conteúdo. Ferramentas como NetFlow e [https://www.peeringdb.com/ PeeringDB] auxiliam bastante. Cerifique-se que você atende à &lt;u&gt;TODOS os requisitos&lt;/u&gt; antes de fazer a solicitação, principalmente se possui a quantidade de mínima de tráfego para ser elegível. Esses servidores somente são enviados aos ISPs no caso das empresas de CDN verificarem que eles trazem benefícios para &lt;u&gt;ambos CDN e ISP&lt;/u&gt;, caso contrário dificilmente serão enviados. Hospedar e manter um servidor de CDN é algo que demanda recursos do provedor como espaço em rack, portas de switch e principalmente um consumo razoável de energia elétrica por isso uma avaliação criteriosa é bastante importante antes de realizar a solicitação.<br /> <br /> Outro detalhe imprescindível na hora de solicitar um servidor de CDN, Peering por Sessão Bilateral ou PNI &lt;u&gt;é o IPv6&lt;/u&gt;. Devido à crescente importância deste protocolo algumas CDNs hoje em dia tem colocado restrições caso você não seja capaz de estabelecer uma sessão IPv6 com eles.Além disso caso você possua IPv6 em seu backbone porém ainda não está distribuindo para os usuários residencias e possui apenas CGNAT44 &lt;u&gt;a maioria das grandes CDNs já possuem suporte completo à IPv6&lt;/u&gt; portanto uma parte significativa do seu tráfego poderia estar fluindo preferencialmente em IPv6 ao invés de estar passando por equipamentos que fazem o GGNAT a um custo computacional maior além de ter a identificação do usuário facilitada em caso de uma solicitação baseada no Marco Civil da Internet.<br /> <br /> A maioria das CDNs exigem que as informações sobre o ASN solicitante estejam atualizadas no PeeringDB portanto antes de solicitar é uma boa prática conferi-las.<br /> <br /> Você pode acessar a URL a seguir para entender melhor o funcionamento de sessões Peering: [[Modelos_Interconexão]]<br /> <br /> ''Última atualização - '''11/05/2020'''''<br /> <br /> === Informações importantes sobre termos de contrato, NDA, propriedade intelectual, uso impróprio de logomarcas, e outras práticas que devem ser abolidas pelo ISP ===<br /> Atenção senhores provedores de acesso à Internet (ISP). Esta seção do presente documento visa esclarecer algumas informações importantes sobre a legitimidade de certas práticas que tem sido detectadas entre os ISPs, generalizando aqui, em particular no que diz respeito ao uso impróprio de recursos providos pelas redes de fornecimento de conteúdo (CDN), e também de algumas violações graves dos termos estabelecidos em regime de contrato entre a detentora da tecnologia (empresa de conteúdo que fornece a CDN) e o ISP. Mas, antes, permita-nos explicar-lhes o que são CDNs, suas características e benefícios gerais:<br /> <br /> Como é de conhecimento comum entre os ISPs, há basicamente dois tipos de arquiteturas ou abordagens no que diz respeito às CDNs: ''Bring-Home'' e ''Enter-Deep Cache''. Foquemos no segundo caso (''Enter-Deep''), que é o tipo que mais se assemelha às CDNs que os ISPs qualificados podem solicitar e receber. A arquitetura ''Enter-Deep Cache'' possui como estratégia estar profundamente fincada dentro do ambiente de redes do ISP, geralmente sendo adotados na forma de clusters. Os benefícios proporcionados pelas CDNs são indiscutíveis:<br /> * Fornecimento de conteúdo de baixa latência, o que, por sua vez, promove uma experiência bem fluída de navegação e interação dos usuários/clientes do ISP.<br /> * Em combinação com sessões de peering privado (PNI) e peering público (IX), a arquitetura Enter-Deep promove economias bastante significativas nos custos operacionais do ISP, e em diversas áreas, especialmente o dimensionamento de recursos e manutenção de custos recorrentes com a contratação de links de trânsito IP.<br /> * Combinada com outras boas práticas de engenharia de redes, engenharia de tráfego, e segurança geral do ASN, as redes de fornecimento de conteúdo contribuem muito substancialmente para aprimoramentos de diversos KPIs do negócio.<br /> * O assinante (cliente) é beneficiado por contar com uma Internet &quot;mais fluida&quot;, e o ISP é beneficiado por poder fornecer uma experiência mais atraente de interação de seus clientes com a Internet, além da redução de custos aliada ao aprimoramento de indicadores-chave importantes do negócio.<br /> No entanto, o ISP precisa entender uma realidade: apesar dos benefícios mútuos para cliente e ISP, e até mesmo para a detentora da tecnologia (empresa de conteúdo), que consegue engajar e monetizar melhor seus (também) clientes, ter uma CDN é na verdade um '''&lt;u&gt;privilégio&lt;/u&gt;'''. O que muitos ISPs fazem é tratar a CDN como um &quot;direito&quot; deles, e isto é completamente equivocado. Mesmo que o ISP reúna os requisitos para a solicitação e obtenção de CDN - aliás, mal sabem, a solicitação não é para &quot;obter uma CDN&quot;, e sim para participar do programa de afiliados da empresa de conteúdo - a resposta/decisão será sempre por conta da detentora da tecnologia, que avaliará diversas métricas para determinar se é vantajoso ou não para ela disponibilizar a sua tecnologia para aquele ISP. Ou seja, há uma relação mútua entre os beneficiados diretos &quot;ISP e CDN&quot; (generalizando o termo aqui); assim como é vantajoso (e sempre será!) para o ISP, tem que ser vantajoso, também, para a empresa dona daquela CDN. Repetindo: CDN não é direito, é privilégio.<br /> <br /> '''Práticas ilegais exercitadas por alguns ISPs:'''<br /> * Amplificar e manipular artificialmente o tráfego via práticas escusas, recheadas de alguns desvios éticos, com o intuito de atingir o requerimento mínimo de consumo exigido pela detentora da CDN.<br /> * Promover abertamente na sua cesta de produtos e soluções que aquele ISP &quot;vende tráfego de CDNs&quot;. O ISP não pode vender tráfego de CDN direta ou abertamente, mas poderá costurar um produto que contemple isto de forma correta e legítima. O ISP poderá fornecer tráfego de CDNs dentro de um produto de &quot;Trânsito IP Parcial&quot; ou nome qualquer, desde que não divulgue que &quot;vende CDN&quot; e muito menos expondo logomarcas, fotos dos servidores, etc.<br /> * Não somente vender abertamente o tráfego de CDNs, as vezes usando nomes um tanto criativos, tais como &quot;IP Confinado&quot;, &quot;IP Confinity&quot;, e outros, e ainda expõem as logomarcas das empresas (ex: Netflix, Facebook, Google, Akamai, etc.). Isto é completamente ilegal.<br /> * Publicam fotos de seus data centers com o propósito de expor aos seus clientes e prospecções que possuem &quot;servidores de CDN da empresa X, Y e Z&quot;. Isto é igualmente não permitido.<br /> Com a exceção do primeiro caso (manipulação artificial do tráfego), os demais casos não tem relação com aspectos mais técnicos envolvendo redes, e sim com outras questões que passam completamente despercebidas por estes indivíduos e empresas. Os contratos que são estabelecidos entre empresas fornecedoras de conteúdo e os ISPs vão um tanto além das questões puramente técnicas, pois há uma preocupação enorme envolvendo uma cadeia inteira de partes interessadas no capital que flui com estes conteúdos, do produtor, passando pelo distribuidor, depois pelo ISP, e, por último, para os clientes. Ou seja, questões relacionadas à proteção de marcas (branding), uso inadequado de logomarcas e afins, propriedade intelectual, pagamento de royalties, e os acordos milionários entre as produtoras de conteúdos e as distribuidoras de conteúdo. A questão toda vai bem além do &quot;tequiniquês&quot;.<br /> <br /> Quando um ISP viola estes termos, ele estará desafiando uma cadeia inteira de partes interessadas que podem tomar ações contra o ISP. Na melhor das hipóteses, o ISP é alertado. Frequentemente, o ISP perde e tem as CDNs recolhidas de sua rede, além de ser banido permanentemente do programa. Há ainda o risco de outras ações serem executadas contra o ISP por uso indevido de imagem, violação de direitos autorais e/ou de propriedade intelectual. <br /> <br /> Esperamos que estas informações sejam úteis para todos vocês, e colocamo-nos à disposição para esclarecer suas dúvidas. Utilizem as nossas listas de discussão!<br /> <br /> ===CDNs===<br /> As CDNs, baseadas em critérios próprios, definem condições em que um servidor pode ser enviado para ser instalado dentro do backbone de um ISP para otimizar a entrega de conteúdo para o usuário final. Isso é vantajoso para a CDN que melhora a qualidade na entrega do conteúdo, para o usuário final e também para ISP pois além de economizar no uso dos links de upstream são capazes de prover uma melhor experiência para seus usuários.<br /> <br /> O tráfego atual de referência para solicitação de servidores de algumas CDN está na faixa dos 2 a 5 Gbps, porém existem condições que isso pode ser flexibilizado à depender da região e da disponibilidade de outros Trânsitos IP presentes serem capazes de distribuir aquele conteúdo. Via de regra em uma grande cidade ou região populosa com acesso à IX que já possui servidores de cache ou uma quantidade razoável de Trânsitos IP é bastante provável que o valor de referência não seja flexibilizado pelas CDNs.<br /> ====Akamai (AANP)====<br /> *Banda mínima: 10 Gbps<br /> *Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp<br /> *Documentação: https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> ====Apple====<br /> *Banda mínima: 25 Gbps<br /> *Informações: https://cache.edge.apple/<br /> *Solicitação: https://cache.edge.apple/inquire<br /> *PeeringDB: https://peeringdb.com/asn/714<br /> *Nota: Como exigem uma quantidade de banda alta para o cache, evite entrar em contato caso seu tráfego não esteja ao menos com previsão de chegar ao mínimo nos próximos 12 meses. Como a Apple ainda não está no IX.Br SP, dê preferencia por entrar em contato sugerindo que eles mantenham pontos de presença no Brasil, será muito mais eficiente. <br /> ====Facebook (FNA)====<br /> *Banda mínima: 5 Gbps<br /> *Email: fna@fb.com<br /> *PeeringDB: https://www.peeringdb.com/net/979<br /> *Nota: O Facebook analisa apenas o tráfego trocado com o ASN solicitante e não de seus respectivos clientes de trânsito (demais ASNs). Também não considera possibilidade da soma do tráfego trocado com os ASNs desejando compartilhar um FNA em um IX Privado ou interconexão bilateral, independente de um contrato existente entre as partes.<br /> *Prefixos CGNAT: Não suportados oficialmente. Considere uso de IPv6.<br /> ====Google (GGC)====<br /> *Banda mínima: 3 Gbps<br /> *Informações: https://peering.google.com/#/options/google-global-cache<br /> *Solicitação: http://isp.google.com/iwantpeering<br /> *Instalação: https://www.gstatic.com/isp/docs/ggc-installation.pdf<br /> *Troubleshooting: https://cloud.google.com/cdn/docs/support<br /> *Portal: https://isp.google.com/dashboard/<br /> * PeeringDB: https://www.peeringdb.com/net/433&lt;nowiki/&gt;https://www.peeringdb.com/net/4319<br /> * Prefixos CGNAT: Aceitos com community. Acess&lt;nowiki/&gt;e a documentação no portal.<br /> <br /> ====Edgecast Verizon Digital Media (EC)====<br /> *Banda mínima: 10 Gbps<br /> *Email: peering@verizondigitalmedia.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/ <br /> *Solicitação: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt; <br /> <br /> *<br /> ====Netflix (OCA)====<br /> *Banda mínima: 5 Gbps (SP, RJ, RS e CE) e 2 Gbps (demais Estados)<br /> *Solicitação: https://openconnect.netflix.com/en/request/<br /> *Instalação: https://openconnect.netflix.com/deploymentguide.pdf<br /> *Troubleshooting: https://openconnect.netflix.com/en/faq/<br /> *Portal: https://my.oc.netflix.com/<br /> *PeeringDB: https://www.peeringdb.com/net/457<br /> *Prefixos CGNAT: Não suportado oficialmente. Considere uso de IPv6.<br /> <br /> ==== Azion (ANA) ====<br /> * Banda mínima: 4 Gbps (Seletiva)<br /> * Email: cdn@azion.com / peering@azion.com<br /> * Informações: https://www.azion.com.br/developers/peering/<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> <br /> ==== SourceForge.Net ====<br /> * Banda mínima: 150Mbps<br /> * Hardware por conta do provedor, com 8TB de disco no mínimo.<br /> * Email: staff@sourceforge.net<br /> * Informações: https://sourceforge.net/p/forge/documentation/Join%20as%20a%20Mirror/<br /> <br /> ==== Microsoft ====<br /> * Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo)<br /> * Email: ispnode@microsoft.com<br /> * Informações: https://peering.azurewebsites.net/Peering/Caching<br /> * PeeringDB: http://as8075.peeringdb.com/<br /> <br /> ===Peerings - Sessões Bilaterais===<br /> É possível também solicitar diretamente à alguns ASNs o estabelecimento de uma sessão bilateral através de algum dos IX onde ambos os ASNs estejam presentes (para saber mais consulte [[Modelos_Interconexão]]). Em alguns casos existe um tráfego mínimo para estabelecimento desta sessão, portanto sempre que possível verifique através de sistemas de monitoramento internos a quantidade de tráfego trocada entre ambos ASNs antes de fazer contato para solicitação de peering.<br /> <br /> Na maioria dos casos os prefixos anunciados para os Route Servers são os mesmos anunciados na sessão bilateral, porém existem também casos onde isso pode ser diferente o que justifica o estabelecimento da sessão ou ainda para permitir ao ASN um melhor controle sobre os anúncios para cada um desses ASNs.Por padrão a sessão é estabelecida na mesma VLAN do ATM v4 e v6, a não ser que exista alguma motivação para que seja estabelecida através de uma VLAN Bilateral.<br /> <br /> Também existem casos de conteúdos como a Microsoft que anunciou recentemente a saída dos Route Servers, portanto em casos como esses é necessário estabelecer uma sessão bilateral para que exista troca de tráfego direta entre ambos os ASNs.<br /> <br /> Antes de solicitar o estabelecimento de uma sessão bilateral através do IX recomenda-se deixar a configuração pronta no seu roteador para agilizar o processo.<br /> <br /> A listagem não exaustiva abaixo apresenta alguns ASNs que são conhecidos por estabelecerem sessões bilaterais no IX-SP:<br /> ====Akamai====<br /> *Email: peering@akamai.com e peering-tix@akamai.com<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> ====Edgecast Verizon Digital Media====<br /> *Email: peering@verizondigitalmedia.com<br /> *Solicitação: peering@verizondigitalmedia.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt;<br /> ====Microsoft====<br /> *Email: peering@microsoft.com<br /> *Solicitação: http://www.microsoft.com/peering<br /> *PeeringDB: [https://www.peeringdb.com/net/694 http://as8075.peeringdb.com/]<br /> <br /> ==== Hurricane Electric ====<br /> * Email: peering@he.net<br /> * Email NOC: noc@he.net (após sessão estar ativada)<br /> * Informações: http://he.net/peering.html<br /> * PeeringDB: https://www.peeringdb.com/net/291<br /> A Hurricane Electric oferece também Trânsito IPv6 gratuito através de sessão bilateral. Para solicitar envie um email para ipv6@he.net<br /> <br /> ====LinkedIn====<br /> *Email: peering@linkedin.com<br /> *PeeringDB: https://www.peeringdb.com/net/4231<br /> ====CloudFlare====<br /> *Email: peering@cloudflare.com<br /> *PeeringDB: https://www.peeringdb.com/net/4224<br /> ====CDNetworks====<br /> *Email: peering@cdnetworks.com<br /> *PeeringDB: https://www.peeringdb.com/net/1372<br /> <br /> ==== Azion ====<br /> * Banda mínima: 150 Mbps (Seletiva)<br /> * Email: peering@azion.com / noc@azion.com<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> <br /> ==== Twitch TV ====<br /> * Email: noc@twitch.tv / peering@twitch.tv<br /> * Contato: https://noc.twitch.tv/<br /> * PeeringDB: https://www.peeringdb.com/asn/46489<br /> * Política: Seletiva<br /> <br /> ==== Oath/Yahoo ====<br /> * Email: peering-requests@oath.com<br /> * Informações: https://peering.oath.com/policy<br /> * PeeringDB: https://www.peeringdb.com/asn/10310/<br /> * Política: Seletiva<br /> <br /> ==== Netflix ====<br /> * Banda Minima: 3Gbps<br /> * Email: peering@netflix.com<br /> * PeeringDB: https://www.peeringdb.com/net/457<br /> * Nota: De acordo com informação publicada no PeeringDB o Netflix anuncia os mesmos prefixos para os Route Servers do ATM e para as Sessões Bilaterais. Por isso não costumam fechar Sessões Bilaterais via IX a não ser em casos complexos de engenharia de tráfego e orientam os participantes a utilizarem as communities disponibilizadas pelo IX.br para manobrarem o tráfego.<br /> <br /> ==== Google ====<br /> * Email: noc@google.com<br /> * Solicitação: &lt;nowiki&gt;https://isp.google.com/iwantpeering&lt;/nowiki&gt;<br /> * PeeringDB: https://www.peeringdb.com/net/433<br /> <br /> ==== Facebook ====<br /> * Email: peering@fb.com / noc@fb.com<br /> * Informação: https://www.facebook.com/peering/<br /> * PeeringDB: https://www.peeringdb.com/net/979<br /> * Política: Seletiva<br /> * Nota: O estabelecimento das sessões bilaterais é sempre através da Vlan do ATM.<br /> <br /> ==== Amazon ====<br /> * Email: peering@amazon.com<br /> * PeeringDB: https://www.peeringdb.com/net/1418<br /> * Política: Seletiva<br /> <br /> ==== SoftLayer ====<br /> * Email: peering@softlayer.com<br /> * PeeringDB: https://www.peeringdb.com/asn/36351<br /> * Política: Seletiva<br /> <br /> ==== RiotGames ====<br /> * Email: peering@riotgames.com<br /> * PeeringDB: https://www.peeringdb.com/asn/6507<br /> * Política: Seletiva<br /> <br /> ==== i3D.net / Ubisoft ====<br /> * Email: peering@i3d.net<br /> * PeeringDB: https://www.peeringdb.com/asn/49544<br /> * Política: Seletiva<br /> <br /> ==== Twitter ====<br /> * Banda mínima: 100 Mbps<br /> * Email: peering@twitter.com<br /> * PeeringDB: https://www.peeringdb.com/asn/13414<br /> * Política: Seletiva<br /> <br /> ==== Globo ====<br /> * Email: peering@peering.globo<br /> * Informações: https://peering.globo<br /> * PeeringDB: https://www.peeringdb.com/net/5703<br /> <br /> ==== Tencent ====<br /> * Email: peering@tencent.com<br /> * Informações: [https://peering.tencent.com/peering/peering_form &lt;nowiki&gt;https://peering.tencent.com/peering/&lt;/nowiki&gt;peering_form]<br /> * PeeringDB: https://www.peeringdb.com/asn/132203<br /> <br /> ===PNIs - Private Network Interconnection===<br /> PNIs são interconexões privadas realizadas diretamente entre dois ASNs sem o intermédio de um terceiro (entenda PNI em: [[Modelos_Interconexão]]). Geralmente é um ''cross-connect'' ou ''golden-jumper'' entre os racks das duas empresas em um mesmo Datacenter onde ambas estejam presentes.No [https://www.peeringdb.com/ PeeringDB] é possível verificar os Datacenters que as CDNs estão presentes e onde existe possibilidade de solicitar um PNI olhando na seção &quot;Private Peering Facilities&quot;.<br /> <br /> Uma das vantagens de um PNI é a de por se tratar de uma conexão direta não esta suscetível à possíveis problemas causados por exemplo na matriz de um IX aonde ambos ASN já trocam tráfego. Além disso por se tratar de uma conexão dedicada a banda toda disponível na porta é dedicada àquele tráfego entre os dois ASNs aliviando assim outras portas de peering para outros tipos de tráfegos.<br /> <br /> Algumas CDNs embora grandes optam por não disponibilizar a modalidade de interconexão através de PNI restringindo assim à troca de tráfego através do IX ou através de um servidor de CDN que é instalado dentro do backbone do ISP.<br /> <br /> Normalmente envolve um custo que é o do ''cross-connect'' ou ''golden-jumper'' que pode ser pago por uma das partes ou dividido igualmente entre ambas. Para que o parceiro ou você possa solicitar este cross, será necessário o envio de um LoA (Letter of Authorization) indicando que a parte remota está autorizando a passado do cabeamento em sua rack, caso você não saiba como criar esse LoA, verifique a sessão download do portal do parceiro ou solicite a seu parceiro um modelo, você também pode se basear neste exemplo fornecido pelo Google https://isp.google.com/static/downloads/LOA.pdf.<br /> <br /> A listagem abaixo contém as informações em quais Datacenters é possível ter um PNI com algumas dessas CDNs:<br /> ====Facebook====<br /> *Banda mínima: 1 Gbps<br /> *Email: peering@fb.com<br /> *Datacenters: Equinix-SP2, Equinix-SP4 e Equinix-RJ1<br /> *PeeringDB: https://www.peeringdb.com/net/979<br /> *Informações: https://wiki.brasilpeeringforum.org/images/4/4e/Peer-pni-parameters-facebook.pdf<br /> ====Google====<br /> *Informações: https://peering.google.com/#/options/peering<br /> *Solicitação: http://isp.google.com/iwantpeering<br /> *Datacenters: Equinix-SP2 (através de transporte), Equinix-SP4, Level 3 - Cotia e Level 3 - Rio de Janeiro.<br /> *PeeringDB: https://www.peeringdb.com/net/433&lt;nowiki/&gt;https://www.peeringdb.com/net/4319<br /> *Modelo LoA: [https://isp.google.com/static/downloads/LOA.pdf https://isp.google.com/static/do]&lt;nowiki/&gt;[https://isp.google.com/static/downloads/LOA.pdf wnloads/LOA.pdf] <br /> ====Edgecast Verizon Digital Media====<br /> *Banda mínima: 1 Gbps<br /> *Email: peering@verizondigitalmedia.com<br /> *Solicitação: peering@verizondigitalmedia.com / CarrierRelations@edgecast.com<br /> *Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/<br /> *PeeringDB: &lt;nowiki&gt;http://as15133.peeringdb.com/&lt;/nowiki&gt;<br /> *Datacenters: Equinix-SP4, Equinix-RJ2<br /> ==== Netflix ====<br /> * Banda Mínima: 3 Gbps<br /> * Email: peering@netflix.com<br /> * Informações: https://openconnect.netflix.com/en/guidelines/<br /> * Datacenters: Equinix-SP2, Equinix-RJ1, NIC-JD, Commcorp Porto Alegre-PAE1, ETICE-Fortaleza<br /> * PeeringDB: https://www.peeringdb.com/net/457<br /> <br /> ==== Akamai ====<br /> * Banda Mínima: 5 Gbps<br /> * Email: netsupport-tix@akamai.com<br /> * Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp<br /> *PeeringDB: https://www.peeringdb.com/net/2<br /> *Datacenters: Equinix-SP4, Teleporto-RJ <br /> <br /> ==== Azion ====<br /> * Banda mínima: 5 Gbps<br /> * Email: peering@azion.com / noc@azion.com<br /> * Informações: https://www.azion.com.br/developers/peering/<br /> * Datacenters: Ascenty Campinas, Commcorp-BSA2, Commcorp-FNS1, Commcorp-PAE1, Equinix-SP3, Level 3 - Cotia, GVT - Curitiba, Globenet - Fortaleza, NIC-JD, PIX Adylnet-PAE, PIX G8 - São Paulo, PIX Vogel - Porto Alegre, Tascom - Salvador<br /> * PeeringDB: https://www.peeringdb.com/net/14511<br /> ==== Twitch TV ====<br /> * Banda mínima: 2.5 Gbps<br /> * Email: noc@twitch.tv / interconnection@twitch.tv<br /> * Contato: https://noc.twitch.tv/<br /> * Datacenters: Equinix-SP2, Level 3 - Cotia, Level 3 - Rio de Janeiro<br /> * PeeringDB: https://www.peeringdb.com/asn/46489<br /> ==== Globo ====<br /> * Email: peering@peering.globo<br /> * Informações: https://peering.globo<br /> * PeeringDB: https://www.peeringdb.com/net/5703<br /> * Locais: Rio de Janeiro: Jacarepaguá, São Paulo: Alameda Santos, Fortaleza: Datacenter Angola Cables<br /> [[Categoria:Interconexão]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Conteudos&diff=2501 2020-05-31T22:48:50Z

<p>Leonardo.furtado: </p> <hr /> <div>== Conteúdos para os Operadores de Redes ==<br /> [[Arquivo:Content-BW.png|commoldura]]<br /> Nesta página você encontrará os links para os diversos artigos, how-tos, tutoriais e vídeos produzidos no âmbito do BPF e direcionados à Comunidade de Internet Brasileira. O intuito é que eles sejam úteis para o dia a dia de operação de redes, infraestrutura, boas práticas e assuntos relacionados.<br /> <br /> Para escrever um novo artigo, how-to ou tutorial e compartilhá-lo é necessário criar antes um usuário na Wiki. Existe um artigo com orientações gerais sobre [[Como Escrever na Wiki]]. Após finalizar o artigo não esqueça de indexá-lo nesta página como também compartilhar conosco na lista de emails.<br /> <br /> Caso haja interesse em publicar algum material mais completo ou algum projeto envie um email para a lista de discussão geral abordando o assunto de interesse para verificar se já existe alguém o alguma Task Force trabalhando neste assunto ou ainda verifique se já existe algo mais específico em alguma das Task Forces temáticas. Toda contribuição da comunidade é bem vinda e incentivada.<br /> <br /> Para facilitar os artigos e materiais publicados abaixo são separados por assuntos.<br /> == Direitos Autorais, Licença de Uso e Termo de Responsabilidade ==<br /> Todos os conteúdos, contribuições e obras publicados pelo Brasil Peering Forum (BPF) estão licenciados com uma '''Licença Creative Commons Atribuição-NãoComercial 4.0 Internacional'''. Consulte o nosso [[Direitos Autorais Licenca de Uso|Termo de Responsabilidade]] para verificar a licença, os direitos e restrições de uso, assim como as devidas isenções de responsabilidades.<br /> <br /> == Artigos ==<br /> <br /> === Geral ===<br /> * [[Como Escrever na Wiki]] - Passo a Passo de como criar um novo artigo e contribuir com a Wiki do BPF.<br /> * [[Assinatura MoU BPF]] - Assinatura do Memorando de Entendimento entre os membros da Board e Comitê de Programa do BPF.<br /> * [[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]] - Aqui reunimos expressões, acrônimos e termos conhecidos referentes ao universo de telecomunicações e ISPs.<br /> <br /> === BCOPs ===<br /> * [[Boas Praticas para Melhorar a Seguranca de seu Provedor]]‎‎ - Boas práticas a serem seguidas para melhorar a segurança de seu Provedor.<br /> * [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] - Artigo que dissemina várias áreas de atenção e práticas para o aumento da segurança da rede do Provedor.<br /> * [[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]] - Artigo dissertativo sobre boas práticas para a escolha, adoção e manutenção de software de equipamentos de redes.<br /> * [[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]] - Artigo que apresenta boas práticas e sugestões para a documentação de ambientes de redes.<br /> * [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas praticas para a implantacão do OSPF em ambientes de ISP]] - Artigo discorrendo sobre 12 boas práticas em situações envolvendo OSPF em ambientes ISP.<br /> <br /> === Capacitação ===<br /> * [[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]] - Artigo didático que comenta boas práticas para ações de suporte na rede do ISP<br /> * [[Aprimorando a Disponibilidade da rede do ISP]] - Artigo com vídeo explicando os fundamentos de disponibilidade das infraestruturas de redes do provedor<br /> * [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]] - Artigo que destaca positivamente o eTOM BPF do Frameworx como conceito de remodelagem de operação e de negócios de ISPs<br /> <br /> === DNS ===<br /> * [[Porque usar um DNS local e algumas dicas para isto]] - Artigo explicativo das razões porque é uma boa prática para um ISP possuir servidores DNS Recursivos próprios do que direcionar o usuário para um servidor público.<br /> * [[DNSSEC Seguranca do DNS|DNSSEC - Seguranca do DNS]] - Artigo conceitual explicando o funcionando do DNSSEC baseado no documento DNSSEC: Securing DNS publicado pela ICANN.<br /> <br /> === Infraestrutura ===<br /> * [[Compatibilidade de GBICs e Cabos Twinax|Compatibilidade de GBICs e cabos Twinax]] - Banco de dados colaborativo sobre experiências de uso de GBICs e cabos Twinax em Roteadores e Switches<br /> * [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]] - Artigo um tanto extenso e completo cobrindo os fundamentos de programabilidade de redes<br /> <br /> === Interconexão ===<br /> * [[Modelos Interconexão]] - Artigo sobre os modelos de interconexão Peering e Trânsito<br /> * [[Looking Glass]] - Artigo com uma lista de Looking Glass nacionais e internacionais<br /> * [[CDN Peering e PNI - Brasil]] - Lista com as principais CDNs, instruções de como solicitar Servidores, Sessões Bilaterias no IX e PNIs.<br /> <br /> === Roteamento ===<br /> * [[Dimensionando Roteador para BGP]] - Considerações a serem levadas em conta ao adquirir um novo Roteador para BGP<br /> * [[Engenharia de Trafego com MPLS TE]]‎ - Artigo explicando o funcionamento do MPLS com Traffic Engineering<br /> * [[Balanceamento de Trafego em Redes MPLS]] - Artigo explicando o funcionamento de distribuição de tráfego em redes MPLS<br /> * [[Redes MPLS para Provedores]] - Artigo explicando as vantagens e benefícios de infraestruturas do provedor baseadas no MPLS<br /> * [[Fundamentos de Roteamento para Provedores]] - Artigo explorando os fundamentos de funções de Camadas 2 e 3, comutação e roteamento, em redes Ethernet IP para provedores<br /> * [[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]] - Artigo explicando as necessidades e opções para a proteção e resiliência de redes Ethernet para provedores<br /> * [[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]] - Artigo abordando as tecnologias 6PE e 6VPE em regime BGP Free Core com MPLS TE. Inclui vídeos demonstrativos<br /> * [[Introducao ao Unified MPLS|Introdução ao Unified MPLS]] - Artigo explicando a adoção do MPLS em infraestruturas de redes de grandes operadores. Inclui vídeo demonstrativo<br /> * [[Lista de Communities BGP]] - Listagem com as Communities disponibilizadas pelos principais Operadores de Trânsito IP e Internet Exchanges<br /> * [[Diferenca entre AS-OVERRIDE e ALLOWAS-IN]] - Explicação básica sobre a diferença entre os dois mecanismos anti-loop do protocolo BGP<br /> * [[Construção de Redes de Gerenciamento OOB para o ISP]] - Artigo dissertativo sobre conceitos de gerenciamento e redes Fora-de-Banda (OOB)<br /> * [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]] - Artigo explicando muitas das diferenças entre as soluções L2VPN MPLS tradicionais e o Ethernet VPN. Inclui vídeos demonstrativos<br /> * [[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]] - Artigo bem dissertativo de conceitos fundamentais que todo profissional de ISP precisa saber a respeito do BGP<br /> * [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]] - Artigo bastante didático e esclarecedor sobre as tecnologias e ferramentas para o QoS.<br /> * [[O Minimo que voce precisa saber sobre DDoS]] - Artigo explicando diferenças entre ataques DDoS e maneiras de se prevenir e mitigar.<br /> * [[Redes que descartam RPKI Invalidos]] - Uma introdução rápida ao RPKI além de listar as operadoras e provedores de trânsito Internet que já implementam o descarte de prefixos inválidos.<br /> * [[O Minimo que Voce precisa saber sobre IRR]] - Artigo explicando o que é IRR, a importância do uso, principais bases e com um tutorial de como adicionar informações em uma base.<br /> * [[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]] - Artigo bastante completo dissertando sobre o gerenciamento e monitoramento do BGP em um Sistema Autônomo.<br /> <br /> === Transmissão ===<br /> * [[Sistemas DWDM de Baixo Custo]] - Artigo explicado sobre como projetar um sistema DWDM de baixo custo.<br /> <br /> == How-tos e Tutoriais ==<br /> <br /> === Geral ===<br /> * [[Como reportar abusos ao Google]] - Instruções sobre como reportar servidores com conteúdos maliciosos hospedados pelo Google.<br /> * [[Como configurar o Winbox no MacOS Catalina]] - Tutorial sobre como executiar o Winbox em 64Bits no MacOS Catalina.<br /> <br /> === Boas Práticas ===<br /> * [[Boas práticas de segurança para roteadores Mikrotik]] - How-to com orientações de segurança e regras a serem aplicadas em roteadores Mikrotik rodando RouterOS.<br /> * [[Como consultar e corrigir a geolocalizacao de seus IPs|Como Consultar e Corrigir a Geolocalização de IPs]] - Tutorial explicando como consultar e corrigir as informações de geolocalização de alocações de um ASN.<br /> * [[MANRS]] - Passo a passo de como cumprir todos os requisitos do MANRS e para se ter um Sistema Autônomo e uma Internet mais segura.<br /> * [[PeeringDB - como se cadastrar e atualizar seus dados|PeeringDB - Como se cadastrar e atualizar seus dados]] - Passo a passo de como realizar o cadastro no PeeringDB e preencher as informações necessárias.<br /> <br /> === DNS ===<br /> * [[Melhorando a performance e resiliencia da rede com Recursive DNS Anycast|Melhorando a performance e resiliência da rede com Recursive DNS Anycast]] - Tutorial que apresenta uma técnica interessante para maior disponibilidade e desempenho dos servidores DNS para os provedores.<br /> <br /> === Edge ===<br /> * [[Concentradores PPPoE com IPv6]] - Como habilitar suporte a IPv6 e distribuição de prefixos para usuários finais em diferentes concentradores.<br /> <br /> === Infraestrutura ===<br /> * [[Log de Portas de Origem em Servidores Web]] - Como adicionar a porta de origem ao log dos Servidores Web e ser capaz de identificar usuários atrás de CGNAT.<br /> * [[CGNAT na pratica|CGNAT na prática]] - Tutorial sobre como configurar um servidor Linux com netfilter para CGNAT com ajustes de configurações voltadas para performance.<br /> * [[Tutorial DNS Hyperlocal]] - Tutorial descrevendo como hospedar uma cópia da zona raiz de DNS para que os servidores Recursivos locais possam consultar com maior performance e eficiência.<br /> * [[Monitoramento-telegraf|Monitoramento Telegraf]] - Como configurar uma solução Telegraf + InfluxDB + Grafana para monitoramento via ICMP de destinos desde diferentes endereços de origem.<br /> * [[Como Ter Seu Proprio Looking Glass|Como Ter Seu Próprio Looking Glass]] - Tutorial ensinando como o ISP poderá facilmente disponibilizar seu próprio Looking Glass para visibilidade e suporte à problemas com o BGP.<br /> * [[Como capturar pacotes no Mikrotik]] - Tutorial ensinando como realizar captura de pacotes no Mikrotik visando a análise e depuração de protocolos e conversações.<br /> * [[Como Monitorar 95th percentile]] - Tutorial demonstrando como monitorar tráfego 95th percentile para cobrança de clientes e possibilidade de exportar dados através de um script.<br /> * [[Orquestrando sua rede com Ansible e Gitlab]] - Tutorial ensinando a utilizar modelos de dados, em uma estrutura CI/CD com Ansible e GitLab.<br /> * [[464XLAT utilizando a ferramenta Jool]] - Tutorial sobre como configurar um ambiente utilizando o mecanismo de transição 464XLAT com a ferramenta Jool.<br /> * [[CGNAT com F5 BIG-IP]] - Tutorial de apresentação e demonstração da solução de CGNAT com a plataforma F5 BIG-IP.<br /> <br /> === IPv6 ===<br /> * [[IPv6 no TPLink WR840N v2]] - Como ativar IPv6 na CPE TPLink WR840N v2<br /> * [[IPv6 na ONU Huawei HS8546 v2]] - Como ativar IPv6 na ONU Huawei HS8546 v2<br /> * [[IPv6 no Mikrotik CPE]] - Como ativar IPv6 em uma CPE Mikrotik (RouterOS)<br /> * [[IPV6 no Ubiquiti AirOS6|IPv6 no Ubiquiti AirOS6]] - Como ativar IPv6 em uma CPE Ubiquiti com AirOS6<br /> * [[IPV6 no Ubiquiti AirOS8|IPv6 no Ubiquiti AirOS8]] - Como ativar IPv6 em uma CPE Ubiquiti com AirOS8<br /> * [[Ipv6-TL-WRN849N|IPv6 no TPLink WRN849N]] - Como ativar IPv6 em uma CPE TPLink WRN849N<br /> * [[IPV6 no Intelbras Wom|IPv6 no Intelbras WOM]] - Como ativar IPv6 em uma CPE Intelbras WOM 500, WOM 5000 MIMO, WOM 5a-23 e WOM 5a MIMO<br /> * [[IPv6 no Dlink Dir-615|IPv6 no Dlink DIR 615]] - Como ativar IPv6 em uma CPE Dlink DIR 615, DIR 608, DIR 610 e DIR 611<br /> * [[IPV6 no DLINK DIR-882|IPv6 no D-Link DIR-882]] - Como ativar IPv6 em uma CPE D-Link DIR-882<br /> * [[Acesso via IPv6 Link-Local]] - Uma maneira de acessar equipamentos via IPv6 Link-Local em caso de perda de conectividade por IPv4<br /> * [[Como Ativar IPv6 em Servicos de Hosting e CDN]] - Tutorial sobre como ativar IPv6 nos serviços de Hosting e CDN mais utilizados<br /> * [[Servidor DNS Recursivo com IPV6 e DNSsec]]- Mini tutorial sobre IPv6 e DNSsec em DNS recursivo Unbound.<br /> * [[Gerando Log de IPv6 Delegation no Mikrotik]] - How to explicando como registrar em um servidor Syslog o Prefixo IPv6 entregue para o usuário em concentradores Mikrotik<br /> <br /> === Interconexão ===<br /> * [[Ajustes de ARP Cache para o IX]] - Tutorial explicativo da problemática do ARP cache e comandos para serem aplicados em múltiplos vendors para melhor operação no IX.<br /> <br /> === Roteamento ===<br /> * [[Como fazer com que um determinado conteudo saia por um link especifico|Como fazer com que um determinado conteúdo saia por um link específico]] - Tutorial bem objetivo ensinando como manipular o roteamento para o recebimento de tráfego em seu AS<br /> * [[Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei|Configuração de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei]] - Tutorial sobre como configurar filtros usando XPL em Huawei<br /> * [[UTRS Registro e Configuracao|UTRS - Registro e Configuração]] - Artigo que explica o funcionamento do serviço UTRS do Team Cymru, passo a passo para solicitação e configurações exemplo.<br /> * [[Protegendo seu ASN com RPKI]] - Tutorial que ensina como implementar o Krill para habilitar e autorizar o ROA para o seu ASN.<br /> <br /> == Tech Notes ==<br /> Esta seção contém contribuições fornecidas por fabricantes (&quot;''vendors''&quot;) acerca de suas soluções, tecnologias disponíveis, diferenciais de mercado e afins.<br /> * [[Otimizacao de balanceamento de tráfego em Link Aggregation utilizando DLB e FAT em switches Datacom|Otimização de balanceamento de tráfego em Link Aggregation utilizando DLB &amp; FAT em switches Datacom]] - Artigo dissertativo acerca das soluções DLB e FAT do portfólio de switches da Datacom<br /> <br /> == Informativos ==<br /> Os informativos do Brasil Peering Forum são editados de forma quinzenal, dependendo do conteúdo e relevância e contém as principais notícias e novidades do mercado de Infraestrutura de Telecom e Internet.Todos eles são também enviados para a [https://listas.brasilpeeringforum.org/mailman/listinfo/bpf Lista Pública de Discussão] do BPF. Inscreva-se para receber as notificações.<br /> * [[Informativo Infra 01]] - 16/09/2019<br /> * [[Informativo Infra 02]] - 22/09/2019<br /> * [[Informativo Infra 03]] - 25/10/2019<br /> * [[Informativo Infra 04]] - 04/11/2019<br /> * [[Informativo Infra 05]] - 17/11/2019<br /> * [[Informativo Infra 06]] - 02/12/2019<br /> * [[Informativo Infra 07]] - 29/12/2019<br /> * [[Informativo Infra 08]] - 26/01/2019<br /> * [[Informativo Infra 09]] - 16/02/2020<br /> * [[Informativo Infra 10]] - 09/03/2020<br /> <br /> == Vídeos ==<br /> === Capacitação ===<br /> * [https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP], por Leonardo Furtado<br /> * [https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP], por Leonardo Furtado<br /> * [https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP], por Leonardo Furtado<br /> === Eventos ===<br /> * [https://www.youtube.com/watch?v=KG2JZ0A_9yY Painel sobre Peering ocorrido durante o Future ISP em Maio de 2018]<br /> * [https://www.youtube.com/watch?v=8GVHB52qu5k Apresentação do Brasil Peering Forum feita por Uesley Correa]<br /> * [https://www.youtube.com/watch?v=SE8YEuVXMWQ Dever de Casa e o Impacto da Negligência Técnica e Administrativa de Participantes do IX-BR], por Elizandro Pacheco no IX Forum 12<br /> * [https://www.youtube.com/watch?v=2oq7pMBF7Oc Tudo que você gostaria de saber sobre transmissões ópticas e WDM], por Tiago Setti no IX Forum 12<br /> * [https://www.youtube.com/watch?v=Obh98S5xyQA Automatização de Listas de Prefixos em Peering BGP - Como fazer e sua importância], por Douglas Fischer no GTER 46<br /> * [https://www.youtube.com/watch?v=hbEC2Sf5o20 BIER: Evolução do IP Multicast, por Tiago Setti] no GTER 46<br /> * [https://www.youtube.com/watch?v=H-m0sKr8I0Q Problemas e soluções na identificação de usuário IPv6 usando RouterOS], por Uesley Correa no GTER 46<br /> * [https://www.youtube.com/watch?v=WjSps5huDGU Painel - Trânsito Burstable com 95th] percentil, por Fernando Frediani, Fábio Monteiro, Edivan Silva e Tiago Setti no GTER 46<br /> * [https://www.youtube.com/watch?v=4-77r2PGKB4 BSDRP - Uma opção de softrouter com FRR], por Antonio Donizeti Corazza Jr no GTER 46<br /> * [https://www.youtube.com/watch?v=CjTcI0-UApI Ataques DDoS como ação anti-competitiva: prevenção, mitigação e reação], por Thiago Ayub no GTER 46<br /> * [https://youtu.be/qBD7zCnbTF4 Automatização de Listas de Prefixos em peering BGP], por Douglas Fischer no LACNIC 31/FTL<br /> * [https://youtu.be/8DdtN_fj_uQ BSDRP - Uma opção de sofftrouter com FRR], por Junior Corazza no LACNIC 31/FTL<br /> * [https://www.youtube.com/watch?v=utPs-sXsOZg A importância de um CGNAT bem feito], por Fernando Frediani no GTER 47<br /> * [https://www.youtube.com/watch?v=l2tVyz1Ba1A Entrevista sobre ataques e mitigação DDoS], com Thiago Ayub<br /> * [https://youtu.be/ElA_71zsc6Y Entrevista com o Carlos Martínez sobre RPKI], com Carlos Martínez, CTO do LACNIC, na 9a Semana de Infraestrutura da Internet no Brasil.<br /> <br /> === Hangouts ===<br /> [https://www.youtube.com/watch?v=fy4efZZ-yvg Desmistificando o CGNAT] - Hangout realizado para debater o assunto e desmistificar esta necessidade dos ISPs. Durante a conversa foram abordadas boas práticas, diferentes modelos de CGNAT, problemas com Jogos e um case prático.<br /> <br /> [https://www.youtube.com/watch?v=ePMfMv3UVOs Boas Práticas de DNS] - Hangout realizado que debateu as melhores práticas para se ter um bom serviço de DNS rodando no seu provedor, a importância de ter seu DNS Reverso configurado corretamente, quando é necessário ter um servidor Autoritativo, DNSSEC e assuntos relacionados.<br /> <br /> === Roteamento e MPLS ===<br /> * [https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores], por Leonardo Furtado<br /> * [https://www.youtube.com/watch?v=5Eg5jC2AMaQ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Parte 1] (Introdução), [https://www.youtube.com/watch?v=W8HS_y7REiM Parte 2] (Introdução ao L3VPN), [https://www.youtube.com/watch?v=TqdZYK_9rlY Parte 3] (Demonstração de Interconexões com L3VPN MPLS), [https://www.youtube.com/watch?v=bmgWGOPbkfw Parte 4] (Demonstração da Solução Carrier Supporting Carrier - (CsC)), [https://www.youtube.com/watch?v=H4SyKiGBOXM Parte 5] (Demonstração de L3VPN MPLS com VPNs &quot;Complex Overlapping&quot;), [https://www.youtube.com/watch?v=6fQ34nnk-Dk Parte 6] (Demonstração de L2VPN MPLS com AToM/EoMPLS/VPWS), por [[Usuário:Leonardo.Furtado|Leonardo Furtado]].<br /> * [https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE], por Leonardo Furtado.<br /> * [https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1] e [https://youtu.be/0N-ejxGncSU Parte 2], por Leonardo Furtado.<br /> * [https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS], por Leonardo Furtado.<br /> * [https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN], por Leonardo Furtado.<br /> * [https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP, da Comunidade de Suporte Cisco em Português], por Leonardo Furtado.<br /> * [https://youtu.be/zSiFtIgT1Ig Palestra de Evoluções de Tecnologias MPLS com Segment Routing e EVPN] - Future ISP 2018, por Leonardo Furtado.<br /> * [https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing, da Comunidade de Suporte Cisco em Português], por Leonardo Furtado<br /> * [https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP], por Leonardo Furtado<br /> * [https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP], por Leonardo Furtado<br /> * [https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)], por Leonardo Furtado</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Boas_praticas_para_a_implantacao_do_ospf_em_ambientes_de_isp&diff=2500 2020-05-31T02:39:02Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Boas Práticas para a Implantação do OSPF em Ambientes de ISP ===<br /> <br /> ==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> <br /> === Introdução ===<br /> Este artigo trata única e exclusivamente do tema OSPF, e pouco será discutido acerca de conceitos de roteamento e outros pré-requisitos para a compreensão e configuração do OSPF. Ou seja, para este artigo, estou assumindo que você já seja um profissional de redes e com alguma prática na configuração e suporte do OSPF, assim como de outros serviços e protocolos de roteamento IPv4 e IPv6.<br /> <br /> Para constar, o OSPF é um daqueles componentes de seu projeto técnico que, se você fizer a coisa certa, muito raramente experimentará qualquer tipo de problema. Quando adotando as boas práticas sugeridas por este artigo, será o tipo de protocolo ou serviço em que configura-se, literalmente, apenas uma única vez, e para não aborrecer-se mais!<br /> <br /> Caso você tenha muitas &quot;lacunas&quot; sobre questões mais fundamentais relacionadas a redes no geral, recomendo a leitura do seguinte artigo: [[Fundamentos de Roteamento para Provedores]].<br /> <br /> Em tempo, este artigo dissemina boas práticas para um conjunto contendo 12 (doze) situações envolvendo o OSPF em ambientes de ISP:<br /> # '''''Mantenha o OSPF dedicado apenas para os prefixos internos da rede do ISP:''''' recomenda-se que toda e qualquer rota representando redes externas ou redes de cliente sejam mantidas pelo BGP, e não pelo IGP.<br /> # '''''Opte por um projeto de rede Ethernet/IP hierárquico, estruturado e modular:''''' por inúmeras razões, incluindo o melhor funcionamento do OSPF, recomendamos esta prática.<br /> # '''''Elabore um plano de endereçamento IPv4 e IPv6 adequado para acomodar as interfaces Loopback e os links internos da sua rede:''''' por diversas razões e não somente por causa do OSPF!<br /> # '''''Configure os enlace físicos ponto a ponto como redes OSPF ponto-a-ponto:''''' uma simples e boa prática que traz benefícios para a formação de adjacências e manutenção de LSDBs mais enxutos.<br /> # '''''Configure corretamente a banda de referência do OSPF para evitar problemas com a derivação de custos de interfaces OSPF:''''' uma boa prática para evitarmos problemas com roteamento subótimo no AS.<br /> # '''''A sumarização de rotas OSPF é um recurso, mas tenha cuidado com os problemas quanto a esta prática em redes MPLS'':''' a sumarização de rotas OSPF tem prós e contras, dependendo do tipo de ambiente.<br /> # '''''Saiba quando e onde implementar Áreas especiais do OSPF'':''' conhecer com mais detalhes as áreas especiais poderá viabilizar projetos com necessidades mais específicas.<br /> # '''''Evite o uso de Virtual-Links:''''' embora historicamente exigido em alguns projetos e ocasiões, recomenda-se evitar este recurso nos projetos de infraestrutura, principalmente quando a rede foi bem construída.<br /> # '''''Sempre que possível, opte por um protocolo IGP que não seja o OSPF para clientes L3VPN MPLS'':''' o OSPF é maravilhoso para o roteamento IGP do AS, mas muito burocrático quando operando na relação PE-CE.<br /> # '''''Proteja o seu OSPF contra determinados riscos de segurança'':''' recomenda-se a adoção de boas práticas para proteger o seu OSPF, assim como os demais componentes do plano de controle.<br /> # '''''Opte por soluções mais apropriadas para engenharia de tráfego, evitando manipulações frequentes da métrica do OSPF'':''' há formas mais interessantes, flexíveis e bem menos engessadas para estas necessidades.<br /> # '''''Ferramentas adicionais para o &quot;ajuste fino&quot; do OSPF (IP Event Dampening, LSA/SPF Throttling, BFD)''''': o OSPF poderá receber auxílio de recursos adicionais para maior estabilidade e escalabilidade. <br /> Aprecie a leitura sem moderação![[Arquivo:Bpf-ospf-1.png|centro|miniaturadaimagem|900x900px|Boas Práticas para a Implantação do OSPF em Ambientes de ISP]]<br /> <br /> === Dissertação sobre as boas práticas para o OSPF em infraestruturas de redes de ISPs ===<br /> Esta seção do artigo destacará cada uma das 12 situações ou áreas de interesse sobre o tema de boas práticas para o OSPF em ambientes de ISP. <br /> <br /> ==== Mantenha o OSPF dedicado apenas para os prefixos internos da rede do ISP ====<br /> No que diz respeito às boas práticas para projetos de redes em ISP, toda e qualquer rota IGP oriunda de um protocolo de roteamento dinâmico - e isto obviamente inclui o OSPF - ou de rotas estáticas, deve servir apenas para quatro propostas primárias:<br /> # Transportar as sessões IBGP entre os roteadores participantes no AS.<br /> # Fornecer a devida conectividade para o endereço IP especificado pelo atributo NEXT_HOP das rotas BGP mantidas no seu sistema autônomo (AS). Ou seja, para fins de roteamento recursivo.<br /> #* A conectividade para este endereço IP (NEXT_HOP) precisa ser o mais eficiente e otimizada possível, podendo seguir integralmente pelo processo de seleção de caminhos do OSPF ou por túneis de engenharia de tráfego (MPLS TE), ou por policies de engenharia de tráfego (SR-TE).<br /> # Fornecer o roteamento unicast necessário para o transporte das sessões LDP entre os roteadores participantes, no caso de ambientes MPLS.<br /> # Fornecer conectividade para serviços internos específicos do próprio ISP.<br /> Qualquer coisa fora disto é gambiarra ou fora das boas práticas. A título de boas práticas, para constar, rotas de trânsito, peering e de qualquer outra coisa externa deve ser provida pelo BGP, e &lt;u&gt;não&lt;/u&gt; pelo OSPF, assim como rotas de clientes do ISP, as quais, também, devem ser rotas mantidas pelo BGP! Isto significa que você jamais deverá permitir no seu projeto que rotas de clientes sejam IGP na sua tabela de roteamento global ou que compartilhem o mesmo processo de roteamento que mantém toda a conectividade IGP do seu backbone! É viável usar o OSPF com clientes, no entanto, apenas em setups de L3VPN MPLS, ou seja, em VRFs dedicadas para clientes, numa relação chamada &quot;PE-CE&quot;, e em combinação com MP-BGP no seu backbone para as famílias de endereços VPNv4 e VPNv6. Isso será discutido mais a frente.<br /> <br /> De antemão já condeno uma prática que vejo muito por aí em ambientes ISP:<br /> Com relação aos assinantes PPPoE, as rotas /32 correspondentes a estes assinantes autenticados em um concentrador BNG/BRAS também não podem existir como rotas IGP na sua rede. Não faça isso! Aliás, para que injetar milhares de prefixos /32, sabendo que autenticações ocorrem a todo o instante e que isto provocará recomputações incessantes sobre o LSDB de seus roteadores? <br /> <br /> O que você poderia fazer ou considerar neste caso:<br /> <br /> 1) Agregar todo o bloco que corresponde aos assinantes autenticados em um concentrador BNG/BRAS (ex: um /22) em uma rota estática apontando para ''Null0,'' juntamente com um ''tag'' específico sobre esta rota estática, indicando uma ação para fins de redistribuição, e, em seguida, redistribuir esta rota estática que contém este ''tag'' para o OSPF como ''External Type-1'', sem complicações.<br /> <br /> 2) Ou, alternativamente, fazendo a mesma coisa, só que redistribuindo para o BGP ao invés do OSPF. Isto é, se o seu concentrador estiver rodando BGP em adição ao serviço BNG (PPPoE).<br /> <br /> &lt;u&gt;As consequências quanto ao não cumprimento desta boa prática:&lt;/u&gt; rotas de clientes na sua tabela de roteamento como IGP poderão representar uma ameaça nas questões de segurança e disponibilidade da sua rede, além de instabilidades e certas dificuldades quanto a convergência da rede. Em adição, o inconveniente elevado aumento de processamento decorrente de computações frequentes e excessivas do LSDB dos roteadores. E, por último, o excesso de rotas IGP que poderá estourar os limites estabelecidos pelas arquiteturas dos seus equipamentos.<br /> <br /> Só para constar: protocolos de roteamento interiores (IGP) não escalam massivamente como o BGP. O limite máximo recomendado pela indústria é de 40 mil rotas IGP na tabela de roteamento, mesmo que o seu roteador suporte 10 milhões de prefixos numa FIB em hardware.<br /> O diagrama mostrado a seguir destaca esta boa prática, que é a de deixar o OSPF dedicado somente para o atendimento das quatro situações discutidas acima.<br /> [[Arquivo:Bpf-ospf-2.png|centro|miniaturadaimagem|1024x1024px|Diagrama ilustrando o OSPF dedicado para os links internos e loopbacks dos roteadores do ISP]]<br /> <br /> ==== Opte por um projeto de rede Ethernet/IP hierárquico, estruturado e modular ====<br /> Em tese, você poderia interconectar os seus roteadores e switches do jeito que você desejasse em sua rede, e isto é uma grande verdade. No entanto, o arranjo topológico desorganizado e sem sentido de uma rede tende a incorrer em alguns indesejáveis desafios, além de introduzir impactos desnecessários sobre o funcionamento de determinados componentes lógicos especificados pelo seu projeto técnico. O bom funcionamento dos protocolos de roteamento IGP, em particular no caso do OSPF aqui, exige algumas definições hierárquicas da topologia da rede.<br /> <br /> Talvez você não saiba, mas o OSPF é disparado o protocolo de roteamento mais exigente em termos de organização topológica, pois, ao contrário dos demais protocolos, a sua abordagem em projetos de múltiplas áreas obriga o estabelecimento de uma hierarquia de dois níveis para o seu funcionamento. Esta hierarquia de dois níveis não é opcional em projetos com múltiplas áreas OSPF: é mandatório!<br /> <br /> O que seria um projeto de rede hierárquica + estruturada + modular? As famosas &quot;camadas de função&quot;, tais como ''Acesso'', ''Pré-Agregação'', ''Agregação'', ''Core'' e ''Borda de Serviços''. Não, não são apenas nomes bonitos! Cada camada corresponde a conjuntos de especificações tecnológicas que ditam a padronização de funcionalidades/recursos que deverão operar naquela camada, assim como a concepção de arquitetura e plataforma de hardware e software a serem empregados em cada uma destas camadas. <br /> <br /> Dependendo do tamanho do seu ISP, uma única área OSPF poderá ser considerada para todo o projeto. No entanto, na medida em que a sua rede for crescendo, a necessidade pelo estabelecimento do OSPF em múltiplas áreas será cada vez mais exigida, e, nestas horas, uma rede com boa apresentação e estruturação hierárquica fará toda a diferença para os resultados almejados.<br /> <br /> &lt;u&gt;As consequências quanto ao não cumprimento desta boa prática:&lt;/u&gt; inabilidade de sumarizar apropriadamente as rotas OSPF, consequentemente estruturas de dados (LSDB e RIB) ficarão mais inchadas; excesso de &quot;falatório&quot; (distribuição de LSAs), impactos mais perceptíveis ou prolongados relacionados aos eventos de convergência da rede, especialmente quando ocorrerem oscilações dos links internos da rede, e você não conseguirá escalar tão bem quanto um projeto OSPF mais organizado neste sentido.<br /> <br /> Mais do que ajudar o OSPF a fazer um bom trabalho: um projeto de redes adequado e com uma abordagem hierárquica promove muitos benefícios para diversos dos recursos lógicos e serviços da infraestrutura, além de facilitar muito a vida dos times de operações da rede! A ilustração a seguir mostra estas camadas, exemplifica algumas de suas funções, e destaca os principais benefícios desta abordagem:<br /> [[Arquivo:Bpf-ospf-3.png|centro|miniaturadaimagem|1092x1092px|Diagrama ilustrativo sobre um projeto de rede hierárquica e exemplos de funções prestadas por cada camada]]<br /> <br /> ==== Elabore um plano de endereçamento IPv4 e IPv6 adequado para acomodar as interfaces Loopback e os links internos da sua rede ====<br /> Um plano de endereçamento IP hierárquico, adequado e eficiente, resolverá muitos dos desafios introduzidos pelos próprios protocolos de roteamento IGP, principalmente no que diz respeito à escalabilidade, tempo de convergência, e à estabilidade da infraestrutura. O endereçamento IP precisa ser bem &quot;encaixado&quot; sobre a topologia da rede, e isto será um alívio para quando você precisar crescer com a rede usando o OSPF em múltiplas áreas, dentre outras necessidades e situações.<br /> <br /> Um plano de endereçamento IP mal projetado e mal distribuído sobre os roteadores e enlaces da rede poderá resultar em complicações em diversas situações. Uma delas tem relação com a agregação ou sumarização de rotas do OSPF, pois este protocolo de roteamento é um tanto burocrático em alguns de seus recursos e facilidades. Para exemplificar, no OSPF é possível sumarizar rotas &lt;u&gt;somente&lt;/u&gt; nas seguintes circunstâncias:<br /> # Sumarização de rotas OSPF no roteador de borda de área (''Area Border Router'' ou ABR): rotas nativas do OSPF só podem ser sumarizadas nos roteadores ABR!<br /> # Sumarização de rotas externas injetadas pelo roteador de borda de sistema autônomo (''Autonomous System Boundary Router'' ou ASBR): no ponto de redistribuição de rotas de outros protocolos ou domínios de roteamento, ou seja, no roteador ASBR, é possível, no momento da redistribuição, fazer a sumarização destas rotas externas redistribuídas para o OSPF.<br /> Isto significa que:<br /> <br /> a) Se a sua rede consistir de uma única área OSPF, não será possível sumarizar rotas OSPF nativas. Isto porque roteadores ABR só existem, obviamente, em projetos OSPF com duas ou mais áreas (multiárea).<br /> <br /> b) Mesmo que a sua rede OSPF seja multiárea, se você foi negligente com a alocação e distribuição dos endereços IP, você será incapaz de sumarizar as rotas OSPF conforme desejado, ou, então, será completamente incapaz de fazê-lo.<br /> <br /> Recomenda-se equipar o seu ISP com um bom software de IPAM para projetar os blocos com bastante atenção e prevendo o crescimento ou a expansão da rede. Por exemplo:<br /> * Projete o endereçamento IPv4/IPv6 da sua rede para ser o mais compatível e hierárquico possível com relação à topologia da sua rede! O &quot;encaixe&quot; precisa ser próximo do perfeito!<br /> * Elabore o seu plano de endereçamento prevendo cenários de expansão de longo prazo.<br /> * Separe um bloco contínuo e bem confortável de endereços IPv4 e IPv6 para atender as interfaces Loopback dos roteadores.<br /> * Separe um bloco contínuo e bem confortável de endereços IPv4 e IPv6 por área para atender as interfaces dos links ponto a ponto da rede.<br /> ** Por mais que você hoje não tenha múltiplas áreas, busque promover esta antecipação de cenário futuro.<br /> * Separe um bloco contínuo e bem confortável por área de endereços IPv4 e IPv6 por área para endereçar outras partes internas, não ponto a ponto, de sua infraestrutura.<br /> Mesmo que você &lt;u&gt;não&lt;/u&gt; vá implementar a sumarização de suas rotas de sua infraestrutura, pois prefere optar por outros mecanismos para a atenuação da inundação frequente de LSAs e ciclos de processamento SPF sobre o LSDB, algo que será discutido posteriormente, neste artigo, é extremamente recomendado que você tenha um eficiente e bem alocado plano de endereçamento IP.<br /> <br /> ==== Configure os enlace físicos ponto a ponto como redes OSPF ponto-a-ponto ====<br /> Uma &quot;mexida&quot; um tanto sutil e que, aparentemente, não faz muita diferença para os projetos com o OSPF. Mas não deixa de ser aquela história que &quot;''a soma de pequenas iniciativas promove grandes resultados''&quot;.<br /> <br /> Resumindo: recomenda-se configurar o OSPF para tratar as interfaces Ethernet físicas ou lógicas (incluindo interfaces VLAN e similares) como &quot;''point-to-point''&quot; (ponto-a-ponto), ao invés do padrão &quot;''Broadcast''&quot;. Há regras para isto. Consulte a tabela a seguir:<br /> {| class=&quot;wikitable&quot;<br /> |+&quot;Network Types&quot; do OSPF<br /> !Network Type<br /> !Descrição<br /> !Exemplos<br /> |-<br /> |'''Broadcast   ''' <br /> |• Uma rede ''multiaccess'' broadcast. Aqui há a expectativa que dois ou mais roteadores rodando o OSPF sejam vizinhos através da mesma subrede IP.<br /> • Por este motivo, é mandatório a presença de um roteador designado (''Designated Router'' ou DR), e, recomendado, ocorrendo naturalmente, do roteador designado de backup (BDR).<br /> |Todas as redes Ethernet, incluindo interfaces L3 ou virtuais L3 (VLAN, SVI, BVI, BDI, etc.).<br /> <br /> '''&lt;u&gt;A proposta (boa prática) sugerida por este artigo:&lt;/u&gt;'''<br /> <br /> Mantermos como redes &quot;Broadcast&quot; somente aquelas onde de fato possuírem mais de dois roteadores e que devam formar adjacências OSPF entre si através de uma mesma subrede IP.<br /> |-<br /> |'''Point-to-point'''<br /> |• Uma rede que une um par de roteadores. Aqui assumimos que a conexão física ou lógica vá atender a comunicação entre apenas dois roteadores, e não mais que isto.<br /> • Por este motivo, não são requeridos as funções DR / BDR para este segmento.<br /> |Originalmente prevendo enlaces Seriais usando PPP, HDLC.<br /> <br /> '''&lt;u&gt;A proposta (boa prática) sugerida por este artigo:&lt;/u&gt;'''<br /> <br /> Se a conexão física for Ethernet (ex: um enlace de fibra) e conectar apenas dois roteadores, por que não definir as interfaces envolvidas nesta conexão como '''''point-to-point''''' ?<br /> <br /> Neste caso, modificaríamos o tipo de rede OSPF destes enlaces de &quot;''Broadcast''&quot; para &quot;''Point-to-Point''&quot;!<br /> <br /> '''Benefícios:'''<br /> <br /> a) Eliminará a necessidade de eleição de roteadores DR e BDR, o que economizará, mesmo que discretamente, o tempo requerido para a formação da vizinhança (adjacência) completa.<br /> <br /> b) Cada enlace físico ponto a ponto que for configurado como rede OSPF ''point-to-point'' resultará em uma entrada a menos no banco de dados (LSDB) dos roteadores da Área OSPF.<br /> <br /> • O LSA Type 2 (''Network LSA)'' é produzido somente pelos roteadores designados (DR). Cada DR numa rede produz uma entrada de LSA Type 2 no LSDB da área onde a interface do DR residir.<br /> <br /> • Ao eliminarmos os roteadores DR das áreas da nossa rede OSPF, melhoraremos um pouquinho os tempos de formação de vizinhanças entre os roteadores, além de podermos reduzir um tanto do tamanho do LSDB de cada área, em caso de redes grandes!<br /> <br /> • O exposto acima diminuirá o tamanho do LSDB de cada área, o que, por sua vez, resultará em menor esforço por parte dos roteadores para a realização das computações devidas, reduzirá um pouco o volume de propagação de LSAs, e deverá ainda melhorar o tempo de convergência geral da rede.<br /> |-<br /> |'''Nonbroadcast multiaccess (NBMA)'''<br /> |• Uma rede que interconecta mais de dois roteadores, mas que, ao mesmo tempo, esta rede não possui capacidade de transmissão broadcast (as mensagens broadcast e multicast não são recebidas por todos os roteadores).<br /> • A presença de roteadores DR / BDR poderá ou não ser requerida.<br /> <br /> • Há cinco modos de operação OSPF disponíveis para redes NBMA:<br /> <br /> • Modos RFC-compliant:<br /> <br /> • non-broadcast<br /> <br /> • point-to-multipoint<br /> <br /> • Modos proprietários Cisco (consulte o seu ''vendor'' sobre o que é suportado aqui):<br /> <br /> • broadcast<br /> <br /> • point-to-multipoint non-broadcast<br /> <br /> • point-to-point<br /> <br /> A escolha do modo dependerá da topologia NBMA da rede.    <br /> |Originalmente prevendo conexões entre os roteadores através de redes Frame Relay, ATM ou X.25.<br /> <br /> Se você for um ISP completamente isento de infraestruturas legadas, ou seja, tendo o Ethernet como única tecnologia de enlace de toda a sua rede, você não precisará preocupar-se com o OSPF em NBMA.<br /> |}<br /> OBS: algumas plataformas mencionam a rede OSPF de uma interface Loopback como &quot;LOOPBACK&quot;. Recomenda-se não modificar isto.<br /> <br /> Para facilitar este entendimento, forneço uma apresentação visual destes tipos de redes OSPF, com ênfase nas melhores práticas. Identifique-se com os tipos de conexões mostradas a seguir, e certifique-se de configurar as suas interfaces de roteadores habilitadas para o OSPF conforme as sugestões de &quot;''network types''&quot;:<br /> <br /> [[Arquivo:Bpf-ospf-4.png|centro|miniaturadaimagem|1024x1024px|Exemplos de tipos de redes OSPF, em especial as boas práticas para cada cenário]]<br /> <br /> ==== Configure corretamente a banda de referência do OSPF para evitar problemas com a derivação de custos de interfaces OSPF ====<br /> Talvez uma das coisas mais óbvias, mas um tanto negligenciadas por alguns ISPs: muitos profissionais com os quais já interagi simplesmente esqueceram-se de definir a banda de referência do OSPF em suas redes!<br /> <br /> Permita-me explicar algo: a métrica do OSPF é o &quot;''Cost''&quot; (custo), e muitos afirmam que o custo de uma interface é inversamente proporcional à sua banda. Isto está parcialmente correto. Na prática, e de forma mais abrangente, o OSPF determina os custos das interfaces dos roteadores da seguinte forma:<br /> Custo = Banda de Referência (em bps) / Banda da Interface (em bps)<br /> O problema é que a banda de referência considerada pelo OSPF na maioria das plataformas/equipamentos é de 100 Mbps (cem megabits por segundo!). Isto significa que qualquer interface de roteador que possuir banda/capacidade igual ou superior a 100 Mbps terá o custo de... &quot;1&quot; (um)! Você vê algum problema nisto?<br /> <br /> Ou seja, em uma rede onde você possuir interfaces 1 Gbps, 10 Gbps, 25 Gbps, 40 Gbps, e, talvez, 100 Gbps, enfim, todas as interfaces acima de 100 Mbps terão o custo de 1, e isto significa que a convergência do OSPF não será capaz de compreender as diferenças entre estas capacidades reais, e que, consequentemente, não conseguirá compreender que um caminho com largura de banda de 40 Gbps é melhor que um caminho que tenha largura de banda de 1 Gbps. E o chamado e indesejável '''''roteamento subótimo''''' (''suboptimal routing'') poderá existir, pois uma &quot;melhor rota&quot; poderá ser, equivocadamente, uma rota que envolve um enlace de 1 Gbps, ao invés de considerar como melhor rota um enlace que ofereça 40 Gbps. Vejamos algumas situações considerando o valor de banda de referência padrão, ou seja, de 100 Mbps:<br /> '''Interface Fast Ethernet (100 Mbps)'''<br /> Custo = 100000000 / 100000000<br /> Custo = 1<br /> <br /> '''Interface Gigabit Ethernet (1 Gbps)'''<br /> Custo = 100000000 / 1000000000<br /> Custo = 1<br /> <br /> '''Interface Ten Gigabit Ethernet (10 Gbps)'''<br /> Custo = 100000000 / 10000000000<br /> Custo = 1<br /> E assim por diante, para 25, 40, 100, e até mesmo o recente 400 Gbps, por exemplo.<br /> <br /> OBS: obviamente não há escala negativa (valores de métricas abaixo de 0), portanto, com a banda de referência padrão (100 Mbps), o custo OSPF de interfaces igual ou superior a 100 Mbps será sempre &quot;1&quot;.<br /> [[Arquivo:Bpf-ospf-5.png|centro|miniaturadaimagem|900x900px|Exemplo de consequências com o valor padrão de banda de referência do OSPF em uma rede]]<br /> &lt;u&gt;Sugestões:&lt;/u&gt; configure a banda de referência do OSPF em todos os roteadores para a capacidade máxima suportada por todos os equipamentos. Se todo os seus roteadores suportarem a configuração da banda de referência para 100 Gbps, faça-o! Do contrário, configure então a banda de referência para 40 Gbps, e ajuste os custos manualmente nas interfaces 40 Gbps e/ou 100 Gbps para ter a granularidade necessária e exigida pelo seu projeto.<br /> <br /> Em último caso, defina os custos manualmente nas interfaces. Mas, no entanto, procure resolver a questão primeiro com a configuração do parâmetro global (banda de referência), evitando ter que intervir com a configuração dos custos manualmente nas interfaces.<br /> <br /> ==== A sumarização de rotas OSPF é um recurso, mas tenha cuidado com os problemas quanto a esta prática em redes MPLS ====<br /> Conforme comentado previamente, o protocolo de roteamento OSPF somente suporta a sumarização de rotas nativas do OSPF pelos roteadores de borda de área (ABR) e de rotas externas redistribuídas para o OSPF por roteadores ASBR. E isto significa que a sumarização de rotas nativas do OSPF só é possível em projetos com múltiplas áreas. <br /> <br /> Se o seu ISP possuir em sua rede uma única área OSPF (''single area''), não será possível sumarizar rotas OSPF neste tipo de ambiente.<br /> <br /> '''&lt;u&gt;OBS: cuidado com a sumarização do bloco alocado/dedicado para endereçar as interfaces Loopback!&lt;/u&gt;''' Especialmente se a sua rede MPLS possuir LSPs fim-a-fim, transportando serviços tais como L2VPN e L3VPN, pois a sumarização de rotas OSPF internas no seu ISP poderá provocar não somente a &quot;quebra&quot; destes LSP, mas a consequente perda de conectividade destes serviços também. Em adição, redes que contam com túneis de engenharia de tráfego entre roteadores especificamente de Core (P-routers) também estão sujeitas ao problema de quebra de LSP fim a fim.<br /> <br /> A ilustração a seguir demonstra esta situação e fornece duas alternativas para evitarmos este problema com a sumarização de prefixos em uma rede MPLS. <br /> [[Arquivo:Bpf-ospf-6b.png|centro|miniaturadaimagem|1024x1024px|Demonstração de uma possível complicação quanto a sumarização de rotas IGP em ambientes MPLS]] <br /> <br /> Aqui vivemos um dilema: por um lado, a sumarização de rotas IGP é uma boa prática. Por outro lado, isto trará problemas em ambientes MPLS. Em tese, é viável realizar a sumarização de rotas num backbone MPLS, desde que &lt;u&gt;não&lt;/u&gt; sumarizando os prefixos referentes aos endereços IP das interfaces Loopback dos roteadores ISP, além de outras medidas cautelares.<br /> <br /> Citemos aqui os benefícios gerais que a sumarização de rotas OSPF pode promover:<br /> * Os LSA &quot;detalhados&quot; (''Type 1 - Router,'' e ''Type 2 - Network'') ficam confinados nas áreas onde são produzidos. Isto é, não cruzam de uma área para outra.<br /> * Os roteadores ABR, os quais conectam uma ou mais áreas para a Area 0.0.0.0 (backbone), fazem um &quot;resumo&quot; (e não uma sumarização de rotas!) das redes IP de cada área a anunciam estes resumos para a Area 0.0.0.0, assim como produzem o resumo das redes IP da Area 0.0.0.0 e injetam isto para as demais áreas onde possuírem interfaces configuradas para o OSPF.<br /> ** Este resumo é definido pelo LSA Type 3 (''Summary LSA'') em nada tem a ver com &quot;sumarização de rotas&quot; referentes aos prefixos: o resumo aqui trata-se da supressão dos detalhamentos topológicos da área onde estes prefixos residirem (os quais existem ou são ditados pelos LSA Type 1 e 2, e cujos os quais não são propagados para fora da área onde residem ou foram originados).<br /> ** Este resumo é definido pelo LSA Type 3 (''Summary LSA''). Este LSA é gerado somente pelos roteadores ABR.<br /> * O exposto acima significa que a sumarização de rotas de uma determinada área (ex: Area 1 ou Area 1.1.1.1) não promoverá benefícios exatamente naquela área, mas sim para a Area 0.0.0.0 e, consequentemente, para as demais áreas &quot;plugadas&quot; no backbone.<br /> ** Entenda: não há como sumarizar rotas de uma determinada área para dentro desta mesma área. As redes IP e os detalhamentos topológicos destas, mantidos pelos LSAs detalhados (Type 1 e Type 2), são resumidos num primeiro instante pelos LSA Type 3 (''Summary LSA''), conforme já comentado, e são então (os LSA Type 3) injetados para a Area 0.0.0.0.<br /> *** No momento em que isto ocorrer, você (administrador da rede), &lt;u&gt;poderá comandar&lt;/u&gt; (ou não) a &lt;u&gt;sumarização de rotas&lt;/u&gt; referentes a estas redes IP em um único ou em poucos LSA Type 3, ao invés de produzir um LSA Type 3 representando cada rede IP específica desta área.<br /> **** Em outras palavras, isto é a efetiva sumarização das rotas OSPF. A sumarização não é automática, tampouco requerida: você, &lt;u&gt;se&lt;/u&gt; desejar sumarizar, deverá configurar esta sumarização manualmente.<br /> * Consequentemente, ao sumarizar, você reduzirá o tamanho do LSDB das áreas da rede OSPF.<br /> ** Ao invés de repassar um LSA Type 3 referente a cada uma das redes IP de uma determinada área (ex: Area 1.1.1.1) para a Area 0.0.0.0 (ex: 50 redes IP na Area 1.1.1.1 resultaria em 50 LSAs Type 3 sendo anunciados para a Area 0.0.0.0), você, por exemplo, alternativamente, poderá sumarizar/agregar todas estas redes IP num único LSA Type 3. Isto é, se o seu plano de endereçamento assim o permitir.<br /> ** Bancos de dados mais enxutos reduzem o esforço de recomputação dos mesmos pelos roteadores OSPF. Ou seja, menor esforço e diminuição do overhead de processamento.<br /> * Consequentemente, ao termos bancos de dados mais enxutos, com o auxílio da sumarização, teremos tabelas de roteamento menores com relação a rotas IGP/OSPF.<br /> ** Isto se traduz em maior escalabilidade, menor ''overhead'', e melhores tempos de convergência do OSPF. E isto não é uma exclusividade apenas de redes de ISP.<br /> * Impactos adversos que por ventura ocorrerem em links de uma determinada área ficarão confinados apenas naquela área.<br /> ** Os roteadores posicionados na área onde ocorrerem oscilações frequentes (flap) de links, por exemplo, deverão propagar/inundar os LSAs detalhados correspondentes a todo instante para dentro da área, assim como realizar as devidas recomputações de seus LSDB.<br /> ** Estes eventos de instabilidades &lt;u&gt;não&lt;/u&gt; são percebidos por roteadores posicionados em outras áreas, pois não estão sendo repassados os LSA Type 3 referentes às redes IP específicas; apenas o LSA Type 3 contendo a rede agregada está sendo repassado para a Area 0.0.0.0 e, consequentemente, para as demais áreas. E este anúncio sumarizado obviamente não é modificado ou não sofre alterações quando ocorrem falhas nos links representando as redes específicas contidas nesta rota sumarizada.<br /> *** Ganha-se muito na questão de estabilidade geral da rede!<br /> Os benefícios quanto à sumarização de rotas são conhecidos: diminuição dos tamanho dos bancos de dados do OSPF (LSDB), diminuição das rotas OSPF da tabelas de roteamento (RIB), diminuição da frequência e propagação de mensagens LSU (os quais transportam os LSAs), ou seja, menor &quot;falatório&quot;, consequentemente menor ''overhead'' de processamento e melhores tempos de convergência para a rede.<br /> <br /> No entanto, vem aqui o ponto de divergência e reflexão quanto à sumarização de rotas OSPF em ambientes MPLS. Acompanhe comigo.<br /> <br /> '''As complicações quanto a sumarização de rotas OSPF em ambientes MPLS'''<br /> * A prática de sumarização de rotas IGP em backbones MPLS sempre acompanhou diversos casos envolvendo problemas.<br /> ** As duas alternativas sugeridas anteriormente são válidas e podem ser consideradas para a mitigação destes problemas.<br /> * No entanto, no que diz respeito à &quot;educar&quot; o OSPF nas questões de &quot;falatório&quot; e diminuição de ''overhead'' de processamento, diversos roteadores embarcam recursos adicionais para melhorarmos os padrões de estabilidade e convergência do OSPF.<br /> ** Em muitos projetos, talvez, ao invés de você sumarizar rotas OSPF no backbone MPLS, você deva considerar ferramentas tais como:<br /> *** '''''IP Event Dampening:''''' para reduzir muito substancialmente os overheads de processamento envolvendo o OSPF quando ocorrerem oscilações de interfaces (''flapping'') muito frequentes.<br /> *** '''''OSPF SPF e LSA Throttling:''''' para reduzir muito substancialmente os overheads de processamento com a propagação de LSAs e recomputações frequentes do LSDB.<br /> *** Estas situações serão discutidas posteriormente neste artigo.<br /> <br /> ==== Saiba quando e onde implementar Áreas especiais do OSPF ====<br /> Como provavelmente já é de seu conhecimento, há duas abordagens com relação aos projetos com o OSPF: ''single area'' (uma única área OSPF), e ''multiarea'' (múltiplas áreas OSPF).<br /> <br /> Quanto a considerar uma abordagem ''single area'' ou ''multiarea'', isto dependerá de algumas características de seu projeto técnico, mas, no entanto, os três argumentos principais são:<br /> * Tamanho da rede, fatorando a quantidade de roteadores presentes assim como a quantidade de links internos, quantidade de adjacências a serem estabelecidas por roteador e, ultimamente, a quantidade de rotas OSPF que deverão ser publicadas na tabela de roteamento (RIB). E, mais importante ainda, o tamanho do LSDB de um projeto ''single area''. <br /> * Locais da rede onde rompimentos de enlaces ou oscilações da disponibilidade de roteadores poderiam provocar algum tipo de impacto no processamento do plano de controle ou algum tipo de inconveniente na ações de convergência deste.<br /> * Onde, de acordo com o seu projeto técnico, for necessário sumarizar rotas OSPF.<br /> Considerando aqui apenas o conceito de projeto ''multiarea'', a título de compreensão do título desta seção do artigo.<br /> <br /> O OSPF apresenta alguns recursos diferenciados relacionados aos projetos com áreas, e o principal deles são as chamadas áreas especiais. Quando configuramos uma área normalmente, ela é tida como uma área ''regular'', e isto significa que o LSDB desta área poderá acomodar todo e qualquer tipo de LSA suportado pelo software de seu equipamento. No entanto, em diversos projetos de redes, os analistas optam por práticas que promovam resultados mais específicos e objetivos.<br /> <br /> Vejamos os tipos de áreas do OSPF:<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de Áreas OSPF e as Situações onde são Empregadas<br /> !Tipo de Área<br /> !Descrição<br /> !LSAs suportados<br /> |-<br /> |'''Área Regular ou Padrão'''<br /> |Uma área regular ou área padrão, como o nome sugere, é uma área comum. Quando configuramos uma área OSPF<br /> é exatamente este tipo de área, exceto quando definimos alguma propriedade que a tipifica como uma área especial.<br /> |Todos os LSAs são suportados numa área padrão.<br /> |-<br /> |'''Área Backbone'''<br /> |Praticamente a mesma coisa, exceto que trata-se da Área 0 ou Área 0.0.0.0 do seu projeto OSPF. Em termos<br /> funcionais, uma Área Backbone e uma Área Regular são praticamente a mesma coisa, só que, no entanto, alguns<br /> <br /> recursos OSPF são exigidos com o envolvimento da Área Backbone, assim como outros não são permitidos, ao<br /> <br /> oposto de uma Área Regular. Por exemplo:<br /> * Num projeto ''multiarea'', todas as demais áreas precisam se conectar diretamente à Área Backbone. A exceção à<br /> regra é o recurso ''Virtual Link''.<br /> * A Área Backbone não pode ser definida como Stuby, NSSA, Totally Stubby ou Totally NSSA.<br /> |Todos os LSAs são suportados numa área padrão.<br /> |-<br /> |'''Área Stub'''<br /> |É o tipo mais conhecido de área especial. O objetivo da Área Stub é preservar recursos dos roteadores posicionados<br /> nesta área, em especial o tamanho do LSDB e, consequentemente, o tamanho da tabela de roteamento (RIB).<br /> <br /> Quando usar uma área Stub? Normalmente fazemos isto quando temos um roteador posicionado num local remoto da rede<br /> <br /> e com apenas um único link conectando-o para o restante da rede, '''&lt;u&gt;e&lt;/u&gt;''' há muitas rotas externas redistribuídas para o OSPF.<br /> <br /> Não fará muito sentido se você definir uma área como Stub e, na sua tabela de roteamento, houver poucas rotas<br /> <br /> OSPF externas que tiverem sido redistribuídas de outros processos de roteamento. <br /> <br /> Portanto, o uso de áreas Stub faz muito sentido em partes da rede (observando as áreas aqui) que conectam dispositivos <br /> <br /> roteadores mais &quot;modestos&quot; e numa rede onde há muitas rotas OSPF externas, as quais serão suprimidas tanto do <br /> <br /> LSDB desta área Stub quanto da tabela de roteamento dos roteadores desta área.<br /> <br /> Ao definirmos uma Área como Stub, é importante defini-la desta forma, também, em todos os roteadores que estiverem<br /> <br /> posicionados nesta área, do contrário você não será capaz sequer de formar as adjacências ali. Outra característica é que<br /> <br /> o roteador ABR desta área produzirá/gerará uma rota padrão (default) para os roteadores desta área, para que eles <br /> <br /> consigam se comunicar com as redes representadas pelas rotas OSPF externas contida na Área 0.0.0.0 e demais áreas.<br /> |Todos os LSAs são permitidos, exceto o<br /> LSA Type 5 (AS External LSA)<br /> |-<br /> |'''Área Not-So-Stubby (NSSA)'''<br /> |Uma Área Stub proibe ou não aceita LSAs Type 5 (External). E sabemos que a configuração de uma<br /> redistribuição de rotas de outros protocolos de roteamento para o OSPF, em um roteador, automaticamente ativa a<br /> <br /> função de ''Autonomous System Boundary Router'' (ASBR), certo?<br /> <br /> Isto significa que roteadores numa Área Stub não recebem LSAs Type 5 (External) e, consequentemente, não terão <br /> <br /> quaisquer rotas OSPF externas em suas tabelas de roteamento e que, para poderem rotear tráfego até a estas redes<br /> <br /> externas, os roteadores da Area Stub precisarão utilizar a rota padrão (default) gerada automaticamente pelo roteador <br /> <br /> ABR desta Área Stub.<br /> <br /> Até aí creio que o entendimento esteja claro.<br /> <br /> Agora vejamos aqui um cenário hipotético: e se, no seu projeto técnico, você precisar redistribuir rotas externas para o<br /> <br /> OSPF em um roteador que está posicionado numa Área definida como Stub? Este tipo de setup não seria suportado, pois,<br /> <br /> novamente, uma Área Stub recusa os LSAs Type 5, os quais são gerados pelos roteadores ASBR.<br /> <br /> Caso você precise de uma solução que reúna os benefícios de uma Area Stub e que ao mesmo tempo permita a presença<br /> <br /> de um roteador ASBR, ou seja, com redistribuição de rotas externas para o OSPF dentro daquela Área, então a sua solução<br /> <br /> deverá ser com uma Área ''Not-So-Stubby'' (NSSA).<br /> <br /> Numa Área NSSA, ocorrem os seguintes:<br /> * Você precisará definir todas interfaces de roteadores desejadas para aquela área como NSSA.<br /> * A Área NSSA, assim como a Área Stub, não aceita LSAs Type 5 (External). Isto prevalece.<br /> * Ao redistribuir rotas externas para o OSPF em um roteador desta Área NSSA, este roteador passará a ser um ASBR.<br /> * O ASBR de uma Área NSSA não gera LSA Type 5 (External), e sim LSA Type 7 (NSSA External LSA).<br /> * Cada rota externa redistribuída pelo roteador ASBR de uma Área NSSA produzirá um LSA Type 7.<br /> * O LSA Type 7 (NSSA External LSA) existirá somente nesta Área NSSA!<br /> * O roteador de borda de área (ABR) da Área NSSA converterá cada LSA Type 7 para um LSA Type 5 quando repassando<br /> o LSA para a Área 0.0.0.0. <br /> * Basicamente isto é governado pelo bit &quot;P&quot; (''propagation''), descrito no campo Options (1 byte) contido no pacote ''Link-State Update'' (LSU).<br /> * Se o roteador ABR da Área NSSA for ao mesmo tempo um roteador ASBR, este bit &quot;P&quot; não é assinalado<br /> * Numa Área NSSA, o roteador ABR não gera uma rota padrão (default) automaticamente, portanto você deverá configurar isto<br /> de forma apropriada (via um &quot;''area xxx nssa default-information-originate''&quot;, ou procedimento similar em seu equipamento).<br /> <br /> Faz muito sentido usar áreas NSSA em projetos onde há roteadores mais modestos e numa rede onde há muitas rotas externas<br /> <br /> em toda a rede NSSA '''&lt;u&gt;e&lt;/u&gt;''', ao mesmo tempo, a necessidade de redistribuir rotas externas para a Área NSSA.<br /> |Todos os LSAs são permitidos, exceto o<br /> LSA Type 5 (AS External LSA).<br /> <br /> O LSA Type 7 (NSSA External LSA), por sua vez,<br /> <br /> reside apenas na própria Área NSSA, e é convertido<br /> <br /> para LSA Type 5 pelo roteador ABR da área.<br /> |-<br /> |'''Área Totally Stubby'''<br /> |É essencialmente uma área Stub, só que bem mais agressiva no sentido de quais tipos de LSA podem existir naquela área.<br /> Numa Área definida como ''Totally Stubby'', obviamente, são permitidos todos os LSAs detalhados (Type 1 - Router, Type 2 - Network)<br /> <br /> que são produzidos pelos roteadores posicionados naquela área.<br /> <br /> Mas aí vem a grande diferença entre ''Totally Stubby'' e ''Stub'': numa área definida como ''Tottaly Stubby'', mais nenhum LSA é permitido,<br /> <br /> e isto inclui o LSA que descreve as redes OSPF contidas em outras áreas (LSA Type 3 (Summary LSA)), assim como o LSA Type 4<br /> <br /> (Summary ASBR), além do LSA que representa as redes OSPF externas (LSA Type 5 (External LSA)).<br /> <br /> Para constar, num setup ''Totally Stubby'', o roteador ABR desta área gera uma rota padrão (default) automaticamente.<br /> <br /> A configuração é idêntica daquela que devemos fazer para uma Área ''Stub'', sendo a única diferença um parâmetro (''&quot;no-summary&quot;'') <br /> <br /> que deverá ser definido apenas no roteador ABR desta área.<br /> <br /> Faz muito sentido uma ''Totally Stubby'' em roteadores em uma área que só possui um único enlace de comunicação para o <br /> <br /> restante da rede, e por onde apenas uma rota padrão (default) é necessária para conectar aquele roteador com o restante da rede.<br /> <br /> Afinal de contas, para que manter um LSDB gigante e um montão de rotas em roteadores de uma área que só possui um link com <br /> <br /> o restante da rede, especialmente quando estes roteadores são mais modestos em termos de poder de processamento?<br /> |Apenas os LSA que descrevem detalhadamente<br /> a topologia e redes OSPF da referida área, ou seja,<br /> <br /> LSA Type 1 (Router), LSA Type 2 (Network).<br /> <br /> Todos os demais LSAs são suprimidos.<br /> |-<br /> |'''Área Totally NSSA'''<br /> |Resumindo, é uma Área NSSA que:<br /> * Não aceita quaisquer LSAs que representem rotas de redes OSPF de outras áreas (LSA Type 3)<br /> * Não aceita quaisquer LSAs que representem rotas de redes externas ao OSPF (LSA Type 5).<br /> * Consequentemente, não aceita LSAs para a conectividade com roteadores ASBR de outras áreas (LSA Type 4).<br /> * Permite que haja roteadores ASBR em sua área, redistribuindo rotas de redes externas para o OSPF e, portanto, produzindo<br /> LSA Type 7.<br /> * O ABR desta área gerará automaticamente uma rota padrão para que os roteadores desta área possam rotear tráfego para<br /> redes OSPF e rotas OSPF externas existentes em outras áreas.<br /> <br /> A configuração é idêntica daquela que devemos fazer para uma Área NSSA, sendo a única diferença um parâmetro que deverá ser<br /> <br /> definido apenas no roteador ABR desta área.<br /> |Apenas os LSA que descrevem detalhadamente<br /> a topologia e redes OSPF da referida área, ou seja,<br /> <br /> LSA Type 1 (Router), LSA Type 2 (Network).<br /> <br /> Os LSA Type 7 gerados por roteadores ASBR<br /> <br /> desta área são obviamente permitidos.<br /> <br /> Todos os demais LSAs são suprimidos.<br /> |}<br /> Talvez seja prudente de minha parte dissertar um pouco, mesmo que de forma resumida e objetiva, os tipos de roteadores OSPF, até mesmo para que haja um melhor esclarecimento e associação com os conceitos de Áreas.<br /> <br /> É necessário frisar aqui que o conceito de áreas do OSPF é definido em nível '''''interface''''', ou seja, ao contrário do protocolo de roteamento IS-IS, onde todas as interfaces (o roteador como um todo) ficam posicionadas numa única área, no caso do OSPF, por sua vez, definimos/configuramos as áreas por interface.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de Roteadores OSPF<br /> !Tipo de Roteador<br /> !Descrição<br /> |-<br /> |'''Roteador Interno'''<br /> |Um rotador é chamado de &quot;interno&quot; quando todas as suas interfaces são configuradas para participar de uma mesma área.<br /> |-<br /> |'''Roteador de Backbone'''<br /> |É essencialmente um roteador interno, sendo que a diferença é que todas as suas interfaces são definidas para participar da Área 0.0.0.0.<br /> |-<br /> |'''Roteador de Borda de Área (ABR)'''<br /> |Um roteador que possui pelo menos uma interface configurada para a Área 0.0.0.0, e uma ou mais interfaces configuradas para outra(s) área(s).<br /> |-<br /> |'''Roteador de Borda de Sistema Autônomo (ASBR)'''<br /> |Um roteador que esteja realizando a redistribuição de rotas de redes externas ao OSPF..<br /> |-<br /> |'''Roteador Designado (DR)'''<br /> |Não é exatamente um tipo de roteador OSPF, e sim uma função. Toda e qualquer interface OSPF de um roteador que estiver conectada a um<br /> dos tipos de redes OSPF (''network types'') que exijam a eleição de um roteador DR, sendo que, neste caso, o próprio roteador em questão é o<br /> <br /> DR do referido segmento.<br /> |-<br /> |'''Roteador Designado de Backup (BDR)'''<br /> |Idem, com relação exposto acima sobre o DR.<br /> |}<br /> O diagrama a seguir ilustra alguns dos tipos de áreas e de roteadores OSPF:<br /> [[Arquivo:Bpf-ospf-7.png|centro|miniaturadaimagem|1024x1024px|Exemplos de alguns tipos de roteadores e de áreas do OSPF]]<br /> Para concluir com o tema sobre áreas especiais, fique atento quanto as explicações fornecidas na tabela anterior. Você deverá ser capaz de identificar quais situações melhor aplicam-se para cada um dos tipos de áreas indicadas.<br /> <br /> ==== Evite o uso de Virtual-Links! ====<br /> Não entrarei em muitos detalhes aqui, tais como diagramas e afins, apenas dissertarei brevemente sobre o recurso ''Virtual Link''. Este recurso foi projetado para as seguintes necessidades:<br /> * Fusão de duas redes OSPF distintas, onde há duas Áreas de backbone (0.0.0.0) OSPF separadas por uma área regular. Ou seja, quando precisamos interconectar as duas Áreas 0.0.0.0 deste cenário através de uma área não-backbone.<br /> * O projeto com OSPF em múltiplas áreas obriga que toda e qualquer área esteja diretamente conectada à Área 0.0.0.0. Suponhamos que em um determinado momento isto não seja viável no seu projeto técnico, onde uma Área (ex: 2.2.2.2) conecta-se à outra área (ex: 1.1.1.1), que por sua vez conecta-se ao backbone (Area 0.0.0.0), algo que não funcionaria por não ser suportado. O mecanismo ''Virtual Link'' poderia ser usado nestas situações para conectar a Área 2.2.2.2 para a Área 0.0.0.0, através da Área 1.1.1.1.<br /> * Quando, numa área não-backbone, você precisa construir uma rota de backup (caminho alternativo) via outro roteador que não esteja plugado na Área 0.0.0.0.<br /> Nestas três situações discutidas acima, o recurso ''Virtual Link'' pode ser considerado.<br /> <br /> No entanto, procure não implementá-lo. Busque formas de aprimorar o seu projeto técnico para que o ''Virtual Link'' jamais seja necessário ou exigido. O ''Virtual Link'' introduz limitações e agrega maior complexidade para o projeto lógico do OSPF!<br /> <br /> É nestas horas que você deverá aplaudir todo e qualquer esforço que tenha tido lá no início por construir uma rede hierárquica, modular e estruturada!<br /> <br /> ==== Sempre que possível, opte por um protocolo IGP que não seja o OSPF para clientes L3VPN MPLS ====<br /> Não será coberto detalhadamente, pois isto será discutido com boa profundidade de detalhes em outros artigos aqui na Wiki do BPF, especialmente sobre o tema L3VPN MPLS.<br /> <br /> No que diz respeito aos serviços L3VPN MPLS em um operador de redes, sabemos que os roteadores PE devem trocar rotas com seus assinantes em suas respectivas VRFs, o que significa que precisamos rodar um protocolo de roteamento nesta relação &quot;ISP x Cliente&quot;, ou seja, o &quot;PE-CE&quot;. Você tem a total liberdade para escolher o protocolo que quiser, pois sabemos que toda e qualquer rota IGP trocada com clientes L3VPN fica completamente segregada das rotas IGP do backbone do ISP. É por esta razão que a tecnologia implementa VRFs, sendo uma VRF para cada assinante e, assim, não compartilhamos rotas IGP com os clientes.<br /> <br /> Quanto aos protocolos ou procedimentos, uma L3VPN poderá considerar:<br /> * Rotas conectadas<br /> * Rotas estáticas<br /> * RIP<br /> * OSPF<br /> * EIGRP<br /> * IS-IS<br /> * BGP<br /> Agora, com as minhas palavras, de todas as opções acima o OSPF é indiscutivelmente o mais burocrático, e pelas seguintes razões:<br /> # Num roteador PE, cada cliente L3VPN que você ou ele optar por usar o OSPF na relação PE-CE, será exigido um processo dedicado do OSPF por cliente. Algumas plataformas de roteadores possuem limites nada confortáveis quanto a isto, particularmente no caso de roteadores &quot;jurássicos&quot;.<br /> # O processo OSPF dedicado para o assinante lá na VRF do roteador PE deverá aparentar ser uma Área 0.0.0.0 ou um Superbackbone. Quando o OSPF é usado na relação PE-CE de uma L3VPN MPLS, nos roteadores PE, diversos procedimentos são exigidos para viabilizar a redistribuição da rota OSPF para o BGP, a conversão desta rota OSPF que foi redistribuída para BGP IPv4 para um endereço VPNv4, e a inclusão de communities estendidas específicas para viabilizar o OSPF na relação PE-CE dos sites remotos daquele assinante. Em alguns setups isto agrega maior complexidade. Mas não é o que complica as coisas aqui, no meu entendimento.<br /> # O OSPF precisa do auxílio de alguns mecanismos para a prevenção de loops de roteamento, tais como ''Down Bit'' e ''Route Tags'', e, tanto o ISP quanto o cliente, deverão trabalhar juntos para que o serviço não seja impactado e que loops não possam ocorrer.<br /> # Talvez a pior parte: problemas com cenários onde há links contratados com duas operadoras distintas, sendo um deles L3VPN MPLS e o outro não, num cenário chamado de &quot;''OSPF Backdoor Link''&quot;:<br /> ## Numa rede OSPF tradicional (e não numa L3VPN), toda e qualquer rota redistribuída para o OSPF torna-se uma rota externa (LSA Type 5).<br /> ## Numa rede L3VPN MPLS, no entanto, para evitar que isto pudesse ser um problema em sites remotos eventualmente configurados como áreas Stub, as rotas redistribuídas do BGP para o OSPF são tidas como rotas inter-area, ou seja, produzindo LSA Type 3, e não rotas externas (LSA Type 5).<br /> ## O problema está no processo de seleção de rotas do OSPF. Acompanhe:<br /> ### Rotas Intra-Area (LSA Type 1 e 2) são preferidas, independentemente do custo da rota.<br /> #### Ex: uma rota Intra-Area tem um custo de 500, e uma rota Inter-Area tem um custo de 100. O OSPF preferirá sempre a rota Intra-Area!<br /> ### Rotas Inter-Area são preferidas somente após as rotas Intra-Area.<br /> ### Rotas Externas Tipo 1 (LSA Type 5 - External Type 1) são preferidas sobre rotas Externas Tipo 2 (LSA Type 5 - External Type 2), independentemente do custo.<br /> ## Portanto, imaginemos um cliente com dois sites remotos estendendo uma área OSPF qualquer entre estes dois sites:<br /> ### Se o cliente tem um link de 1 Gbps com serviço L3VPN via o ISP &quot;A&quot;, e tem, também, um link de 100 Mbps comum, não-L3VPN, com o ISP &quot;B&quot;.<br /> #### Rotas OSPF aprendidas pelo link não-L3VPN MPS (ISP &quot;B&quot;) serão tratadas como rotas Intra-Area.<br /> #### Rotas OSPF aprendidas pelo link L3VPN MPLS (ISP &quot;A&quot;) serão tratadas como rotas Inter-Area.<br /> #### Sabemos que em termos de custos, o link pelo ISP &quot;A&quot; é indiscutivelmente melhor que o link pelo ISP &quot;B&quot;.<br /> ##### É... no entanto, o OSPF optará encaminhar tráfego pelo link de 100 Mbps, ao invés do link de 1 Gbps!<br /> ###### Rotas Intra-Area tem preferência sobre rotas Inter-Area.<br /> ## Este problema pode ser resolvido com um recurso chamado '''''OSPF Sham-Link'''''. O problema é que isto não é uma ação executada pelo cliente, e sim por você, ISP! E não é um procedimento pequeno, ou seja, agregará esforço e complexidade para o seu time de ativação e suporte!<br /> Por estes motivos que eu não curto o OSPF para atuar como PE-CE. Mas, atenção, é uma recomendação ou preferência de cenário apenas! Na verdade, quem ditará se você deverá usar ou não o OSPF neste tipo de situação será o tipo de acordo que você possui com o seu cliente! Em muitos casos, o uso do OSPF para o PE-CE é inevitável por conta disso.<br /> <br /> Em tempo, estas situações discutidas acima podem ser consultadas no draft '''''OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs''''' ([https://tools.ietf.org/html/draft-ietf-l3vpn-ospf-2547-05 draft-ietf-l3vpn-ospf-2547-05.txt])<br /> <br /> Caso você tenha curiosidade, verifique este tipo de setup na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-ospf-8.png|centro|miniaturadaimagem|999x999px|Uma L3VPN MPLS com protocolo de roteamento OSPF na relação PE-CE]]<br /> <br /> ==== Proteja o seu OSPF contra determinados riscos de segurança ====<br /> Um dos temas mais importantes: a segurança da infraestrutura de redes e de tudo aquilo que roda no topo desta. A segurança da informação precisa ser observada fim-a-fim, e cada elemento ativo de rede precisa fornecer a sua parcela de contribuição.<br /> <br /> Felizmente isto já foi previsto e bem documentado em um artigo aqui na Wiki do BPF. Confira: [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para Proteção de Roteadores e Switches]]. Há uma seção exclusiva sobre a proteção do protocolo de roteamento OSPF!<br /> <br /> ==== Opte por soluções mais apropriadas para engenharia de tráfego, evitando manipulações frequentes da métrica do OSPF ====<br /> Nos &quot;primórdios&quot; das redes IP, toda a vez que necessitávamos realizar alguma engenharia de tráfego, tínhamos que lançar diversas &quot;gambiarras&quot;, incluindo rotas estáticas, ferramentas de políticas de roteamento, filtros, PBR, etc. Além de outras práticas/recursos, tais como a manipulação de Distância Administrativa (AD) sobre uma ou mais rotas, manipulação das métricas (no caso do OSPF, o custo das interfaces), dentre outras iniciativas.<br /> <br /> Não que não funcionem, a questão não é essa. A questão é que toda a vez que manipulamos alguma coisa neste sentido diretamente nas configurações do protocolo de roteamento IGP, corremos o risco de &quot;errarmos a mão&quot;, ou seja, podemos até conseguir resolver o problema daquele cenário, mas ao preço de provocar outros distúrbios até então imprevistos, ou então o cenário acabar ficando desnecessariamente completo ou engessado.<br /> <br /> Ao invés de você manipular o IGP para fazer a engenharia de tráfego, que tal estudar e considerar tecnologias mais sofisticadas e flexíveis para este propósito? Dê uma conferida sobre em nosso artigo [[Engenharia de Trafego com MPLS TE|Engenharia de Tráfego com MPLS TE]], disponível em nossa Wiki, e veja se isto não faria maior sentido para o seu projeto!<br /> <br /> Futuramente, ou em breve, disponibilizarei alguns artigos sobre a evolução do MPLS TE clássico, com títulos tais como '''''Transição de Infraestruturas MPLS Tradicionais para o SRTILFA''''' e '''''Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE''''', e potencialmente outros artigos sobre este tema.<br /> <br /> ==== Ferramentas adicionais para o &quot;ajuste fino&quot; do OSPF (IP Event Dampening, LSA/SPF Throttling, Timers) ====<br /> Redes OSPF muito grandes precisam de bastante cuidados, especialmente nas questões de hierarquia e modularidade das topologias física e lógica, bom arranjo hierárquico também para o plano de endereçamento IP, além de um bom projeto de múltiplas áreas com o OSPF. Só que em alguns ou muitos casos, especialmente nos grandes operadores de redes, para destravar o crescimento da rede como um todo em níveis próximos dos &quot;colossais&quot;, outras iniciativas precisam ser projetadas para a infraestrutura.<br /> <br /> Uma destas iniciativas em termos de abordagens de projeto IGP com MPLS é o ''Unified MPLS'', tema já disponibilizado na forma de um artigo aqui na nossa Wiki do BPF. Confira: [[Introducao ao Unified MPLS|Introdução ao Unified MPLS]].<br /> <br /> Agora tiremos o ''Unified MPLS'' da jogada e foquemos em alguns recursos que podem fazer o seu OSPF fluir melhor na sua rede!<br /> <br /> Em alguns momentos, o OSPF pode ser um protocolo um tanto &quot;tagarela&quot;, particularmente quando ocorrem oscilações frequentes acerca da disponibilidade de enlaces (links) e roteadores. Ou seja, toda a vez que um evento &quot;''up/down''&quot; ocorrer na sua rede, a prioridade do roteador que percebeu o evento é adicionar esta mudança (ex: novo LSA, atualização de LSA, remoção de LSA) no seu LSDB, comunicar isto para as suas adjacências, receber a confirmação de recebimento do evento por parte de seus vizinhos, e realizar a computação de seu LSDB (procedimento denominado ''Shortest-Path First'', com seu algoritmo Dijkstra), derivando consequentemente a sua árvore de caminhos de menor custo (SPT), e publicar estes melhores caminhos como rotas OSPF em sua tabela de roteamento.<br /> <br /> O que ocorre na verdade é o que chamamos de &quot;inundação de LSA&quot; ou &quot;''LSA flooding''&quot;, pois uma das principais propostas do OSPF é a de convergir o mais rapidamente possível. Uma vez a rede estando completamente convergida, isto é, todos os roteadores participantes estão cientes do evento e já concluíram a computação de seus bancos de dados (LSDB), o OSPF voltará a ficar &quot;quieto&quot;, ou seja, trocando apenas mensagens ''Hello'' (OSPF Packet Type 1) e nada mais, e, a cada 30 minutos, uma breve troca de resumos para confirmar que todos os roteadores possuem as informações completas e mais vigentes.<br /> <br /> Em outras palavras, o OSPF é um protocolo quase que &quot;calado&quot; apenas em redes estáveis, onde ocorrem poucos eventos de modificações topológicas. <br /> <br /> No entanto, em redes grandes, onde frequentemente ocorrem eventos de rompimento de fibras, entrada/remoção de redes IP, etc., o OSPF passa a ser bastante &quot;falante&quot;, pois, novamente, o ''LSA flooding'' ocorre para assegurar a mas rápida convergência possível. Mas este não é o maior dos problemas.<br /> <br /> O maior dos problema ocorre em ambientes que são vítimas de sucessivos e frequentes eventos de falhas, mesmo aquelas que sejam isoladas para um ponto específico da rede. Cada vez que um LSA novo ou atualizado é recebido por um roteador, novamente, ele precisa incorporar aquele LSA em seu LSDB, repassar via pacote ''Link-State Update'' (LSU) para seus vizinhos, receber um pacote ''Link-State Acknowledgement'' (LSAck) de cada um deles, e recomputar o seu LSDB, com a execução do SPF, produzir efetivamente a sua SPT, e posteriormente publicar as melhores rotas OSPF em sua tabela de roteamento (RIB). Antigamente isto era bem mais problemático, porque o OSPF, de certa forma, é um protocolo que desprende um bom ciclo de processamento e consume recursos substancialmente quando fazendo isto. Agora imagine isto acontecendo frequentemente, a todo instante! Os roteadores há alguns anos realmente podiam sentir os impactos desse ''overhead'' de processamento!<br /> <br /> Sendo bem honesto aqui, os roteadores ''carrier grade'' dos dias atuais dão conta disto com &quot;um pé nas costas&quot;, devido as suas excepcionais capacidades de processamento. Mas isto não significa que não devemos &quot;tunar&quot; o OSPF para que ele se comporte melhor, com mais fluidez, e até mesmo para evitarmos surpresas desagradáveis em nossas redes. O que é o foco dessa seção aqui.<br /> <br /> Como normalmente mitigamos este tipo de situação:<br /> # Projeto de rede bem hierárquica e modularizada.<br /> # Plano de endereçamento IP compatível com esta hierarquia da rede.<br /> # Bom projeto com múltiplas áreas OSPF.<br /> # Sumarização de rotas.<br /> ## Eventos de falhas com graves e frequentes oscilações ficam confinados nas áreas onde ocorrerem, e não são propagados para outras áreas, ou seja, limitamos o diâmetro do impacto aqui.<br /> ## O problema com a sumarização de rotas em ambientes ISP: qual operador de redes hoje em dia não possui o MPLS? Sumarização de rotas IGP e MPLS não combinam.<br /> ## E sumarização por si só não mitiga todos as situações discutidas previamente.<br /> # Adotamos mecanismos bem interessantes para limitar o montante de dano envolvendo o &quot;falatório&quot; excessivo do OSPF assim como as recomputações recorrentes e muito frequentes.<br /> ## É aqui que consideramos o ''IP Event Dampening'' e os ajustes nos diversos temporizadores (''Throttling de LSA e de SPF do OSPF'').<br /> '''Sobre o ''IP Event Dampening'''''<br /> <br /> O recurso '''''IP Event Dampening''''' apresenta um mecanismo de decaimento exponencial configurável para suprimir o efeitos de eventos excessivos de alteração de interface em protocolos de roteamento e de entradas nas tabelas de roteamento na rede. Este recurso permite que o operador de rede configure um roteador para identificar automaticamente e reduzir seletivamente um interface local que está oscilando frequentemente.<br /> <br /> O objetivo do recurso: vale a pena propagar LSAs referentes a links que falham incessantemente, &quot;on and off&quot;? Não seria mais inteligente suprimir a propagação de eventos sobre interfaces que oscilam frequentemente em um determinado período de tempo?<br /> <br /> Muitos administradores simplesmente colocariam interfaces assim em modo &quot;shutdown&quot; e, após um período, reativariam a interface para verificar se o problema teria sido resolvido. Eu diria que isto é até viável, mas, sem dúvidas, o recurso ''IP Event Dampening'' acaba sendo mais inteligente.<br /> <br /> O ''IP Event Dampening'' é mais inteligente e indicado porque permite que você configure um roteador para identificar automaticamente e reduzir seletivamente as interfaces locais daquele roteador que estão oscilando. Este amortecimento que ocorre removerá a interface da rede até que a referida interface cesse a sua oscilação e possa ter a sua rede retornada para a tabela de roteamento. Isto assegurará e melhorará os tempos de convergência da rede, promoverá o isolamento de falhas para que estas perturbações não sejam propagadas, culminando na redução da utilização de recursos de processamento dos roteadores e contribuindo para uma boa melhora da estabilidade geral da rede.<br /> <br /> '''Sobre o ''OSPF Link-State Advertisement Throttling'''''<br /> <br /> O outro mecanismo que prometi discutir aqui é o ''OSPF Link-State Advertisement Throttling''. Esse recurso fornece um mecanismo dinâmico para desacelerar as atualizações dos ''Link-State Advertisements'' (LSA) do OSPF durante períodos de instabilidade da rede, e viabiliza também uma convergência OSPF mais rápida, fornecendo limitação de taxa LSA em milissegundos.<br /> <br /> Para se ter uma noção, antes do advento do recurso ''OSPF LSA Throttling'', a geração de LSA era limitada por uma taxa típica de 5 segundos. Isso significava que as alterações em um LSA não podiam ser propagadas em milissegundos, portanto a rede OSPF não conseguia alcançar a convergência de milissegundos, algo que é bastante desejado por muitos tipos de ambientes mais críticos. O recurso de limitação dos LSAs do OSPF (o ''throttling'') é na verdade ativado por padrão em muitas plataforma de roteadores, possibilitando naturalmente uma convergência mais rápida do OSPF, preferencialmente, mas nem sempre, em milissegundos.<br /> <br /> Mesmo que seja um recurso ativo por padrão em muitos roteadores, é passível de customizações, e é aqui onde você, engenheiro da rede, entra em ação. Você poderá personalizar o comando que controla a geração (envio) de LSAs, ou o comando que controlará o intervalo de recebimento de LSAs. Esse recurso também fornece um mecanismo dinâmico para diminuir a frequência das atualizações do LSA no OSPF durante momentos de instabilidade da rede.<br /> <br /> Como o recurso funciona:<br /> <br /> Os ''timers'' padrão ou customizados por você controlam a geração (envio) de LSAs. Na prática, o primeiro LSA é sempre gerado imediatamente após uma alteração na topologia do OSPF, e o próximo LSA gerado é controlado pelo intervalo mínimo de início. Os LSAs subsequentes gerados para ou sobre o mesmo LSA têm taxa limitada até o intervalo máximo ser atingido. O &quot;mesmo LSA&quot; é definido como uma instância LSA que contém o mesmo número de ID LSA, tipo de LSA e Router ID do roteador. Outro comando pode ser usado para controlar o intervalo mínimo para a aceitação de um mesmo LSA. Se uma instância do mesmo LSA chegar antes do intervalo definido, o LSA será descartado. Na prática, recomenda-se que o intervalo de chegada seja menor ou igual ao intervalo de tempo de espera (hold-time) dos temporizadores de ''throttling'' de LSA.<br /> <br /> Este recurso permite reduzir os impactos relacionados às inundações de LSAs em redes sofrendo instabilidades e ao mesmo tempo em que promovendo ótimos tempos de convergência.<br /> <br /> '''''Sobre o recurso OSPF Shortest Path First Throttling'''''<br /> <br /> O recurso ''OSPF Shortest Path First Throttling'' possibilita customizar o cálculo do procedimento SPF em intervalos de milissegundos e atrasar potencialmente estes cálculos de SPF durante eventos de instabilidade da rede. Normalmente, no OSPF, e sem considerar aqui este recurso, o procedimento SPF é programado para calcular a árvore do caminho mais curto (SPT) quando houver uma alteração na topologia, e sabendo que uma execução do SPF poderá incluir vários eventos de alteração de topologia.<br /> <br /> A vantagem do recurso ''OSPF Shortest Path First Throttling'' aqui é que o intervalo no qual os cálculos do SPF deverão ocorrer é escolhido dinamicamente e baseado na frequência das alterações de topologia na rede. Este intervalo a ser escolhido deverá estar dentro dos limites dos intervalos de valores especificados por você, o administrador. Se a topologia de rede estiver instável, a otimização do SPF calculará os intervalos de agendamento do SPF como mais longos, até que a topologia se torne estável novamente.<br /> <br /> O que você ganha com isto? Diminui o impacto no plano de controle de seus roteadores quando a rede estiver instável!<br /> <br /> '''''Sobre os Bidirectional Forwarding Detection (BFD)'''''<br /> <br /> Muitos não sabem, mas os temporizadores ''Hello'' e Dead precisam ser idênticos entre dois roteadores que devam formar uma adjacência OSPF. Se forem diferentes, os roteadores não conseguirão concluir o procedimento de formação de adjacência. <br /> <br /> Visando acelerar a convergência da rede, em especial quando há um rompimento de um enlace de fibra entre dois roteadores, os administradores modificam ou customizam estes roteadores. Apesar de ser uma inciativa válida, a recomendação é que isto não seja feito com este propósito, pois poderá onerar ainda mais o processamento do OSPF.<br /> <br /> Ao invés de fazer isto, considere a &quot;terceirização&quot; da checagem por disponibilidade de adjacência para outro serviço, prestado por um protocolo bastante confiável, eficiente, e bem ''lightweight'' (leve): o '''''Bidirectional Forwarding Detection''''' ('''''BFD''''') ou &quot;Detecção de Encaminhamento Bidirecional&quot;. Além de ser bem rápido em termos de detecção de falhas, podendo ser nível milissegundo, é um protocolo mais esperto do que este procedimento que o próprio OSPF utiliza. Explico melhor.<br /> <br /> Quando um roteador OSPF percebe que uma interface &quot;caiu&quot; (o estado do protocolo IP da porta entrou em &quot;down&quot;), ele aciona rapidamente a convergência da rede. O desafio é quando ocorre uma falha de comunicação bidirecional neste link e o OSPF fica incapaz de perceber isto. O que ocorrerá: o OSPF deverá aguardar a expiração do ''Dead Interva''l (por exemplo, 40 segundos em redes ''Broadcast'') para, somente depois, descobrir que o seu vizinho não está mais &quot;vivo&quot;, e, portanto, acionando a convergência logo em seguida. Ou seja, percebe-se que os protocolos de roteamento não são muito espertos quanto à detecção destes tipos de incidente envolvendo a comunicação bidirecional.<br /> <br /> Felizmente, o BFD suporta isto, e o faz muito bem. Consegue muito rapidamente identificar problemas de comunicação bidirecional em um link e imediatamente comunica este problema para o protocolo de roteamento poder tomar a ação. <br /> <br /> A minha sugestão é que você estude e, se viável para o seu projeto técnico, adote o BFD para a rápida detecção de falhas de comunicação bidirecional nos links, ao invés de manipular os timers de ''Hello'' e ''Dead'' do OSPF. No geral, e em termos de processamento, é menos oneroso lidar com o BFD em segmentos críticos de sua rede do que ajustar os temporizadores de ''Hello'' e ''Dead'' nos roteadores OSPF. Note que não estou sugerindo para que você adote o BFD imediatamente: você precisa estudar e determinar onde, ao invés de modificar os timers do OSPF, fica melhor lidar com o BFD.<br /> <br /> === Por que você, como engenheiro de redes de um ISP, opta por usar o protocolo de roteamento OSPF em sua rede? ===<br /> Um tanto óbvio, não? Mas encerraremos este artigo com uma proposta mais didática.<br /> <br /> Em primeiro momento, permita-me antecipar que o que comentarei a seguir é válido tanto para IPv4 (OSPFv2) quanto para IPv6 (OSPFv3).<br /> <br /> A pergunta pode ser um tanto óbvia, assim como as prováveis respostas. O OSPF não é nenhuma novidade no mercado e está presente nas redes há muitos e muitos anos. Todo mundo já ouviu falar que o OSPF é rápido - isto é, converge rapidamente - que é mais escalável, inteligente, etc., mas não é todo mundo que descreve com detalhes as razões pelos quais o OSPF é o protocolo de roteamento de escolha dos operadores de redes de telecomunicações ou ISPs. Que tal então fornecer os argumentos com maiores propriedades?<br /> <br /> A propósito, eu poderia ter mudado o título desta pergunta para citar &quot;'''''por que adotar um protocolo de roteamento Link-State?'''''&quot; ao invés de &quot;OSPF&quot; apenas, pois isto traria muita justiça ao protocolo de roteamento IS-IS! <br /> <br /> Apesar de haver algumas semelhanças entre o OSPF e o IS-IS, são protocolos com características e propriedades bastante únicas na perspectiva de cada um. Eu particularmente prefiro o IS-IS, mas reconheço que o OSPF é muito mais difundido aqui no Brasil.<br /> <br /> Não será desta vez que dissertarei sobre o IS-IS, pois o foco do artigo é o protocolo de roteamento OSPF, que é amplamente difundido entre os operadores de redes. Mas, fique tranquilo, falar (e muito bem!) de IS-IS está no meu radar aqui para a Wiki do BPF, assim como compará-lo com o OSPF.<br /> {| class=&quot;wikitable&quot;<br /> |+Principais Características que Favorecem a Adoção do OSPF em Ambientes de ISP<br /> !Característica<br /> !Explicações<br /> |-<br /> |'''Confiabilidade na troca de mensagens'''<br /> |Protocolos de roteamento baseados no conceito de vetor de distância (Distance Vector) não implementam quaisquer mecanismos de confiabilidade na troca de mensagens. <br /> Um roteador rodando RIP pode simplesmente enviar toda a sua tabela de rotas RIP para seus (pseudo) vizinhos sem que haja mesmo o conceito de vizinhança/neighbor propriamente dito.<br /> <br /> Ou seja, dois roteadores não formam uma vizinhança para, depois, trocarem as suas rotas! Em adição, não há mecanismos de reconhecimento (ack) de recebimento de rotas, dentre muitas fragilidades existentes.<br /> <br /> Protocolos Link-State, como é o caso do OSPF e do IS-IS são muito superiores aqui:<br /> * Antes de trocar as informações sobre as redes, os roteadores OSPF precisam formar uma vizinhança por completo (termo aqui é &quot;adjacência&quot;).<br /> * Para que consigam formar uma adjacência, um conjunto de pré-requisitos é testado e validado durante o procedimento.<br /> * Ao contrário do RIP, os roteadores OSPF '''&lt;u&gt;não&lt;/u&gt;''' trocam rotas! Roteadores OSPF trocam informações sobre o estado dos links das interfaces participantes do protocolo, em estruturas de dados denominadas ''Link-State Advertisements'' (LSA).<br /> * O OSPF emprega ''PDUs'' (mensagens próprias em pacotes) para coordenar todo o processo de vizinhança/adjacência, troca de mensagens sobre os links da rede, e reconhecimento (ack) ou confiabilidade quanto à troca destas mensagens.<br /> * O roteador OSPF suporta mecanismos de retransmissão em caso de não reconhecimento de recebimento de uma informação (LSA) por parte de um de seus vizinhos.<br /> * Ao contrário do RIP - um distance vector - que faz envio periódico a cada 30 segundos de &lt;u&gt;toda&lt;/u&gt; a sua tabela de rotas, o OSPF é um protocolo um tanto &quot;quieto&quot;, principalmente em rede estáveis, pois, uma vez convergido por completo, não faz envio periódico de informações da rede. Ou seja, realiza apenas o chamado &quot;''triggered updates''&quot;.<br /> * Ainda com relação ao ''bullet'' anterior, o OSPF, sim, resincroniza o seu banco de dados a cada 30 minutos e através de um procedimento simplificado com envio resumido apenas das informações.<br /> |-<br /> |'''Escalabilidade e Diâmetro da Rede'''<br /> |Talvez seja o argumento mais fácil e conhecido sobre a diferenças entre protocolos Distance Vector e Link-State.<br /> * A escalabilidade pode ser mesurada de quatro formas: quantidade de elementos roteadores ativos, diâmetro da rede, tamanho das tabelas de roteamento, capacidade da rede de responder a eventos de falhas ou convergência do plano de controle.<br /> * O protocolo de roteamento OSPF é indiscutivelmente mais escalável que os protocolos vetores de distância sobre os quatro pontos discutidos acima.<br /> * Não somente isto: os protocolos vetores de distância não são recomendados para ambientes de ISP, pelo menos no que diz respeito ao roteamento das redes internas do ISP, mas podem atuar (RIPv2) numa relação PE-CE em um serviço L3VPN MPLS.<br /> <br /> * O RIP possui diâmetro máximo de 15 saltos, o que é muito pouco para as infraestruturas de rede de muitos anos pra cá. O OSPF não possui limitações tangíveis quanto ao diâmetro da rede, embora haja a necessidade de boas práticas para a construção de uma rede hierárquica e também do projeto com áreas.<br /> * O OSPF escala muito bem e para redes muito grandes, mas &lt;u&gt;desde que&lt;/u&gt; sejam observadas boas práticas, um bom e eficiente projeto de áreas, ''tuning'' (&quot;ajuste fino&quot;) de temporizadores de mensagens e computação de LSDB, sumarização de rotas, etc.<br /> * A escalabilidade entre ambos o RIP e OSPF é gritante também no que diz respeito à quantidade de informações (rotas) que podem ser mantidas na tabela de roteamento. Como o RIP obrigatoriamente tem que anunciar todas as suas rotas a cada 30 segundos, o processamento é severamente impactado, o que, consequentemente, limita a escalabilidade da rede.<br /> * Em ambos os casos (RIP e OSPF), a escalabilidade pode ser maior com o uso adequado da sumarização de rotas, embora que a escalabilidade do OSPF será sempre muito maior. Para a sumarização efetiva, são fundamentais as boas práticas para a hierarquia da rede (que, no OSPF, é mandatória), e um bom plano de endereçamento IP.<br /> |-<br /> |'''Confiabilidade da Convergência'''<br /> |Outra área funcional em que o OSPF aplica uma verdadeira &quot;surra&quot; no RIPv2. Caso você não compreenda bem o termo, a &quot;convergência&quot; pode ser esclarecida da seguinte forma:<br /> <br /> &quot;''O tempo gasto, além da eficiência do procedimento, com a propagação de um evento na rede (ex: link down ou link up) para todos os roteadores, e até que todos estes tenham concluído a propagação deste evento, assim como concluído todos os procedimentos de reprogramação de suas estruturas de dados (ex: RIB)''&quot;.<br /> <br /> Isto significa que a convergência é qualificada tanto na hora de &quot;difundir&quot; o evento através da rede (remoção de rotas ou adição de rotas) entre todos os roteadores, quanto da conclusão da recomputação de suas estruturas de dados, resultando, consequentemente, em tabelas de roteamento 100% atualizadas quanto aos destinos conhecidos da rede.<br /> <br /> O protocolo RIPv2 é precário neste sentido. Ambientes RIP podem levar até 180 segundos para convergir acerca do entendimento de algumas poucas rotas, e até 240 segundos para reconhecer que uma determinada rede IP não está mais acessível.<br /> <br /> O OSPF, por sua vez, é infinitamente mais vezes ágil no que diz respeito a este tão importante procedimento. Por isto citamos que &quot;''o OSPF converge rapidamente''&quot;.<br /> <br /> E, para concluir aqui, uma das situações mais conhecidas envolvendo os protocolos Distance Vector e Link-State: protocolos como o RIP não possuem conhecimentos topológicos da rede, e sobrevivem com o recebimento de informações (rotas) de &quot;segunda-mão&quot;. Por exemplo: &quot;''o meu vizinho me contou que tem uma rede 'X' com 'n' saltos de distância''&quot;.<br /> <br /> Ou seja, tudo o que aquele roteador realmente conhece são os seus roteadores &quot;vizinhos&quot; (lembrando que não há vizinhanças de fato no RIP!), que são os roteadores conectados na mesma subrede IP que ele.<br /> <br /> O OSPF é completamente diferente disto: cada roteador OSPF possui detalhamentos topológicos de todos os roteadores e interfaces OSPF em uma área! Quem é o mais confiável aqui, um protocolo que sobrevive de &quot;rumores&quot; ou um protocolo que fornece um mapa de toda a topologia de uma área? Acho a pergunta até desnecessária, mas...<br /> |-<br /> |'''Prevenção de Loops de Roteamento'''<br /> |Se em alguma ocasião na sua rede você deparou-se com uma mensagem &quot;''TTL expired in transit''&quot; ou &quot;''TTL expirado em trânsito''&quot; durante um teste de conectividade com &quot;ping&quot;, então você já sabe o que é um loop no roteamento da rede.<br /> Loops L3 em redes são comuns principalmente nas seguintes situações:<br /> * ''Configuração incorreta do roteamento estático'', mesmo em ambientes onde há um protocolo de roteamento em operação.<br /> * ''Falhas na convergência do protocolo de roteamento'', geralmente por erros no projeto técnico e/ou configuração nos elementos.<br /> * ''Bugs no software de um ou mais equipamentos'', um cenário raro.<br /> <br /> O fato é que o OSPF é absurdamente muito mais seguro nesta questão de prevenção de loops. Resta você saber o &quot;por que&quot;?<br /> <br /> Falando (e mal) do RIP aqui. Este protocolo implementa alguns procedimentos para este propósito que são o ''counting to infinity, split horizon, poison reverse'' e ''holddown timers''. Estes mecanismos é o que limitam o diâmetro da rede RIP para 15 saltos apenas, assim como provocam a sua convergência bem lenta.<br /> <br /> Por sua vez, o OSPF é uma história completamente diferente, e isto será detalhado em outra ocasião. <br /> <br /> A principal razão desta eficiência do OSPF está no seu conceito de solução mesmo, que é o projeto de Áreas OSPF: roteadores posicionados em uma mesma área OSPF possuem rigorosamente as mesmas informações e nas mesmas características e qualidades de detalhes. Isto fornece a '''''noção topológica''''' de todas as redes daquela área.<br /> <br /> Como um roteador OSPF poderá errar ou equivocar-se e provocar um loop, se ele sabe ou conhece toda a topologia da área? Só se: ''a) você configurou alguma coisa de forma incorreta, b) o seu projeto tem falhas de abordagens de roteamento, c) você tem um problema (bug) no seu software''.<br /> <br /> Em suma, no que diz respeito à questão de prevenção de loop, o OSPF é um protocolo extremamente seguro, e fornece excelente imunidade quanto a este tipo de incidente, ao contrário do RIP, que possui baixa imunidade.<br /> |-<br /> |'''Maior sofisticação e controle de operação do IGP'''<br /> |Em termos mais práticos, o protocolo de roteamento OSPF é bem superior ao RIP, um Distance Vector, no que diz respeito a alguns recursos periféricos mas que podem ser importantes e/ou exigidos em projetos de redes de ISPs. <br /> Facilidades tais como ajustes nos temporizadores do protocolo e nos mecanismos de recomputação podem promover ganhos adicionais de confiabilidade e a redução do overhead de processamento.<br /> <br /> Em adição, as ferramentas de controle e manipulação das rotas OSPF são mais avançadas e apropriadas do que os mecanismos e recursos suportados por protocolos não Link-State.<br /> |-<br /> |'''Compatibilidade nativa com o MPLS Traffiic Engineering'''<br /> |Para poder encerrar os &quot;pros e contras&quot; e justificar de forma definitiva os motivos pelos quais um protocolo Link-State (seja o OSPF ou o IS-IS) deve ser utilizado por operadores de redes de telecomunicações ou ISPs.<br /> Projetos de infraestrutura IP+MPLS que necessitem ou almejem a engenharia de tráfego por MPLS exigem, por obrigação, o suporte a um IGP compatível com as extensões de engenharia de tráfego por MPLS. <br /> <br /> A indústria, ao invés de criar um novo protocolo para isto - além do RSVP-TE, que provê a sinalização, controle de admissão de túneis, e o fornecimento do ''label'' para TE - resolveu fazer o óbvio, que foi aproveitar os protocolos Link-State existentes para que estes pudessem acomodar as extensões de TE.<br /> <br /> E, adivinhe? O OSPF e o IS-IS são os únicos protocolos de roteamento IGP que suportam o MPLS TE. Não há como implementar o MPLS TE sem o OSPF ou o IS-IS na sua rede. Ponto final.<br /> |-<br /> |'''Compatibilidade nativa com o Segment Routing'''<br /> |Mesmo com o advento do Segment Routing como tecnologia que se propõe a substituir gradualmente as redes MPLS clássicas, novamente, isto só é viável com protocolos de roteamento Link-State, ou seja, o OSPF ou o IS-IS. <br /> No caso do Segment Routing, todas as funções de ''label switching'' e de engenharia de tráfego fluem diretamente pelos componentes destes protocolos de roteamento IGP. Portanto, sem OSPF ou IS-IS, não há como adotar o SR em sua rede.<br /> |}<br /> <br /> === O OSPF não morreu! ===<br /> Não estou acreditando que tive que editar este artigo (edição: 30-05-2020) e gastar o meu tempo para ter que explicar alguma coisa sobre esta falácia de que o OSPF morreu ou que as empresas estão deixando de usá-lo. Vamos a alguns fatos rápidos:<br /> * Se você possui uma rede de médio porte e o seu '''''&lt;u&gt;Core&lt;/u&gt;'''''/backbone ainda for L2, principalmente no caso de ISP, tem alguma coisa muito errada com... VOCÊ. Aparentemente você não entende muito das coisas, mas fique a vontade para refutar. Numa rede corporativa/LAN, o L2 é aceitável, embora haja soluções melhores (SD-Access, SD-LAN, e outras). No ISP, jamais. No data center, a recomendação é por VXLAN, com ou sem o EVPN (recomendado).<br /> * Você pode construir e manter redes de Acesso no ISP baseadas no L2, mas, por que você faria isto? Certamente não seria por motivos de maior eficiência, disponibilidade, resiliência ou confiabilidade, pois, redes L2 nativas, independentemente do protocolo de resiliência e de como funciona a arquitetura L2 do equipamento que você usa, jamais serão mais confiáveis, flexíveis e escaláveis que redes L3 onde o OSPF for o IGP. Então só me restam três argumentos possíveis:<br /> ** '''''&lt;u&gt;Custos&lt;/u&gt;'''''. A classe de equipamento que você usa na sua rede não suporta os recursos necessários para um projeto com tecnologias mais apropriadas, então você é obrigado a recorrer ao L2 e recursos complementares.<br /> ** '''''&lt;u&gt;Falta de conhecimento do MPLS&lt;/u&gt;'''''. Mesmo que o foco aqui seja o OSPF, por se tratar de uma rede de Acesso, você eventualmente precisará transportar serviços Ethernet/L2 sobre esta rede, em adição a outros serviços. Se a rede de Acesso e/ou backbone for baseado no OSPF, você precisará do MPLS para poder acomodar no topo deste uma emulação e transporte de serviço Ethernet, ou seja, fazendo isto por meios das tecnologias clássicas de L2VPN (VPLS, VPWS), ou partindo já para o Ethernet VPN (EVPN)<br /> ** Há uma terceira sugestão aqui: você pode ter redes de Acesso com diâmetro adequado (não excessivamente extensas) contando com um bom protocolo de resiliência (ex: EAPS, G.8032, REP) interconectadas por um backbone MPLS, talvez isto fosse promover o melhor equilíbrio entre funcionalidades, KPIs como a disponibilidade + confiabilidade, e custos. E isto é tido como um ''&lt;u&gt;bom projeto&lt;/u&gt;''. Mas isto não seria melhor do que uma rede inteiramente MPLS com serviços L2VPN no topo, e tendo como o IGP para viabilizar isso tudo o OSPF ou o IS-IS.<br /> Tendo dito tudo isto, informo ainda que o OSPF não só não morreu como cada vez mais as empresas o utilizam. Há muitos anos, e cada vez mais, redes inteiras dos maiores operadores de redes do mundo tem sido migradas para arquiteturas baseadas no MPLS, e, por esta e outras razões, o OSPF passa a ser uma exigência incondicional nestes projetos por conta das necessidades por engenharia e proteção de tráfego com o MPLS-TE + FRR. Ou então com o IS-IS.<br /> <br /> Para concluir, mais recentemente, operadores tem aos poucos migrado as suas infraestruturas para a nova geração de arquiteturas baseadas no MPLS, neste caso para o Segment Routing. O que os &quot;terraplanistas da telecom&quot; não sabem é que o Segment Routing é uma tecnologia viabilizada ''&lt;u&gt;integralmente&lt;/u&gt;'' por um protocolo IGP do tipo Link-State, ou seja, funciona diretamente pelo OSPF ou IS-IS. Sem OSPF (ou o IS-IS), simplesmente não há Segment Routing.<br /> <br /> Os desafios de redes L2 nativas em ambientes de ISP são apresentados de forma bastante objetiva e didática neste video aqui:<br /> <br /> [https://youtu.be/_djmAf0GMgc Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte - Leonardo Furtado]<br /> <br /> E, outra revisão disto, mas já mirando a adoção do Segment Routing e do Ethernet VPN, também aqui, neste vídeo:<br /> <br /> [https://youtu.be/zSiFtIgT1Ig Adoção de Tecnologias Cisco - Leonardo Furtado]<br /> <br /> Agora, voltemos à programação normal! Assunto encerrado.<br /> <br /> === Conclusão do artigo ===<br /> Espero que este artigo tenha cumprido com a sua missão, que foi, ao mesmo tempo, disseminar boas práticas para a configuração do OSPF em redes de ISPs, assim como esclarecer um pouco mais sobre os fundamentos do OSPF para os &quot;mais leigos&quot;.<br /> <br /> Até o próximo artigo!<br /> <br /> '''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''<br /> [[Categoria:Roteamento]]<br /> [[Categoria:BCOPs]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Conteudos&diff=2486 2020-05-31T00:38:34Z

<p>Leonardo.furtado: </p> <hr /> <div>== Conteúdos para os Operadores de Redes ==<br /> [[Arquivo:Content-BW.png|commoldura]]<br /> Nesta página você encontrará os links para os diversos artigos, how-tos, tutoriais e vídeos produzidos no âmbito do BPF e direcionados à Comunidade de Internet Brasileira. O intuito é que eles sejam úteis para o dia a dia de operação de redes, infraestrutura, boas práticas e assuntos relacionados.<br /> <br /> Para escrever um novo artigo, how-to ou tutorial e compartilhá-lo é necessário criar antes um usuário na Wiki. Existe um artigo com orientações gerais sobre [[Como Escrever na Wiki]]. Após finalizar o artigo não esqueça de indexá-lo nesta página como também compartilhar conosco na lista de emails.<br /> <br /> Caso haja interesse em publicar algum material mais completo ou algum projeto envie um email para a lista de discussão geral abordando o assunto de interesse para verificar se já existe alguém o alguma Task Force trabalhando neste assunto ou ainda verifique se já existe algo mais específico em alguma das Task Forces temáticas. Toda contribuição da comunidade é bem vinda e incentivada.<br /> <br /> Para facilitar os artigos e materiais publicados abaixo são separados por assuntos.<br /> == Direitos Autorais, Licença de Uso e Termo de Responsabilidade ==<br /> Todos os conteúdos, contribuições e obras publicados pelo Brasil Peering Forum (BPF) estão licenciados com uma '''Licença Creative Commons Atribuição-NãoComercial 4.0 Internacional'''. Consulte o nosso [[Direitos Autorais Licenca de Uso|Termo de Responsabilidade]] para verificar a licença, os direitos e restrições de uso, assim como as devidas isenções de responsabilidades.<br /> <br /> == Artigos ==<br /> <br /> === Geral ===<br /> * [[Como Escrever na Wiki]] - Passo a Passo de como criar um novo artigo e contribuir com a Wiki do BPF.<br /> * [[Assinatura MoU BPF]] - Assinatura do Memorando de Entendimento entre os membros da Board e Comitê de Programa do BPF.<br /> * [[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]] - Aqui reunimos expressões, acrônimos e termos conhecidos referentes ao universo de telecomunicações e ISPs.<br /> <br /> === BCOPs ===<br /> * [[Boas Praticas para Melhorar a Seguranca de seu Provedor]]‎‎ - Boas práticas a serem seguidas para melhorar a segurança de seu Provedor.<br /> * [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] - Artigo que dissemina várias áreas de atenção e práticas para o aumento da segurança da rede do Provedor.<br /> * [[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]] - Artigo dissertativo sobre boas práticas para a escolha, adoção e manutenção de software de equipamentos de redes.<br /> * [[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]] - Artigo que apresenta boas práticas e sugestões para a documentação de ambientes de redes.<br /> * [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas praticas para a implantacão do OSPF em ambientes de ISP]] - Artigo discorrendo sobre 12 boas práticas em situações envolvendo OSPF em ambientes ISP.<br /> <br /> === DNS ===<br /> * [[Porque usar um DNS local e algumas dicas para isto]] - Artigo explicativo das razões porque é uma boa prática para um ISP possuir servidores DNS Recursivos próprios do que direcionar o usuário para um servidor público.<br /> * [[DNSSEC Seguranca do DNS|DNSSEC - Seguranca do DNS]] - Artigo conceitual explicando o funcionando do DNSSEC baseado no documento DNSSEC: Securing DNS publicado pela ICANN.<br /> <br /> === Infraestrutura ===<br /> * [[Compatibilidade de GBICs e Cabos Twinax|Compatibilidade de GBICs e cabos Twinax]] - Banco de dados colaborativo sobre experiências de uso de GBICs e cabos Twinax em Roteadores e Switches<br /> * [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]] - Artigo um tanto extenso e completo cobrindo os fundamentos de programabilidade de redes<br /> <br /> === Interconexão ===<br /> * [[Modelos Interconexão]] - Artigo sobre os modelos de interconexão Peering e Trânsito<br /> * [[Looking Glass]] - Artigo com uma lista de Looking Glass nacionais e internacionais<br /> * [[CDN Peering e PNI - Brasil]] - Lista com as principais CDNs, instruções de como solicitar Servidores, Sessões Bilaterias no IX e PNIs.<br /> <br /> === Roteamento ===<br /> * [[Dimensionando Roteador para BGP]] - Considerações a serem levadas em conta ao adquirir um novo Roteador para BGP<br /> * [[Engenharia de Trafego com MPLS TE]]‎ - Artigo explicando o funcionamento do MPLS com Traffic Engineering<br /> * [[Balanceamento de Trafego em Redes MPLS]] - Artigo explicando o funcionamento de distribuição de tráfego em redes MPLS<br /> * [[Redes MPLS para Provedores]] - Artigo explicando as vantagens e benefícios de infraestruturas do provedor baseadas no MPLS<br /> * [[Fundamentos de Roteamento para Provedores]] - Artigo explorando os fundamentos de funções de Camadas 2 e 3, comutação e roteamento, em redes Ethernet IP para provedores<br /> * [[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]] - Artigo explicando as necessidades e opções para a proteção e resiliência de redes Ethernet para provedores<br /> * [[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]] - Artigo abordando as tecnologias 6PE e 6VPE em regime BGP Free Core com MPLS TE. Inclui vídeos demonstrativos<br /> * [[Introducao ao Unified MPLS|Introdução ao Unified MPLS]] - Artigo explicando a adoção do MPLS em infraestruturas de redes de grandes operadores. Inclui vídeo demonstrativo<br /> * [[Lista de Communities BGP]] - Listagem com as Communities disponibilizadas pelos principais Operadores de Trânsito IP e Internet Exchanges<br /> * [[Diferenca entre AS-OVERRIDE e ALLOWAS-IN]] - Explicação básica sobre a diferença entre os dois mecanismos anti-loop do protocolo BGP<br /> * [[Construção de Redes de Gerenciamento OOB para o ISP]] - Artigo dissertativo sobre conceitos de gerenciamento e redes Fora-de-Banda (OOB)<br /> * [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]] - Artigo explicando muitas das diferenças entre as soluções L2VPN MPLS tradicionais e o Ethernet VPN. Inclui vídeos demonstrativos<br /> * [[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]] - Artigo bem dissertativo de conceitos fundamentais que todo profissional de ISP precisa saber a respeito do BGP<br /> * [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]] - Artigo bastante didático e esclarecedor sobre as tecnologias e ferramentas para o QoS.<br /> * [[O Minimo que voce precisa saber sobre DDoS]] - Artigo explicando diferenças entre ataques DDoS e maneiras de se prevenir e mitigar.<br /> * [[Redes que descartam RPKI Invalidos]] - Uma introdução rápida ao RPKI além de listar as operadoras e provedores de trânsito Internet que já implementam o descarte de prefixos inválidos.<br /> * [[O Minimo que Voce precisa saber sobre IRR]] - Artigo explicando o que é IRR, a importância do uso, principais bases e com um tutorial de como adicionar informações em uma base.<br /> * [[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]] - Artigo bastante completo dissertando sobre o gerenciamento e monitoramento do BGP em um Sistema Autônomo.<br /> <br /> === Transmissão ===<br /> * [[Sistemas DWDM de Baixo Custo]] - Artigo explicado sobre como projetar um sistema DWDM de baixo custo<br /> <br /> === Capacitação ===<br /> * [[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]] - Artigo didático que comenta boas práticas para ações de suporte na rede do ISP<br /> * [[Aprimorando a Disponibilidade da rede do ISP]] - Artigo com vídeo explicando os fundamentos de disponibilidade das infraestruturas de redes do provedor<br /> * [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]] - Artigo que destaca positivamente o eTOM BPF do Frameworx como conceito de remodelagem de operação e de negócios de ISPs<br /> <br /> == How-tos e Tutoriais ==<br /> <br /> === Geral ===<br /> * [[Como reportar abusos ao Google]] - Instruções sobre como reportar servidores com conteúdos maliciosos hospedados pelo Google<br /> * [[Como configurar o Winbox no MacOS Catalina]] - Tutorial sobre como executiar o Winbox em 64Bits no MacOS Catalina<br /> <br /> === DNS ===<br /> * [[Melhorando a performance e resiliencia da rede com Recursive DNS Anycast|Melhorando a performance e resiliência da rede com Recursive DNS Anycast]] - Tutorial que apresenta uma técnica interessante para maior disponibilidade e desempenho dos servidores DNS para os provedores<br /> <br /> === Boas Práticas ===<br /> * [[Boas práticas de segurança para roteadores Mikrotik]] - How-to com orientações de segurança e regras a serem aplicadas em roteadores Mikrotik rodando RouterOS.<br /> * [[Como consultar e corrigir a geolocalizacao de seus IPs|Como Consultar e Corrigir a Geolocalização de IPs]] - Tutorial explicando como consultar e corrigir as informações de geolocalização de alocações de um ASN.<br /> * [[MANRS]] - Passo a passo de como cumprir todos os requisitos do MANRS e para se ter um Sistema Autônomo e uma Internet mais segura<br /> * [[PeeringDB - como se cadastrar e atualizar seus dados|PeeringDB - Como se cadastrar e atualizar seus dados]] - Passo a passo de como realizar o cadastro no PeeringDB e preencher as informações necessárias<br /> <br /> === Edge ===<br /> * [[Concentradores PPPoE com IPv6]] - Como habilitar suporte a IPv6 e distribuição de prefixos para usuários finais em diferentes concentradores.<br /> <br /> === Infraestrutura ===<br /> * [[Log de Portas de Origem em Servidores Web]] - Como adicionar a porta de origem ao log dos Servidores Web e ser capaz de identificar usuários atrás de CGNAT.<br /> * [[CGNAT na pratica|CGNAT na prática]] - Tutorial sobre como configurar um servidor Linux com netfilter para CGNAT com ajustes de configurações voltadas para performance.<br /> * [[Tutorial DNS Hyperlocal]] - Tutorial descrevendo como hospedar uma cópia da zona raiz de DNS para que os servidores Recursivos locais possam consultar com maior performance e eficiência.<br /> * [[Monitoramento-telegraf|Monitoramento Telegraf]] - Como configurar uma solução Telegraf + InfluxDB + Grafana para monitoramento via ICMP de destinos desde diferentes endereços de origem.<br /> * [[Como Ter Seu Proprio Looking Glass|Como Ter Seu Próprio Looking Glass]] - Tutorial ensinando como o ISP poderá facilmente disponibilizar seu próprio Looking Glass para visibilidade e suporte à problemas com o BGP.<br /> * [[Como capturar pacotes no Mikrotik]] - Tutorial ensinando como realizar captura de pacotes no Mikrotik visando a análise e depuração de protocolos e conversações.<br /> * [[Como Monitorar 95th percentile]] - Tutorial demonstrando como monitorar tráfego 95th percentile para cobrança de clientes e possibilidade de exportar dados através de um script.<br /> * [[Orquestrando sua rede com Ansible e Gitlab]] - Tutorial ensinando a utilizar modelos de dados, em uma estrutura CI/CD com Ansible e GitLab.<br /> * [[464XLAT utilizando a ferramenta Jool]] - Tutorial sobre como configurar um ambiente utilizando o mecanismo de transição 464XLAT com a ferramenta Jool.<br /> * [[CGNAT com F5 BIG-IP]] - Tutorial de apresentação e demonstração da solução de CGNAT com a plataforma F5 BIG-IP.<br /> <br /> === Interconexão ===<br /> * [[Ajustes de ARP Cache para o IX]] - Tutorial explicativo da problemática do ARP cache e comandos para serem aplicados em múltiplos vendors para melhor operação no IX.<br /> <br /> === IPv6 ===<br /> * [[IPv6 no TPLink WR840N v2]] - Como ativar IPv6 na CPE TPLink WR840N v2<br /> * [[IPv6 na ONU Huawei HS8546 v2]] - Como ativar IPv6 na ONU Huawei HS8546 v2<br /> * [[IPv6 no Mikrotik CPE]] - Como ativar IPv6 em uma CPE Mikrotik (RouterOS)<br /> * [[IPV6 no Ubiquiti AirOS6|IPv6 no Ubiquiti AirOS6]] - Como ativar IPv6 em uma CPE Ubiquiti com AirOS6<br /> * [[IPV6 no Ubiquiti AirOS8|IPv6 no Ubiquiti AirOS8]] - Como ativar IPv6 em uma CPE Ubiquiti com AirOS8<br /> * [[Ipv6-TL-WRN849N|IPv6 no TPLink WRN849N]] - Como ativar IPv6 em uma CPE TPLink WRN849N<br /> * [[IPV6 no Intelbras Wom|IPv6 no Intelbras WOM]] - Como ativar IPv6 em uma CPE Intelbras WOM 500, WOM 5000 MIMO, WOM 5a-23 e WOM 5a MIMO<br /> * [[IPv6 no Dlink Dir-615|IPv6 no Dlink DIR 615]] - Como ativar IPv6 em uma CPE Dlink DIR 615, DIR 608, DIR 610 e DIR 611<br /> * [[IPV6 no DLINK DIR-882|IPv6 no D-Link DIR-882]] - Como ativar IPv6 em uma CPE D-Link DIR-882<br /> * [[Acesso via IPv6 Link-Local]] - Uma maneira de acessar equipamentos via IPv6 Link-Local em caso de perda de conectividade por IPv4<br /> * [[Como Ativar IPv6 em Servicos de Hosting e CDN]] - Tutorial sobre como ativar IPv6 nos serviços de Hosting e CDN mais utilizados<br /> * [[Servidor DNS Recursivo com IPV6 e DNSsec]]- Mini tutorial sobre IPv6 e DNSsec em DNS recursivo Unbound.<br /> * [[Gerando Log de IPv6 Delegation no Mikrotik]] - How to explicando como registrar em um servidor Syslog o Prefixo IPv6 entregue para o usuário em concentradores Mikrotik<br /> <br /> === Roteamento ===<br /> * [[Como fazer com que um determinado conteudo saia por um link especifico|Como fazer com que um determinado conteúdo saia por um link específico]] - Tutorial bem objetivo ensinando como manipular o roteamento para o recebimento de tráfego em seu AS<br /> * [[Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei|Configuração de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei]] - Tutorial sobre como configurar filtros usando XPL em Huawei<br /> * [[UTRS Registro e Configuracao|UTRS - Registro e Configuração]] - Artigo que explica o funcionamento do serviço UTRS do Team Cymru, passo a passo para solicitação e configurações exemplo.<br /> * [[Protegendo seu ASN com RPKI]] - Tutorial que ensina como implementar o Krill para habilitar e autorizar o ROA para o seu ASN.<br /> <br /> == Tech Notes ==<br /> Esta seção contém contribuições fornecidas por fabricantes (&quot;''vendors''&quot;) acerca de suas soluções, tecnologias disponíveis, diferenciais de mercado e afins.<br /> * [[Otimizacao de balanceamento de tráfego em Link Aggregation utilizando DLB e FAT em switches Datacom|Otimização de balanceamento de tráfego em Link Aggregation utilizando DLB &amp; FAT em switches Datacom]] - Artigo dissertativo acerca das soluções DLB e FAT do portfólio de switches da Datacom<br /> <br /> == Informativos ==<br /> Os informativos do Brasil Peering Forum são editados de forma quinzenal, dependendo do conteúdo e relevância e contém as principais notícias e novidades do mercado de Infraestrutura de Telecom e Internet.Todos eles são também enviados para a [https://listas.brasilpeeringforum.org/mailman/listinfo/bpf Lista Pública de Discussão] do BPF. Inscreva-se para receber as notificações.<br /> * [[Informativo Infra 01]] - 16/09/2019<br /> * [[Informativo Infra 02]] - 22/09/2019<br /> * [[Informativo Infra 03]] - 25/10/2019<br /> * [[Informativo Infra 04]] - 04/11/2019<br /> * [[Informativo Infra 05]] - 17/11/2019<br /> * [[Informativo Infra 06]] - 02/12/2019<br /> * [[Informativo Infra 07]] - 29/12/2019<br /> * [[Informativo Infra 08]] - 26/01/2019<br /> * [[Informativo Infra 09]] - 16/02/2020<br /> * [[Informativo Infra 10]] - 09/03/2020<br /> <br /> == Vídeos ==<br /> <br /> === Eventos ===<br /> * [https://www.youtube.com/watch?v=KG2JZ0A_9yY Painel sobre Peering ocorrido durante o Future ISP em Maio de 2018]<br /> * [https://www.youtube.com/watch?v=8GVHB52qu5k Apresentação do Brasil Peering Forum feita por Uesley Correa]<br /> * [https://www.youtube.com/watch?v=SE8YEuVXMWQ Dever de Casa e o Impacto da Negligência Técnica e Administrativa de Participantes do IX-BR], por Elizandro Pacheco no IX Forum 12<br /> * [https://www.youtube.com/watch?v=2oq7pMBF7Oc Tudo que você gostaria de saber sobre transmissões ópticas e WDM], por Tiago Setti no IX Forum 12<br /> * [https://www.youtube.com/watch?v=Obh98S5xyQA Automatização de Listas de Prefixos em Peering BGP - Como fazer e sua importância], por Douglas Fischer no GTER 46<br /> * [https://www.youtube.com/watch?v=hbEC2Sf5o20 BIER: Evolução do IP Multicast, por Tiago Setti] no GTER 46<br /> * [https://www.youtube.com/watch?v=H-m0sKr8I0Q Problemas e soluções na identificação de usuário IPv6 usando RouterOS], por Uesley Correa no GTER 46<br /> * [https://www.youtube.com/watch?v=WjSps5huDGU Painel - Trânsito Burstable com 95th] percentil, por Fernando Frediani, Fábio Monteiro, Edivan Silva e Tiago Setti no GTER 46<br /> * [https://www.youtube.com/watch?v=4-77r2PGKB4 BSDRP - Uma opção de softrouter com FRR], por Antonio Donizeti Corazza Jr no GTER 46<br /> * [https://www.youtube.com/watch?v=CjTcI0-UApI Ataques DDoS como ação anti-competitiva: prevenção, mitigação e reação], por Thiago Ayub no GTER 46<br /> * [https://youtu.be/qBD7zCnbTF4 Automatização de Listas de Prefixos em peering BGP], por Douglas Fischer no LACNIC 31/FTL<br /> * [https://youtu.be/8DdtN_fj_uQ BSDRP - Uma opção de sofftrouter com FRR], por Junior Corazza no LACNIC 31/FTL<br /> * [https://www.youtube.com/watch?v=utPs-sXsOZg A importância de um CGNAT bem feito], por Fernando Frediani no GTER 47<br /> * [https://www.youtube.com/watch?v=l2tVyz1Ba1A Entrevista sobre ataques e mitigação DDoS], com Thiago Ayub<br /> * [https://youtu.be/ElA_71zsc6Y Entrevista com o Carlos Martínez sobre RPKI], com Carlos Martínez, CTO do LACNIC, na 9a Semana de Infraestrutura da Internet no Brasil.<br /> <br /> === Hangouts ===<br /> [https://www.youtube.com/watch?v=fy4efZZ-yvg Desmistificando o CGNAT] - Hangout realizado para debater o assunto e desmistificar esta necessidade dos ISPs. Durante a conversa foram abordadas boas práticas, diferentes modelos de CGNAT, problemas com Jogos e um case prático.<br /> <br /> [https://www.youtube.com/watch?v=ePMfMv3UVOs Boas Práticas de DNS] - Hangout realizado que debateu as melhores práticas para se ter um bom serviço de DNS rodando no seu provedor, a importância de ter seu DNS Reverso configurado corretamente, quando é necessário ter um servidor Autoritativo, DNSSEC e assuntos relacionados.<br /> <br /> === Roteamento e MPLS ===<br /> * [https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores], por Leonardo Furtado<br /> * [https://www.youtube.com/watch?v=5Eg5jC2AMaQ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Parte 1] (Introdução), [https://www.youtube.com/watch?v=W8HS_y7REiM Parte 2] (Introdução ao L3VPN), [https://www.youtube.com/watch?v=TqdZYK_9rlY Parte 3] (Demonstração de Interconexões com L3VPN MPLS), [https://www.youtube.com/watch?v=bmgWGOPbkfw Parte 4] (Demonstração da Solução Carrier Supporting Carrier - (CsC)), [https://www.youtube.com/watch?v=H4SyKiGBOXM Parte 5] (Demonstração de L3VPN MPLS com VPNs &quot;Complex Overlapping&quot;), [https://www.youtube.com/watch?v=6fQ34nnk-Dk Parte 6] (Demonstração de L2VPN MPLS com AToM/EoMPLS/VPWS), por [[Usuário:Leonardo.Furtado|Leonardo Furtado]].<br /> * [https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE], por Leonardo Furtado.<br /> * [https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1] e [https://youtu.be/0N-ejxGncSU Parte 2], por Leonardo Furtado.<br /> * [https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS], por Leonardo Furtado.<br /> * [https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN], por Leonardo Furtado.<br /> * [https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP, da Comunidade de Suporte Cisco em Português], por Leonardo Furtado.<br /> * [https://youtu.be/zSiFtIgT1Ig Palestra de Evoluções de Tecnologias MPLS com Segment Routing e EVPN] - Future ISP 2018, por Leonardo Furtado.<br /> * [https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing, da Comunidade de Suporte Cisco em Português], por Leonardo Furtado<br /> * [https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP], por Leonardo Furtado<br /> * [https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP], por Leonardo Furtado<br /> * [https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)], por Leonardo Furtado<br /> === Capacitação ===<br /> * [https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP], por Leonardo Furtado<br /> * [https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP], por Leonardo Furtado<br /> * [https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP], por Leonardo Furtado</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2485 2020-05-31T00:18:29Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira, consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos e habilidades. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, juntamente com as devidas habilidades correspondentes aos conhecimentos específicos da área, assim como possíveis outros conhecimentos (periféricos), visando, especificamente, neste caso, o crescimento ou evolução em suas profissões.<br /> # Atitudes e motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem adquirir conhecimentos, habilidades, desenvolver competências, e, consequentemente, evoluir?'''''<br /> <br /> As respostas podem variar de acordo com cada indivíduo, mas a minha resposta mais precisa para esta pergunta seria o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema, na minha opinião, está no método. O método pode estar ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento, e responderá a tantas das perguntas e preocupações que você vive no momento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;. &quot;''Como desenvolver as minhas habilidades?''&quot;)<br /> ** Metodologias didáticas de ensino e aprendizado.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação, aderência e aptidão.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> ** Educação continuada.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, tampouco professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em tantas empresas que já perdi as contas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que reúno bagagem o suficiente para, legitimamente. contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a minha resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''. Há aqueles que adorariam complicar as coisas e sugerir a incorporação de outros elementos e complexidades, tais como condição social, falta de oportunidades, fator &quot;Q.I.&quot; (&quot;Quem Indica&quot;, o famoso contatinho com o &quot;Comandante Faber Castell&quot; lá da empresa), profissional naturalmente desmotivado por ter percebido, após um tempo, que aquela profissão não era para ele, dentre outros fatores e complicações. O fato é, independentemente disso tudo, você &lt;u&gt;jamais decolará&lt;/u&gt; na carreira sem o conhecimento. Seja você rico ou pobre, preto ou branco, nordestino ou sulista, hétero ou homo, evangélico ou ateísta, tudo isso é mínimo se comparado ao que realmente importa para você conseguir deslanchar nesta área, aliás, em qualquer profissão: '''''conhecimento'''''. Você pode até ter ótimos conhecimentos e estar com falta de sorte no momento, mas um indivíduo sem conhecimento é um indivíduo pouco útil para esta ou qualquer carreira ou profissão.Você pode até conseguir um emprego na área com conhecimentos fracos ou medianos, mas, decolar, jamais!<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que conseguíssemos traçar um caminho que de fato pudesse levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos, e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com alguns dos modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, focarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir alguns tipos de conhecimento que são irrelevantes para os meus propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> <br /> OBS: os &quot;''&lt;u&gt;exemplos relacionados à nossa área de TIC&lt;/u&gt;''&quot; da tabela a seguir mesclam, de forma muito íntima e implícita &quot;conhecimento&quot; e &quot;habilidade&quot;, mas saiba de antemão que são coisas distintas. Isto será esclarecido posteriormente neste artigo.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, obtido principalmente por observação, experiência em lidar com os resultados herdados por senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo. Frequentemente obtido com base na tentativa e erro.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> * Entrelaçamento quântico <br /> * Tabela Periódica <br /> * Leis de Newton <br /> * Princípio de Arquimedes <br /> * Algoritmo de Dijkstra <br /> |<br /> * &quot;O ignorante afirma, o sábio duvida, o sensato reflete.&quot; (Aristóteles)<br /> * &quot;Só sei que nada sei.&quot; (Sócrates)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> * &quot;Não existem métodos fáceis para resolver problemas difíceis.&quot; (René Descartes)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> * Aplicar um complexo e plástico golpe de capoeira!<br /> * Arriscar-se com êxito fazendo parkour no alto dos edifícios<br /> Em todos estes casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à nossa área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede com bastante fluidez e obedecendo as guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção sobre a configuração de elementos de rede, relacionando corretamente as áreas funcionais e controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia sendo impulsionada pelo mercado, liderada por um determinado fabricante, centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing.<br /> * &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se de certa forma à favor dos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. <br /> * &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará efetivamente a mesma coisa que as implementações RSVP-TE atuais fazem?&quot;. &quot;Valeria a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?&quot;. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado com marketing/branding do que com soluções técnicas de fato inovadoras?&quot;. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se sempre de incluir o parâmetro &quot;add&quot; para o comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}<br /> Note que não está sendo feito qualquer julgamento em termos de &quot;''que tipo de conhecimento é melhor?''&quot; porque isto simplesmente não existe! Em termos de resultados, ou eficácia, um conhecimento empírico pode ser (e muitas vezes é!) o meio mais correto ou indicado para resolvermos um problema, ou que um conhecimento puramente tácito promova os resultados desejados de forma mais efetiva que com um conhecimento empírico apenas. Um conhecimento científico não é melhor só porque é baseado em alguma teoria aliada à uma comprovação por método, pois um conhecimento filosófico pode resolver, e com alguma frequência isto acontece, um desafio que não está sendo possível resolver com um conhecimento científico; enfim, acho que você me entendeu.<br /> <br /> Caso você não tenha identificado uma afinidade ou utilidade entre esta tabela acima e a proposta deste artigo, algo tipo &quot;tudo muito supérfluo!&quot;, sugiro que repense! Apesar de ter um aspecto um tanto teórico, acho de suma importância você saber identificar como os seus conhecimentos vigentes estão enquadrados ou tipificados. Lá na frente isto poderá ser útil na hora de identificar o que precisa ser feito para aprimorar a maneira como você entende o funcionamento de determinadas tecnologias ou soluções, ou quais práticas e processos precisam ser aprimorados para um suporte mais efetivo destas, dentre outras situações. Alguns exemplos de como este &quot;''drag &amp; drop''&quot; poderia ser feito:<br /> * '''De tudo o que você sabe dissertar ou executar, em sua forma mais prática ou efetiva (implantar, configurar, operar, prestar suporte), ou seja, tecnologias, equipamentos, soluções, processos e afins, o que de fato você:'''<br /> ** '''''Conhece por herança organizacional, seja na empresa atual ou experiências prévias, ou através de convívio e troca de experiências com grupos de indivíduos e suas opiniões?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências. <br /> **** Por exemplo, adquiriu uma habilidade e experiência através de um roteiro, processo interno da empresa (&quot;é assim que você deve fazer&quot;, &quot;assim funciona&quot;, ou &quot;não faça isto!&quot;), modus operandi do setor da empresa, etc.<br /> *** Estes seriam &lt;u&gt;conhecimentos empíricos&lt;/u&gt;!<br /> ** '''''Conhece, por meios de algum processo de validação, e com o emprego de práticas documentadas em artefatos de indústria, BCOPs, frameworks, e com eficácias e resultados tecnicamente comprovados?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, adquiriu conhecimentos e experiência em um projeto e implantação de BGP integralmente apoiado por BCPs (BCP 38, 194, 185, MANRS); uma validação de circuito de dados com base no RFC 2544, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos científicos&lt;/u&gt;!<br /> ** '''''Conhece por questionamentos de princípios de aderência, aplicabilidades, julgamento de utilidade, associação de benefícios e casos de uso?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, adquiriu conhecimentos e experiência em conduzir uma análise qualitativa de riscos ou de uma matriz funcional de qualidade; questionamentos e dissertações de casos quanto ao uso de determinadas tecnologias e soluções, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos filosóficos&lt;/u&gt;!<br /> ** '''''Conhece por experiência e vivência próprias, ou seja, tentativa e erro, satisfação e frustração com resultados, etc.?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, saber identificar e antecipar riscos em determinadas manobras de configuração em função de experiência prévia ruim; saber conduzir uma operação através de uma ordem apropriada, evitando-se problemas de indisponibilidades, também por experiência prévia; saber qual versão de software usar por não conter um bug que, em um caso anterior, provocou um distúrbio na sua infraestrutura; saber que, antes de ativar um recurso no software de seu roteador, por experiência prévia/própria, outro recurso deve estar habilitado como pré-requisito, do contrário não funcionará ou provocará algum tipo de distúrbio, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos tácitos&lt;/u&gt;!<br /> Viu só? Nem tudo o que é teoria é &quot;burocrático&quot;! Há sempre como extrair coisas positivas de muitos conceitos teóricos ou aparentemente abstratos. E vou um pouco além neste discurso sobre como isto poderá ser útil para você. Imagine que você fizesse uma auto-avaliação (aliás, sugiro mesmo que faça isto!), qual seria o resultado? E quais seriam os significados destes resultados? Quanto aos &quot;significados&quot;, eu tecerei uma opinião estritamente pessoal, pois a interpretação de cada caso é realmente bastante individualizada. Eu posso pensar de um jeito, e você de outro completamente diferente. Certo? Caso você tenha interesse em saber como &lt;u&gt;'''eu'''&lt;/u&gt; (autor) penso, estas seriam as minhas respostas:<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;tácita'''''&quot;<br /> <br /> Isto para mim significaria uma coisa: generalizando aqui, você pode até ser bem &quot;safo&quot;, mas desde que seus conhecimentos sejam realmente bem seguros e produzam bons resultados. O que é difícil. Explico o por que. São preocupantes as possíveis (e não confirmadas, por isto estou generalizando) divergências entre o que órgãos de indústria ou fabricantes promovem como recomendações e boas práticas, e o que você de fato executa ou como executa o seu trabalho.<br /> <br /> Com a complexidade cada vez mais crescente das soluções tecnológicas, assim como os padrões de boas práticas operacionais, é pouco provável que um indivíduo majoritariamente &quot;tácito&quot; seja efetivo em suas atribuições, especialmente quando pensando aqui nas tantas métricas sobre as quais deverá estar apoiado todo o funcionamento do aparato tecnológico, ou seja, ''Disponibilidade'', ''Performance'', ''Segurança'', ''Confiabilidade'', ''Disponibilidade'', ''Escalabilidade'', e etc. <br /> <br /> Dificilmente um indivíduo deste perfil conseguiria orquestrar um ambiente com conhecimentos puramente tácitos. &quot;Ah, mas ele estudou o manual do fabricante para fazer o procedimento 'x'!&quot;, mas, peraí, isto não seria um conhecimento tácito! Assim como &quot;ele seguiu o processo da Operação da empresa para fazer a configuração&quot;, mas, peraí, isto também não seria um conhecimento tácito! Compreende a diferença? <br /> <br /> Não consigo vislumbrar um indivíduo majoritariamente &quot;tácito&quot; funcional, pois, tal perfil, seria um risco tremendo para os negócios de uma empresa. Gambiarras e experimentações individualizadas, com pouco ou nenhum apoio e suporte de conhecimentos científicos ou empíricos, não são uma opção! Nesta área de redes e afins, conhecimento tácito é algo muito íntimo e específico (vide os exemplos da tabela anterior), e geralmente são muito bons/úteis como complemento de outras formas de conhecimento, como o científico e o empírico. <br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;empírica'''''&quot;<br /> <br /> Tudo o que um indivíduo aprendeu a executar num ambiente de redes obedecendo algum padrão ou procedimento estabelecido pela empresa ou pelo mercado (&quot;senso comum&quot;), é considerado um conhecimento empírico. Assim como conhecimentos obtidos junto à uma comunidade de especialistas. O que é bom ou muito bom. Especialmente quando o indivíduo passa a entender os cuidados que devem ser observados durante a condução do trabalho em questão. Isto significa que na maior parte do tempo este indivíduo estará conduzindo atividades de acordo com padrões ou modelos confiáveis, realizando configurações, ajustes, manobras, adaptações e afins, tudo inspirado num esqueleto funcional, seguro, e resultados auditáveis ou perceptíveis.<br /> <br /> É nessas horas, inclusive, voltando ao caso anterior, que os conhecimentos &lt;u&gt;tácitos&lt;/u&gt; complementam e fazem a diferença: nem sempre os padrões ou procedimentos são bem elaborados ou seguros; nem sempre as descrições dos requisitos e respectivas tarefas asseguram que o trabalho a ser realizado estará isento de riscos ou que vá funcionar &quot;de primeira&quot;. Como ocorre por muitas vezes, o indivíduo tende a perceber isto e a tomar cuidados extras na hora de conduzir seus trabalhos, podendo usar a sua própria experiência/vivência na hora de fazer as coisas, evitar armadilhas, maximizar resultados, etc. É nessas horas que o indivíduo &quot;safo&quot; usa a sua experiência (conhecimentos tácitos) como complemento aos conhecimentos obtidos de forma empírica ou científica.<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;filosófica&quot;'''''<br /> <br /> Um indivíduo, através de uma demanda cotidiana que implemente ações cujos conhecimentos correspondentes/associados foram obtidos de forma empírica (um procedimento, um processo, um modelo...), não importando em qual estágio de sua carreira ele obteve este conhecimento, poderá eventualmente divergir de opiniões. Poderá não concordar, pelo menos não inicialmente, ou até que seja convencido por alguém. Poderá ponderar, questionar os propósitos imputados ou critérios adotados. E, em função disto, poderá desejar modificar ou aprimorar aquela demanda ou aquele processo. Refinar o método como um todo, ou parte dele. <br /> <br /> Obviamente que, &quot;questionar&quot;, &quot;ponderar&quot;, ou &quot;criticar&quot; apenas, recusando-se a todo custo a cumprir com o seu dever, qualquer que tenha sido a tarefa imputada a ele, eu não chamaria isto de conhecimento filosófico, e sim de &quot;birra de criança&quot;. O conhecimento filosófico não é fazer birra ou ter atitudes antiprofissionais! O que se espera de uma iniciativa correta para estes casos é um perfil questionador de um indivíduo trazendo à tona novos desafios e propósitos para a elaboração de novas respostas, e tudo objetivando efetividade e resultados.<br /> <br /> Isto é uma qualidade de conhecimento que tipifica bem um perfil de profissional centrado em qualidade e resultados, e vemos isto muito presente em arquitetos de soluções, alguns perfis de gestores, e até mesmo em engenheiros de redes e analistas.<br /> <br /> === Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC ===<br /> Fugindo aqui momentaneamente deste discurso de tipo de conhecimentos, e retornando ao tema de motivações abordado previamente, mas, desta vez, incorporando justificativas e argumentos na fórmula, quais são as principais motivações, justificativas e argumentos para que um indivíduo vá buscar efetivamente conhecimentos relacionados aos temas da área de TIC? Tentemos exercitar isto de forma ampla e um pouco generalista, desprezando as individualidades que movem o coração de cada um de nós. Talvez eu esteja acertando em boa parte sobre tudo o que está sugerido a seguir, mas é bem provável também que você mesmo possua seus próprios argumentos, justificativas e motivações.<br /> {| class=&quot;wikitable&quot;<br /> |+Alguns casos de argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC<br /> ! colspan=&quot;3&quot; |Argumentos<br /> |-<br /> !Requisitos para Funções Vigentes<br /> !Requisitos para Funções Futuras<br /> !Requisitos para Prospecções e Planos de Carreira<br /> |-<br /> |Obter as qualificações e competências para a conformidade com requisitos vigentes, os quais são estabelecidos pelo empregador.<br /> |Aprendizado e domínio de novas tecnologias, equipamentos ou ferramentas, como parte de um processo de adoção tecnológica na empresa, os quais são impostos ou estabelecidos pelo empregador.<br /> |Obter as qualificações e competências exigidas para enquadramento de perfil junto à uma vaga ou oportunidade pretendida pelo mercado de trabalho.<br /> |-<br /> |Aprimorar as habilidades em alinhamento com os requisitos vigentes, os quais são impostos ou estabelecidos pelo empregador.<br /> |Aprimoramento e domínio de habilidades para remodelagem em futuro próximo de componentes, processos e práticas vigentes, e a extração de melhores resultados com o uso de tecnologias atuais, em grande parte por iniciativa própria.<br /> |Obter as qualificações e competências exigidas visando a evolução ou crescimento de carreira, na mesma empresa em que atua no momento ou em outras oportunidades e prospecções.<br /> |-<br /> ! colspan=&quot;3&quot; |Justificativas<br /> |-<br /> |O empregador produz a descrição do cargo que você ocupa (&quot;''job description''&quot;), estabelecendo os pré-requisitos para a função, dentre habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |Tecnologias evoluem. Equipamentos e software ficam obsoletos. Novas ferramentas e solução são introduzidas para aprimorar funções. Ciclos de compras de soluções a cada 3-5 anos. Nesta área, esta será a sua realidade quando atuando em praticamente qualquer empresa.<br /> |O empregador produz a descrição do cargo que você pretende ocupar (&quot;''job description''&quot;), estabelecendo os pré-requisitos para a função, dentre habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |-<br /> |Para manter-se neste cargo você precisa reunir as devidas comprovações de que ou possui estes pré-requisitos, além de, obviamente, demonstrar resultados no exercício da função.<br /> |É esperado do indivíduo o devido compromisso em adquirir novas habilidades, desde a aprender a lidar com novo tipo de solução, ou equipamento de fabricante/modelo diferente daquele que você está habituado; dominar uma nova ferramenta; dominar um novo processo. É um processo contínuo de aprendizado.<br /> |Para ocupar o cargo pretendido você precisa reunir as devidas comprovações de que ostenta ou possui estes pré-requisitos, além de experiência comprovada, etc., e isto é normalmente verificado em uma entrevista ou durante um processo seletivo.<br /> |-<br /> ! colspan=&quot;3&quot; |Motivações<br /> |-<br /> |Por razões óbvias, decorrentes das relações trabalhistas, você precisa se &quot;enquadrar&quot;. Numa relação trabalhista há uma troca: você fornece resultados através do seu trabalho, e o seu empregador o recompensa por isto. <br /> Se você não conseguir fornecer resultados, por quaisquer que sejam os motivos, mas, neste nosso exemplo aqui, por insuficiência de conhecimentos, a probabilidade é que você seja desligado do cargo.<br /> <br /> '''Manter-se empregado, por si só, já seria uma motivação, talvez a principal.'''<br /> |Conforme já citado para este caso, tecnologias evoluem. Equipamentos ficam obsoletos e são substituídos, sejam por questões de capacidade, inovação tecnológica (novos recursos), descontinuação ou longevidade de suporte do fabricante, ou decorrente de um novo projeto na área de concessão ou expansão. <br /> <br /> Novos projetos sempre surgirão prevendo o atendimento de objetivos estabelecidos por áreas internas do negócio.<br /> <br /> Empresas normalmente procuram capacitar os times atuais para lidar com estes novos desafios, ao invés de, toda vez que surgir um projeto com uma tecnologia nova, contratar mais e mais profissionais.<br /> <br /> Nestas situações específicas você tem uma ótima oportunidade de aprender coisas novas, capacitar-se com novos conhecimentos e habilidades, e de evoluir tecnicamente em sua profissão.<br /> <br /> '''A oportunidade de aprender e evoluir. Muitas vezes tendo acesso a recursos de treinamentos de custo elevado, inviáveis na ótica de investimento pessoal. A possibilidade de atuar em um projeto de visibilidade que vá enriquecer o seu currículo; a abertura de novas oportunidades.'''<br /> <br /> '''A troca de experiências com profissionais diferenciados que poderão estar envolvidos num projeto juntamente com você (ex: especialistas do fabricante, profissionais-referência da área, etc). São ótimos motivações.'''<br /> |Quando somos jovens, temos um sonho. Desejamos ingressar no mercado de trabalho seguindo ou o nosso coração ou o que for mais viável ou conveniente em termos de oportunidade. O fato que a maioria quer mesmo é trabalhar. <br /> Alguns tem a sorte de acertar em sua primeira oportunidade de emprego, pelo menos no que diz respeito à área ou segmento de trabalho pretendido.<br /> <br /> Apesar de existirem ferramentas que facilitem a entrada de novos profissionais no marcado de trabalho, tais como programas de estágio e intercâmbios, ainda assim há alguns pré-requisitos que precisam ser preenchidos.<br /> <br /> O jovem profissional pode até não ter experiência alguma na função, o que, inclusive, é o esperado na maioria dos casos.<br /> <br /> Preparar-se devidamente para um processo seletivo, especificamente através da obtenção dos conhecimentos teóricos e técnicos exigidos para a oportunidade em questão, garantiriam chances bem maiores de êxito.<br /> <br /> Preparar-se adequadamente para suprir algo &quot;extra&quot;, além do que está sendo exigido, mas que seja compatível com a função/oportunidade pretendida, aumentariam ainda mais estas chances.<br /> <br /> '''A oportunidade de você começar direito. A oportunidade de você dar o pontapé inicial na sua carreira e já preenchendo as competências-base de tudo aquilo que norteará a sua evolução na área. O seu primeiro emprego. São excelentes questões motivacionais.'''<br /> |-<br /> |Muito frequentemente conseguimos uma vaga para um emprego sem necessariamente atendermos a todos os requisitos que foram definidos para esta, mas, quando isto acontece, normalmente preenchemos os principais requisitos, restando &quot;apenas&quot; alguns destes a serem cumpridos.<br /> Nestes casos, geralmente o empregador está &quot;apostando&quot; em você, nas suas habilidades, e na sua capacidade de desenvolver-se continuadamente, buscando preencher &quot;in loco&quot; aqueles requisitos que você não preencheu quando assumiu aquela função.<br /> <br /> '''Manter-se empregado. Não decepcionar aqueles que apostaram em você. Aprender uma nova habilidade; evoluir. Ser reconhecido pelos seu esforço e comprometimento. Seriam ótimas motivações.'''<br /> |Nem todas as situações de &quot;cenário futuro&quot; precisam ser por imposição do empregador ou por circunstâncias de novos projetos iniciados pela empresa. <br /> <br /> Você pode (e deve!) estar atento e sensível às áreas de desenvolvimento e aprimoramento pessoal. A educação continuada poderá abrir novas oportunidades na empresa em que você atua, ou em novos mercados.<br /> <br /> Ao aprimorar as suas habilidades e conquistar novos conhecimentos, você adquirirá naturalmente um senso crítico que tende a funcionar como uma &quot;faísca&quot; para o surgimento de novas formas de fornecer resultados para os negócios da companhia ou para as suas próprias atribuições.<br /> <br /> Nestas situações, você pode conquistar novas oportunidades, tais como encabeçar um novo projeto iniciado por você mesmo, liderar um time, tornar-se uma referência para a resolução de problemas críticos, pontuais ou recorrentes, destravar quase que por completo o seu pontencial.<br /> <br /> '''A satisfação de projetar e construir coisas, de sentir uma afinidade entre aquilo que você vislumbrou e aquilo que está acontecendo; reputação, credibilidade, saber que a empresa e seus colaboradores podem contar com você; a perspectiva de aumento salarial ou de promoção para um cargo. Todos estes são ótimas motivações.'''<br /> |Talvez você esteja passando por aquela fase de não sentir-se mais motivado com a função atual.<br /> <br /> As vezes, você até encontra-se motivado, mas não se sente desafiado o suficiente e não vê perspectivas de mudanças na dinâmica do seu trabalho na função atual. <br /> <br /> Você quer evoluir, quer dar o próximo salto na sua carreira, seguir adiante.<br /> <br /> Crescer profissionalmente, ser melhor recompensado por isto; ter uma equiparação salarial proporcional ao valor que você pretende fornecer para o seu empregador.<br /> <br /> Preencher um cargo mais ousado, ter mais responsabilidades, tomar decisões importantes.<br /> <br /> Isto raramente acontece no &quot;modo automático&quot;; sem planejamento.<br /> <br /> Você realmente terá que trilhar este caminho, ou seja, planejar todas as ações que viabilizarão este upgrade na carreira. <br /> <br /> Você precisará ser ousado, sistemático, organizado. Quase que por simbiose, estudar + capacitar-se + implementar as suas idéias na forma mais prática ou objetiva possível. Sem fazer isto, dificilmente você conseguirá absorver os conhecimentos que possibilitarão este impulsionamento na sua carreira.<br /> <br /> '''Dar efetivamente o próximo salto, evoluir objetivamente na carreira. Conquistar novos horizontes; aumento salarial; aspiração de um cargo mais valorizado e diferenciado. Tornar-se uma referência; um profissional conhecedor, credenciado e respeitado. São todas estas excelentes motivações.'''<br /> |}<br /> <br /> === Conhecimentos, Habilidades, Atitudes e Competências (CHAC) e desempenho: as suas diferenças, e como reuni-las ===<br /> Como já dissertei um tanto sobre conhecimentos, está na hora de partirmos para a questão de habilidades, atitudes, competências, e o desempenho. Muitos acreditam que conhecimento e habilidade sejam a mesma coisa. Pode parecer confuso, mas, na verdade, não são. Também não significam exatamente a mesma coisa &quot;habilidades&quot; e &quot;competências&quot;. Esta seção do artigo aborda a minha visão sobre as diferenças entre estes casos, e inclui no bolo também as atitudes que deverão acompanhar o seu desenvolvimento profissional com estes conhecimentos, habilidades e competências, e como o desempenho participa disto tudo.<br /> <br /> O '''''&lt;u&gt;conhecimento&lt;/u&gt;''''' é o entendimento técnico ou teórico de um assunto específico. Na área de TIC, é perfeitamente possível você ler bastante e informar-se sobre uma tecnologia que não necessariamente faça parte do seu perfil ou de seu cotidiano. Por exemplo, &quot;estar por dentro&quot; (bem informado) sobre desenvolvimento de aplicações Web, quando, na prática, você é um profissional de redes. Como outro exemplo, você pode ser bom conhecedor de &quot;segurança da informação&quot; por ter lido ou até mesmo estudado muita coisa nos aspectos teórico e técnico, feito cursos/treinamentos, etc., mas isto não significa que você possua as habilidades associadas aos conhecimentos obtidos. São duas coisas completamente diferentes. É possível que você não esteja trabalhando com determinada tecnologia, isto é, você (ainda) não atua na prática com os casos discutidos por uma dada tecnologia, mas que você tenha um interesse natural pelos temas daquela área e, consequentemente, passe a estudar estes temas, ganhando boa fluência teórica e técnica.<br /> <br /> A '''''&lt;u&gt;habilidade&lt;/u&gt;''''', por sua vez, é a sua capacidade de saber executar aquelas coisas que são ditadas pelos seus conhecimentos adquiridos. Ou seja, você aprendeu a tecnologia, solução ou ferramenta; obteve os devidos conhecimentos, e, através de muita prática em ambientes que simulam condições e cenários reais, adquiriu as boas habilidades associadas a estes conhecimentos. Ou, melhor ainda, executou estes conhecimentos ''in loco'' em um projeto ou situação cotidiana. Há uma diferença razoável entre conhecer bem alguma coisa e possuir as habilidades &quot;abençoadas&quot; para saber lidar com estas questões nas suas formas mais práticas.<br /> <br /> Um exemplo aqui: eu (autor) sou aficcionado por astronomia e astrofísica, e passo horas todas as semanas lendo sobre o tema, &quot;estudando&quot;, me informando de verdade. Isto me coloca na condição de conhecedor do tema (e numa escala que vai de &quot;leigo total&quot;, &quot;iniciante&quot;, até &quot;crânio master&quot;, embora eu esteja bem longe desse nível aí), mas nem de longe isso representa uma habilidade: eu seria incapaz de atuar nesta área com os conhecimentos que possuo no momento, e me enxergo muito distante disso tudo. São realidades completamente distintas. Você ler bastante sobre um assunto traz muito conhecimento, fato, mas o quanto disso se traduz em habilidades? Ler e decorar todas as bulas de medicamentos, saber dissertar de cor e salteado sobre elas, não te faz um médico farmacologista!<br /> <br /> A '''''&lt;u&gt;atitude&lt;/u&gt;''''' tem relação com a forma em que você enxerga esta referência entre os conhecimentos que são indispensáveis para os seus propósitos de carreira (vide tabela &quot;''Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC''&quot;) e a preparação e obtenção efetiva das habilidades necessárias correspondentes. Entenda que empregadores/empresas/clientes estão interessados em mais que apenas você conhecer alguma coisa: todos esperam confiança no seu trabalho, além os devidos resultados! E, acredite, esta confiança vem desde o início das relações pretendidas (ex: um processo seletivo, uma proposta para prestação de serviços, uma reunião de negócios para fechar um contrato), durante a própria condução do seu trabalho (a maneira como você inicia e planeja as atividades, organiza o seu trabalho, justifica as suas ações, efetiva configurações, realiza o suporte etc.), enfim, tudo isto move o ponteiro do &quot;desconfiômetro&quot; para baixo ou para cima. Quem nunca ouviu falar de casos de &quot;''fulano'' falando é quase que um mestre, mas, na hora de colocar a mão na massa, 'trava'&quot;? Essa é a diferença entre conhecimento e habilidade! A atitude é o que você deve fazer a respeito para transformar os seus conhecimentos em habilidades. São os seus métodos, práticas, disciplina, responsabilidade, compromisso, proatividade e ação.<br /> <br /> A '''''&lt;u&gt;competência&lt;/u&gt;''''' pode ser definida como um conjunto de habilidades harmonicamente desenvolvidas para caracterizar a sua função ou profissão, como, por exemplo, um engenheiro de redes. Enquanto habilidades tendem a ser coisas mais específicas (por exemplo, um protocolo, um equipamento, um serviço), uma competência, por sua vez, é o desenvolvimento de um conjunto de habilidades que fornecem este perfil tipificado para um cargo/função. Para exemplificar, um engenheiro de redes deve possuir diversas competências, cada qual reunindo seus conjuntos de habilidades necessárias para o exercício da função.<br /> <br /> Já o '''''&lt;u&gt;desempenho&lt;/u&gt;''''' trata-se de um indicador da competência que pode ser usado para mensurar o grau de aptidão e resultados de um indivíduo no exercício de suas funções. Uma questão interessante envolvendo o desempenho é que, ao mesmo tempo, não é um sinônimo integral de competência! Confuso, não? Eu explico: um desempenho ruim pode não indicar exatamente uma falta de competência, e sim, possivelmente, em alguns casos, que os resultados ruins tem sido provocados por interferências e fatores alheios às competências do indivíduo, tais como a ausência de materiais/recursos em condições adequadas para a condução de um trabalho, as próprias condições de trabalho no geral, aspectos emocionais que por ventura estejam afetando a qualidade do trabalho daquele profissional, enfim, a lista é grande aqui. Mas, no geral, podemos afirmar e utilizar o &quot;desempenho&quot; como métrica de determinação da competência de um indivíduo.<br /> <br /> Se organizássemos estes conceitos teríamos os seguintes resultados:<br /> * Conhecimentos representam aquilo que você sabe, obtidos de forma empírica, tácita, científica e filosófica. Treinamentos, cursos, palestras, workshops, brainstorms, etc., são formas de você obter ou aprimorar seus conhecimentos.<br /> * Habilidades representam a tradução destes conhecimentos para um plano ou aspecto mais prático. É o &quot;saber fazer&quot; propriamente dito. Ou seja, como você utiliza os conhecimentos obtidos na sua vida profissional, nas tarefas do cotidiano, etc. O seu envolvimento em ações mais práticas tais como desenvolver um projeto, instalar e configurar equipamentos, aditivar uma funcionalidade no seu projeto lógico, efetuar diagnóstico e suporte a problemas, etc., são exemplos de habilidades. Muitas habilidades, apesar de poderem ser demonstradas na prática, não envolvem você ter que lidar diretamente com o componente relacionado ao conhecimento correspondente numa implementação ou ação de suporte. Por exemplo, conhecimentos aprofundados sobre um determinado protocolo de roteamento (ex: BGP), mas que você não vá lidar com isto num equipamento, e sim em um plano de projeto, elaboração de um cronograma, produção de uma uma documentação, ou geração de um novo processo referente a esta tecnologia; estes seriam o caso de um engenheiro de pré-vendas ou Systems Engineer.<br /> * Competências representam os conjuntos de habilidades que tipificam o seu cargo/função. Quando uma competência de &quot;''routing e switching''&quot; é demandada para um perfil profissional (engenheiro de redes), o que assumimos neste caso? Que você tenha experiência em dissertar sobre o equipamento, suas características físicas e lógicas, capacidades; instalação física e configuração lógica, lidar com um projeto técnico que informe como as tecnologias estarão integradas na rede, quais padrões e diretivas de configuração deverão ser implementados, a configuração e manutenção efetivas da solução, etc. Isto é um exemplo de uma competência típica de um engenheiro de redes. É importante salientar que há diferenças entre as palavras &quot;competência&quot; e &quot;competente&quot;. A &quot;competência&quot; significa possuir habilidades, comportamentos e atitudes compatíveis com as tarefas que fazem parte da sua função profissional, em qualquer situação relacionada às suas atribuições. A palavra &quot;competente&quot; significa ter capacidade para fazer algo em determinado momento.<br /> * Desempenho é a demonstração das suas competências na forma de resultados. É o indicador de que você é efetivo na condução das habilidades que constituem estas competências.<br /> <br /> === Habilidades técnicas (&quot;''Hard Skills''&quot;) e habilidades comportamentais (&quot;''Soft Skills''&quot;) ===<br /> Nem tudo aquilo que deve fazer parte do perfil do profissional é composto por apenas habilidades técnicas, ou &quot;''hard skills''&quot;! É verdade que por muitos anos os critérios de seleção de um perfil profissional durante processos de recrutamento eram baseados quase que integralmente nestas habilidades mais técnicas, como competências relacionadas exclusivamente a equipamentos, tecnologias, protocolos, serviços e soluções. Para ser honesto, atualmente as habilidades comportamentais pesam significativamente a favor ou contra as chances do candidato de conseguir um emprego, promoção ou aumento de salário!<br /> <br /> Com o mundo cada vez mais dinâmico e conectado, com desafios mais complexos a serem superados e tudo mais, espera-se do indivíduo em muitos casos habilidades que vão além do que ele sabe fazer com determinado tipo de solução. As empresas e seus processos seletivos estão cada vez mais rigorosos nesta parte envolvendo habilidades comportamentais e interpessoais. Antes de explicar como podemos desenvolver ambos os tipos de habilidades, acho que convém mostrar alguns exemplos de cada caso.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Exemplos de habilidades técnicas (&quot;''hard skills''&quot;) e habilidades comportamentais (&quot;''soft skills''&quot;)<br /> !Habilidades técnicas (hard skills)<br /> !Características<br /> !Habilidades comportamentais (soft skills)<br /> !Características<br /> |-<br /> |<br /> |<br /> |'''Atitude'''<br /> |A atitude é uma habilidade comportamental pouco específica, pois abrange uma diversidade de possibilidades, mas não menos apreciável: na verdade, é uma das características mais cobiçadas por empregadores, clientes e prospecções.<br /> No geral, a atitude é praticamente &quot;um conjunto de atitudes&quot; que define o seu perfil como indivíduo e profissional. Apresentarei alguns exemplos de atitudes ainda nesta tabela.<br /> |-<br /> |<br /> |<br /> |'''Capacidade analítica'''<br /> |A capacidade analítica é essencialmente uma forma de pensar que tem como objetivo a explicação de situações e fatos por meios de uma decomposição mais simples e de fácil explicação.<br /> Um profissional com boa capacidade analítica tem muita facilidade em interpretar dados e fornecer explicações simples, mas não menos úteis, para situações complexas e em momentos decisivos.<br /> |-<br /> |<br /> |<br /> |'''Capacidade de persuasão'''<br /> |A persuasão é uma forma de comunicação estratégica que é feita através de argumentos lógicos ou simbólicos, sendo a capacidade de argumentação e a retórica essenciais para conseguir persuadir alguém ou modificar o panorama de alguma situação a seu favor, ou a favor da sua empresa, em uma negociação ou gerenciamento de crise.<br /> A persuasão precisa estar acompanhada de outras habilidades comportamentais, como a ética, empatia, criatividade, capacidade de comunicação (em muitos casos) e inteligência emocional. <br /> <br /> Na área de TIC, é uma habilidade indispensável para profissionais de vendas, pré-vendas e palestrantes, mas também pode ser útil para profissionais de perfil mais técnico.<br /> |-<br /> |<br /> |<br /> |'''Capacidade de trabalhar sob pressão'''<br /> |Em poucas palavras, é uma habilidade que permite o indivíduo identificar prioridades para assegurar os resultados almejados, permitindo ainda a definição das melhores ações, mesmo em condições adversas, ao mesmo tempo em que mantendo-se o equilíbrio pessoal, respondendo às demandas e privilegiando frequentemente a qualidade e o prazo daquele objetivo.<br /> Muitos cargos e funções exigem um perfil de indivíduo que saiba lidar com trabalho sob pressão. Na nossa área, times de suporte, logística e operações são constantemente bombardeados por situações que exigem este tipo de habilidade.<br /> <br /> Trabalhar sob pressão (ou ter essa capacidade) automaticamente inclui outras habilidades comportamentais, como a inteligência emocional e a flexibilidade ou resiliência.<br /> |-<br /> |<br /> |<br /> |'''Comunicação interpessoal'''<br /> |A comunicação interpessoal é uma habilidade comportamental que que indica a proficiência do indivíduo em estabelecer comunicações efetivas com outras pessoas ou grupos de indivíduos, com foco nas relações e troca de idéias e experiências.<br /> <br /> Alguns cargos e funções fazem extenso uso de comunicação entre as partes, e o indivíduo com boa comunicação interpessoal conseguirá desempenhar as suas funções com naturalidade.<br /> |-<br /> |<br /> |<br /> |'''Criatividade'''<br /> |A criatividade é a capacidade de criar, produzir ou inventar coisas novas, bem como a capacidade de transformar situações e inovar no modo de agir. <br /> <br /> Dentre os atributos de um profissional criativo temos a curiosidade e a forma diferente de olhar as coisas, além da busca incessante por novas oportunidades e possibilidades. <br /> <br /> Na área de TIC, a criatividade é fundamental para todo e qualquer profissional que estiver engajado em produzir conceitos para superar os desafios do negócio. <br /> <br /> Projetistas (projetos de solução e adoção tecnológica), engenheiros de pré-vendas, times de vendas, dentre outros, precisam destacar bem esta habilidade, pois a criatividade faz uma diferença estupenda para as competências destes perfis.<br /> |-<br /> |<br /> |<br /> |'''Empatia'''<br /> |Uma habilidade comportamental bastante peculiar que se traduz em uma capacidade notoriamente psicológica, e que envolve a compreensão e a troca de sentimentos e emoções entre dois indivíduos.<br /> <br /> A empatia é uma capacidade bastante apreciada em diversas situações, e é um excelente fomentador de outras capacidades comportamentais, como a persuação, senso de liderança, positividade e trabalho em equipe.<br /> |-<br /> |<br /> |<br /> |'''Ética'''<br /> |A ética dita a conduta humana e profissional, e a moral é a qualidade desta conduta, especialmente quando está em julgamento os pontos de vista do bem e do mal. Ou do certo e do errado. A ética é um conceito um tanto amplo (altruísmo, caráter, costume, hábito, etc.).<br /> <br /> A ética deve ser exercitada sob o ponto de vista da certeza de que aquilo que você está fazendo é o certo, ou aquilo que seria o errado você não está fazendo, mesmo que, naturalmente, defendendo os interesses do seu empregador. Mas para tudo há um limite.<br /> <br /> Sem ética pessoal e profissional, você estará fadado a orbitar o perímetro dos profissionais que transmitem desconfiança e insegurança para relações de trabalho. Reflita!<br /> |-<br /> |<br /> |<br /> |Falar em público<br /> |<br /> |-<br /> |<br /> |<br /> |Flexibilidade / resiliência<br /> |<br /> |-<br /> |<br /> |<br /> |Gestão do tempo<br /> |<br /> |-<br /> |<br /> |<br /> |Inteligência emocional<br /> |<br /> |-<br /> |<br /> |<br /> |Motivação<br /> |<br /> |-<br /> |<br /> |<br /> |Paciência<br /> |<br /> |-<br /> |<br /> |<br /> |Positividade<br /> |<br /> |-<br /> |<br /> |<br /> |Proatividade<br /> |<br /> |-<br /> |<br /> |<br /> |Rede de contatos ativos<br /> |<br /> |-<br /> |<br /> |<br /> |Resolução de conflitos<br /> |<br /> |-<br /> |<br /> |<br /> |Senso de liderança<br /> |<br /> |-<br /> |<br /> |<br /> |Solução de problemas<br /> |<br /> |-<br /> |<br /> |<br /> |Tomada de decisão<br /> |<br /> |-<br /> |<br /> |<br /> |Trabalho em equipe<br /> |<br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2484 2020-05-30T00:14:57Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira, consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos e habilidades. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, juntamente com as devidas habilidades correspondentes aos conhecimentos específicos da área, assim como possíveis outros conhecimentos (periféricos), visando, especificamente, neste caso, o crescimento ou evolução em suas profissões.<br /> # Atitudes e motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem evoluir?'''''<br /> <br /> As respostas podem variar de acordo com cada indivíduo, mas a minha resposta mais precisa para esta pergunta seria o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema, na minha opinião, está no método. O método pode estar ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento, e responderá a tantas das perguntas e preocupações que você vive no momento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;)<br /> ** Metodologias didáticas de ensino e aprendizado.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação, aderência e aptidão.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> ** Educação continuada.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, tampouco professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em tantas empresas que já perdi as contas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que reúno bagagem o suficiente para, legitimamente. contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a minha resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''. Há aqueles que adorariam complicar as coisas e sugerir a incorporação de outros elementos e complexidades, tais como condição social, falta de oportunidades, fator &quot;Q.I.&quot; (&quot;Quem Indica&quot;, o famoso contatinho com o &quot;Comandante Faber Castell&quot; lá da empresa), profissional naturalmente desmotivado por ter percebido, após um tempo, que aquela profissão não era para ele, dentre outros fatores e complicações. O fato é, independentemente disso tudo, você &lt;u&gt;jamais decolará&lt;/u&gt; na carreira sem o conhecimento. Seja você rico ou pobre, preto ou branco, nordestino ou sulista, hétero ou homo, evangélico ou ateísta, tudo isso é mínimo se comparado ao que realmente importa para você conseguir deslanchar nesta área, aliás, em qualquer profissão: '''''conhecimento'''''. Você pode até ter ótimos conhecimentos e estar com falta de sorte no momento, mas um indivíduo sem conhecimento é um indivíduo pouco útil para esta ou qualquer carreira ou profissão.Você pode até conseguir um emprego na área com conhecimentos fracos ou medianos, mas, decolar, jamais!<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que conseguíssemos traçar um caminho que de fato pudesse levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos, e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com alguns dos modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, focarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir alguns tipos de conhecimento que são irrelevantes para os meus propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> <br /> OBS: os &quot;''&lt;u&gt;exemplos relacionados à nossa área de TIC&lt;/u&gt;''&quot; da tabela a seguir mesclam, de forma muito íntima e implícita &quot;conhecimento&quot; e &quot;habilidade&quot;, mas saiba de antemão que são coisas distintas. Isto será esclarecido posteriormente neste artigo.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, obtido principalmente por observação, experiência em lidar com os resultados herdados por senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo. Frequentemente obtido com base na tentativa e erro.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> * Entrelaçamento quântico <br /> * Tabela Periódica <br /> * Leis de Newton <br /> * Princípio de Arquimedes <br /> * Algoritmo de Dijkstra <br /> |<br /> * &quot;O ignorante afirma, o sábio duvida, o sensato reflete.&quot; (Aristóteles)<br /> * &quot;Só sei que nada sei.&quot; (Sócrates)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> * &quot;Não existem métodos fáceis para resolver problemas difíceis.&quot; (René Descartes)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> * Aplicar um complexo e plástico golpe de capoeira!<br /> * Arriscar-se com êxito fazendo parkour no alto dos edifícios<br /> Em todos estes casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à nossa área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede com bastante fluidez e obedecendo as guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção sobre a configuração de elementos de rede, relacionando corretamente as áreas funcionais e controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia sendo impulsionada pelo mercado, liderada por um determinado fabricante, centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing.<br /> * &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se de certa forma à favor dos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. <br /> * &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará efetivamente a mesma coisa que as implementações RSVP-TE atuais fazem?&quot;. &quot;Valeria a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?&quot;. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado com marketing/branding do que com soluções técnicas de fato inovadoras?&quot;. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se sempre de incluir o parâmetro &quot;add&quot; para o comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}<br /> Note que não está sendo feito qualquer julgamento em termos de &quot;''que tipo de conhecimento é melhor?''&quot; porque isto simplesmente não existe! Em termos de resultados, ou eficácia, um conhecimento empírico pode ser (e muitas vezes é!) o meio mais correto ou indicado para resolvermos um problema, ou que um conhecimento puramente tácito promova os resultados desejados de forma mais efetiva que com um conhecimento empírico apenas. Um conhecimento científico não é melhor só porque é baseado em alguma teoria aliada à uma comprovação por método, pois um conhecimento filosófico pode resolver, e com alguma frequência isto acontece, um desafio que não está sendo possível resolver com um conhecimento científico; enfim, acho que você me entendeu.<br /> <br /> Caso você não tenha identificado uma afinidade ou utilidade entre esta tabela acima e a proposta deste artigo, algo tipo &quot;tudo muito supérfluo!&quot;, sugiro que repense! Apesar de ter um aspecto um tanto teórico, acho de suma importância você saber identificar como os seus conhecimentos vigentes estão enquadrados ou tipificados. Lá na frente isto poderá ser útil na hora de identificar o que precisa ser feito para aprimorar a maneira como você entende o funcionamento de determinadas tecnologias ou soluções, ou quais práticas e processos precisam ser aprimorados para um suporte mais efetivo destas, dentre outras situações. Alguns exemplos de como este &quot;''drag &amp; drop''&quot; poderia ser feito:<br /> * '''De tudo o que você sabe dissertar ou executar, em sua forma mais prática ou efetiva (implantar, configurar, operar, prestar suporte), ou seja, tecnologias, equipamentos, soluções, processos e afins, o que de fato você:'''<br /> ** '''''Conhece por herança organizacional, seja na empresa atual ou experiências prévias, ou através de convívio e troca de experiências com grupos de indivíduos e suas opiniões?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências. <br /> **** Por exemplo, adquiriu uma habilidade e experiência através de um roteiro, processo interno da empresa (&quot;é assim que você deve fazer&quot;, &quot;assim funciona&quot;, ou &quot;não faça isto!&quot;), modus operandi do setor da empresa, etc.<br /> *** Estes seriam &lt;u&gt;conhecimentos empíricos&lt;/u&gt;!<br /> ** '''''Conhece, por meios de algum processo de validação, e com o emprego de práticas documentadas em artefatos de indústria, BCOPs, frameworks, e com eficácias e resultados tecnicamente comprovados?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, adquiriu conhecimentos e experiência em um projeto e implantação de BGP integralmente apoiado por BCPs (BCP 38, 194, 185, MANRS); uma validação de circuito de dados com base no RFC 2544, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos científicos&lt;/u&gt;!<br /> ** '''''Conhece por questionamentos de princípios de aderência, aplicabilidades, julgamento de utilidade, associação de benefícios e casos de uso?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, adquiriu conhecimentos e experiência em conduzir uma análise qualitativa de riscos ou de uma matriz funcional de qualidade; questionamentos e dissertações de casos quanto ao uso de determinadas tecnologias e soluções, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos filosóficos&lt;/u&gt;!<br /> ** '''''Conhece por experiência e vivência próprias, ou seja, tentativa e erro, satisfação e frustração com resultados, etc.?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, saber identificar e antecipar riscos em determinadas manobras de configuração em função de experiência prévia ruim; saber conduzir uma operação através de uma ordem apropriada, evitando-se problemas de indisponibilidades, também por experiência prévia; saber qual versão de software usar por não conter um bug que, em um caso anterior, provocou um distúrbio na sua infraestrutura; saber que, antes de ativar um recurso no software de seu roteador, por experiência prévia/própria, outro recurso deve estar habilitado como pré-requisito, do contrário não funcionará ou provocará algum tipo de distúrbio, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos tácitos&lt;/u&gt;!<br /> Viu só? Nem tudo o que é teoria é &quot;burocrático&quot;! Há sempre como extrair coisas positivas de muitos conceitos teóricos ou aparentemente abstratos. E vou um pouco além neste discurso sobre como isto poderá ser útil para você. Imagine que você fizesse uma auto-avaliação (aliás, sugiro mesmo que faça isto!), qual seria o resultado? E quais seriam os significados destes resultados? Quanto aos &quot;significados&quot;, eu tecerei uma opinião estritamente pessoal, pois a interpretação de cada caso é realmente bastante individualizada. Eu posso pensar de um jeito, e você de outro completamente diferente. Certo? Caso você tenha interesse em saber como &lt;u&gt;'''eu'''&lt;/u&gt; (autor) penso, estas seriam as minhas respostas:<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;tácita'''''&quot;<br /> <br /> Isto para mim significaria uma coisa: generalizando aqui, você pode até ser bem &quot;safo&quot;, mas desde que seus conhecimentos sejam realmente bem seguros e produzam bons resultados. O que é difícil. Explico o por que. São preocupantes as possíveis (e não confirmadas, por isto estou generalizando) divergências entre o que órgãos de indústria ou fabricantes promovem como recomendações e boas práticas, e o que você de fato executa ou como executa o seu trabalho.<br /> <br /> Com a complexidade cada vez mais crescente das soluções tecnológicas, assim como os padrões de boas práticas operacionais, é pouco provável que um indivíduo majoritariamente &quot;tácito&quot; seja efetivo em suas atribuições, especialmente quando pensando aqui nas tantas métricas sobre as quais deverá estar apoiado todo o funcionamento do aparato tecnológico, ou seja, ''Disponibilidade'', ''Performance'', ''Segurança'', ''Confiabilidade'', ''Disponibilidade'', ''Escalabilidade'', e etc. <br /> <br /> Dificilmente um indivíduo deste perfil conseguiria orquestrar um ambiente com conhecimentos puramente tácitos. &quot;Ah, mas ele estudou o manual do fabricante para fazer o procedimento 'x'!&quot;, mas, peraí, isto não seria um conhecimento tácito! Assim como &quot;ele seguiu o processo da Operação da empresa para fazer a configuração&quot;, mas, peraí, isto também não seria um conhecimento tácito! Compreende a diferença? <br /> <br /> Não consigo vislumbrar um indivíduo majoritariamente &quot;tácito&quot; funcional, pois, tal perfil, seria um risco tremendo para os negócios de uma empresa. Gambiarras e experimentações individualizadas, com pouco ou nenhum apoio e suporte de conhecimentos científicos ou empíricos, não são uma opção! Nesta área de redes e afins, conhecimento tácito é algo muito íntimo e específico (vide os exemplos da tabela anterior), e geralmente são muito bons/úteis como complemento de outras formas de conhecimento, como o científico e o empírico. <br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;empírica'''''&quot;<br /> <br /> Tudo o que um indivíduo aprendeu a executar num ambiente de redes obedecendo algum padrão ou procedimento estabelecido pela empresa ou pelo mercado (&quot;senso comum&quot;), é considerado um conhecimento empírico. Assim como conhecimentos obtidos junto à uma comunidade de especialistas. O que é bom ou muito bom. Especialmente quando o indivíduo passa a entender os cuidados que devem ser observados durante a condução do trabalho em questão. Isto significa que na maior parte do tempo este indivíduo estará conduzindo atividades de acordo com padrões ou modelos confiáveis, realizando configurações, ajustes, manobras, adaptações e afins, tudo inspirado num esqueleto funcional, seguro, e resultados auditáveis ou perceptíveis.<br /> <br /> É nessas horas, inclusive, voltando ao caso anterior, que os conhecimentos &lt;u&gt;tácitos&lt;/u&gt; complementam e fazem a diferença: nem sempre os padrões ou procedimentos são bem elaborados ou seguros; nem sempre as descrições dos requisitos e respectivas tarefas asseguram que o trabalho a ser realizado estará isento de riscos ou que vá funcionar &quot;de primeira&quot;. Como ocorre por muitas vezes, o indivíduo tende a perceber isto e a tomar cuidados extras na hora de conduzir seus trabalhos, podendo usar a sua própria experiência/vivência na hora de fazer as coisas, evitar armadilhas, maximizar resultados, etc. É nessas horas que o indivíduo &quot;safo&quot; usa a sua experiência (conhecimentos tácitos) como complemento aos conhecimentos obtidos de forma empírica ou científica.<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;filosófica&quot;'''''<br /> <br /> Um indivíduo, através de uma demanda cotidiana que implemente ações cujos conhecimentos correspondentes/associados foram obtidos de forma empírica (um procedimento, um processo, um modelo...), não importando em qual estágio de sua carreira ele obteve este conhecimento, poderá eventualmente divergir de opiniões. Poderá não concordar, pelo menos não inicialmente, ou até que seja convencido por alguém. Poderá ponderar, questionar os propósitos imputados ou critérios adotados. E, em função disto, poderá desejar modificar ou aprimorar aquela demanda ou aquele processo. Refinar o método como um todo, ou parte dele. <br /> <br /> Obviamente que, &quot;questionar&quot;, &quot;ponderar&quot;, ou &quot;criticar&quot; apenas, recusando-se a todo custo a cumprir com o seu dever, qualquer que tenha sido a tarefa imputada a ele, eu não chamaria isto de conhecimento filosófico, e sim de &quot;birra de criança&quot;. O conhecimento filosófico não é fazer birra ou ter atitudes antiprofissionais! O que se espera de uma iniciativa correta para estes casos é um perfil questionador de um indivíduo trazendo à tona novos desafios e propósitos para a elaboração de novas respostas, e tudo objetivando efetividade e resultados.<br /> <br /> Isto é uma qualidade de conhecimento que tipifica bem um perfil de profissional centrado em qualidade e resultados, e vemos isto muito presente em arquitetos de soluções, alguns perfis de gestores, e até mesmo em engenheiros de redes e analistas.<br /> <br /> === Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC ===<br /> Fugindo aqui momentaneamente deste discurso de tipo de conhecimentos, e retornando ao tema de motivações abordado previamente, mas, desta vez, incorporando justificativas e argumentos na fórmula, quais são as principais motivações, justificativas e argumentos para que um indivíduo vá buscar efetivamente conhecimentos relacionados aos temas da área de TIC? Tentemos exercitar isto de forma ampla e um pouco generalista, desprezando as individualidades que movem o coração de cada um de nós. Talvez eu esteja acertando em boa parte sobre tudo o que está sugerido a seguir, mas é bem provável também que você mesmo possua seus próprios argumentos, justificativas e motivações.<br /> {| class=&quot;wikitable&quot;<br /> |+Alguns casos de argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC<br /> ! colspan=&quot;3&quot; |Argumentos<br /> |-<br /> !Requisitos para Funções Vigentes<br /> !Requisitos para Funções Futuras<br /> !Requisitos para Prospecções e Planos de Carreira<br /> |-<br /> |Obter as qualificações e competências para a conformidade com requisitos vigentes, os quais são estabelecidos pelo empregador.<br /> |Aprendizado e domínio de novas tecnologias, equipamentos ou ferramentas, como parte de um processo de adoção tecnológica na empresa, os quais são impostos ou estabelecidos pelo empregador.<br /> |Obter as qualificações e competências exigidas para enquadramento de perfil junto à uma vaga ou oportunidade pretendida pelo mercado de trabalho.<br /> |-<br /> |Aprimorar as habilidades em alinhamento com os requisitos vigentes, os quais são impostos ou estabelecidos pelo empregador.<br /> |Aprimoramento e domínio de habilidades para remodelagem em futuro próximo de componentes, processos e práticas vigentes, e a extração de melhores resultados com o uso de tecnologias atuais, em grande parte por iniciativa própria.<br /> |Obter as qualificações e competências exigidas visando a evolução ou crescimento de carreira, na mesma empresa em que atua no momento ou em outras oportunidades e prospecções.<br /> |-<br /> ! colspan=&quot;3&quot; |Justificativas<br /> |-<br /> |O empregador produz a descrição do cargo que você ocupa (&quot;''job description''&quot;), estabelecendo os pré-requisitos para a função, dentre habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |Tecnologias evoluem. Equipamentos e software ficam obsoletos. Novas ferramentas e solução são introduzidas para aprimorar funções. Ciclos de compras de soluções a cada 3-5 anos. Nesta área, esta será a sua realidade quando atuando em praticamente qualquer empresa.<br /> |O empregador produz a descrição do cargo que você pretende ocupar (&quot;''job description''&quot;), estabelecendo os pré-requisitos para a função, dentre habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |-<br /> |Para manter-se neste cargo você precisa reunir as devidas comprovações de que ou possui estes pré-requisitos, além de, obviamente, demonstrar resultados no exercício da função.<br /> |É esperado do indivíduo o devido compromisso em adquirir novas habilidades, desde a aprender a lidar com novo tipo de solução, ou equipamento de fabricante/modelo diferente daquele que você está habituado; dominar uma nova ferramenta; dominar um novo processo. É um processo contínuo de aprendizado.<br /> |Para ocupar o cargo pretendido você precisa reunir as devidas comprovações de que ostenta ou possui estes pré-requisitos, além de experiência comprovada, etc., e isto é normalmente verificado em uma entrevista ou durante um processo seletivo.<br /> |-<br /> ! colspan=&quot;3&quot; |Motivações<br /> |-<br /> |Por razões óbvias, decorrentes das relações trabalhistas, você precisa se &quot;enquadrar&quot;. Numa relação trabalhista há uma troca: você fornece resultados através do seu trabalho, e o seu empregador o recompensa por isto. <br /> Se você não conseguir fornecer resultados, por quaisquer que sejam os motivos, mas, neste nosso exemplo aqui, por insuficiência de conhecimentos, a probabilidade é que você seja desligado do cargo.<br /> <br /> '''Manter-se empregado, por si só, já seria uma motivação, talvez a principal.'''<br /> |Conforme já citado para este caso, tecnologias evoluem. Equipamentos ficam obsoletos e são substituídos, sejam por questões de capacidade, inovação tecnológica (novos recursos), descontinuação ou longevidade de suporte do fabricante, ou decorrente de um novo projeto na área de concessão ou expansão. <br /> <br /> Novos projetos sempre surgirão prevendo o atendimento de objetivos estabelecidos por áreas internas do negócio.<br /> <br /> Empresas normalmente procuram capacitar os times atuais para lidar com estes novos desafios, ao invés de, toda vez que surgir um projeto com uma tecnologia nova, contratar mais e mais profissionais.<br /> <br /> Nestas situações específicas você tem uma ótima oportunidade de aprender coisas novas, capacitar-se com novos conhecimentos e habilidades, e de evoluir tecnicamente em sua profissão.<br /> <br /> '''A oportunidade de aprender e evoluir. Muitas vezes tendo acesso a recursos de treinamentos de custo elevado, inviáveis na ótica de investimento pessoal. A possibilidade de atuar em um projeto de visibilidade que vá enriquecer o seu currículo; a abertura de novas oportunidades.'''<br /> <br /> '''A troca de experiências com profissionais diferenciados que poderão estar envolvidos num projeto juntamente com você (ex: especialistas do fabricante, profissionais-referência da área, etc). São ótimos motivações.'''<br /> |Quando somos jovens, temos um sonho. Desejamos ingressar no mercado de trabalho seguindo ou o nosso coração ou o que for mais viável ou conveniente em termos de oportunidade. O fato que a maioria quer mesmo é trabalhar. <br /> Alguns tem a sorte de acertar em sua primeira oportunidade de emprego, pelo menos no que diz respeito à área ou segmento de trabalho pretendido.<br /> <br /> Apesar de existirem ferramentas que facilitem a entrada de novos profissionais no marcado de trabalho, tais como programas de estágio e intercâmbios, ainda assim há alguns pré-requisitos que precisam ser preenchidos.<br /> <br /> O jovem profissional pode até não ter experiência alguma na função, o que, inclusive, é o esperado na maioria dos casos.<br /> <br /> Preparar-se devidamente para um processo seletivo, especificamente através da obtenção dos conhecimentos teóricos e técnicos exigidos para a oportunidade em questão, garantiriam chances bem maiores de êxito.<br /> <br /> Preparar-se adequadamente para suprir algo &quot;extra&quot;, além do que está sendo exigido, mas que seja compatível com a função/oportunidade pretendida, aumentariam ainda mais estas chances.<br /> <br /> '''A oportunidade de você começar direito. A oportunidade de você dar o pontapé inicial na sua carreira e já preenchendo as competências-base de tudo aquilo que norteará a sua evolução na área. O seu primeiro emprego. São excelentes questões motivacionais.'''<br /> |-<br /> |Muito frequentemente conseguimos uma vaga para um emprego sem necessariamente atendermos a todos os requisitos que foram definidos para esta, mas, quando isto acontece, normalmente preenchemos os principais requisitos, restando &quot;apenas&quot; alguns destes a serem cumpridos.<br /> Nestes casos, geralmente o empregador está &quot;apostando&quot; em você, nas suas habilidades, e na sua capacidade de desenvolver-se continuadamente, buscando preencher &quot;in loco&quot; aqueles requisitos que você não preencheu quando assumiu aquela função.<br /> <br /> '''Manter-se empregado. Não decepcionar aqueles que apostaram em você. Aprender uma nova habilidade; evoluir. Ser reconhecido pelos seu esforço e comprometimento. Seriam ótimas motivações.'''<br /> |Nem todas as situações de &quot;cenário futuro&quot; precisam ser por imposição do empregador ou por circunstâncias de novos projetos iniciados pela empresa. <br /> <br /> Você pode (e deve!) estar atento e sensível às áreas de desenvolvimento e aprimoramento pessoal. A educação continuada poderá abrir novas oportunidades na empresa em que você atua, ou em novos mercados.<br /> <br /> Ao aprimorar as suas habilidades e conquistar novos conhecimentos, você adquirirá naturalmente um senso crítico que tende a funcionar como uma &quot;faísca&quot; para o surgimento de novas formas de fornecer resultados para os negócios da companhia ou para as suas próprias atribuições.<br /> <br /> Nestas situações, você pode conquistar novas oportunidades, tais como encabeçar um novo projeto iniciado por você mesmo, liderar um time, tornar-se uma referência para a resolução de problemas críticos, pontuais ou recorrentes, destravar quase que por completo o seu pontencial.<br /> <br /> '''A satisfação de projetar e construir coisas, de sentir uma afinidade entre aquilo que você vislumbrou e aquilo que está acontecendo; reputação, credibilidade, saber que a empresa e seus colaboradores podem contar com você; a perspectiva de aumento salarial ou de promoção para um cargo. Todos estes são ótimas motivações.'''<br /> |Talvez você esteja passando por aquela fase de não sentir-se mais motivado com a função atual.<br /> <br /> As vezes, você até encontra-se motivado, mas não se sente desafiado o suficiente e não vê perspectivas de mudanças na dinâmica do seu trabalho na função atual. <br /> <br /> Você quer evoluir, quer dar o próximo salto na sua carreira, seguir adiante.<br /> <br /> Crescer profissionalmente, ser melhor recompensado por isto; ter uma equiparação salarial proporcional ao valor que você pretende fornecer para o seu empregador.<br /> <br /> Preencher um cargo mais ousado, ter mais responsabilidades, tomar decisões importantes.<br /> <br /> Isto raramente acontece no &quot;modo automático&quot;; sem planejamento.<br /> <br /> Você realmente terá que trilhar este caminho, ou seja, planejar todas as ações que viabilizarão este upgrade na carreira. <br /> <br /> Você precisará ser ousado, sistemático, organizado. Quase que por simbiose, estudar + capacitar-se + implementar as suas idéias na forma mais prática ou objetiva possível. Sem fazer isto, dificilmente você conseguirá absorver os conhecimentos que possibilitarão este impulsionamento na sua carreira.<br /> <br /> '''Dar efetivamente o próximo salto, evoluir objetivamente na carreira. Conquistar novos horizontes; aumento salarial; aspiração de um cargo mais valorizado e diferenciado. Tornar-se uma referência; um profissional conhecedor, credenciado e respeitado. São todas estas excelentes motivações.'''<br /> |}<br /> <br /> === Conhecimentos, Habilidades, Atitudes e Competências (CHAC) e desempenho: as suas diferenças, e como reuni-las ===<br /> Como já dissertei um tanto sobre conhecimentos, está na hora de partirmos para a questão de habilidades, atitudes, competências, e o desempenho. Muitos acreditam que conhecimento e habilidade sejam a mesma coisa. Pode parecer confuso, mas, na verdade, não são. Também não significam exatamente a mesma coisa &quot;habilidades&quot; e &quot;competências&quot;. Esta seção do artigo aborda a minha visão sobre as diferenças entre estes casos, e inclui no bolo também as atitudes que deverão acompanhar o seu desenvolvimento profissional com estes conhecimentos, habilidades e competências, e como o desempenho participa disto tudo.<br /> <br /> O '''''&lt;u&gt;conhecimento&lt;/u&gt;''''' é o entendimento técnico ou teórico de um assunto específico. Na área de TIC, é perfeitamente possível você ler bastante e informar-se sobre uma tecnologia que não necessariamente faça parte do seu perfil ou de seu cotidiano. Por exemplo, &quot;estar por dentro&quot; (bem informado) sobre desenvolvimento de aplicações Web, quando, na prática, você é um profissional de redes. Como outro exemplo, você pode ser bom conhecedor de &quot;segurança da informação&quot; por ter lido ou até mesmo estudado muita coisa nos aspectos teórico e técnico, feito cursos/treinamentos, etc., mas isto não significa que você possua as habilidades associadas aos conhecimentos obtidos. São duas coisas completamente diferentes. É possível que você não esteja trabalhando com determinada tecnologia, isto é, você (ainda) não atua na prática com os casos discutidos por uma dada tecnologia, mas que você tenha um interesse natural pelos temas daquela área e, consequentemente, passe a estudar estes temas, ganhando boa fluência teórica e técnica.<br /> <br /> A '''''&lt;u&gt;habilidade&lt;/u&gt;''''', por sua vez, é a sua capacidade de saber executar aquelas coisas que são ditadas pelos seus conhecimentos. Ou seja, você aprendeu a tecnologia, solução ou ferramenta; obteve os devidos conhecimentos, e, através de muita prática em ambientes que simulam condições e cenários reais, adquiriu as boas habilidades associadas a estes conhecimentos. Ou, melhor ainda, executou estes conhecimentos ''in loco'' em um projeto ou situação cotidiana. Há uma diferença razoável entre conhecer bem alguma coisa e possuir as habilidades &quot;abençoadas&quot; para saber lidar com estas questões nas suas formas mais práticas.<br /> <br /> A '''''&lt;u&gt;atitude&lt;/u&gt;''''' tem relação com a forma em que você enxerga esta referência entre os conhecimentos que são indispensáveis para os seus propósitos de carreira (vide tabela &quot;''Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC''&quot;) e a preparação e obtenção efetiva das habilidades necessárias correspondentes. Entenda que empregadores/empresas/clientes estão interessados em mais que apenas você conhecer alguma coisa: todos esperam confiança no seu trabalho, além os devidos resultados! E, acredite, esta confiança vem desde o início das relações pretendidas (ex: um processo seletivo, uma proposta para prestação de serviços, uma reunião de negócios para fechar um contrato), durante a própria condução do seu trabalho (a maneira como você inicia e planeja as atividades, organiza o seu trabalho, justifica as suas ações, efetiva configurações, realiza o suporte etc.), enfim, tudo isto move o ponteiro do &quot;desconfiômetro&quot; para baixo ou para cima. Quem nunca ouviu falar de casos de &quot;''fulano'' falando é quase que um mestre, mas, na hora de colocar a mão na massa, 'trava'&quot;? Essa é a diferença entre conhecimento e habilidade! A atitude é o que você deve fazer a respeito para transformar os seus conhecimentos em habilidades. São os seus métodos, práticas, disciplina, responsabilidade, compromisso, proatividade e ação.<br /> <br /> A '''''&lt;u&gt;competência&lt;/u&gt;''''' pode ser definida como um conjunto de habilidades harmonicamente desenvolvidas para caracterizar a sua função ou profissão, como, por exemplo, um engenheiro de redes. Enquanto habilidades tendem a ser coisas mais específicas (por exemplo, um protocolo, um equipamento, um serviço), uma competência, por sua vez, é o desenvolvimento de um conjunto de habilidades que fornecem este perfil tipificado para um cargo/função. Para exemplificar, um engenheiro de redes deve possuir diversas competências, cada qual reunindo seus conjuntos de habilidades necessárias para o exercício da função.<br /> <br /> Já o '''''&lt;u&gt;desempenho&lt;/u&gt;''''' trata-se de um indicador da competência que pode ser usado para mensurar o grau de aptidão e resultados de um indivíduo no exercício de suas funções. Uma questão interessante envolvendo o desempenho é que, ao mesmo tempo, não é um sinônimo integral de competência! Confuso, não? Eu explico: um desempenho ruim pode não indicar exatamente uma falta de competência, e sim, possivelmente, em alguns casos, que os resultados ruins tem sido provocados por interferências e fatores alheios às competências do indivíduo, tais como a ausência de materiais/recursos em condições adequadas para a condução de um trabalho, as próprias condições de trabalho no geral, aspectos emocionais que por ventura estejam afetando a qualidade do trabalho daquele profissional, enfim, a lista é grande aqui. Mas, no geral, podemos afirmar e utilizar o &quot;desempenho&quot; como métrica de determinação da competência de um indivíduo.</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2483 2020-05-29T17:32:58Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira, consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, visando precisamente o crescimento ou evolução em suas profissões.<br /> # Motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem evoluir?'''''<br /> <br /> A minha resposta mais precisa para esta pergunta é o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema está no método. Ou o método é ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento, e responderá a tantas das perguntas e preocupações que você vive no momento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;)<br /> ** Metodologias didáticas de ensino e aprendizado.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação, aderência e aptidão.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> ** Educação continuada.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, tampouco professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em tantas empresas que já perdi as contas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que reúno bagagem o suficiente para, legitimamente. contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a minha resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''. Há aqueles que adorariam complicar as coisas e sugerir a incorporação de outros elementos e complexidades, tais como condição social, falta de oportunidades, fator &quot;Q.I.&quot; (&quot;Quem Indica&quot;, o famoso contatinho com o &quot;Comandante Faber Castell&quot; lá da empresa), profissional naturalmente desmotivado por ter percebido, após um tempo, que aquela profissão não era para ele, dentre outros fatores e complicações. O fato é, independentemente disso tudo, você &lt;u&gt;jamais decolará&lt;/u&gt; na carreira sem o conhecimento. Seja você rico ou pobre, preto ou branco, nordestino ou sulista, hétero ou homo, evangélico ou ateísta, tudo isso é mínimo se comparado ao que realmente importa para você conseguir deslanchar nesta área, aliás, em qualquer profissão: '''''conhecimento'''''. Você pode até ter ótimos conhecimentos e estar com falta de sorte no momento, mas um indivíduo sem conhecimento é um indivíduo pouco útil para esta ou qualquer carreira ou profissão.Você pode até conseguir um emprego na área com conhecimentos fracos ou medianos, mas, decolar, jamais!<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que conseguíssemos traçar um caminho que de fato pudesse levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos, e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com alguns dos modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, focarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir alguns tipos de conhecimento que são irrelevantes para os meus propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, obtido principalmente por observação, experiência em lidar com os resultados herdados por senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo. Frequentemente obtido com base na tentativa e erro.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> * Entrelaçamento quântico <br /> * Tabela Periódica <br /> * Leis de Newton <br /> * Princípio de Arquimedes <br /> * Algoritmo de Dijkstra <br /> |<br /> * &quot;O ignorante afirma, o sábio duvida, o sensato reflete.&quot; (Aristóteles)<br /> * &quot;Só sei que nada sei.&quot; (Sócrates)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> * &quot;Não existem métodos fáceis para resolver problemas difíceis.&quot; (René Descartes)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> * Aplicar um complexo e plástico golpe de capoeira!<br /> * Arriscar-se com êxito fazendo parkour no alto dos edifícios<br /> Em todos estes casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à nossa área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede com bastante fluidez e obedecendo as guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção sobre a configuração de elementos de rede, relacionando corretamente as áreas funcionais e controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia sendo impulsionada pelo mercado, liderada por um determinado fabricante, centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing.<br /> * &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se de certa forma à favor dos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. <br /> * &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará efetivamente a mesma coisa que as implementações RSVP-TE atuais fazem?&quot;. &quot;Valeria a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?&quot;. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado com marketing/branding do que com soluções técnicas de fato inovadoras?&quot;. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se sempre de incluir o parâmetro &quot;add&quot; para o comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}<br /> Note que não está sendo feito qualquer julgamento em termos de &quot;''que tipo de conhecimento é melhor?''&quot; porque isto simplesmente não existe! Em termos de resultados, ou eficácia, um conhecimento empírico pode ser (e muitas vezes é!) o meio mais correto ou indicado para resolvermos um problema, ou que um conhecimento puramente tácito promova os resultados desejados de forma mais efetiva que com um conhecimento empírico apenas. Um conhecimento científico não é melhor só porque é baseado em alguma teoria aliada à uma comprovação por método, pois um conhecimento filosófico pode resolver, e com alguma frequência isto acontece, um desafio que não está sendo possível resolver com um conhecimento científico; enfim, acho que você me entendeu.<br /> <br /> Caso você não tenha identificado uma afinidade ou utilidade entre esta tabela acima e a proposta deste artigo, algo tipo &quot;tudo muito supérfluo!&quot;, sugiro que repense! Apesar de ter um aspecto um tanto teórico, acho de suma importância você saber identificar como os seus conhecimentos vigentes estão enquadrados ou tipificados. Lá na frente isto poderá ser útil na hora de identificar o que precisa ser feito para aprimorar a maneira como você entende o funcionamento de determinadas tecnologias ou soluções, ou quais práticas e processos precisam ser aprimorados para um suporte mais efetivo destas, dentre outras situações. Alguns exemplos de como este &quot;''drag &amp; drop''&quot; poderia ser feito:<br /> * '''De tudo o que você sabe dissertar ou executar, em sua forma mais prática ou efetiva (implantar, configurar, operar, prestar suporte), ou seja, tecnologias, equipamentos, soluções, processos e afins, o que de fato você:'''<br /> ** '''''Conhece por herança organizacional, seja na empresa atual ou experiências prévias, ou através de convívio e troca de experiências com grupos de indivíduos e suas opiniões?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências. <br /> **** Por exemplo, adquiriu uma habilidade e experiência através de um roteiro, processo interno da empresa (&quot;é assim que você deve fazer&quot;, &quot;assim funciona&quot;, ou &quot;não faça isto!&quot;), modus operandi do setor da empresa, etc.<br /> *** Estes seriam &lt;u&gt;conhecimentos empíricos&lt;/u&gt;!<br /> ** '''''Conhece, por meios de algum processo de validação, e com o emprego de práticas documentadas em artefatos de indústria, BCOPs, frameworks, e com eficácias e resultados tecnicamente comprovados?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, adquiriu conhecimentos e experiência em um projeto e implantação de BGP integralmente apoiado por BCPs (BCP 38, 194, 185, MANRS); uma validação de circuito de dados com base no RFC 2544, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos científicos&lt;/u&gt;!<br /> ** '''''Conhece por questionamentos de princípios de aderência, aplicabilidades, julgamento de utilidade, associação de benefícios e casos de uso?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, adquiriu conhecimentos e experiência em conduzir uma análise qualitativa de riscos ou de uma matriz funcional de qualidade; questionamentos e dissertações de casos quanto ao uso de determinadas tecnologias e soluções, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos filosóficos&lt;/u&gt;!<br /> ** '''''Conhece por experiência e vivência próprias, ou seja, tentativa e erro, satisfação e frustração com resultados, etc.?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, saber identificar e antecipar riscos em determinadas manobras de configuração em função de experiência prévia ruim; saber conduzir uma operação através de uma ordem apropriada, evitando-se problemas de indisponibilidades, também por experiência prévia; saber qual versão de software usar por não conter um bug que, em um caso anterior, provocou um distúrbio na sua infraestrutura; saber que, antes de ativar um recurso no software de seu roteador, por experiência prévia/própria, outro recurso deve estar habilitado como pré-requisito, do contrário não funcionará ou provocará algum tipo de distúrbio, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos tácitos&lt;/u&gt;!<br /> Viu só? Nem tudo o que é teoria é &quot;burocrático&quot;! Há sempre como extrair coisas positivas de muitos conceitos teóricos ou aparentemente abstratos. E vou um pouco além neste discurso sobre como isto poderá ser útil para você. Imagine que você fizesse uma auto-avaliação (aliás, sugiro mesmo que faça isto!), qual seria o resultado? E quais seriam os significados destes resultados? Quanto aos &quot;significados&quot;, eu tecerei uma opinião estritamente pessoal, pois a interpretação de cada caso é realmente bastante individualizada. Eu posso pensar de um jeito, e você de outro completamente diferente. Certo? Caso você tenha interesse em saber como &lt;u&gt;'''eu'''&lt;/u&gt; (autor) penso, estas seriam as minhas respostas:<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;tácita'''''&quot;<br /> <br /> Isto para mim significaria uma coisa: generalizando aqui, você pode até ser bem &quot;safo&quot;, mas desde que seus conhecimentos sejam realmente bem seguros e produzam bons resultados. O que é difícil. Explico o por que. São preocupantes as possíveis (e não confirmadas, por isto estou generalizando) divergências entre o que órgãos de indústria ou fabricantes promovem como recomendações e boas práticas, e o que você de fato executa ou como executa o seu trabalho.<br /> <br /> Com a complexidade cada vez mais crescente das soluções tecnológicas, assim como os padrões de boas práticas operacionais, é pouco provável que um indivíduo majoritariamente &quot;tácito&quot; seja efetivo em suas atribuições, especialmente quando pensando aqui nas tantas métricas sobre as quais deverá estar apoiado todo o funcionamento do aparato tecnológico, ou seja, ''Disponibilidade'', ''Performance'', ''Segurança'', ''Confiabilidade'', ''Disponibilidade'', ''Escalabilidade'', e etc. <br /> <br /> Dificilmente um indivíduo deste perfil conseguiria orquestrar um ambiente com conhecimentos puramente tácitos. &quot;Ah, mas ele estudou o manual do fabricante para fazer o procedimento 'x'!&quot;, mas, peraí, isto não seria um conhecimento tácito! Assim como &quot;ele seguiu o processo da Operação da empresa para fazer a configuração&quot;, mas, peraí, isto também não seria um conhecimento tácito! Compreende a diferença? <br /> <br /> Não consigo vislumbrar um indivíduo majoritariamente &quot;tácito&quot; funcional, pois, tal perfil, seria um risco tremendo para os negócios de uma empresa. Gambiarras e experimentações individualizadas, com pouco ou nenhum apoio e suporte de conhecimentos científicos ou empíricos, não são uma opção! Nesta área de redes e afins, conhecimento tácito é algo muito íntimo e específico (vide os exemplos da tabela anterior), e geralmente são muito bons/úteis como complemento de outras formas de conhecimento, como o científico e o empírico. <br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;empírica'''''&quot;<br /> <br /> Tudo o que um indivíduo aprendeu a executar num ambiente de redes obedecendo algum padrão ou procedimento estabelecido pela empresa ou pelo mercado (&quot;senso comum&quot;), é considerado um conhecimento empírico. Assim como conhecimentos obtidos junto à uma comunidade de especialistas. O que é bom ou muito bom. Especialmente quando o indivíduo passa a entender os cuidados que devem ser observados durante a condução do trabalho em questão. Isto significa que na maior parte do tempo este indivíduo estará conduzindo atividades de acordo com padrões ou modelos confiáveis, realizando configurações, ajustes, manobras, adaptações e afins, tudo inspirado num esqueleto funcional, seguro, e resultados auditáveis ou perceptíveis.<br /> <br /> É nessas horas, inclusive, voltando ao caso anterior, que os conhecimentos &lt;u&gt;tácitos&lt;/u&gt; complementam e fazem a diferença: nem sempre os padrões ou procedimentos são bem elaborados ou seguros; nem sempre as descrições dos requisitos e respectivas tarefas asseguram que o trabalho a ser realizado estará isento de riscos ou que vá funcionar &quot;de primeira&quot;. Como ocorre por muitas vezes, o indivíduo tende a perceber isto e a tomar cuidados extras na hora de conduzir seus trabalhos, podendo usar a sua própria experiência/vivência na hora de fazer as coisas, evitar armadilhas, maximizar resultados, etc. É nessas horas que o indivíduo &quot;safo&quot; usa a sua experiência (conhecimentos tácitos) como complemento aos conhecimentos obtidos de forma empírica ou científica.<br /> <br /> '''''Pensamento do autor: uma avaliação geral e hipotética dos seus conhecimentos indicou a maior parte como sendo &quot;filosófica&quot;'''''<br /> <br /> Um indivíduo, através de uma demanda cotidiana que implemente ações cujos conhecimentos correspondentes/associados foram obtidos de forma empírica (um procedimento, um processo, um modelo...), não importando em qual estágio de sua carreira ele obteve este conhecimento, poderá eventualmente divergir de opiniões. Poderá não concordar, pelo menos não inicialmente, ou até que seja convencido por alguém. Poderá ponderar, questionar os propósitos imputados ou critérios adotados. E, em função disto, poderá desejar modificar ou aprimorar aquela demanda ou aquele processo. Refinar o método como um todo, ou parte dele. <br /> <br /> Obviamente que, &quot;questionar&quot;, &quot;ponderar&quot;, ou &quot;criticar&quot; apenas, recusando-se a todo custo a cumprir com o seu dever, qualquer que tenha sido a tarefa imputada a ele, eu não chamaria isto de conhecimento filosófico, e sim de &quot;birra de criança&quot;. O conhecimento filosófico não é fazer birra ou ter atitudes antiprofissionais! O que se espera de uma iniciativa correta para estes casos é um perfil questionador de um indivíduo trazendo à tona novos desafios e propósitos para a elaboração de novas respostas, e tudo objetivando efetividade e resultados.<br /> <br /> Isto é uma qualidade de conhecimento que tipifica bem um perfil de profissional centrado em qualidade e resultados, e vemos isto muito presente em arquitetos de soluções, alguns perfis de gestores, e até mesmo em engenheiros de redes e analistas.<br /> <br /> === Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC ===<br /> Fugindo aqui momentaneamente deste discurso de tipo de conhecimentos, e retornando ao tema de motivações abordado previamente, mas, desta vez, incorporando justificativas e argumentos na fórmula, quais são as principais motivações, justificativas e argumentos para que um indivíduo vá buscar efetivamente conhecimentos relacionados aos temas da área de TIC? Tentemos exercitar isto de forma ampla e um pouco generalista, desprezando as individualidades que movem o coração de cada um de nós. Talvez eu esteja acertando em boa parte sobre tudo o que está sugerido a seguir, mas é bem provável também que você mesmo possua seus próprios argumentos, justificativas e motivações.<br /> {| class=&quot;wikitable&quot;<br /> |+Alguns casos de argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC<br /> ! colspan=&quot;3&quot; |Argumentos<br /> |-<br /> !Requisitos para Funções Vigentes<br /> !Requisitos para Funções Futuras<br /> !Requisitos para Prospecções e Planos de Carreira<br /> |-<br /> |Obter as qualificações e competências para a conformidade com requisitos vigentes, os quais são estabelecidos pelo empregador.<br /> |Aprendizado e domínio de novas tecnologias, equipamentos ou ferramentas, como parte de um processo de adoção tecnológica na empresa, os quais são impostos ou estabelecidos pelo empregador.<br /> |Obter as qualificações e competências exigidas para enquadramento de perfil junto à uma vaga ou oportunidade pretendida pelo mercado de trabalho.<br /> |-<br /> |Aprimorar as habilidades em alinhamento com os requisitos vigentes, os quais são impostos ou estabelecidos pelo empregador.<br /> |Aprimoramento e domínio de habilidades para remodelagem em futuro próximo de componentes, processos e práticas vigentes, e a extração de melhores resultados com o uso de tecnologias atuais, em grande parte por iniciativa própria.<br /> |Obter as qualificações e competências exigidas visando a evolução ou crescimento de carreira, na mesma empresa em que atua no momento ou em outras oportunidades e prospecções.<br /> |-<br /> ! colspan=&quot;3&quot; |Justificativas<br /> |-<br /> |O empregador produz a descrição do cargo que você ocupa (&quot;''job description''&quot;), estabelecendo os pré-requisitos para a função, dentre habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |Tecnologias evoluem. Equipamentos e software ficam obsoletos. Novas ferramentas e solução são introduzidas para aprimorar funções. Ciclos de compras de soluções a cada 3-5 anos. Nesta área, esta será a sua realidade quando atuando em praticamente qualquer empresa.<br /> |O empregador produz a descrição do cargo que você pretende ocupar (&quot;''job description''&quot;), estabelecendo os pré-requisitos para a função, dentre habilidades &quot;''hard skills''&quot; e &quot;''soft skills''&quot;.<br /> |-<br /> |Para manter-se neste cargo você precisa reunir as devidas comprovações de que ou possui estes pré-requisitos, além de, obviamente, demonstrar resultados no exercício da função.<br /> |É esperado do indivíduo o devido compromisso em adquirir novas habilidades, desde a aprender a lidar com novo tipo de solução, ou equipamento de fabricante/modelo diferente daquele que você está habituado; dominar uma nova ferramenta; dominar um novo processo. É um processo contínuo de aprendizado.<br /> |Para ocupar o cargo pretendido você precisa reunir as devidas comprovações de que ostenta ou possui estes pré-requisitos, além de experiência comprovada, etc., e isto é normalmente verificado em uma entrevista ou durante um processo seletivo.<br /> |-<br /> ! colspan=&quot;3&quot; |Motivações<br /> |-<br /> |Por razões óbvias, decorrentes das relações trabalhistas, você precisa se &quot;enquadrar&quot;. Numa relação trabalhista há uma troca: você fornece resultados através do seu trabalho, e o seu empregador o recompensa por isto. <br /> Se você não conseguir fornecer resultados, por quaisquer que sejam os motivos, mas, neste nosso exemplo aqui, por insuficiência de conhecimentos, a probabilidade é que você seja desligado do cargo.<br /> <br /> '''Manter-se empregado, por si só, já seria uma motivação, talvez a principal.'''<br /> |Conforme já citado para este caso, tecnologias evoluem. Equipamentos ficam obsoletos e são substituídos, sejam por questões de capacidade, inovação tecnológica (novos recursos), descontinuação ou longevidade de suporte do fabricante, ou decorrente de um novo projeto na área de concessão ou expansão. <br /> <br /> Novos projetos sempre surgirão prevendo o atendimento de objetivos estabelecidos por áreas internas do negócio.<br /> <br /> Empresas normalmente procuram capacitar os times atuais para lidar com estes novos desafios, ao invés de, toda vez que surgir um projeto com uma tecnologia nova, contratar mais e mais profissionais.<br /> <br /> Nestas situações específicas você tem uma ótima oportunidade de aprender coisas novas, capacitar-se com novos conhecimentos e habilidades, e de evoluir tecnicamente em sua profissão.<br /> <br /> '''A oportunidade de aprender e evoluir. Muitas vezes tendo acesso a recursos de treinamentos de custo elevado, inviáveis na ótica de investimento pessoal. A possibilidade de atuar em um projeto de visibilidade que vá enriquecer o seu currículo; a abertura de novas oportunidades.'''<br /> <br /> '''A troca de experiências com profissionais diferenciados que poderão estar envolvidos num projeto juntamente com você (ex: especialistas do fabricante, profissionais-referência da área, etc). São ótimos motivações.'''<br /> |Quando somos jovens, temos um sonho. Desejamos ingressar no mercado de trabalho seguindo ou o nosso coração ou o que for mais viável ou conveniente em termos de oportunidade. O fato que a maioria quer mesmo é trabalhar. <br /> Alguns tem a sorte de acertar em sua primeira oportunidade de emprego, pelo menos no que diz respeito à área ou segmento de trabalho pretendido.<br /> <br /> Apesar de existirem ferramentas que facilitem a entrada de novos profissionais no marcado de trabalho, tais como programas de estágio e intercâmbios, ainda assim há alguns pré-requisitos que precisam ser preenchidos.<br /> <br /> O jovem profissional pode até não ter experiência alguma na função, o que, inclusive, é o esperado na maioria dos casos.<br /> <br /> Preparar-se devidamente para um processo seletivo, especificamente através da obtenção dos conhecimentos teóricos e técnicos exigidos para a oportunidade em questão, garantiriam chances bem maiores de êxito.<br /> <br /> Preparar-se adequadamente para suprir algo &quot;extra&quot;, além do que está sendo exigido, mas que seja compatível com a função/oportunidade pretendida, aumentariam ainda mais estas chances.<br /> <br /> '''A oportunidade de você começar direito. A oportunidade de você dar o pontapé inicial na sua carreira e já preenchendo as competências-base de tudo aquilo que norteará a sua evolução na área. O seu primeiro emprego. São excelentes questões motivacionais.'''<br /> |-<br /> |Muito frequentemente conseguimos uma vaga para um emprego sem necessariamente atendermos a todos os requisitos que foram definidos para esta, mas, quando isto acontece, normalmente preenchemos os principais requisitos, restando &quot;apenas&quot; alguns destes a serem cumpridos.<br /> Nestes casos, geralmente o empregador está &quot;apostando&quot; em você, nas suas habilidades, e na sua capacidade de desenvolver-se continuadamente, buscando preencher &quot;in loco&quot; aqueles requisitos que você não preencheu quando assumiu aquela função.<br /> <br /> '''Manter-se empregado. Não decepcionar aqueles que apostaram em você. Aprender uma nova habilidade; evoluir. Ser reconhecido pelos seu esforço e comprometimento. Seriam ótimas motivações.'''<br /> |Nem todas as situações de &quot;cenário futuro&quot; precisam ser por imposição do empregador ou por circunstâncias de novos projetos iniciados pela empresa. <br /> <br /> Você pode (e deve!) estar atento e sensível às áreas de desenvolvimento e aprimoramento pessoal. A educação continuada poderá abrir novas oportunidades na empresa em que você atua, ou em novos mercados.<br /> <br /> Ao aprimorar as suas habilidades e conquistar novos conhecimentos, você adquirirá naturalmente um senso crítico que tende a funcionar como uma &quot;faísca&quot; para o surgimento de novas formas de fornecer resultados para os negócios da companhia ou para as suas próprias atribuições.<br /> <br /> Nestas situações, você pode conquistar novas oportunidades, tais como encabeçar um novo projeto iniciado por você mesmo, liderar um time, tornar-se uma referência para a resolução de problemas críticos, pontuais ou recorrentes, destravar quase que por completo o seu pontencial.<br /> <br /> '''A satisfação de projetar e construir coisas, de sentir uma afinidade entre aquilo que você vislumbrou e aquilo que está acontecendo; reputação, credibilidade, saber que a empresa e seus colaboradores podem contar com você; a perspectiva de aumento salarial ou de promoção para um cargo. Todos estes são ótimas motivações.'''<br /> |Talvez você esteja passando por aquela fase de não sentir-se mais motivado com a função atual.<br /> <br /> As vezes, você até encontra-se motivado, mas não se sente desafiado o suficiente e não vê perspectivas de mudanças na dinâmica do seu trabalho na função atual. <br /> <br /> Você quer evoluir, quer dar o próximo salto na sua carreira, seguir adiante.<br /> <br /> Crescer profissionalmente, ser melhor recompensado por isto; ter uma equiparação salarial proporcional ao valor que você pretende fornecer para o seu empregador.<br /> <br /> Preencher um cargo mais ousado, ter mais responsabilidades, tomar decisões importantes.<br /> <br /> Isto raramente acontece no &quot;modo automático&quot;; sem planejamento.<br /> <br /> Você realmente terá que trilhar este caminho, ou seja, planejar todas as ações que viabilizarão este upgrade na carreira. <br /> <br /> Você precisará ser ousado, sistemático, organizado. Quase que por simbiose, estudar + capacitar-se + implementar as suas idéias na forma mais prática ou objetiva possível. Sem fazer isto, dificilmente você conseguirá absorver os conhecimentos que possibilitarão este impulsionamento na sua carreira.<br /> <br /> '''Dar efetivamente o próximo salto, evoluir objetivamente na carreira. Conquistar novos horizontes; aumento salarial; aspiração de um cargo mais valorizado e diferenciado. Tornar-se uma referência; um profissional conhecedor, credenciado e respeitado. São todas estas excelentes motivações.'''<br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2482 2020-05-29T02:46:16Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, visando precisamente o crescimento ou evolução em suas profissões.<br /> # Motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem evoluir?'''''<br /> <br /> A minha resposta mais precisa para esta pergunta é o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema está no método. Ou o método é ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento, e responderá a tantas das perguntas e preocupações que você vive no momento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;)<br /> ** Metodologias didáticas.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação, aderência e aptidão.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> ** Educação continuada.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, tampouco professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em tantas empresas que já perdi as contas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que reúno bagagem o suficiente para, legitimamente. contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a minha resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''. Há aqueles que adorariam complicar as coisas e sugerir a incorporação de outros elementos e complexidades, tais como condição social, falta de oportunidades, fator &quot;Q.I.&quot; (&quot;Quem Indica&quot;, o famoso contatinho com o &quot;Comandante Faber Castell&quot; lá da empresa), profissional naturalmente desmotivado por ter percebido, após um tempo, que aquela profissão não era para ele, dentre outros fatores e complicações. O fato é, independentemente disso tudo, você &lt;u&gt;jamais decolará&lt;/u&gt; na carreira sem o conhecimento. Seja você rico ou pobre, preto ou branco, nordestino ou sulista, hétero ou homo, evangélico ou ateísta, tudo isso é mínimo se comparado ao que realmente importa para você conseguir deslanchar nesta área, aliás, em qualquer profissão: '''''conhecimento'''''. Você pode até ter ótimos conhecimentos e estar com falta de sorte no momento, mas um indivíduo sem conhecimento é um indivíduo pouco útil para esta ou qualquer carreira ou profissão.Você pode até conseguir um emprego na área com conhecimentos fracos ou medianos, mas, decolar, jamais!<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que conseguíssemos traçar um caminho que de fato pudesse levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos, e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com alguns dos modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, focarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir alguns tipos de conhecimento que são irrelevantes para os meus propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, muitas vezes com base na tentativa e erro, obtido principalmente por observação, experiência em lidar com os resultados herdados por senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> |<br /> * &quot;O ignorante afirma, o sábio duvida, o sensato reflete.&quot; (Aristóteles)<br /> * &quot;Só sei que nada sei.&quot; (Sócrates)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> * &quot;Não existem métodos fáceis para resolver problemas difíceis.&quot; (René Descartes)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> * Aplicar um complexo e plástico golpe de capoeira!<br /> * Arriscar-se com êxito fazendo parkour no alto dos edifícios<br /> Em todos estes casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede com bastante fluidez e obedecendo as guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção sobre a configuração de elementos de rede, relacionando corretamente as áreas funcionais e controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia sendo impulsionada pelo mercado, liderada por um determinado fabricante, centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing.<br /> * &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se de certa forma à favor dos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. <br /> * &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará efetivamente a mesma coisa que as implementações RSVP-TE atuais fazem?&quot;. &quot;Valeria a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?&quot;. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado com marketing/branding do que com soluções técnicas de fato inovadoras?&quot;. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se sempre de incluir o parâmetro &quot;add&quot; para o comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}<br /> Note que não está sendo feito qualquer julgamento em termos de &quot;''que tipo de conhecimento é melhor?''&quot; porque isto simplesmente não existe! Em termos de resultados, ou eficácia, um conhecimento empírico pode ser (e muitas vezes é!) o meio mais correto ou indicado para resolvermos um problema, ou que um conhecimento puramente tácito promova os resultados desejados de forma mais efetiva que com um conhecimento empírico apenas. Um conhecimento científico não é melhor só porque é baseado em alguma teoria aliada à uma comprovação por método, pois um conhecimento filosófico pode resolver, e com alguma frequência isto acontece, um desafio que não está sendo possível resolver com um conhecimento científico; enfim, acho que você me entendeu.<br /> <br /> Caso você não tenha identificado uma afinidade ou utilidade entre esta tabela acima e a proposta deste artigo, algo tipo &quot;tudo muito supérfluo!&quot;, sugiro que repense! Apesar de ter um aspecto um tanto teórico, acho de suma importância você saber identificar como os seus conhecimentos vigentes estão enquadrados ou tipificados. Lá na frente isto poderá ser útil na hora de identificar o que precisa ser feito para aprimorar a maneira como você entende o funcionamento de determinadas tecnologias ou soluções, ou quais práticas e processos precisam ser aprimorados para um suporte mais efetivo destas, dentre outras situações. Alguns exemplos de como este &quot;''drag &amp; drop''&quot; poderia ser feito:<br /> * '''De tudo o que você sabe dissertar ou executar, em sua forma mais prática ou efetiva (implantar, configurar, operar, prestar suporte), ou seja, tecnologias, equipamentos, soluções, processos e afins, o que de fato você:'''<br /> ** '''''Conhece por herança organizacional, seja na empresa atual ou experiências prévias, ou através de convívio e troca de experiências com grupos de indivíduos e suas opiniões?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências. <br /> **** Por exemplo, um roteiro, processo interno da empresa (&quot;é assim que você deve fazer&quot;, &quot;assim funciona&quot;, ou &quot;não faça isto!&quot;), modus operandi do setor da empresa, etc.<br /> *** Estes seriam &lt;u&gt;conhecimentos empíricos&lt;/u&gt;!<br /> ** '''''Conhece, por meios de algum processo de validação, e com o emprego de práticas documentadas em artefatos de indústria, BCOPs, frameworks, e com eficácias e resultados tecnicamente comprovados?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, um projeto e implantação de BGP integralmente apoiado por BCPs (BCP 38, 194, 185, MANRS); uma validação de circuito de dados com base no RFC 2544, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos científicos&lt;/u&gt;!<br /> ** '''''Conhece por questionamentos de princípios de aderência, aplicabilidades, julgamento de utilidade, associação de benefícios e casos de uso?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, a condução de uma análise qualitativa de riscos ou de uma matriz funcional de qualidade; questionamentos e dissertações de casos quanto ao uso de determinadas tecnologias e soluções, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos filosóficos&lt;/u&gt;!<br /> ** '''''Conhece por experiência e vivência próprias, ou seja, tentativa e erro, satisfação e frustração com resultados, etc.?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, saber identificar e antecipar riscos em determinadas manobras de configuração em função de experiência prévia ruim; saber conduzir uma operação através de uma ordem apropriada, evitando-se problemas de indisponibilidades, também por experiência prévia; saber qual versão de software usar por não conter um bug que, em um caso anterior, provocou um distúrbio na sua infraestrutura; saber que, antes de ativar um recurso no software de seu roteador, por experiência prévia/própria, outro recurso deve estar habilitado como pré-requisito, do contrário não funcionará ou provocará algum tipo de distúrbio, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos tácitos&lt;/u&gt;!<br /> Viu só? Nem tudo o que é teoria é &quot;burocrático&quot;! Há sempre como extrair coisas positivas de muitos conceitos teóricos ou aparentemente abstratos. E vou um pouco além neste discurso sobre como isto poderá ser útil para você. Imagine que você fizesse uma auto-avaliação (aliás, sugiro mesmo que faça isto!), qual seria o resultado? E quais seriam os significados destes resultados? Quanto aos &quot;significados&quot;, eu tecerei uma opinião estritamente pessoal, pois a interpretação de cada caso é realmente bastante individualizada. Eu posso pensar de um jeito, e você de outro completamente diferente. Certo? Caso você tenha interesse em saber como &lt;u&gt;'''eu'''&lt;/u&gt; (autor) penso, estas seriam as minhas respostas:<br /> <br /> '''''Pensamento do autor: a avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;tácita'''''&quot;<br /> <br /> Isto para mim significaria uma coisa: generalizando aqui, você pode até ser bem &quot;safo&quot;, mas desde que seus conhecimentos sejam realmente bem seguros e produzam bons resultados. O que é difícil. Explico o por que. São preocupantes as possíveis (e não confirmadas, por isto estou generalizando) divergências entre o que órgãos de indústria ou fabricantes promovem como recomendações e boas práticas, e o que você de fato executa ou como executa o seu trabalho.<br /> <br /> Com a complexidade cada vez mais crescente das soluções tecnológicas, assim como os padrões de boas práticas operacionais, é pouco provável que um indivíduo majoritariamente &quot;tácito&quot; seja efetivo em suas atribuições, especialmente quando pensando aqui nas tantas métricas sobre as quais deverá estar apoiado todo o funcionamento do aparato tecnológico, ou seja, ''Disponibilidade'', ''Performance'', ''Segurança'', ''Confiabilidade'', ''Disponibilidade'', ''Escalabilidade'', e etc. <br /> <br /> Dificilmente um indivíduo deste perfil conseguiria orquestrar um ambiente com conhecimentos puramente tácitos. &quot;Ah, mas ele estudou o manual do fabricante para fazer o procedimento 'x'!&quot;, mas, peraí, isto não seria um conhecimento tácito. Assim como &quot;ele seguiu o processo da Operação da empresa para fazer a configuração&quot;, mas, peraí, isto também não seria um conhecimento tácito. Compreende? <br /> <br /> Não consigo vislumbrar um indivíduo majoritariamente &quot;tácito&quot; funcional, pois, tal perfil, seria um risco tremendo para os negócios de uma empresa. Gambiarras e experimentações individualizadas, com pouco ou nenhum apoio e suporte de conhecimentos científicos ou empíricos, não são uma opção! Nesta área de redes e afins, conhecimento tácito é algo muito íntimo e específico (vide os exemplos da tabela anterior), e geralmente são muito bons/úteis como complemento de outras formas de conhecimento, como o científico e o empírico. <br /> <br /> '''''Pensamento do autor: a avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;empírico'''''&quot;<br /> <br /> Tudo o que um indivíduo aprendeu a executar num ambiente de redes obedecendo algum padrão ou procedimento estabelecido pela empresa ou pelo mercado (&quot;senso comum&quot;), é considerado um conhecimento empírico. Assim como conhecimentos obtidos junto à uma comunidade de especialistas. O que é bom ou muito bom. Especialmente quando o indivíduo passa a entender os cuidados que devem ser observados durante a condução do trabalho em questão. Isto significa que na maior parte do tempo este indivíduo estará conduzindo atividades de acordo com padrões ou modelos confiáveis, realizando configurações, ajustes, manobras, adaptações e afins, tudo inspirado num esqueleto funcional, seguro, e resultados auditáveis ou perceptíveis.<br /> <br /> É nessas horas, inclusive, voltando ao caso anterior, que os conhecimentos &lt;u&gt;tácitos&lt;/u&gt; complementam e fazem a diferença: nem sempre os padrões ou procedimentos são bem elaborados ou seguros; nem sempre as descrições dos requisitos e respectivas tarefas asseguram que o trabalho a ser realizado estará isento de riscos ou que vá funcionar &quot;de primeira&quot;. Como ocorre por muitas vezes, o indivíduo tende a perceber isto e a tomar cuidados extras na hora de conduzir seus trabalhos, podendo usar a sua própria experiência/vivência na hora de fazer as coisas, evitar armadilhas, maximizar resultados, etc. É nessas horas que o indivíduo &quot;safo&quot; usa a sua experiência (conhecimentos tácitos) como complemento aos conhecimentos obtidos de forma empírica ou científica.<br /> <br /> '''''Pensamento do autor: avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;filosófica&quot;'''''<br /> <br /> Um indivíduo, através de uma demanda cotidiana que implemente ações cujos conhecimentos correspondentes/associados foram obtidos de forma empírica (um procedimento, um processo, um modelo...), não importando em qual estágio de sua carreira ele obteve este conhecimento, poderá eventualmente divergir de opiniões. Poderá não concordar, pelo menos não inicialmente, ou até que seja convencido por alguém. Poderá ponderar, questionar os propósitos imputados ou critérios adotados. E, em função disto, poderá desejar modificar ou aprimorar aquela demanda ou aquele processo. Refinar o método como um todo, ou parte dele. <br /> <br /> Obviamente que, &quot;questionar&quot;, &quot;ponderar&quot;, ou &quot;criticar&quot; apenas, recusando-se a todo custo a cumprir com o seu dever, qualquer que tenha sido a tarefa imputada a ele, eu não chamaria isto de conhecimento filosófico, e sim de &quot;birra de criança&quot;. O conhecimento filosófico não é fazer birra ou ter atitudes antiprofissionais! O que se espera de uma iniciativa correta para estes casos é um perfil questionador de um indivíduo trazendo à tona novos desafios e propósitos para a elaboração de novas respostas, e tudo objetivando efetividade e resultados.<br /> <br /> Isto é uma qualidade de conhecimento que tipifica bem um perfil de profissional centrado em qualidade e resultados, e vemos isto muito presente em arquitetos de soluções, alguns perfis de gestores, e até mesmo em engenheiros de redes e analistas.<br /> <br /> === Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC ===<br /> Fugindo aqui momentaneamente deste discurso de tipo de conhecimentos, e retornando ao tema de motivações abordado previamente, mas, desta vez, incorporando justificativas e argumentos na fórmula, quais seriam os principais motivos, justificativas e argumentos para que um indivíduo fosse buscar conhecimentos relacionados aos temas da área de TIC? Tentemos exercitar isto de forma ampla.<br /> {| class=&quot;wikitable&quot;<br /> |+Argumentos, justificativas e motivações para a busca de conhecimentos na área de TIC<br /> !<br /> !<br /> !Argumentos<br /> !<br /> |-<br /> !<br /> !Requisitos para Funções Vigentes<br /> !Requisitos para Funções Futuras<br /> !Requisitos para Prospecções e Planos de Carreira<br /> |-<br /> |<br /> |Obter as qualificações e competências para a conformidade com requisitos vigentes, os quais são estabelecidos pelo empregador.<br /> |Aprendizado e domínio de novas tecnologias, equipamentos ou ferramentas, como parte de um processo de adoção tecnológica na empresa, os quais são impostos ou estabelecidos pelo empregador.<br /> |Obter as qualificações e competências exigidas para enquadramento de perfil junto à uma vaga ou oportunidade pretendida pelo mercado de trabalho.<br /> |-<br /> |<br /> |Aprimorar as habilidades em alinhamento com os requisitos vigentes, os quais são impostos ou estabelecidos pelo empregador.<br /> |Aprimoramento e domínio de habilidades para remodelagem em futuro próximo de componentes, processos e práticas vigentes, e a extração de melhores resultados com o uso de tecnologias atuais, em grande parte por iniciativa própria.<br /> |Obter as qualificações e competências exigidas visando a evolução ou crescimento de carreira, na mesma empresa em que atua no momento ou em outras oportunidades e prospecções.<br /> |-<br /> |<br /> |<br /> |<br /> |<br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2481 2020-05-29T02:03:47Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, visando precisamente o crescimento ou evolução em suas profissões.<br /> # Motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem evoluir?'''''<br /> <br /> A minha resposta mais precisa para esta pergunta é o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema está no método. Ou o método é ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento, e responderá a tantas das perguntas e preocupações que você vive no momento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;)<br /> ** Metodologias didáticas.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação, aderência e aptidão.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> ** Educação continuada.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, tampouco professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em tantas empresas que já perdi as contas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que reúno bagagem o suficiente para, legitimamente. contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''.<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que consigamos traçar um caminho que de fato vá levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos, e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com alguns dos modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, focarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir alguns tipos de conhecimento que são irrelevantes para os meus propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, muitas vezes com base na tentativa e erro, obtido principalmente por observação, experiência em lidar com os resultados herdados por senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> |<br /> * &quot;O ignorante afirma, o sábio duvida, o sensato reflete.&quot; (Aristóteles)<br /> * &quot;Só sei que nada sei.&quot; (Sócrates)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> * &quot;Não existem métodos fáceis para resolver problemas difíceis.&quot; (René Descartes)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> * Aplicar um complexo e plástico golpe de capoeira!<br /> * Arriscar-se com êxito fazendo parkour no alto dos edifícios<br /> Em todos estes casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede com bastante fluidez e obedecendo as guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção sobre a configuração de elementos de rede, relacionando corretamente as áreas funcionais e controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia sendo impulsionada pelo mercado, liderada por um determinado fabricante, centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing.<br /> * &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se de certa forma à favor dos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. <br /> * &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará efetivamente a mesma coisa que as implementações RSVP-TE atuais fazem?&quot;. &quot;Valeria a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?&quot;. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado com marketing/branding do que com soluções técnicas de fato inovadoras?&quot;. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se sempre de incluir o parâmetro &quot;add&quot; para o comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}<br /> Note que não está sendo feito qualquer julgamento em termos de &quot;''que tipo de conhecimento é melhor?''&quot; porque isto simplesmente não existe! Em termos de resultados, ou eficácia, um conhecimento empírico pode ser (e muitas vezes é!) o meio mais correto ou indicado para resolvermos um problema, ou que um conhecimento puramente tácito promova os resultados desejados de forma mais efetiva que um conhecimento empírico. Um conhecimento científico não é melhor só porque é baseado em alguma teoria aliada à uma comprovação de método, pois um conhecimento filosófico pode resolver, e com alguma frequência isto acontece, um desafio que não está sendo possível resolver com um conhecimento científico; enfim, acho que você me entendeu.<br /> <br /> Caso você não tenha identificado uma afinidade ou utilidade entre esta tabela acima e a proposta deste artigo, algo tipo &quot;tudo muito supérfluo!&quot;, sugiro que repense! Apesar de ter um aspecto um tanto teórico, acho de suma importância você saber identificar como os seus conhecimentos vigentes estão enquadrados ou tipificados. Lá na frente isto poderá ser útil na hora de identificar o que precisa ser feito para aprimorar a maneira como você entende o funcionamento de determinadas tecnologias ou soluções, ou quais práticas e processos precisam ser aprimorados para um suporte mais efetivo destas, dentre outras situações. Alguns exemplos de como este &quot;''drag &amp; drop''&quot; poderia ser feito:<br /> * '''De tudo o que você sabe dissertar ou executar, em sua forma mais prática ou efetiva (implantar, configurar, operar, prestar suporte), ou seja, tecnologias, equipamentos, soluções, processos e afins, o que de fato você:'''<br /> ** '''''Conhece por herança organizacional, seja na empresa atual ou experiências prévias, ou através de convívio e troca de experiências com grupos de indivíduos e suas opiniões?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências. <br /> **** Por exemplo, um roteiro, processo interno da empresa (&quot;é assim que você deve fazer&quot;, &quot;assim funciona&quot;, ou &quot;não faça isto!&quot;), modus operandi do setor da empresa, etc.<br /> *** Estes seriam &lt;u&gt;conhecimentos empíricos&lt;/u&gt;!<br /> ** '''''Conhece, por meios de algum processo de validação, e com o emprego de práticas documentadas em artefatos de indústria, BCOPs, frameworks, e com eficácias e resultados tecnicamente comprovados?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, um projeto e implantação de BGP integralmente apoiado por BCPs (BCP 38, 194, 185, MANRS); uma validação de circuito de dados com base no RFC 2544, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos científicos&lt;/u&gt;!<br /> ** '''''Conhece por questionamentos de princípios de aderência, aplicabilidades, julgamento de utilidade, associação de benefícios e casos de uso?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, a condução de uma análise qualitativa de riscos ou de uma matriz funcional de qualidade; questionamentos e dissertações de casos quanto ao uso de determinadas tecnologias e soluções, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos filosóficos&lt;/u&gt;!<br /> ** '''''Conhece por experiência e vivência próprias, ou seja, tentativa e erro, satisfação e frustração com resultados, etc.?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, saber identificar e antecipar riscos em determinadas manobras de configuração em função de experiência prévia ruim; saber conduzir uma operação através de uma ordem apropriada, evitando-se problemas de indisponibilidades, também por experiência prévia; saber qual versão de software usar por não conter um bug que, em um caso anterior, provocou um distúrbio na sua infraestrutura; saber que, antes de ativar um recurso no software de seu roteador, por experiência prévia/própria, outro recurso deve estar habilitado como pré-requisito, do contrário não funcionará ou provocará algum tipo de distúrbio, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos tácitos&lt;/u&gt;!<br /> Viu só? Nem tudo o que é teoria é &quot;burocrático&quot;! Há sempre como extrair coisas positivas de muitos conceitos teóricos ou aparentemente abstratos. E vou um pouco além neste discurso sobre como isto poderá ser útil para você. Imagine que você fizesse uma auto-avaliação (aliás, sugiro mesmo que faça isto!), qual seria o resultado? E quais seriam os significados destes resultados? Quanto aos &quot;significados&quot;, eu tecerei uma opinião estritamente pessoal, pois a interpretação de cada caso é realmente bastante individualizada. Eu posso pensar de um jeito, e você de outro completamente diferente. Certo? Caso você tenha interesse em saber como &lt;u&gt;'''eu'''&lt;/u&gt; (autor) penso, estas seriam as minhas respostas:<br /> <br /> '''''Pensamento do autor: a avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;tácita'''''&quot;<br /> <br /> Isto para mim significaria uma coisa: generalizando aqui, você pode até ser bem &quot;safo&quot;, mas desde que seus conhecimentos sejam realmente bem seguros e produzam bons resultados. O que é difícil. Explico o por que. São preocupantes as possíveis (e não confirmadas, por isto estou generalizando) divergências entre o que órgãos de indústria ou fabricantes promovem como recomendações e boas práticas, e o que você de fato executa ou como executa o seu trabalho.<br /> <br /> Com a complexidade cada vez mais crescente das soluções tecnológicas, assim como os padrões de boas práticas operacionais, é pouco provável que um indivíduo majoritariamente &quot;tácito&quot; seja efetivo em suas atribuições, especialmente quando pensando aqui nas tantas métricas sobre as quais deverá estar apoiado todo o funcionamento do aparato tecnológico, ou seja, ''Disponibilidade'', ''Performance'', ''Segurança'', ''Confiabilidade'', ''Disponibilidade'', ''Escalabilidade'', e etc. <br /> <br /> Dificilmente um indivíduo deste perfil conseguiria orquestrar um ambiente com conhecimentos puramente tácitos. &quot;Ah, mas ele estudou o manual do fabricante para fazer o procedimento 'x'!&quot;, mas, peraí, isto não seria um conhecimento tácito. Assim como &quot;ele seguiu o processo da Operação da empresa para fazer a configuração&quot;, mas, peraí, isto também não seria um conhecimento tácito. Compreende? <br /> <br /> Não consigo vislumbrar um indivíduo majoritariamente &quot;tácito&quot; funcional, pois, tal perfil, seria um risco tremendo para os negócios de uma empresa. Gambiarras e experimentações individualizadas, com pouco ou nenhum apoio e suporte de conhecimentos científicos ou empíricos, não são uma opção! Nesta área de redes e afins, conhecimento tácito é algo muito íntimo e específico (vide os exemplos da tabela anterior), e geralmente são muito bons/úteis como complemento de outras formas de conhecimento, como o científico e o empírico. <br /> <br /> '''''Pensamento do autor: a avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;empírico'''''&quot;<br /> <br /> Tudo o que um indivíduo aprendeu a executar num ambiente de redes obedecendo algum padrão ou procedimento estabelecido pela empresa ou pelo mercado (&quot;senso comum&quot;), é considerado um conhecimento empírico. Assim como conhecimentos obtidos junto à uma comunidade de especialistas. O que é bom ou muito bom. Especialmente quando o indivíduo passa a entender os cuidados que devem ser observados durante a condução do trabalho em questão. Isto significa que na maior parte do tempo este indivíduo estará conduzindo atividades de acordo com padrões ou modelos confiáveis, realizando configurações, ajustes, manobras, adaptações e afins, tudo inspirado num esqueleto funcional, seguro, e resultados auditáveis ou perceptíveis.<br /> <br /> É nessas horas, inclusive, voltando ao caso anterior, que os conhecimentos &lt;u&gt;tácitos&lt;/u&gt; complementam e fazem a diferença: nem sempre os padrões ou procedimentos são bem elaborados ou seguros; nem sempre as descrições dos requisitos e respectivas tarefas asseguram que o trabalho a ser realizado estará isento de riscos ou que vá funcionar &quot;de primeira&quot;. Como ocorre por muitas vezes, o indivíduo tende a perceber isto e a tomar cuidados extras na hora de conduzir seus trabalhos, podendo usar a sua própria experiência/vivência na hora de fazer as coisas, evitar armadilhas, maximizar resultados, etc. É nessas horas que o indivíduo &quot;safo&quot; usa a sua experiência (conhecimentos tácitos) como complemento aos conhecimentos obtidos de forma empírica ou científica.<br /> <br /> '''''Pensamento do autor: avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;filosófica&quot;'''''<br /> <br /> Um indivíduo, através de uma ação cotidiana que implemente ações cujos conhecimentos correspondentes/associados foram obtidos de forma empírica (um procedimento, um processo...), poderá eventualmente divergir de opiniões. Poderá não concordar, pelo menos não inicialmente, ou até que seja convencido por alguém. Poderá ponderar, questionar os propósitos imputados ou critérios adotados. E, em função disto, poderá desejar modificar ou aprimorar aquela demanda ou aquele processo. Refinar o método como um todo, ou parte dele. <br /> <br /> Obviamente que, &quot;questionar&quot;, &quot;ponderar&quot;, ou &quot;criticar&quot; apenas, recusando-se a todo custo a cumprir com o seu dever, qualquer que tenha sido a tarefa imputada a ele, eu não chamaria isto de conhecimento filosófico, e sim de &quot;birra de criança&quot;. O conhecimento filosófico não é fazer birra ou ter atitudes antiprofissionais! O que se espera de uma iniciativa correta para estes casos é um perfil questionador de um indivíduo trazendo à tona novos desafios e propósitos para a elaboração de novas respostas, e tudo objetivando efetividade e resultados.<br /> <br /> Isto é uma qualidade de conhecimento que tipifica bem um perfil de profissional centrado em qualidade e resultados, e vemos isto muito presente em arquitetos de soluções, alguns perfis de gestores, e até mesmo em engenheiros de redes e analistas.<br /> <br /> === Motivações para a busca de conhecimentos na área de TIC ===<br /> Fugindo aqui momentaneamente deste discurso de tipo de conhecimentos, e retornando ao tema de motivações abordado previamente, mas, desta vez, incorporando justificativas e argumentos na fórmula, quais seriam os principais motivos, justificativas e argumentos para que um indivíduo fosse buscar conhecimentos relacionados aos temas da área de TIC? Tentemos exercitar isto de forma ampla.<br /> {| class=&quot;wikitable&quot;<br /> |+Motivações<br /> !<br /> !<br /> !Argumentos<br /> !<br /> |-<br /> !<br /> !Requisitos para Funções Vigentes<br /> !Requisitos para Funções Futuras<br /> !Requisitos para Prospecções e Planos de Carreira<br /> |-<br /> |<br /> |Obter as qualificações e competências para a conformidade com requisitos vigentes, os quais são estabelecidos pelo empregador.<br /> |Aprendizado e domínio de novas tecnologias, equipamentos ou ferramentas, como parte de um processo de adoção tecnológica na empresa, os quais são impostos ou estabelecidos pelo empregador.<br /> |Obter as qualificações e competências exigidas para enquadramento de perfil junto à uma vaga ou oportunidade pretendida pelo mercado de trabalho.<br /> |-<br /> |<br /> |Aprimorar as habilidades em alinhamento com os requisitos vigentes, os quais são impostos ou estabelecidos pelo empregador.<br /> |Aprimoramento e domínio de habilidades para remodelagem em futuro próximo de componentes, processos e práticas vigentes, e a extração de melhores resultados com o uso de tecnologias atuais, em grande parte por iniciativa própria.<br /> |Obter as qualificações e competências exigidas visando a evolução ou crescimento de carreira, na mesma empresa em que atua no momento ou em outras oportunidades e prospecções.<br /> |-<br /> |<br /> |<br /> |<br /> |<br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2480 2020-05-29T01:51:46Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, visando precisamente o crescimento ou evolução em suas profissões.<br /> # Motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem evoluir?'''''<br /> <br /> A minha resposta mais precisa para esta pergunta é o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema está no método. Ou o método é ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento, e responderá a tantas das perguntas e preocupações que você vive no momento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;)<br /> ** Metodologias didáticas.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação, aderência e aptidão.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> ** Educação continuada.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, tampouco professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em tantas empresas que já perdi as contas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que reúno bagagem o suficiente para, legitimamente. contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''.<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que consigamos traçar um caminho que de fato vá levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos, e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com alguns dos modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, focarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir alguns tipos de conhecimento que são irrelevantes para os meus propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, muitas vezes com base na tentativa e erro, obtido principalmente por observação, experiência em lidar com os resultados herdados por senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> |<br /> * &quot;O ignorante afirma, o sábio duvida, o sensato reflete.&quot; (Aristóteles)<br /> * &quot;Só sei que nada sei.&quot; (Sócrates)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> * &quot;Não existem métodos fáceis para resolver problemas difíceis.&quot; (René Descartes)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> * Aplicar um complexo e plástico golpe de capoeira!<br /> * Arriscar-se com êxito fazendo parkour no alto dos edifícios<br /> Em todos estes casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede com bastante fluidez e obedecendo as guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção sobre a configuração de elementos de rede, relacionando corretamente as áreas funcionais e controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia sendo impulsionada pelo mercado, liderada por um determinado fabricante, centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing.<br /> * &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se de certa forma à favor dos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. <br /> * &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará efetivamente a mesma coisa que as implementações RSVP-TE atuais fazem?&quot;. &quot;Valeria a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?&quot;. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado com marketing/branding do que com soluções técnicas de fato inovadoras?&quot;. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se sempre de incluir o parâmetro &quot;add&quot; para o comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}<br /> Note que não está sendo feito qualquer julgamento em termos de &quot;''que tipo de conhecimento é melhor?''&quot; porque isto simplesmente não existe! Em termos de resultados, ou eficácia, um conhecimento empírico pode ser (e muitas vezes é!) o meio mais correto ou indicado para resolvermos um problema, ou que um conhecimento puramente tácito promova os resultados desejados de forma mais efetiva que um conhecimento empírico. Um conhecimento científico não é melhor só porque é baseado em alguma teoria aliada à uma comprovação de método, pois um conhecimento filosófico pode resolver, e com alguma frequência isto acontece, um desafio que não está sendo possível resolver com um conhecimento científico; enfim, acho que você me entendeu.<br /> <br /> Caso você não tenha identificado uma afinidade ou utilidade entre esta tabela acima e a proposta deste artigo, algo tipo &quot;tudo muito supérfluo!&quot;, sugiro que repense! Apesar de ter um aspecto um tanto teórico, acho de suma importância você saber identificar como os seus conhecimentos vigentes estão enquadrados ou tipificados. Lá na frente isto poderá ser útil na hora de identificar o que precisa ser feito para aprimorar a maneira como você entende o funcionamento de determinadas tecnologias ou soluções, ou quais práticas e processos precisam ser aprimorados para um suporte mais efetivo destas, dentre outras situações. Alguns exemplos de como este &quot;''drag &amp; drop''&quot; poderia ser feito:<br /> * '''De tudo o que você sabe dissertar ou executar, em sua forma mais prática ou efetiva (implantar, configurar, operar, prestar suporte), ou seja, tecnologias, equipamentos, soluções, processos e afins, o que de fato você:'''<br /> ** '''''Conhece por herança organizacional, seja na empresa atual ou experiências prévias, ou através de convívio e troca de experiências com grupos de indivíduos e suas opiniões?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências. <br /> **** Por exemplo, um roteiro, processo interno da empresa (&quot;é assim que você deve fazer&quot;, &quot;assim funciona&quot;, ou &quot;não faça isto!&quot;), modus operandi do setor da empresa, etc.<br /> *** Estes seriam &lt;u&gt;conhecimentos empíricos&lt;/u&gt;!<br /> ** '''''Conhece, por meios de algum processo de validação, e com o emprego de práticas documentadas em artefatos de indústria, BCOPs, frameworks, e com eficácias e resultados tecnicamente comprovados?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, um projeto e implantação de BGP integralmente apoiado por BCPs (BCP 38, 194, 185, MANRS); uma validação de circuito de dados com base no RFC 2544, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos científicos&lt;/u&gt;!<br /> ** '''''Conhece por questionamentos de princípios de aderência, aplicabilidades, julgamento de utilidade, associação de benefícios e casos de uso?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, a condução de uma análise qualitativa de riscos ou de uma matriz funcional de qualidade; questionamentos e dissertações de casos quanto ao uso de determinadas tecnologias e soluções, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos filosóficos&lt;/u&gt;!<br /> ** '''''Conhece por experiência e vivência próprias, ou seja, tentativa e erro, satisfação e frustração com resultados, etc.?'''''<br /> *** Procure identificar e relacionar estas habilidades e competências.<br /> **** Por exemplo, saber identificar e antecipar riscos em determinadas manobras de configuração em função de experiência prévia ruim; saber conduzir uma operação através de uma ordem apropriada, evitando-se problemas de indisponibilidades, também por experiência prévia; saber qual versão de software usar por não conter um bug que, em um caso anterior, provocou um distúrbio na sua infraestrutura; saber que, antes de ativar um recurso no software de seu roteador, por experiência prévia/própria, outro recurso deve estar habilitado como pré-requisito, do contrário não funcionará ou provocará algum tipo de distúrbio, etc.<br /> *** Estes seriam os seus &lt;u&gt;conhecimentos tácitos&lt;/u&gt;!<br /> Viu só? Nem tudo o que é teoria é &quot;burocrático&quot;! Há sempre como extrair coisas positivas de muitos conceitos teóricos ou aparentemente abstratos. E vou um pouco além neste discurso sobre como isto poderá ser útil para você. Imagine que você fizesse uma auto-avaliação (aliás, sugiro mesmo que faça isto!), qual seria o resultado? E quais seriam os significados destes resultados? Quanto aos &quot;significados&quot;, eu tecerei uma opinião estritamente pessoal, pois a interpretação de cada caso é realmente bastante individualizada. Eu posso pensar de um jeito, e você de outro completamente diferente. Certo? Caso você tenha interesse em saber como &lt;u&gt;'''eu'''&lt;/u&gt; (autor) penso, estas seriam as minhas respostas:<br /> <br /> '''''Pensamento do autor: a avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;tácita'''''&quot;<br /> <br /> Isto para mim significaria uma coisa: generalizando aqui, você pode até ser bem &quot;safo&quot;, mas desde que seus conhecimentos sejam realmente bem seguros e produzam bons resultados. O que é difícil. Explico o por que. São preocupantes as possíveis (e não confirmadas, por isto estou generalizando) divergências entre o que órgãos de indústria ou fabricantes promovem como recomendações e boas práticas, e o que você de fato executa ou como executa o seu trabalho.<br /> <br /> Com a complexidade cada vez mais crescente das soluções tecnológicas, assim como os padrões de boas práticas operacionais, é pouco provável que um indivíduo majoritariamente &quot;tácito&quot; seja efetivo em suas atribuições, especialmente quando pensando aqui nas tantas métricas sobre as quais deverá estar apoiado todo o funcionamento do aparato tecnológico, ou seja, ''Disponibilidade'', ''Performance'', ''Segurança'', ''Confiabilidade'', ''Disponibilidade'', ''Escalabilidade'', e etc. <br /> <br /> Dificilmente um indivíduo deste perfil conseguiria orquestrar um ambiente com conhecimentos puramente tácitos. &quot;Ah, mas ele estudou o manual do fabricante para fazer o procedimento 'x'!&quot;, mas, peraí, isto não seria um conhecimento tácito. Assim como &quot;ele seguiu o processo da Operação da empresa para fazer a configuração&quot;, mas, peraí, isto também não seria um conhecimento tácito. Compreende? <br /> <br /> Não consigo vislumbrar um indivíduo majoritariamente &quot;tácito&quot; funcional, pois tal perfil seria um risco tremendo para os negócios de uma empresa. Gambiarras e experimentações individualizadas, com pouco ou nenhum apoio e suporte de conhecimentos científicos ou empíricos, não são uma opção! Nesta área de redes e afins, conhecimento tácito é algo muito íntimo e específico (vide os exemplos da tabela anterior), e geralmente são muito bons/úteis como complemento de outras formas de conhecimento, como o científico e o empírico. <br /> <br /> '''''Pensamento do autor: a avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;empírico'''''&quot;<br /> <br /> Tudo o que um indivíduo aprendeu a executar num ambiente de redes obedecendo algum padrão ou procedimento estabelecido pela empresa ou pelo mercado (&quot;senso comum&quot;), é considerado um conhecimento empírico. Assim como conhecimentos obtidos junto à uma comunidade de especialistas. O que é bom ou muito bom. Especialmente quando o indivíduo passa a entender os cuidados que devem ser observados durante a condução do trabalho em questão. Isto significa que na maior parte do tempo este indivíduo estará conduzindo atividades de acordo com padrões ou modelos confiáveis, realizando configurações, ajustes, manobras, adaptações e afins, tudo inspirado num esqueleto funcional, seguro, e resultados auditáveis ou perceptíveis.<br /> <br /> É nessas horas, inclusive, voltando ao caso anterior, que os conhecimentos &lt;u&gt;tácitos&lt;/u&gt; complementam e fazem a diferença: nem sempre os padrões ou procedimentos são bem elaborados ou seguros; nem sempre as descrições dos requisitos e respectivas tarefas asseguram que o trabalho a ser realizado estará isento de riscos ou que vá funcionar &quot;de primeira&quot;. Muitos indivíduos tendem a perceber isto e a tomar cuidados extras na hora de conduzir seus trabalhos, podendo usar a sua própria experiência/vivência na hora de fazer as coisas, evitar armadilhas, maximizar resultados, etc. É nessas horas que o indivíduo &quot;safo&quot; usa a sua experiência (conhecimentos tácitos) como complemento aos conhecimentos obtidos de forma empírica ou científica.<br /> <br /> '''''Pensamento do autor: avaliação geral dos seus conhecimentos indicou a maior parte como sendo &quot;filosófica&quot;'''''<br /> <br /> Um indivíduo, através de uma ação cotidiana que implemente ações cujos conhecimentos correspondentes/associados foram obtidos de forma empírica (um procedimento, um processo...), poderá eventualmente divergir de opiniões. Poderá não concordar, pelo menos não inicialmente, ou até que seja convencido por alguém. Poderá ponderar, questionar os propósitos imputados ou critérios adotados. E, em função disto, poderá desejar modificar ou aprimorar aquela demanda ou aquele processo. Refinar o método como um todo. <br /> <br /> Obviamente que &quot;questionar&quot;, &quot;ponderar&quot;, ou &quot;criticar&quot; apenas, recusando-se a todo custo a cumprir com o seu dever, qualquer que tenha sido a tarefa imputada a ele, eu não chamaria isto de conhecimento filosófico, e sim de &quot;birra de criança&quot;. O conhecimento filosófico não é fazer birra e ter atitudes antiprofissionais! O que se espera de uma iniciativa correta para estes casos é um perfil questionador do indivíduo trazendo à tona novos desafios e propósitos para novas respostas, e tudo objetivando efetividade e resultados.<br /> <br /> Isto é uma qualidade de conhecimento filosófico que tipifica bem um perfil de profissional centrado em qualidade e resultados, e vemos isto muito presente em arquitetos de soluções, alguns perfis de gestores, e até mesmo em engenheiros de redes e analistas.<br /> <br /> === Motivações para a busca de conhecimentos na área de TIC ===<br /> Fugindo aqui momentaneamente deste discurso de tipo de conhecimentos, e retornando ao tema de motivações abordado previamente, mas, desta vez, incorporando justificativas e argumentos na fórmula, quais seriam os principais motivos, justificativas e argumentos para que um indivíduo fosse buscar conhecimentos relacionados aos temas da área de TIC? Tentemos exercitar isto de forma ampla.<br /> {| class=&quot;wikitable&quot;<br /> |+Motivações<br /> !<br /> !<br /> !Argumentos<br /> !<br /> |-<br /> !<br /> !Requisitos para Funções Vigentes<br /> !Requisitos para Funções Futuras<br /> !Requisitos para Prospecções e Planos de Carreira<br /> |-<br /> |<br /> |Obter as qualificações e competências para a conformidade com requisitos vigentes, os quais são estabelecidos pelo empregador.<br /> |Aprendizado e domínio de novas tecnologias, equipamentos ou ferramentas, como parte de um processo de adoção tecnológica na empresa, os quais são impostos ou estabelecidos pelo empregador.<br /> |Obter as qualificações e competências exigidas para enquadramento de perfil junto à uma vaga ou oportunidade pretendida pelo mercado de trabalho.<br /> |-<br /> |<br /> |Aprimorar as habilidades em alinhamento com os requisitos vigentes, os quais são impostos ou estabelecidos pelo empregador.<br /> |Aprimoramento e domínio de habilidades para remodelagem em futuro próximo de componentes, processos e práticas vigentes, e a extração de melhores resultados com o uso de tecnologias atuais, em grande parte por iniciativa própria.<br /> |Obter as qualificações e competências exigidas visando a evolução ou crescimento de carreira, na mesma empresa em que atua no momento ou em outras oportunidades e prospecções.<br /> |-<br /> |<br /> |<br /> |<br /> |<br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2479 2020-05-28T20:07:43Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, visando precisamente o crescimento ou evolução em suas profissões.<br /> # Motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem evoluir?'''''<br /> <br /> A minha resposta mais precisa para esta pergunta é o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema está no método. Ou o método é ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, e ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;)<br /> ** Metodologias didáticas.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação e aptidão.<br /> ** Educação continuada.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, '''&lt;u&gt;tampouco&lt;/u&gt;''' professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em mais de 500 empresas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que posso legitimamente contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''.<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que consigamos traçar um caminho que de fato vá levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos, e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com alguns dos modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, focarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir alguns tipos de conhecimento que são irrelevantes para os meus propósitos pretendidos, como o teológico, mítico, sensorial, artístico e outros.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, muitas vezes com base na tentativa e erro, obtido principalmente por observação, experiência em lidar com os resultados herdados por senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> |<br /> * &quot;O amor é a expressão da carência&quot; (Platão)<br /> * &quot;Penso, logo existo&quot; (Descartes)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> Em ambos os casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> * O profissional que executa intervenções nas configurações dos elementos de rede com bastante fluidez e obedecendo as guias operacionais (GMUD) instauradas pela área de Operações da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> * O profissional que desenvolve ou conduz/opera procedimentos de intervenção sobre a configuração de elementos de rede, relacionando corretamente as áreas funcionais e controles de frameworks consagrados da indústria, como ITIL, COBIT e Frameworx eTOM BPF, como ferramentas e métodos seguros para o gerenciamento de configurações.<br /> |<br /> * O profissional que questiona a eficácia ou o propósito de uma nova tecnologia sendo impulsionada pelo mercado, liderada por um determinado fabricante, centrada na evolução das arquiteturas baseadas no MPLS. Neste caso, o Segment Routing. &quot;Por que isto é necessário?&quot;. &quot;Por que não sanear a parte 'X' das implementações MPLS tradicionais, ao invés de reescrever o book inteiro, forçando bases inteiras de clientes a comprarem novos equipamentos somente para poderem acomodar o SRv6?&quot;.<br /> * O profissional que questiona a aplicabilidade da nova tecnologia de engenharia de tráfego baseada no Segment Routing (SR-TE), opondo-se de certa forma à favor dos cenários e soluções maduras e vigentes com a tecnologia RSVP-TE. &quot;Até onde é vantajoso empurrar uma tecnologia que, em termos de resultados práticos, fará efetivamente a mesma coisa que as implementações RSVP-TE atuais fazem?&quot;. &quot;Valeria a pena substituir o hardware de grande parte da minha rede para acomodar o SR-TE, especialmente observando o caso do SRv6, apenas para reduzir a quantidade de protocolos no meu control plane?&quot;. &quot;Não estaria o SR-TE, assim como o SRv6, mais alinhado com marketing/branding do que com soluções técnicas de fato inovadoras?&quot;. <br /> * O profissional que questiona os indicadores-chave de performance afetados pelas ações de Engenharia e Operações da empresa, e que busca sanear estes problemas com iniciativas que buscam equilibrar eficiência operacional, custos operacionais, desenvolvimento do potencial do capital humano; instauração de metodologias/métodos de reorganização ao suporte aos problemas que são percebidos pelos clientes e absorvidos pelas áreas internas da empresa.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes no regime de tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> * O profissional que aprende por osmose ou tentativa &amp; erro que deverá possuir backup da configuração do equipamento antes de efetivar as modificações desejadas, ou que implementa um &quot;commit confirmed&quot; para rollback instantâneo, pois, da última vez que interviu na configuração de um equipamento, provocou acidentalmente um downtime que o isolou por longo período de tempo, além de afetar clientes. O profissional que sabe que precisa coordenar manobras de configuração na rede, pois compreende, por experiência prévia ou não, que a sua central de atendimento será inundada de telefonemas de clientes reclamando, desavisados da manobra.<br /> * O profissional que procura lembrar-se sempre de incluir o parâmetro &quot;add&quot; para o comando &quot;switchport trunk allowed vlan&quot; quando autorizando uma nova VLAN para um uplink/tronco em switches Cisco, pois, do contrário, sabe que, por experiência prévia, provocará uma grande indisponibilidade nos serviços da rede.<br /> <br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2476 2020-05-28T18:49:16Z

<p>Leonardo.furtado: </p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, visando precisamente o crescimento ou evolução em suas profissões.<br /> # Motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem evoluir?'''''<br /> <br /> A minha resposta mais precisa para esta pergunta é o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema está no método. Ou o método é ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, e ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;)<br /> ** Metodologias didáticas.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação e aptidão.<br /> ** Educação continuada.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, '''&lt;u&gt;tampouco&lt;/u&gt;''' professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em mais de 500 empresas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que posso legitimamente contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''.<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que consigamos traçar um caminho que de fato vá levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com os modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, ficarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir conhecimento teológico, mítico, sensorial, artístico e outros.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, muitas vezes com base na tentativa e erro, obtido principalmente por observação, experiência em lidar com os resultados e senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> |<br /> * &quot;O amor é a expressão da carência&quot; (Platão)<br /> * &quot;Penso, logo existo&quot; (Descartes)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> Em ambos os casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à área de TIC'''<br /> |<br /> * O profissional que adquire experiência no dimensionamento e provisionamento de circuitos de comunicação de dados com base nos conhecimentos adquiridos por senso comum, tais como procedimentos estabelecidos por áreas internas da empresa.<br /> * O profissional de operação de redes que conduz configurações do protocolo de roteamento OSPF com base em experiência adquirida com os procedimentos e padrões definidos pela área de Engenharia da empresa, adquirindo boa competência e segurança no procedimento.<br /> * O profissional adquire experiência no provisionamento/ativação de circuitos ou serviços (ex: L3VPN, L2VPN, BGP) de clientes em um ISP seguindo um roteiro ou conhecimento herdado. Apesar da experiência e fluidez ao executar o procedimento, o profissional muitas das vezes não conhece bem o funcionamento destas tecnologias ou não sabe justificar os métodos empregados.<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados empregando o Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais, incorporando em seu trabalho os conceitos discutidos pelo &lt;nowiki&gt;RFC 5136&lt;/nowiki&gt; (Defining Network Capacity), &lt;nowiki&gt;RFC 2544&lt;/nowiki&gt; (Benchmarking Methodology for Network Interconnect Devices), dentre outras práticas, metodologias e ferramentas.<br /> * O profissional que, ao projetar, implantar ou suportar uma rede OSPF compreende o funcionamento do algoritmo Dijkstra para a determinação de caminhos de menor custo, e sabe dissertar com propriedade sobre os componentes gerais do OSPF, ou que projeta redes OSPF conhecendo seus componentes e boas práticas.<br /> * O profissional que descreve de forma correta e fluida sobre cada um dos componentes envolvidos na composição de um serviço de cliente (L3VPN, L2VPN, BGP), atentando quanto aos seus respectivos componentes e RFCs, procedimentos homologados pela documentação dos fabricantes de equipamentos, e características de funcionamento e integração do arranjo tecnológico destas soluções.<br /> |<br /> |<br /> * O profissional que dimensiona e provisiona circuitos de comunicação de dados usando como &quot;bússola&quot; os conhecimentos obtidos por experiência prévia em outras áreas da tecnologia de redes, extraindo resultados baseados em observações próprias, in loco.<br /> * O profissional que realiza procedimentos de configuração e operação do OSPF com base em observações próprias, muitas vezes na base da tentativa &amp; erro e análises de resultados, incorporando seus próprios padrões e métodos na medida em que vai revelando o que pode ser feito e o que não deve ser feito.<br /> * O profissional que realiza configurações para ativação de um serviço de cliente (ex: L3VPN, L2VPN, BGP), muitas das vezes respondendo à demandas emergenciais ou necessidades de curto prazo, e que experimenta, na base da tentativa/erro, e análises de resultados, concluir o objetivo desejado sem que haja necessariamente um procedimento interno homologado para isto ou o emprego de práticas discutidas pelos padrões associados a estas tecnologias.<br /> <br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Como_decolar_na_carreira_da_tecnologia_da_informacao_e_comunicacao&diff=2474 2020-05-28T04:27:14Z

<p>Leonardo.furtado: Draft, inicial, ainda em desenvolvimento.</p> <hr /> <div>== Como Decolar na Carreira da Tecnologia da Informação e Comunicação ==<br /> <br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Confesso que tive certa dificuldade em produzir este artigo, pois, sabe como é, as vezes a minha cabeça dá aquela viajada e vai a mil! Sabe aquela diferença entre ''control plane'' e ''data plane''? RIB e FIB? Nem sempre é fácil colocar de forma prática, concreta e útil mesmo, aquilo que estou maquinando lá nos confins de minha mente...<br /> <br /> Mas o que me motivou a seguir adiante e a tentar implementar as minhas idéias aqui, no &quot;data plane&quot;, ou seja, na forma de um artigo, foi a constatação após anos e anos dialogando com diversos profissionais na área, dentre alunos, colegas de trabalho e clientes, especificamente quando discutindo (ou observando apenas) a questão de resultados na carreira profissional destes e de outros indivíduos. Faça as seguintes perguntas a si mesmo:<br /> * '''''Com quantas pessoas você já conversou sobre insatisfação com o trabalho, especialmente aquelas questões relacionadas aos resultados em suas carreiras?'''''<br /> * '''''Com quantas pessoas você já dialogou que não sabem exatamente por onde começar na área, no que diz respeito a estudos, certificações, e afins?'''''<br /> * '''''Com quantas pessoas você já dialogou sobre estagnação na questão de conhecimentos? Pessoas que já atuam na área por alguns anos, mas que estão literalmente estagnadas?'''''<br /> * '''''Quantos indivíduos da área você conhece (talvez você seja um destes!) que possuem em seus computadores, ou até mesmo em HDDs externos, uma fartura monstruosa de materiais de todos os tipos, dentre ebooks, cursos, PDFs, PPTs, etc., mas que, ao mesmo tempo, não conseguem extrair praticamente qualquer coisa útil, ou que usufruem muito pouco disto tudo?''''' <br /> * '''''Quantos indivíduos &quot;cursomaníacos&quot;, os chamados &quot;'''studentholics'''&quot;, você conhece? Aqueles caras que fazem cursos bem frequentemente de praticamente tudo mas que, ao mesmo tempo, isto aparentemente faz pouca diferença para suas carreiras?'''''<br /> Convenhamos, a quantidade de materiais - fartura mesmo - disponíveis na Internet é praticamente infinita, desde artigos, blogues, vídeos, tutoriais, cursos EAD, sem contar com aquilo que você pode fazer fora da Internet, tais como cursos, seminários e workshops presenciais, dentre tantas coisas. Tudo isso é muito farto e amplamente disponível. E muita gente é exposta a uma rotina assim, com excesso de informação e acesso a todo tipo de material, mas, estranhamente, são pessoas que não conseguem atingir os seus objetivos de carreira. Possuem dificuldades para evoluir técnica e profissionalmente, ou não se sentem realizadas com seus trabalhos vigentes, ou ambos. Onde está o problema?<br /> <br /> Ao longo dos meus quase 25 anos de carreira consegui identificar os seguintes quatro perfis de indivíduos que não têm tido êxito nas questões associadas ao crescimento de suas carreiras profissionais. Veja se você consegue se identificar em algum destes perfis:<br /> # '''''O indivíduo que tem recursos adequados (materiais, acesso a cursos, mentoria, etc.), mas que não tem organização pessoal para usufruir disto (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que não tem os recursos suficientes (materiais, acesso a cursos, mentoria, etc.), mas possui alguma ou boa organização pessoal (foco, disciplina, compromisso, responsabilidade, etc.).'''''<br /> # '''''O indivíduo que tem nem um, nem outro. Ou seja, sem recursos e sem organização pessoal adequados.'''''<br /> # '''''O indivíduo que possui ambos recursos e organização pessoal, mas que, mesmo assim, está virtualmente estagnado ou sem ainda obter êxito desejado no crescimento de carreira.'''''<br /> Agora, faço a seguinte pergunta. Aliás, recomendo que você faça também a si mesmo: '''''o que estes quatro perfis possuem em comum?''''' <br /> <br /> As minhas respostas seriam:<br /> # Obtenção de conhecimentos. Sim, este 4 perfis possuem em comum o interesse pela obtenção de conhecimentos como um dos pilares de objetivos de carreira, visando precisamente o crescimento ou evolução em suas profissões.<br /> # Motivações pessoais. Para alguns, uma questão puramente financeira, ou seja, evoluir para conquistar trabalhos de melhor remuneração. Para outros, a pura satisfação de estar lidando com algo que lhes dê prazer ou que os habilitem a encarar e superar desafios. Para muitos, as duas coisas!<br /> Mais uma pergunta aqui: '''''é possível identificar os elementos impeditivos em comum para estes 4 perfis, ou seja, por que, com tantos recursos, materiais, cursos, &quot;excesso de informação&quot;, muitos profissionais da área não conseguem evoluir?'''''<br /> <br /> A minha resposta mais precisa para esta pergunta é o '''''&lt;u&gt;método&lt;/u&gt;'''''. O problema está no método. Ou o método é ausente, incompleto, desfocado, desviado ou disforme. Método possui como significado &quot;''ramo da lógica que se ocupa dos métodos das diferentes ciências''&quot; e, por extensão, &quot;''corpo de regras e diligências estabelecidas para realizar uma pesquisa; método.''&quot;. Eu entendo que, antes de você querer sair estudando tudo o que vir pela frente, ler indeliberadamente todo o tipo de material, realizar todos os cursos e exames que certificação que aparecerem na sua frente, etc., enfim, que antes de tudo isso, você estabeleça um método. Será exatamente este método que norteará todo o seu roteiro de ascensão profissional, apontará para a direção para qual você deverá navegar, e ditará algumas diretivas essenciais para o êxito desta sua empreitada pela busca do conhecimento:<br /> * Identificação dos conteúdos relevantes para o meu propósito de carreira, os quais são ditados por objetivos, motivações pessoais, diretivas do trabalho vigente, etc. (&quot;''O que eu devo estudar?''&quot;)<br /> ** A validação de aderência dos temas e tópicos. (&quot;''O que é relevante para reconhecimento profissional e funcionamento ou efetividade em curto prazo? E, no longo prazo, o que devo observar para dar o próximo salto na carreira?''&quot;)<br /> ** A identificação de pré-requisitos e estruturação de interações. (&quot;''Qual deverá ser a ordem de prioridades e sequências dos meus estudos?''&quot;)<br /> * Elaboração de um plano de estudos. (&quot;''Como devo conduzir a minha busca por conhecimentos?''&quot;)<br /> ** Metodologias didáticas.<br /> ** Recursos didáticos.<br /> ** Ferramentas.<br /> ** Validação e aptidão.<br /> ** Educação continuada.<br /> * Reorganização pessoal para acomodar meu plano de estudos.<br /> ** Disciplina.<br /> ** Foco.<br /> ** Compromisso.<br /> ** Responsabilidade.<br /> * Etc.<br /> Por isto que entendo que o método vem antes de tudo. Antes mesmo de questões óbvias, como a disciplina, foco, compromisso e tudo mais, tudo deve começar com o a definição e instauração propriamente dita de um método, pois este deverá compor o alicerce que acomodará todo o resto. E é basicamente por este modelo ou arranjo de idéias que resolvi organizar este artigo. Entenda que este artigo tem uma pegada um tanto &quot;pessoal&quot;, e estou sendo honesto com o leitor: '''&lt;u&gt;não&lt;/u&gt;''' sou formado em pedagogia, &lt;u&gt;'''não'''&lt;/u&gt; sou educador, '''&lt;u&gt;tampouco&lt;/u&gt;''' professor. Sou apenas um (acredito) qualificado &quot;arquiteto de soluções de TI&quot; com muitos anos de bagagem nas funções de engenharia de redes e sistemas, projetos executados em mais de 500 empresas, além de umas 7 mil &quot;horas de vôo&quot; atuando também como instrutor. Embora estas credenciais não me qualifiquem como pedagogo ou educador, acho que posso legitimamente contribuir para que estudantes e profissionais da área consigam identificar as suas fraquezas e limitações, almejando êxito para as suas carreiras. <br /> <br /> Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo. Vamos lá?<br /> <br /> === Significado da palavra &quot;conhecimento&quot; ===<br /> Caso você esteja se perguntando &quot;''como decolar na carreira da tecnologia da informação e comunicação?''&quot;, a resposta mais objetiva para esta pergunta seria: '''''conhecimento'''''.<br /> <br /> No entanto, o termo &quot;conhecimento&quot; é um tanto subjetivo e precisaríamos explorar isto com maior propriedade para que consigamos traçar um caminho que de fato vá levá-lo ao tão desejado êxito na carreira da tecnologia da informação e comunicação (ou &quot;TIC&quot;). E é exatamente esta e outras respostas que planejo abordar neste artigo, além de tentar sugerir um plano ou roteiro que possa ser seguido por você, leitor, seja você um iniciante na área ou um profissional já rodado, com alguma experiência.<br /> <br /> Para provar que o termo ''conhecimento'' é tão subjetivo para os nossos propósitos, mas, ao mesmo tempo, tão óbvio, vejamos o seu significado gramatical:<br /> <br /> Substantivo masculino<br /> <br /> 1. ato ou efeito de conhecer.<br /> <br /> 2. ato de perceber ou compreender por meio da razão e/ou da experiência.<br /> <br /> '''''Significado de conhecimento, conforme o dicionário Aurélio:'''''<br /> <br /> Substantivo masculino. Entendimento sobre algo; saber: conhecimento de leis. Ação de entender por meio da inteligência, da razão ou da experiência. [Por Extensão] Ação de dominar uma ciência, uma arte, um método, um procedimento etc.: ele tinha grande conhecimento de história.<br /> <br /> === Tipos de conhecimentos e como estes estão relacionados com a nossa carreira na área de TIC ===<br /> Para que tudo possa fazer sentido neste artigo precisamos envolver melhor o uso deste termo, deste substantivo denominado &quot;conhecimento&quot;, pois, afinal de contas, temos que identificar quais coisas, situações, contextos e propósitos deverão estar compreendidos nesta definição. E como isto pode ser vislumbrado nos diversos tipos de conhecimentos de acordo com os modelos empregados pelos indivíduos mais &quot;letrados&quot; nesta seara da pedagogia.<br /> <br /> Os padrões ou tipos de conhecimentos que você precisa perseguir para atuar na área de TIC, ou para especializar-se em uma determinada tecnologia, variam de acordo com o perfil que você preenche atualmente ou que pretende preencher em futuro próximo, como uma nova vaga, upgrade de nível na área, dentre outras situações. Para começarmos, tentemos classificar estes padrões de conhecimentos que entendo fazerem parte da área de TIC, e fazendo isto através de uma linguagem mais técnica inicialmente. Na tabela a seguir, ficarei nos tipos de conhecimentos e como estes podem estar associados com a nossa carreira de TIC. Para esta dissertação de casos, desprezarei a necessidade de incluir conhecimento teológico, mítico, sensorial, artístico e outros.<br /> {| class=&quot;wikitable&quot;<br /> |+Tipos de conhecimentos, suas características e situações gerais, e como estes estão relacionados com a nossa carreira na área de TIC<br /> !<br /> !Empírico<br /> !Científico<br /> !Filosófico<br /> !Tácito<br /> |-<br /> |'''Definição'''<br /> |É o tipo de conhecimento que adquirimos no dia-a-dia, muitas vezes com base na tentativa e erro, obtido principalmente por observação, experiência em lidar com os resultados e senso comum; conhecimento obtido através da vivência com equipes e times de trabalho. É chamado também de conhecimento popular, vulgar, ou por herança.<br /> |Esse tipo de conhecimento engloba análises de informações e fatos que foram cientificamente comprovados por meios de métodos, observações associadas à experimentações, e servindo para atestar a veracidade ou falsidade de determinada teoria ou conceito.<br /> |É o conhecimento que surge das reflexões que fazemos sobre as questões imateriais e subjetivas, baseado na reflexão e construção de conceitos e ideias, a partir do uso do raciocínio em busca do saber, e tendo como principal preocupação questionar e encontrar respostas racionais para determinadas questões, mas não necessariamente comprovar algo.<br /> |Similar ao conhecimento empírico, o conhecimento tácito se baseia nas experiências vivenciadas individualmente por cada pessoa ao longo da vida, sendo, neste caso, um conhecimento particular do indivíduo.<br /> |-<br /> |'''Valor'''<br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais. Acredita-se que o conhecimento empírico ajuda a percorrer um caminho mais curto, através do qual relacionamos tudo o que observamos com nossas experiências anteriores.<br /> |O valor deste conhecimento é factual, uma vez que lida efetivamente com fatos e ocorrências.<br /> |Valorativo, pois este tipo de conhecimento lida com hipóteses que não podem ser observadas. <br /> |É valorativo, pois este tipo de conhecimento apoia-se nas experiências pessoais, mais ainda do que os conhecimentos obtidos de forma empírica.<br /> |-<br /> |'''Verificação'''<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |É verificável, pois é alimentado por fatos e resultados.<br /> |Não é verificável, pois se trata de teorias que não podem ser testadas. Ou seja, seu ponto de partida consiste em hipóteses, as quais não poderão ser submetidas à observação<br /> |É verificável, pois se trata de situações ligadas ao dia-a-dia.<br /> |-<br /> |'''Exatidão'''<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, a partir de novas comprovações e experimentações científicas, e aproximadamente exato.<br /> |Infalível, pois suas hipóteses e definições não são submetidas ao decisivo teste da observação ou experimentação. e exato.<br /> |Falível, pois não é definitivo, já que determinada idéia ou teoria pode ser derrubada e substituída por outra, e inexato.<br /> |-<br /> |'''Sistema'''<br /> |É assistemático, pois é organizado com base nas experiências do indivíduo exercitadas sob senso comum.<br /> |É sistemático, pois todo o conhecimento é ordenado logicamente.<br /> |É sistemático, pois este conhecimento busca uma coerência com a realidade estudada.<br /> |É assistemático, pois se baseia nas experiências vivenciadas individualmente ao longo da vida.<br /> |-<br /> |'''Exemplos gerais'''<br /> |<br /> * Leite com manga faz mal.<br /> * Chá de boldo cura problemas no fígado<br /> * Beber café para ficar acordado.<br /> * Um agricultor que, mesmo sem nenhum estudo, sabe exatamente quando plantar e colher cada vegetal.<br /> * Bombril nas antenas dos televisores antigos para melhorar a recepção do sinal<br /> |<br /> * Lei da Gravidade<br /> * Biogênese<br /> * Teoria da Relatividade Geral<br /> * Teorema de Pitágoras<br /> * Sequenciamento de DNA <br /> |<br /> * &quot;O amor é a expressão da carência&quot; (Platão)<br /> * &quot;Penso, logo existo&quot; (Descartes)<br /> * “Todos vêem o que você parece ser, mas poucos sabem o que você realmente é” (Maquiavel)<br /> * “Ao falar você apenas repete o que já sabe, mas ao ouvir, talvez possa aprender alguma coisa.” (Dalai Lama)<br /> * “Pouco conhecimento faz com que as pessoas se sintam orgulhosas. Muito conhecimento, que se sintam humildes.” (Leonardo da Vinci)<br /> |<br /> * Andar de bicicleta<br /> * Tocar instrumento musical (sem relação com o conhecimento artístico)<br /> Em ambos os casos, tratam-se de algo que é aprendido apenas a partir da experiência e tentativa, sendo desnecessário o uso de instruções escritas ou orais para aprender.<br /> |-<br /> |'''Exemplos relacionados à área de TIC'''<br /> |<br /> |<br /> * Teorema de Shannon–Hartley para explicar conceitos de capacidades de circuitos digitais<br /> * Determinação de rotas de menor custo com o algoritmo Dijkstra<br /> * O OSPF como protocolo de roteamento link-state mais eficiente que alternativas por protocolos distance-vector<br /> * Estudo de viabilidade de cobertura RF para projeto WiFi no padrão 802.11ax<br /> * Abordagem de projeto de redes hierárquicas, modulares e estruturadas<br /> * Eficiência do plano de endereçamento IP, subredes e agregação de rotas<br /> |<br /> |<br /> |}</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Solucoes_para_o_gerenciamento_efetivo_do_bgp_em_um_sistema_autonomo&diff=2462 2020-05-25T16:20:39Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo ===<br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Todos os engenheiros de redes sênior que atuam em ISPs, ou em qualquer empresa séria que possua um Sistema Autônomo, compreendem a importância em estudar corretamente a farta quantidade de informações referentes às sessões e respectivas tabelas BGP, e não apenas na perspectiva da tabela BGP de seus próprios e respectivos ASNs, e sim estendendo estes estudos e tratamentos de dados na perspectiva de vários pontos de monitoramento, os quais incluem coletores, ''route views'', ''looking glasses'', e afins, espalhados pela Internet. Ou seja, como você (ou, neste caso, o seu ASN) vê o mundo ao seu redor, e como as várias partes do mundo (ASNs em suas respectivas regiões) vêem o seu ASN.<br /> <br /> Isto para sintetizar primariamente as iniciativas de prevenção dos dois principais tipos de incidentes envolvendo o roteamento de Internet, a saber: ''route leaks'' e ''prefix hijack''. Só que as necessidades de um ASN no que tange ao monitoramento de seu BGP vão bem além do que somente (embora gravíssimos) incidentes com ''route leaks'' e ''prefix hijacks'', para os quais, inclusive, já existem BCOPs específicas para prevenção e mitigação, como é o caso do &lt;nowiki&gt;RFC 7454&lt;/nowiki&gt; / BCP 194, BCP 38, BCP 185, e MANRS. Há muito mais coisas a serem observadas e tratadas com relação ao BGP do que apenas as questões de segurança.<br /> <br /> Ou seja, em adição às questões de segurança, o Sistema Autônomo/ASN precisa monitorar constantemente, dentre dezenas de objetos e métricas gerenciáveis, e seus respectivos KPIs, e de uma magnitude grande de componentes, o '''''&lt;u&gt;seu&lt;/u&gt; BGP''''' como um todo. Isto para que respostas possam ser fornecidas para sanear diversos desafios que vão além da segurança do roteamento daquele ASN (e estendendo-se para seu cone de clientes), tais como a escalabilidade, engenharia de tráfego com ênfase na redução inteligente de custos e com potencial aumento de qualidade de serviço (ex: fornecer conteúdo com menor latência ao mesmo tempo em que reduzindo custos com esta iniciativa); planejamento de capacidades, planejamento das métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, os padrões de convergência da rede, plano diretor de investimentos, desenvolvimento e manutenção da cesta de produtos e serviços com foco na capacidade e uso estatístico de recursos da rede, toda a parte financeira também, etc.<br /> <br /> Falando especificamente do BGP, os modelos &lt;u&gt;tradicionais&lt;/u&gt; de monitoramento possuem restrições: ''routeviews'' (com algumas exceções) e ''looking glasses'' não mantém históricos de informações sobre rotas (seja pelo prefixo direto ou pela expressão regular do atributo AS_PATH), consequentemente não se sabe o que aconteceu, quando e por quem. Além disto, uma sessão BGP somente anuncia as suas melhores rotas (''best path''), e esta informação pode ser obtida de um roteador por CLI ou outro procedimento, como o NETCONF, porém, novamente, sem dados históricos. O que algumas empresas fazem para compensar estas restrições dos modelos tradicionais com ferramentas vigentes é recorrer a soluções e sistemas que consigam manter estas informações numa base de dados que seja flexível, escalável e gerenciável, e que mantenha um histórico de mudanças sobre estes registros. Ou seja, construir e customizar sistemas específicos, ou adquirir um sistema comercial para este propósito. E que, preferencialmente, seja de fácil integração com outros sistemas (incluindo Sistemas de Suporte à Operação (OSS)).<br /> <br /> O que estou propondo aqui é ampliar os conceitos de ferramentas para o monitoramento efetivo do BGP: além de manter seus ''looking glasses'' e consultar ''route views'', onde aplicáveis, os ASN poderem manter as suas próprias bases de dados com históricos acerca de tudo o que ocorre com o BGP na perspectiva daquele ASN, de seu cone de clientes, além da sua relação com seus upstreams de trânsito IP, sessões de peering e afins. Ou seja, não apenas o &quot;snapshot&quot; do que está acontecendo na hora, mas obter informações sobre prefixos e ASNs através de uma linha temporal e para atender diversos casos e aplicações técnicas e de negócios. É o que chamamos de &quot;'''''telemetria orientada a modelos'''''&quot;, que, nos projetos mais sofisticados e completos, combina ferramentas de &quot;telemetria baseadas em eventos&quot; (obtenção de dados por CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, BMP, etc.), e &quot;telemetria de streaming periódica&quot;, com monitoramento de diversos objetos relacionados à capacidade e dados estatísticos de consumo (latência, ''throughput'', processamento) por meios de diversas ferramentas e procedimentos. Interessante, não?<br /> <br /> Em suma, este artigo está centrado na dissertação de propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!<br /> <br /> ==== Observação importante: ====<br /> Se você estiver aguardando uma solução &quot;pronta&quot; ou com uma expectativa de que eu vá fornecer aqui uma &quot;receita de bolo&quot;, lamento muito, mas não é esta a intenção do artigo! Fornecerei aqui uma visão muito mais ampla deste contexto, e tentarei desmembrar este tópico empregando alguns conceitos de pesquisa aplicada e de desenvolvimento experimental. Entenda isto como um pontapé inicial para que você consiga adquirir os conhecimentos necessários para desenvolver seus próprios conceitos de adoção tecnológica, processual e instrumental, objetivando o gerenciamento e monitoramento do BGP de seu AS, e culminando na tomada de decisão de sua parte sobre uma ou mais das seguintes possibilidades:<br /> # Investimentos em soluções comerciais existentes, com potencial de customizações e integração com outros sistemas para o atendimento de necessidades específicas do seu negócio.<br /> # Desenvolvimento de sistemas com fábrica de software própria, atendendo a todos os modelos de gerenciamento desejados.<br /> # Adoção de ferramentas específicas para o atendimento de necessidades igualmente específicas, tais como soluções de código aberto ou até mesmo de ordem comercial.<br /> <br /> === Um &quot;abre-alas&quot; sobre a importância e missão dos sistemas de gerenciamento no geral ===<br /> Antes de começarmos, gostaria de comentar uma característica do meu trabalho e que afeta o meu julgamento por completo. Aqueles que me conhecem de longa data sabem que sou um tanto insistente em algumas das minhas análises, visões, conclusões e objeções. Para estas pessoas que me conhecem, quantas vezes já não ouviram o Leonardo Furtado citar a seguinte frase?&lt;blockquote&gt;''&quot;Muitos profissionais de ISP (incluindo alguns perfis de gestores) pecam na hora de investir e de tomar decisões importantes para seus negócios: adquirem soluções tecnológicas focando apenas ou principalmente nas necessidades de curto prazo, muitas vezes adotando soluções minimalistas, e centradas no fator de menor custo&quot;''&lt;/blockquote&gt;A relação desta frase com o artigo em questão é óbvia, e você entenderá melhor logo a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem que haja um propósito bem definido para as áreas do negócio que realmente importam. Muitas vezes a necessidade é muito óbvia ou específica, tais como &quot;monitorar o consumo de banda referente a uma interface conectada para um upstream de trânsito IP&quot;, o que é plenamente justificável, sem dúvidas, claro! No entanto, o maior problema não reside no objeto gerenciado em questão (monitoramento de banda, monitoramento de problemas de uma interface, processamento, etc.), e sim na ausência de analíticos associados aos objetos gerenciados pelas ferramentas em questão, as quais foram adquiridas pela organização (e seja lá quais tenham sido os critérios), e que foram implantadas pelo time de engenharia ou de operações. Em outras palavras: o software está &quot;lá&quot;, implantado, e sendo (sub)utilizado pelos operadores. Mas.. quais são os reais objetivos? Quais são os indicadores desejados? Quais são os ''thresholds''? Quais são as métricas gerenciáveis daquele componente, de cada componente? Como determinados ''thresholds'' e eventos associados àquele objeto impactam no meu negócio? Quais ações e tomadas de decisões executaremos para prevenir, mitigar e responder ao eventos fornecidos pelo gerenciamento acerca daquele objeto gerenciado? Como este objeto gerenciado participa do meu negócio e nas diversas áreas, centros de custo, e contextos, incluindo comercial, reputação, financeiro (capex, opex, fluxo de caixa, etc.), engenharia (capacidade, disponibilidade, resiliência, consumo de recursos, tráfego, etc.), operações, fornecedores, etc.? A lista é grande.<br /> <br /> Com 25 anos de profissão, o que mais vi em toda a minha carreira e em muitas empresas que visitei foram soluções de gerenciamento inteiras praticamente &quot;encalhadas&quot;, subutilizadas! Sistemas complexos e por muitas vezes interessantes que, de diversas funções e capacidades disponíveis, são extraídos apenas recursos pontuais e, mesmo assim, sem que analíticos e dados importantes pudessem ser coletados, tratados e consumidos pelas áreas relevantes do negócio para que estas pudessem aproveitar estas informações para algo realmente útil, seja algo visando aprimorar a parte técnica/tecnológica ou a parte do negócio propriamente dito.<br /> <br /> Outra forma de sintetizar isto: ''&lt;u&gt;em muitas empresas não há efetivamente um projeto prevendo a construção (ou adoção/contratação) de sistemas de gerenciamento&lt;/u&gt;''. O gerenciamento efetivo ou adequado é frequentemente a parte mais negligenciada da infraestrutura.<br /> <br /> Dissertar amplamente sobre isto está fora do escopo deste artigo, mas a mensagem que gostaria de deixar aqui é bem simples: tratando-se de sistemas de gerenciamento, e não importando para qual finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), procure conduzir um projeto técnico consistente e específico para este(s) sistema(s), e que vá identificar e documentar os seguintes:<br /> * Em alinhamento com o projeto de infraestrutura vigente, incluindo todo o parque tecnológico presente (hardware e software), quais são as necessidades da área técnica da empresa, assim como de possíveis outras áreas interessadas?<br /> * Quais problemas estamos sofrendo no momento e/ou que gostaríamos de evitar?<br /> * Como cada um destes problemas, incidentes ou circunstâncias impacta nos negócios da empresa? É possível quantificar os prejuízos, quaisquer que sejam (reputação, multas, reparação, cancelamento de contratos, perda de receitas, aumento de custos imprevistos, etc.)? E quais áreas internas do negócio são impactadas? É viável fazer esta associação?<br /> * Quais deverão ser os objetos gerenciados?<br /> * Quais são as facilidades de gerenciamento suportadas pelo meu parque tecnológico (HW e SW)? E quais são as capacidades demandadas sobre cada um destes recursos?<br /> * Das tecnologias ou recursos disponíveis e suportados pela infraestrutura, quais são as melhores e mais aderentes opções para o atendimento de cada objeto gerenciado identificado? (prós e contras, matriz funcional de qualidade, etc.)<br /> * Quais deverão ser os indicadores e métricas para estes objetos gerenciados quando utilizando-se dos recursos ou facilidades de gerenciamento identificados como mais aderentes para os meus propósitos?<br /> * Como as áreas internas do negócio, onde aplicáveis, consumirão estes analíticos, indicadores e métricas?<br /> * Quais processos deverão ser estabelecidos para ações de prevenção, mitigação e reação quanto aos ''thresholds'' dos objetos gerenciados?<br /> * Dentre muitas questões.<br /> Somente após responder estas perguntas e planejar toda a iniciação do projeto de adoção de solução de gerenciamento é que você conseguirá encontrar a solução ideal, a(s) &quot;ferramenta(s)&quot;, e fazendo isto com critérios consistentes nos requisitos de facilidades, recursos, integração, custos, etc. Entendo que esta deva ser a aderência a ser pensada e projetada, assim como entendo que você precisará instaurar os processos primeiro para depois chegar a estas conclusões. Dica: para o tema &quot;processos&quot;, confira o artigo [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]! <br /> <br /> A implantação e operação de sistemas de gerenciamento, quaisquer que sejam as finalidades, deve passar primeiro por um plano de projeto que vá identificar todas as questões envolvendo necessidades, desafios, métricas desejadas, capacidades e qualidades demandadas, os objetos a serem gerenciados, as facilidades e recursos necessários, como os dados serão coletados, processados e armazenados, e como a organização como um todo deverá consumir e tirar proveito destes dados para aprimorar seus indicadores. <br /> [[Arquivo:Bpf-gerbgp-requisitos.png|centro|miniaturadaimagem|900x900px|&quot;Carroça não anda na frente de boi&quot;: exercite o planejamento antes de sair implantando ferramentas, e usufrua de melhores resultados!]]<br /> <br /> === Por que um ASN precisa investir no gerenciamento de seu ambiente BGP? ===<br /> Ou '''''quais problemas poderão ser resolvidos com o gerenciamento efetivo do BGP em seu ASN'''''?<br /> <br /> &lt;u&gt;A sequência deste artigo estará centrada quase que integralmente no &quot;BGP&quot;&lt;/u&gt; e possivelmente citarei outros elementos que participam diretamente do funcionamento deste. Ou seja, não pretendo realmente dissertar sobre necessidades, objetivos e requisitos gerais envolvendo disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isto não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?<br /> <br /> Suponhamos que as áreas de engenharia e operações de um ISP cheguem a um consenso de que é necessário ter ampla visibilidade e acesso à informações relevantes especificamente relacionadas ao BGP para que sejam discutidas formas de antecipar e mitigar riscos, e responder aos diversos tipos de incidentes relacionados às questões de segurança, disponibilidade, performance, ou seja, o SLA em geral, assim como o planejamento de capacidades e a engenharia financeira do negócio. Se tivéssemos que exercitar este consenso entre estas duas áreas, quais teriam sido alguns dos diversos critérios factíveis? Para este exercício hipotético, proponho que estes requisitos sejam devidamente categorizados da seguinte forma para melhor compreensão e dissertação de casos:<br /> * '''Segurança do roteamento BGP'''<br /> * '''Segurança do plano de controle da rede'''<br /> * '''Segurança contra ataques de negação de serviços'''<br /> * '''instabilidades do BGP'''<br /> * '''Engenharia de tráfego'''<br /> * '''Planejamento de capacidades'''<br /> * '''Reputação e conformidade'''<br /> O seu trabalho, na condição de engenheiro de rede ou arquiteto de soluções, deverá ser a busca por respostas para iniciar este planejamento!<br /> [[Arquivo:Bpf-gerbgp-planejamento.png|centro|miniaturadaimagem|900x900px|Brainstorming para o planejamento de uma solução de gerenciamento específica para o BGP]]<br /> Dissertemos um pouco mais sobre estes caso hipotético através da exposição de conceitos envolvendo '''''Necessidades''''', '''''Requisitos''''', '''''Problemas ou desafios a serem resolvidos''''' pelas organizações que operam um Sistema Autônomo, sendo provedores de acesso à Internet (ISP) ou não:<br /> {| class=&quot;wikitable&quot;<br /> |+<br /> Matriz de Necessidades, Requisitos e Desafios a serem Superados para a Demanda &quot;BGP&quot; do ISP<br /> !Categoria<br /> !Necessidade<br /> !Requisito<br /> !Problemas ou desafios a serem resolvidos<br /> !Partes interessadas<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento da segurança do roteamento BGP'''<br /> |Deteção e mitigação de prefixos Bogons<br /> |Identificação e mitigação de prefixos Bogons, Maritans e não alocados<br /> |<br /> * Evitar o recebimento e propagação de rotas referentes a prefixos Bogons, Martians e Unallocated<br /> * Aumentar a reputação do Sistema Autônomo, como parte de boas práticas para a prevenção de incidentes de segurança associados a anúncios bogons.<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de vazamento de rotas e sequestro de prefixos do ASN<br /> |Identificação e mitigação de route leaks<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Assegurar que o ASN não crie ou gere route leaks, assim como assegurar que route leaks não sejam aceitos a partir de sessões de clientes, peering e trânsito<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Encurtar o tempo de deteção de incidentes envolvendo route leaks<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de route leaks<br /> |NOC, Engenharia<br /> |-<br /> |Identificação e mitigação de sequestro de prefixos (prefix hijacks)<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Evitar que o ASN não sequestre prefixos, assim como recusar o recebimento de quaisquer anúncios com ROA (RPKI) e/ou IRR inválidos<br /> * Encurtar o tempo e detecção de incidentes envolvendo o sequestro de prefixos<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de sequestro de prefixos<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de abusos contra recursos do BGP<br /> |Controle de recebimento de anúncios de ASNs vizinhos<br /> |<br /> * Evitar abusos e possíveis impactos relacionados à capacidades e escassez de recursos<br /> * Evitar que ASNs de clientes anunciem de forma acidental ou maliciosa uma quantidade de prefixos superior à estimada ou autorizada<br /> * Evitar abusos com a desagregação através de anúncios excessivamente específicos recebidos de clientes, peering e trânsito<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> |Controle de abuso de AS-Path Prepending<br /> |<br /> * Evitar que o ASN do ISP, assim como ASNs vizinhos e o restante da Internet, sofram possíveis impactos e instabilidades quanto à prefixos com excesso de AS-Path Prepending atrelado aos anúncios<br /> * Evitar abusos quanto ao recebimento de rotas BGP que contenham AS-Path Prepending excessivos (uma forma de ''Self-Inflicted Vulnerability'')<br /> * Encurtar o tempo de detecção de incidentes desta natureza.<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da segurança do plano de controle da rede'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de incidentes de segurança contra o próprio BGP<br /> |Controle de vulnerabilidades sobre as mensagens do BGP<br /> |<br /> * Evitar indisponibilidades e outros tipos de incidentes que possam ser provocados com a exploração das mensagens do BGP (conforme (3.1. Vulnerabilities in BGP Messages do &lt;nowiki&gt;RFC 4272&lt;/nowiki&gt;)<br /> * Evitar a manipulação e injeção maliciosa de atributos sobre os anúncios por mensagens ''Update'' do BGP<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de exploração destas vulnerabilidades<br /> |SOC, NOC. Engenharia<br /> |-<br /> |Controle de incidentes de segurança lançados diretamente contra as sessões BGP<br /> |<br /> * Evitar que as sessões BGP sejam atingidas diretamente por técnicas maliciosas que visam desde o downtime/indisponibilidade, sequestro de sessões, injeção de informações errôneas<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de ataques lançados contra os processos BGP<br /> |SOC, NOC, Engenharia<br /> |-<br /> |'''Gerenciamento da segurança contra negação de serviços'''<br /> |Detecção e mitigação contra ataques DDoS<br /> |Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS<br /> |<br /> * Evitar ou atenuar efeitos adversos de indisponibilidades, instabilidades, impactos severos no SLA de clientes, prejuízos financeiros de grandes proporções, e danos na reputação da empresa<br /> * Evitar a injeção de informações maliciosas na tabela BGP que permitam livre comunicação entre hosts infectados em suas botnets<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e mitigação de DDoS<br /> |SOC, NOC, Engenharia<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento de instabilidades do BGP'''<br /> | rowspan=&quot;5&quot; |Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA<br /> |Detecção de oscilações de sessões BGP<br /> |<br /> * Evitar que ocorram instabilidades na prestação de serviços de acesso à Internet por conta de oscilações das sessões BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e problemas com as sessões BGP<br /> |NOC<br /> |-<br /> |Detecção de oscilações de rotas (route flaps)<br /> |<br /> * Evitar que ocorram indisponibilidades na comunicação com determinados serviços/destinos de Internet por conta de oscilações e intermitências quanto à convergência da tabela BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e oscilações de rotas BGP<br /> |NOC<br /> |-<br /> |Detecção de rotas eventualmente suprimidas por Dampening<br /> |<br /> * Evitar discrepâncias nas matrizes de tráfego e, de certa forma, atenuar a assimetria do roteamento IP, ''blackhole'' ou ''routing loops'' por conta da eventual supressão de rotas (dampening) executada no ASN local ou em vizinhos<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de supressão de rotas BGP e como estes eventos afetam o comportamento da rede e a disponibilidade de serviços<br /> |NOC<br /> |-<br /> |Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces<br /> |<br /> * Evitar que determinados recursos tais como capacidade de enlaces, arquiteturas de roteadores (CPU, memória, FIB, etc.) fiquem subutilizados enquanto outros elementos fiquem sobrecarregados<br /> * Evitar gargalos nas operações e transações de rede, os quais podem provocar impactos no SLA<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção de gargalos e esgotamento de recursos<br /> |NOC, Engenharia<br /> |-<br /> |Planejamento e antecipação de cenários &quot;what if&quot;<br /> |<br /> * Evitar que manobras de configurações, incluindo modificações nas políticas de roteamento e ações de engenharia de tráfego provoquem distúrbios não antecipados<br /> * Antecipar impactos na convergência e disponibilidade da rede através de uma análise preditiva envolvendo cenários de falhas<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;4&quot; |'''Gerenciamento da engenharia de tráfego'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de impactos sobre os recursos de infraestrutura decorrentes de eventos pontuais na Internet<br /> |Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento<br /> |<br /> * Superar as limitações operacionais da empresa em função da escassez de informações e a falta de visibilidade sobre os fluxos de tráfego<br /> * Aprimorar as ações de dimensionamento de recursos de infraestrutura, tais como plataformas de switches e roteadores, além de enlaces de comunicação de dados<br /> * Aprimorar os resultados das ações de engenharia tráfego para fins de acomodar melhor as conversações da rede sobre os recursos disponíveis<br /> * Atenuar ou eliminar os desafios que provocam impactos sobre o SLA de assinantes<br /> * Fornecer analíticos, dados históricos e baselines relacionados às matrizes de tráfego, com histórico de consumo por ASN, peer, prefixo, protocolo de transporte, tipo de aplicação, marcações, atributos, etc.<br /> |Engenharia<br /> |-<br /> |Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas<br /> |<br /> * Reduzir os indicadores de MTTR e MDT associados aos eventos de falhas relacionadas ao BGP<br /> * Reduzir os indicadores de reclamações por conta da violação de SLAs envolvendo indisponibilidades, latência, jitter, perda de pacotes, etc.<br /> * Reduzir os impactos provocados nas áreas internas do negócio que são destinadas ao interfaceamento com clientes, tais como comercial, atendimento a clientes, NOC, jurídico, etc.<br /> * Fornecer analíticos, dados históricos e baselines referentes aos impactos decorrentes de falhas para alimentar as tomadas de decisão e para nortear os investimentos e processos de mitigação<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Aprimoramento de SLA<br /> |Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP<br /> |<br /> * Reduzir impactos não antecipados sobre ações de engenharia de rede e de tráfego executadas pela área de engenharia ou de operações da empresa<br /> * Aprimorar as tomadas de decisão acerca das políticas de roteamento para o atendimento dos modelos de interconexão privado e público<br /> * Aprimorar as tomadas de decisão para as políticas de roteamento de acordo com os modelos de interesse de tráfego (''hot potato'', ''cold potato'', e outras diretrizes) sobre os regimes de interconexão <br /> * Fomentar ações racionais de engenharia de tráfego para equilibrar as métricas de SLA (latência, jitter, disponibilidade) sobre os custos (opex) de cada enlace de transporte e de de cada acordo de troca de tráfego<br /> |Engenharia<br /> |-<br /> |Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como MPLS TE e SR-TE<br /> |<br /> * Assegurar aderência quanto ao mapeamento do tráfego sobre os recursos locais do AS, prevendo simultaneamente as métricas de desempenho e a relação de custos de infraestrutura para a sustentação de SLAs<br /> * Promover a redução racional de custos através da associação de classes de tráfego ou de matrizes de conversação sobre os enlaces e sessões associadas às métricas de SLA de cada caso<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;3&quot; |'''Gerenciamento da planejamento de capacidades'''<br /> | rowspan=&quot;3&quot; |Planejamento de capacidades com foco na redução racional de custos operacionais<br /> |Bilhetagem e tarifação de tráfego<br /> |<br /> * Determinação da matriz de tráfego em combinação com iniciativas de bilhetagem e tarifação para determinar rateio de custos de infraestrutura nas áreas internas do negócio<br /> * Fornecer métricas de utilização dos fluxos de tráfego de interesse sobre os recursos de transporte para identificar áreas de otimização de custos<br /> * Viabilizar a compreensão da participação de cada centro de custo / área interna do negócio quanto aos padrões de consumo e contribuições orçamentárias<br /> * Viabilizar e fomentar a derivação da política de preços de produtos e serviços destinados a clientes em função das matrizes de tráfego, interesses de tráfego e modelos de interconexão<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Dimensionamento de recursos de transporte e acordos de troca de tráfego<br /> |<br /> * Planejamento de capacidades de conexões do ISP com os acordos de troca de tráfego nos regimes de peering e trânsito IP, incluindo 95th percentil<br /> |Engenharia<br /> |-<br /> |<br /> * Dimensionamento de especificações, requisitos, recursos e capacidades das arquiteturas e demais componentes de infraestrutura a serem utilizados para a sustentação dos modelos de interconexão para os perfis de tráfego<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da reputação e conformidade'''<br /> |Conquistar níveis de excelência em conformidade<br /> |Deteção e mitigação de incidentes e situações não aderentes aos frameworks e boas práticas destinadas aos Sistemas Autônomos<br /> |<br /> * Fornecer analíticos e dados históricos que classifiquem as ocorrências de incidentes provocados por eventos previstos e imprevistos pelas políticas internas da empresa<br /> * Fornecer métricas auditáveis quanto os incidentes de segurança associados ao BGP<br /> |NOC, SOC, Engenharia<br /> |-<br /> |Conquistar níveis de excelência na reputação do Sistema Autônomo<br /> |Fornecimento de ferramentas para o compartilhamento de transparência e iniciativas de suporte com outros (demais) Sistemas Autônomos<br /> |<br /> * Manutenção de sistemas e bases de informação que divulguem, dentre outros, a política de roteamento da empresa, plano de communities, &quot;normas da casa&quot;, requisitos de segurança, requisitos de interconexão, modalidades de SLA, etc.<br /> * Manutenção de sistemas e bases de informação que forneçam os pontos de contato e suporte para as demandas associadas ao BGP e contextos periféricos do AS, tais como &quot;Abuse&quot;, &quot;Peering&quot;, &quot;NOC&quot;, e outros<br /> * Disponibilização de ferramentas de autosserviço para a redução do tempo de diagnóstico e identificação de problemas por parte de NOCs de outros Sistemas Autônomos, tais como Looking Glass e outros.<br /> * Promover aderência quanto às boas práticas citadas pelos objetivos &quot;''Coordination''&quot; e &quot;''Global Validation''&quot; do ''Mutually Agreed Norms for Routing Security'' (MANRS) <br /> * Fornecer analíticos acerca da utilização das ferramentas de autosserviço para identificar necessidades de mercado, técnicas, perfil dos visitantes, áreas de interesse e geração de novas oportunidades <br /> |NOC<br /> |}<br /> <br /> === Exemplos de soluções conhecidas para o atendimento das diversas necessidades e requisitos associados ao gerenciamento do Sistema Autonomo ===<br /> No que diz respeito aos conjuntos de necessidades e respectivos requisitos fornecidos na tabela anterior, eu particularmente compreendo que tratam-se de situações absolutamente reais. Ao projetar a tabela acima, em nenhum momento pensei especificamente ou diretamente nas possíveis soluções e ferramentas que pudessem ser empregadas para cada caso, ou seja, toda a linha de raciocínio foi de fato estabelecida sobre '''''necessidades + requisitos + problemas + desafios''''' que entendo que a maioria dos operadores de redes tenham interessem em lidar em suas operações cotidianas.<br /> <br /> Todavia, chegaria o momento em que precisaríamos traduzir isto para um plano definitivamente concreto, certo? Sim, precisaríamos identificar ferramentas que conseguissem fornecer resultados para cada uma das situações descritas na tabela anterior. E é justamente isto que tentarei fazer agora: num primeiro momento, &quot;espalhar na mesa&quot; o que temos no mercado hoje; as soluções existentes que podem ser usadas para executar estes casos e cumprir com estas necessidades. <br /> <br /> Note que as ferramentas associadas a cada tipo de requisito não fornecem apenas as funcionalidades para aquele requisito em questão: tomei a liberdade de fazer desta forma apenas para deixar claro que a ferramenta foi &quot;pensada&quot; após o par &quot;necessidade + requisito&quot; ter sido identificado e confirmado para o meu conceito de projeto. <br /> <br /> Está fora do escopo desta parte do artigo qualquer esforço de validação e dissertação de aderência qualitativa (&quot;''o quão bem a ferramenta X executa e atende as necessidades, requisitos, problemas, desafios...''&quot;), assim como promover qualquer comparativo entre as opções mencionadas (&quot;''qual é a melhor ferramenta para a necessidade X?''&quot;).<br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança do roteamento BGP<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação e mitigação de prefixos Bogons, Martians e não alocados'''<br /> | rowspan=&quot;3&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://radar.qrator.net/ RADAR by QRATOR]<br /> * [https://team-cymru.com/community-services/bogon-reference/ Team Cymru fullbogons]<br /> |-<br /> |'''Identificação e mitigação de route leaks'''<br /> |-<br /> |'''Identificação de sequestro de prefixos'''<br /> |}<br /> O &lt;nowiki&gt;RFC 7908&lt;/nowiki&gt; (''Problem Definition and Classification of BGP Route Leaks'') descreve com bastante propriedade a caracterização e tipificação dos incidentes denominados route leaks, enquanto o draft-ietf-grow-route-leak-detection-mitigation-02 (''Methods for Detection and Mitigation of BGP Route Leaks'') propõe mecanismos de detecção e mitigação destes incidentes. Está fora do escopo deste artigo a dissertação sobre route leaks.<br /> <br /> Em adição, diversos artefatos contendo recomendações para a mitigação de prefix hijack foram produzidos, dentre eles o BCP 185 (''Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)''), &lt;nowiki&gt;RFC 7682&lt;/nowiki&gt; (''Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration''), &lt;nowiki&gt;RFC 2650&lt;/nowiki&gt; (''Using RPSL in Practice''), e o &quot;''Action 1: Prevent propagation of incorrect routing information''&quot; do Mutually Agreed Norms for Routing Security (MANRS). A dissertação sobre prefix hijack está fora do escopo deste artigo.<br /> <br /> As ferramentas comentadas na tabela acima podem ser usadas para fornecer dados e até mesmo, em alguns casos, prover algum grau de automação na resposta de incidentes envolvendo route leaks, prefix hijacks e outras situações. Outra possibilidade bastante interessante é projetar integrações entre estas ferramentas/serviços por meios as APIs disponibilizadas. Nos exemplos indicados acima, a [https://developer.thousandeyes.com/v6/ ThousandEyes fornece APIs] que podem ser aproveitadas para integrações com outros sistemas, assim como podem ser consideradas as [https://portal.bgpmon.net/bgpmonapi.php APIs do BGPmon da Cisco], [https://api.qrator.net/ APIs da QRATOR], etc. <br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança e instabilidades do roteamento BGP <br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de recebimento de anúncios de ASNs vizinhos'''<br /> | rowspan=&quot;5&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://bgpstream.caida.org/ BGPStream]<br /> * [https://share.zabbix.com/search?searchword=BGP&amp;search_cat=1 Zabbix com plugins compatíveis com estas necessidades]<br /> |-<br /> |'''Controle de abuso de AS-Path Prepending'''<br /> |-<br /> |'''Detecção de oscilações de sessões BGP'''<br /> |-<br /> |'''Detecção de oscilações de rotas (route flaps)'''<br /> |-<br /> |'''Detecção de rotas eventualmente suprimidas por Dampening'''<br /> |}<br /> Entendo que as ferramentas indicadas na tabela acima forneçam as funcionalidades devidas para que o administrador do Sistema Autônomo possua meios de identificar e reagir contra uma diversidade de situações envolvendo sessões e anúncios do protocolo BGP. <br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento engenharia de tráfego e planejamento de capacidades<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento'''<br /> | rowspan=&quot;7&quot; |<br /> * [https://www.telcomanager.com/trafip-analise-de-trafego/ TRAFip]<br /> * [https://www.noction.com/intelligent-routing-platform-bgp-network-optimization Noction IRP]<br /> * [https://www.blueplanet.com/products/route-optimization.html Ciena BluePlanet ROA]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/crosswork-network-automation/datasheet-c78-740228.html Cisco Crosswork Network Insights]<br /> * [https://www.manageengine.com/products/netflow/ ManageEngine NetFlow Analyzer]<br /> * [https://developer.cisco.com/docs/wan-automation-engine/#!overview/cisco-wan-automation-engine Cisco WAE em combinação com XTC]<br /> |-<br /> |'''Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas'''<br /> |-<br /> |'''Bilhetagem e tarifação de tráfego'''<br /> |-<br /> |'''Dimensionamento de recursos de transporte e acordos de troca de tráfego'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como BGP-LS, MPLS TE e SR-TE'''<br /> |-<br /> |'''Planejamento e antecipação de cenários &quot;what if&quot;'''<br /> |}<br /> A compreensão dos fluxos de tráfego, tanto na rede do próprio AS quanto nas conexões com os AS vizinhos, é algo muito importante para que o provedor consiga tomar as decisões corretas em algumas esferas técnicas do projeto e da operação cotidiana. Afinal de contas, para que seja possível o dimensionamento correto de recursos que acomodarão seus assinantes e respectivos serviços, o provedor precisa ter as informações necessárias para concluir este planejamento de capacidades, a engenharia de tráfego, e as questões de engenharia de redes tais como a disponibilidade, atrelada aos padrões de redundância, resiliência e métricas de confiabilidade, e em alinhamento com o projeto técnico e o plano de negócios. As ferramentas mencionadas na tabela acima possuem funcionalidades que cumprem bem com estes requisitos.<br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento da segurança do plano de controle da rede e segurança contra negação de serviços<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de vulnerabilidades sobre as mensagens do BGP'''<br /> | rowspan=&quot;4&quot; |<br /> * Ferramentas e soluções de detecção e prevenção de intrusão<br /> * [https://www.andrisoft.com/software/wanguard Andrisoft Wanguard]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://br.netscout.com/arbor-ddos Arbor para Operadoras]<br /> * [https://wiki.brasilpeeringforum.org/w/UTRS_Registro_e_Configuracao Team Cymru UTRS]<br /> |-<br /> |'''Controle de incidentes de segurança lançados diretamente contra as sessões BGP'''<br /> |-<br /> |'''Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS'''<br /> |-<br /> |'''Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces'''<br /> |}<br /> Tão importante quanto disponibilidade, performance e visibilidade geral dos componentes associados ao funcionamento do BGP em um Sistema Autônomo, é o gerenciamento da segurança da infraestrutura como um todo, sendo que, neste caso, as questões mais diretamente ao roteamento do AS. Na questão de segurança &quot;geral&quot; do AS, muita coisa já foi discutida em outros artigos já publicados na Wiki do Brasil Peering Forum, tais como o [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] e [[Boas Praticas para Melhorar a Seguranca de seu Provedor|Boas Práticas para Melhorar a Segurança de seu Provedor]]. As soluções mencionadas na tabela acima são indicadas para a mitigação de incidentes de segurança e ataques DDoS lançados contra a rede do ISP e/ou de seu cone de clientes.<br /> <br /> === Modelos e ferramentas orientadas ao gerenciamento do BGP ===<br /> Saindo um pouco desse discurso de &quot;necessidades, requisitos, desafios, etc,&quot;, serão discutidas a seguir as possibilidades em termos de modelos e ferramentas de gerenciamento que podem ser consideradas e utilizadas para os nossos interesses com o BGP. Pois, afinal de contas, não adianta vislumbrar um mundo perfeito ao melhor estilo &quot;''imagine all the people...''&quot; se não há formas efetivas de executarmos aquilo que nós desejamos, certo? Isto significa que temos que por os pés no chão e analisarmos as possibilidades nada utópicas! Se dependesse de nossas mentes altamente criativas, conseguiríamos, num estalar de dedos, fazer tudo funcionar da maneira como as nossas brilhantes mentes sonham, e ter acesso a todo o tipo de informações e analíticos que, na prática, sequer sabemos se existem ou se podem ser recuperadas dos elementos de nossa rede. <br /> <br /> E, antes de discutirmos quais tipos de informações/dados podemos obter em nosso ambiente e determinarmos o que podemos fazer com estas informações, tentemos em um primeiro momento compreendermos os protocolos, serviços e procedimentos que podem ser utilizados para recuperarmos informações dos equipamentos e sistemas de nossa infraestrutura.<br /> <br /> ==== Modelo &quot;pull&quot; tradicional de recuperação de dados ====<br /> O modelo ''pull'' de recuperação de dados consiste no envolvimento de procedimentos onde estações de gerenciamento acessam os dispositivos para a obtenção de informações acerca de um ou mais objetos gerenciados. Os exemplos de procedimentos mais comuns são as consultas executadas com protocolos tais como ''Simple Network Management Protocol'' (SNMP), ''Remote Monitoring'' (RMON), ''Secure Shell'' (SSH) e ''Telnet''. <br /> <br /> Como o próprio termo sugere (''pull''), os sistemas de gerenciamento requisitam informações para os equipamentos da rede através de mecanismos de solicitação e resposta, como é o caso das mensagens ''GetRequest'', ''GetBulkRequest'' e ''GetBulkRequest'', do SNMP, sobre algum objeto gerenciado (''Object Identifier'' (OID)), devidamente especificado em uma biblioteca ''Management Information Base'' (MIB) apropriada, a qual deverá ser suportada por ambos o equipamento (ex: roteador) e o sistema da estação de gerenciamento em questão, sendo que as respostas para estas requisições são fornecidas por meios de mensagens ''Response'' deste protocolo.<br /> <br /> Outra possibilidade envolveria scripts devidamente organizados ou acomodados em estações de gerenciamento que executem conexões diretas com o interpretador de linha de comando (CLI) dos equipamentos da rede e execute operações com comandos específicos de interesse do administrador, tais como a obtenção de contadores de uma interface (&quot;''show interfaces''&quot;) para a checagem por eventuais problemas, ou a verificação de status das sessões BGP do roteador (&quot;''show bgp summary''&quot; e &quot;''show bgp neighbor''&quot;), a contabilização da quantidade de rotas anunciadas para determinado vizinho BGP (&quot;''show route advertising-protocol bgp x.x.x.x''&quot; no JUNOS, &quot;''show bgp neighbor x.x.x.x advertised-routes''&quot; no Cisco IOS XR), dentre muitas possibilidades. O &quot;output&quot; de uma operação envolvendo um destes comandos seria então mantido num arquivo temporário para que outros scripts e procedimentos possam ser executados para consumir estes dados e fornecer algum tipo de tratamento e interpretação posterior.<br /> <br /> ==== Modelo &quot;push&quot; tradicional de recuperação de dados ====<br /> O modelo ''push'' de recuperação de dados ocorre no sentido inverso ao modelo ''pull'': os equipamentos da rede encaminham as informações para as estações de gerenciamento, e isto pode ocorrer através de definições periódicas do serviço monitorado para o envio de informações ou baseado em eventos. Exemplos de procedimentos ''push'' incluem as mensagens ''Trap'' do protocolo SNMP onde as mensagens destes &quot;traps&quot; nestes casos acompanhariam duas variáveis primárias, sendo o ''sysUpTime'' e o ''snmpTrapOID'', juntamente com outras instruções para reportar alguma condição que tenha sido detectada sobre o monitoramento estabelecido de um OID, e havendo o reconhecimento por parte do coletor de eventos com o envolvimento da mensagem ''InformRequest-PDU''.<br /> <br /> Outro exemplo de modelo ''push'' seria com o serviço Syslog sobre uma das 24 &quot;''facilities''&quot; (de 0 a 23) especificadas pelo &lt;nowiki&gt;RFC 5424&lt;/nowiki&gt;, sendo algumas de uso reservado para aplicações e serviços específicos, enquanto outras são de uso local (podendo ser destinados praticamente para qualquer finalidade) em combinação com um dos 8 níveis de severidade (0=EMERGENCY, 1=ALERT, 2=CRITICAL, 3=ERROR, 4=WARNING, 5=NOTICE, 6=INFORMATIONAL, 7=DEBUG) para comunicar eventos específicos de acordo com esta combinação de ''Facility'' x ''Severity'' para uma estação coletora de Syslog. Sistemas bastante completos e flexíveis de correlação de eventos podem consumir e processar estas informações para reportar uma gama muito ampla de situações, além de permitir a derivação de métricas e analíticos. O uso de scripts podem ser por ações independentes projetadas pelo administrador, ou ainda como parte integrante de funções existentes de sistemas de gerenciamento propriamente ditos.<br /> <br /> Dentre outras possibilidades envolvendo este modelo ''push'', há as próprias ferramentas embarcadas nos sistemas operacionais / software dos roteadores e switches, dentre os quais recomendo o ''Cisco Embedded Event Manager'' (EEM), ''Junos Event Scripts'', assim como facilidades similares encontradas em plataformas de outros fabricantes, os quais permitem flexibilizar bastante como eventos e outras informações podem ser encaminhadas para outros sistemas residindo em servidores da rede.<br /> <br /> ==== Telemetria orientada a modelos ====<br /> Ou MDT. As ferramentas e procedimentos clássicos empregados nos modelos ''pull'' e ''push'' tradicionais, citados previamente, possuem algumas restrições e limitações, mas isto não significa que protocolos e procedimentos tais como SNMP, shell scripting, recursos de software de roteadores (Cisco EEM, Junos Event Scripts, Huawei OPS, etc.) serão descontinuados ou aposentados tão cedo, muito pelo contrário. Na verdade, a tendência é que sejam encontrados novos propósitos e finalidades para estes protocolos e serviços mais legados, ou ainda dedicando-os para coletas de instruções e operações bem mais específicas, e não tão generalistas como ocorre atualmente na maioria das redes, enquanto novas tecnologias estão ganhando espaço para conquistarmos melhores resultados para as nossas necessidades de gerenciamento de configurações, gerenciamento de performance, gerenciamento de falhas, analíticos, ''big data'' e afins. E é justamente aqui onde entra o conceito de '''''telemetria''''' na sua forma mais ampla e efetiva.<br /> <br /> A telemetria orientada à modelos embarca e combina procedimentos de &quot;''telemetria orientada a eventos''&quot; e, principalmente, como destaque, a &quot;''telemetria de streaming periódica''&quot;, para proporcionar os melhores resultados, e não apenas nas ações técnicas e operacionais que competem aos centros de gerência de redes, tais como gerenciamento FCAPS no geral, mas, principalmente, em termos de ''big data'', analíticos e afins, sendo o principal diferencial entre esta modalidade e os modelos tradicionais de gerenciamento no geral.<br /> <br /> A principal diferença entre as duas abordagens, a &quot;tradicional&quot; e a &quot;telemetria&quot;, é que o modelo tradicional, simplificando aqui, emprega o protocolo SNMP, além de outros procedimentos já citados. Para efeitos comparativos, operações com protocolos tais como o SNMP são executadas com o modelo ''pull'' diretamente sobre os elementos da rede, exceto quando considerando aqui os SNMP Traps, que são muito específicos para alertas e eventos, e que operam por método ''push''. Já na telemetria por streaming periódico os dados são enviados diretamente e em tempo real a partir dos elementos da rede para os coletores e sistemas de gerenciamento, ou seja, conceito &quot;''push''&quot; mesmo, mas com diferenças significativas em termos de capacidade, recursos e disponibilidade de informações, além da própria característica &quot;''tempo real''&quot;. No que diz respeito à telemetria orientada e eventos, um dos maiores exemplos é o recurso ''BGP Monitoring Protocol'' (BMP), que poderá encaminhar eventos praticamente em tempo real acerca da operação do protocolo BGP no seu ASN. Os ganhos e benefícios disto tudo serão discutidos posteriormente neste artigo.<br /> <br /> A ilustração a seguir exemplifica as diferenças e principais componentes empregados em cada um dos casos citados aqui:<br /> [[Arquivo:Bpf-gerbgp-comparativosger.jpg|centro|miniaturadaimagem|907x907px|Comparativos entre os modelos de gerenciamento factíveis para o BGP]]<br /> <br /> ==== Comparativos entre os diversos tipos de tecnologias (protocolos e serviços), suas capacidades, finalidades e propósitos, e suas respectivas categorizações ====<br /> A tabela a seguir certamente será muito útil para concentrarmos muitas informações importantes e bem relevantes para dissertarmos sobre os aspectos e possibilidades quanto ao gerenciamento do BGP.<br /> {| class=&quot;wikitable&quot;<br /> |+Tabela comparativa entre diversos tipos de protocolos e serviços, suas capacidades, finalidades e propósitos<br /> !Ferramenta<br /> <br /> (Protocolo e/ou Serviço)<br /> !Alguns exemplos de situações em que pode ser empregada<br /> |-<br /> |'''SNMP (operações &quot;Get&quot;)'''<br /> |Operações de recuperação e amostragem de informações obtidas por meios de operações &quot;get&quot; do SNMP.<br /> * Consultas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Identificação de propriedades de sessões BGP (ex: temporizadores) e capacidades suportadas<br /> * Identificação da quantidade de rotas aceitas de uma sessão BGP<br /> * Identificação da quantidade de rotas recusadas de uma sessão BGP<br /> * Identificação da quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Identificação de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> * Recuperação da tabela de roteamento (Ex: 1.3.6.1.2.1.4.21 - ipRouteTable)<br /> |-<br /> |'''SNMP Traps'''<br /> |Alertas que poderão ser recebidos por sistemas de gerenciamento com suporte às MIBs necessárias.<br /> * Alertas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Alertas de quantidade de rotas recebidas de uma sessão BGP<br /> * Alertas de quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Alertas de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> |-<br /> |'''RMON'''<br /> |O RMON tem pouca ou nenhuma utilidade específica para os interesses de gerenciamento do BGP, mas suas capacidades e recursos poderão ser obtidas e combinadas para agregar valor ao propósito de gerenciamento como um todo.<br /> * Estatísticas em tempo real de utilização dos segmentos Ethernet envolvidos no transporte de sessões BGP (utilização, erros, colisões)<br /> * Fornecer histórico de estatísticas selecionadas, e com suporte ao uso de variáveis especificadas pelo usuário.<br /> <br /> * Encaminhamento de alarmes para RMON SNMP traps quando houver o cruzamento de determinados thresholds pré-definidos, inclusive com suporte a grupos de alarmes.<br /> * Monitoramento de hosts, tais como a quantidade de bytes e frames enviados e recebidos de vizinhos BGP.<br /> * Ordenamento de &quot;top hosts&quot; com coleta e manutenção de dados referentes a conexões ativas por um determinado período de tempo.<br /> * Matriz de tráfego entre dois roteadores envolvidos numa sessão BGP.<br /> * Filtragem de dados com base em padrões de interesse do administrador, tais como endereços MAC, e portas de protocolos de transporte.Captura de pacotes para análise posterior em depuradores.<br /> * Descoberta e estatísticas por protocolo.<br /> * Mapeamento entre endereços MAC e endereços IP referentes as sessões BGP<br /> * Estatísticas de tráfego L3 com ordenamento por host ou par de conversação (origem/destino), como complemento ao monitoramento do BGP.<br /> * Estatísticas de tráfego L7 por protocolo de aplicação e por host, como complemento ao monitoramento do BGP.<br /> |-<br /> |'''Syslog'''<br /> |Alertas que poderão ser recebidos por servidores syslog &quot;crus&quot; ou uma solução específica para correlação de eventos e processamento de analíticos.<br /> * Alertas de esgotamento de recursos de memória para algum processo ou ação do BGP<br /> * Alertas de problemas com a instalação de rotas BGP devido a inconsistências ou atributos inválidos<br /> * Alertas de falhas de semântica de políticas (route-map, route-policy, etc.) vinculadas a sessões BGP<br /> * Alertas de falhas nas estruturas internas dos processos BGP<br /> * Alertas de problemas de processamento de ações sobre atributos (ex: remoção de AS_PATH, modificação de NEXT_HOP)<br /> * Alertas de recebimento de prefixos inválidos (ex: Martians)<br /> |-<br /> |'''Shell scripting para invocação de CLI'''<br /> |Recuperação de qualquer informação possível por comandos na CLI do roteador.<br /> * Verificação do status de todas as vizinhanças BGP<br /> * Verificação detalhada de uma vizinhança BGP específica<br /> * Contadores de prefixos anunciados e recebidos por vizinho BGP<br /> * Detalhamento das rotas BGP anunciadas para um determinado vizinho BGP<br /> * Detalhamento das rotas BGP recebidas de um determinado vizinho<br /> * Consultas sobre a tabela BGP integral<br /> * Consultas sobre a tabela BGP com parâmetros de refinamento (expressão regular/regex, community, next-hop, policy...)<br /> * Consultas sobre a tabela BGP de rotas não filtradas (pré-policy) de um determinado vizinho (soft-reconfig inbound)<br /> |-<br /> |'''Cisco EEM'''<br /> |Componente do software de roteadores da Cisco, permitindo que você automatize tarefas, execute modificações e ajustes sobre diversos componentes lógicos, e crie ações alternativas. Dentre muitas possibilidades, e focando aqui no BGP, é possível:<br /> * Monitorar o estado operacional ou funcionamento de determinados protocolos e serviços e tomar ações automaticamente em função de algum evento pré-definido por você.<br /> * Implementar uma rotina de verificação de oscilação de sessões BGP, as quais, atingindo um determinado &quot;''threshold''&quot;, poderá invocar uma ação de notificação por Syslog, SNMP, Email (que poderá ser uma máscara de WhatsApp ou Telegram).<br /> * Em adição ao conceito acima, executar uma ação que poderá incluir a modificação de uma route policy para consequente redução do atributo LOCAL_PREF implementado sobre as rotas recebidas de um peer que está oscilando.<br /> * Em adição ao conceito acima, executar uma ação que poderá decidir por desabilitar administrativamente aquela sessão por um determinado período de tempo ou até que haja garantias de que a sessão esteja estável por &quot;x&quot; horas.<br /> * Implementar uma rotina de detecção de existência ou ausência de uma determinada rota BGP na tabela de roteamento (RIB), permitindo uma ação desejada que poderia incluir o estabelecimento de um túnel GRE ou TE, o &quot;shutdown&quot; ou &quot;no shutdown&quot; de uma interface, uma mudança de policy, etc.<br /> * Implementar uma rotina que vá coletar informações (tabela BGP, NLRIs com determinados atributos (ex: communities), rotas BGP da RIB, sessões, etc.) em intervalos periódicos, escrevendo os ''outputs''/dados em um arquivo em um servidor FTP.<br /> * &quot;Quem tem limites é município&quot;. O limite é virtualmente a capacidade criativa do administrador da rede; a sua imaginação. Experimente!<br /> |-<br /> |'''Juniper Event Scripts'''<br /> |Componente embarcado no sistema operacional JUNOS dos roteadores da Juniper Networks e com proposta similar ao Cisco EEM.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o Juniper Event Scripts propõe-se a fazer aquilo que o Cisco EEM faz, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas duas ferramentas.<br /> |-<br /> |'''Huawei Open Programmability System (OPS)'''<br /> |Componente embarcado no sistema operacional dos roteadores da Huawei e com proposta similar ao Cisco EEM e ao Juniper Event Scripts.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o OPS propõe-se a fazer aquilo que o Cisco EEM e o Juniper Event Scripts fazem, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas três ferramentas.<br /> |-<br /> |'''OpenConfig, NETCONF, RESTCONF, gNMI, gRPC, e modelos YANG'''<br /> |O OpenConfig, padrão aberto para o desenvolvimento de interfaces programáticas, viabiliza um gerenciamento mais dinâmico das infraestruturas (ex: telemetria) utilizando como transporte os protocolos e procedimentos NETCONF, RESTCONF, gNMI ou gRPC, em combinação com repositórios de dados modelados pelo YANG, para proporcionar um novo universo de possibilidades em termos de gerenciamento.<br /> <br /> Uma de suas principais aplicabilidades envolve o chamado ''Model-Driven Telemetry'' ou MDT. Quando pensando em gerenciamento por este modelo de telemetria, as possibilidades chegam a surpreender, pois a entrada de dados por ser feita pelos protocolos supracitados, ou ainda por JSON, Kafka, Google Protocol Buffer (GPB), Google RPC (GRPC), dentre outros, a lista é interessante.<br /> <br /> Já a saída de dados poderá ser feita para Kafka, Prometheus, InfluxDB, JSON, XML, e outros, pois a lista é igualmente interessante, o que abre um leque realmente surpreendente de situações e possibilidades. Nunca as redes foram tanto &quot;''software-defined''&quot;: o MDT é um divisor de águas! <br /> * Modelagem e streaming periódico/contínuo de dados para a representação das rotas BGP da RIB com suporte a 5 RIBs lógicas por família de endereços.<br /> * Provimento de definições de dados para tabelas BGP, tipos, identidades, especificações, atributos, e afins, para o gerenciamento efetivo do BGP por OpenConfig.<br /> * Gerenciamento, automação e orquestração de sessões e políticas de roteamento.<br /> * Streaming contínuo de indicadores de performance do BGP, incluindo FSM das sessões, quantidade de sessões, quantidade de rotas total e aceitas/recusadas por neighbor, etc.<br /> * Streaming contínuo de indicadores de anomalias associadas ao BGP.<br /> |-<br /> |'''NetFlow / JFlow / sFlow'''<br /> |O emprego destas tecnologias correlacionam os registros dos fluxos de tráfego juntamente com as informações de roteamento BGP para que seja possível visualizar as conversações para a extração de diversos analíticos importantes.<br /> * Monitoramento em tempo real de registros de fluxos de conversações juntamente com as indicações de Sistemas Autônomos envolvidos.<br /> * Identificação através de pesquisas customizadas sobre fluxos de tráfego por origem, destino, par origem-destino, protocolo de transporte, marcação de QoS, Sistema Autônomo BGP, etc.<br /> * Identificação dos &quot;''top talkers''&quot; por uma variedade de critérios de consulta.<br /> |-<br /> |'''BGP Link-State (BGP-LS)'''<br /> |O BGP Link-State (LS) é uma extensão do protocolo BGP fornecida por meios de um ''Address Family Identifier'' (AFI) e ''Sub-address Family Identifier'' (SAFI) para transportar o ''Link-State Database'' (LSDB) de protocolos IGP (OSPF e IS-IS) através do BGP. <br /> <br /> O BGP-LS permite uma série de aplicações, desde o fornecimento de informações topológicas detalhadas da rede para servidores específicos orientados à otimização de tráfego de rede na camada de Aplicação (ALTO), suporte a Path Computation Element (PCE) para engenharia de tráfego, e outros.<br /> <br /> No que diz respeito ao monitoramento do BGP, o BGP-LS poderá atuar como um componente adicional para agregar mais informações em diversas bases e sistemas onde os dados específicos de BGP são coletados, mantidos, processados, e representados.<br /> * Fornecimento de informações topológicas detalhadas da rede.<br /> * Combinação e correlação dos dados topológicos com estruturas de dados fornecidas por outros meios de gerenciamento centrados na otimização e visibilidade do BGP, tais como sFlow/JFlow/NetFlow, BMP, CLI, e SNMP.<br /> * Visibilidade, correlação de eventos, aprimorar ações de planejamento de capacidades e de engenharia de tráfego, e detecção de incidentes de segurança.<br /> |-<br /> |'''BGP Monitoring Protocol (BMP)'''<br /> |Acesso de sistemas de gerenciamento ao Adj-RIB-In de peers BGP para o recebimento periódico de estatísticas do protocolo.<br /> * Recebimento periódico de estatísticas que possam ser usadas para monitorar as atividades específicas do BGP.<br /> * Recebimento de notificações acerca do estado operacional das sessões BGP.<br /> * Recebimento das tabelas BGP pré-policy, ou seja, antes que o roteador implemente os filtros de import/export sobre as rotas.<br /> * Recebimento das tabelas BGP pós-policy, ou seja, após o roteador ter filtrado e filtrado atributos associados às rotas.<br /> * Em combinação com validadores de IRR, poderá detectar route leaks gerados ou recebidos pelo AS local.<br /> * Em combinação com validadores de RPKI, poderá detectar violações de ASN de origem associados às rotas recebidas ou enviadas.<br /> * Poderá ser combinado para fornecer funcionalidade de Looking Glass.<br /> * Fornecimento de visibilidade histórica envolvendo estado de sessões.<br /> * Fornecimento de visibilidade e histórico de prefixos com refinamento por &quot;peer&quot;, &quot;ASN&quot; e &quot;prefixo&quot;.<br /> * Permite estudar através de uma linha temporal todos os anúncios e recebimentos realizados, incluindo rotas aceitas e recusadas.<br /> * Permite estudar através de uma linha temporal todas as modificações de atributos executadas sobre rotas aceitas.<br /> |}<br /> Como não dá para abordar tudo em um artigo - talvez outros artigos sobre o tema sejam disponibilizados na Wiki do BPF - procurarei demonstrar algumas coisas que podem ser feitas com algumas das ferramentas/opções listadas na tabela acima. Que tal focarmos em dois componentes aqui? SNMP e BMP. <br /> <br /> === Monitoramento do BGP com o Simple Network Management Protocol (SNMP) ===<br /> O monitoramento de infraestruturas de redes por SNMP não é novidade alguma para os profissionais da área, muito pelo contrário. E, no que diz respeito ao monitoramento do BGP, o SNMP tem sido amplamente utilizado por muitas empresas para cumprir com diversas das necessidades e desafios comentados previamente. Por ser algo um tanto difundido, talvez o único método de gerenciamento/monitoramento propriamente dito adotado por ISPs regionais de pequeno e médio portes, não desprenderei muito tempo nesta seção do artigo.<br /> <br /> Diversas plataformas baseadas em software podem ser utilizadas para monitorar o BGP, dentre os quais destaco os seguintes:<br /> * [https://www.zabbix.com/ Zabbix]<br /> * [https://www.librenms.org/ LibreNMS]<br /> * [https://www.observium.org/ Observium]<br /> * [https://www.nagios.com/ Nagios]<br /> * [https://www.cacti.net/ Cacti]<br /> * [https://www.opennms.com/ OpenNMS]<br /> * [https://www.solarwinds.com/pt/ Solarwinds]<br /> * [https://www.paessler.com/prtg PRTG]<br /> * Integrações de boa parte destas soluções com o [https://grafana.com/ Grafana] para a geração de dashboards<br /> * Soluções comercias de fabricantes tais como Cisco, Juniper e outros<br /> Está fora do escopo deste artigo tecer quaisquer comparativos (&quot;''qual é o melhor?''&quot;, etc.) dentre estas soluções.<br /> <br /> Independentemente de qual abordagem/solução seja escolhida por você para atender as suas necessidades, o fato é que você terá que assegurar o devido suporte a alguns componentes específicos para o monitoramento do BGP, em particular a '''''BGP4-MIB''''', conforme descrita no RFC 4273 (''Definitions of Managed Objects for BGP-4'') e RFC 4275 (''BGP-4 MIB Implementation Survey''). Você deverá considerar também eventuais MIBs que implementem OIDs proprietários de acordo com o fabricante do equipamento que você necessitar monitorar pela sua gerência SNMP, por exemplo a [https://www.juniper.net/documentation/en_US/junos/topics/reference/mibs/mib-jnx-bgpmib2.txt '''''Juniper-BGP-MIB'''''] e [https://mibs.cloudapps.cisco.com/ITDIT/MIBS/MainServlet?ReleaseSel=4669&amp;PlatformSel=269&amp;fsSel=348 '''''Cisco-BGP-MIBv2'''''] , e certificar-se que seus sistemas de gerenciamento (ex: Zabbix) implementem funções para operações de consulta sobre os OIDs desejados com estas MIBs. Além destas MIBs, muitos destes sistemas possuem plugins prontos para o monitoramento do BGP em condições diversas, por exemplo:<br /> * Zabbix<br /> ** [https://share.zabbix.com/network_devices/cisco/cisco-bgp-ipv4-ipv6-32-bit-asn Cisco BGP IPv4/IPv6 32-bit ASN]<br /> ** [https://share.zabbix.com/network_devices/juniper/juniper-mx-discovery-int-re-bgp4-ipv4-and-ipv6 Template SNMP Juniper MX discovery: int, RE, BGP4 ipv4 and ipv6]<br /> ** [https://share.zabbix.com/network_devices/mikrotik/zabbix-routeros-bgp-monitoring Zabbix RouterOS BGP Monitoring]<br /> * LibreNMS<br /> ** [https://docs.librenms.org/API/Routing/ Monitoramento de sessões BGP] e [https://docs.librenms.org/Alerting/Entities/ Entities]<br /> * Observium<br /> ** [https://docs.observium.org/config_options/ Monitoramento de sessões BGP]<br /> * Nagios<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check-BGP-neighbor-JunOS/details Check BGP Neighbor JunOS]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp/details check_bgp]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_counters/details check_bgp_counters]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_v4_v6/details check_bgp_v4_v6]<br /> * Grafana<br /> ** [https://grafana.com/grafana/plugins/alexanderzobnin-zabbix-app Plugin para Zabbix]<br /> ** [https://grafana.com/grafana/plugins?orderBy=weight&amp;direction=asc Plugins para diversas finalidades e integrações]<br /> ** [https://grafana.com/grafana/dashboards?dataSource=alexanderzobnin-zabbix-datasource&amp;orderBy=name&amp;direction=asc Dashboards &quot;prontos&quot;]<br /> * Outros! basta pesquisar pelos recursos desejados junto à documentação do seu sistema de gerenciamento, entrar em contato com o suporte de desenvolvimento, contratar uma consultoria especializada, etc.<br /> O funcionamento do monitoramento do BGP por SNMP não é complexo, pois é um procedimento um tanto difundido entre os operadores de redes. As estações de gerenciamento são configuradas para executar consultas periódicas sobre os roteadores monitorados usando operações &quot;''Get''&quot; sobre os ''Object Identifiers'' (OID) desejados, os quais precisam ser especificados numa MIB apropriada (ex: BGP4-MIB), e cujo o suporte a esta MIB deverá existir tanto no roteador monitorado quanto no software em execução na estação de gerenciamento. O SNMP funciona neste caso como um mecanismo de solicitação e resposta, e as informações recuperadas por meios deste mecanismo são armazenadas nas bases de dados que acompanham estas soluções, e devidamente processadas para reportar alguma coisa em alguma função do sistema. Em adição, é possível consultar estes dados via integrações com outros sistemas (ex: Grafana) para finalidades de representação melhor elaboradas, como painéis/dashboards e afins. Por exemplo:<br /> [[Arquivo:Bpf-gerbgp-snmp.jpg|centro|miniaturadaimagem|900x900px|Exemplo de monitoramento do BGP por procedimento SNMP]]<br /> É importante frisar também que o gerenciamento do BGP para a questão de incidentes tais como oscilações de sessões (ou &quot;''flapping''&quot;) pode ser tratada por intermédio de mensagens ''SNMP trap''. O sistema de gerenciamento (chamamos aqui de software &quot;NMS&quot;), ao receber o evento por SNMP trap, buscará processar a informação de acordo com as diretivas que estiverem definidas para o elemento de rede gerenciado, permitindo destacar o evento da falha de forma visível nos painéis correspondentes oferecidos pelo software NMS. Apesar de isto não ser novidade alguma, acho que não custa nada deixar isto esclarecido para a eventualidade deste artigo ser consultado por indivíduos mais leigos.<br /> [[Arquivo:Bpf-gerbgp-snmptrap.jpg|centro|miniaturadaimagem|900x900px|SNMP traps para a funcionalidade de notificações e alertas do gerenciamento de falhas]]<br /> <br /> Nas mãos de profissionais caprichados, é possível construir painéis bastante interessantes com soluções relativamente simples, mas não menos interessantes, intuitivas ou funcionais, baseadas no SNMP, em especial quando envolvendo o Grafana para a produção destes painéis. Alguns casos de uso do Zabbix + Grafana para o monitoramento do BGP serão demonstrados aqui, sendo que, em alguns cenários, além do SNMP, outros procedimentos podem ser envolvidos para a recuperação e representação das informações desejadas para cada painel.<br /> <br /> No painel demonstrado a seguir, idealizado pelo Caio Ribeiro da [https://www.facebook.com/flowbix Flowbix], foi possível concentrar muita informação útil/relevante numa única tela: desde status das sessões BGP com seus respectivos ''uptimes'', total de prefixos IPv4 com indicadores de RIB e FIB, estado dos módulos ópticos do equipamento roteador BGP monitorado, a estatísticas de consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio1.jpg|centro|miniaturadaimagem|1280x1280px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também idealizado pela Flowbix, outra consolidação de dados importantes numa única tela, incluindo latência, índice de perda de pacotes, disponibilidade, uso de recursos tais como CPU, memória e espaço em disco, estado geral das sessões BGP monitoradas, e consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio2.jpg|centro|miniaturadaimagem|967x967px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também elaborado pela Flowbix, temos estatísticas mais centradas no estado das sessões BGP, e em combinação com uma visão geral dos índices de latência registrados.<br /> [[Arquivo:Bpf-gerbgp-caio3.jpg|centro|miniaturadaimagem|900x900px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Realmente, os limites em termos de construção de painéis para objetos gerenciados por SNMP com uma combinação NMS (ex: Zabbix) + Grafana, além de outros possíveis procedimentos, são um tanto amplos. Muita coisa de fato pode ser feita, desde que você possua os conhecimentos necessários para desenvolver estas integrações. Ou, então, por que você não investe em serviços de integração para o seu negócio?<br /> <br /> === Monitoramento por meios do BGP Monitoring Protocol (BMP) ===<br /> Muitos profissionais da área, incluindo engenheiros que atuam nas principais empresas de Internet do mundo, fabricantes e pesquisadores, chegaram a conclusão que era realmente necessário que tivessem acesso ao conteúdo das rotas mantidas nas tabelas BGP de roteadores, assim como uma visão do conteúdo das mensagens Update empregadas na troca de rotas entre sessões BGP. O grande desafio, porém, é que os modelos tradicionais de gerenciamento (ex: SNMP) praticamente inviabilizam o cumprimento de ações que fornecessem estas informações. Surgiu então o '''''BGP Monitoring Protocol''''', especificado originalmente no &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; (''BGP Monitoring Protocol (BMP)'') e complementado pelo &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)'').<br /> <br /> O BMP fornece meios de acesso ao ''Adj-RIB-In'' de uma sessão BGP de uma forma contínua em adição a um despejo periódico de dados estatísticos para uma estação coletora, devidamente equipada com software específico, para que os engenheiros do Sistema Autônomo possam analisar o funcionamento e o comportamento do BGP.<br /> <br /> Antes mesmo de você conhecer os benefícios do monitoramento do BGP com o protocolo BMP, você precisa saber identificar alguns componentes e conceitos fundamentais <br /> * '''''Adj-RIB-In''''': conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt; (''A Border Gateway Protocol 4 (BGP-4)''), o ''Adj-RIBs-In'' contém as informações de roteamento ainda não processadas que foram anunciadas pelo roteador BGP para seus vizinhos. É conhecido também pelo termo &quot;''pre-policy Adj-RIBs-In''&quot;. Na perspectiva do BMP, o ''Adj-RIB-In'' representa todas as rotas que foram recebidas pelo coletor antes destas informações terem sido processadas por uma policy inbound.<br /> * '''''Post-Policy Adj-RIBs-In''''': é o resultado de aplicação da política de roteamento inbound (ou &quot;import&quot;, como é conhecido em algumas plataformas), mas antes de ter ocorrido o processo de seleção de caminhos (best-path) do BGP para a composição da tabela de roteamento local. Na perspectiva do BMP, o ''post-policy Adj-RIB-In'' representa as informações que foram recebidas pelo coletor após a aplicação de policies inbound ou modificações de quaisquer atributos.<br /> Ou seja, a diferença entre ''pre-policy Adj-RIB-In'' e ''post-policy Adj-RIB-In'' é que, no primeiro caso, não houve a aplicação de quaisquer filtros sobre as rotas recebidas antes que estas informações fossem exportadas para o coletor BMP. E, no post-policy, as informações são encaminhadas para o coletor BMP após o roteador ter &quot;filtrado&quot; (e, potencialmente, modificado atributos) por meios de policies inbound, mas antes do roteador ter conduzido o processo de seleção de ''best path'' para posterior composição da RIB local referente a estas rotas BGP. O monitoramento de updates recebidos de um roteador antes da aplicação de policies inbound tem sido provavelmente a aplicação mais frequente envolvendo o BMP, enquanto o post-policy está mais centrado nas questões relacionadas à auditoria e validação das políticas de roteamento implementadas pela empresa.<br /> <br /> No entanto, o monitoramento apenas do ''Adj-RIB-In'' impõe uma restrição sobre quais dados estariam disponíveis ou acessíveis para os coletores BMP. Como a maioria dos Sistemas Autônomos não possui qualquer implementação de BMP e, quando possuem, não disponibilizam estas informações para terceiros (ex: acesso leitura-apenas ao painel da estação coletora BMP), a sua empresa fica sem visibilidade sobre de fato o que foi anunciado e aceito para os peers de ASs vizinhos. Tudo bem que a consulta destas informações por Looking Glass (que não são baseados em BMP) até permite que você consiga de fato ver se um determinado anúncio encontra-se presente nas tabelas BGP do AS vizinho, mas, no entanto, sem quaisquer dados históricos e facilidades deste tipo, os quais estariam disponíveis com o BMP, ou na alçada deste. E é justamente aí que entra outra proposta, que é o &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)''). Este RFC introduz alguns argumentos e facilidades adicionais para o BMP, dentre os quais:<br /> * '''''Adj-RIB-Out:''''' conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt;, o ''Adj-RIB-Out'' contém as rotas designadas para anúncios para os peers BGP por intermédio das mensagens UPDATE.<br /> * '''''Pre-policy Adj-RIB-Out''''': é o resultado de representação dos prefixos que serão anunciados pelas mensagens UPDATE antes da aplicação de policies outbound (ou &quot;export&quot;). Geralmente é a mesma coisa que encontra-se no momento na RIB local do roteador.<br /> * '''''Post-policy Adj-RIB-Out:''''' é o resultado do envio de prefixos através de anúncios (UPDATE) após o processamento das informações pelas policies outbound. É a representação do que de fato está sendo anunciado para um peer BGP específico.<br /> O ''BGP Monitoring Protocol'' (BMP) opera sobre uma sessão TCP entre o roteador monitorado e a estação coletora BMP. A configuração da sessão é um tanto flexibilizada, com possibilidade de conexão passiva (iniciada pelo roteador apenas) e mecanismos de backoff de tentativas de conexão com intervalos configuráveis, assim como outros parâmetros para o controle de fluxo de informações entre o roteador e a estação coletora BMP. Nenhuma mensagem BMP é enviada da estação coletora para o roteador, mas nada impede que o administrador da rede configure uma policy inbound para recusar quaisquer anúncios (que sabemos que nunca serão enviados) vindos da estação coletora BMP. Com relação às mensagens empregadas pelo BMP, o &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; especifica as seguintes:<br /> * '''''Type 0: Route Monitoring (RM)''''': é usado para fornecer um dump inicial de todas as rotas recebidas a partir de um peer, e atua também como um mecanismo contínuo para relatar, de forma incremental, as rotas que são anunciadas e revogadas (''withdrawn)'' por um peer para a estação coletora BMP. A mensagem ''Route Monitoring'' consiste de ''Common Header'' + ''Per-Peer Header'' + mensagem BGP ''UPDATE'' na íntegra.<br /> * '''''Type 1: Statistics Report (SR)''''': fornece um despejo periódico de estatísticas que podem ser utilizadas pelo coletor BMP para relatar as atividades específicas do BGP realizadas pelo roteador. A mensagem ''Stats Reports'' consiste de ''Common Header'' + ''Per-Peer Header'' + um campo de 4 bytes indicando a quantidade de contadores, sendo que cada contador é codificado na forma de um TLV. Stats são informados como ''Counters'' (32-bit) ou ''Gauges'' (64-bit).<br /> * '''''Type 2: Peer Down Notification''''': uma mensagem que é enviada para indicar que uma sessão BGP foi desconectada, fornecendo ainda o motivo para esta desconexão. A mensagem ''Peer Down Notification m''enciona um dos 5 motivos indicativos do encerramento de uma sessão BGP do roteador (''Reason'' 1 a ''Reason'' 5).<br /> * '''''Type 3: Peer Up Notification''''': uma mensagem que informa que uma sessão BGP ficou Up ou &quot;Established&quot;. Esta mensagem inclui informações importantes sobre o que ficou negociado entre os roteadores participantes desta sessão (conteúdo da mensagem OPEN) e também dados referentes à sessão BGP. A mensagem ''Peer Up Notification'' consiste de ''Common Header'' + ''Per-Peer Header'' + a mensagem (BGP) ''OPEN'' enviada + a mensagem ''OPEN'' que foi recebida + informações sobre o peer (opcional)<br /> * '''''Type 4: Initiation Message''''': fornece um mecanismo de indicação para o coletor BMP sobre o roteador BGP, incluindo o fabricante/modelo, versão de software, etc., funcionando como uma espécie de controle de inventário. A mensagem ''Initiation Message'' consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' contendo informações acerca do roteador monitorado, sendo que ''sysDescr'' e ''sysName'' são obrigatórios, enquanto os demais são opcionais.<br /> * '''''Type 5: Termination Message''''': fornece um mecanismo utilizado para informar que a sessão BMP entre o roteador e o coletor BMP foi interrompida. A mensagem ''Termination Message'' consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' descrevendo um dos 5 motivos (''Reason'' 0 a Reason 4) pela ''terminação'' da sessão BMP com o roteador monitorado.<br /> * '''''Type 6: Route Mirroring Message''''': um mecanismo para o roteador monitorado enviar duplicatas literalmente de mensagens conforme são recebidas. Pode ser usado para espelhar exatamente uma sessão BGP monitorada, assim como ser usado para relatar PDUs malformados do protocolo BGP. A mensagem ''Route Mirroring'' consiste de ''Common Header'' + ''Per-Peer Header'' + conjuntos de TLVs que descrevem as mensagens, sendo que 2 bytes informam o código do tipo de mensagem (ex: Type 0 = ''BGP Message'', Type 1 = ''Information'', Type 1 Code 0 = ''Errored PDU'' e Type 1 Code 1 = ''Messages Lost''), 2 bytes o campo de comprimento, e um campo de valor de comprimento variável.<br /> O &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; por sua vez implementa algumas modificações nas estruturas destas mensagens para acomodar as situações ''Adj-RIB-In'' e ''Adj-RIB-Out'', tais como flag O assinalado para &quot;0&quot; em mensagens BMP com cabeçalho ''per-peer'', e os flags necessários para denotar especificamente ''Adj-RIB-In'' ou ''Adj-RIB-Out'' para as mensagens ''Route Monitoring'' e ''Route Mirroring''.<br /> [[Arquivo:Bpf-gerbgp-bmpheaders.jpg|centro|miniaturadaimagem|900x900px|Cabeçalhos do BMP conforme &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt;]]Acredito que você já esteja entendendo melhor as funcionalidades básicas proporcionadas pelo ''BGP Monitoring Protocol'' (BMP)! Que tal apresentarmos um caso prático envolvendo o monitoramento do BGP por esta tecnologia?<br /> <br /> ==== Caso de uso: monitoramento por BGP Monitoring Protocol (BMP) com o Streaming Network Analytics System (SNAS) ====<br /> O caso apresentado a seguir é uma das diversas possibilidades associadas ao monitoramento do BGP em um Sistema Autônomo com o BMP. Para encurtarmos uma dissertação excessivamente prolongada deste caso, optei por elaborar um simples &quot;canvas&quot; para representar um conceito de solução proposta baseada no ''Streaming Network Analytics System'' (SNAS). O modelo canvas mostrado a seguir tem uma estrutura modificada/customizada para refletir as características gerais do conceito de solução proposto da maneira que eu gostaria de fornecer, ou seja, colocando numa única página, a relação de ''Problemas/Necessidades'', ''Solução'', ''Argumentos de Adoção'', ''Vantagens'', ''Desvantagens'', ''Resultados'', ''Características de Extensibilidade e Integração'' e um ''Bloco Representativo da Solução''. Este arranjo ou customização do modelo canvas deve ser eficiente o bastante para esclarecer esta solução.<br /> [[Arquivo:Bpf-gerbgp-openbmp.jpg|centro|miniaturadaimagem|900x900px|Canvas model do conceito de solução factível com base numa derivação do SNAS para o gerenciamento com o BGP Monitoring Protocol ]]<br /> Apenas para constar, a solução é composta pelos seguintes componentes, cada qual com uma função bastante especifica, e devidamente &quot;empacotados&quot; para implementação em containers com Docker: <br /> * '''openBMP:''' servindo como coletor de BMP. Uma sessão BMP é estabelecida entre este coletor e cada roteador onde desejamos monitorar ou coletar os dados referentes ao BGP.<br /> * '''Apache Kafka:''' o Kafka atua como uma plataforma de processamento de streaming de alta capacidade e baixa latência para o tratamento de dados em tempo real. A presença do Kafka no projeto permite conectar múltiplos ''publishers'' e ''subscribers'' para a disseminação de dados de forma bastante rápida, sendo um ótimo diferencial para as questões de integração e compartilhamento de dados de nossa solução com outros sistemas. Esta instalação inclui ainda o '''''Zookeeper''''', um software também desenvolvido pela Apache e que atua como um serviço centralizado, sendo usado para manter os dados de nomenclatura e configuração e para fornecer sincronização flexível e robusta nos sistemas distribuídos. O ''Zookeeper'' controla o status dos nós do cluster Kafka e também rastreia os tópicos, partições, etc.<br /> * '''PostgreSQL:''' O projeto SNAS original emprega como banco de dados o MySQL/MariaDB, isto tem servido bem aos propósitos por um bom tempo. Todavia, os desenvolvedores entenderam que estava na hora de substituí-lo por um banco de dados mais eficiente em função de algumas das limitações do MariaDB, tais como gerenciamento manual de partições de dados de séries temporais, recuperação de espaço em disco e requerimentos de memória do InnoDB, suporte fraco a JSON, dentre outras. O PostgreSQL resolve estas limitações e ainda adiciona algumas facilidades consideradas interessantes pelos desenvolvedores do SNAS, sendo que o consumidor dos dados implementa todas as APIs de análise do barramento de mensagens via o Kafka. Nesta implementação, o container inclui ainda os seguintes: '''''TimescaleDB''''', '''''RPKI Validator''''', e consultas às bases IRR por procedimento '''''Whois'''''. O ''TimescaleDB'' é um banco de dados de código aberto desenvolvido para tornar o SQL escalável para dados de séries temporais, e é aqui empacotado como uma extensão do PostgreSQL para fornecer o particionamento automático através do tempo e espaço (chave de particionamento). O ''RPKI Validator'', por sua vez, é acionado em rotinas próprias para a verificação do status ROA de cada prefixo mantido na base de dados da solução, enquanto o ''Whois'' é invocado em outras rotinas para a recuperação de informações nas bases IRR.<br /> * '''Grafana:''' o SNAS original possui o seu próprio front end WebUI, obviamente não baseado no Grafana, o qual é compatível somente com a instalação original baseada no MySQL/MariaDB. Esta WebUI não é compatível com o PostgreSQL, tampouco o Grafana, nas novas implementações, é compatível com o MariaDB. Caso você queira reaproveitar esta WebUI original com novas instalações já baseadas no PostgreSQL ao invés do MariaDB, ou utilizar como WebUI o Grafana sobre o MariaDB, ao invés da WebUI original, você realmente terá que &quot;por a mão na massa&quot; e fazer todos os ajustes de códigos necessários, etc. Atualmente existem 12 dashboards &quot;prontos&quot; para atuar especificamente sobre a base de dados desta solução por openBMP/SNAS, mas nada impede que você construa os seus próprios dashboards para atender as suas necessidades mais específicas!<br /> * '''Docker:''' a implementação do SNAS ou de qualquer customização derivada a partir deste não depende exclusivamente do Docker! Você pode montar a solução do zero e do jeito que bem entender. Só vejo que há benefícios associados à separação destas aplicações com a abordagem por containers. Sem contar que, para um setup inicial rápido para fins de conhecer o potencial do SNAS, você poderá clonar uma instalação literalmente pronta e colocá-la para rodar em questão de minutos! Lá na frente você então poderá decidir-se como deverá ser a sua instalação definitiva em ambiente de produção, podendo ser em Docker ou não.<br /> [[Arquivo:Bpf-gerbgp-snasdocker.jpg|centro|miniaturadaimagem|900x900px|Cenário: SNAS em containers Docker]]<br /> Apesar de termos basicamente uma solução &quot;pronta&quot; contendo os componentes acima, é possível conceber diversos tipos de integrações com sistemas desenvolvidos internamente ou com soluções comerciais, os quais, por sua vez, podem consumir os dados fornecidos pelo BMP, seja com streaming nativamente por BMP ou então com acesso direto às informações já armazenadas num banco de dados, sem contar ainda o potencial de distribuição de dados em tempo real via a facilidade introduzida com o Kafka. Os desenvolvedores do SNAS inclusive sugerem este e outros cenários de integração em diversas áreas de sua documentação. Um destes cenários destaco a seguir:<br /> [[Arquivo:Bpf-gerbgp-snas.jpg|centro|miniaturadaimagem|900x900px|Exemplo de cenário de integração do SNAS]]Todavia, a solução que será apresentada a seguir é baseada integralmente (e somente) no SNAS, contemplando duas possibilidades para o banco de dados: instalação original baseada no MariaDB + frontend WebUI do SNAS, e instalação baseada no PostgreSQL e integração com o Grafana, juntamente com os dashboards específicos para os nossos objetivos de monitoramento. Em termos de funcionamento desta integração envolvendo as duas possibilidades em termos de bancos de dados e os frontends WebUI original e Grafana, a ilustração a seguir poderá prover uma elucidação adequada:<br /> [[Arquivo:Bpf-gerbgp-snasio.jpg|centro|miniaturadaimagem|900x900px|Coletor, DB e Frontend do SNAS.io (Fonte: snas.io)]]'''Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos'''<br /> <br /> Um caso real aqui obtido com um ISP que realiza o monitoramento por BMP juntamente com painéis por Grafana. Uma realidade é como o seu Sistema Autônomo (você) enxerga o mundo, e outra coisa é como as demais empresas com presença na Internet enxergam o seu AS (você). Uma facilidade muito interessante de um dos 12 dashboards &quot;prontos&quot; para o SNAS é a capacidade de visualização de qualquer ASN na perspectiva das tabelas BGP do seu ASN (você). Uma vez que o coletor BMP (''openbmp'') recebe/coleta as mensagens vindas dos roteadores monitorados, os dados contidos nestas mensagens são reorganizados e repassados diretamente para o Kafka que as comunica/repassa para a base SQL. Este dashboard do Grafana então realiza consultas sobre as diversas tabelas, constrói e representa as informações que destacam como um determinado ASN - e você pode consultar praticamente qualquer ASN neste dashboard - é visto a partir do ASN da sua empresa (você). O dashboard plotará algumas informações bem relevantes, tais como as relações de upstreams e downstreams do ASN pesquisado, juntamente com a resolução correspondente às bases IRR, incluindo os objetos route/route6 identificados para aquele ASN.<br /> <br /> Esta ferramenta poderá ser muito útil não apenas para você, administrador do AS da sua empresa, mas para que os demais ASs possam ter a liberdade de estudar como são vistos a partir do AS da sua empresa, ou seja, um bom esforço de cooperação para facilitar a vida de outros profissionais/empresas quando estes estiverem diagnosticando eventuais problemas relacionados ao roteamento de/para o seu AS.<br /> [[Arquivo:Bpg-gerbgp-bmpasvniew.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para funcionalidade Looking Glass'''<br /> <br /> Looking Glass não é novidade alguma, muito pelo contrário. Mas me surpreende a quantidade de ASNs que não disponibilizam esta ferramenta, à título de &quot;esforço de cooperação&quot;, para que terceiros (outros profissionais e empresas) possam consultá-lo no intuito de diagnosticar e resolver problemas de roteamento associados aos anúncios por BGP. Inacreditável!<br /> <br /> Embora Looking Glasses sejam bastante úteis e conhecidos, há uma limitação aqui: ao consultar um Looking Glass sobre um determinado prefixo/rota, a resposta será sempre aquilo que estiver constando no momento em que você estiver realizando aquela consulta. Perde-se o tato no que concerne ao que poderia ou pode ter acontecido com relação ao prefixo consultado: &quot;''quantas vezes houve alterações nas propriedades desta rota?''&quot;, &quot;''esta rota estava presente neste LG ontem a noite, quando meus usuários reclamaram problemas de acesso?''&quot;, &quot;''qual é a frequência de oscilações das minhas rotas neste ASN por um determinado upstream?''&quot;, e coisas deste tipo. E é justamente nessas horas que este dashboard com funcionalidade estilo Looking Glass poderá ser extremamente útil.<br /> <br /> Este dashboard, também produzido com o Grafana, permite que você possa pesquisar sobre um prefixo e obter, através de uma linha temporal, todo o histórico de mudanças associadas ao anúncio deste prefixo/rota pesquisado, e isto certamente deverá responder a muitos de seus questionamentos. Infelizmente não é possível fazer pesquisas sobre outras propriedades da rota, tais como pesquisas sobre os atributos, principalmente sobre o AS_PATH. Mas creio que isto seja viável no ponto de vista de implementação, cabendo a você estudar toda a estrutura de dados mantida na base SQL, &quot;acertar&quot; a mão nas ''queries'', e desenvolver o seu próprio dashboard para uma consulta por expressão regular e afins!<br /> [[Arquivo:Bpg-gerbgp-bmplg.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]<br /> [[Arquivo:Bpg-gerbgp-bmplg2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos'''<br /> <br /> Outro dashboard montado com o Grafana que oferece uma utilidade tremenda: a capacidade de consultar o histórico de anúncios originados a partir de um determinado ASN! Na verdade, são 3 dashboards distintos que oferecem visibilidades sobre prefixos com ordenamento &quot;''por prefixo''&quot;, &quot;''por peer''&quot;, &quot;''por ASN''&quot;.<br /> <br /> Este tipo de consulta pode ser muito útil quando desejamos compreender as frequências de alterações nas rotas originadas em um ASN, em particular quando seus usuários estiverem reclamando de problemas de acesso a conteúdos vinculados a estas redes. Isto inclusive poderá ser muito útil para saber quais de seus upstreams diretos são mais &quot;estáveis&quot;, já que alterações frequentes e recorrentes destes anúncios por um determinado peer podem indicar que um dos seus upstreams está passando por alguma dificuldade, por exemplo, ou executando manobras nas políticas de roteamento em um determinado horário, ocasionando em oscilações e instabilidades na convergência do seu BGP.<br /> <br /> As pesquisas podem ser realizadas sobre um destes 3 dashboards designados para esta finalidade, conforme:<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas especificamente a um prefixo qualquer:''''' você poderá usar o dashboard &quot;''Prefix History (by Prefix)''&quot; para visualizar todas as mudanças associadas ao prefixo em questão, tais como a data/hora, tipo de evento (''advertised'', ''withdrawn''), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, o prefixo/rota consultado, o ASN de origem, a lista de AS-Path associada ao prefixo, e as communities associadas a cada prefixo identificado neste período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a quaisquer prefixos originados especificamente em um ASN qualquer:''''' você poderá usar o dashboard &quot;''Prefix History (by ASN)''&quot; para determinar características tais como data/hora, tipo de evento (''advertised'', ''withdrawn''), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, os prefixos/rotas deste ASN identificados neste período, o ASN de origem consultado, a lista de AS-Path associada a cada um dos prefixos identificados neste período, e as communities associadas a cada prefixo identificado neste período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a eventos referentes a quaisquer prefixos e de quaisquer ASNs, coletados a partir de um roteador monitorado combinado com cada peer:''''' você poderá usar o dashboard &quot;''Prefix History (by Peer)''&quot; para filtrar a origem dos eventos conforme coletados pelos roteadores monitorados pelo coletor BMP, incluindo data/hora, tipo de evento (''advertised'', ''withdrawn''), roteador monitorado, peer externo, prefixo, lista de AS-Path, e communities associadas à cada rota identificada neste período conforme reportado pelo roteador monitorado.<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por ASN]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por Peer]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis3.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por prefixo]]'''Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos'''<br /> <br /> Um dashboard mais &quot;cosmético&quot; ou &quot;visual&quot;, mas não menos importante. Com este painel você será capaz de identificar, através de seus gráficos, eventuais anomalias associadas às sessões BGP e de suas respectivas atividades relacionadas a anúncios, tais como volume e frequência de eventos ''advertised'' e ''withdrawn'', anúncios (''advertised'') por roteador, retiradas (''withdrawn'') por roteador, ''Updates'' por peer e ''Withdraws'' por peer.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmptop.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de de incidentes de segurança como BGP'''<br /> <br /> Conforme comentado anteriormente, o container que oferece o componente '''''openbmp_psql''''' (PostgreSQL) não contém apenas o PostgreSQL: há ainda a presença do ''TimescaleDB'' e de um '''''validador de RPKI'''''. Na medida em que os dados coletados pelo ''openbmp'' são armazenados na base de dados via o interfaceamento com o ''Kafka'', rotinas são executadas em segundo plano para identificar os registros ROA ''Valid'', ''Unknown'' ou ''Invalid'' referentes a cada um dos prefixos mantidos nas diversas tabelas acomodadas pela solução. Este dashboard permite apresentar um &quot;mapa&quot; de quantos ou quais prefixos um ASN possui erros de validação do RPKI. E, em adição, rotinas secundárias são invocadas para a realização de consultas sobre as bases de ''Internet Routing Registry'' (IRR) referentes a estes mesmos prefixos armazenados na base de dados da solução.<br /> <br /> Consequentemente, através deste dashboard por Grafana, você passa a ter condições de identificar potenciais incidentes relacionados a sequestro de prefixos (''hijacks'') e vazamento de rotas (''route leaks'') associados a um ASN específico sobre o qual você poderá realizar esta consulta. Isto poderá ser útil para visualizar problemas em potencial envolvendo os anúncios de prefixos, os quais podem ser recusados tanto pelas políticas de roteamento do seu próprio ASN quanto pelas políticas de roteamento de upstreams, pois, cada vez mais, as empresas tem adotado certo grau de automação na hora de implementar os filtros necessários para o envio e recebimento de anúncios envolvendo seu cone de clientes, ou seja, filtros de rotas que fatoram o estado de validação do RPKI (descarte de ROA inválido) e também o validação por IRR. <br /> <br /> Apesar de não ser &quot;perfeito&quot; e nem 100% garantido, este dashboard pode ser particularmente útil quando estamos interessados em observar o estado geral da segurança do roteamento BGP no que tange à validade dos anúncios por RPKI e IRR, com maior foco na deteção de ''hijacks'' e ''route leaks''.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de Hijacks e Route Leaks]]<br /> [[Arquivo:Bpf-gerbgp-incidents.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento incidentes de segurança do BGP (Fonte: snas.io)]]<br /> <br /> '''Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR'''<br /> <br /> Este painel aproveita grande parte dos componentes citados no painel anterior (validador RPKI e consultas ao IRR) para fornecer uma visualização mais simplificada de quantos prefixos mantidos na base apresentam algum problema de validação RPKI ou IRR.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR]]'''Caso de uso: monitoramento de sessão BGP por BMP com a WebUI nativa do SNAS.io''' <br /> <br /> O monitoramento por BMP possibilita a extração de algumas informações que atendem a diversas das demandas operacionais do cotidiano do ISP, como, por exemplo, a verificação do estado e demais informações relacionadas às sessões BGP, com resultado parecido com aquele que você obteria com um comando &quot;''show bgp neighbor''&quot; de um roteador.<br /> <br /> [[Arquivo:Bpf-gerbgp-snaspeer info.png|centro|miniaturadaimagem|800x800px|Caso de uso: Peer Info com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: painel Top 20 de prefixos anunciados e removidos com a WebUI nativa do SNAS.io''' <br /> <br /> Com funcionalidade similar ao que foi mostrado no painel AS View com o Grafana, a interface WebUI original do SNAS.io provê uma visibilidade geral do AS numa relação &quot;Top 20&quot;.<br /> [[Arquivo:Bpf-gerbgp-snastop20.png|centro|miniaturadaimagem|800x800px|Caso de uso: Top 20 prefixos anunciados e removidos com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: análise de segurança com a WebUI nativa do SNAS.io''' <br /> <br /> Com visibilidade similar ao que foi demonstrado em alguns painéis anteriores, esta facilidade permite uma rápida visualização acerca da quantidade de ASNs com problemas de validação do RPKI.<br /> [[Arquivo:Bpf-gerbgp-snastsecurity report.png|centro|miniaturadaimagem|800x800px|Caso de uso: análise de segurança com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snasrpki drill down.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatório de violação de RPKI com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: integração e visibilidade com BGP Link-State (BGP-LS)'''<br /> <br /> Para atender à necessidade de aplicações que exijam visibilidade topológica em áreas IGP ou mesmo em sistemas autônomos, uma AFI/SAFI para o BGP foi definida para permitir que este protocolo carregue em si as informações detalhadas sobre os estados de links, ou seja, a topologia da rede é codificada nos NLRI e as propriedades de objetos são codificadas em atributos do BGP-LS. Esta função do SNAS.io permite mostrar os detalhamentos topológicos transportados pelo BGP para que engenheiros de rede compreendam como melhor otimizar o fornecimento de determinados perfis de conteúdos.<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate map traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate SPF and traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: relatórios por Sistema Autônomo com a WebUI nativa do SNAS.io'''<br /> <br /> Como o próprio nome sugere, por esta interface podemos informar um número de AS e obtermos informações detalhadas incluindo os registros correspondentes das bases IRR, os prefixos originados pelo ASN pesquisado, e, conforme o entendimento do BGP, a relação de upstreams e downstreams daquele ASN.<br /> [[Arquivo:As view.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatórios por AS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> <br /> ==== Caso de uso: monitoramento, analíticos e big data com o Streaming Network Analytics System (SNAS/openBMP) em combinação com o Platform for Network Data Analytics (PNDA) ====<br /> A combinação do PNDA com o SNAS funciona como uma espécie de &quot;''unha e carne''&quot;, pois agrega muitas facilidades que trazem à tona os padrões de visibilidade e transparência acerca do comportamento geral do BGP, em particular as métricas que mais nos preocupam no cotidiano para a tomada de decisões estratégicas. O combo &quot;PNDA + SNAS&quot; abre as portas do '''''big data''''' para as necessidades de BGP ou do roteamento do AS propriamente dito!<br /> <br /> Nesta solução, o SNAS captura os eventos BGP dos roteadores com o uso do ''BGP Monitoring Protocol'' (BMP), exatamente conforme demonstrado anteriormente, só que, em seguida, o SNAS encaminha os eventos coletados via ''Logstash'' para o cluster PNDA através de uma interface que o SNAS mantém com o Kafka - daí uma das aplicabilidades de termos inserido o Kafka neste contexto. O HDFS do PNDA oferece a capacidade de registrar e manter grandes quantidades de dados históricos de eventos, portanto a solução é bem escalável. Na sequência, uma aplicação baseada no Spark cria as consultas que são executadas sobre os dados, extraindo as informações desejadas. Os resultados são então armazenados no componente HBase do PNDA e expostos por meios de uma API REST, onde os usuários/administradores poderão usar uma interface Web amigável para visualizar estes resultados.<br /> <br /> Para os propósitos aqui discutidos, o PNDA executa os seguintes procedimentos com as suas respectivas tecnologias embarcadas:<br /> * Entrada de dados por uma infinidade de opções, incluindo '''''Logstash''''', '''''Open Daylight''''', '''''Bulk Ingest''''' tool, '''''SNAS.io''''', '''''SNMP''''', '''''pmacct''''', '''''Cisco IOS XR Telemetry''''', etc.<br /> * Distribuição de dados por '''''Apache Kafka''''' e '''''Zookeeper'''''.<br /> * Processamento de stream em alta velocidade com '''''Spark Streaming'''''.<br /> * Processamento em lote de alto volume com '''''Spark'''''.<br /> * Exploração de dados de forma livre com o '''''Jupyter'''''.<br /> * Consulta estruturada sobre big data com '''''Impala'''''.<br /> * Manipulação de séries temporais com '''''OpenTSDB''''' e '''''Grafana'''''.<br /> O PNDA é bastante sofisticado no que diz respeito às tecnologias que são disponibilizadas. Uma instalação padrão inclui os seguintes:<br /> * '''''SaltStack:''''' é um software de código aberto baseado em Python para automação de TI orientada a eventos, execução remota de tarefas e gerenciamento de configurações.<br /> * '''''OpenStack Heat templates:''''' o Heat implementa um mecanismo de orquestração para ativar vários aplicativos de nuvem compostos com base em modelos na forma de arquivos de texto que podem ser tratados como código.<br /> * '''''AWS CFN templates:''''' o AWS CloudFormation oferece uma linguagem comum para modelar e provisionar recursos de aplicativos da AWS e terceirizados em um ambiente de nuvem.<br /> * '''''Apache Kafka:''''' é literalmente a &quot;porta da frente&quot; para a entrada dos fluxos dados originados pelos equipamentos da rede.<br /> * '''''Bulk Ingest:''''' atuando como alternativa ao Kafka para acomodar cenários de migração de dados existentes para o PNDA.<br /> * '''''Zookeeper for Kafka:''''' é utilizado pelo Kafka para descoberta e requisições de busca junto aos brokers referentes às partições que deseja consumir.<br /> * '''''JMX Proxy:''''' usado para, dentre outras coisas no PNDA, a exposição de todos os atributos MBean disponíveis em uma determinada JVM por meio de uma simples solicitação HTTP.<br /> * '''''Apache Impala:''''' atuando como um mecanismo de execução paralelo para consultas SQL com acesso de baixa latência e exploração interativa de dados no HDFS e HBase. O Impala permite que os dados sejam armazenados em formato bruto, com a agregação realizada no momento da consulta, sem a necessidade de agregação inicial de dados.<br /> * '''''CMAK (aka &quot;Kafka Manager&quot;):''''' como ferramenta de gerenciamento de clusters Kafka.<br /> * '''''ELK''''' (Logserver)<br /> ** '''''Elasticsearch:''''' um dos componentes da arquitetura de logs empregada pelo PNDA.<br /> ** '''''Logstash:''''' um dos componentes da arquitetura de logs empregada pelo PNDA, usado para receber dados de inúmeras fontes, transformação e compartilhamento de dados.<br /> ** '''''Kibana:''''' um dos componentes da arquitetura de logs empregada pelo PNDA, atuando como plugin de visualização de dados do Elasticsearch.<br /> * '''''Jupyter Hub''''' e '''''Jupyter Notebook:''''' atua como um aplicação que permite criar e compartilhar documentos que contêm código ativo, equações, visualizações e texto explicativo. No PNDA, ele suporta a exploração e apresentação de dados do HDFS e HBase.<br /> * '''''OpenTSDB:''''' atua como um banco de dados escalável de séries temporais que permite armazenar e fornecer grandes quantidades de dados de séries temporais, sem perder granularidade. <br /> * '''''Grafana:''''' atua como construtor de gráficos e painéis para visualizar métricas de séries temporais do PNDA.<br /> * '''''Anaconda:''''' o Anaconda é uma distribuição gratuita e de código aberto das linguagens de programação Python e R para computação científica. Usado para diversas funções do PNDA.<br /> * '''''Consul.io:''''' para gerenciamento de endpoints e descoberta de serviços.<br /> * '''''Apache Flink:''''' atua como uma estrutura e um mecanismo de processamento distribuído para cálculos com estado em fluxos de dados ilimitados e limitados. O Flink foi projetado para executar em todos os ambientes comuns de cluster, executar cálculos na velocidade da memória e em qualquer escala.<br /> * '''''Apache Knox:''''' atua como gateway de aplicativo para interagir com as APIs REST e as UIs das implantações do Apache Hadoop, fornecendo um ponto de acesso único para todas as interações REST e HTTP com os clusters do Apache Hadoop.<br /> O PNDA de fato propõe-se a ser uma plataforma escalável e aberta de big data, com a finalidade de suportar análises operacionais e de inteligência de negócios para redes e serviços, e não sendo uma ferramenta restrita ou específica apenas para ambientes ISP. Algumas destas tecnologias supracitadas dependem de qual distribuição Hadoop for escolhida, sendo que o PNDA pode ser implantado usando Cloudera CDH ou Hortonworks HDP. Dependendo de qual for a distribuição, componentes/pacotes adicionais serão exigidos (ex:, para uma instalação baseada no Cloudera CDH PNDA, são exigidos também Apache Avro + Crunch + DataFu + Hadoop + HBase + Hive + Hue + Impala + Kite SDK + Mahout + Parquet + Pig + Spark + Sqoop/Sqoop2 + ZooKeeper, e outros). <br /> A ilustração a seguir mostra as tantas possibilidades de recebimento de eventos e streaming com o PNDA. Note que o SNAS.io é mencionado como uma das formas de recebimento de dados:<br /> [[Arquivo:Bpf-gerbgp-pnda.jpg|centro|miniaturadaimagem|900x900px|Visão geral do PNDA (Fonte: PNDA.io)]]<br /> <br /> A integração do ''OpenBMP'' ou ''SNAS'' com o ''PNDA'' poderá ser feita usando o ''Logstash''. Conforme já demonstrado anteriormente, os roteadores monitorados enviam as mensagens BMP para o ''OpenBMP/SNAS'', o qual envia estes dados para o ''Kafka''. Por sua vez, o barramento de dados do ''Kafka'' oferece a muitos aplicativos em lote ou streaming a capacidade de acessar feeds BMP existentes de qualquer número de roteadores. A proposta aqui então é a de produzir estes dados BMP no coletor ''OpenBMP/SNAS'' e encaminhá-los para o ''Kafka'' para que possam ser consumidos pelo ''Logstash'' da instalação PNDA. Esta integração está comentada neste link&lt;nowiki/&gt;https://github.com/SNAS/openbmp/blob/master/docs/LOGSTASH.md.<br /> <br /> A interação dos administradores da rede com estes dados poderá ser feita por APIs ou por qualquer outra aplicação que seja pensada para consumir estes dados.<br /> <br /> '''Caso de uso: monitoramento, analíticos e big data com SNAS.io e PNDA.io'''<br /> <br /> Caso você ainda esteja se questionando sobre as vantagens e benefícios de incorporar conceitos de telemetria para o monitoramento do seu BGP, talvez esta seção do artigo possa convencê-lo. Um dos maiores atrativos da telemetria baseada orientada a modelos (eventos + streaming periódico) é que permite obter dados em tempo real e com flexibilidade e granularidade muito superiores aos modelos de gerenciamento tradicionais, já discutidos previamente neste artigo. Quando combinando este modelo de gerenciamento com as soluções certas baseadas em software, você passa a ter acesso a praticamente tudo aquilo que você não conseguia conceber com os modelos tradicionais.<br /> <br /> Nunca foi tão viável entrar no mundo de analíticos e big data com foco nas questões de rede, neste caso aqui o BGP. A combinação de SNAS.io e PNDA.io pode destravar a inteligência que está faltando na grande maioria dos Sistemas Autônomos que correspondem aos ISPs e pequeno e médio portes. Ou seja, big data não é mais luxo de grandes operadores de redes!<br /> <br /> Dentre tantas ações viáveis com big data sobre o BGP, é possível classificar e filtrar todo o histórico de anúncios originados e anunciados por AS, o que por sua vez permite compreender melhor como as mudanças realizadas por upstreams podem estar afetando a convergência do roteamento BGP do seu AS. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda1.png|centro|miniaturadaimagem|900x900px|Análise de prefixos originados e anunciados por AS (Fonte: pnda.io)]]Outra possibilidade é poder consultar informações detalhadas sobre qualquer AS que estiver mencionado em qualquer anúncio que tenha sido registrado e armazenado na base de dados da solução, e isto, por si só, já economiza um tempo bastante razoável, pois você não precisaria ter que recorrer a sistemas ou websites externos para obter estas informações. E sem contar que estas informações sobre estes AS podem ser processadas para representar uma infinidade de analíticos e relatórios adicionais. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda2.png|centro|miniaturadaimagem|900x900px|Informações detalhadas por AS (Fonte: pnda.io)]]Uma das necessidades mais críticas no que diz respeito aos projetos mais elaborados de engenharia de tráfego com o BGP é contar com uma visibilidade bastante aprofundada das relações entre os Sistemas Autônomos na visão do AS da sua empresa, pois isto é o que permite estudar a cadeia de relações com propriedade e conduzir - com auxílio de outros procedimentos - os estudos sobre as matrizes de tráfego, dentre outras coisas. A obtenção destas informações pelos métodos tradicionais é praticamente inviável. Por exemplo, não é viável com SNMP. Já por CLI/Scripting visando a recuperação, ''parsing'' e armazenamento destas informações numa base de dados para consultas posteriores, enfim, seria ao mesmo tempo frágil, pouco escalável, e com elevados requerimentos computacionais, ou seja, praticamente inviável. Por sua vez, o monitoramento do BGP por telemetria, combinado com soluções de software especializadas no processamento e tratamento destes dados, habilita todo um big data sobre como o AS da sua empresa se relaciona com os demais AS da Internet. Com funções inteligentes de pesquisa de baixíssimo esforço você poderá compreender como o seu AS se relaciona com os demais AS da Internet. A ilustração a seguir mostra isso:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda3.png|centro|miniaturadaimagem|900x900px|Análise de relações entre os AS associados aos anúncios mantidos na base de dados (Fonte: pnda.io)]]Outra aplicação muito útil: imagine que você precise estudar os caminhos de AS_PATH associados a determinados destinos, por exemplo, entre dois ASs quaisquer. Como você faria isto pelas vias normais? Você simplesmente teria que acessar diversos roteadores e estudar &quot;na unha&quot;, um por um, todos os anúncios em combinação com cada opção de caminho entre a origem e o destino desejados. Se você conhece bem o BGP e atua em uma operadora ou ISP de maior porte, certamente já teve que fazer este tipo de trabalho um bocado de vezes. Demanda muito tempo, foco, atenção! Pois bem, numa plataforma de analíticos &amp; big data com dados de BGP você não teria dificuldade em estudar todos os caminhos entre a origem e o destino pretendidos, e com &quot;ridículos&quot; cliques identificar quais são os caminhos ativos, quais são os caminhos de menor comprimento de AS_PATH, e quais são os caminhos de maior comprimento de AS_PATH. E tudo isto numa fração de minuto! Isto é demonstrado na ilustração a seguir:[[Arquivo:Bpf-gerbgp-pnda4.png|centro|miniaturadaimagem|900x900px|Análise caminhos &quot;ativo, mais curto, mais longo&quot; entre dois AS (Fonte: pnda.io)]]Nem tudo são flores na parte de segurança do BGP, em especial anomalias associadas a prefixos e atributo AS_PATH. Uma vez que todas as informações do BGP estão armazenadas em bases de dados bastante otimizadas para analíticos, com pouco esforço você conseguirá identificar problemas relacionados à segurança do BGP. A ilustração a seguir demonstra esta facilidade:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda5.png|centro|miniaturadaimagem|900x900px|Análise de anomalias associadas a prefixos e AS_PATH (Fonte: pnda.io)]]Mais uma funcionalidade interessante aqui: você poder estudar cada ASN identificado na base de dados da solução, consultar informações detalhadas de casa ASN, obter um histórico dos anúncios enviados e recebidos de/para cada ASN, estudar a lista de AS_PATH associada aos anúncios, pesquisar por problemas que podem estar assolando o roteamento BGP do seu AS, dentre outras necessidades.<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda6.png|centro|miniaturadaimagem|900x900px|Análise de caminhos por AS (Fonte: pnda.io)]]<br /> <br /> Por ser uma solução em grande parte baseada em software de código aberto, entendo que o potencial de customização seja absurdo. Na mão de times de desenvolvimento experientes, a sua empresa poderá customizar a solução como bem desejar, incorporando elementos diversos, ajustando, refinando, até que obtenha-se os resultados desejados pelas diversas áreas internas do negócio que possam beneficiar-se com as funções, relatórios e analíticos do monitoramento BGP.<br /> <br /> Para concluir o tema SNAS.io + PNDA.io, caso você queira experimentar uma versão minimalista (com algumas limitações e não recomendado para ambientes de produção), recomendo o [https://github.com/pndaproject/red-pnda Red PNDA]! Você poderá baixar a OVA e rodá-la como uma máquina virtual em uma sandbox para explorar e aprender a desenvolver sobre um ambiente PNDA propício.<br /> <br /> === Conclusão do artigo e próximos passos ===<br /> O tema gerenciamento por si só é algo absolutamente muito extenso, mesmo que eu tenha focado apenas no gerenciamento/monitoramento do BGP. Infelizmente, não há como realmente dissertar livremente sobre o tema em um único artigo. Todavia, está no radar de próximos artigos, aqui na wiki do BPF, conteúdos relacionados ao gerenciamento/monitoramento do BGP com os seguintes:<br /> * Aplicabilidades do ''Multi-Threaded Routing Toolkit'' (MRT) - &lt;nowiki&gt;RFC 6396&lt;/nowiki&gt; e &lt;nowiki&gt;RFC 8050&lt;/nowiki&gt;<br /> * Gerenciamento e monitoramento por telemetria com exemplos de soluções (ex: Cisco IOS XR Telemetry, Pipeline, e outros)<br /> * Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> * Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> * Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> * Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> Siga acompanhando os trabalhos do Brasil Peering Forum! Espero que você tenha curtido este artigo; divulgue-o!<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> [[Categoria:Roteamento]]<br /> [[Categoria:Infraestrutura]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Solucoes_para_o_gerenciamento_efetivo_do_bgp_em_um_sistema_autonomo&diff=2460 2020-05-25T03:19:37Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo ===<br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Todos os engenheiros de redes sênior que atuam em ISPs, ou em qualquer empresa séria que possua um Sistema Autônomo, compreendem a importância em estudar corretamente a farta quantidade de informações referentes às sessões e respectivas tabelas BGP, e não apenas na perspectiva da tabela BGP de seus próprios e respectivos ASNs, e sim estendendo estes estudos e tratamentos de dados na perspectiva de vários pontos de monitoramento, os quais incluem coletores, ''route views'', ''looking glasses'', e afins, espalhados pela Internet. Ou seja, como você (ou, neste caso, o seu ASN) vê o mundo ao seu redor, e como as várias partes do mundo (ASNs em suas respectivas regiões) vêem o seu ASN.<br /> <br /> Isto para sintetizar primariamente as iniciativas de prevenção dos dois principais tipos de incidentes envolvendo o roteamento de Internet, a saber: ''route leaks'' e ''prefix hijack''. Só que as necessidades de um ASN no que tange ao monitoramento de seu BGP vão bem além do que somente (embora gravíssimos) incidentes com ''route leaks'' e ''prefix hijacks'', para os quais, inclusive, já existem BCOPs específicas para prevenção e mitigação, como é o caso do &lt;nowiki&gt;RFC 7454&lt;/nowiki&gt; / BCP 194, BCP 38, BCP 185, e MANRS. Há muito mais coisas a serem observadas e tratadas com relação ao BGP do que apenas as questões de segurança.<br /> <br /> Ou seja, em adição às questões de segurança, o Sistema Autônomo/ASN precisa monitorar constantemente, dentre dezenas de objetos e métricas gerenciáveis, e seus respectivos KPIs, e de uma magnitude grande de componentes, o '''''&lt;u&gt;seu&lt;/u&gt; BGP''''' como um todo. Isto para que respostas possam ser fornecidas para sanear diversos desafios que vão além da segurança do roteamento daquele ASN (e estendendo-se para seu cone de clientes), tais como a escalabilidade, engenharia de tráfego com ênfase na redução inteligente de custos e com potencial aumento de qualidade de serviço (ex: fornecer conteúdo com menor latência ao mesmo tempo em que reduzindo custos com esta iniciativa); planejamento de capacidades, planejamento das métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, os padrões de convergência da rede, plano diretor de investimentos, desenvolvimento e manutenção da cesta de produtos e serviços com foco na capacidade e uso estatístico de recursos da rede, toda a parte financeira também, etc.<br /> <br /> Falando especificamente do BGP, os modelos &lt;u&gt;tradicionais&lt;/u&gt; de monitoramento possuem restrições: ''routeviews'' (com algumas exceções) e ''looking glasses'' não mantém históricos de informações sobre rotas (seja pelo prefixo direto ou pela expressão regular do atributo AS_PATH), consequentemente não se sabe o que aconteceu, quando e por quem. Além disto, uma sessão BGP somente anuncia as suas melhores rotas (''best path''), e esta informação pode ser obtida de um roteador por CLI ou outro procedimento, como o NETCONF, porém, novamente, sem dados históricos. O que algumas empresas fazem para compensar estas restrições dos modelos tradicionais com ferramentas vigentes é recorrer a soluções e sistemas que consigam manter estas informações numa base de dados que seja flexível, escalável e gerenciável, e que mantenha um histórico de mudanças sobre estes registros. Ou seja, construir e customizar sistemas específicos, ou adquirir um sistema comercial para este propósito. E que, preferencialmente, seja de fácil integração com outros sistemas (incluindo Sistemas de Suporte à Operação (OSS)).<br /> <br /> O que estou propondo aqui é ampliar os conceitos de ferramentas para o monitoramento efetivo do BGP: além de manter seus ''looking glasses'' e consultar ''route views'', onde aplicáveis, os ASN poderem manter as suas próprias bases de dados com históricos acerca de tudo o que ocorre com o BGP na perspectiva daquele ASN, de seu cone de clientes, além da sua relação com seus upstreams de trânsito IP, sessões de peering e afins. Ou seja, não apenas o &quot;snapshot&quot; do que está acontecendo na hora, mas obter informações sobre prefixos e ASNs através de uma linha temporal e para atender diversos casos e aplicações técnicas e de negócios. É o que chamamos de &quot;'''''telemetria orientada a modelos'''''&quot;, que, nos projetos mais sofisticados e completos, combina ferramentas de &quot;telemetria baseadas em eventos&quot; (obtenção de dados por CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, BMP, etc.), e &quot;telemetria de streaming periódica&quot;, com monitoramento de diversos objetos relacionados à capacidade e dados estatísticos de consumo (latência, ''throughput'', processamento) por meios de diversas ferramentas e procedimentos. Interessante, não?<br /> <br /> Em suma, este artigo está centrado na dissertação de propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!<br /> <br /> ==== Observação importante: ====<br /> Se você estiver aguardando uma solução &quot;pronta&quot; ou com uma expectativa de que eu vá fornecer aqui uma &quot;receita de bolo&quot;, lamento muito, mas não é esta a intenção do artigo! Fornecerei aqui uma visão muito mais ampla deste contexto, e tentarei desmembrar este tópico empregando alguns conceitos de pesquisa aplicada e de desenvolvimento experimental. Entenda isto como um pontapé inicial para que você consiga adquirir os conhecimentos necessários para desenvolver seus próprios conceitos de adoção tecnológica, processual e instrumental, objetivando o gerenciamento e monitoramento do BGP de seu AS, e culminando na tomada de decisão de sua parte sobre uma ou mais das seguintes possibilidades:<br /> # Investimentos em soluções comerciais existentes, com potencial de customizações e integração com outros sistemas para o atendimento de necessidades específicas do seu negócio.<br /> # Desenvolvimento de sistemas com fábrica de software própria, atendendo a todos os modelos de gerenciamento desejados.<br /> # Adoção de ferramentas específicas para o atendimento de necessidades igualmente específicas, tais como soluções de código aberto ou até mesmo de ordem comercial.<br /> <br /> === Um &quot;abre-alas&quot; sobre a importância e missão dos sistemas de gerenciamento no geral ===<br /> Antes de começarmos, gostaria de comentar uma característica do meu trabalho e que afeta o meu julgamento por completo. Aqueles que me conhecem de longa data sabem que sou um tanto insistente em algumas das minhas análises, visões, conclusões e objeções. Para estas pessoas que me conhecem, quantas vezes já não ouviram o Leonardo Furtado citar a seguinte frase?&lt;blockquote&gt;''&quot;Muitos profissionais de ISP (incluindo alguns perfis de gestores) pecam na hora de investir e de tomar decisões importantes para seus negócios: adquirem soluções tecnológicas focando apenas ou principalmente nas necessidades de curto prazo, muitas vezes adotando soluções minimalistas, e centradas no fator de menor custo&quot;''&lt;/blockquote&gt;A relação desta frase com o artigo em questão é óbvia, e você entenderá melhor logo a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem que haja um propósito bem definido para as áreas do negócio que realmente importam. Muitas vezes a necessidade é muito óbvia ou específica, tais como &quot;monitorar o consumo de banda referente a uma interface conectada para um upstream de trânsito IP&quot;, o que é plenamente justificável, sem dúvidas, claro! No entanto, o maior problema não reside no objeto gerenciado em questão (monitoramento de banda, monitoramento de problemas de uma interface, processamento, etc.), e sim na ausência de analíticos associados aos objetos gerenciados pelas ferramentas em questão, as quais foram adquiridas pela organização (e seja lá quais tenham sido os critérios), e que foram implantadas pelo time de engenharia ou de operações. Em outras palavras: o software está &quot;lá&quot;, implantado, e sendo (sub)utilizado pelos operadores. Mas.. quais são os reais objetivos? Quais são os indicadores desejados? Quais são os ''thresholds''? Quais são as métricas gerenciáveis daquele componente, de cada componente? Como determinados ''thresholds'' e eventos associados àquele objeto impactam no meu negócio? Quais ações e tomadas de decisões executaremos para prevenir, mitigar e responder ao eventos fornecidos pelo gerenciamento acerca daquele objeto gerenciado? Como este objeto gerenciado participa do meu negócio e nas diversas áreas, centros de custo, e contextos, incluindo comercial, reputação, financeiro (capex, opex, fluxo de caixa, etc.), engenharia (capacidade, disponibilidade, resiliência, consumo de recursos, tráfego, etc.), operações, fornecedores, etc.? A lista é grande.<br /> <br /> Com 25 anos de profissão, o que mais vi em toda a minha carreira e em muitas empresas que visitei foram soluções de gerenciamento inteiras praticamente &quot;encalhadas&quot;, subutilizadas! Sistemas complexos e por muitas vezes interessantes que, de diversas funções e capacidades disponíveis, são extraídos apenas recursos pontuais e, mesmo assim, sem que analíticos e dados importantes pudessem ser coletados, tratados e consumidos pelas áreas relevantes do negócio para que estas pudessem aproveitar estas informações para algo realmente útil, seja algo visando aprimorar a parte técnica/tecnológica ou a parte do negócio propriamente dito.<br /> <br /> Outra forma de sintetizar isto: ''&lt;u&gt;em muitas empresas não há efetivamente um projeto prevendo a construção (ou adoção/contratação) de sistemas de gerenciamento&lt;/u&gt;''. O gerenciamento efetivo ou adequado é frequentemente a parte mais negligenciada da infraestrutura.<br /> <br /> Dissertar amplamente sobre isto está fora do escopo deste artigo, mas a mensagem que gostaria de deixar aqui é bem simples: tratando-se de sistemas de gerenciamento, e não importando para qual finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), procure conduzir um projeto técnico consistente e específico para este(s) sistema(s), e que vá identificar e documentar os seguintes:<br /> * Em alinhamento com o projeto de infraestrutura vigente, incluindo todo o parque tecnológico presente (hardware e software), quais são as necessidades da área técnica da empresa, assim como de possíveis outras áreas interessadas?<br /> * Quais problemas estamos sofrendo no momento e/ou que gostaríamos de evitar?<br /> * Como cada um destes problemas, incidentes ou circunstâncias impacta nos negócios da empresa? É possível quantificar os prejuízos, quaisquer que sejam (reputação, multas, reparação, cancelamento de contratos, perda de receitas, aumento de custos imprevistos, etc.)? E quais áreas internas do negócio são impactadas? É viável fazer esta associação?<br /> * Quais deverão ser os objetos gerenciados?<br /> * Quais são as facilidades de gerenciamento suportadas pelo meu parque tecnológico (HW e SW)? E quais são as capacidades demandadas sobre cada um destes recursos?<br /> * Das tecnologias ou recursos disponíveis e suportados pela infraestrutura, quais são as melhores e mais aderentes opções para o atendimento de cada objeto gerenciado identificado? (prós e contras, matriz funcional de qualidade, etc.)<br /> * Quais deverão ser os indicadores e métricas para estes objetos gerenciados quando utilizando-se dos recursos ou facilidades de gerenciamento identificados como mais aderentes para os meus propósitos?<br /> * Como as áreas internas do negócio, onde aplicáveis, consumirão estes analíticos, indicadores e métricas?<br /> * Quais processos deverão ser estabelecidos para ações de prevenção, mitigação e reação quanto aos ''thresholds'' dos objetos gerenciados?<br /> * Dentre muitas questões.<br /> Somente após responder estas perguntas e planejar toda a iniciação do projeto de adoção de solução de gerenciamento é que você conseguirá encontrar a solução ideal, a(s) &quot;ferramenta(s)&quot;, e fazendo isto com critérios consistentes nos requisitos de facilidades, recursos, integração, custos, etc. Entendo que esta deva ser a aderência a ser pensada e projetada, assim como entendo que você precisará instaurar os processos primeiro para depois chegar a estas conclusões. Dica: para o tema &quot;processos&quot;, confira o artigo [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]! <br /> <br /> A implantação e operação de sistemas de gerenciamento, quaisquer que sejam as finalidades, deve passar primeiro por um plano de projeto que vá identificar todas as questões envolvendo necessidades, desafios, métricas desejadas, capacidades e qualidades demandadas, os objetos a serem gerenciados, as facilidades e recursos necessários, como os dados serão coletados, processados e armazenados, e como a organização como um todo deverá consumir e tirar proveito destes dados para aprimorar seus indicadores. <br /> [[Arquivo:Bpf-gerbgp-requisitos.png|centro|miniaturadaimagem|900x900px|&quot;Carroça não anda na frente de boi&quot;: exercite o planejamento antes de sair implantando ferramentas, e usufrua de melhores resultados!]]<br /> <br /> === Por que um ASN precisa investir no gerenciamento de seu ambiente BGP? ===<br /> Ou '''''quais problemas poderão ser resolvidos com o gerenciamento efetivo do BGP em seu ASN'''''?<br /> <br /> &lt;u&gt;A sequência deste artigo estará centrada quase que integralmente no &quot;BGP&quot;&lt;/u&gt; e possivelmente citarei outros elementos que participam diretamente do funcionamento deste. Ou seja, não pretendo realmente dissertar sobre necessidades, objetivos e requisitos gerais envolvendo disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isto não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?<br /> <br /> Suponhamos que as áreas de engenharia e operações de um ISP cheguem a um consenso de que é necessário ter ampla visibilidade e acesso à informações relevantes especificamente relacionadas ao BGP para que sejam discutidas formas de antecipar e mitigar riscos, e responder aos diversos tipos de incidentes relacionados às questões de segurança, disponibilidade, performance, ou seja, o SLA em geral, assim como o planejamento de capacidades e a engenharia financeira do negócio. Se tivéssemos que exercitar este consenso entre estas duas áreas, quais teriam sido alguns dos diversos critérios factíveis? Para este exercício hipotético, proponho que estes requisitos sejam devidamente categorizados da seguinte forma para melhor compreensão e dissertação de casos:<br /> * '''Segurança do roteamento BGP'''<br /> * '''Segurança do plano de controle da rede'''<br /> * '''Segurança contra ataques de negação de serviços'''<br /> * '''instabilidades do BGP'''<br /> * '''Engenharia de tráfego'''<br /> * '''Planejamento de capacidades'''<br /> * '''Reputação e conformidade'''<br /> O seu trabalho, na condição de engenheiro de rede ou arquiteto de soluções, deverá ser a busca por respostas para iniciar este planejamento!<br /> [[Arquivo:Bpf-gerbgp-planejamento.png|centro|miniaturadaimagem|900x900px|Brainstorming para o planejamento de uma solução de gerenciamento específica para o BGP]]<br /> Dissertemos um pouco mais sobre estes caso hipotético através da exposição de conceitos envolvendo '''''Necessidades''''', '''''Requisitos''''', '''''Problemas ou desafios a serem resolvidos''''' pelas organizações que operam um Sistema Autônomo, sendo provedores de acesso à Internet (ISP) ou não:<br /> {| class=&quot;wikitable&quot;<br /> |+<br /> Matriz de Necessidades, Requisitos e Desafios a serem Superados para a Demanda &quot;BGP&quot; do ISP<br /> !Categoria<br /> !Necessidade<br /> !Requisito<br /> !Problemas ou desafios a serem resolvidos<br /> !Partes interessadas<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento da segurança do roteamento BGP'''<br /> |Deteção e mitigação de prefixos Bogons<br /> |Identificação e mitigação de prefixos Bogons, Maritans e não alocados<br /> |<br /> * Evitar o recebimento e propagação de rotas referentes a prefixos Bogons, Martians e Unallocated<br /> * Aumentar a reputação do Sistema Autônomo, como parte de boas práticas para a prevenção de incidentes de segurança associados a anúncios bogons.<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de vazamento de rotas e sequestro de prefixos do ASN<br /> |Identificação e mitigação de route leaks<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Assegurar que o ASN não crie ou gere route leaks, assim como assegurar que route leaks não sejam aceitos a partir de sessões de clientes, peering e trânsito<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Encurtar o tempo de deteção de incidentes envolvendo route leaks<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de route leaks<br /> |NOC, Engenharia<br /> |-<br /> |Identificação e mitigação de sequestro de prefixos (prefix hijacks)<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Evitar que o ASN não sequestre prefixos, assim como recusar o recebimento de quaisquer anúncios com ROA (RPKI) e/ou IRR inválidos<br /> * Encurtar o tempo e detecção de incidentes envolvendo o sequestro de prefixos<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de sequestro de prefixos<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de abusos contra recursos do BGP<br /> |Controle de recebimento de anúncios de ASNs vizinhos<br /> |<br /> * Evitar abusos e possíveis impactos relacionados à capacidades e escassez de recursos<br /> * Evitar que ASNs de clientes anunciem de forma acidental ou maliciosa uma quantidade de prefixos superior à estimada ou autorizada<br /> * Evitar abusos com a desagregação através de anúncios excessivamente específicos recebidos de clientes, peering e trânsito<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> |Controle de abuso de AS-Path Prepending<br /> |<br /> * Evitar que o ASN do ISP, assim como ASNs vizinhos e o restante da Internet, sofram possíveis impactos e instabilidades quanto à prefixos com excesso de AS-Path Prepending atrelado aos anúncios<br /> * Evitar abusos quanto ao recebimento de rotas BGP que contenham AS-Path Prepending excessivos (uma forma de ''Self-Inflicted Vulnerability'')<br /> * Encurtar o tempo de detecção de incidentes desta natureza.<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da segurança do plano de controle da rede'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de incidentes de segurança contra o próprio BGP<br /> |Controle de vulnerabilidades sobre as mensagens do BGP<br /> |<br /> * Evitar indisponibilidades e outros tipos de incidentes que possam ser provocados com a exploração das mensagens do BGP (conforme (3.1. Vulnerabilities in BGP Messages do &lt;nowiki&gt;RFC 4272&lt;/nowiki&gt;)<br /> * Evitar a manipulação e injeção maliciosa de atributos sobre os anúncios por mensagens ''Update'' do BGP<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de exploração destas vulnerabilidades<br /> |SOC, NOC. Engenharia<br /> |-<br /> |Controle de incidentes de segurança lançados diretamente contra as sessões BGP<br /> |<br /> * Evitar que as sessões BGP sejam atingidas diretamente por técnicas maliciosas que visam desde o downtime/indisponibilidade, sequestro de sessões, injeção de informações errôneas<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de ataques lançados contra os processos BGP<br /> |SOC, NOC, Engenharia<br /> |-<br /> |'''Gerenciamento da segurança contra negação de serviços'''<br /> |Detecção e mitigação contra ataques DDoS<br /> |Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS<br /> |<br /> * Evitar ou atenuar efeitos adversos de indisponibilidades, instabilidades, impactos severos no SLA de clientes, prejuízos financeiros de grandes proporções, e danos na reputação da empresa<br /> * Evitar a injeção de informações maliciosas na tabela BGP que permitam livre comunicação entre hosts infectados em suas botnets<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e mitigação de DDoS<br /> |SOC, NOC, Engenharia<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento de instabilidades do BGP'''<br /> | rowspan=&quot;5&quot; |Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA<br /> |Detecção de oscilações de sessões BGP<br /> |<br /> * Evitar que ocorram instabilidades na prestação de serviços de acesso à Internet por conta de oscilações das sessões BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e problemas com as sessões BGP<br /> |NOC<br /> |-<br /> |Detecção de oscilações de rotas (route flaps)<br /> |<br /> * Evitar que ocorram indisponibilidades na comunicação com determinados serviços/destinos de Internet por conta de oscilações e intermitências quanto à convergência da tabela BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e oscilações de rotas BGP<br /> |NOC<br /> |-<br /> |Detecção de rotas eventualmente suprimidas por Dampening<br /> |<br /> * Evitar discrepâncias nas matrizes de tráfego e, de certa forma, atenuar a assimetria do roteamento IP, ''blackhole'' ou ''routing loops'' por conta da eventual supressão de rotas (dampening) executada no ASN local ou em vizinhos<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de supressão de rotas BGP e como estes eventos afetam o comportamento da rede e a disponibilidade de serviços<br /> |NOC<br /> |-<br /> |Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces<br /> |<br /> * Evitar que determinados recursos tais como capacidade de enlaces, arquiteturas de roteadores (CPU, memória, FIB, etc.) fiquem subutilizados enquanto outros elementos fiquem sobrecarregados<br /> * Evitar gargalos nas operações e transações de rede, os quais podem provocar impactos no SLA<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção de gargalos e esgotamento de recursos<br /> |NOC, Engenharia<br /> |-<br /> |Planejamento e antecipação de cenários &quot;what if&quot;<br /> |<br /> * Evitar que manobras de configurações, incluindo modificações nas políticas de roteamento e ações de engenharia de tráfego provoquem distúrbios não antecipados<br /> * Antecipar impactos na convergência e disponibilidade da rede através de uma análise preditiva envolvendo cenários de falhas<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;4&quot; |'''Gerenciamento da engenharia de tráfego'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de impactos sobre os recursos de infraestrutura decorrentes de eventos pontuais na Internet<br /> |Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento<br /> |<br /> * Superar as limitações operacionais da empresa em função da escassez de informações e a falta de visibilidade sobre os fluxos de tráfego<br /> * Aprimorar as ações de dimensionamento de recursos de infraestrutura, tais como plataformas de switches e roteadores, além de enlaces de comunicação de dados<br /> * Aprimorar os resultados das ações de engenharia tráfego para fins de acomodar melhor as conversações da rede sobre os recursos disponíveis<br /> * Atenuar ou eliminar os desafios que provocam impactos sobre o SLA de assinantes<br /> * Fornecer analíticos, dados históricos e baselines relacionados às matrizes de tráfego, com histórico de consumo por ASN, peer, prefixo, protocolo de transporte, tipo de aplicação, marcações, atributos, etc.<br /> |Engenharia<br /> |-<br /> |Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas<br /> |<br /> * Reduzir os indicadores de MTTR e MDT associados aos eventos de falhas relacionadas ao BGP<br /> * Reduzir os indicadores de reclamações por conta da violação de SLAs envolvendo indisponibilidades, latência, jitter, perda de pacotes, etc.<br /> * Reduzir os impactos provocados nas áreas internas do negócio que são destinadas ao interfaceamento com clientes, tais como comercial, atendimento a clientes, NOC, jurídico, etc.<br /> * Fornecer analíticos, dados históricos e baselines referentes aos impactos decorrentes de falhas para alimentar as tomadas de decisão e para nortear os investimentos e processos de mitigação<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Aprimoramento de SLA<br /> |Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP<br /> |<br /> * Reduzir impactos não antecipados sobre ações de engenharia de rede e de tráfego executadas pela área de engenharia ou de operações da empresa<br /> * Aprimorar as tomadas de decisão acerca das políticas de roteamento para o atendimento dos modelos de interconexão privado e público<br /> * Aprimorar as tomadas de decisão para as políticas de roteamento de acordo com os modelos de interesse de tráfego (''hot potato'', ''cold potato'', e outras diretrizes) sobre os regimes de interconexão <br /> * Fomentar ações racionais de engenharia de tráfego para equilibrar as métricas de SLA (latência, jitter, disponibilidade) sobre os custos (opex) de cada enlace de transporte e de de cada acordo de troca de tráfego<br /> |Engenharia<br /> |-<br /> |Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como MPLS TE e SR-TE<br /> |<br /> * Assegurar aderência quanto ao mapeamento do tráfego sobre os recursos locais do AS, prevendo simultaneamente as métricas de desempenho e a relação de custos de infraestrutura para a sustentação de SLAs<br /> * Promover a redução racional de custos através da associação de classes de tráfego ou de matrizes de conversação sobre os enlaces e sessões associadas às métricas de SLA de cada caso<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;3&quot; |'''Gerenciamento da planejamento de capacidades'''<br /> | rowspan=&quot;3&quot; |Planejamento de capacidades com foco na redução racional de custos operacionais<br /> |Bilhetagem e tarifação de tráfego<br /> |<br /> * Determinação da matriz de tráfego em combinação com iniciativas de bilhetagem e tarifação para determinar rateio de custos de infraestrutura nas áreas internas do negócio<br /> * Fornecer métricas de utilização dos fluxos de tráfego de interesse sobre os recursos de transporte para identificar áreas de otimização de custos<br /> * Viabilizar a compreensão da participação de cada centro de custo / área interna do negócio quanto aos padrões de consumo e contribuições orçamentárias<br /> * Viabilizar e fomentar a derivação da política de preços de produtos e serviços destinados a clientes em função das matrizes de tráfego, interesses de tráfego e modelos de interconexão<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Dimensionamento de recursos de transporte e acordos de troca de tráfego<br /> |<br /> * Planejamento de capacidades de conexões do ISP com os acordos de troca de tráfego nos regimes de peering e trânsito IP, incluindo 95th percentil<br /> |Engenharia<br /> |-<br /> |<br /> * Dimensionamento de especificações, requisitos, recursos e capacidades das arquiteturas e demais componentes de infraestrutura a serem utilizados para a sustentação dos modelos de interconexão para os perfis de tráfego<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da reputação e conformidade'''<br /> |Conquistar níveis de excelência em conformidade<br /> |Deteção e mitigação de incidentes e situações não aderentes aos frameworks e boas práticas destinadas aos Sistemas Autônomos<br /> |<br /> * Fornecer analíticos e dados históricos que classifiquem as ocorrências de incidentes provocados por eventos previstos e imprevistos pelas políticas internas da empresa<br /> * Fornecer métricas auditáveis quanto os incidentes de segurança associados ao BGP<br /> |NOC, SOC, Engenharia<br /> |-<br /> |Conquistar níveis de excelência na reputação do Sistema Autônomo<br /> |Fornecimento de ferramentas para o compartilhamento de transparência e iniciativas de suporte com outros (demais) Sistemas Autônomos<br /> |<br /> * Manutenção de sistemas e bases de informação que divulguem, dentre outros, a política de roteamento da empresa, plano de communities, &quot;normas da casa&quot;, requisitos de segurança, requisitos de interconexão, modalidades de SLA, etc.<br /> * Manutenção de sistemas e bases de informação que forneçam os pontos de contato e suporte para as demandas associadas ao BGP e contextos periféricos do AS, tais como &quot;Abuse&quot;, &quot;Peering&quot;, &quot;NOC&quot;, e outros<br /> * Disponibilização de ferramentas de autosserviço para a redução do tempo de diagnóstico e identificação de problemas por parte de NOCs de outros Sistemas Autônomos, tais como Looking Glass e outros.<br /> * Promover aderência quanto às boas práticas citadas pelos objetivos &quot;''Coordination''&quot; e &quot;''Global Validation''&quot; do ''Mutually Agreed Norms for Routing Security'' (MANRS) <br /> * Fornecer analíticos acerca da utilização das ferramentas de autosserviço para identificar necessidades de mercado, técnicas, perfil dos visitantes, áreas de interesse e geração de novas oportunidades <br /> |NOC<br /> |}<br /> <br /> === Exemplos de soluções conhecidas para o atendimento das diversas necessidades e requisitos associados ao gerenciamento do Sistema Autonomo ===<br /> No que diz respeito aos conjuntos de necessidades e respectivos requisitos fornecidos na tabela anterior, eu particularmente compreendo que tratam-se de situações absolutamente reais. Ao projetar a tabela acima, em nenhum momento pensei especificamente ou diretamente nas possíveis soluções e ferramentas que pudessem ser empregadas para cada caso, ou seja, toda a linha de raciocínio foi de fato estabelecida sobre '''''necessidades + requisitos + problemas + desafios''''' que entendo que a maioria dos operadores de redes tenham interessem em lidar em suas operações cotidianas.<br /> <br /> Todavia, chegaria o momento em que precisaríamos traduzir isto para um plano definitivamente concreto, certo? Sim, precisaríamos identificar ferramentas que conseguissem fornecer resultados para cada uma das situações descritas na tabela anterior. E é justamente isto que tentarei fazer agora: num primeiro momento, &quot;espalhar na mesa&quot; o que temos no mercado hoje; as soluções existentes que podem ser usadas para executar estes casos e cumprir com estas necessidades. <br /> <br /> Note que as ferramentas associadas a cada tipo de requisito não fornecem apenas as funcionalidades para aquele requisito em questão: tomei a liberdade de fazer desta forma apenas para deixar claro que a ferramenta foi &quot;pensada&quot; após o par &quot;necessidade + requisito&quot; ter sido identificado e confirmado para o meu conceito de projeto. <br /> <br /> Está fora do escopo desta parte do artigo qualquer esforço de validação e dissertação de aderência qualitativa (&quot;''o quão bem a ferramenta X executa e atende as necessidades, requisitos, problemas, desafios...''&quot;), assim como promover qualquer comparativo entre as opções mencionadas (&quot;''qual é a melhor ferramenta para a necessidade X?''&quot;).<br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança do roteamento BGP<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação e mitigação de prefixos Bogons, Martians e não alocados'''<br /> | rowspan=&quot;3&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://radar.qrator.net/ RADAR by QRATOR]<br /> * [https://team-cymru.com/community-services/bogon-reference/ Team Cymru fullbogons]<br /> |-<br /> |'''Identificação e mitigação de route leaks'''<br /> |-<br /> |'''Identificação de sequestro de prefixos'''<br /> |}<br /> O &lt;nowiki&gt;RFC 7908&lt;/nowiki&gt; (''Problem Definition and Classification of BGP Route Leaks'') descreve com bastante propriedade a caracterização e tipificação dos incidentes denominados route leaks, enquanto o draft-ietf-grow-route-leak-detection-mitigation-02 (''Methods for Detection and Mitigation of BGP Route Leaks'') propõe mecanismos de detecção e mitigação destes incidentes. Está fora do escopo deste artigo a dissertação sobre route leaks.<br /> <br /> Em adição, diversos artefatos contendo recomendações para a mitigação de prefix hijack foram produzidos, dentre eles o BCP 185 (''Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)''), &lt;nowiki&gt;RFC 7682&lt;/nowiki&gt; (''Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration''), &lt;nowiki&gt;RFC 2650&lt;/nowiki&gt; (''Using RPSL in Practice''), e o &quot;''Action 1: Prevent propagation of incorrect routing information''&quot; do Mutually Agreed Norms for Routing Security (MANRS). A dissertação sobre prefix hijack está fora do escopo deste artigo.<br /> <br /> As ferramentas comentadas na tabela acima podem ser usadas para fornecer dados e até mesmo, em alguns casos, prover algum grau de automação na resposta de incidentes envolvendo route leaks, prefix hijacks e outras situações. Outra possibilidade bastante interessante é projetar integrações entre estas ferramentas/serviços por meios as APIs disponibilizadas. Nos exemplos indicados acima, a [https://developer.thousandeyes.com/v6/ ThousandEyes fornece APIs] que podem ser aproveitadas para integrações com outros sistemas, assim como podem ser consideradas as [https://portal.bgpmon.net/bgpmonapi.php APIs do BGPmon da Cisco], [https://api.qrator.net/ APIs da QRATOR], etc. <br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança e instabilidades do roteamento BGP <br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de recebimento de anúncios de ASNs vizinhos'''<br /> | rowspan=&quot;5&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://bgpstream.caida.org/ BGPStream]<br /> * [https://share.zabbix.com/search?searchword=BGP&amp;search_cat=1 Zabbix com plugins compatíveis com estas necessidades]<br /> |-<br /> |'''Controle de abuso de AS-Path Prepending'''<br /> |-<br /> |'''Detecção de oscilações de sessões BGP'''<br /> |-<br /> |'''Detecção de oscilações de rotas (route flaps)'''<br /> |-<br /> |'''Detecção de rotas eventualmente suprimidas por Dampening'''<br /> |}<br /> Entendo que as ferramentas indicadas na tabela acima forneçam as funcionalidades devidas para que o administrador do Sistema Autônomo possua meios de identificar e reagir contra uma diversidade de situações envolvendo sessões e anúncios do protocolo BGP. <br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento engenharia de tráfego e planejamento de capacidades<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento'''<br /> | rowspan=&quot;7&quot; |<br /> * [https://www.telcomanager.com/trafip-analise-de-trafego/ TRAFip]<br /> * [https://www.noction.com/intelligent-routing-platform-bgp-network-optimization Noction IRP]<br /> * [https://www.blueplanet.com/products/route-optimization.html Ciena BluePlanet ROA]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/crosswork-network-automation/datasheet-c78-740228.html Cisco Crosswork Network Insights]<br /> * [https://www.manageengine.com/products/netflow/ ManageEngine NetFlow Analyzer]<br /> * [https://developer.cisco.com/docs/wan-automation-engine/#!overview/cisco-wan-automation-engine Cisco WAE em combinação com XTC]<br /> |-<br /> |'''Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas'''<br /> |-<br /> |'''Bilhetagem e tarifação de tráfego'''<br /> |-<br /> |'''Dimensionamento de recursos de transporte e acordos de troca de tráfego'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como BGP-LS, MPLS TE e SR-TE'''<br /> |-<br /> |'''Planejamento e antecipação de cenários &quot;what if&quot;'''<br /> |}<br /> A compreensão dos fluxos de tráfego, tanto na rede do próprio AS quanto nas conexões com os AS vizinhos, é algo muito importante para que o provedor consiga tomar as decisões corretas em algumas esferas técnicas do projeto e da operação cotidiana. Afinal de contas, para que seja possível o dimensionamento correto de recursos que acomodarão seus assinantes e respectivos serviços, o provedor precisa ter as informações necessárias para concluir este planejamento de capacidades, a engenharia de tráfego, e as questões de engenharia de redes tais como a disponibilidade, atrelada aos padrões de redundância, resiliência e métricas de confiabilidade, e em alinhamento com o projeto técnico e o plano de negócios. As ferramentas mencionadas na tabela acima possuem funcionalidades que cumprem bem com estes requisitos.<br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento da segurança do plano de controle da rede e segurança contra negação de serviços<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de vulnerabilidades sobre as mensagens do BGP'''<br /> | rowspan=&quot;4&quot; |<br /> * Ferramentas e soluções de detecção e prevenção de intrusão<br /> * [https://www.andrisoft.com/software/wanguard Andrisoft Wanguard]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://br.netscout.com/arbor-ddos Arbor para Operadoras]<br /> * [https://wiki.brasilpeeringforum.org/w/UTRS_Registro_e_Configuracao Team Cymru UTRS]<br /> |-<br /> |'''Controle de incidentes de segurança lançados diretamente contra as sessões BGP'''<br /> |-<br /> |'''Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS'''<br /> |-<br /> |'''Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces'''<br /> |}<br /> Tão importante quanto disponibilidade, performance e visibilidade geral dos componentes associados ao funcionamento do BGP em um Sistema Autônomo, é o gerenciamento da segurança da infraestrutura como um todo, sendo que, neste caso, as questões mais diretamente ao roteamento do AS. Na questão de segurança &quot;geral&quot; do AS, muita coisa já foi discutida em outros artigos já publicados na Wiki do Brasil Peering Forum, tais como o [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] e [[Boas Praticas para Melhorar a Seguranca de seu Provedor|Boas Práticas para Melhorar a Segurança de seu Provedor]]. As soluções mencionadas na tabela acima são indicadas para a mitigação de incidentes de segurança e ataques DDoS lançados contra a rede do ISP e/ou de seu cone de clientes.<br /> <br /> === Modelos e ferramentas orientadas ao gerenciamento do BGP ===<br /> Saindo um pouco desse discurso de &quot;necessidades, requisitos, desafios, etc,&quot;, serão discutidas a seguir as possibilidades em termos de modelos e ferramentas de gerenciamento que podem ser consideradas e utilizadas para os nossos interesses com o BGP. Pois, afinal de contas, não adianta vislumbrar um mundo perfeito ao melhor estilo &quot;''imagine all the people...''&quot; se não há formas efetivas de executarmos aquilo que nós desejamos, certo? Isto significa que temos que por os pés no chão e analisarmos as possibilidades nada utópicas! Se dependesse de nossas mentes altamente criativas, conseguiríamos, num estalar de dedos, fazer tudo funcionar da maneira como as nossas brilhantes mentes sonham, e ter acesso a todo o tipo de informações e analíticos que, na prática, sequer sabemos se existem ou se podem ser recuperadas dos elementos de nossa rede. <br /> <br /> E, antes de discutirmos quais tipos de informações/dados podemos obter em nosso ambiente e determinarmos o que podemos fazer com estas informações, tentemos em um primeiro momento compreendermos os protocolos, serviços e procedimentos que podem ser utilizados para recuperarmos informações dos equipamentos e sistemas de nossa infraestrutura.<br /> <br /> ==== Modelo &quot;pull&quot; tradicional de recuperação de dados ====<br /> O modelo ''pull'' de recuperação de dados consiste no envolvimento de procedimentos onde estações de gerenciamento acessam os dispositivos para a obtenção de informações acerca de um ou mais objetos gerenciados. Os exemplos de procedimentos mais comuns são as consultas executadas com protocolos tais como ''Simple Network Management Protocol'' (SNMP), ''Remote Monitoring'' (RMON), ''Secure Shell'' (SSH) e ''Telnet''. <br /> <br /> Como o próprio termo sugere (''pull''), os sistemas de gerenciamento requisitam informações para os equipamentos da rede através de mecanismos de solicitação e resposta, como é o caso das mensagens ''GetRequest'', ''GetBulkRequest'' e ''GetBulkRequest'', do SNMP, sobre algum objeto gerenciado (''Object Identifier'' (OID)), devidamente especificado em uma biblioteca ''Management Information Base'' (MIB) apropriada, a qual deverá ser suportada por ambos o equipamento (ex: roteador) e o sistema da estação de gerenciamento em questão, sendo que as respostas para estas requisições são fornecidas por meios de mensagens ''Response'' deste protocolo.<br /> <br /> Outra possibilidade envolveria scripts devidamente organizados ou acomodados em estações de gerenciamento que executem conexões diretas com o interpretador de linha de comando (CLI) dos equipamentos da rede e execute operações com comandos específicos de interesse do administrador, tais como a obtenção de contadores de uma interface (&quot;''show interfaces''&quot;) para a checagem por eventuais problemas, ou a verificação de status das sessões BGP do roteador (&quot;''show bgp summary''&quot; e &quot;''show bgp neighbor''&quot;), a contabilização da quantidade de rotas anunciadas para determinado vizinho BGP (&quot;''show route advertising-protocol bgp x.x.x.x''&quot; no JUNOS, &quot;''show bgp neighbor x.x.x.x advertised-routes''&quot; no Cisco IOS XR), dentre muitas possibilidades. O &quot;output&quot; de uma operação envolvendo um destes comandos seria então mantido num arquivo temporário para que outros scripts e procedimentos possam ser executados para consumir estes dados e fornecer algum tipo de tratamento e interpretação posterior.<br /> <br /> ==== Modelo &quot;push&quot; tradicional de recuperação de dados ====<br /> O modelo ''push'' de recuperação de dados ocorre no sentido inverso ao modelo ''pull'': os equipamentos da rede encaminham as informações para as estações de gerenciamento, e isto pode ocorrer através de definições periódicas do serviço monitorado para o envio de informações ou baseado em eventos. Exemplos de procedimentos ''push'' incluem as mensagens ''Trap'' do protocolo SNMP onde as mensagens destes &quot;traps&quot; nestes casos acompanhariam duas variáveis primárias, sendo o ''sysUpTime'' e o ''snmpTrapOID'', juntamente com outras instruções para reportar alguma condição que tenha sido detectada sobre o monitoramento estabelecido de um OID, e havendo o reconhecimento por parte do coletor de eventos com o envolvimento da mensagem ''InformRequest-PDU''.<br /> <br /> Outro exemplo de modelo ''push'' seria com o serviço Syslog sobre uma das 24 &quot;''facilities''&quot; (de 0 a 23) especificadas pelo &lt;nowiki&gt;RFC 5424&lt;/nowiki&gt;, sendo algumas de uso reservado para aplicações e serviços específicos, enquanto outras são de uso local (podendo ser destinados praticamente para qualquer finalidade) em combinação com um dos 8 níveis de severidade (0=EMERGENCY, 1=ALERT, 2=CRITICAL, 3=ERROR, 4=WARNING, 5=NOTICE, 6=INFORMATIONAL, 7=DEBUG) para comunicar eventos específicos de acordo com esta combinação de ''Facility'' x ''Severity'' para uma estação coletora de Syslog. Sistemas bastante completos e flexíveis de correlação de eventos podem consumir e processar estas informações para reportar uma gama muito ampla de situações, além de permitir a derivação de métricas e analíticos. O uso de scripts podem ser por ações independentes projetadas pelo administrador, ou ainda como parte integrante de funções existentes de sistemas de gerenciamento propriamente ditos.<br /> <br /> Dentre outras possibilidades envolvendo este modelo ''push'', há as próprias ferramentas embarcadas nos sistemas operacionais / software dos roteadores e switches, dentre os quais recomendo o ''Cisco Embedded Event Manager'' (EEM), ''Junos Event Scripts'', assim como facilidades similares encontradas em plataformas de outros fabricantes, os quais permitem flexibilizar bastante como eventos e outras informações podem ser encaminhadas para outros sistemas residindo em servidores da rede.<br /> <br /> ==== Telemetria orientada a modelos ====<br /> Ou MDT. As ferramentas e procedimentos clássicos empregados nos modelos ''pull'' e ''push'' tradicionais, citados previamente, possuem algumas restrições e limitações, mas isto não significa que protocolos e procedimentos tais como SNMP, shell scripting, recursos de software de roteadores (Cisco EEM, Junos Event Scripts, Huawei OPS, etc.) serão descontinuados ou aposentados tão cedo, muito pelo contrário. Na verdade, a tendência é que sejam encontrados novos propósitos e finalidades para estes protocolos e serviços mais legados, ou ainda dedicando-os para coletas de instruções e operações bem mais específicas, e não tão generalistas como ocorre atualmente na maioria das redes, enquanto novas tecnologias estão ganhando espaço para conquistarmos melhores resultados para as nossas necessidades de gerenciamento de configurações, gerenciamento de performance, gerenciamento de falhas, analíticos, ''big data'' e afins. E é justamente aqui onde entra o conceito de '''''telemetria''''' na sua forma mais ampla e efetiva.<br /> <br /> A telemetria orientada à modelos embarca e combina procedimentos de &quot;''telemetria orientada a eventos''&quot; e, principalmente, como destaque, a &quot;''telemetria de streaming periódica''&quot;, para proporcionar os melhores resultados, e não apenas nas ações técnicas e operacionais que competem aos centros de gerência de redes, tais como gerenciamento FCAPS no geral, mas, principalmente, em termos de ''big data'', analíticos e afins, sendo o principal diferencial entre esta modalidade e os modelos tradicionais de gerenciamento no geral.<br /> <br /> A principal diferença entre as duas abordagens, a &quot;tradicional&quot; e a &quot;telemetria&quot;, é que o modelo tradicional, simplificando aqui, emprega o protocolo SNMP, além de outros procedimentos já citados. Para efeitos comparativos, operações com protocolos tais como o SNMP são executadas com o modelo ''pull'' diretamente sobre os elementos da rede, exceto quando considerando aqui os SNMP Traps, que são muito específicos para alertas e eventos, e que operam por método ''push''. Já na telemetria por streaming periódico os dados são enviados diretamente e em tempo real a partir dos elementos da rede para os coletores e sistemas de gerenciamento, ou seja, conceito &quot;''push''&quot; mesmo, mas com diferenças significativas em termos de capacidade, recursos e disponibilidade de informações, além da própria característica &quot;''tempo real''&quot;. No que diz respeito à telemetria orientada e eventos, um dos maiores exemplos é o recurso ''BGP Monitoring Protocol'' (BMP), que poderá encaminhar eventos praticamente em tempo real acerca da operação do protocolo BGP no seu ASN. Os ganhos e benefícios disto tudo serão discutidos posteriormente neste artigo.<br /> <br /> A ilustração a seguir exemplifica as diferenças e principais componentes empregados em cada um dos casos citados aqui:<br /> [[Arquivo:Bpf-gerbgp-comparativosger.jpg|centro|miniaturadaimagem|907x907px|Comparativos entre os modelos de gerenciamento factíveis para o BGP]]<br /> <br /> ==== Comparativos entre os diversos tipos de tecnologias (protocolos e serviços), suas capacidades, finalidades e propósitos, e suas respectivas categorizações ====<br /> A tabela a seguir certamente será muito útil para concentrarmos muitas informações importantes e bem relevantes para dissertarmos sobre os aspectos e possibilidades quanto ao gerenciamento do BGP.<br /> {| class=&quot;wikitable&quot;<br /> |+Tabela comparativa entre diversos tipos de protocolos e serviços, suas capacidades, finalidades e propósitos<br /> !Ferramenta<br /> <br /> (Protocolo e/ou Serviço)<br /> !Alguns exemplos de situações em que pode ser empregada<br /> |-<br /> |'''SNMP (operações &quot;Get&quot;)'''<br /> |Operações de recuperação e amostragem de informações obtidas por meios de operações &quot;get&quot; do SNMP.<br /> * Consultas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Identificação de propriedades de sessões BGP (ex: temporizadores) e capacidades suportadas<br /> * Identificação da quantidade de rotas aceitas de uma sessão BGP<br /> * Identificação da quantidade de rotas recusadas de uma sessão BGP<br /> * Identificação da quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Identificação de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> * Recuperação da tabela de roteamento (Ex: 1.3.6.1.2.1.4.21 - ipRouteTable)<br /> |-<br /> |'''SNMP Traps'''<br /> |Alertas que poderão ser recebidos por sistemas de gerenciamento com suporte às MIBs necessárias.<br /> * Alertas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Alertas de quantidade de rotas recebidas de uma sessão BGP<br /> * Alertas de quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Alertas de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> |-<br /> |'''RMON'''<br /> |O RMON tem pouca ou nenhuma utilidade específica para os interesses de gerenciamento do BGP, mas suas capacidades e recursos poderão ser obtidas e combinadas para agregar valor ao propósito de gerenciamento como um todo.<br /> * Estatísticas em tempo real de utilização dos segmentos Ethernet envolvidos no transporte de sessões BGP (utilização, erros, colisões)<br /> * Fornecer histórico de estatísticas selecionadas, e com suporte ao uso de variáveis especificadas pelo usuário.<br /> <br /> * Encaminhamento de alarmes para RMON SNMP traps quando houver o cruzamento de determinados thresholds pré-definidos, inclusive com suporte a grupos de alarmes.<br /> * Monitoramento de hosts, tais como a quantidade de bytes e frames enviados e recebidos de vizinhos BGP.<br /> * Ordenamento de &quot;top hosts&quot; com coleta e manutenção de dados referentes a conexões ativas por um determinado período de tempo.<br /> * Matriz de tráfego entre dois roteadores envolvidos numa sessão BGP.<br /> * Filtragem de dados com base em padrões de interesse do administrador, tais como endereços MAC, e portas de protocolos de transporte.Captura de pacotes para análise posterior em depuradores.<br /> * Descoberta e estatísticas por protocolo.<br /> * Mapeamento entre endereços MAC e endereços IP referentes as sessões BGP<br /> * Estatísticas de tráfego L3 com ordenamento por host ou par de conversação (origem/destino), como complemento ao monitoramento do BGP.<br /> * Estatísticas de tráfego L7 por protocolo de aplicação e por host, como complemento ao monitoramento do BGP.<br /> |-<br /> |'''Syslog'''<br /> |Alertas que poderão ser recebidos por servidores syslog &quot;crus&quot; ou uma solução específica para correlação de eventos e processamento de analíticos.<br /> * Alertas de esgotamento de recursos de memória para algum processo ou ação do BGP<br /> * Alertas de problemas com a instalação de rotas BGP devido a inconsistências ou atributos inválidos<br /> * Alertas de falhas de semântica de políticas (route-map, route-policy, etc.) vinculadas a sessões BGP<br /> * Alertas de falhas nas estruturas internas dos processos BGP<br /> * Alertas de problemas de processamento de ações sobre atributos (ex: remoção de AS_PATH, modificação de NEXT_HOP)<br /> * Alertas de recebimento de prefixos inválidos (ex: Martians)<br /> |-<br /> |'''Shell scripting para invocação de CLI'''<br /> |Recuperação de qualquer informação possível por comandos na CLI do roteador.<br /> * Verificação do status de todas as vizinhanças BGP<br /> * Verificação detalhada de uma vizinhança BGP específica<br /> * Contadores de prefixos anunciados e recebidos por vizinho BGP<br /> * Detalhamento das rotas BGP anunciadas para um determinado vizinho BGP<br /> * Detalhamento das rotas BGP recebidas de um determinado vizinho<br /> * Consultas sobre a tabela BGP integral<br /> * Consultas sobre a tabela BGP com parâmetros de refinamento (expressão regular/regex, community, next-hop, policy...)<br /> * Consultas sobre a tabela BGP de rotas não filtradas (pré-policy) de um determinado vizinho (soft-reconfig inbound)<br /> |-<br /> |'''Cisco EEM'''<br /> |Componente do software de roteadores da Cisco, permitindo que você automatize tarefas, execute modificações e ajustes sobre diversos componentes lógicos, e crie ações alternativas. Dentre muitas possibilidades, e focando aqui no BGP, é possível:<br /> * Monitorar o estado operacional ou funcionamento de determinados protocolos e serviços e tomar ações automaticamente em função de algum evento pré-definido por você.<br /> * Implementar uma rotina de verificação de oscilação de sessões BGP, as quais, atingindo um determinado &quot;''threshold''&quot;, poderá invocar uma ação de notificação por Syslog, SNMP, Email (que poderá ser uma máscara de WhatsApp ou Telegram).<br /> * Em adição ao conceito acima, executar uma ação que poderá incluir a modificação de uma route policy para consequente redução do atributo LOCAL_PREF implementado sobre as rotas recebidas de um peer que está oscilando.<br /> * Em adição ao conceito acima, executar uma ação que poderá decidir por desabilitar administrativamente aquela sessão por um determinado período de tempo ou até que haja garantias de que a sessão esteja estável por &quot;x&quot; horas.<br /> * Implementar uma rotina de detecção de existência ou ausência de uma determinada rota BGP na tabela de roteamento (RIB), permitindo uma ação desejada que poderia incluir o estabelecimento de um túnel GRE ou TE, o &quot;shutdown&quot; ou &quot;no shutdown&quot; de uma interface, uma mudança de policy, etc.<br /> * Implementar uma rotina que vá coletar informações (tabela BGP, NLRIs com determinados atributos (ex: communities), rotas BGP da RIB, sessões, etc.) em intervalos periódicos, escrevendo os ''outputs''/dados em um arquivo em um servidor FTP.<br /> * &quot;Quem tem limites é município&quot;. O limite é virtualmente a capacidade criativa do administrador da rede; a sua imaginação. Experimente!<br /> |-<br /> |'''Juniper Event Scripts'''<br /> |Componente embarcado no sistema operacional JUNOS dos roteadores da Juniper Networks e com proposta similar ao Cisco EEM.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o Juniper Event Scripts propõe-se a fazer aquilo que o Cisco EEM faz, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas duas ferramentas.<br /> |-<br /> |'''Huawei Open Programmability System (OPS)'''<br /> |Componente embarcado no sistema operacional dos roteadores da Huawei e com proposta similar ao Cisco EEM e ao Juniper Event Scripts.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o OPS propõe-se a fazer aquilo que o Cisco EEM e o Juniper Event Scripts fazem, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas três ferramentas.<br /> |-<br /> |'''OpenConfig, NETCONF, RESTCONF, gNMI, gRPC, e modelos YANG'''<br /> |O OpenConfig, padrão aberto para o desenvolvimento de interfaces programáticas, viabiliza um gerenciamento mais dinâmico das infraestruturas (ex: telemetria) utilizando como transporte os protocolos e procedimentos NETCONF, RESTCONF, gNMI ou gRPC, em combinação com repositórios de dados modelados pelo YANG, para proporcionar um novo universo de possibilidades em termos de gerenciamento.<br /> <br /> Uma de suas principais aplicabilidades envolve o chamado ''Model-Driven Telemetry'' ou MDT. Quando pensando em gerenciamento por este modelo de telemetria, as possibilidades chegam a surpreender, pois a entrada de dados por ser feita pelos protocolos supracitados, ou ainda por JSON, Kafka, Google Protocol Buffer (GPB), Google RPC (GRPC), dentre outros, a lista é interessante.<br /> <br /> Já a saída de dados poderá ser feita para Kafka, Prometheus, InfluxDB, JSON, XML, e outros, pois a lista é igualmente interessante, o que abre um leque realmente surpreendente de situações e possibilidades. Nunca as redes foram tanto &quot;''software-defined''&quot;: o MDT é um divisor de águas! <br /> * Modelagem e streaming periódico/contínuo de dados para a representação das rotas BGP da RIB com suporte a 5 RIBs lógicas por família de endereços.<br /> * Provimento de definições de dados para tabelas BGP, tipos, identidades, especificações, atributos, e afins, para o gerenciamento efetivo do BGP por OpenConfig.<br /> * Gerenciamento, automação e orquestração de sessões e políticas de roteamento.<br /> * Streaming contínuo de indicadores de performance do BGP, incluindo FSM das sessões, quantidade de sessões, quantidade de rotas total e aceitas/recusadas por neighbor, etc.<br /> * Streaming contínuo de indicadores de anomalias associadas ao BGP.<br /> |-<br /> |'''NetFlow / JFlow / sFlow'''<br /> |O emprego destas tecnologias correlacionam os registros dos fluxos de tráfego juntamente com as informações de roteamento BGP para que seja possível visualizar as conversações para a extração de diversos analíticos importantes.<br /> * Monitoramento em tempo real de registros de fluxos de conversações juntamente com as indicações de Sistemas Autônomos envolvidos.<br /> * Identificação através de pesquisas customizadas sobre fluxos de tráfego por origem, destino, par origem-destino, protocolo de transporte, marcação de QoS, Sistema Autônomo BGP, etc.<br /> * Identificação dos &quot;''top talkers''&quot; por uma variedade de critérios de consulta.<br /> |-<br /> |'''BGP Link-State (BGP-LS)'''<br /> |O BGP Link-State (LS) é uma extensão do protocolo BGP fornecida por meios de um ''Address Family Identifier'' (AFI) e ''Sub-address Family Identifier'' (SAFI) para transportar o ''Link-State Database'' (LSDB) de protocolos IGP (OSPF e IS-IS) através do BGP. <br /> <br /> O BGP-LS permite uma série de aplicações, desde o fornecimento de informações topológicas detalhadas da rede para servidores específicos orientados à otimização de tráfego de rede na camada de Aplicação (ALTO), suporte a Path Computation Element (PCE) para engenharia de tráfego, e outros.<br /> <br /> No que diz respeito ao monitoramento do BGP, o BGP-LS poderá atuar como um componente adicional para agregar mais informações em diversas bases e sistemas onde os dados específicos de BGP são coletados, mantidos, processados, e representados.<br /> * Fornecimento de informações topológicas detalhadas da rede.<br /> * Combinação e correlação dos dados topológicos com estruturas de dados fornecidas por outros meios de gerenciamento centrados na otimização e visibilidade do BGP, tais como sFlow/JFlow/NetFlow, BMP, CLI, e SNMP.<br /> * Visibilidade, correlação de eventos, aprimorar ações de planejamento de capacidades e de engenharia de tráfego, e detecção de incidentes de segurança.<br /> |-<br /> |'''BGP Monitoring Protocol (BMP)'''<br /> |Acesso de sistemas de gerenciamento ao Adj-RIB-In de peers BGP para o recebimento periódico de estatísticas do protocolo.<br /> * Recebimento periódico de estatísticas que possam ser usadas para monitorar as atividades específicas do BGP.<br /> * Recebimento de notificações acerca do estado operacional das sessões BGP.<br /> * Recebimento das tabelas BGP pré-policy, ou seja, antes que o roteador implemente os filtros de import/export sobre as rotas.<br /> * Recebimento das tabelas BGP pós-policy, ou seja, após o roteador ter filtrado e filtrado atributos associados às rotas.<br /> * Em combinação com validadores de IRR, poderá detectar route leaks gerados ou recebidos pelo AS local.<br /> * Em combinação com validadores de RPKI, poderá detectar violações de ASN de origem associados às rotas recebidas ou enviadas.<br /> * Poderá ser combinado para fornecer funcionalidade de Looking Glass.<br /> * Fornecimento de visibilidade histórica envolvendo estado de sessões.<br /> * Fornecimento de visibilidade e histórico de prefixos com refinamento por &quot;peer&quot;, &quot;ASN&quot; e &quot;prefixo&quot;.<br /> * Permite estudar através de uma linha temporal todos os anúncios e recebimentos realizados, incluindo rotas aceitas e recusadas.<br /> * Permite estudar através de uma linha temporal todas as modificações de atributos executadas sobre rotas aceitas.<br /> |}<br /> Como não dá para abordar tudo em um artigo - talvez outros artigos sobre o tema sejam disponibilizados na Wiki do BPF - procurarei demonstrar algumas coisas que podem ser feitas com algumas das ferramentas/opções listadas na tabela acima. Que tal focarmos em dois componentes aqui? SNMP e BMP. <br /> <br /> === Monitoramento do BGP com o Simple Network Management Protocol (SNMP) ===<br /> O monitoramento de infraestruturas de redes por SNMP não é novidade alguma para os profissionais da área, muito pelo contrário. E, no que diz respeito ao monitoramento do BGP, o SNMP tem sido amplamente utilizado por muitas empresas para cumprir com diversas das necessidades e desafios comentados previamente. Por ser algo um tanto difundido, talvez o único método de gerenciamento/monitoramento propriamente dito adotado por ISPs regionais de pequeno e médio portes, não desprenderei muito tempo nesta seção do artigo.<br /> <br /> Diversas plataformas baseadas em software podem ser utilizadas para monitorar o BGP, dentre os quais destaco os seguintes:<br /> * [https://www.zabbix.com/ Zabbix]<br /> * [https://www.librenms.org/ LibreNMS]<br /> * [https://www.observium.org/ Observium]<br /> * [https://www.nagios.com/ Nagios]<br /> * [https://www.cacti.net/ Cacti]<br /> * [https://www.opennms.com/ OpenNMS]<br /> * [https://www.solarwinds.com/pt/ Solarwinds]<br /> * [https://www.paessler.com/prtg PRTG]<br /> * Integrações de boa parte destas soluções com o [https://grafana.com/ Grafana] para a geração de dashboards<br /> * Soluções comercias de fabricantes tais como Cisco, Juniper e outros<br /> Está fora do escopo deste artigo tecer quaisquer comparativos (&quot;''qual é o melhor?''&quot;, etc.) dentre estas soluções.<br /> <br /> Independentemente de qual abordagem/solução seja escolhida por você para atender as suas necessidades, o fato é que você terá que assegurar o devido suporte a alguns componentes específicos para o monitoramento do BGP, em particular a '''''BGP4-MIB''''', conforme descrita no RFC 4273 (''Definitions of Managed Objects for BGP-4'') e RFC 4275 (''BGP-4 MIB Implementation Survey''). Você deverá considerar também eventuais MIBs que implementem OIDs proprietários de acordo com o fabricante do equipamento que você necessitar monitorar pela sua gerência SNMP, por exemplo a [https://www.juniper.net/documentation/en_US/junos/topics/reference/mibs/mib-jnx-bgpmib2.txt '''''Juniper-BGP-MIB'''''] e [https://mibs.cloudapps.cisco.com/ITDIT/MIBS/MainServlet?ReleaseSel=4669&amp;PlatformSel=269&amp;fsSel=348 '''''Cisco-BGP-MIBv2'''''] , e certificar-se que seus sistemas de gerenciamento (ex: Zabbix) implementem funções para operações de consulta sobre os OIDs desejados com estas MIBs. Além destas MIBs, muitos destes sistemas possuem plugins prontos para o monitoramento do BGP em condições diversas, por exemplo:<br /> * Zabbix<br /> ** [https://share.zabbix.com/network_devices/cisco/cisco-bgp-ipv4-ipv6-32-bit-asn Cisco BGP IPv4/IPv6 32-bit ASN]<br /> ** [https://share.zabbix.com/network_devices/juniper/juniper-mx-discovery-int-re-bgp4-ipv4-and-ipv6 Template SNMP Juniper MX discovery: int, RE, BGP4 ipv4 and ipv6]<br /> ** [https://share.zabbix.com/network_devices/mikrotik/zabbix-routeros-bgp-monitoring Zabbix RouterOS BGP Monitoring]<br /> * LibreNMS<br /> ** [https://docs.librenms.org/API/Routing/ Monitoramento de sessões BGP] e [https://docs.librenms.org/Alerting/Entities/ Entities]<br /> * Observium<br /> ** [https://docs.observium.org/config_options/ Monitoramento de sessões BGP]<br /> * Nagios<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check-BGP-neighbor-JunOS/details Check BGP Neighbor JunOS]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp/details check_bgp]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_counters/details check_bgp_counters]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_v4_v6/details check_bgp_v4_v6]<br /> * Grafana<br /> ** [https://grafana.com/grafana/plugins/alexanderzobnin-zabbix-app Plugin para Zabbix]<br /> ** [https://grafana.com/grafana/plugins?orderBy=weight&amp;direction=asc Plugins para diversas finalidades e integrações]<br /> ** [https://grafana.com/grafana/dashboards?dataSource=alexanderzobnin-zabbix-datasource&amp;orderBy=name&amp;direction=asc Dashboards &quot;prontos&quot;]<br /> * Outros! basta pesquisar pelos recursos desejados junto à documentação do seu sistema de gerenciamento, entrar em contato com o suporte de desenvolvimento, contratar uma consultoria especializada, etc.<br /> O funcionamento do monitoramento do BGP por SNMP não é complexo, pois é um procedimento um tanto difundido entre os operadores de redes. As estações de gerenciamento são configuradas para executar consultas periódicas sobre os roteadores monitorados usando operações &quot;''Get''&quot; sobre os ''Object Identifiers'' (OID) desejados, os quais precisam ser especificados numa MIB apropriada (ex: BGP4-MIB), e cujo o suporte a esta MIB deverá existir tanto no roteador monitorado quanto no software em execução na estação de gerenciamento. O SNMP funciona neste caso como um mecanismo de solicitação e resposta, e as informações recuperadas por meios deste mecanismo são armazenadas nas bases de dados que acompanham estas soluções, e devidamente processadas para reportar alguma coisa em alguma função do sistema. Em adição, é possível consultar estes dados via integrações com outros sistemas (ex: Grafana) para finalidades de representação melhor elaboradas, como painéis/dashboards e afins. Por exemplo:<br /> [[Arquivo:Bpf-gerbgp-snmp.jpg|centro|miniaturadaimagem|900x900px|Exemplo de monitoramento do BGP por procedimento SNMP]]<br /> É importante frisar também que o gerenciamento do BGP para a questão de incidentes tais como oscilações de sessões (ou &quot;''flapping''&quot;) pode ser tratada por intermédio de mensagens ''SNMP trap''. O sistema de gerenciamento (chamamos aqui de software &quot;NMS&quot;), ao receber o evento por SNMP trap, buscará processar a informação de acordo com as diretivas que estiverem definidas para o elemento de rede gerenciado, permitindo destacar o evento da falha de forma visível nos painéis correspondentes oferecidos pelo software NMS. Apesar de isto não ser novidade alguma, acho que não custa nada deixar isto esclarecido para a eventualidade deste artigo ser consultado por indivíduos mais leigos.<br /> [[Arquivo:Bpf-gerbgp-snmptrap.jpg|centro|miniaturadaimagem|900x900px|SNMP traps para a funcionalidade de notificações e alertas do gerenciamento de falhas]]<br /> <br /> Nas mãos de profissionais caprichados, é possível construir painéis bastante interessantes com soluções relativamente simples, mas não menos interessantes, intuitivas ou funcionais, baseadas no SNMP, em especial quando envolvendo o Grafana para a produção destes painéis. Alguns casos de uso do Zabbix + Grafana para o monitoramento do BGP serão demonstrados aqui, sendo que, em alguns cenários, além do SNMP, outros procedimentos podem ser envolvidos para a recuperação e representação das informações desejadas para cada painel.<br /> <br /> No painel demonstrado a seguir, idealizado pelo Caio Ribeiro da [https://www.facebook.com/flowbix Flowbix], foi possível concentrar muita informação útil/relevante numa única tela: desde status das sessões BGP com seus respectivos ''uptimes'', total de prefixos IPv4 com indicadores de RIB e FIB, estado dos módulos ópticos do equipamento roteador BGP monitorado, a estatísticas de consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio1.jpg|centro|miniaturadaimagem|1280x1280px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também idealizado pela Flowbix, outra consolidação de dados importantes numa única tela, incluindo latência, índice de perda de pacotes, disponibilidade, uso de recursos tais como CPU, memória e espaço em disco, estado geral das sessões BGP monitoradas, e consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio2.jpg|centro|miniaturadaimagem|967x967px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também elaborado pela Flowbix, temos estatísticas mais centradas no estado das sessões BGP, e em combinação com uma visão geral dos índices de latência registrados.<br /> [[Arquivo:Bpf-gerbgp-caio3.jpg|centro|miniaturadaimagem|900x900px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Realmente, os limites em termos de construção de painéis para objetos gerenciados por SNMP com uma combinação NMS (ex: Zabbix) + Grafana, além de outros possíveis procedimentos, são um tanto amplos. Muita coisa de fato pode ser feita, desde que você possua os conhecimentos necessários para desenvolver estas integrações. Ou, então, por que você não investe em serviços de integração para o seu negócio?<br /> <br /> === Monitoramento por meios do BGP Monitoring Protocol (BMP) ===<br /> Muitos profissionais da área, incluindo engenheiros que atuam nas principais empresas de Internet do mundo, fabricantes e pesquisadores, chegaram a conclusão que era realmente necessário que tivessem acesso ao conteúdo das rotas mantidas nas tabelas BGP de roteadores, assim como uma visão do conteúdo das mensagens Update empregadas na troca de rotas entre sessões BGP. O grande desafio, porém, é que os modelos tradicionais de gerenciamento (ex: SNMP) praticamente inviabilizam o cumprimento de ações que fornecessem estas informações. Surgiu então o '''''BGP Monitoring Protocol''''', especificado originalmente no &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; (''BGP Monitoring Protocol (BMP)'') e complementado pelo &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)'').<br /> <br /> O BMP fornece meios de acesso ao ''Adj-RIB-In'' de uma sessão BGP de uma forma contínua em adição a um despejo periódico de dados estatísticos para uma estação coletora, devidamente equipada com software específico, para que os engenheiros do Sistema Autônomo possam analisar o funcionamento e o comportamento do BGP.<br /> <br /> Antes mesmo de você conhecer os benefícios do monitoramento do BGP com o protocolo BMP, você precisa saber identificar alguns componentes e conceitos fundamentais <br /> * '''''Adj-RIB-In''''': conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt; (''A Border Gateway Protocol 4 (BGP-4)''), o ''Adj-RIBs-In'' contém as informações de roteamento ainda não processadas que foram anunciadas pelo roteador BGP para seus vizinhos. É conhecido também pelo termo &quot;''pre-policy Adj-RIBs-In''&quot;. Na perspectiva do BMP, o ''Adj-RIB-In'' representa todas as rotas que foram recebidas pelo coletor antes destas informações terem sido processadas por uma policy inbound.<br /> * '''''Post-Policy Adj-RIBs-In''''': é o resultado de aplicação da política de roteamento inbound (ou &quot;import&quot;, como é conhecido em algumas plataformas), mas antes de ter ocorrido o processo de seleção de caminhos (best-path) do BGP para a composição da tabela de roteamento local. Na perspectiva do BMP, o ''post-policy Adj-RIB-In'' representa as informações que foram recebidas pelo coletor após a aplicação de policies inbound ou modificações de quaisquer atributos.<br /> Ou seja, a diferença entre ''pre-policy Adj-RIB-In'' e ''post-policy Adj-RIB-In'' é que, no primeiro caso, não houve a aplicação de quaisquer filtros sobre as rotas recebidas antes que estas informações fossem exportadas para o coletor BMP. E, no post-policy, as informações são encaminhadas para o coletor BMP após o roteador ter &quot;filtrado&quot; (e, potencialmente, modificado atributos) por meios de policies inbound, mas antes do roteador ter conduzido o processo de seleção de ''best path'' para posterior composição da RIB local referente a estas rotas BGP. O monitoramento de updates recebidos de um roteador antes da aplicação de policies inbound tem sido provavelmente a aplicação mais frequente envolvendo o BMP, enquanto o post-policy está mais centrado nas questões relacionadas à auditoria e validação das políticas de roteamento implementadas pela empresa.<br /> <br /> No entanto, o monitoramento apenas do ''Adj-RIB-In'' impõe uma restrição sobre quais dados estariam disponíveis ou acessíveis para os coletores BMP. Como a maioria dos Sistemas Autônomos não possui qualquer implementação de BMP e, quando possuem, não disponibilizam estas informações para terceiros (ex: acesso leitura-apenas ao painel da estação coletora BMP), a sua empresa fica sem visibilidade sobre de fato o que foi anunciado e aceito para os peers de ASs vizinhos. Tudo bem que a consulta destas informações por Looking Glass (que não são baseados em BMP) até permite que você consiga de fato ver se um determinado anúncio encontra-se presente nas tabelas BGP do AS vizinho, mas, no entanto, sem quaisquer dados históricos e facilidades deste tipo, os quais estariam disponíveis com o BMP, ou na alçada deste. E é justamente aí que entra outra proposta, que é o &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)''). Este RFC introduz alguns argumentos e facilidades adicionais para o BMP, dentre os quais:<br /> * '''''Adj-RIB-Out:''''' conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt;, o ''Adj-RIB-Out'' contém as rotas designadas para anúncios para os peers BGP por intermédio das mensagens UPDATE.<br /> * '''''Pre-policy Adj-RIB-Out''''': é o resultado de representação dos prefixos que serão anunciados pelas mensagens UPDATE antes da aplicação de policies outbound (ou &quot;export&quot;). Geralmente é a mesma coisa que encontra-se no momento na RIB local do roteador.<br /> * '''''Post-policy Adj-RIB-Out:''''' é o resultado do envio de prefixos através de anúncios (UPDATE) após o processamento das informações pelas policies outbound. É a representação do que de fato está sendo anunciado para um peer BGP específico.<br /> O ''BGP Monitoring Protocol'' (BMP) opera sobre uma sessão TCP entre o roteador monitorado e a estação coletora BMP. A configuração da sessão é um tanto flexibilizada, com possibilidade de conexão passiva (iniciada pelo roteador apenas) e mecanismos de backoff de tentativas de conexão com intervalos configuráveis, assim como outros parâmetros para o controle de fluxo de informações entre o roteador e a estação coletora BMP. Nenhuma mensagem BMP é enviada da estação coletora para o roteador, mas nada impede que o administrador da rede configure uma policy inbound para recusar quaisquer anúncios (que sabemos que nunca serão enviados) vindos da estação coletora BMP. Com relação às mensagens empregadas pelo BMP, o &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; especifica as seguintes:<br /> * '''''Type 0: Route Monitoring (RM)''''': é usado para fornecer um dump inicial de todas as rotas recebidas a partir de um peer, e atua também como um mecanismo contínuo para relatar, de forma incremental, as rotas que são anunciadas e revogadas (''withdrawn)'' por um peer para a estação coletora BMP. A mensagem ''Route Monitoring'' consiste de ''Common Header'' + ''Per-Peer Header'' + mensagem BGP ''UPDATE'' na íntegra.<br /> * '''''Type 1: Statistics Report (SR)''''': fornece um despejo periódico de estatísticas que podem ser utilizadas pelo coletor BMP para relatar as atividades específicas do BGP realizadas pelo roteador. A mensagem ''Stats Reports'' consiste de ''Common Header'' + ''Per-Peer Header'' + um campo de 4 bytes indicando a quantidade de contadores, sendo que cada contador é codificado na forma de um TLV. Stats são informados como ''Counters'' (32-bit) ou ''Gauges'' (64-bit).<br /> * '''''Type 2: Peer Down Notification''''': uma mensagem que é enviada para indicar que uma sessão BGP foi desconectada, fornecendo ainda o motivo para esta desconexão. A mensagem ''Peer Down Notification m''enciona um dos 5 motivos indicativos do encerramento de uma sessão BGP do roteador (''Reason'' 1 a ''Reason'' 5).<br /> * '''''Type 3: Peer Up Notification''''': uma mensagem que informa que uma sessão BGP ficou Up ou &quot;Established&quot;. Esta mensagem inclui informações importantes sobre o que ficou negociado entre os roteadores participantes desta sessão (conteúdo da mensagem OPEN) e também dados referentes à sessão BGP. A mensagem ''Peer Up Notification'' consiste de ''Common Header'' + ''Per-Peer Header'' + a mensagem (BGP) ''OPEN'' enviada + a mensagem ''OPEN'' que foi recebida + informações sobre o peer (opcional)<br /> * '''''Type 4: Initiation Message''''': fornece um mecanismo de indicação para o coletor BMP sobre o roteador BGP, incluindo o fabricante/modelo, versão de software, etc., funcionando como uma espécie de controle de inventário. A mensagem ''Initiation Message'' consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' contendo informações acerca do roteador monitorado, sendo que ''sysDescr'' e ''sysName'' são obrigatórios, enquanto os demais são opcionais.<br /> * '''''Type 5: Termination Message''''': fornece um mecanismo utilizado para informar que a sessão BMP entre o roteador e o coletor BMP foi interrompida. A mensagem ''Termination Message'' consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' descrevendo um dos 5 motivos (''Reason'' 0 a Reason 4) pela ''terminação'' da sessão BMP com o roteador monitorado.<br /> * '''''Type 6: Route Mirroring Message''''': um mecanismo para o roteador monitorado enviar duplicatas literalmente de mensagens conforme são recebidas. Pode ser usado para espelhar exatamente uma sessão BGP monitorada, assim como ser usado para relatar PDUs malformados do protocolo BGP. A mensagem ''Route Mirroring'' consiste de ''Common Header'' + ''Per-Peer Header'' + conjuntos de TLVs que descrevem as mensagens, sendo que 2 bytes informam o código do tipo de mensagem (ex: Type 0 = ''BGP Message'', Type 1 = ''Information'', Type 1 Code 0 = ''Errored PDU'' e Type 1 Code 1 = ''Messages Lost''), 2 bytes o campo de comprimento, e um campo de valor de comprimento variável.<br /> O &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; por sua vez implementa algumas modificações nas estruturas destas mensagens para acomodar as situações ''Adj-RIB-In'' e ''Adj-RIB-Out'', tais como flag O assinalado para &quot;0&quot; em mensagens BMP com cabeçalho ''per-peer'', e os flags necessários para denotar especificamente ''Adj-RIB-In'' ou ''Adj-RIB-Out'' para as mensagens ''Route Monitoring'' e ''Route Mirroring''.<br /> [[Arquivo:Bpf-gerbgp-bmpheaders.jpg|centro|miniaturadaimagem|900x900px|Cabeçalhos do BMP conforme &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt;]]Acredito que você já esteja entendendo melhor as funcionalidades básicas proporcionadas pelo ''BGP Monitoring Protocol'' (BMP)! Que tal apresentarmos um caso prático envolvendo o monitoramento do BGP por esta tecnologia?<br /> <br /> ==== Caso de uso: monitoramento por BGP Monitoring Protocol (BMP) com o Streaming Network Analytics System (SNAS) ====<br /> O caso apresentado a seguir é uma das diversas possibilidades associadas ao monitoramento do BGP em um Sistema Autônomo com o BMP. Para encurtarmos uma dissertação excessivamente prolongada deste caso, optei por elaborar um simples &quot;canvas&quot; para representar um conceito de solução proposta baseada no ''Streaming Network Analytics System'' (SNAS). O modelo canvas mostrado a seguir tem uma estrutura modificada/customizada para refletir as características gerais do conceito de solução proposto da maneira que eu gostaria de fornecer, ou seja, colocando numa única página, a relação de ''Problemas/Necessidades'', ''Solução'', ''Argumentos de Adoção'', ''Vantagens'', ''Desvantagens'', ''Resultados'', ''Características de Extensibilidade e Integração'' e um ''Bloco Representativo da Solução''. Este arranjo ou customização do modelo canvas deve ser eficiente o bastante para esclarecer esta solução.<br /> [[Arquivo:Bpf-gerbgp-openbmp.jpg|centro|miniaturadaimagem|900x900px|Canvas model do conceito de solução factível com base numa derivação do SNAS para o gerenciamento com o BGP Monitoring Protocol ]]<br /> Apenas para constar, a solução é composta pelos seguintes componentes, cada qual com uma função bastante especifica, e devidamente &quot;empacotados&quot; para implementação em containers com Docker: <br /> * '''openBMP:''' servindo como coletor de BMP. Uma sessão BMP é estabelecida entre este coletor e cada roteador onde desejamos monitorar ou coletar os dados referentes ao BGP.<br /> * '''Apache Kafka:''' o Kafka atua como uma plataforma de processamento de streaming de alta capacidade e baixa latência para o tratamento de dados em tempo real. A presença do Kafka no projeto permite conectar múltiplos ''publishers'' e ''subscribers'' para a disseminação de dados de forma bastante rápida, sendo um ótimo diferencial para as questões de integração e compartilhamento de dados de nossa solução com outros sistemas. Esta instalação inclui ainda o '''''Zookeeper''''', um software também desenvolvido pela Apache e que atua como um serviço centralizado, sendo usado para manter os dados de nomenclatura e configuração e para fornecer sincronização flexível e robusta nos sistemas distribuídos. O ''Zookeeper'' controla o status dos nós do cluster Kafka e também rastreia os tópicos, partições, etc.<br /> * '''PostgreSQL:''' O projeto SNAS original emprega como banco de dados o MySQL/MariaDB, isto tem servido bem aos propósitos por um bom tempo. Todavia, os desenvolvedores entenderam que estava na hora de substituí-lo por um banco de dados mais eficiente em função de algumas das limitações do MariaDB, tais como gerenciamento manual de partições de dados de séries temporais, recuperação de espaço em disco e requerimentos de memória do InnoDB, suporte fraco a JSON, dentre outras. O PostgreSQL resolve estas limitações e ainda adiciona algumas facilidades consideradas interessantes pelos desenvolvedores do SNAS, sendo que o consumidor dos dados implementa todas as APIs de análise do barramento de mensagens via o Kafka. Nesta implementação, o container inclui ainda os seguintes: '''''TimescaleDB''''', '''''RPKI Validator''''', e consultas às bases IRR por procedimento '''''Whois'''''. O ''TimescaleDB'' é um banco de dados de código aberto desenvolvido para tornar o SQL escalável para dados de séries temporais, e é aqui empacotado como uma extensão do PostgreSQL para fornecer o particionamento automático através do tempo e espaço (chave de particionamento). O ''RPKI Validator'', por sua vez, é acionado em rotinas próprias para a verificação do status ROA de cada prefixo mantido na base de dados da solução, enquanto o ''Whois'' é invocado em outras rotinas para a recuperação de informações nas bases IRR.<br /> * '''Grafana:''' o SNAS original possui o seu próprio front end WebUI, obviamente não baseado no Grafana, o qual é compatível somente com a instalação original baseada no MySQL/MariaDB. Esta WebUI não é compatível com o PostgreSQL, tampouco o Grafana, nas novas implementações, é compatível com o MariaDB. Caso você queira reaproveitar esta WebUI original com novas instalações já baseadas no PostgreSQL ao invés do MariaDB, ou utilizar como WebUI o Grafana sobre o MariaDB, ao invés da WebUI original, você realmente terá que &quot;por a mão na massa&quot; e fazer todos os ajustes de códigos necessários, etc. Atualmente existem 12 dashboards &quot;prontos&quot; para atuar especificamente sobre a base de dados desta solução por openBMP/SNAS, mas nada impede que você construa os seus próprios dashboards para atender as suas necessidades mais específicas!<br /> * '''Docker:''' a implementação do SNAS ou de qualquer customização derivada a partir deste não depende exclusivamente do Docker! Você pode montar a solução do zero e do jeito que bem entender. Só vejo que há benefícios associados à separação destas aplicações com a abordagem por containers. Sem contar que, para um setup inicial rápido para fins de conhecer o potencial do SNAS, você poderá clonar uma instalação literalmente pronta e colocá-la para rodar em questão de minutos! Lá na frente você então poderá decidir-se como deverá ser a sua instalação definitiva em ambiente de produção, podendo ser em Docker ou não.<br /> [[Arquivo:Bpf-gerbgp-snasdocker.jpg|centro|miniaturadaimagem|900x900px|Cenário: SNAS em containers Docker]]<br /> Apesar de termos basicamente uma solução &quot;pronta&quot; contendo os componentes acima, é possível conceber diversos tipos de integrações com sistemas desenvolvidos internamente ou com soluções comerciais, os quais, por sua vez, podem consumir os dados fornecidos pelo BMP, seja com streaming nativamente por BMP ou então com acesso direto às informações já armazenadas num banco de dados, sem contar ainda o potencial de distribuição de dados em tempo real via a facilidade introduzida com o Kafka. Os desenvolvedores do SNAS inclusive sugerem este e outros cenários de integração em diversas áreas de sua documentação. Um destes cenários destaco a seguir:<br /> [[Arquivo:Bpf-gerbgp-snas.jpg|centro|miniaturadaimagem|900x900px|Exemplo de cenário de integração do SNAS]]Todavia, a solução que será apresentada a seguir é baseada integralmente (e somente) no SNAS, contemplando duas possibilidades para o banco de dados: instalação original baseada no MariaDB + frontend WebUI do SNAS, e instalação baseada no PostgreSQL e integração com o Grafana, juntamente com os dashboards específicos para os nossos objetivos de monitoramento. Em termos de funcionamento desta integração envolvendo as duas possibilidades em termos de bancos de dados e os frontends WebUI original e Grafana, a ilustração a seguir poderá prover uma elucidação adequada:<br /> [[Arquivo:Bpf-gerbgp-snasio.jpg|centro|miniaturadaimagem|900x900px|Coletor, DB e Frontend do SNAS.io (Fonte: snas.io)]]'''Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos'''<br /> <br /> Um caso real aqui obtido com um ISP que realiza o monitoramento por BMP juntamente com painéis por Grafana. Uma realidade é como o seu Sistema Autônomo (você) enxerga o mundo, e outra coisa é como as demais empresas com presença na Internet enxergam o seu AS (você). Uma facilidade muito interessante de um dos 12 dashboards &quot;prontos&quot; para o SNAS é a capacidade de visualização de qualquer ASN na perspectiva das tabelas BGP do seu ASN (você). Uma vez que o coletor BMP (''openbmp'') recebe/coleta as mensagens vindas dos roteadores monitorados, os dados contidos nestas mensagens são reorganizados e repassados diretamente para o Kafka que as comunica/repassa para a base SQL. Este dashboard do Grafana então realiza consultas sobre as diversas tabelas, constrói e representa as informações que destacam como um determinado ASN - e você pode consultar praticamente qualquer ASN neste dashboard - é visto a partir do ASN da sua empresa (você). O dashboard plotará algumas informações bem relevantes, tais como as relações de upstreams e downstreams do ASN pesquisado, juntamente com a resolução correspondente às bases IRR, incluindo os objetos route/route6 identificados para aquele ASN.<br /> <br /> Esta ferramenta poderá ser muito útil não apenas para você, administrador do AS da sua empresa, mas para que os demais ASs possam ter a liberdade de estudar como são vistos a partir do AS da sua empresa, ou seja, um bom esforço de cooperação para facilitar a vida de outros profissionais/empresas quando estes estiverem diagnosticando eventuais problemas relacionados ao roteamento de/para o seu AS.<br /> [[Arquivo:Bpg-gerbgp-bmpasvniew.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para funcionalidade Looking Glass'''<br /> <br /> Looking Glass não é novidade alguma, muito pelo contrário. Mas me surpreende a quantidade de ASNs que não disponibilizam esta ferramenta, à título de &quot;esforço de cooperação&quot;, para que terceiros (outros profissionais e empresas) possam consultá-lo no intuito de diagnosticar e resolver problemas de roteamento associados aos anúncios por BGP. Inacreditável!<br /> <br /> Embora Looking Glasses sejam bastante úteis e conhecidos, há uma limitação aqui: ao consultar um Looking Glass sobre um determinado prefixo/rota, a resposta será sempre aquilo que estiver constando no momento em que você estiver realizando aquela consulta. Perde-se o tato no que concerne ao que poderia ou pode ter acontecido com relação ao prefixo consultado: &quot;''quantas vezes houve alterações nas propriedades desta rota?''&quot;, &quot;''esta rota estava presente neste LG ontem a noite, quando meus usuários reclamaram problemas de acesso?''&quot;, &quot;''qual é a frequência de oscilações das minhas rotas neste ASN por um determinado upstream?''&quot;, e coisas deste tipo. E é justamente nessas horas que este dashboard com funcionalidade estilo Looking Glass poderá ser extremamente útil.<br /> <br /> Este dashboard, também produzido com o Grafana, permite que você possa pesquisar sobre um prefixo e obter, através de uma linha temporal, todo o histórico de mudanças associadas ao anúncio deste prefixo/rota pesquisado, e isto certamente deverá responder a muitos de seus questionamentos. Infelizmente não é possível fazer pesquisas sobre outras propriedades da rota, tais como pesquisas sobre os atributos, principalmente sobre o AS_PATH. Mas creio que isto seja viável no ponto de vista de implementação, cabendo a você estudar toda a estrutura de dados mantida na base SQL, &quot;acertar&quot; a mão nas ''queries'', e desenvolver o seu próprio dashboard para uma consulta por expressão regular e afins!<br /> [[Arquivo:Bpg-gerbgp-bmplg.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]<br /> [[Arquivo:Bpg-gerbgp-bmplg2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos'''<br /> <br /> Outro dashboard montado com o Grafana que oferece uma utilidade tremenda: a capacidade de consultar o histórico de anúncios originados a partir de um determinado ASN! Na verdade, são 3 dashboards distintos que oferecem visibilidades sobre prefixos com ordenamento &quot;''por prefixo''&quot;, &quot;''por peer''&quot;, &quot;''por ASN''&quot;.<br /> <br /> Este tipo de consulta pode ser muito útil quando desejamos compreender as frequências de alterações nas rotas originadas em um ASN, em particular quando seus usuários estiverem reclamando de problemas de acesso a conteúdos vinculados a estas redes. Isto inclusive poderá ser muito útil para saber quais de seus upstreams diretos são mais &quot;estáveis&quot;, já que alterações frequentes e recorrentes destes anúncios por um determinado peer podem indicar que um dos seus upstreams está passando por alguma dificuldade, por exemplo, ou executando manobras nas políticas de roteamento em um determinado horário, ocasionando em oscilações e instabilidades na convergência do seu BGP.<br /> <br /> As pesquisas podem ser realizadas sobre um destes 3 dashboards designados para esta finalidade, conforme:<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas especificamente a um prefixo qualquer:''''' você poderá usar o dashboard &quot;''Prefix History (by Prefix)''&quot; para visualizar todas as mudanças associadas ao prefixo em questão, tais como a data/hora, tipo de evento (''advertised'', ''withdrawn''), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, o prefixo/rota consultado, o ASN de origem, a lista de AS-Path associada ao prefixo, e as communities associadas a cada prefixo identificado neste período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a quaisquer prefixos originados especificamente em um ASN qualquer:''''' você poderá usar o dashboard &quot;''Prefix History (by ASN)''&quot; para determinar características tais como data/hora, tipo de evento (''advertised'', ''withdrawn''), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, os prefixos/rotas deste ASN identificados neste período, o ASN de origem consultado, a lista de AS-Path associada a cada um dos prefixos identificados neste período, e as communities associadas a cada prefixo identificado neste período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a eventos referentes a quaisquer prefixos e de quaisquer ASNs, coletados a partir de um roteador monitorado combinado com cada peer:''''' você poderá usar o dashboard &quot;''Prefix History (by Peer)''&quot; para filtrar a origem dos eventos conforme coletados pelos roteadores monitorados pelo coletor BMP, incluindo data/hora, tipo de evento (''advertised'', ''withdrawn''), roteador monitorado, peer externo, prefixo, lista de AS-Path, e communities associadas à cada rota identificada neste período conforme reportado pelo roteador monitorado.<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por ASN]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por Peer]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis3.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por prefixo]]'''Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos'''<br /> <br /> Um dashboard mais &quot;cosmético&quot; ou &quot;visual&quot;, mas não menos importante. Com este painel você será capaz de identificar, através de seus gráficos, eventuais anomalias associadas às sessões BGP e de suas respectivas atividades relacionadas a anúncios, tais como volume e frequência de eventos ''advertised'' e ''withdrawn'', anúncios (''advertised'') por roteador, retiradas (''withdrawn'') por roteador, ''Updates'' por peer e ''Withdraws'' por peer.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmptop.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de de incidentes de segurança como BGP'''<br /> <br /> Conforme comentado anteriormente, o container que oferece o componente '''''openbmp_psql''''' (PostgreSQL) não contém apenas o PostgreSQL: há ainda a presença do ''TimescaleDB'' e de um '''''validador de RPKI'''''. Na medida em que os dados coletados pelo ''openbmp'' são armazenados na base de dados via o interfaceamento com o ''Kafka'', rotinas são executadas em segundo plano para identificar os registros ROA ''Valid'', ''Unknown'' ou ''Invalid'' referentes a cada um dos prefixos mantidos nas diversas tabelas acomodadas pela solução. Este dashboard permite apresentar um &quot;mapa&quot; de quantos ou quais prefixos um ASN possui erros de validação do RPKI. E, em adição, rotinas secundárias são invocadas para a realização de consultas sobre as bases de ''Internet Routing Registry'' (IRR) referentes a estes mesmos prefixos armazenados na base de dados da solução.<br /> <br /> Consequentemente, através deste dashboard por Grafana, você passa a ter condições de identificar potenciais incidentes relacionados a sequestro de prefixos (''hijacks'') e vazamento de rotas (''route leaks'') associados a um ASN específico sobre o qual você poderá realizar esta consulta. Isto poderá ser útil para visualizar problemas em potencial envolvendo os anúncios de prefixos, os quais podem ser recusados tanto pelas políticas de roteamento do seu próprio ASN quanto pelas políticas de roteamento de upstreams, pois, cada vez mais, as empresas tem adotado certo grau de automação na hora de implementar os filtros necessários para o envio e recebimento de anúncios envolvendo seu cone de clientes, ou seja, filtros de rotas que fatoram o estado de validação do RPKI (descarte de ROA inválido) e também o validação por IRR. <br /> <br /> Apesar de não ser &quot;perfeito&quot; e nem 100% garantido, este dashboard pode ser particularmente útil quando estamos interessados em observar o estado geral da segurança do roteamento BGP no que tange à validade dos anúncios por RPKI e IRR, com maior foco na deteção de ''hijacks'' e ''route leaks''.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de Hijacks e Route Leaks]]<br /> [[Arquivo:Bpf-gerbgp-incidents.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento incidentes de segurança do BGP (Fonte: snas.io)]]<br /> <br /> '''Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR'''<br /> <br /> Este painel aproveita grande parte dos componentes citados no painel anterior (validador RPKI e consultas ao IRR) para fornecer uma visualização mais simplificada de quantos prefixos mantidos na base apresentam algum problema de validação RPKI ou IRR.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR]]'''Caso de uso: monitoramento de sessão BGP por BMP com a WebUI nativa do SNAS.io''' <br /> <br /> O monitoramento por BMP possibilita a extração de algumas informações que atendem a diversas das demandas operacionais do cotidiano do ISP, como, por exemplo, a verificação do estado e demais informações relacionadas às sessões BGP, com resultado parecido com aquele que você obteria com um comando &quot;''show bgp neighbor''&quot; de um roteador.<br /> <br /> [[Arquivo:Bpf-gerbgp-snaspeer info.png|centro|miniaturadaimagem|800x800px|Caso de uso: Peer Info com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: painel Top 20 de prefixos anunciados e removidos com a WebUI nativa do SNAS.io''' <br /> <br /> Com funcionalidade similar ao que foi mostrado no painel AS View com o Grafana, a interface WebUI original do SNAS.io provê uma visibilidade geral do AS numa relação &quot;Top 20&quot;.<br /> [[Arquivo:Bpf-gerbgp-snastop20.png|centro|miniaturadaimagem|800x800px|Caso de uso: Top 20 prefixos anunciados e removidos com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: análise de segurança com a WebUI nativa do SNAS.io''' <br /> <br /> Com visibilidade similar ao que foi demonstrado em alguns painéis anteriores, esta facilidade permite uma rápida visualização acerca da quantidade de ASNs com problemas de validação do RPKI.<br /> [[Arquivo:Bpf-gerbgp-snastsecurity report.png|centro|miniaturadaimagem|800x800px|Caso de uso: análise de segurança com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snasrpki drill down.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatório de violação de RPKI com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: integração e visibilidade com BGP Link-State (BGP-LS)'''<br /> <br /> Para atender à necessidade de aplicações que exijam visibilidade topológica em áreas IGP ou mesmo em sistemas autônomos, uma AFI/SAFI para o BGP foi definida para permitir que este protocolo carregue em si as informações detalhadas sobre os estados de links, ou seja, a topologia da rede é codificada nos NLRI e as propriedades de objetos são codificadas em atributos do BGP-LS. Esta função do SNAS.io permite mostrar os detalhamentos topológicos transportados pelo BGP para que engenheiros de rede compreendam como melhor otimizar o fornecimento de determinados perfis de conteúdos.<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate map traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate SPF and traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: relatórios por Sistema Autônomo com a WebUI nativa do SNAS.io'''<br /> <br /> Como o próprio nome sugere, por esta interface podemos informar um número de AS e obtermos informações detalhadas incluindo os registros correspondentes das bases IRR, os prefixos originados pelo ASN pesquisado, e, conforme o entendimento do BGP, a relação de upstreams e downstreams daquele ASN.<br /> [[Arquivo:As view.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatórios por AS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> <br /> ==== Caso de uso: monitoramento, analíticos e big data com o Streaming Network Analytics System (SNAS/openBMP) em combinação com o Platform for Network Data Analytics (PNDA) ====<br /> A combinação do PNDA com o SNAS funciona como uma espécie de &quot;''unha e carne''&quot;, pois agrega muitas facilidades que trazem à tona os padrões de visibilidade e transparência acerca do comportamento geral do BGP, em particular as métricas que mais nos preocupam no cotidiano para a tomada de decisões estratégicas. O combo &quot;PNDA + SNAS&quot; abre as portas do '''''big data''''' para as necessidades de BGP ou do roteamento do AS propriamente dito!<br /> <br /> Nesta solução, o SNAS captura os eventos BGP dos roteadores com o uso do ''BGP Monitoring Protocol'' (BMP), exatamente conforme demonstrado anteriormente, só que, em seguida, o SNAS encaminha os eventos coletados via ''Logstash'' para o cluster PNDA através de uma interface que o SNAS mantém com o Kafka - daí uma das aplicabilidades de termos inserido o Kafka neste contexto. O HDFS do PNDA oferece a capacidade de registrar e manter grandes quantidades de dados históricos de eventos, portanto a solução é bem escalável. Na sequência, uma aplicação baseada no Spark cria as consultas que são executadas sobre os dados, extraindo as informações desejadas. Os resultados são então armazenados no componente HBase do PNDA e expostos por meios de uma API REST, onde os usuários/administradores poderão usar uma interface Web amigável para visualizar estes resultados.<br /> <br /> Para os propósitos aqui discutidos, o PNDA executa os seguintes procedimentos com as suas respectivas tecnologias embarcadas:<br /> * Entrada de dados por uma infinidade de opções, incluindo '''''Logstash''''', '''''Open Daylight''''', '''''Bulk Ingest''''' tool, '''''SNAS.io''''', '''''SNMP''''', '''''pmacct''''', '''''Cisco IOS XR Telemetry''''', etc.<br /> * Distribuição de dados por '''''Apache Kafka''''' e '''''Zookeeper'''''.<br /> * Processamento de stream em alta velocidade com '''''Spark Streaming'''''.<br /> * Processamento em lote de alto volume com '''''Spark'''''.<br /> * Exploração de dados de forma livre com o '''''Jupyter'''''.<br /> * Consulta estruturada sobre big data com '''''Impala'''''.<br /> * Manipulação de séries temporais com '''''OpenTSDB''''' e '''''Grafana'''''.<br /> O PNDA é bastante sofisticado no que diz respeito às tecnologias que são disponibilizadas. Uma instalação padrão inclui os seguintes:<br /> * '''''SaltStack:''''' é um software de código aberto baseado em Python para automação de TI orientada a eventos, execução remota de tarefas e gerenciamento de configurações.<br /> * '''''OpenStack Heat templates:''''' o Heat implementa um mecanismo de orquestração para ativar vários aplicativos de nuvem compostos com base em modelos na forma de arquivos de texto que podem ser tratados como código.<br /> * '''''AWS CFN templates:''''' o AWS CloudFormation oferece uma linguagem comum para modelar e provisionar recursos de aplicativos da AWS e terceirizados em um ambiente de nuvem.<br /> * '''''Apache Kafka:''''' é literalmente a &quot;porta da frente&quot; para a entrada dos fluxos dados originados pelos equipamentos da rede.<br /> * '''''Bulk Ingest:''''' atuando como alternativa ao Kafka para acomodar cenários de migração de dados existentes para o PNDA.<br /> * '''''Zookeeper for Kafka:''''' é utilizado pelo Kafka para descoberta e requisições de busca junto aos brokers referentes às partições que deseja consumir.<br /> * '''''JMX Proxy:''''' usado para, dentre outras coisas no PNDA, a exposição de todos os atributos MBean disponíveis em uma determinada JVM por meio de uma simples solicitação HTTP.<br /> * '''''Apache Impala:''''' atuando como um mecanismo de execução paralelo para consultas SQL com acesso de baixa latência e exploração interativa de dados no HDFS e HBase. O Impala permite que os dados sejam armazenados em formato bruto, com a agregação realizada no momento da consulta, sem a necessidade de agregação inicial de dados.<br /> * '''''CMAK (aka &quot;Kafka Manager&quot;):''''' como ferramenta de gerenciamento de clusters Kafka.<br /> * '''''ELK''''' (Logserver)<br /> ** '''''Elasticsearch:''''' um dos componentes da arquitetura de logs empregada pelo PNDA.<br /> ** '''''Logstash:''''' um dos componentes da arquitetura de logs empregada pelo PNDA, usado para receber dados de inúmeras fontes, transformação e compartilhamento de dados.<br /> ** '''''Kibana:''''' um dos componentes da arquitetura de logs empregada pelo PNDA, atuando como plugin de visualização de dados do Elasticsearch.<br /> * '''''Jupyter Hub''''' e '''''Jupyter Notebook:''''' atua como um aplicação que permite criar e compartilhar documentos que contêm código ativo, equações, visualizações e texto explicativo. No PNDA, ele suporta a exploração e apresentação de dados do HDFS e HBase.<br /> * '''''OpenTSDB:''''' atua como um banco de dados escalável de séries temporais que permite armazenar e fornecer grandes quantidades de dados de séries temporais, sem perder granularidade. <br /> * '''''Grafana:''''' atua como construtor de gráficos e painéis para visualizar métricas de séries temporais do PNDA.<br /> * '''''Anaconda:''''' o Anaconda é uma distribuição gratuita e de código aberto das linguagens de programação Python e R para computação científica. Usado para diversas funções do PNDA.<br /> * '''''Consul.io:''''' para gerenciamento de endpoints e descoberta de serviços.<br /> * '''''Apache Flink:''''' atua como uma estrutura e um mecanismo de processamento distribuído para cálculos com estado em fluxos de dados ilimitados e limitados. O Flink foi projetado para executar em todos os ambientes comuns de cluster, executar cálculos na velocidade da memória e em qualquer escala.<br /> * '''''Apache Knox:''''' atua como gateway de aplicativo para interagir com as APIs REST e as UIs das implantações do Apache Hadoop, fornecendo um ponto de acesso único para todas as interações REST e HTTP com os clusters do Apache Hadoop.<br /> O PNDA de fato propõe-se a ser uma plataforma escalável e aberta de big data, com a finalidade de suportar análises operacionais e de inteligência de negócios para redes e serviços, e não sendo uma ferramenta restrita ou específica apenas para ambientes ISP. Algumas destas tecnologias supracitadas dependem de qual distribuição Hadoop for escolhida, sendo que o PNDA pode ser implantado usando Cloudera CDH ou Hortonworks HDP. Dependendo de qual for a distribuição, componentes/pacotes adicionais serão exigidos (ex:, para uma instalação baseada no Cloudera CDH PNDA, são exigidos também Apache Avro + Crunch + DataFu + Hadoop + HBase + Hive + Hue + Impala + Kite SDK + Mahout + Parquet + Pig + Spark + Sqoop/Sqoop2 + ZooKeeper, e outros). <br /> A ilustração a seguir mostra as tantas possibilidades de recebimento de eventos e streaming com o PNDA. Note que o SNAS.io é mencionado como uma das formas de recebimento de dados:<br /> [[Arquivo:Bpf-gerbgp-pnda.jpg|centro|miniaturadaimagem|900x900px|Visão geral do PNDA (Fonte: PNDA.io)]]<br /> <br /> A integração do ''OpenBMP'' ou ''SNAS'' com o ''PNDA'' poderá ser feita usando o ''Logstash''. Conforme já demonstrado anteriormente, os roteadores monitorados enviam as mensagens BMP para o ''OpenBMP/SNAS'', o qual envia estes dados para o ''Kafka''. Por sua vez, o barramento de dados do ''Kafka'' oferece a muitos aplicativos em lote ou streaming a capacidade de acessar feeds BMP existentes de qualquer número de roteadores. A proposta aqui então é a de produzir estes dados BMP no coletor ''OpenBMP/SNAS'' e encaminhá-los para o ''Kafka'' para que possam ser consumidos pelo ''Logstash'' da instalação PNDA. Esta integração está comentada neste link&lt;nowiki/&gt;https://github.com/SNAS/openbmp/blob/master/docs/LOGSTASH.md.<br /> <br /> A interação dos administradores da rede com estes dados poderá ser feita por APIs ou por qualquer outra aplicação que seja pensada para consumir estes dados.<br /> <br /> '''Caso de uso: monitoramento, analíticos e big data com SNAS.io e PNDA.io'''<br /> <br /> Caso você ainda esteja se questionando sobre as vantagens e benefícios de incorporar conceitos de telemetria para o monitoramento do seu BGP, talvez esta seção do artigo possa convencê-lo. Um dos maiores atrativos da telemetria baseada orientada a modelos (eventos + streaming periódico) é que permite obter dados em tempo real e com flexibilidade e granularidade muito superiores aos modelos de gerenciamento tradicionais, já discutidos previamente neste artigo. Quando combinando este modelo de gerenciamento com as soluções certas baseadas em software, você passa a ter acesso a praticamente tudo aquilo que você não conseguia conceber com os modelos tradicionais.<br /> <br /> Nunca foi tão viável entrar no mundo de analíticos e big data com foco nas questões de rede, neste caso aqui o BGP. A combinação de SNAS.io e PNDA.io pode destravar a inteligência que está faltando na grande maioria dos Sistemas Autônomos que correspondem aos ISPs e pequeno e médio portes. Ou seja, big data não é mais luxo de grandes operadores de redes!<br /> <br /> Dentre tantas ações viáveis com big data sobre o BGP, é possível classificar e filtrar todo o histórico de anúncios originados e anunciados por AS, o que por sua vez permite compreender melhor como as mudanças realizadas por upstreams podem estar afetando a convergência do roteamento BGP do seu AS. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda1.png|centro|miniaturadaimagem|900x900px|Análise de prefixos originados e anunciados por AS (Fonte: pnda.io)]]Outra possibilidade é poder consultar informações detalhadas sobre qualquer AS que estiver mencionado em qualquer anúncio que tenha sido registrado e armazenado na base de dados da solução, e isto, por si só, já economiza um tempo bastante razoável, pois você não precisaria ter que recorrer a sistemas ou websites externos para obter estas informações. E sem contar que estas informações sobre estes AS podem ser processadas para representar uma infinidade de analíticos e relatórios adicionais. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda2.png|centro|miniaturadaimagem|900x900px|Informações detalhadas por AS (Fonte: pnda.io)]]Uma das necessidades mais críticas no que diz respeito aos projetos mais elaborados de engenharia de tráfego com o BGP é contar com uma visibilidade bastante aprofundada das relações entre os Sistemas Autônomos na visão do AS da sua empresa, pois isto é o que permite estudar a cadeia de relações com propriedade e conduzir - com auxílio de outros procedimentos - os estudos sobre as matrizes de tráfego, dentre outras coisas. A obtenção destas informações pelos métodos tradicionais é praticamente inviável. Por exemplo, não é viável com SNMP. Já por CLI/Scripting visando a recuperação, ''parsing'' e armazenamento destas informações numa base de dados para consultas posteriores, enfim, seria ao mesmo tempo frágil, pouco escalável, e com elevados requerimentos computacionais, ou seja, praticamente inviável. Por sua vez, o monitoramento do BGP por telemetria, combinado com soluções de software especializadas no processamento e tratamento destes dados, habilita todo um big data sobre como o AS da sua empresa se relaciona com os demais AS da Internet. Com funções inteligentes de pesquisa de baixíssimo esforço você poderá compreender como o seu AS se relaciona com os demais AS da Internet. A ilustração a seguir mostra isso:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda3.png|centro|miniaturadaimagem|900x900px|Análise de relações entre os AS associados aos anúncios mantidos na base de dados (Fonte: pnda.io)]]Outra aplicação muito útil: imagine que você precise estudar os caminhos de AS_PATH associados a determinados destinos, por exemplo, entre dois ASs quaisquer. Como você faria isto pelas vias normais? Você simplesmente teria que acessar diversos roteadores e estudar &quot;na unha&quot;, um por um, todos os anúncios em combinação com cada opção de caminho entre a origem e o destino desejados. Se você conhece bem o BGP e atua em uma operadora ou ISP de maior porte, certamente já teve que fazer este tipo de trabalho um bocado de vezes. Demanda muito tempo, foco, atenção! Pois bem, numa plataforma de analíticos &amp; big data com dados de BGP você não teria dificuldade em estudar todos os caminhos entre a origem e o destino pretendidos, e com &quot;ridículos&quot; cliques identificar quais são os caminhos ativos, quais são os caminhos de menor comprimento de AS_PATH, e quais são os caminhos de maior comprimento de AS_PATH. E tudo isto numa fração de minuto! Isto é demonstrado na ilustração a seguir:[[Arquivo:Bpf-gerbgp-pnda4.png|centro|miniaturadaimagem|900x900px|Análise caminhos &quot;ativo, mais curto, mais longo&quot; entre dois AS (Fonte: pnda.io)]]Nem tudo são flores na parte de segurança do BGP, em especial anomalias associadas a prefixos e atributo AS_PATH. Uma vez que todas as informações do BGP estão armazenadas em bases de dados bastante otimizadas para analíticos, com pouco esforço você conseguirá identificar problemas relacionados à segurança do BGP. A ilustração a seguir demonstra esta facilidade:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda5.png|centro|miniaturadaimagem|900x900px|Análise de anomalias associadas a prefixos e AS_PATH (Fonte: pnda.io)]]Mais uma funcionalidade interessante aqui: você poder estudar cada ASN identificado na base de dados da solução, consultar informações detalhadas de casa ASN, obter um histórico dos anúncios enviados e recebidos de/para cada ASN, estudar a lista de AS_PATH associada aos anúncios, pesquisar por problemas que podem estar assolando o roteamento BGP do seu AS, dentre outras necessidades.<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda6.png|centro|miniaturadaimagem|900x900px|Análise de caminhos por AS (Fonte: pnda.io)]]<br /> <br /> Por ser uma solução em grande parte baseada em software de código aberto, entendo que o potencial de customização seja absurdo. Na mão de times de desenvolvimento experientes, a sua empresa poderá customizar a solução como bem desejar, incorporando elementos diversos, ajustando, refinando, até que obtenha-se os resultados desejados pelas diversas áreas internas do negócio que possam beneficiar-se com as funções, relatórios e analíticos do monitoramento BGP.<br /> <br /> Para concluir o tema SNAS.io + PNDA.io, caso você queira experimentar uma versão minimalista (com algumas limitações e não recomendado para ambientes de produção), recomendo o [https://github.com/pndaproject/red-pnda Red PNDA]! Você poderá baixar a OVA e rodá-la como uma máquina virtual em uma sandbox para explorar e aprender a desenvolver sobre um ambiente PNDA propício.<br /> <br /> === Conclusão do artigo e próximos passos ===<br /> O tema gerenciamento por si só é algo absolutamente muito extenso, mesmo que eu tenha focado apenas no gerenciamento/monitoramento do BGP. Infelizmente, não há como realmente dissertar livremente sobre o tema em um único artigo. Todavia, está no radar de próximos artigos, aqui na wiki do BPF, conteúdos relacionados ao gerenciamento/monitoramento do BGP com os seguintes:<br /> * Aplicabilidades do ''Multi-Threaded Routing'' (MRT)<br /> * Gerenciamento e monitoramento por telemetria com exemplos de soluções (ex: Cisco IOS XR Telemetry, Pipeline, e outros)<br /> * Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> * Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> * Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> * Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> Siga acompanhando os trabalhos do Brasil Peering Forum! Espero que você tenha curtido este artigo; divulgue-o!<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> [[Categoria:Roteamento]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Conteudos&diff=2458 2020-05-25T03:14:31Z

<p>Leonardo.furtado: </p> <hr /> <div>== Conteúdos para os Operadores de Redes ==<br /> [[Arquivo:Content-BW.png|commoldura]]<br /> Nesta página você encontrará os links para os diversos artigos, how-tos, tutoriais e vídeos produzidos no âmbito do BPF e direcionados à Comunidade de Internet Brasileira. O intuito é que eles sejam úteis para o dia a dia de operação de redes, infraestrutura, boas práticas e assuntos relacionados.<br /> <br /> Para escrever um novo artigo, how-to ou tutorial e compartilhá-lo é necessário criar antes um usuário na Wiki. Existe um artigo com orientações gerais sobre [[Como Escrever na Wiki]]. Após finalizar o artigo não esqueça de indexá-lo nesta página como também compartilhar conosco na lista de emails.<br /> <br /> Caso haja interesse em publicar algum material mais completo ou algum projeto envie um email para a lista de discussão geral abordando o assunto de interesse para verificar se já existe alguém o alguma Task Force trabalhando neste assunto ou ainda verifique se já existe algo mais específico em alguma das Task Forces temáticas. Toda contribuição da comunidade é bem vinda e incentivada.<br /> <br /> Para facilitar os artigos e materiais publicados abaixo são separados por assuntos.<br /> == Direitos Autorais, Licença de Uso e Termo de Responsabilidade ==<br /> Todos os conteúdos, contribuições e obras publicados pelo Brasil Peering Forum (BPF) estão licenciados com uma '''Licença Creative Commons Atribuição-NãoComercial 4.0 Internacional'''. Consulte o nosso [[Direitos Autorais Licenca de Uso|Termo de Responsabilidade]] para verificar a licença, os direitos e restrições de uso, assim como as devidas isenções de responsabilidades.<br /> <br /> == Artigos ==<br /> <br /> === Geral ===<br /> * [[Como Escrever na Wiki]] - Passo a Passo de como criar um novo artigo e contribuir com a Wiki do BPF.<br /> * [[Assinatura MoU BPF]] - Assinatura do Memorando de Entendimento entre os membros da Board e Comitê de Programa do BPF.<br /> * [[Enciclopedia e desciclopedia da telecom|Enciclopédia e &quot;Desciclopédia&quot; da Telecom]] - Aqui reunimos expressões, acrônimos e termos conhecidos referentes ao universo de telecomunicações e ISPs.<br /> <br /> === BCOPs ===<br /> * [[Boas Praticas para Melhorar a Seguranca de seu Provedor]]‎‎ - Boas práticas a serem seguidas para melhorar a segurança de seu Provedor.<br /> * [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] - Artigo que dissemina várias áreas de atenção e práticas para o aumento da segurança da rede do Provedor.<br /> * [[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]] - Artigo dissertativo sobre boas práticas para a escolha, adoção e manutenção de software de equipamentos de redes.<br /> * [[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]] - Artigo que apresenta boas práticas e sugestões para a documentação de ambientes de redes.<br /> * [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas praticas para a implantacão do OSPF em ambientes de ISP]] - Artigo discorrendo sobre 12 boas práticas em situações envolvendo OSPF em ambientes ISP.<br /> <br /> === DNS ===<br /> * [[Porque usar um DNS local e algumas dicas para isto]] - Artigo explicativo das razões porque é uma boa prática para um ISP possuir servidores DNS Recursivos próprios do que direcionar o usuário para um servidor público.<br /> * [[DNSSEC Seguranca do DNS|DNSSEC - Seguranca do DNS]] - Artigo conceitual explicando o funcionando do DNSSEC baseado no documento DNSSEC: Securing DNS publicado pela ICANN.<br /> <br /> === Infraestrutura ===<br /> * [[Compatibilidade de GBICs e Cabos Twinax|Compatibilidade de GBICs e cabos Twinax]] - Banco de dados colaborativo sobre experiências de uso de GBICs e cabos Twinax em Roteadores e Switches<br /> * [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]] - Artigo um tanto extenso e completo cobrindo os fundamentos de programabilidade de redes<br /> <br /> === Interconexão ===<br /> * [[Modelos Interconexão]] - Artigo sobre os modelos de interconexão Peering e Trânsito<br /> * [[Looking Glass]] - Artigo com uma lista de Looking Glass nacionais e internacionais<br /> * [[CDN Peering e PNI - Brasil]] - Lista com as principais CDNs, instruções de como solicitar Servidores, Sessões Bilaterias no IX e PNIs.<br /> <br /> === Roteamento ===<br /> * [[Dimensionando Roteador para BGP]] - Considerações a serem levadas em conta ao adquirir um novo Roteador para BGP<br /> * [[Engenharia de Trafego com MPLS TE]]‎ - Artigo explicando o funcionamento do MPLS com Traffic Engineering<br /> * [[Balanceamento de Trafego em Redes MPLS]] - Artigo explicando o funcionamento de distribuição de tráfego em redes MPLS<br /> * [[Redes MPLS para Provedores]] - Artigo explicando as vantagens e benefícios de infraestruturas do provedor baseadas no MPLS<br /> * [[Fundamentos de Roteamento para Provedores]] - Artigo explorando os fundamentos de funções de Camadas 2 e 3, comutação e roteamento, em redes Ethernet IP para provedores<br /> * [[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]] - Artigo explicando as necessidades e opções para a proteção e resiliência de redes Ethernet para provedores<br /> * [[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]] - Artigo abordando as tecnologias 6PE e 6VPE em regime BGP Free Core com MPLS TE. Inclui vídeos demonstrativos<br /> * [[Introducao ao Unified MPLS|Introdução ao Unified MPLS]] - Artigo explicando a adoção do MPLS em infraestruturas de redes de grandes operadores. Inclui vídeo demonstrativo<br /> * [[Lista de Communities BGP]] - Listagem com as Communities disponibilizadas pelos principais Operadores de Trânsito IP e Internet Exchanges<br /> * [[Diferenca entre AS-OVERRIDE e ALLOWAS-IN]] - Explicação básica sobre a diferença entre os dois mecanismos anti-loop do protocolo BGP<br /> * [[Construção de Redes de Gerenciamento OOB para o ISP]] - Artigo dissertativo sobre conceitos de gerenciamento e redes Fora-de-Banda (OOB)<br /> * [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]] - Artigo explicando muitas das diferenças entre as soluções L2VPN MPLS tradicionais e o Ethernet VPN. Inclui vídeos demonstrativos<br /> * [[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]] - Artigo bem dissertativo de conceitos fundamentais que todo profissional de ISP precisa saber a respeito do BGP<br /> * [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]] - Artigo bastante didático e esclarecedor sobre as tecnologias e ferramentas para o QoS.<br /> * [[O Minimo que voce precisa saber sobre DDoS]] - Artigo explicando diferenças entre ataques DDoS e maneiras de se prevenir e mitigar.<br /> * [[Redes que descartam RPKI Invalidos]] - Uma introdução rápida ao RPKI além de listar as operadoras e provedores de trânsito Internet que já implementam o descarte de prefixos inválidos.<br /> * [[O Minimo que Voce precisa saber sobre IRR]] - Artigo explicando o que é IRR, a importância do uso, principais bases e com um tutorial de como adicionar informações em uma base.<br /> * [[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]] - Artigo bastante completo dissertando sobre o gerenciamento e monitoramento do BGP em um Sistema Autônomo.<br /> <br /> === Transmissão ===<br /> * [[Sistemas DWDM de Baixo Custo]] - Artigo explicado sobre como projetar um sistema DWDM de baixo custo<br /> <br /> === Capacitação ===<br /> * [[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]] - Artigo didático que comenta boas práticas para ações de suporte na rede do ISP<br /> * [[Aprimorando a Disponibilidade da rede do ISP]] - Artigo com vídeo explicando os fundamentos de disponibilidade das infraestruturas de redes do provedor<br /> * [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]] - Artigo que destaca positivamente o eTOM BPF do Frameworx como conceito de remodelagem de operação e de negócios de ISPs<br /> <br /> == How-tos e Tutoriais ==<br /> <br /> === Geral ===<br /> * [[Como reportar abusos ao Google]] - Instruções sobre como reportar servidores com conteúdos maliciosos hospedados pelo Google<br /> * [[Como configurar o Winbox no MacOS Catalina]] - Tutorial sobre como executiar o Winbox em 64Bits no MacOS Catalina<br /> <br /> === DNS ===<br /> * [[Melhorando a performance e resiliencia da rede com Recursive DNS Anycast|Melhorando a performance e resiliência da rede com Recursive DNS Anycast]] - Tutorial que apresenta uma técnica interessante para maior disponibilidade e desempenho dos servidores DNS para os provedores<br /> <br /> === Boas Práticas ===<br /> * [[Boas práticas de segurança para roteadores Mikrotik]] - How-to com orientações de segurança e regras a serem aplicadas em roteadores Mikrotik rodando RouterOS.<br /> * [[Como consultar e corrigir a geolocalizacao de seus IPs|Como Consultar e Corrigir a Geolocalização de IPs]] - Tutorial explicando como consultar e corrigir as informações de geolocalização de alocações de um ASN.<br /> * [[MANRS]] - Passo a passo de como cumprir todos os requisitos do MANRS e para se ter um Sistema Autônomo e uma Internet mais segura<br /> * [[PeeringDB - como se cadastrar e atualizar seus dados|PeeringDB - Como se cadastrar e atualizar seus dados]] - Passo a passo de como realizar o cadastro no PeeringDB e preencher as informações necessárias<br /> <br /> === Edge ===<br /> * [[Concentradores PPPoE com IPv6]] - Como habilitar suporte a IPv6 e distribuição de prefixos para usuários finais em diferentes concentradores.<br /> <br /> === Infraestrutura ===<br /> * [[Log de Portas de Origem em Servidores Web]] - Como adicionar a porta de origem ao log dos Servidores Web e ser capaz de identificar usuários atrás de CGNAT.<br /> * [[CGNAT na pratica|CGNAT na prática]] - Tutorial sobre como configurar um servidor Linux com netfilter para CGNAT com ajustes de configurações voltadas para performance.<br /> * [[Tutorial DNS Hyperlocal]] - Tutorial descrevendo como hospedar uma cópia da zona raiz de DNS para que os servidores Recursivos locais possam consultar com maior performance e eficiência.<br /> * [[Monitoramento-telegraf|Monitoramento Telegraf]] - Como configurar uma solução Telegraf + InfluxDB + Grafana para monitoramento via ICMP de destinos desde diferentes endereços de origem.<br /> * [[Como Ter Seu Proprio Looking Glass|Como Ter Seu Próprio Looking Glass]] - Tutorial ensinando como o ISP poderá facilmente disponibilizar seu próprio Looking Glass para visibilidade e suporte à problemas com o BGP.<br /> * [[Como capturar pacotes no Mikrotik]] - Tutorial ensinando como realizar captura de pacotes no Mikrotik visando a análise e depuração de protocolos e conversações.<br /> * [[Como Monitorar 95th percentile]] - Tutorial demonstrando como monitorar tráfego 95th percentile para cobrança de clientes e possibilidade de exportar dados através de um script.<br /> * [[Orquestrando sua rede com Ansible e Gitlab]] - Tutorial ensinando a utilizar modelos de dados, em uma estrutura CI/CD com Ansible e GitLab.<br /> * [[464XLAT utilizando a ferramenta Jool]] - Tutorial sobre como configurar um ambiente utilizando o mecanismo de transição 464XLAT com a ferramenta Jool.<br /> * [[CGNAT com F5 BIG-IP]] - Tutorial de apresentação e demonstração da solução de CGNAT com a plataforma F5 BIG-IP.<br /> <br /> === Interconexão ===<br /> * [[Ajustes de ARP Cache para o IX]] - Tutorial explicativo da problemática do ARP cache e comandos para serem aplicados em múltiplos vendors para melhor operação no IX.<br /> <br /> === IPv6 ===<br /> * [[IPv6 no TPLink WR840N v2]] - Como ativar IPv6 na CPE TPLink WR840N v2<br /> * [[IPv6 na ONU Huawei HS8546 v2]] - Como ativar IPv6 na ONU Huawei HS8546 v2<br /> * [[IPv6 no Mikrotik CPE]] - Como ativar IPv6 em uma CPE Mikrotik (RouterOS)<br /> * [[IPV6 no Ubiquiti AirOS6|IPv6 no Ubiquiti AirOS6]] - Como ativar IPv6 em uma CPE Ubiquiti com AirOS6<br /> * [[IPV6 no Ubiquiti AirOS8|IPv6 no Ubiquiti AirOS8]] - Como ativar IPv6 em uma CPE Ubiquiti com AirOS8<br /> * [[Ipv6-TL-WRN849N|IPv6 no TPLink WRN849N]] - Como ativar IPv6 em uma CPE TPLink WRN849N<br /> * [[IPV6 no Intelbras Wom|IPv6 no Intelbras WOM]] - Como ativar IPv6 em uma CPE Intelbras WOM 500, WOM 5000 MIMO, WOM 5a-23 e WOM 5a MIMO<br /> * [[IPv6 no Dlink Dir-615|IPv6 no Dlink DIR 615]] - Como ativar IPv6 em uma CPE Dlink DIR 615, DIR 608, DIR 610 e DIR 611<br /> * [[IPV6 no DLINK DIR-882|IPv6 no D-Link DIR-882]] - Como ativar IPv6 em uma CPE D-Link DIR-882<br /> * [[Acesso via IPv6 Link-Local]] - Uma maneira de acessar equipamentos via IPv6 Link-Local em caso de perda de conectividade por IPv4<br /> * [[Como Ativar IPv6 em Servicos de Hosting e CDN]] - Tutorial sobre como ativar IPv6 nos serviços de Hosting e CDN mais utilizados<br /> * [[Servidor DNS Recursivo com IPV6 e DNSsec]]- Mini tutorial sobre IPv6 e DNSsec em DNS recursivo Unbound.<br /> * [[Gerando Log de IPv6 Delegation no Mikrotik]] - How to explicando como registrar em um servidor Syslog o Prefixo IPv6 entregue para o usuário em concentradores Mikrotik<br /> <br /> === Roteamento ===<br /> * [[Como fazer com que um determinado conteudo saia por um link especifico|Como fazer com que um determinado conteúdo saia por um link específico]] - Tutorial bem objetivo ensinando como manipular o roteamento para o recebimento de tráfego em seu AS<br /> * [[Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei|Configuração de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei]] - Tutorial sobre como configurar filtros usando XPL em Huawei<br /> * [[UTRS Registro e Configuracao|UTRS - Registro e Configuração]] - Artigo que explica o funcionamento do serviço UTRS do Team Cymru, passo a passo para solicitação e configurações exemplo.<br /> <br /> == Tech Notes ==<br /> Esta seção contém contribuições fornecidas por fabricantes (&quot;''vendors''&quot;) acerca de suas soluções, tecnologias disponíveis, diferenciais de mercado e afins.<br /> * [[Otimizacao de balanceamento de tráfego em Link Aggregation utilizando DLB e FAT em switches Datacom|Otimização de balanceamento de tráfego em Link Aggregation utilizando DLB &amp; FAT em switches Datacom]] - Artigo dissertativo acerca das soluções DLB e FAT do portfólio de switches da Datacom<br /> <br /> == Informativos ==<br /> Os informativos do Brasil Peering Forum são editados de forma quinzenal, dependendo do conteúdo e relevância e contém as principais notícias e novidades do mercado de Infraestrutura de Telecom e Internet.Todos eles são também enviados para a [https://listas.brasilpeeringforum.org/mailman/listinfo/bpf Lista Pública de Discussão] do BPF. Inscreva-se para receber as notificações.<br /> * [[Informativo Infra 01]] - 16/09/2019<br /> * [[Informativo Infra 02]] - 22/09/2019<br /> * [[Informativo Infra 03]] - 25/10/2019<br /> * [[Informativo Infra 04]] - 04/11/2019<br /> * [[Informativo Infra 05]] - 17/11/2019<br /> * [[Informativo Infra 06]] - 02/12/2019<br /> * [[Informativo Infra 07]] - 29/12/2019<br /> * [[Informativo Infra 08]] - 26/01/2019<br /> * [[Informativo Infra 09]] - 16/02/2020<br /> * [[Informativo Infra 10]] - 09/03/2020<br /> <br /> == Vídeos ==<br /> <br /> === Eventos ===<br /> * [https://www.youtube.com/watch?v=KG2JZ0A_9yY Painel sobre Peering ocorrido durante o Future ISP em Maio de 2018]<br /> * [https://www.youtube.com/watch?v=8GVHB52qu5k Apresentação do Brasil Peering Forum feita por Uesley Correa]<br /> * [https://www.youtube.com/watch?v=SE8YEuVXMWQ Dever de Casa e o Impacto da Negligência Técnica e Administrativa de Participantes do IX-BR], por Elizandro Pacheco no IX Forum 12<br /> * [https://www.youtube.com/watch?v=2oq7pMBF7Oc Tudo que você gostaria de saber sobre transmissões ópticas e WDM], por Tiago Setti no IX Forum 12<br /> * [https://www.youtube.com/watch?v=Obh98S5xyQA Automatização de Listas de Prefixos em Peering BGP - Como fazer e sua importância], por Douglas Fischer no GTER 46<br /> * [https://www.youtube.com/watch?v=hbEC2Sf5o20 BIER: Evolução do IP Multicast, por Tiago Setti] no GTER 46<br /> * [https://www.youtube.com/watch?v=H-m0sKr8I0Q Problemas e soluções na identificação de usuário IPv6 usando RouterOS], por Uesley Correa no GTER 46<br /> * [https://www.youtube.com/watch?v=WjSps5huDGU Painel - Trânsito Burstable com 95th] percentil, por Fernando Frediani, Fábio Monteiro, Edivan Silva e Tiago Setti no GTER 46<br /> * [https://www.youtube.com/watch?v=4-77r2PGKB4 BSDRP - Uma opção de softrouter com FRR], por Antonio Donizeti Corazza Jr no GTER 46<br /> * [https://www.youtube.com/watch?v=CjTcI0-UApI Ataques DDoS como ação anti-competitiva: prevenção, mitigação e reação], por Thiago Ayub no GTER 46<br /> * [https://youtu.be/qBD7zCnbTF4 Automatização de Listas de Prefixos em peering BGP], por Douglas Fischer no LACNIC 31/FTL<br /> * [https://youtu.be/8DdtN_fj_uQ BSDRP - Uma opção de sofftrouter com FRR], por Junior Corazza no LACNIC 31/FTL<br /> * [https://www.youtube.com/watch?v=utPs-sXsOZg A importância de um CGNAT bem feito], por Fernando Frediani no GTER 47<br /> * [https://www.youtube.com/watch?v=l2tVyz1Ba1A Entrevista sobre ataques e mitigação DDoS], com Thiago Ayub<br /> * [https://youtu.be/ElA_71zsc6Y Entrevista com o Carlos Martínez sobre RPKI], com Carlos Martínez, CTO do LACNIC, na 9a Semana de Infraestrutura da Internet no Brasil.<br /> <br /> === Hangouts ===<br /> [https://www.youtube.com/watch?v=fy4efZZ-yvg Desmistificando o CGNAT] - Hangout realizado para debater o assunto e desmistificar esta necessidade dos ISPs. Durante a conversa foram abordadas boas práticas, diferentes modelos de CGNAT, problemas com Jogos e um case prático.<br /> <br /> [https://www.youtube.com/watch?v=ePMfMv3UVOs Boas Práticas de DNS] - Hangout realizado que debateu as melhores práticas para se ter um bom serviço de DNS rodando no seu provedor, a importância de ter seu DNS Reverso configurado corretamente, quando é necessário ter um servidor Autoritativo, DNSSEC e assuntos relacionados.<br /> <br /> === Roteamento e MPLS ===<br /> * [https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores], por Leonardo Furtado<br /> * [https://www.youtube.com/watch?v=5Eg5jC2AMaQ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Parte 1] (Introdução), [https://www.youtube.com/watch?v=W8HS_y7REiM Parte 2] (Introdução ao L3VPN), [https://www.youtube.com/watch?v=TqdZYK_9rlY Parte 3] (Demonstração de Interconexões com L3VPN MPLS), [https://www.youtube.com/watch?v=bmgWGOPbkfw Parte 4] (Demonstração da Solução Carrier Supporting Carrier - (CsC)), [https://www.youtube.com/watch?v=H4SyKiGBOXM Parte 5] (Demonstração de L3VPN MPLS com VPNs &quot;Complex Overlapping&quot;), [https://www.youtube.com/watch?v=6fQ34nnk-Dk Parte 6] (Demonstração de L2VPN MPLS com AToM/EoMPLS/VPWS), por [[Usuário:Leonardo.Furtado|Leonardo Furtado]].<br /> * [https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE], por Leonardo Furtado.<br /> * [https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1] e [https://youtu.be/0N-ejxGncSU Parte 2], por Leonardo Furtado.<br /> * [https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS], por Leonardo Furtado.<br /> * [https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN], por Leonardo Furtado.<br /> * [https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP, da Comunidade de Suporte Cisco em Português], por Leonardo Furtado.<br /> * [https://youtu.be/zSiFtIgT1Ig Palestra de Evoluções de Tecnologias MPLS com Segment Routing e EVPN] - Future ISP 2018, por Leonardo Furtado.<br /> * [https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing, da Comunidade de Suporte Cisco em Português], por Leonardo Furtado<br /> * [https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP], por Leonardo Furtado<br /> * [https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP], por Leonardo Furtado<br /> * [https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)], por Leonardo Furtado<br /> === Capacitação ===<br /> * [https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP], por Leonardo Furtado<br /> * [https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP], por Leonardo Furtado<br /> * [https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP], por Leonardo Furtado</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Solucoes_para_o_gerenciamento_efetivo_do_bgp_em_um_sistema_autonomo&diff=2457 2020-05-25T02:38:08Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo ===<br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Todos os engenheiros de redes sênior que atuam em ISPs, ou em qualquer empresa séria que possua um Sistema Autônomo, compreendem a importância em estudar corretamente a farta quantidade de informações referentes às sessões e respectivas tabelas BGP, e não apenas na perspectiva da tabela BGP de seus próprios e respectivos ASNs, e sim estendendo estes estudos e tratamentos de dados na perspectiva de vários pontos de monitoramento, os quais incluem coletores, ''route views'', ''looking glasses'', e afins, espalhados pela Internet. Ou seja, como você (ou, neste caso, o seu ASN) vê o mundo ao seu redor, e como as várias partes do mundo (ASNs em suas respectivas regiões) vêem o seu ASN.<br /> <br /> Isto para sintetizar primariamente as iniciativas de prevenção dos dois principais tipos de incidentes envolvendo o roteamento de Internet, a saber: ''route leaks'' e ''prefix hijack''. Só que as necessidades de um ASN no que tange ao monitoramento de seu BGP vão bem além do que somente (embora gravíssimos) incidentes com ''route leaks'' e ''prefix hijacks'', para os quais, inclusive, já existem BCOPs específicas para prevenção e mitigação, como é o caso do &lt;nowiki&gt;RFC 7454&lt;/nowiki&gt; / BCP 194, BCP 38, BCP 185, e MANRS. Há muito mais coisas a serem observadas e tratadas com relação ao BGP do que apenas as questões de segurança.<br /> <br /> Ou seja, em adição às questões de segurança, o Sistema Autônomo/ASN precisa monitorar constantemente, dentre dezenas de objetos e métricas gerenciáveis, e seus respectivos KPIs, e de uma magnitude grande de componentes, o '''''&lt;u&gt;seu&lt;/u&gt; BGP''''' como um todo. Isto para que respostas possam ser fornecidas para sanear diversos desafios que vão além da segurança do roteamento daquele ASN (e estendendo-se para seu cone de clientes), tais como a escalabilidade, engenharia de tráfego com ênfase na redução inteligente de custos e com potencial aumento de qualidade de serviço (ex: fornecer conteúdo com menor latência ao mesmo tempo em que reduzindo custos com esta iniciativa); planejamento de capacidades, planejamento das métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, os padrões de convergência da rede, plano diretor de investimentos, desenvolvimento e manutenção da cesta de produtos e serviços com foco na capacidade e uso estatístico de recursos da rede, toda a parte financeira também, etc.<br /> <br /> Falando especificamente do BGP, os modelos &lt;u&gt;tradicionais&lt;/u&gt; de monitoramento possuem restrições: ''routeviews'' (com algumas exceções) e ''looking glasses'' não mantém históricos de informações sobre rotas (seja pelo prefixo direto ou pela expressão regular do atributo AS_PATH), consequentemente não se sabe o que aconteceu, quando e por quem. Além disto, uma sessão BGP somente anuncia as suas melhores rotas (''best path''), e esta informação pode ser obtida de um roteador por CLI ou outro procedimento, como o NETCONF, porém, novamente, sem dados históricos. O que algumas empresas fazem para compensar estas restrições dos modelos tradicionais com ferramentas vigentes é recorrer a soluções e sistemas que consigam manter estas informações numa base de dados que seja flexível, escalável e gerenciável, e que mantenha um histórico de mudanças sobre estes registros. Ou seja, construir e customizar sistemas específicos, ou adquirir um sistema comercial para este propósito. E que, preferencialmente, seja de fácil integração com outros sistemas (incluindo Sistemas de Suporte à Operação (OSS)).<br /> <br /> O que estou propondo aqui é ampliar os conceitos de ferramentas para o monitoramento efetivo do BGP: além de manter seus ''looking glasses'' e consultar ''route views'', onde aplicáveis, os ASN poderem manter as suas próprias bases de dados com históricos acerca de tudo o que ocorre com o BGP na perspectiva daquele ASN, de seu cone de clientes, além da sua relação com seus upstreams de trânsito IP, sessões de peering e afins. Ou seja, não apenas o &quot;snapshot&quot; do que está acontecendo na hora, mas obter informações sobre prefixos e ASNs através de uma linha temporal e para atender diversos casos e aplicações técnicas e de negócios. É o que chamamos de &quot;'''''telemetria orientada a modelos'''''&quot;, que, nos projetos mais sofisticados e completos, combina ferramentas de &quot;telemetria baseadas em eventos&quot; (obtenção de dados por CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, BMP, etc.), e &quot;telemetria de streaming periódica&quot;, com monitoramento de diversos objetos relacionados à capacidade e dados estatísticos de consumo (latência, ''throughput'', processamento) por meios de diversas ferramentas e procedimentos. Interessante, não?<br /> <br /> Em suma, este artigo está centrado na dissertação de propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!<br /> <br /> ==== Observação importante: ====<br /> Se você estiver aguardando uma solução &quot;pronta&quot; ou com uma expectativa de que eu vá fornecer aqui uma &quot;receita de bolo&quot;, lamento muito, mas não é esta a intenção do artigo! Fornecerei aqui uma visão muito mais ampla deste contexto, e tentarei desmembrar este tópico empregando alguns conceitos de pesquisa aplicada e de desenvolvimento experimental. Entenda isto como um pontapé inicial para que você consiga adquirir os conhecimentos necessários para desenvolver seus próprios conceitos de adoção tecnológica, processual e instrumental, objetivando o gerenciamento e monitoramento do BGP de seu AS, e culminando na tomada de decisão de sua parte sobre uma ou mais das seguintes possibilidades:<br /> # Investimentos em soluções comerciais existentes, com potencial de customizações e integração com outros sistemas para o atendimento de necessidades específicas do seu negócio.<br /> # Desenvolvimento de sistemas com fábrica de software própria, atendendo a todos os modelos de gerenciamento desejados.<br /> # Adoção de ferramentas específicas para o atendimento de necessidades igualmente específicas, tais como soluções de código aberto ou até mesmo de ordem comercial.<br /> <br /> === Um &quot;abre-alas&quot; sobre a importância e missão dos sistemas de gerenciamento no geral ===<br /> Antes de começarmos, gostaria de comentar uma característica do meu trabalho e que afeta o meu julgamento por completo. Aqueles que me conhecem de longa data sabem que sou um tanto insistente em algumas das minhas análises, visões, conclusões e objeções. Para estas pessoas que me conhecem, quantas vezes já não ouviram o Leonardo Furtado citar a seguinte frase?&lt;blockquote&gt;''&quot;Muitos profissionais de ISP (incluindo alguns perfis de gestores) pecam na hora de investir e de tomar decisões importantes para seus negócios: adquirem soluções tecnológicas focando apenas ou principalmente nas necessidades de curto prazo, muitas vezes adotando soluções minimalistas, e centradas no fator de menor custo&quot;''&lt;/blockquote&gt;A relação desta frase com o artigo em questão é óbvia, e você entenderá melhor logo a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem que haja um propósito bem definido para as áreas do negócio que realmente importam. Muitas vezes a necessidade é muito óbvia ou específica, tais como &quot;monitorar o consumo de banda referente a uma interface conectada para um upstream de trânsito IP&quot;, o que é plenamente justificável, sem dúvidas, claro! No entanto, o maior problema não reside no objeto gerenciado em questão (monitoramento de banda, monitoramento de problemas de uma interface, processamento, etc.), e sim na ausência de analíticos associados aos objetos gerenciados pelas ferramentas em questão, as quais foram adquiridas pela organização (e seja lá quais tenham sido os critérios), e que foram implantadas pelo time de engenharia ou de operações. Em outras palavras: o software está &quot;lá&quot;, implantado, e sendo (sub)utilizado pelos operadores. Mas.. quais são os reais objetivos? Quais são os indicadores desejados? Quais são os ''thresholds''? Quais são as métricas gerenciáveis daquele componente, de cada componente? Como determinados ''thresholds'' e eventos associados àquele objeto impactam no meu negócio? Quais ações e tomadas de decisões executaremos para prevenir, mitigar e responder ao eventos fornecidos pelo gerenciamento acerca daquele objeto gerenciado? Como este objeto gerenciado participa do meu negócio e nas diversas áreas, centros de custo, e contextos, incluindo comercial, reputação, financeiro (capex, opex, fluxo de caixa, etc.), engenharia (capacidade, disponibilidade, resiliência, consumo de recursos, tráfego, etc.), operações, fornecedores, etc.? A lista é grande.<br /> <br /> Com 25 anos de profissão, o que mais vi em toda a minha carreira e em muitas empresas que visitei foram soluções de gerenciamento inteiras praticamente &quot;encalhadas&quot;, subutilizadas! Sistemas complexos e por muitas vezes interessantes que, de diversas funções e capacidades disponíveis, são extraídos apenas recursos pontuais e, mesmo assim, sem que analíticos e dados importantes pudessem ser coletados, tratados e consumidos pelas áreas relevantes do negócio para que estas pudessem aproveitar estas informações para algo realmente útil, seja algo visando aprimorar a parte técnica/tecnológica ou a parte do negócio propriamente dito.<br /> <br /> Outra forma de sintetizar isto: ''&lt;u&gt;em muitas empresas não há efetivamente um projeto prevendo a construção (ou adoção/contratação) de sistemas de gerenciamento&lt;/u&gt;''. O gerenciamento efetivo ou adequado é frequentemente a parte mais negligenciada da infraestrutura.<br /> <br /> Dissertar amplamente sobre isto está fora do escopo deste artigo, mas a mensagem que gostaria de deixar aqui é bem simples: tratando-se de sistemas de gerenciamento, e não importando para qual finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), procure conduzir um projeto técnico consistente e específico para este(s) sistema(s), e que vá identificar e documentar os seguintes:<br /> * Em alinhamento com o projeto de infraestrutura vigente, incluindo todo o parque tecnológico presente (hardware e software), quais são as necessidades da área técnica da empresa, assim como de possíveis outras áreas interessadas?<br /> * Quais problemas estamos sofrendo no momento e/ou que gostaríamos de evitar?<br /> * Como cada um destes problemas, incidentes ou circunstâncias impacta nos negócios da empresa? É possível quantificar os prejuízos, quaisquer que sejam (reputação, multas, reparação, cancelamento de contratos, perda de receitas, aumento de custos imprevistos, etc.)? E quais áreas internas do negócio são impactadas? É viável fazer esta associação?<br /> * Quais deverão ser os objetos gerenciados?<br /> * Quais são as facilidades de gerenciamento suportadas pelo meu parque tecnológico (HW e SW)? E quais são as capacidades demandadas sobre cada um destes recursos?<br /> * Das tecnologias ou recursos disponíveis e suportados pela infraestrutura, quais são as melhores e mais aderentes opções para o atendimento de cada objeto gerenciado identificado? (prós e contras, matriz funcional de qualidade, etc.)<br /> * Quais deverão ser os indicadores e métricas para estes objetos gerenciados quando utilizando-se dos recursos ou facilidades de gerenciamento identificados como mais aderentes para os meus propósitos?<br /> * Como as áreas internas do negócio, onde aplicáveis, consumirão estes analíticos, indicadores e métricas?<br /> * Quais processos deverão ser estabelecidos para ações de prevenção, mitigação e reação quanto aos ''thresholds'' dos objetos gerenciados?<br /> * Dentre muitas questões.<br /> Somente após responder estas perguntas e planejar toda a iniciação do projeto de adoção de solução de gerenciamento é que você conseguirá encontrar a solução ideal, a(s) &quot;ferramenta(s)&quot;, e fazendo isto com critérios consistentes nos requisitos de facilidades, recursos, integração, custos, etc. Entendo que esta deva ser a aderência a ser pensada e projetada, assim como entendo que você precisará instaurar os processos primeiro para depois chegar a estas conclusões. Dica: para o tema &quot;processos&quot;, confira o artigo [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]! <br /> <br /> A implantação e operação de sistemas de gerenciamento, quaisquer que sejam as finalidades, deve passar primeiro por um plano de projeto que vá identificar todas as questões envolvendo necessidades, desafios, métricas desejadas, capacidades e qualidades demandadas, os objetos a serem gerenciados, as facilidades e recursos necessários, como os dados serão coletados, processados e armazenados, e como a organização como um todo deverá consumir e tirar proveito destes dados para aprimorar seus indicadores. <br /> [[Arquivo:Bpf-gerbgp-requisitos.png|centro|miniaturadaimagem|900x900px|&quot;Carroça não anda na frente de boi&quot;: exercite o planejamento antes de sair implantando ferramentas, e usufrua de melhores resultados!]]<br /> <br /> === Por que um ASN precisa investir no gerenciamento de seu ambiente BGP? ===<br /> Ou '''''quais problemas poderão ser resolvidos com o gerenciamento efetivo do BGP em seu ASN'''''?<br /> <br /> &lt;u&gt;A sequência deste artigo estará centrada quase que integralmente no &quot;BGP&quot;&lt;/u&gt; e possivelmente citarei outros elementos que participam diretamente do funcionamento deste. Ou seja, não pretendo realmente dissertar sobre necessidades, objetivos e requisitos gerais envolvendo disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isto não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?<br /> <br /> Suponhamos que as áreas de engenharia e operações de um ISP cheguem a um consenso de que é necessário ter ampla visibilidade e acesso à informações relevantes especificamente relacionadas ao BGP para que sejam discutidas formas de antecipar e mitigar riscos, e responder aos diversos tipos de incidentes relacionados às questões de segurança, disponibilidade, performance, ou seja, o SLA em geral, assim como o planejamento de capacidades e a engenharia financeira do negócio. Se tivéssemos que exercitar este consenso entre estas duas áreas, quais teriam sido alguns dos diversos critérios factíveis? Para este exercício hipotético, proponho que estes requisitos sejam devidamente categorizados da seguinte forma para melhor compreensão e dissertação de casos:<br /> * '''Segurança do roteamento BGP'''<br /> * '''Segurança do plano de controle da rede'''<br /> * '''Segurança contra ataques de negação de serviços'''<br /> * '''instabilidades do BGP'''<br /> * '''Engenharia de tráfego'''<br /> * '''Planejamento de capacidades'''<br /> * '''Reputação e conformidade'''<br /> O seu trabalho, na condição de engenheiro de rede ou arquiteto de soluções, deverá ser a busca por respostas para iniciar este planejamento!<br /> [[Arquivo:Bpf-gerbgp-planejamento.png|centro|miniaturadaimagem|900x900px|Brainstorming para o planejamento de uma solução de gerenciamento específica para o BGP]]<br /> Dissertemos um pouco mais sobre estes caso hipotético através da exposição de conceitos envolvendo '''''Necessidades''''', '''''Requisitos''''', '''''Problemas ou desafios a serem resolvidos''''' pelas organizações que operam um Sistema Autônomo, sendo provedores de acesso à Internet (ISP) ou não:<br /> {| class=&quot;wikitable&quot;<br /> |+<br /> Matriz de Necessidades, Requisitos e Desafios a serem Superados para a Demanda &quot;BGP&quot; do ISP<br /> !Categoria<br /> !Necessidade<br /> !Requisito<br /> !Problemas ou desafios a serem resolvidos<br /> !Partes interessadas<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento da segurança do roteamento BGP'''<br /> |Deteção e mitigação de prefixos Bogons<br /> |Identificação e mitigação de prefixos Bogons, Maritans e não alocados<br /> |<br /> * Evitar o recebimento e propagação de rotas referentes a prefixos Bogons, Martians e Unallocated<br /> * Aumentar a reputação do Sistema Autônomo, como parte de boas práticas para a prevenção de incidentes de segurança associados a anúncios bogons.<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de vazamento de rotas e sequestro de prefixos do ASN<br /> |Identificação e mitigação de route leaks<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Assegurar que o ASN não crie ou gere route leaks, assim como assegurar que route leaks não sejam aceitos a partir de sessões de clientes, peering e trânsito<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Encurtar o tempo de deteção de incidentes envolvendo route leaks<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de route leaks<br /> |NOC, Engenharia<br /> |-<br /> |Identificação e mitigação de sequestro de prefixos (prefix hijacks)<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Evitar que o ASN não sequestre prefixos, assim como recusar o recebimento de quaisquer anúncios com ROA (RPKI) e/ou IRR inválidos<br /> * Encurtar o tempo e detecção de incidentes envolvendo o sequestro de prefixos<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de sequestro de prefixos<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de abusos contra recursos do BGP<br /> |Controle de recebimento de anúncios de ASNs vizinhos<br /> |<br /> * Evitar abusos e possíveis impactos relacionados à capacidades e escassez de recursos<br /> * Evitar que ASNs de clientes anunciem de forma acidental ou maliciosa uma quantidade de prefixos superior à estimada ou autorizada<br /> * Evitar abusos com a desagregação através de anúncios excessivamente específicos recebidos de clientes, peering e trânsito<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> |Controle de abuso de AS-Path Prepending<br /> |<br /> * Evitar que o ASN do ISP, assim como ASNs vizinhos e o restante da Internet, sofram possíveis impactos e instabilidades quanto à prefixos com excesso de AS-Path Prepending atrelado aos anúncios<br /> * Evitar abusos quanto ao recebimento de rotas BGP que contenham AS-Path Prepending excessivos (uma forma de ''Self-Inflicted Vulnerability'')<br /> * Encurtar o tempo de detecção de incidentes desta natureza.<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da segurança do plano de controle da rede'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de incidentes de segurança contra o próprio BGP<br /> |Controle de vulnerabilidades sobre as mensagens do BGP<br /> |<br /> * Evitar indisponibilidades e outros tipos de incidentes que possam ser provocados com a exploração das mensagens do BGP (conforme (3.1. Vulnerabilities in BGP Messages do &lt;nowiki&gt;RFC 4272&lt;/nowiki&gt;)<br /> * Evitar a manipulação e injeção maliciosa de atributos sobre os anúncios por mensagens ''Update'' do BGP<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de exploração destas vulnerabilidades<br /> |SOC, NOC. Engenharia<br /> |-<br /> |Controle de incidentes de segurança lançados diretamente contra as sessões BGP<br /> |<br /> * Evitar que as sessões BGP sejam atingidas diretamente por técnicas maliciosas que visam desde o downtime/indisponibilidade, sequestro de sessões, injeção de informações errôneas<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de ataques lançados contra os processos BGP<br /> |SOC, NOC, Engenharia<br /> |-<br /> |'''Gerenciamento da segurança contra negação de serviços'''<br /> |Detecção e mitigação contra ataques DDoS<br /> |Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS<br /> |<br /> * Evitar ou atenuar efeitos adversos de indisponibilidades, instabilidades, impactos severos no SLA de clientes, prejuízos financeiros de grandes proporções, e danos na reputação da empresa<br /> * Evitar a injeção de informações maliciosas na tabela BGP que permitam livre comunicação entre hosts infectados em suas botnets<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e mitigação de DDoS<br /> |SOC, NOC, Engenharia<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento de instabilidades do BGP'''<br /> | rowspan=&quot;5&quot; |Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA<br /> |Detecção de oscilações de sessões BGP<br /> |<br /> * Evitar que ocorram instabilidades na prestação de serviços de acesso à Internet por conta de oscilações das sessões BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e problemas com as sessões BGP<br /> |NOC<br /> |-<br /> |Detecção de oscilações de rotas (route flaps)<br /> |<br /> * Evitar que ocorram indisponibilidades na comunicação com determinados serviços/destinos de Internet por conta de oscilações e intermitências quanto à convergência da tabela BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e oscilações de rotas BGP<br /> |NOC<br /> |-<br /> |Detecção de rotas eventualmente suprimidas por Dampening<br /> |<br /> * Evitar discrepâncias nas matrizes de tráfego e, de certa forma, atenuar a assimetria do roteamento IP, ''blackhole'' ou ''routing loops'' por conta da eventual supressão de rotas (dampening) executada no ASN local ou em vizinhos<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de supressão de rotas BGP e como estes eventos afetam o comportamento da rede e a disponibilidade de serviços<br /> |NOC<br /> |-<br /> |Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces<br /> |<br /> * Evitar que determinados recursos tais como capacidade de enlaces, arquiteturas de roteadores (CPU, memória, FIB, etc.) fiquem subutilizados enquanto outros elementos fiquem sobrecarregados<br /> * Evitar gargalos nas operações e transações de rede, os quais podem provocar impactos no SLA<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção de gargalos e esgotamento de recursos<br /> |NOC, Engenharia<br /> |-<br /> |Planejamento e antecipação de cenários &quot;what if&quot;<br /> |<br /> * Evitar que manobras de configurações, incluindo modificações nas políticas de roteamento e ações de engenharia de tráfego provoquem distúrbios não antecipados<br /> * Antecipar impactos na convergência e disponibilidade da rede através de uma análise preditiva envolvendo cenários de falhas<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;4&quot; |'''Gerenciamento da engenharia de tráfego'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de impactos sobre os recursos de infraestrutura decorrentes de eventos pontuais na Internet<br /> |Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento<br /> |<br /> * Superar as limitações operacionais da empresa em função da escassez de informações e a falta de visibilidade sobre os fluxos de tráfego<br /> * Aprimorar as ações de dimensionamento de recursos de infraestrutura, tais como plataformas de switches e roteadores, além de enlaces de comunicação de dados<br /> * Aprimorar os resultados das ações de engenharia tráfego para fins de acomodar melhor as conversações da rede sobre os recursos disponíveis<br /> * Atenuar ou eliminar os desafios que provocam impactos sobre o SLA de assinantes<br /> * Fornecer analíticos, dados históricos e baselines relacionados às matrizes de tráfego, com histórico de consumo por ASN, peer, prefixo, protocolo de transporte, tipo de aplicação, marcações, atributos, etc.<br /> |Engenharia<br /> |-<br /> |Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas<br /> |<br /> * Reduzir os indicadores de MTTR e MDT associados aos eventos de falhas relacionadas ao BGP<br /> * Reduzir os indicadores de reclamações por conta da violação de SLAs envolvendo indisponibilidades, latência, jitter, perda de pacotes, etc.<br /> * Reduzir os impactos provocados nas áreas internas do negócio que são destinadas ao interfaceamento com clientes, tais como comercial, atendimento a clientes, NOC, jurídico, etc.<br /> * Fornecer analíticos, dados históricos e baselines referentes aos impactos decorrentes de falhas para alimentar as tomadas de decisão e para nortear os investimentos e processos de mitigação<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Aprimoramento de SLA<br /> |Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP<br /> |<br /> * Reduzir impactos não antecipados sobre ações de engenharia de rede e de tráfego executadas pela área de engenharia ou de operações da empresa<br /> * Aprimorar as tomadas de decisão acerca das políticas de roteamento para o atendimento dos modelos de interconexão privado e público<br /> * Aprimorar as tomadas de decisão para as políticas de roteamento de acordo com os modelos de interesse de tráfego (''hot potato'', ''cold potato'', e outras diretrizes) sobre os regimes de interconexão <br /> * Fomentar ações racionais de engenharia de tráfego para equilibrar as métricas de SLA (latência, jitter, disponibilidade) sobre os custos (opex) de cada enlace de transporte e de de cada acordo de troca de tráfego<br /> |Engenharia<br /> |-<br /> |Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como MPLS TE e SR-TE<br /> |<br /> * Assegurar aderência quanto ao mapeamento do tráfego sobre os recursos locais do AS, prevendo simultaneamente as métricas de desempenho e a relação de custos de infraestrutura para a sustentação de SLAs<br /> * Promover a redução racional de custos através da associação de classes de tráfego ou de matrizes de conversação sobre os enlaces e sessões associadas às métricas de SLA de cada caso<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;3&quot; |'''Gerenciamento da planejamento de capacidades'''<br /> | rowspan=&quot;3&quot; |Planejamento de capacidades com foco na redução racional de custos operacionais<br /> |Bilhetagem e tarifação de tráfego<br /> |<br /> * Determinação da matriz de tráfego em combinação com iniciativas de bilhetagem e tarifação para determinar rateio de custos de infraestrutura nas áreas internas do negócio<br /> * Fornecer métricas de utilização dos fluxos de tráfego de interesse sobre os recursos de transporte para identificar áreas de otimização de custos<br /> * Viabilizar a compreensão da participação de cada centro de custo / área interna do negócio quanto aos padrões de consumo e contribuições orçamentárias<br /> * Viabilizar e fomentar a derivação da política de preços de produtos e serviços destinados a clientes em função das matrizes de tráfego, interesses de tráfego e modelos de interconexão<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Dimensionamento de recursos de transporte e acordos de troca de tráfego<br /> |<br /> * Planejamento de capacidades de conexões do ISP com os acordos de troca de tráfego nos regimes de peering e trânsito IP, incluindo 95th percentil<br /> |Engenharia<br /> |-<br /> |<br /> * Dimensionamento de especificações, requisitos, recursos e capacidades das arquiteturas e demais componentes de infraestrutura a serem utilizados para a sustentação dos modelos de interconexão para os perfis de tráfego<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da reputação e conformidade'''<br /> |Conquistar níveis de excelência em conformidade<br /> |Deteção e mitigação de incidentes e situações não aderentes aos frameworks e boas práticas destinadas aos Sistemas Autônomos<br /> |<br /> * Fornecer analíticos e dados históricos que classifiquem as ocorrências de incidentes provocados por eventos previstos e imprevistos pelas políticas internas da empresa<br /> * Fornecer métricas auditáveis quanto os incidentes de segurança associados ao BGP<br /> |NOC, SOC, Engenharia<br /> |-<br /> |Conquistar níveis de excelência na reputação do Sistema Autônomo<br /> |Fornecimento de ferramentas para o compartilhamento de transparência e iniciativas de suporte com outros (demais) Sistemas Autônomos<br /> |<br /> * Manutenção de sistemas e bases de informação que divulguem, dentre outros, a política de roteamento da empresa, plano de communities, &quot;normas da casa&quot;, requisitos de segurança, requisitos de interconexão, modalidades de SLA, etc.<br /> * Manutenção de sistemas e bases de informação que forneçam os pontos de contato e suporte para as demandas associadas ao BGP e contextos periféricos do AS, tais como &quot;Abuse&quot;, &quot;Peering&quot;, &quot;NOC&quot;, e outros<br /> * Disponibilização de ferramentas de autosserviço para a redução do tempo de diagnóstico e identificação de problemas por parte de NOCs de outros Sistemas Autônomos, tais como Looking Glass e outros.<br /> * Promover aderência quanto às boas práticas citadas pelos objetivos &quot;''Coordination''&quot; e &quot;''Global Validation''&quot; do ''Mutually Agreed Norms for Routing Security'' (MANRS) <br /> * Fornecer analíticos acerca da utilização das ferramentas de autosserviço para identificar necessidades de mercado, técnicas, perfil dos visitantes, áreas de interesse e geração de novas oportunidades <br /> |NOC<br /> |}<br /> <br /> === Exemplos de soluções conhecidas para o atendimento das diversas necessidades e requisitos associados ao gerenciamento do Sistema Autonomo ===<br /> No que diz respeito aos conjuntos de necessidades e respectivos requisitos fornecidos na tabela anterior, eu particularmente compreendo que tratam-se de situações absolutamente reais. Ao projetar a tabela acima, em nenhum momento pensei especificamente ou diretamente nas possíveis soluções e ferramentas que pudessem ser empregadas para cada caso, ou seja, toda a linha de raciocínio foi de fato estabelecida sobre '''''necessidades + requisitos + problemas + desafios''''' que entendo que a maioria dos operadores de redes tenham interessem em lidar em suas operações cotidianas.<br /> <br /> Todavia, chegaria o momento em que precisaríamos traduzir isto para um plano definitivamente concreto, certo? Sim, precisaríamos identificar ferramentas que conseguissem fornecer resultados para cada uma das situações descritas na tabela anterior. E é justamente isto que tentarei fazer agora: num primeiro momento, &quot;espalhar na mesa&quot; o que temos no mercado hoje; as soluções existentes que podem ser usadas para executar estes casos e cumprir com estas necessidades. <br /> <br /> Note que as ferramentas associadas a cada tipo de requisito não fornecem apenas as funcionalidades para aquele requisito em questão: tomei a liberdade de fazer desta forma apenas para deixar claro que a ferramenta foi &quot;pensada&quot; após o par &quot;necessidade + requisito&quot; ter sido identificado e confirmado para o meu conceito de projeto. <br /> <br /> Está fora do escopo desta parte do artigo qualquer esforço de validação e dissertação de aderência qualitativa (&quot;''o quão bem a ferramenta X executa e atende as necessidades, requisitos, problemas, desafios...''&quot;), assim como promover qualquer comparativo entre as opções mencionadas (&quot;''qual é a melhor ferramenta para a necessidade X?''&quot;).<br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança do roteamento BGP<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação e mitigação de prefixos Bogons, Martians e não alocados'''<br /> | rowspan=&quot;3&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://radar.qrator.net/ RADAR by QRATOR]<br /> * [https://team-cymru.com/community-services/bogon-reference/ Team Cymru fullbogons]<br /> |-<br /> |'''Identificação e mitigação de route leaks'''<br /> |-<br /> |'''Identificação de sequestro de prefixos'''<br /> |}<br /> O &lt;nowiki&gt;RFC 7908&lt;/nowiki&gt; (''Problem Definition and Classification of BGP Route Leaks'') descreve com bastante propriedade a caracterização e tipificação dos incidentes denominados route leaks, enquanto o draft-ietf-grow-route-leak-detection-mitigation-02 (''Methods for Detection and Mitigation of BGP Route Leaks'') propõe mecanismos de detecção e mitigação destes incidentes. Está fora do escopo deste artigo a dissertação sobre route leaks.<br /> <br /> Em adição, diversos artefatos contendo recomendações para a mitigação de prefix hijack foram produzidos, dentre eles o BCP 185 (''Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)''), &lt;nowiki&gt;RFC 7682&lt;/nowiki&gt; (''Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration''), &lt;nowiki&gt;RFC 2650&lt;/nowiki&gt; (''Using RPSL in Practice''), e o &quot;''Action 1: Prevent propagation of incorrect routing information''&quot; do Mutually Agreed Norms for Routing Security (MANRS). A dissertação sobre prefix hijack está fora do escopo deste artigo.<br /> <br /> As ferramentas comentadas na tabela acima podem ser usadas para fornecer dados e até mesmo, em alguns casos, prover algum grau de automação na resposta de incidentes envolvendo route leaks, prefix hijacks e outras situações. Outra possibilidade bastante interessante é projetar integrações entre estas ferramentas/serviços por meios as APIs disponibilizadas. Nos exemplos indicados acima, a [https://developer.thousandeyes.com/v6/ ThousandEyes fornece APIs] que podem ser aproveitadas para integrações com outros sistemas, assim como podem ser consideradas as [https://portal.bgpmon.net/bgpmonapi.php APIs do BGPmon da Cisco], [https://api.qrator.net/ APIs da QRATOR], etc. <br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança e instabilidades do roteamento BGP <br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de recebimento de anúncios de ASNs vizinhos'''<br /> | rowspan=&quot;5&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://bgpstream.caida.org/ BGPStream]<br /> * [https://share.zabbix.com/search?searchword=BGP&amp;search_cat=1 Zabbix com plugins compatíveis com estas necessidades]<br /> |-<br /> |'''Controle de abuso de AS-Path Prepending'''<br /> |-<br /> |'''Detecção de oscilações de sessões BGP'''<br /> |-<br /> |'''Detecção de oscilações de rotas (route flaps)'''<br /> |-<br /> |'''Detecção de rotas eventualmente suprimidas por Dampening'''<br /> |}<br /> Entendo que as ferramentas indicadas na tabela acima forneçam as funcionalidades devidas para que o administrador do Sistema Autônomo possua meios de identificar e reagir contra uma diversidade de situações envolvendo sessões e anúncios do protocolo BGP. <br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento engenharia de tráfego e planejamento de capacidades<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento'''<br /> | rowspan=&quot;7&quot; |<br /> * [https://www.telcomanager.com/trafip-analise-de-trafego/ TRAFip]<br /> * [https://www.noction.com/intelligent-routing-platform-bgp-network-optimization Noction IRP]<br /> * [https://www.blueplanet.com/products/route-optimization.html Ciena BluePlanet ROA]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/crosswork-network-automation/datasheet-c78-740228.html Cisco Crosswork Network Insights]<br /> * [https://www.manageengine.com/products/netflow/ ManageEngine NetFlow Analyzer]<br /> * [https://developer.cisco.com/docs/wan-automation-engine/#!overview/cisco-wan-automation-engine Cisco WAE em combinação com XTC]<br /> |-<br /> |'''Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas'''<br /> |-<br /> |'''Bilhetagem e tarifação de tráfego'''<br /> |-<br /> |'''Dimensionamento de recursos de transporte e acordos de troca de tráfego'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como BGP-LS, MPLS TE e SR-TE'''<br /> |-<br /> |'''Planejamento e antecipação de cenários &quot;what if&quot;'''<br /> |}<br /> A compreensão dos fluxos de tráfego, tanto na rede do próprio AS quanto nas conexões com os AS vizinhos, é algo muito importante para que o provedor consiga tomar as decisões corretas em algumas esferas técnicas do projeto e da operação cotidiana. Afinal de contas, para que seja possível o dimensionamento correto de recursos que acomodarão seus assinantes e respectivos serviços, o provedor precisa ter as informações necessárias para concluir este planejamento de capacidades, a engenharia de tráfego, e as questões de engenharia de redes tais como a disponibilidade, atrelada aos padrões de redundância, resiliência e métricas de confiabilidade, e em alinhamento com o projeto técnico e o plano de negócios. As ferramentas mencionadas na tabela acima possuem funcionalidades que cumprem bem com estes requisitos.<br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento da segurança do plano de controle da rede e segurança contra negação de serviços<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de vulnerabilidades sobre as mensagens do BGP'''<br /> | rowspan=&quot;4&quot; |<br /> * Ferramentas e soluções de detecção e prevenção de intrusão<br /> * [https://www.andrisoft.com/software/wanguard Andrisoft Wanguard]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://br.netscout.com/arbor-ddos Arbor para Operadoras]<br /> * [https://wiki.brasilpeeringforum.org/w/UTRS_Registro_e_Configuracao Team Cymru UTRS]<br /> |-<br /> |'''Controle de incidentes de segurança lançados diretamente contra as sessões BGP'''<br /> |-<br /> |'''Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS'''<br /> |-<br /> |'''Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces'''<br /> |}<br /> Tão importante quanto disponibilidade, performance e visibilidade geral dos componentes associados ao funcionamento do BGP em um Sistema Autônomo, é o gerenciamento da segurança da infraestrutura como um todo, sendo que, neste caso, as questões mais diretamente ao roteamento do AS. Na questão de segurança &quot;geral&quot; do AS, muita coisa já foi discutida em outros artigos já publicados na Wiki do Brasil Peering Forum, tais como o [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] e [[Boas Praticas para Melhorar a Seguranca de seu Provedor|Boas Práticas para Melhorar a Segurança de seu Provedor]]. As soluções mencionadas na tabela acima são indicadas para a mitigação de incidentes de segurança e ataques DDoS lançados contra a rede do ISP e/ou de seu cone de clientes.<br /> <br /> === Modelos e ferramentas orientadas ao gerenciamento do BGP ===<br /> Saindo um pouco desse discurso de &quot;necessidades, requisitos, desafios, etc,&quot;, serão discutidas a seguir as possibilidades em termos de modelos e ferramentas de gerenciamento que podem ser consideradas e utilizadas para os nossos interesses com o BGP. Pois, afinal de contas, não adianta vislumbrar um mundo perfeito ao melhor estilo &quot;''imagine all the people...''&quot; se não há formas efetivas de executarmos aquilo que nós desejamos, certo? Isto significa que temos que por os pés no chão e analisarmos as possibilidades nada utópicas! Se dependesse de nossas mentes altamente criativas, conseguiríamos, num estalar de dedos, fazer tudo funcionar da maneira como as nossas brilhantes mentes sonham, e ter acesso a todo o tipo de informações e analíticos que, na prática, sequer sabemos se existem ou se podem ser recuperadas dos elementos de nossa rede. <br /> <br /> E, antes de discutirmos quais tipos de informações/dados podemos obter em nosso ambiente e determinarmos o que podemos fazer com estas informações, tentemos em um primeiro momento compreendermos os protocolos, serviços e procedimentos que podem ser utilizados para recuperarmos informações dos equipamentos e sistemas de nossa infraestrutura.<br /> <br /> ==== Modelo &quot;pull&quot; tradicional de recuperação de dados ====<br /> O modelo ''pull'' de recuperação de dados consiste no envolvimento de procedimentos onde estações de gerenciamento acessam os dispositivos para a obtenção de informações acerca de um ou mais objetos gerenciados. Os exemplos de procedimentos mais comuns são as consultas executadas com protocolos tais como ''Simple Network Management Protocol'' (SNMP), ''Remote Monitoring'' (RMON), ''Secure Shell'' (SSH) e ''Telnet''. <br /> <br /> Como o próprio termo sugere (''pull''), os sistemas de gerenciamento requisitam informações para os equipamentos da rede através de mecanismos de solicitação e resposta, como é o caso das mensagens ''GetRequest'', ''GetBulkRequest'' e ''GetBulkRequest'', do SNMP, sobre algum objeto gerenciado (''Object Identifier'' (OID)), devidamente especificado em uma biblioteca ''Management Information Base'' (MIB) apropriada, a qual deverá ser suportada por ambos o equipamento (ex: roteador) e o sistema da estação de gerenciamento em questão, sendo que as respostas para estas requisições são fornecidas por meios de mensagens ''Response'' deste protocolo.<br /> <br /> Outra possibilidade envolveria scripts devidamente organizados ou acomodados em estações de gerenciamento que executem conexões diretas com o interpretador de linha de comando (CLI) dos equipamentos da rede e execute operações com comandos específicos de interesse do administrador, tais como a obtenção de contadores de uma interface (&quot;''show interfaces''&quot;) para a checagem por eventuais problemas, ou a verificação de status das sessões BGP do roteador (&quot;''show bgp summary''&quot; e &quot;''show bgp neighbor''&quot;), a contabilização da quantidade de rotas anunciadas para determinado vizinho BGP (&quot;''show route advertising-protocol bgp x.x.x.x''&quot; no JUNOS, &quot;''show bgp neighbor x.x.x.x advertised-routes''&quot; no Cisco IOS XR), dentre muitas possibilidades. O &quot;output&quot; de uma operação envolvendo um destes comandos seria então mantido num arquivo temporário para que outros scripts e procedimentos possam ser executados para consumir estes dados e fornecer algum tipo de tratamento e interpretação posterior.<br /> <br /> ==== Modelo &quot;push&quot; tradicional de recuperação de dados ====<br /> O modelo ''push'' de recuperação de dados ocorre no sentido inverso ao modelo ''pull'': os equipamentos da rede encaminham as informações para as estações de gerenciamento, e isto pode ocorrer através de definições periódicas do serviço monitorado para o envio de informações ou baseado em eventos. Exemplos de procedimentos ''push'' incluem as mensagens ''Trap'' do protocolo SNMP onde as mensagens destes &quot;traps&quot; nestes casos acompanhariam duas variáveis primárias, sendo o ''sysUpTime'' e o ''snmpTrapOID'', juntamente com outras instruções para reportar alguma condição que tenha sido detectada sobre o monitoramento estabelecido de um OID, e havendo o reconhecimento por parte do coletor de eventos com o envolvimento da mensagem ''InformRequest-PDU''.<br /> <br /> Outro exemplo de modelo ''push'' seria com o serviço Syslog sobre uma das 24 &quot;''facilities''&quot; (de 0 a 23) especificadas pelo &lt;nowiki&gt;RFC 5424&lt;/nowiki&gt;, sendo algumas de uso reservado para aplicações e serviços específicos, enquanto outras são de uso local (podendo ser destinados praticamente para qualquer finalidade) em combinação com um dos 8 níveis de severidade (0=EMERGENCY, 1=ALERT, 2=CRITICAL, 3=ERROR, 4=WARNING, 5=NOTICE, 6=INFORMATIONAL, 7=DEBUG) para comunicar eventos específicos de acordo com esta combinação de ''Facility'' x ''Severity'' para uma estação coletora de Syslog. Sistemas bastante completos e flexíveis de correlação de eventos podem consumir e processar estas informações para reportar uma gama muito ampla de situações, além de permitir a derivação de métricas e analíticos. O uso de scripts podem ser por ações independentes projetadas pelo administrador, ou ainda como parte integrante de funções existentes de sistemas de gerenciamento propriamente ditos.<br /> <br /> Dentre outras possibilidades envolvendo este modelo ''push'', há as próprias ferramentas embarcadas nos sistemas operacionais / software dos roteadores e switches, dentre os quais recomendo o ''Cisco Embedded Event Manager'' (EEM), ''Junos Event Scripts'', assim como facilidades similares encontradas em plataformas de outros fabricantes, os quais permitem flexibilizar bastante como eventos e outras informações podem ser encaminhadas para outros sistemas residindo em servidores da rede.<br /> <br /> ==== Telemetria orientada a modelos ====<br /> Ou MDT. As ferramentas e procedimentos clássicos empregados nos modelos ''pull'' e ''push'' tradicionais, citados previamente, possuem algumas restrições e limitações, mas isto não significa que protocolos e procedimentos tais como SNMP, shell scripting, recursos de software de roteadores (Cisco EEM, Junos Event Scripts, Huawei OPS, etc.) serão descontinuados ou aposentados tão cedo, muito pelo contrário. Na verdade, a tendência é que sejam encontrados novos propósitos e finalidades para estes protocolos e serviços mais legados, ou ainda dedicando-os para coletas de instruções e operações bem mais específicas, e não tão generalistas como ocorre atualmente na maioria das redes, enquanto novas tecnologias estão ganhando espaço para conquistarmos melhores resultados para as nossas necessidades de gerenciamento de configurações, gerenciamento de performance, gerenciamento de falhas, analíticos, ''big data'' e afins. E é justamente aqui onde entra o conceito de '''''telemetria''''' na sua forma mais ampla e efetiva.<br /> <br /> A telemetria orientada à modelos embarca e combina procedimentos de &quot;''telemetria orientada a eventos''&quot; e, principalmente, como destaque, a &quot;''telemetria de streaming periódica''&quot;, para proporcionar os melhores resultados, e não apenas nas ações técnicas e operacionais que competem aos centros de gerência de redes, tais como gerenciamento FCAPS no geral, mas, principalmente, em termos de ''big data'', analíticos e afins, sendo o principal diferencial entre esta modalidade e os modelos tradicionais de gerenciamento no geral.<br /> <br /> A principal diferença entre as duas abordagens, a &quot;tradicional&quot; e a &quot;telemetria&quot;, é que o modelo tradicional, simplificando aqui, emprega o protocolo SNMP, além de outros procedimentos já citados. Para efeitos comparativos, operações com protocolos tais como o SNMP são executadas com o modelo ''pull'' diretamente sobre os elementos da rede, exceto quando considerando aqui os SNMP Traps, que são muito específicos para alertas e eventos, e que operam por método ''push''. Já na telemetria por streaming periódico os dados são enviados diretamente e em tempo real a partir dos elementos da rede para os coletores e sistemas de gerenciamento, ou seja, conceito &quot;''push''&quot; mesmo, mas com diferenças significativas em termos de capacidade, recursos e disponibilidade de informações, além da própria característica &quot;''tempo real''&quot;. No que diz respeito à telemetria orientada e eventos, um dos maiores exemplos é o recurso ''BGP Monitoring Protocol'' (BMP), que poderá encaminhar eventos praticamente em tempo real acerca da operação do protocolo BGP no seu ASN. Os ganhos e benefícios disto tudo serão discutidos posteriormente neste artigo.<br /> <br /> A ilustração a seguir exemplifica as diferenças e principais componentes empregados em cada um dos casos citados aqui:<br /> [[Arquivo:Bpf-gerbgp-comparativosger.jpg|centro|miniaturadaimagem|907x907px|Comparativos entre os modelos de gerenciamento factíveis para o BGP]]<br /> <br /> ==== Comparativos entre os diversos tipos de tecnologias (protocolos e serviços), suas capacidades, finalidades e propósitos, e suas respectivas categorizações ====<br /> A tabela a seguir certamente será muito útil para concentrarmos muitas informações importantes e bem relevantes para dissertarmos sobre os aspectos e possibilidades quanto ao gerenciamento do BGP.<br /> {| class=&quot;wikitable&quot;<br /> |+Tabela comparativa entre diversos tipos de protocolos e serviços, suas capacidades, finalidades e propósitos<br /> !Ferramenta<br /> <br /> (Protocolo e/ou Serviço)<br /> !Alguns exemplos de situações em que pode ser empregada<br /> |-<br /> |'''SNMP (operações &quot;Get&quot;)'''<br /> |Operações de recuperação e amostragem de informações obtidas por meios de operações &quot;get&quot; do SNMP.<br /> * Consultas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Identificação de propriedades de sessões BGP (ex: temporizadores) e capacidades suportadas<br /> * Identificação da quantidade de rotas aceitas de uma sessão BGP<br /> * Identificação da quantidade de rotas recusadas de uma sessão BGP<br /> * Identificação da quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Identificação de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> * Recuperação da tabela de roteamento (Ex: 1.3.6.1.2.1.4.21 - ipRouteTable)<br /> |-<br /> |'''SNMP Traps'''<br /> |Alertas que poderão ser recebidos por sistemas de gerenciamento com suporte às MIBs necessárias.<br /> * Alertas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Alertas de quantidade de rotas recebidas de uma sessão BGP<br /> * Alertas de quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Alertas de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> |-<br /> |'''RMON'''<br /> |O RMON tem pouca ou nenhuma utilidade específica para os interesses de gerenciamento do BGP, mas suas capacidades e recursos poderão ser obtidas e combinadas para agregar valor ao propósito de gerenciamento como um todo.<br /> * Estatísticas em tempo real de utilização dos segmentos Ethernet envolvidos no transporte de sessões BGP (utilização, erros, colisões)<br /> * Fornecer histórico de estatísticas selecionadas, e com suporte ao uso de variáveis especificadas pelo usuário.<br /> <br /> * Encaminhamento de alarmes para RMON SNMP traps quando houver o cruzamento de determinados thresholds pré-definidos, inclusive com suporte a grupos de alarmes.<br /> * Monitoramento de hosts, tais como a quantidade de bytes e frames enviados e recebidos de vizinhos BGP.<br /> * Ordenamento de &quot;top hosts&quot; com coleta e manutenção de dados referentes a conexões ativas por um determinado período de tempo.<br /> * Matriz de tráfego entre dois roteadores envolvidos numa sessão BGP.<br /> * Filtragem de dados com base em padrões de interesse do administrador, tais como endereços MAC, e portas de protocolos de transporte.Captura de pacotes para análise posterior em depuradores.<br /> * Descoberta e estatísticas por protocolo.<br /> * Mapeamento entre endereços MAC e endereços IP referentes as sessões BGP<br /> * Estatísticas de tráfego L3 com ordenamento por host ou par de conversação (origem/destino), como complemento ao monitoramento do BGP.<br /> * Estatísticas de tráfego L7 por protocolo de aplicação e por host, como complemento ao monitoramento do BGP.<br /> |-<br /> |'''Syslog'''<br /> |Alertas que poderão ser recebidos por servidores syslog &quot;crus&quot; ou uma solução específica para correlação de eventos e processamento de analíticos.<br /> * Alertas de esgotamento de recursos de memória para algum processo ou ação do BGP<br /> * Alertas de problemas com a instalação de rotas BGP devido a inconsistências ou atributos inválidos<br /> * Alertas de falhas de semântica de políticas (route-map, route-policy, etc.) vinculadas a sessões BGP<br /> * Alertas de falhas nas estruturas internas dos processos BGP<br /> * Alertas de problemas de processamento de ações sobre atributos (ex: remoção de AS_PATH, modificação de NEXT_HOP)<br /> * Alertas de recebimento de prefixos inválidos (ex: Martians)<br /> |-<br /> |'''Shell scripting para invocação de CLI'''<br /> |Recuperação de qualquer informação possível por comandos na CLI do roteador.<br /> * Verificação do status de todas as vizinhanças BGP<br /> * Verificação detalhada de uma vizinhança BGP específica<br /> * Contadores de prefixos anunciados e recebidos por vizinho BGP<br /> * Detalhamento das rotas BGP anunciadas para um determinado vizinho BGP<br /> * Detalhamento das rotas BGP recebidas de um determinado vizinho<br /> * Consultas sobre a tabela BGP integral<br /> * Consultas sobre a tabela BGP com parâmetros de refinamento (expressão regular/regex, community, next-hop, policy...)<br /> * Consultas sobre a tabela BGP de rotas não filtradas (pré-policy) de um determinado vizinho (soft-reconfig inbound)<br /> |-<br /> |'''Cisco EEM'''<br /> |Componente do software de roteadores da Cisco, permitindo que você automatize tarefas, execute modificações e ajustes sobre diversos componentes lógicos, e crie ações alternativas. Dentre muitas possibilidades, e focando aqui no BGP, é possível:<br /> * Monitorar o estado operacional ou funcionamento de determinados protocolos e serviços e tomar ações automaticamente em função de algum evento pré-definido por você.<br /> * Implementar uma rotina de verificação de oscilação de sessões BGP, as quais, atingindo um determinado &quot;''threshold''&quot;, poderá invocar uma ação de notificação por Syslog, SNMP, Email (que poderá ser uma máscara de WhatsApp ou Telegram).<br /> * Em adição ao conceito acima, executar uma ação que poderá incluir a modificação de uma route policy para consequente redução do atributo LOCAL_PREF implementado sobre as rotas recebidas de um peer que está oscilando.<br /> * Em adição ao conceito acima, executar uma ação que poderá decidir por desabilitar administrativamente aquela sessão por um determinado período de tempo ou até que haja garantias de que a sessão esteja estável por &quot;x&quot; horas.<br /> * Implementar uma rotina de detecção de existência ou ausência de uma determinada rota BGP na tabela de roteamento (RIB), permitindo uma ação desejada que poderia incluir o estabelecimento de um túnel GRE ou TE, o &quot;shutdown&quot; ou &quot;no shutdown&quot; de uma interface, uma mudança de policy, etc.<br /> * Implementar uma rotina que vá coletar informações (tabela BGP, NLRIs com determinados atributos (ex: communities), rotas BGP da RIB, sessões, etc.) em intervalos periódicos, escrevendo os ''outputs''/dados em um arquivo em um servidor FTP.<br /> * &quot;Quem tem limites é município&quot;. O limite é virtualmente a capacidade criativa do administrador da rede; a sua imaginação. Experimente!<br /> |-<br /> |'''Juniper Event Scripts'''<br /> |Componente embarcado no sistema operacional JUNOS dos roteadores da Juniper Networks e com proposta similar ao Cisco EEM.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o Juniper Event Scripts propõe-se a fazer aquilo que o Cisco EEM faz, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas duas ferramentas.<br /> |-<br /> |'''Huawei Open Programmability System (OPS)'''<br /> |Componente embarcado no sistema operacional dos roteadores da Huawei e com proposta similar ao Cisco EEM e ao Juniper Event Scripts.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o OPS propõe-se a fazer aquilo que o Cisco EEM e o Juniper Event Scripts fazem, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas três ferramentas.<br /> |-<br /> |'''OpenConfig, NETCONF, RESTCONF, gNMI, gRPC, e modelos YANG'''<br /> |O OpenConfig, padrão aberto para o desenvolvimento de interfaces programáticas, viabiliza um gerenciamento mais dinâmico das infraestruturas (ex: telemetria) utilizando como transporte os protocolos e procedimentos NETCONF, RESTCONF, gNMI ou gRPC, em combinação com repositórios de dados modelados pelo YANG, para proporcionar um novo universo de possibilidades em termos de gerenciamento.<br /> <br /> Uma de suas principais aplicabilidades envolve o chamado ''Model-Driven Telemetry'' ou MDT. Quando pensando em gerenciamento por este modelo de telemetria, as possibilidades chegam a surpreender, pois a entrada de dados por ser feita pelos protocolos supracitados, ou ainda por JSON, Kafka, Google Protocol Buffer (GPB), Google RPC (GRPC), dentre outros, a lista é interessante.<br /> <br /> Já a saída de dados poderá ser feita para Kafka, Prometheus, InfluxDB, JSON, XML, e outros, pois a lista é igualmente interessante, o que abre um leque realmente surpreendente de situações e possibilidades. Nunca as redes foram tanto &quot;''software-defined''&quot;: o MDT é um divisor de águas! <br /> * Modelagem e streaming periódico/contínuo de dados para a representação das rotas BGP da RIB com suporte a 5 RIBs lógicas por família de endereços.<br /> * Provimento de definições de dados para tabelas BGP, tipos, identidades, especificações, atributos, e afins, para o gerenciamento efetivo do BGP por OpenConfig.<br /> * Gerenciamento, automação e orquestração de sessões e políticas de roteamento.<br /> * Streaming contínuo de indicadores de performance do BGP, incluindo FSM das sessões, quantidade de sessões, quantidade de rotas total e aceitas/recusadas por neighbor, etc.<br /> * Streaming contínuo de indicadores de anomalias associadas ao BGP.<br /> |-<br /> |'''NetFlow / JFlow / sFlow'''<br /> |O emprego destas tecnologias correlacionam os registros dos fluxos de tráfego juntamente com as informações de roteamento BGP para que seja possível visualizar as conversações para a extração de diversos analíticos importantes.<br /> * Monitoramento em tempo real de registros de fluxos de conversações juntamente com as indicações de Sistemas Autônomos envolvidos.<br /> * Identificação através de pesquisas customizadas sobre fluxos de tráfego por origem, destino, par origem-destino, protocolo de transporte, marcação de QoS, Sistema Autônomo BGP, etc.<br /> * Identificação dos &quot;''top talkers''&quot; por uma variedade de critérios de consulta.<br /> |-<br /> |'''BGP Link-State (BGP-LS)'''<br /> |O BGP Link-State (LS) é uma extensão do protocolo BGP fornecida por meios de um ''Address Family Identifier'' (AFI) e ''Sub-address Family Identifier'' (SAFI) para transportar o ''Link-State Database'' (LSDB) de protocolos IGP (OSPF e IS-IS) através do BGP. <br /> <br /> O BGP-LS permite uma série de aplicações, desde o fornecimento de informações topológicas detalhadas da rede para servidores específicos orientados à otimização de tráfego de rede na camada de Aplicação (ALTO), suporte a Path Computation Element (PCE) para engenharia de tráfego, e outros.<br /> <br /> No que diz respeito ao monitoramento do BGP, o BGP-LS poderá atuar como um componente adicional para agregar mais informações em diversas bases e sistemas onde os dados específicos de BGP são coletados, mantidos, processados, e representados.<br /> * Fornecimento de informações topológicas detalhadas da rede.<br /> * Combinação e correlação dos dados topológicos com estruturas de dados fornecidas por outros meios de gerenciamento centrados na otimização e visibilidade do BGP, tais como sFlow/JFlow/NetFlow, BMP, CLI, e SNMP.<br /> * Visibilidade, correlação de eventos, aprimorar ações de planejamento de capacidades e de engenharia de tráfego, e detecção de incidentes de segurança.<br /> |-<br /> |'''BGP Monitoring Protocol (BMP)'''<br /> |Acesso de sistemas de gerenciamento ao Adj-RIB-In de peers BGP para o recebimento periódico de estatísticas do protocolo.<br /> * Recebimento periódico de estatísticas que possam ser usadas para monitorar as atividades específicas do BGP.<br /> * Recebimento de notificações acerca do estado operacional das sessões BGP.<br /> * Recebimento das tabelas BGP pré-policy, ou seja, antes que o roteador implemente os filtros de import/export sobre as rotas.<br /> * Recebimento das tabelas BGP pós-policy, ou seja, após o roteador ter filtrado e filtrado atributos associados às rotas.<br /> * Em combinação com validadores de IRR, poderá detectar route leaks gerados ou recebidos pelo AS local.<br /> * Em combinação com validadores de RPKI, poderá detectar violações de ASN de origem associados às rotas recebidas ou enviadas.<br /> * Poderá ser combinado para fornecer funcionalidade de Looking Glass.<br /> * Fornecimento de visibilidade histórica envolvendo estado de sessões.<br /> * Fornecimento de visibilidade e histórico de prefixos com refinamento por &quot;peer&quot;, &quot;ASN&quot; e &quot;prefixo&quot;.<br /> * Permite estudar através de uma linha temporal todos os anúncios e recebimentos realizados, incluindo rotas aceitas e recusadas.<br /> * Permite estudar através de uma linha temporal todas as modificações de atributos executadas sobre rotas aceitas.<br /> |}<br /> Como não dá para abordar tudo em um artigo - talvez outros artigos sobre o tema sejam disponibilizados na Wiki do BPF - procurarei demonstrar algumas coisas que podem ser feitas com algumas das ferramentas/opções listadas na tabela acima. Que tal focarmos em dois componentes aqui? SNMP e BMP. <br /> <br /> === Monitoramento do BGP com o Simple Network Management Protocol (SNMP) ===<br /> O monitoramento de infraestruturas de redes por SNMP não é novidade alguma para os profissionais da área, muito pelo contrário. E, no que diz respeito ao monitoramento do BGP, o SNMP tem sido amplamente utilizado por muitas empresas para cumprir com diversas das necessidades e desafios comentados previamente. Por ser algo um tanto difundido, talvez o único método de gerenciamento/monitoramento propriamente dito adotado por ISPs regionais de pequeno e médio portes, não desprenderei muito tempo nesta seção do artigo.<br /> <br /> Diversas plataformas baseadas em software podem ser utilizadas para monitorar o BGP, dentre os quais destaco os seguintes:<br /> * [https://www.zabbix.com/ Zabbix]<br /> * [https://www.librenms.org/ LibreNMS]<br /> * [https://www.observium.org/ Observium]<br /> * [https://www.nagios.com/ Nagios]<br /> * [https://www.cacti.net/ Cacti]<br /> * [https://www.opennms.com/ OpenNMS]<br /> * [https://www.solarwinds.com/pt/ Solarwinds]<br /> * [https://www.paessler.com/prtg PRTG]<br /> * Integrações de boa parte destas soluções com o [https://grafana.com/ Grafana] para a geração de dashboards<br /> * Soluções comercias de fabricantes tais como Cisco, Juniper e outros<br /> Está fora do escopo deste artigo tecer quaisquer comparativos (&quot;''qual é o melhor?''&quot;, etc.) dentre estas soluções.<br /> <br /> Independentemente de qual abordagem/solução seja escolhida por você para atender as suas necessidades, o fato é que você terá que assegurar o devido suporte a alguns componentes específicos para o monitoramento do BGP, em particular a '''''BGP4-MIB''''', conforme descrita no RFC 4273 (''Definitions of Managed Objects for BGP-4'') e RFC 4275 (''BGP-4 MIB Implementation Survey''). Você deverá considerar também eventuais MIBs que implementem OIDs proprietários de acordo com o fabricante do equipamento que você necessitar monitorar pela sua gerência SNMP, por exemplo a [https://www.juniper.net/documentation/en_US/junos/topics/reference/mibs/mib-jnx-bgpmib2.txt '''''Juniper-BGP-MIB'''''] e [https://mibs.cloudapps.cisco.com/ITDIT/MIBS/MainServlet?ReleaseSel=4669&amp;PlatformSel=269&amp;fsSel=348 '''''Cisco-BGP-MIBv2'''''] , e certificar-se que seus sistemas de gerenciamento (ex: Zabbix) implementem funções para operações de consulta sobre os OIDs desejados com estas MIBs. Além destas MIBs, muitos destes sistemas possuem plugins prontos para o monitoramento do BGP em condições diversas, por exemplo:<br /> * Zabbix<br /> ** [https://share.zabbix.com/network_devices/cisco/cisco-bgp-ipv4-ipv6-32-bit-asn Cisco BGP IPv4/IPv6 32-bit ASN]<br /> ** [https://share.zabbix.com/network_devices/juniper/juniper-mx-discovery-int-re-bgp4-ipv4-and-ipv6 Template SNMP Juniper MX discovery: int, RE, BGP4 ipv4 and ipv6]<br /> ** [https://share.zabbix.com/network_devices/mikrotik/zabbix-routeros-bgp-monitoring Zabbix RouterOS BGP Monitoring]<br /> * LibreNMS<br /> ** [https://docs.librenms.org/API/Routing/ Monitoramento de sessões BGP] e [https://docs.librenms.org/Alerting/Entities/ Entities]<br /> * Observium<br /> ** [https://docs.observium.org/config_options/ Monitoramento de sessões BGP]<br /> * Nagios<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check-BGP-neighbor-JunOS/details Check BGP Neighbor JunOS]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp/details check_bgp]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_counters/details check_bgp_counters]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_v4_v6/details check_bgp_v4_v6]<br /> * Grafana<br /> ** [https://grafana.com/grafana/plugins/alexanderzobnin-zabbix-app Plugin para Zabbix]<br /> ** [https://grafana.com/grafana/plugins?orderBy=weight&amp;direction=asc Plugins para diversas finalidades e integrações]<br /> ** [https://grafana.com/grafana/dashboards?dataSource=alexanderzobnin-zabbix-datasource&amp;orderBy=name&amp;direction=asc Dashboards &quot;prontos&quot;]<br /> * Outros! basta pesquisar pelos recursos desejados junto à documentação do seu sistema de gerenciamento, entrar em contato com o suporte de desenvolvimento, contratar uma consultoria especializada, etc.<br /> O funcionamento do monitoramento do BGP por SNMP não é complexo, pois é um procedimento um tanto difundido entre os operadores de redes. As estações de gerenciamento são configuradas para executar consultas periódicas sobre os roteadores monitorados usando operações &quot;''Get''&quot; sobre os ''Object Identifiers'' (OID) desejados, os quais precisam ser especificados numa MIB apropriada (ex: BGP4-MIB), e cujo o suporte a esta MIB deverá existir tanto no roteador monitorado quanto no software em execução na estação de gerenciamento. O SNMP funciona neste caso como um mecanismo de solicitação e resposta, e as informações recuperadas por meios deste mecanismo são armazenadas nas bases de dados que acompanham estas soluções, e devidamente processadas para reportar alguma coisa em alguma função do sistema. Em adição, é possível consultar estes dados via integrações com outros sistemas (ex: Grafana) para finalidades de representação melhor elaboradas, como painéis/dashboards e afins. Por exemplo:<br /> [[Arquivo:Bpf-gerbgp-snmp.jpg|centro|miniaturadaimagem|900x900px|Exemplo de monitoramento do BGP por procedimento SNMP]]<br /> É importante frisar também que o gerenciamento do BGP para a questão de incidentes tais como oscilações de sessões (ou &quot;''flapping''&quot;) pode ser tratada por intermédio de mensagens ''SNMP trap''. O sistema de gerenciamento (chamamos aqui de software &quot;NMS&quot;), ao receber o evento por SNMP trap, buscará processar a informação de acordo com as diretivas que estiverem definidas para o elemento de rede gerenciado, permitindo destacar o evento da falha de forma visível nos painéis correspondentes oferecidos pelo software NMS. Apesar de isto não ser novidade alguma, acho que não custa nada deixar isto esclarecido para a eventualidade deste artigo ser consultado por indivíduos mais leigos.<br /> [[Arquivo:Bpf-gerbgp-snmptrap.jpg|centro|miniaturadaimagem|900x900px|SNMP traps para a funcionalidade de notificações e alertas do gerenciamento de falhas]]<br /> <br /> Nas mãos de profissionais caprichados, é possível construir painéis bastante interessantes com soluções relativamente simples, mas não menos interessantes, intuitivas ou funcionais, baseadas no SNMP, em especial quando envolvendo o Grafana para a produção destes painéis. Alguns casos de uso do Zabbix + Grafana para o monitoramento do BGP serão demonstrados aqui, sendo que, em alguns cenários, além do SNMP, outros procedimentos podem ser envolvidos para a recuperação e representação das informações desejadas para cada painel.<br /> <br /> No painel demonstrado a seguir, idealizado pelo Caio Ribeiro da [https://www.facebook.com/flowbix Flowbix], foi possível concentrar muita informação útil/relevante numa única tela: desde status das sessões BGP com seus respectivos ''uptimes'', total de prefixos IPv4 com indicadores de RIB e FIB, estado dos módulos ópticos do equipamento roteador BGP monitorado, a estatísticas de consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio1.jpg|centro|miniaturadaimagem|1280x1280px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também idealizado pela Flowbix, outra consolidação de dados importantes numa única tela, incluindo latência, índice de perda de pacotes, disponibilidade, uso de recursos tais como CPU, memória e espaço em disco, estado geral das sessões BGP monitoradas, e consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio2.jpg|centro|miniaturadaimagem|967x967px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também elaborado pela Flowbix, temos estatísticas mais centradas no estado das sessões BGP, e em combinação com uma visão geral dos índices de latência registrados.<br /> [[Arquivo:Bpf-gerbgp-caio3.jpg|centro|miniaturadaimagem|900x900px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Realmente, os limites em termos de construção de painéis para objetos gerenciados por SNMP com uma combinação NMS (ex: Zabbix) + Grafana, além de outros possíveis procedimentos, são um tanto amplos. Muita coisa de fato pode ser feita, desde que você possua os conhecimentos necessários para desenvolver estas integrações. Ou, então, por que você não investe em serviços de integração para o seu negócio?<br /> <br /> === Monitoramento por meios do BGP Monitoring Protocol (BMP) ===<br /> Muitos profissionais da área, incluindo engenheiros que atuam nas principais empresas de Internet do mundo, fabricantes e pesquisadores, chegaram a conclusão que era realmente necessário que tivessem acesso ao conteúdo das rotas mantidas nas tabelas BGP de roteadores, assim como uma visão do conteúdo das mensagens Update empregadas na troca de rotas entre sessões BGP. O grande desafio, porém, é que os modelos tradicionais de gerenciamento (ex: SNMP) praticamente inviabilizam o cumprimento de ações que fornecessem estas informações. Surgiu então o '''''BGP Monitoring Protocol''''', especificado originalmente no &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; (''BGP Monitoring Protocol (BMP)'') e complementado pelo &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)'').<br /> <br /> O BMP fornece meios de acesso ao ''Adj-RIB-In'' de uma sessão BGP de uma forma contínua em adição a um despejo periódico de dados estatísticos para uma estação coletora, devidamente equipada com software específico, para que os engenheiros do Sistema Autônomo possam analisar o funcionamento e o comportamento do BGP.<br /> <br /> Antes mesmo de você conhecer os benefícios do monitoramento do BGP com o protocolo BMP, você precisa saber identificar alguns componentes e conceitos fundamentais <br /> * '''''Adj-RIB-In''''': conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt; (''A Border Gateway Protocol 4 (BGP-4)''), o ''Adj-RIBs-In'' contém as informações de roteamento ainda não processadas que foram anunciadas pelo roteador BGP para seus vizinhos. É conhecido também pelo termo &quot;''pre-policy Adj-RIBs-In''&quot;. Na perspectiva do BMP, o ''Adj-RIB-In'' representa todas as rotas que foram recebidas pelo coletor antes destas informações terem sido processadas por uma policy inbound.<br /> * '''''Post-Policy Adj-RIBs-In''''': é o resultado de aplicação da política de roteamento inbound (ou &quot;import&quot;, como é conhecido em algumas plataformas), mas antes de ter ocorrido o processo de seleção de caminhos (best-path) do BGP para a composição da tabela de roteamento local. Na perspectiva do BMP, o ''post-policy Adj-RIB-In'' representa as informações que foram recebidas pelo coletor após a aplicação de policies inbound ou modificações de quaisquer atributos.<br /> Ou seja, a diferença entre ''pre-policy Adj-RIB-In'' e ''post-policy Adj-RIB-In'' é que, no primeiro caso, não houve a aplicação de quaisquer filtros sobre as rotas recebidas antes que estas informações fossem exportadas para o coletor BMP. E, no post-policy, as informações são encaminhadas para o coletor BMP após o roteador ter &quot;filtrado&quot; (e, potencialmente, modificado atributos) por meios de policies inbound, mas antes do roteador ter conduzido o processo de seleção de ''best path'' para posterior composição da RIB local referente a estas rotas BGP. O monitoramento de updates recebidos de um roteador antes da aplicação de policies inbound tem sido provavelmente a aplicação mais frequente envolvendo o BMP, enquanto o post-policy está mais centrado nas questões relacionadas à auditoria e validação das políticas de roteamento implementadas pela empresa.<br /> <br /> No entanto, o monitoramento apenas do ''Adj-RIB-In'' impõe uma restrição sobre quais dados estariam disponíveis ou acessíveis para os coletores BMP. Como a maioria dos Sistemas Autônomos não possui qualquer implementação de BMP e, quando possuem, não disponibilizam estas informações para terceiros (ex: acesso leitura-apenas ao painel da estação coletora BMP), a sua empresa fica sem visibilidade sobre de fato o que foi anunciado e aceito para os peers de ASs vizinhos. Tudo bem que a consulta destas informações por Looking Glass (que não são baseados em BMP) até permite que você consiga de fato ver se um determinado anúncio encontra-se presente nas tabelas BGP do AS vizinho, mas, no entanto, sem quaisquer dados históricos e facilidades deste tipo, os quais estariam disponíveis com o BMP, ou na alçada deste. E é justamente aí que entra outra proposta, que é o &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)''). Este RFC introduz alguns argumentos e facilidades adicionais para o BMP, dentre os quais:<br /> * '''''Adj-RIB-Out:''''' conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt;, o ''Adj-RIB-Out'' contém as rotas designadas para anúncios para os peers BGP por intermédio das mensagens UPDATE.<br /> * '''''Pre-policy Adj-RIB-Out''''': é o resultado de representação dos prefixos que serão anunciados pelas mensagens UPDATE antes da aplicação de policies outbound (ou &quot;export&quot;). Geralmente é a mesma coisa que encontra-se no momento na RIB local do roteador.<br /> * '''''Post-policy Adj-RIB-Out:''''' é o resultado do envio de prefixos através de anúncios (UPDATE) após o processamento das informações pelas policies outbound. É a representação do que de fato está sendo anunciado para um peer BGP específico.<br /> O ''BGP Monitoring Protocol'' (BMP) opera sobre uma sessão TCP entre o roteador monitorado e a estação coletora BMP. A configuração da sessão é um tanto flexibilizada, com possibilidade de conexão passiva (iniciada pelo roteador apenas) e mecanismos de backoff de tentativas de conexão com intervalos configuráveis, assim como outros parâmetros para o controle de fluxo de informações entre o roteador e a estação coletora BMP. Nenhuma mensagem BMP é enviada da estação coletora para o roteador, mas nada impede que o administrador da rede configure uma policy inbound para recusar quaisquer anúncios (que sabemos que nunca serão enviados) vindos da estação coletora BMP. Com relação às mensagens empregadas pelo BMP, o &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; especifica as seguintes:<br /> * '''''Type 0: Route Monitoring (RM)''''': é usado para fornecer um dump inicial de todas as rotas recebidas a partir de um peer, e atua também como um mecanismo contínuo para relatar, de forma incremental, as rotas que são anunciadas e revogadas (''withdrawn)'' por um peer para a estação coletora BMP. A mensagem ''Route Monitoring'' consiste de ''Common Header'' + ''Per-Peer Header'' + mensagem BGP ''UPDATE'' na íntegra.<br /> * '''''Type 1: Statistics Report (SR)''''': fornece um despejo periódico de estatísticas que podem ser utilizadas pelo coletor BMP para relatar as atividades específicas do BGP realizadas pelo roteador. A mensagem ''Stats Reports'' consiste de ''Common Header'' + ''Per-Peer Header'' + um campo de 4 bytes indicando a quantidade de contadores, sendo que cada contador é codificado na forma de um TLV. Stats são informados como ''Counters'' (32-bit) ou ''Gauges'' (64-bit).<br /> * '''''Type 2: Peer Down Notification''''': uma mensagem que é enviada para indicar que uma sessão BGP foi desconectada, fornecendo ainda o motivo para esta desconexão. A mensagem ''Peer Down Notification m''enciona um dos 5 motivos indicativos do encerramento de uma sessão BGP do roteador (''Reason'' 1 a ''Reason'' 5).<br /> * '''''Type 3: Peer Up Notification''''': uma mensagem que informa que uma sessão BGP ficou Up ou &quot;Established&quot;. Esta mensagem inclui informações importantes sobre o que ficou negociado entre os roteadores participantes desta sessão (conteúdo da mensagem OPEN) e também dados referentes à sessão BGP. A mensagem ''Peer Up Notification'' consiste de ''Common Header'' + ''Per-Peer Header'' + a mensagem (BGP) ''OPEN'' enviada + a mensagem ''OPEN'' que foi recebida + informações sobre o peer (opcional)<br /> * '''''Type 4: Initiation Message''''': fornece um mecanismo de indicação para o coletor BMP sobre o roteador BGP, incluindo o fabricante/modelo, versão de software, etc., funcionando como uma espécie de controle de inventário. A mensagem ''Initiation Message'' consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' contendo informações acerca do roteador monitorado, sendo que ''sysDescr'' e ''sysName'' são obrigatórios, enquanto os demais são opcionais.<br /> * '''''Type 5: Termination Message''''': fornece um mecanismo utilizado para informar que a sessão BMP entre o roteador e o coletor BMP foi interrompida. A mensagem ''Termination Message'' consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' descrevendo um dos 5 motivos (''Reason'' 0 a Reason 4) pela ''terminação'' da sessão BMP com o roteador monitorado.<br /> * '''''Type 6: Route Mirroring Message''''': um mecanismo para o roteador monitorado enviar duplicatas literalmente de mensagens conforme são recebidas. Pode ser usado para espelhar exatamente uma sessão BGP monitorada, assim como ser usado para relatar PDUs malformados do protocolo BGP. A mensagem ''Route Mirroring'' consiste de ''Common Header'' + ''Per-Peer Header'' + conjuntos de TLVs que descrevem as mensagens, sendo que 2 bytes informam o código do tipo de mensagem (ex: Type 0 = ''BGP Message'', Type 1 = ''Information'', Type 1 Code 0 = ''Errored PDU'' e Type 1 Code 1 = ''Messages Lost''), 2 bytes o campo de comprimento, e um campo de valor de comprimento variável.<br /> O &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; por sua vez implementa algumas modificações nas estruturas destas mensagens para acomodar as situações ''Adj-RIB-In'' e ''Adj-RIB-Out'', tais como flag O assinalado para &quot;0&quot; em mensagens BMP com cabeçalho ''per-peer'', e os flags necessários para denotar especificamente ''Adj-RIB-In'' ou ''Adj-RIB-Out'' para as mensagens ''Route Monitoring'' e ''Route Mirroring''.<br /> [[Arquivo:Bpf-gerbgp-bmpheaders.jpg|centro|miniaturadaimagem|900x900px|Cabeçalhos do BMP conforme &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt;]]Acredito que você já esteja entendendo melhor as funcionalidades básicas proporcionadas pelo ''BGP Monitoring Protocol'' (BMP)! Que tal apresentarmos um caso prático envolvendo o monitoramento do BGP por esta tecnologia?<br /> <br /> ==== Caso de uso: monitoramento por BGP Monitoring Protocol (BMP) com o Streaming Network Analytics System (SNAS) ====<br /> O caso apresentado a seguir é uma das diversas possibilidades associadas ao monitoramento do BGP em um Sistema Autônomo com o BMP. Para encurtarmos uma dissertação excessivamente prolongada deste caso, optei por elaborar um simples &quot;canvas&quot; para representar um conceito de solução proposta baseada no ''Streaming Network Analytics System'' (SNAS). O modelo canvas mostrado a seguir tem uma estrutura modificada/customizada para refletir as características gerais do conceito de solução proposto da maneira que eu gostaria de fornecer, ou seja, colocando numa única página, a relação de ''Problemas/Necessidades'', ''Solução'', ''Argumentos de Adoção'', ''Vantagens'', ''Desvantagens'', ''Resultados'', ''Características de Extensibilidade e Integração'' e um ''Bloco Representativo da Solução''. Este arranjo ou customização do modelo canvas deve ser eficiente o bastante para esclarecer esta solução.<br /> [[Arquivo:Bpf-gerbgp-openbmp.jpg|centro|miniaturadaimagem|900x900px|Canvas model do conceito de solução factível com base numa derivação do SNAS para o gerenciamento com o BGP Monitoring Protocol ]]<br /> Apenas para constar, a solução é composta pelos seguintes componentes, cada qual com uma função bastante especifica, e devidamente &quot;empacotados&quot; para implementação em containers com Docker: <br /> * '''openBMP:''' servindo como coletor de BMP. Uma sessão BMP é estabelecida entre este coletor e cada roteador onde desejamos monitorar ou coletar os dados referentes ao BGP.<br /> * '''Apache Kafka:''' o Kafka atua como uma plataforma de processamento de streaming de alta capacidade e baixa latência para o tratamento de dados em tempo real. A presença do Kafka no projeto permite conectar múltiplos ''publishers'' e ''subscribers'' para a disseminação de dados de forma bastante rápida, sendo um ótimo diferencial para as questões de integração e compartilhamento de dados de nossa solução com outros sistemas. Esta instalação inclui ainda o '''''Zookeeper''''', um software também desenvolvido pela Apache e que atua como um serviço centralizado, sendo usado para manter os dados de nomenclatura e configuração e para fornecer sincronização flexível e robusta nos sistemas distribuídos. O ''Zookeeper'' controla o status dos nós do cluster Kafka e também rastreia os tópicos, partições, etc.<br /> * '''PostgreSQL:''' O projeto SNAS original emprega como banco de dados o MySQL/MariaDB, isto tem servido bem aos propósitos por um bom tempo. Todavia, os desenvolvedores entenderam que estava na hora de substituí-lo por um banco de dados mais eficiente em função de algumas das limitações do MariaDB, tais como gerenciamento manual de partições de dados de séries temporais, recuperação de espaço em disco e requerimentos de memória do InnoDB, suporte fraco a JSON, dentre outras. O PostgreSQL resolve estas limitações e ainda adiciona algumas facilidades consideradas interessantes pelos desenvolvedores do SNAS, sendo que o consumidor dos dados implementa todas as APIs de análise do barramento de mensagens via o Kafka. Nesta implementação, o container inclui ainda os seguintes: '''''TimescaleDB''''', '''''RPKI Validator''''', e consultas às bases IRR por procedimento '''''Whois'''''. O ''TimescaleDB'' é um banco de dados de código aberto desenvolvido para tornar o SQL escalável para dados de séries temporais, e é aqui empacotado como uma extensão do PostgreSQL para fornecer o particionamento automático através do tempo e espaço (chave de particionamento). O ''RPKI Validator'', por sua vez, é acionado em rotinas próprias para a verificação do status ROA de cada prefixo mantido na base de dados da solução, enquanto o ''Whois'' é invocado em outras rotinas para a recuperação de informações nas bases IRR.<br /> * '''Grafana:''' o SNAS original possui o seu próprio front end WebUI, obviamente não baseado no Grafana, o qual é compatível somente com a instalação original baseada no MySQL/MariaDB. Esta WebUI não é compatível com o PostgreSQL, tampouco o Grafana, nas novas implementações, é compatível com o MariaDB. Caso você queira reaproveitar esta WebUI original com novas instalações já baseadas no PostgreSQL ao invés do MariaDB, ou utilizar como WebUI o Grafana sobre o MariaDB, ao invés da WebUI original, você realmente terá que &quot;por a mão na massa&quot; e fazer todos os ajustes de códigos necessários, etc. Atualmente existem 12 dashboards &quot;prontos&quot; para atuar especificamente sobre a base de dados desta solução por openBMP/SNAS, mas nada impede que você construa os seus próprios dashboards para atender as suas necessidades mais específicas!<br /> * '''Docker:''' a implementação do SNAS ou de qualquer customização derivada a partir deste não depende exclusivamente do Docker! Você pode montar a solução do zero e do jeito que bem entender. Só vejo que há benefícios associados à separação destas aplicações com a abordagem por containers. Sem contar que, para um setup inicial rápido para fins de conhecer o potencial do SNAS, você poderá clonar uma instalação literalmente pronta e colocá-la para rodar em questão de minutos! Lá na frente você então poderá decidir-se como deverá ser a sua instalação definitiva em ambiente de produção, podendo ser em Docker ou não.<br /> [[Arquivo:Bpf-gerbgp-snasdocker.jpg|centro|miniaturadaimagem|900x900px|Cenário: SNAS em containers Docker]]<br /> Apesar de termos basicamente uma solução &quot;pronta&quot; contendo os componentes acima, é possível conceber diversos tipos de integrações com sistemas desenvolvidos internamente ou com soluções comerciais, os quais, por sua vez, podem consumir os dados fornecidos pelo BMP, seja com streaming nativamente por BMP ou então com acesso direto às informações já armazenadas num banco de dados, sem contar ainda o potencial de distribuição de dados em tempo real via a facilidade introduzida com o Kafka. Os desenvolvedores do SNAS inclusive sugerem este e outros cenários de integração em diversas áreas de sua documentação. Um destes cenários destaco a seguir:<br /> [[Arquivo:Bpf-gerbgp-snas.jpg|centro|miniaturadaimagem|900x900px|Exemplo de cenário de integração do SNAS]]Todavia, a solução que será apresentada a seguir é baseada integralmente (e somente) no SNAS, contemplando duas possibilidades para o banco de dados: instalação original baseada no MariaDB + frontend WebUI do SNAS, e instalação baseada no PostgreSQL e integração com o Grafana, juntamente com os dashboards específicos para os nossos objetivos de monitoramento. Em termos de funcionamento desta integração envolvendo as duas possibilidades em termos de bancos de dados e os frontends WebUI original e Grafana, a ilustração a seguir poderá prover uma elucidação adequada:<br /> [[Arquivo:Bpf-gerbgp-snasio.jpg|centro|miniaturadaimagem|900x900px|Coletor, DB e Frontend do SNAS.io (Fonte: snas.io)]]'''Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos'''<br /> <br /> Um caso real aqui obtido com um ISP que realiza o monitoramento por BMP juntamente com painéis por Grafana. Uma realidade é como o seu Sistema Autônomo (você) enxerga o mundo, e outra coisa é como as demais empresas com presença na Internet enxergam o seu AS (você). Uma facilidade muito interessante de um dos 12 dashboards &quot;prontos&quot; para o SNAS é a capacidade de visualização de qualquer ASN na perspectiva das tabelas BGP do seu ASN (você). Uma vez que o coletor BMP (''openbmp'') recebe/coleta as mensagens vindas dos roteadores monitorados, os dados contidos nestas mensagens são reorganizados e repassados diretamente para o Kafka que as comunica/repassa para a base SQL. Este dashboard do Grafana então realiza consultas sobre as diversas tabelas, constrói e representa as informações que destacam como um determinado ASN - e você pode consultar praticamente qualquer ASN neste dashboard - é visto a partir do ASN da sua empresa (você). O dashboard plotará algumas informações bem relevantes, tais como as relações de upstreams e downstreams do ASN pesquisado, juntamente com a resolução correspondente às bases IRR, incluindo os objetos route/route6 identificados para aquele ASN.<br /> <br /> Esta ferramenta poderá ser muito útil não apenas para você, administrador do AS da sua empresa, mas para que os demais ASs possam ter a liberdade de estudar como são vistos a partir do AS da sua empresa, ou seja, um bom esforço de cooperação para facilitar a vida de outros profissionais/empresas quando estes estiverem diagnosticando eventuais problemas relacionados ao roteamento de/para o seu AS.<br /> [[Arquivo:Bpg-gerbgp-bmpasvniew.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para funcionalidade Looking Glass'''<br /> <br /> Looking Glass não é novidade alguma, muito pelo contrário. Mas me surpreende a quantidade de ASNs que não disponibilizam esta ferramenta, à título de &quot;esforço de cooperação&quot;, para que terceiros (outros profissionais e empresas) possam consultá-lo no intuito de diagnosticar e resolver problemas de roteamento associados aos anúncios por BGP. Inacreditável!<br /> <br /> Embora Looking Glasses sejam bastante úteis e conhecidos, há uma limitação aqui: ao consultar um Looking Glass sobre um determinado prefixo/rota, a resposta será sempre aquilo que estiver constando no momento em que você estiver realizando aquela consulta. Perde-se o tato no que concerne ao que poderia ou pode ter acontecido com relação ao prefixo consultado: &quot;''quantas vezes houve alterações nas propriedades desta rota?''&quot;, &quot;''esta rota estava presente neste LG ontem a noite, quando meus usuários reclamaram problemas de acesso?''&quot;, &quot;''qual é a frequência de oscilações das minhas rotas neste ASN por um determinado upstream?''&quot;, e coisas deste tipo. E é justamente nessas horas que este dashboard com funcionalidade estilo Looking Glass poderá ser extremamente útil.<br /> <br /> Este dashboard, também produzido com o Grafana, permite que você possa pesquisar sobre um prefixo e obter, através de uma linha temporal, todo o histórico de mudanças associadas ao anúncio deste prefixo/rota pesquisado, e isto certamente deverá responder a muitos de seus questionamentos. Infelizmente não é possível fazer pesquisas sobre outras propriedades da rota, tais como pesquisas sobre os atributos, principalmente sobre o AS_PATH. Mas creio que isto seja viável no ponto de vista de implementação, cabendo a você estudar toda a estrutura de dados mantida na base SQL, &quot;acertar&quot; a mão nas ''queries'', e desenvolver o seu próprio dashboard para uma consulta por expressão regular e afins!<br /> [[Arquivo:Bpg-gerbgp-bmplg.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]<br /> [[Arquivo:Bpg-gerbgp-bmplg2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos'''<br /> <br /> Outro dashboard montado com o Grafana que oferece uma utilidade tremenda: a capacidade de consultar o histórico de anúncios originados a partir de um determinado ASN! Na verdade, são 3 dashboards distintos que oferecem visibilidades sobre prefixos com ordenamento &quot;''por prefixo''&quot;, &quot;''por peer''&quot;, &quot;''por ASN''&quot;.<br /> <br /> Este tipo de consulta pode ser muito útil quando desejamos compreender as frequências de alterações nas rotas originadas em um ASN, em particular quando seus usuários estiverem reclamando de problemas de acesso a conteúdos vinculados a estas redes. Isto inclusive poderá ser muito útil para saber quais de seus upstreams diretos são mais &quot;estáveis&quot;, já que alterações frequentes e recorrentes destes anúncios por um determinado peer podem indicar que um dos seus upstreams está passando por alguma dificuldade, por exemplo, ou executando manobras nas políticas de roteamento em um determinado horário, ocasionando em oscilações e instabilidades na convergência do seu BGP.<br /> <br /> As pesquisas podem ser realizadas sobre um destes 3 dashboards designados para esta finalidade, conforme:<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas especificamente a um prefixo qualquer:''''' você poderá usar o dashboard &quot;''Prefix History (by Prefix)''&quot; para visualizar todas as mudanças associadas ao prefixo em questão, tais como a data/hora, tipo de evento (''advertised'', ''withdrawn''), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, o prefixo/rota consultado, o ASN de origem, a lista de AS-Path associada ao prefixo, e as communities associadas a cada prefixo identificado neste período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a quaisquer prefixos originados especificamente em um ASN qualquer:''''' você poderá usar o dashboard &quot;''Prefix History (by ASN)''&quot; para determinar características tais como data/hora, tipo de evento (''advertised'', ''withdrawn''), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, os prefixos/rotas deste ASN identificados neste período, o ASN de origem consultado, a lista de AS-Path associada a cada um dos prefixos identificados neste período, e as communities associadas a cada prefixo identificado neste período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a eventos referentes a quaisquer prefixos e de quaisquer ASNs, coletados a partir de um roteador monitorado combinado com cada peer:''''' você poderá usar o dashboard &quot;''Prefix History (by Peer)''&quot; para filtrar a origem dos eventos conforme coletados pelos roteadores monitorados pelo coletor BMP, incluindo data/hora, tipo de evento (''advertised'', ''withdrawn''), roteador monitorado, peer externo, prefixo, lista de AS-Path, e communities associadas à cada rota identificada neste período conforme reportado pelo roteador monitorado.<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por ASN]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por Peer]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis3.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por prefixo]]'''Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos'''<br /> <br /> Um dashboard mais &quot;cosmético&quot; ou &quot;visual&quot;, mas não menos importante. Com este painel você será capaz de identificar, através de seus gráficos, eventuais anomalias associadas às sessões BGP e de suas respectivas atividades relacionadas a anúncios, tais como volume e frequência de eventos ''advertised'' e ''withdrawn'', anúncios (''advertised'') por roteador, retiradas (''withdrawn'') por roteador, ''Updates'' por peer e ''Withdraws'' por peer.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmptop.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de de incidentes de segurança como BGP'''<br /> <br /> Conforme comentado anteriormente, o container que oferece o componente '''''openbmp_psql''''' (PostgreSQL) não contém apenas o PostgreSQL: há ainda a presença do ''TimescaleDB'' e de um '''''validador de RPKI'''''. Na medida em que os dados coletados pelo ''openbmp'' são armazenados na base de dados via o interfaceamento com o ''Kafka'', rotinas são executadas em segundo plano para identificar os registros ROA ''Valid'', ''Unknown'' ou ''Invalid'' referentes a cada um dos prefixos mantidos nas diversas tabelas acomodadas pela solução. Este dashboard permite apresentar um &quot;mapa&quot; de quantos ou quais prefixos um ASN possui erros de validação do RPKI. E, em adição, rotinas secundárias são invocadas para a realização de consultas sobre as bases de ''Internet Routing Registry'' (IRR) referentes a estes mesmos prefixos armazenados na base de dados da solução.<br /> <br /> Consequentemente, através deste dashboard por Grafana, você passa a ter condições de identificar potenciais incidentes relacionados a sequestro de prefixos (''hijacks'') e vazamento de rotas (''route leaks'') associados a um ASN específico sobre o qual você poderá realizar esta consulta. Isto poderá ser útil para visualizar problemas em potencial envolvendo os anúncios de prefixos, os quais podem ser recusados tanto pelas políticas de roteamento do seu próprio ASN quanto pelas políticas de roteamento de upstreams, pois, cada vez mais, as empresas tem adotado certo grau de automação na hora de implementar os filtros necessários para o envio e recebimento de anúncios envolvendo seu cone de clientes, ou seja, filtros de rotas que fatoram o estado de validação do RPKI (descarte de ROA inválido) e também o validação por IRR. <br /> <br /> Apesar de não ser &quot;perfeito&quot; e nem 100% garantido, este dashboard pode ser particularmente útil quando estamos interessados em observar o estado geral da segurança do roteamento BGP no que tange à validade dos anúncios por RPKI e IRR, com maior foco na deteção de ''hijacks'' e ''route leaks''.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de Hijacks e Route Leaks]]<br /> [[Arquivo:Bpf-gerbgp-incidents.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento incidentes de segurança do BGP (Fonte: snas.io)]]<br /> <br /> '''Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR'''<br /> <br /> Este painel aproveita grande parte dos componentes citados no painel anterior (validador RPKI e consultas ao IRR) para fornecer uma visualização mais simplificada de quantos prefixos mantidos na base apresentam algum problema de validação RPKI ou IRR.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR]]'''Caso de uso: monitoramento de sessão BGP por BMP com a WebUI nativa do SNAS.io''' <br /> <br /> O monitoramento por BMP possibilita a extração de algumas informações que atendem a diversas das demandas operacionais do cotidiano do ISP, como, por exemplo, a verificação do estado e demais informações relacionadas às sessões BGP, com resultado parecido com aquele que você obteria com um comando &quot;''show bgp neighbor''&quot; de um roteador.<br /> <br /> [[Arquivo:Bpf-gerbgp-snaspeer info.png|centro|miniaturadaimagem|800x800px|Caso de uso: Peer Info com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: painel Top 20 de prefixos anunciados e removidos com a WebUI nativa do SNAS.io''' <br /> <br /> Com funcionalidade similar ao que foi mostrado no painel AS View com o Grafana, a interface WebUI original do SNAS.io provê uma visibilidade geral do AS numa relação &quot;Top 20&quot;.<br /> [[Arquivo:Bpf-gerbgp-snastop20.png|centro|miniaturadaimagem|800x800px|Caso de uso: Top 20 prefixos anunciados e removidos com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: análise de segurança com a WebUI nativa do SNAS.io''' <br /> <br /> Com visibilidade similar ao que foi demonstrado em alguns painéis anteriores, esta facilidade permite uma rápida visualização acerca da quantidade de ASNs com problemas de validação do RPKI.<br /> [[Arquivo:Bpf-gerbgp-snastsecurity report.png|centro|miniaturadaimagem|800x800px|Caso de uso: análise de segurança com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snasrpki drill down.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatório de violação de RPKI com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: integração e visibilidade com BGP Link-State (BGP-LS)'''<br /> <br /> Para atender à necessidade de aplicações que exijam visibilidade topológica em áreas IGP ou mesmo em sistemas autônomos, uma AFI/SAFI para o BGP foi definida para permitir que este protocolo carregue em si as informações detalhadas sobre os estados de links, ou seja, a topologia da rede é codificada nos NLRI e as propriedades de objetos são codificadas em atributos do BGP-LS. Esta função do SNAS.io permite mostrar os detalhamentos topológicos transportados pelo BGP para que engenheiros de rede compreendam como melhor otimizar o fornecimento de determinados perfis de conteúdos.<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate map traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate SPF and traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: relatórios por Sistema Autônomo com a WebUI nativa do SNAS.io'''<br /> <br /> Como o próprio nome sugere, por esta interface podemos informar um número de AS e obtermos informações detalhadas incluindo os registros correspondentes das bases IRR, os prefixos originados pelo ASN pesquisado, e, conforme o entendimento do BGP, a relação de upstreams e downstreams daquele ASN.<br /> [[Arquivo:As view.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatórios por AS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> <br /> ==== Caso de uso: monitoramento, analíticos e big data com o Streaming Network Analytics System (SNAS/openBMP) em combinação com o Platform for Network Data Analytics (PNDA) ====<br /> A combinação do PNDA com o SNAS funciona como uma espécie de &quot;''unha e carne''&quot;, pois agrega muitas facilidades que trazem à tona os padrões de visibilidade e transparência acerca do comportamento geral do BGP, em particular as métricas que mais nos preocupam no cotidiano para a tomada de decisões estratégicas. O combo &quot;PNDA + SNAS&quot; abre as portas do '''''big data''''' para as necessidades de BGP ou do roteamento do AS propriamente dito!<br /> <br /> Nesta solução, o SNAS captura os eventos BGP dos roteadores com o uso do ''BGP Monitoring Protocol'' (BMP), exatamente conforme demonstrado anteriormente, só que, em seguida, o SNAS encaminha os eventos coletados via ''Logstash'' para o cluster PNDA através de uma interface que o SNAS mantém com o Kafka - daí uma das aplicabilidades de termos inserido o Kafka neste contexto. O HDFS do PNDA oferece a capacidade de registrar e manter grandes quantidades de dados históricos de eventos, portanto a solução é bem escalável. Na sequência, uma aplicação baseada no Spark cria as consultas que são executadas sobre os dados, extraindo as informações desejadas. Os resultados são então armazenados no componente HBase do PNDA e expostos por meios de uma API REST, onde os usuários/administradores poderão usar uma interface Web amigável para visualizar estes resultados.<br /> <br /> Para os propósitos aqui discutidos, o PNDA executa os seguintes procedimentos com as suas respectivas tecnologias embarcadas:<br /> * Entrada de dados por uma infinidade de opções, incluindo '''''Logstash''''', '''''Open Daylight''''', '''''Bulk Ingest''''' tool, '''''SNAS.io''''', '''''SNMP''''', '''''pmacct''''', '''''Cisco IOS XR Telemetry''''', etc.<br /> * Distribuição de dados por '''''Apache Kafka''''' e '''''Zookeeper'''''.<br /> * Processamento de stream em alta velocidade com '''''Spark Streaming'''''.<br /> * Processamento em lote de alto volume com '''''Spark'''''.<br /> * Exploração de dados de forma livre com o '''''Jupyter'''''.<br /> * Consulta estruturada sobre big data com '''''Impala'''''.<br /> * Manipulação de séries temporais com '''''OpenTSDB''''' e '''''Grafana'''''.<br /> O PNDA é bastante sofisticado no que diz respeito às tecnologias que são disponibilizadas. Uma instalação padrão inclui os seguintes:<br /> * '''''SaltStack:''''' é um software de código aberto baseado em Python para automação de TI orientada a eventos, execução remota de tarefas e gerenciamento de configurações.<br /> * '''''OpenStack Heat templates:''''' o Heat implementa um mecanismo de orquestração para ativar vários aplicativos de nuvem compostos com base em modelos na forma de arquivos de texto que podem ser tratados como código.<br /> * '''''AWS CFN templates:''''' o AWS CloudFormation oferece uma linguagem comum para modelar e provisionar recursos de aplicativos da AWS e terceirizados em um ambiente de nuvem.<br /> * '''''Apache Kafka:''''' é literalmente a &quot;porta da frente&quot; para a entrada dos fluxos dados originados pelos equipamentos da rede.<br /> * '''''Bulk Ingest:''''' atuando como alternativa ao Kafka para acomodar cenários de migração de dados existentes para o PNDA.<br /> * '''''Zookeeper for Kafka:''''' é utilizado pelo Kafka para descoberta e requisições de busca junto aos brokers referentes às partições que deseja consumir.<br /> * '''''JMX Proxy:''''' usado para, dentre outras coisas no PNDA, a exposição de todos os atributos MBean disponíveis em uma determinada JVM por meio de uma simples solicitação HTTP.<br /> * '''''Apache Impala:''''' atuando como um mecanismo de execução paralelo para consultas SQL com acesso de baixa latência e exploração interativa de dados no HDFS e HBase. O Impala permite que os dados sejam armazenados em formato bruto, com a agregação realizada no momento da consulta, sem a necessidade de agregação inicial de dados.<br /> * '''''CMAK (aka &quot;Kafka Manager&quot;):''''' como ferramenta de gerenciamento de clusters Kafka.<br /> * '''''ELK''''' (Logserver)<br /> * '''''Logstash:''''' um dos componentes da arquitetura de logs empregada pelo PNDA, usado para receber dados de inúmeras fontes, transformação e compartilhamento de dados.<br /> * '''''Elasticsearch:''''' um dos componentes da arquitetura de logs empregada pelo PNDA.<br /> * '''''Kibana:''''' um dos componentes da arquitetura de logs empregada pelo PNDA, atuando como plugin de visualização de dados do Elasticsearch.<br /> * '''''Jupyter Hub''''' e '''''Jupyter Notebook:''''' atua como um aplicação que permite criar e compartilhar documentos que contêm código ativo, equações, visualizações e texto explicativo. No PNDA, ele suporta a exploração e apresentação de dados do HDFS e HBase.<br /> * '''''OpenTSDB:''''' atua como um banco de dados escalável de séries temporais que permite armazenar e fornecer grandes quantidades de dados de séries temporais, sem perder granularidade. <br /> * '''''Grafana:''''' atua como construtor de gráficos e painéis para visualizar métricas de séries temporais do PNDA.<br /> * '''''Anaconda:''''' o Anaconda é uma distribuição gratuita e de código aberto das linguagens de programação Python e R para computação científica. Usado para diversas funções do PNDA.<br /> * '''''Consul.io:''''' para gerenciamento de endpoints e descoberta de serviços.<br /> * '''''Apache Flink:''''' atua como uma estrutura e um mecanismo de processamento distribuído para cálculos com estado em fluxos de dados ilimitados e limitados. O Flink foi projetado para executar em todos os ambientes comuns de cluster, executar cálculos na velocidade da memória e em qualquer escala.<br /> * '''''Apache Knox:''''' atua como gateway de aplicativo para interagir com as APIs REST e as UIs das implantações do Apache Hadoop, fornecendo um ponto de acesso único para todas as interações REST e HTTP com os clusters do Apache Hadoop.<br /> O PNDA de fato propõe-se a ser uma plataforma escalável e aberta de big data, com a finalidade de suportar análises operacionais e de inteligência de negócios para redes e serviços, e não sendo uma ferramenta restrita ou específica apenas para ambientes ISP. Algumas destas tecnologias supracitadas dependem de qual distribuição Hadoop for escolhida, sendo que o PNDA pode ser implantado usando Cloudera CDH ou Hortonworks HDP. Dependendo de qual for a distribuição, componentes/pacotes adicionais serão exigidos (ex:, para uma instalação baseada no Cloudera CDH PNDA, são exigidos também Apache Avro + Crunch + DataFu + Hadoop + HBase + Hive + Hue + Impala + Kite SDK + Mahout + Parquet + Pig + Spark + Sqoop/Sqoop2 + ZooKeeper, e outros). <br /> A ilustração a seguir mostra as tantas possibilidades de recebimento de eventos e streaming com o PNDA. Note que o SNAS.io é mencionado como uma das formas de recebimento de dados:<br /> [[Arquivo:Bpf-gerbgp-pnda.jpg|centro|miniaturadaimagem|900x900px|Visão geral do PNDA (Fonte: PNDA.io)]]<br /> <br /> A integração do ''OpenBMP'' ou ''SNAS'' com o ''PNDA'' poderá ser feita usando o ''Logstash''. Conforme já demonstrado anteriormente, os roteadores monitorados enviam as mensagens BMP para o ''OpenBMP/SNAS'', o qual envia estes dados para o ''Kafka''. Por sua vez, o barramento de dados do ''Kafka'' oferece a muitos aplicativos em lote ou streaming a capacidade de acessar feeds BMP existentes de qualquer número de roteadores. A proposta aqui então é a de produzir estes dados BMP no coletor ''OpenBMP/SNAS'' e encaminhá-los para o ''Kafka'' para que possam ser consumidos pelo ''Logstash'' da instalação PNDA. Esta integração está comentada neste link&lt;nowiki/&gt;https://github.com/SNAS/openbmp/blob/master/docs/LOGSTASH.md.<br /> <br /> A interação dos administradores da rede com estes dados poderá ser feita por APIs ou por qualquer outra aplicação que seja pensada para consumir estes dados.<br /> <br /> '''Caso de uso: monitoramento, analíticos e big data com SNAS.io e PNDA.io'''<br /> <br /> Caso você ainda esteja se questionando sobre as vantagens e benefícios de incorporar conceitos de telemetria para o monitoramento do seu BGP, talvez esta seção do artigo possa convencê-lo. Um dos maiores atrativos da telemetria baseada orientada a modelos (eventos + streaming periódico) é que permite obter dados em tempo real e com flexibilidade e granularidade muito superiores aos modelos de gerenciamento tradicionais, já discutidos previamente neste artigo. Quando combinando este modelo de gerenciamento com as soluções certas baseadas em software, você passa a ter acesso a praticamente tudo aquilo que você não conseguia conceber com os modelos tradicionais.<br /> <br /> Nunca foi tão viável entrar no mundo de analíticos e big data com foco nas questões de rede, neste caso aqui o BGP. A combinação de SNAS.io e PNDA.io pode destravar a inteligência que está faltando na grande maioria dos Sistemas Autônomos que correspondem aos ISPs e pequeno e médio portes. Ou seja, big data não é mais luxo de grandes operadores de redes!<br /> <br /> Dentre tantas ações viáveis com big data sobre o BGP, é possível classificar e filtrar todo o histórico de anúncios originados e anunciados por AS, o que por sua vez permite compreender melhor como as mudanças realizadas por upstreams podem estar afetando a convergência do roteamento BGP do seu AS. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda1.png|centro|miniaturadaimagem|900x900px|Análise de prefixos originados e anunciados por AS (Fonte: pnda.io)]]Outra possibilidade é poder consultar informações detalhadas sobre qualquer AS que estiver mencionado em qualquer anúncio que tenha sido registrado e armazenado na base de dados da solução, e isto, por si só, já economiza um tempo bastante razoável, pois você não precisaria ter que recorrer a sistemas ou websites externos para obter estas informações. E sem contar que estas informações sobre estes AS podem ser processadas para representar uma infinidade de analíticos e relatórios adicionais. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda2.png|centro|miniaturadaimagem|900x900px|Informações detalhadas por AS (Fonte: pnda.io)]]Uma das necessidades mais críticas no que diz respeito aos projetos mais elaborados de engenharia de tráfego com o BGP é contar com uma visibilidade bastante aprofundada das relações entre os Sistemas Autônomos na visão do AS da sua empresa, pois isto é o que permite estudar a cadeia de relações com propriedade e conduzir - com auxílio de outros procedimentos - os estudos sobre as matrizes de tráfego, dentre outras coisas. A obtenção destas informações pelos métodos tradicionais é praticamente inviável. Por exemplo, não é viável com SNMP. Já por CLI/Scripting visando a recuperação, ''parsing'' e armazenamento destas informações numa base de dados para consultas posteriores, enfim, seria ao mesmo tempo frágil, pouco escalável, e com elevados requerimentos computacionais, ou seja, praticamente inviável. Por sua vez, o monitoramento do BGP por telemetria, combinado com soluções de software especializadas no processamento e tratamento destes dados, habilita todo um big data sobre como o AS da sua empresa se relaciona com os demais AS da Internet. Com funções inteligentes de pesquisa de baixíssimo esforço você poderá compreender como o seu AS se relaciona com os demais AS da Internet. A ilustração a seguir mostra isso:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda3.png|centro|miniaturadaimagem|900x900px|Análise de relações entre os AS associados aos anúncios mantidos na base de dados (Fonte: pnda.io)]]Outra aplicação muito útil: imagine que você precise estudar os caminhos de AS_PATH associados a determinados destinos, por exemplo, entre dois ASs quaisquer. Como você faria isto pelas vias normais? Você simplesmente teria que acessar diversos roteadores e estudar &quot;na unha&quot;, um por um, todos os anúncios em combinação com cada opção de caminho entre a origem e o destino desejados. Se você conhece bem o BGP e atua em uma operadora ou ISP de maior porte, certamente já teve que fazer este tipo de trabalho um bocado de vezes. Demanda muito tempo, foco, atenção! Pois bem, numa plataforma de analíticos &amp; big data com dados de BGP você não teria dificuldade em estudar todos os caminhos entre a origem e o destino pretendidos, e com &quot;ridículos&quot; cliques identificar quais são os caminhos ativos, quais são os caminhos de menor comprimento de AS_PATH, e quais são os caminhos de maior comprimento de AS_PATH. E tudo isto numa fração de minuto! Isto é demonstrado na ilustração a seguir:[[Arquivo:Bpf-gerbgp-pnda4.png|centro|miniaturadaimagem|900x900px|Análise caminhos &quot;ativo, mais curto, mais longo&quot; entre dois AS (Fonte: pnda.io)]]Nem tudo são flores na parte de segurança do BGP, em especial anomalias associadas a prefixos e atributo AS_PATH. Uma vez que todas as informações do BGP estão armazenadas em bases de dados bastante otimizadas para analíticos, com pouco esforço você conseguirá identificar problemas relacionados à segurança do BGP. A ilustração a seguir demonstra esta facilidade:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda5.png|centro|miniaturadaimagem|900x900px|Análise de anomalias associadas a prefixos e AS_PATH (Fonte: pnda.io)]]Mais uma funcionalidade interessante aqui: você poder estudar cada ASN identificado na base de dados da solução, consultar informações detalhadas de casa ASN, obter um histórico dos anúncios enviados e recebidos de/para cada ASN, estudar a lista de AS_PATH associada aos anúncios, pesquisar por problemas que podem estar assolando o roteamento BGP do seu AS, dentre outras necessidades.<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda6.png|centro|miniaturadaimagem|900x900px|Análise de caminhos por AS (Fonte: pnda.io)]]<br /> <br /> Por ser uma solução em grande parte baseada em software de código aberto, entendo que o potencial de customização seja absurdo. Na mão de times de desenvolvimento experientes, a sua empresa poderá customizar a solução como bem desejar, incorporando elementos diversos, ajustando, refinando, até que obtenha-se os resultados desejados pelas diversas áreas internas do negócio que possam beneficiar-se com as funções, relatórios e analíticos do monitoramento BGP.<br /> <br /> Para concluir o tema SNAS.io + PNDA.io, caso você queira experimentar uma versão minimalista (com algumas limitações e não recomendado para ambientes de produção), recomendo o [https://github.com/pndaproject/red-pnda Red PNDA]! Você poderá baixar a OVA e rodá-la como uma máquina virtual em uma sandbox para explorar e aprender a desenvolver sobre um ambiente PNDA propício.<br /> <br /> === Conclusão do artigo e próximos passos ===<br /> O tema gerenciamento por si só é algo absolutamente muito extenso, mesmo que eu tenha focado apenas no gerenciamento/monitoramento do BGP. Infelizmente, não há como realmente dissertar livremente sobre o tema em um único artigo. Todavia, está no radar de próximos artigos, aqui na wiki do BPF, conteúdos relacionados ao gerenciamento/monitoramento do BGP com os seguintes:<br /> * Aplicabilidades do ''Multi-Threaded Routing'' (MRT)<br /> * Gerenciamento e monitoramento por telemetria com exemplos de soluções (ex: Cisco IOS XR Telemetry, Pipeline, e outros)<br /> * Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> * Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> * Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> * Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> Siga acompanhando os trabalhos do Brasil Peering Forum! Espero que você tenha curtido este artigo; divulgue-o!<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> [[Categoria:Roteamento]]</div>

Leonardo.furtado https://wiki.brasilpeeringforum.org/index.php?title=Solucoes_para_o_gerenciamento_efetivo_do_bgp_em_um_sistema_autonomo&diff=2456 2020-05-25T02:37:22Z

<p>Leonardo.furtado: </p> <hr /> <div>=== Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo ===<br /> ====Nota sobre direitos autorais, termo de uso e isenção de responsabilidade====<br /> Consulte [[Direitos Autorais Licenca de Uso|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].<br /> <br /> '''Autor: [[Usuário:Leonardo.furtado|Leonardo Furtado]]'''<br /> <br /> === Introdução ===<br /> Todos os engenheiros de redes sênior que atuam em ISPs, ou em qualquer empresa séria que possua um Sistema Autônomo, compreendem a importância em estudar corretamente a farta quantidade de informações referentes às sessões e respectivas tabelas BGP, e não apenas na perspectiva da tabela BGP de seus próprios e respectivos ASNs, e sim estendendo estes estudos e tratamentos de dados na perspectiva de vários pontos de monitoramento, os quais incluem coletores, ''route views'', ''looking glasses'', e afins, espalhados pela Internet. Ou seja, como você (ou, neste caso, o seu ASN) vê o mundo ao seu redor, e como as várias partes do mundo (ASNs em suas respectivas regiões) vêem o seu ASN.<br /> <br /> Isto para sintetizar primariamente as iniciativas de prevenção dos dois principais tipos de incidentes envolvendo o roteamento de Internet, a saber: ''route leaks'' e ''prefix hijack''. Só que as necessidades de um ASN no que tange ao monitoramento de seu BGP vão bem além do que somente (embora gravíssimos) incidentes com ''route leaks'' e ''prefix hijacks'', para os quais, inclusive, já existem BCOPs específicas para prevenção e mitigação, como é o caso do &lt;nowiki&gt;RFC 7454&lt;/nowiki&gt; / BCP 194, BCP 38, BCP 185, e MANRS. Há muito mais coisas a serem observadas e tratadas com relação ao BGP do que apenas as questões de segurança.<br /> <br /> Ou seja, em adição às questões de segurança, o Sistema Autônomo/ASN precisa monitorar constantemente, dentre dezenas de objetos e métricas gerenciáveis, e seus respectivos KPIs, e de uma magnitude grande de componentes, o '''''&lt;u&gt;seu&lt;/u&gt; BGP''''' como um todo. Isto para que respostas possam ser fornecidas para sanear diversos desafios que vão além da segurança do roteamento daquele ASN (e estendendo-se para seu cone de clientes), tais como a escalabilidade, engenharia de tráfego com ênfase na redução inteligente de custos e com potencial aumento de qualidade de serviço (ex: fornecer conteúdo com menor latência ao mesmo tempo em que reduzindo custos com esta iniciativa); planejamento de capacidades, planejamento das métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, os padrões de convergência da rede, plano diretor de investimentos, desenvolvimento e manutenção da cesta de produtos e serviços com foco na capacidade e uso estatístico de recursos da rede, toda a parte financeira também, etc.<br /> <br /> Falando especificamente do BGP, os modelos &lt;u&gt;tradicionais&lt;/u&gt; de monitoramento possuem restrições: ''routeviews'' (com algumas exceções) e ''looking glasses'' não mantém históricos de informações sobre rotas (seja pelo prefixo direto ou pela expressão regular do atributo AS_PATH), consequentemente não se sabe o que aconteceu, quando e por quem. Além disto, uma sessão BGP somente anuncia as suas melhores rotas (''best path''), e esta informação pode ser obtida de um roteador por CLI ou outro procedimento, como o NETCONF, porém, novamente, sem dados históricos. O que algumas empresas fazem para compensar estas restrições dos modelos tradicionais com ferramentas vigentes é recorrer a soluções e sistemas que consigam manter estas informações numa base de dados que seja flexível, escalável e gerenciável, e que mantenha um histórico de mudanças sobre estes registros. Ou seja, construir e customizar sistemas específicos, ou adquirir um sistema comercial para este propósito. E que, preferencialmente, seja de fácil integração com outros sistemas (incluindo Sistemas de Suporte à Operação (OSS)).<br /> <br /> O que estou propondo aqui é ampliar os conceitos de ferramentas para o monitoramento efetivo do BGP: além de manter seus ''looking glasses'' e consultar ''route views'', onde aplicáveis, os ASN poderem manter as suas próprias bases de dados com históricos acerca de tudo o que ocorre com o BGP na perspectiva daquele ASN, de seu cone de clientes, além da sua relação com seus upstreams de trânsito IP, sessões de peering e afins. Ou seja, não apenas o &quot;snapshot&quot; do que está acontecendo na hora, mas obter informações sobre prefixos e ASNs através de uma linha temporal e para atender diversos casos e aplicações técnicas e de negócios. É o que chamamos de &quot;'''''telemetria orientada a modelos'''''&quot;, que, nos projetos mais sofisticados e completos, combina ferramentas de &quot;telemetria baseadas em eventos&quot; (obtenção de dados por CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, BMP, etc.), e &quot;telemetria de streaming periódica&quot;, com monitoramento de diversos objetos relacionados à capacidade e dados estatísticos de consumo (latência, ''throughput'', processamento) por meios de diversas ferramentas e procedimentos. Interessante, não?<br /> <br /> Em suma, este artigo está centrado na dissertação de propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!<br /> <br /> ==== Observação importante: ====<br /> Se você estiver aguardando uma solução &quot;pronta&quot; ou com uma expectativa de que eu vá fornecer aqui uma &quot;receita de bolo&quot;, lamento muito, mas não é esta a intenção do artigo! Fornecerei aqui uma visão muito mais ampla deste contexto, e tentarei desmembrar este tópico empregando alguns conceitos de pesquisa aplicada e de desenvolvimento experimental. Entenda isto como um pontapé inicial para que você consiga adquirir os conhecimentos necessários para desenvolver seus próprios conceitos de adoção tecnológica, processual e instrumental, objetivando o gerenciamento e monitoramento do BGP de seu AS, e culminando na tomada de decisão de sua parte sobre uma ou mais das seguintes possibilidades:<br /> # Investimentos em soluções comerciais existentes, com potencial de customizações e integração com outros sistemas para o atendimento de necessidades específicas do seu negócio.<br /> # Desenvolvimento de sistemas com fábrica de software própria, atendendo a todos os modelos de gerenciamento desejados.<br /> # Adoção de ferramentas específicas para o atendimento de necessidades igualmente específicas, tais como soluções de código aberto ou até mesmo de ordem comercial.<br /> <br /> === Um &quot;abre-alas&quot; sobre a importância e missão dos sistemas de gerenciamento no geral ===<br /> Antes de começarmos, gostaria de comentar uma característica do meu trabalho e que afeta o meu julgamento por completo. Aqueles que me conhecem de longa data sabem que sou um tanto insistente em algumas das minhas análises, visões, conclusões e objeções. Para estas pessoas que me conhecem, quantas vezes já não ouviram o Leonardo Furtado citar a seguinte frase?&lt;blockquote&gt;''&quot;Muitos profissionais de ISP (incluindo alguns perfis de gestores) pecam na hora de investir e de tomar decisões importantes para seus negócios: adquirem soluções tecnológicas focando apenas ou principalmente nas necessidades de curto prazo, muitas vezes adotando soluções minimalistas, e centradas no fator de menor custo&quot;''&lt;/blockquote&gt;A relação desta frase com o artigo em questão é óbvia, e você entenderá melhor logo a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem que haja um propósito bem definido para as áreas do negócio que realmente importam. Muitas vezes a necessidade é muito óbvia ou específica, tais como &quot;monitorar o consumo de banda referente a uma interface conectada para um upstream de trânsito IP&quot;, o que é plenamente justificável, sem dúvidas, claro! No entanto, o maior problema não reside no objeto gerenciado em questão (monitoramento de banda, monitoramento de problemas de uma interface, processamento, etc.), e sim na ausência de analíticos associados aos objetos gerenciados pelas ferramentas em questão, as quais foram adquiridas pela organização (e seja lá quais tenham sido os critérios), e que foram implantadas pelo time de engenharia ou de operações. Em outras palavras: o software está &quot;lá&quot;, implantado, e sendo (sub)utilizado pelos operadores. Mas.. quais são os reais objetivos? Quais são os indicadores desejados? Quais são os ''thresholds''? Quais são as métricas gerenciáveis daquele componente, de cada componente? Como determinados ''thresholds'' e eventos associados àquele objeto impactam no meu negócio? Quais ações e tomadas de decisões executaremos para prevenir, mitigar e responder ao eventos fornecidos pelo gerenciamento acerca daquele objeto gerenciado? Como este objeto gerenciado participa do meu negócio e nas diversas áreas, centros de custo, e contextos, incluindo comercial, reputação, financeiro (capex, opex, fluxo de caixa, etc.), engenharia (capacidade, disponibilidade, resiliência, consumo de recursos, tráfego, etc.), operações, fornecedores, etc.? A lista é grande.<br /> <br /> Com 25 anos de profissão, o que mais vi em toda a minha carreira e em muitas empresas que visitei foram soluções de gerenciamento inteiras praticamente &quot;encalhadas&quot;, subutilizadas! Sistemas complexos e por muitas vezes interessantes que, de diversas funções e capacidades disponíveis, são extraídos apenas recursos pontuais e, mesmo assim, sem que analíticos e dados importantes pudessem ser coletados, tratados e consumidos pelas áreas relevantes do negócio para que estas pudessem aproveitar estas informações para algo realmente útil, seja algo visando aprimorar a parte técnica/tecnológica ou a parte do negócio propriamente dito.<br /> <br /> Outra forma de sintetizar isto: ''&lt;u&gt;em muitas empresas não há efetivamente um projeto prevendo a construção (ou adoção/contratação) de sistemas de gerenciamento&lt;/u&gt;''. O gerenciamento efetivo ou adequado é frequentemente a parte mais negligenciada da infraestrutura.<br /> <br /> Dissertar amplamente sobre isto está fora do escopo deste artigo, mas a mensagem que gostaria de deixar aqui é bem simples: tratando-se de sistemas de gerenciamento, e não importando para qual finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), procure conduzir um projeto técnico consistente e específico para este(s) sistema(s), e que vá identificar e documentar os seguintes:<br /> * Em alinhamento com o projeto de infraestrutura vigente, incluindo todo o parque tecnológico presente (hardware e software), quais são as necessidades da área técnica da empresa, assim como de possíveis outras áreas interessadas?<br /> * Quais problemas estamos sofrendo no momento e/ou que gostaríamos de evitar?<br /> * Como cada um destes problemas, incidentes ou circunstâncias impacta nos negócios da empresa? É possível quantificar os prejuízos, quaisquer que sejam (reputação, multas, reparação, cancelamento de contratos, perda de receitas, aumento de custos imprevistos, etc.)? E quais áreas internas do negócio são impactadas? É viável fazer esta associação?<br /> * Quais deverão ser os objetos gerenciados?<br /> * Quais são as facilidades de gerenciamento suportadas pelo meu parque tecnológico (HW e SW)? E quais são as capacidades demandadas sobre cada um destes recursos?<br /> * Das tecnologias ou recursos disponíveis e suportados pela infraestrutura, quais são as melhores e mais aderentes opções para o atendimento de cada objeto gerenciado identificado? (prós e contras, matriz funcional de qualidade, etc.)<br /> * Quais deverão ser os indicadores e métricas para estes objetos gerenciados quando utilizando-se dos recursos ou facilidades de gerenciamento identificados como mais aderentes para os meus propósitos?<br /> * Como as áreas internas do negócio, onde aplicáveis, consumirão estes analíticos, indicadores e métricas?<br /> * Quais processos deverão ser estabelecidos para ações de prevenção, mitigação e reação quanto aos ''thresholds'' dos objetos gerenciados?<br /> * Dentre muitas questões.<br /> Somente após responder estas perguntas e planejar toda a iniciação do projeto de adoção de solução de gerenciamento é que você conseguirá encontrar a solução ideal, a(s) &quot;ferramenta(s)&quot;, e fazendo isto com critérios consistentes nos requisitos de facilidades, recursos, integração, custos, etc. Entendo que esta deva ser a aderência a ser pensada e projetada, assim como entendo que você precisará instaurar os processos primeiro para depois chegar a estas conclusões. Dica: para o tema &quot;processos&quot;, confira o artigo [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]]! <br /> <br /> A implantação e operação de sistemas de gerenciamento, quaisquer que sejam as finalidades, deve passar primeiro por um plano de projeto que vá identificar todas as questões envolvendo necessidades, desafios, métricas desejadas, capacidades e qualidades demandadas, os objetos a serem gerenciados, as facilidades e recursos necessários, como os dados serão coletados, processados e armazenados, e como a organização como um todo deverá consumir e tirar proveito destes dados para aprimorar seus indicadores. <br /> [[Arquivo:Bpf-gerbgp-requisitos.png|centro|miniaturadaimagem|900x900px|&quot;Carroça não anda na frente de boi&quot;: exercite o planejamento antes de sair implantando ferramentas, e usufrua de melhores resultados!]]<br /> <br /> === Por que um ASN precisa investir no gerenciamento de seu ambiente BGP? ===<br /> Ou '''''quais problemas poderão ser resolvidos com o gerenciamento efetivo do BGP em seu ASN'''''?<br /> <br /> &lt;u&gt;A sequência deste artigo estará centrada quase que integralmente no &quot;BGP&quot;&lt;/u&gt; e possivelmente citarei outros elementos que participam diretamente do funcionamento deste. Ou seja, não pretendo realmente dissertar sobre necessidades, objetivos e requisitos gerais envolvendo disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isto não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?<br /> <br /> Suponhamos que as áreas de engenharia e operações de um ISP cheguem a um consenso de que é necessário ter ampla visibilidade e acesso à informações relevantes especificamente relacionadas ao BGP para que sejam discutidas formas de antecipar e mitigar riscos, e responder aos diversos tipos de incidentes relacionados às questões de segurança, disponibilidade, performance, ou seja, o SLA em geral, assim como o planejamento de capacidades e a engenharia financeira do negócio. Se tivéssemos que exercitar este consenso entre estas duas áreas, quais teriam sido alguns dos diversos critérios factíveis? Para este exercício hipotético, proponho que estes requisitos sejam devidamente categorizados da seguinte forma para melhor compreensão e dissertação de casos:<br /> * '''Segurança do roteamento BGP'''<br /> * '''Segurança do plano de controle da rede'''<br /> * '''Segurança contra ataques de negação de serviços'''<br /> * '''instabilidades do BGP'''<br /> * '''Engenharia de tráfego'''<br /> * '''Planejamento de capacidades'''<br /> * '''Reputação e conformidade'''<br /> O seu trabalho, na condição de engenheiro de rede ou arquiteto de soluções, deverá ser a busca por respostas para iniciar este planejamento!<br /> [[Arquivo:Bpf-gerbgp-planejamento.png|centro|miniaturadaimagem|900x900px|Brainstorming para o planejamento de uma solução de gerenciamento específica para o BGP]]<br /> Dissertemos um pouco mais sobre estes caso hipotético através da exposição de conceitos envolvendo '''''Necessidades''''', '''''Requisitos''''', '''''Problemas ou desafios a serem resolvidos''''' pelas organizações que operam um Sistema Autônomo, sendo provedores de acesso à Internet (ISP) ou não:<br /> {| class=&quot;wikitable&quot;<br /> |+<br /> Matriz de Necessidades, Requisitos e Desafios a serem Superados para a Demanda &quot;BGP&quot; do ISP<br /> !Categoria<br /> !Necessidade<br /> !Requisito<br /> !Problemas ou desafios a serem resolvidos<br /> !Partes interessadas<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento da segurança do roteamento BGP'''<br /> |Deteção e mitigação de prefixos Bogons<br /> |Identificação e mitigação de prefixos Bogons, Maritans e não alocados<br /> |<br /> * Evitar o recebimento e propagação de rotas referentes a prefixos Bogons, Martians e Unallocated<br /> * Aumentar a reputação do Sistema Autônomo, como parte de boas práticas para a prevenção de incidentes de segurança associados a anúncios bogons.<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de vazamento de rotas e sequestro de prefixos do ASN<br /> |Identificação e mitigação de route leaks<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Assegurar que o ASN não crie ou gere route leaks, assim como assegurar que route leaks não sejam aceitos a partir de sessões de clientes, peering e trânsito<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Encurtar o tempo de deteção de incidentes envolvendo route leaks<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de route leaks<br /> |NOC, Engenharia<br /> |-<br /> |Identificação e mitigação de sequestro de prefixos (prefix hijacks)<br /> |<br /> * Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos<br /> * Evitar que a reputação do ASN seja afetada em decorrência destes eventos<br /> * Evitar que o ASN não sequestre prefixos, assim como recusar o recebimento de quaisquer anúncios com ROA (RPKI) e/ou IRR inválidos<br /> * Encurtar o tempo e detecção de incidentes envolvendo o sequestro de prefixos<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de sequestro de prefixos<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Deteção e mitigação de abusos contra recursos do BGP<br /> |Controle de recebimento de anúncios de ASNs vizinhos<br /> |<br /> * Evitar abusos e possíveis impactos relacionados à capacidades e escassez de recursos<br /> * Evitar que ASNs de clientes anunciem de forma acidental ou maliciosa uma quantidade de prefixos superior à estimada ou autorizada<br /> * Evitar abusos com a desagregação através de anúncios excessivamente específicos recebidos de clientes, peering e trânsito<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> |Controle de abuso de AS-Path Prepending<br /> |<br /> * Evitar que o ASN do ISP, assim como ASNs vizinhos e o restante da Internet, sofram possíveis impactos e instabilidades quanto à prefixos com excesso de AS-Path Prepending atrelado aos anúncios<br /> * Evitar abusos quanto ao recebimento de rotas BGP que contenham AS-Path Prepending excessivos (uma forma de ''Self-Inflicted Vulnerability'')<br /> * Encurtar o tempo de detecção de incidentes desta natureza.<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios<br /> |NOC, Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da segurança do plano de controle da rede'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de incidentes de segurança contra o próprio BGP<br /> |Controle de vulnerabilidades sobre as mensagens do BGP<br /> |<br /> * Evitar indisponibilidades e outros tipos de incidentes que possam ser provocados com a exploração das mensagens do BGP (conforme (3.1. Vulnerabilities in BGP Messages do &lt;nowiki&gt;RFC 4272&lt;/nowiki&gt;)<br /> * Evitar a manipulação e injeção maliciosa de atributos sobre os anúncios por mensagens ''Update'' do BGP<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de exploração destas vulnerabilidades<br /> |SOC, NOC. Engenharia<br /> |-<br /> |Controle de incidentes de segurança lançados diretamente contra as sessões BGP<br /> |<br /> * Evitar que as sessões BGP sejam atingidas diretamente por técnicas maliciosas que visam desde o downtime/indisponibilidade, sequestro de sessões, injeção de informações errôneas<br /> * Encurtar o tempo de detecção de incidentes desta natureza<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de ataques lançados contra os processos BGP<br /> |SOC, NOC, Engenharia<br /> |-<br /> |'''Gerenciamento da segurança contra negação de serviços'''<br /> |Detecção e mitigação contra ataques DDoS<br /> |Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS<br /> |<br /> * Evitar ou atenuar efeitos adversos de indisponibilidades, instabilidades, impactos severos no SLA de clientes, prejuízos financeiros de grandes proporções, e danos na reputação da empresa<br /> * Evitar a injeção de informações maliciosas na tabela BGP que permitam livre comunicação entre hosts infectados em suas botnets<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e mitigação de DDoS<br /> |SOC, NOC, Engenharia<br /> |-<br /> | rowspan=&quot;5&quot; |'''Gerenciamento de instabilidades do BGP'''<br /> | rowspan=&quot;5&quot; |Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA<br /> |Detecção de oscilações de sessões BGP<br /> |<br /> * Evitar que ocorram instabilidades na prestação de serviços de acesso à Internet por conta de oscilações das sessões BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e problemas com as sessões BGP<br /> |NOC<br /> |-<br /> |Detecção de oscilações de rotas (route flaps)<br /> |<br /> * Evitar que ocorram indisponibilidades na comunicação com determinados serviços/destinos de Internet por conta de oscilações e intermitências quanto à convergência da tabela BGP<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e oscilações de rotas BGP<br /> |NOC<br /> |-<br /> |Detecção de rotas eventualmente suprimidas por Dampening<br /> |<br /> * Evitar discrepâncias nas matrizes de tráfego e, de certa forma, atenuar a assimetria do roteamento IP, ''blackhole'' ou ''routing loops'' por conta da eventual supressão de rotas (dampening) executada no ASN local ou em vizinhos<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de supressão de rotas BGP e como estes eventos afetam o comportamento da rede e a disponibilidade de serviços<br /> |NOC<br /> |-<br /> |Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces<br /> |<br /> * Evitar que determinados recursos tais como capacidade de enlaces, arquiteturas de roteadores (CPU, memória, FIB, etc.) fiquem subutilizados enquanto outros elementos fiquem sobrecarregados<br /> * Evitar gargalos nas operações e transações de rede, os quais podem provocar impactos no SLA<br /> * Encurtar o tempo de detecção e reação a estes tipos de incidentes<br /> * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção de gargalos e esgotamento de recursos<br /> |NOC, Engenharia<br /> |-<br /> |Planejamento e antecipação de cenários &quot;what if&quot;<br /> |<br /> * Evitar que manobras de configurações, incluindo modificações nas políticas de roteamento e ações de engenharia de tráfego provoquem distúrbios não antecipados<br /> * Antecipar impactos na convergência e disponibilidade da rede através de uma análise preditiva envolvendo cenários de falhas<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;4&quot; |'''Gerenciamento da engenharia de tráfego'''<br /> | rowspan=&quot;2&quot; |Detecção e mitigação de impactos sobre os recursos de infraestrutura decorrentes de eventos pontuais na Internet<br /> |Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento<br /> |<br /> * Superar as limitações operacionais da empresa em função da escassez de informações e a falta de visibilidade sobre os fluxos de tráfego<br /> * Aprimorar as ações de dimensionamento de recursos de infraestrutura, tais como plataformas de switches e roteadores, além de enlaces de comunicação de dados<br /> * Aprimorar os resultados das ações de engenharia tráfego para fins de acomodar melhor as conversações da rede sobre os recursos disponíveis<br /> * Atenuar ou eliminar os desafios que provocam impactos sobre o SLA de assinantes<br /> * Fornecer analíticos, dados históricos e baselines relacionados às matrizes de tráfego, com histórico de consumo por ASN, peer, prefixo, protocolo de transporte, tipo de aplicação, marcações, atributos, etc.<br /> |Engenharia<br /> |-<br /> |Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas<br /> |<br /> * Reduzir os indicadores de MTTR e MDT associados aos eventos de falhas relacionadas ao BGP<br /> * Reduzir os indicadores de reclamações por conta da violação de SLAs envolvendo indisponibilidades, latência, jitter, perda de pacotes, etc.<br /> * Reduzir os impactos provocados nas áreas internas do negócio que são destinadas ao interfaceamento com clientes, tais como comercial, atendimento a clientes, NOC, jurídico, etc.<br /> * Fornecer analíticos, dados históricos e baselines referentes aos impactos decorrentes de falhas para alimentar as tomadas de decisão e para nortear os investimentos e processos de mitigação<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Aprimoramento de SLA<br /> |Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP<br /> |<br /> * Reduzir impactos não antecipados sobre ações de engenharia de rede e de tráfego executadas pela área de engenharia ou de operações da empresa<br /> * Aprimorar as tomadas de decisão acerca das políticas de roteamento para o atendimento dos modelos de interconexão privado e público<br /> * Aprimorar as tomadas de decisão para as políticas de roteamento de acordo com os modelos de interesse de tráfego (''hot potato'', ''cold potato'', e outras diretrizes) sobre os regimes de interconexão <br /> * Fomentar ações racionais de engenharia de tráfego para equilibrar as métricas de SLA (latência, jitter, disponibilidade) sobre os custos (opex) de cada enlace de transporte e de de cada acordo de troca de tráfego<br /> |Engenharia<br /> |-<br /> |Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como MPLS TE e SR-TE<br /> |<br /> * Assegurar aderência quanto ao mapeamento do tráfego sobre os recursos locais do AS, prevendo simultaneamente as métricas de desempenho e a relação de custos de infraestrutura para a sustentação de SLAs<br /> * Promover a redução racional de custos através da associação de classes de tráfego ou de matrizes de conversação sobre os enlaces e sessões associadas às métricas de SLA de cada caso<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;3&quot; |'''Gerenciamento da planejamento de capacidades'''<br /> | rowspan=&quot;3&quot; |Planejamento de capacidades com foco na redução racional de custos operacionais<br /> |Bilhetagem e tarifação de tráfego<br /> |<br /> * Determinação da matriz de tráfego em combinação com iniciativas de bilhetagem e tarifação para determinar rateio de custos de infraestrutura nas áreas internas do negócio<br /> * Fornecer métricas de utilização dos fluxos de tráfego de interesse sobre os recursos de transporte para identificar áreas de otimização de custos<br /> * Viabilizar a compreensão da participação de cada centro de custo / área interna do negócio quanto aos padrões de consumo e contribuições orçamentárias<br /> * Viabilizar e fomentar a derivação da política de preços de produtos e serviços destinados a clientes em função das matrizes de tráfego, interesses de tráfego e modelos de interconexão<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |Dimensionamento de recursos de transporte e acordos de troca de tráfego<br /> |<br /> * Planejamento de capacidades de conexões do ISP com os acordos de troca de tráfego nos regimes de peering e trânsito IP, incluindo 95th percentil<br /> |Engenharia<br /> |-<br /> |<br /> * Dimensionamento de especificações, requisitos, recursos e capacidades das arquiteturas e demais componentes de infraestrutura a serem utilizados para a sustentação dos modelos de interconexão para os perfis de tráfego<br /> |Engenharia<br /> |-<br /> | rowspan=&quot;2&quot; |'''Gerenciamento da reputação e conformidade'''<br /> |Conquistar níveis de excelência em conformidade<br /> |Deteção e mitigação de incidentes e situações não aderentes aos frameworks e boas práticas destinadas aos Sistemas Autônomos<br /> |<br /> * Fornecer analíticos e dados históricos que classifiquem as ocorrências de incidentes provocados por eventos previstos e imprevistos pelas políticas internas da empresa<br /> * Fornecer métricas auditáveis quanto os incidentes de segurança associados ao BGP<br /> |NOC, SOC, Engenharia<br /> |-<br /> |Conquistar níveis de excelência na reputação do Sistema Autônomo<br /> |Fornecimento de ferramentas para o compartilhamento de transparência e iniciativas de suporte com outros (demais) Sistemas Autônomos<br /> |<br /> * Manutenção de sistemas e bases de informação que divulguem, dentre outros, a política de roteamento da empresa, plano de communities, &quot;normas da casa&quot;, requisitos de segurança, requisitos de interconexão, modalidades de SLA, etc.<br /> * Manutenção de sistemas e bases de informação que forneçam os pontos de contato e suporte para as demandas associadas ao BGP e contextos periféricos do AS, tais como &quot;Abuse&quot;, &quot;Peering&quot;, &quot;NOC&quot;, e outros<br /> * Disponibilização de ferramentas de autosserviço para a redução do tempo de diagnóstico e identificação de problemas por parte de NOCs de outros Sistemas Autônomos, tais como Looking Glass e outros.<br /> * Promover aderência quanto às boas práticas citadas pelos objetivos &quot;''Coordination''&quot; e &quot;''Global Validation''&quot; do ''Mutually Agreed Norms for Routing Security'' (MANRS) <br /> * Fornecer analíticos acerca da utilização das ferramentas de autosserviço para identificar necessidades de mercado, técnicas, perfil dos visitantes, áreas de interesse e geração de novas oportunidades <br /> |NOC<br /> |}<br /> <br /> === Exemplos de soluções conhecidas para o atendimento das diversas necessidades e requisitos associados ao gerenciamento do Sistema Autonomo ===<br /> No que diz respeito aos conjuntos de necessidades e respectivos requisitos fornecidos na tabela anterior, eu particularmente compreendo que tratam-se de situações absolutamente reais. Ao projetar a tabela acima, em nenhum momento pensei especificamente ou diretamente nas possíveis soluções e ferramentas que pudessem ser empregadas para cada caso, ou seja, toda a linha de raciocínio foi de fato estabelecida sobre '''''necessidades + requisitos + problemas + desafios''''' que entendo que a maioria dos operadores de redes tenham interessem em lidar em suas operações cotidianas.<br /> <br /> Todavia, chegaria o momento em que precisaríamos traduzir isto para um plano definitivamente concreto, certo? Sim, precisaríamos identificar ferramentas que conseguissem fornecer resultados para cada uma das situações descritas na tabela anterior. E é justamente isto que tentarei fazer agora: num primeiro momento, &quot;espalhar na mesa&quot; o que temos no mercado hoje; as soluções existentes que podem ser usadas para executar estes casos e cumprir com estas necessidades. <br /> <br /> Note que as ferramentas associadas a cada tipo de requisito não fornecem apenas as funcionalidades para aquele requisito em questão: tomei a liberdade de fazer desta forma apenas para deixar claro que a ferramenta foi &quot;pensada&quot; após o par &quot;necessidade + requisito&quot; ter sido identificado e confirmado para o meu conceito de projeto. <br /> <br /> Está fora do escopo desta parte do artigo qualquer esforço de validação e dissertação de aderência qualitativa (&quot;''o quão bem a ferramenta X executa e atende as necessidades, requisitos, problemas, desafios...''&quot;), assim como promover qualquer comparativo entre as opções mencionadas (&quot;''qual é a melhor ferramenta para a necessidade X?''&quot;).<br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança do roteamento BGP<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação e mitigação de prefixos Bogons, Martians e não alocados'''<br /> | rowspan=&quot;3&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://radar.qrator.net/ RADAR by QRATOR]<br /> * [https://team-cymru.com/community-services/bogon-reference/ Team Cymru fullbogons]<br /> |-<br /> |'''Identificação e mitigação de route leaks'''<br /> |-<br /> |'''Identificação de sequestro de prefixos'''<br /> |}<br /> O &lt;nowiki&gt;RFC 7908&lt;/nowiki&gt; (''Problem Definition and Classification of BGP Route Leaks'') descreve com bastante propriedade a caracterização e tipificação dos incidentes denominados route leaks, enquanto o draft-ietf-grow-route-leak-detection-mitigation-02 (''Methods for Detection and Mitigation of BGP Route Leaks'') propõe mecanismos de detecção e mitigação destes incidentes. Está fora do escopo deste artigo a dissertação sobre route leaks.<br /> <br /> Em adição, diversos artefatos contendo recomendações para a mitigação de prefix hijack foram produzidos, dentre eles o BCP 185 (''Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)''), &lt;nowiki&gt;RFC 7682&lt;/nowiki&gt; (''Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration''), &lt;nowiki&gt;RFC 2650&lt;/nowiki&gt; (''Using RPSL in Practice''), e o &quot;''Action 1: Prevent propagation of incorrect routing information''&quot; do Mutually Agreed Norms for Routing Security (MANRS). A dissertação sobre prefix hijack está fora do escopo deste artigo.<br /> <br /> As ferramentas comentadas na tabela acima podem ser usadas para fornecer dados e até mesmo, em alguns casos, prover algum grau de automação na resposta de incidentes envolvendo route leaks, prefix hijacks e outras situações. Outra possibilidade bastante interessante é projetar integrações entre estas ferramentas/serviços por meios as APIs disponibilizadas. Nos exemplos indicados acima, a [https://developer.thousandeyes.com/v6/ ThousandEyes fornece APIs] que podem ser aproveitadas para integrações com outros sistemas, assim como podem ser consideradas as [https://portal.bgpmon.net/bgpmonapi.php APIs do BGPmon da Cisco], [https://api.qrator.net/ APIs da QRATOR], etc. <br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Algumas soluções para o gerenciamento da segurança e instabilidades do roteamento BGP <br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de recebimento de anúncios de ASNs vizinhos'''<br /> | rowspan=&quot;5&quot; |<br /> * [https://www.thousandeyes.com/solutions/bgp-and-route-monitoring ThousandEyes]<br /> * [https://bgpmon.net/ BGPmon by Cisco]<br /> * [https://www.snas.io/ Streaming Network Analytics System (SNAS)]<br /> * [http://pnda.io/ Platform for Network Data Analytics (PNDA)]<br /> * [https://bgpstream.caida.org/ BGPStream]<br /> * [https://share.zabbix.com/search?searchword=BGP&amp;search_cat=1 Zabbix com plugins compatíveis com estas necessidades]<br /> |-<br /> |'''Controle de abuso de AS-Path Prepending'''<br /> |-<br /> |'''Detecção de oscilações de sessões BGP'''<br /> |-<br /> |'''Detecção de oscilações de rotas (route flaps)'''<br /> |-<br /> |'''Detecção de rotas eventualmente suprimidas por Dampening'''<br /> |}<br /> Entendo que as ferramentas indicadas na tabela acima forneçam as funcionalidades devidas para que o administrador do Sistema Autônomo possua meios de identificar e reagir contra uma diversidade de situações envolvendo sessões e anúncios do protocolo BGP. <br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento engenharia de tráfego e planejamento de capacidades<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento'''<br /> | rowspan=&quot;7&quot; |<br /> * [https://www.telcomanager.com/trafip-analise-de-trafego/ TRAFip]<br /> * [https://www.noction.com/intelligent-routing-platform-bgp-network-optimization Noction IRP]<br /> * [https://www.blueplanet.com/products/route-optimization.html Ciena BluePlanet ROA]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/crosswork-network-automation/datasheet-c78-740228.html Cisco Crosswork Network Insights]<br /> * [https://www.manageengine.com/products/netflow/ ManageEngine NetFlow Analyzer]<br /> * [https://developer.cisco.com/docs/wan-automation-engine/#!overview/cisco-wan-automation-engine Cisco WAE em combinação com XTC]<br /> |-<br /> |'''Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas'''<br /> |-<br /> |'''Bilhetagem e tarifação de tráfego'''<br /> |-<br /> |'''Dimensionamento de recursos de transporte e acordos de troca de tráfego'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP'''<br /> |-<br /> |'''Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como BGP-LS, MPLS TE e SR-TE'''<br /> |-<br /> |'''Planejamento e antecipação de cenários &quot;what if&quot;'''<br /> |}<br /> A compreensão dos fluxos de tráfego, tanto na rede do próprio AS quanto nas conexões com os AS vizinhos, é algo muito importante para que o provedor consiga tomar as decisões corretas em algumas esferas técnicas do projeto e da operação cotidiana. Afinal de contas, para que seja possível o dimensionamento correto de recursos que acomodarão seus assinantes e respectivos serviços, o provedor precisa ter as informações necessárias para concluir este planejamento de capacidades, a engenharia de tráfego, e as questões de engenharia de redes tais como a disponibilidade, atrelada aos padrões de redundância, resiliência e métricas de confiabilidade, e em alinhamento com o projeto técnico e o plano de negócios. As ferramentas mencionadas na tabela acima possuem funcionalidades que cumprem bem com estes requisitos.<br /> {| class=&quot;wikitable&quot;<br /> |+Gerenciamento da segurança do plano de controle da rede e segurança contra negação de serviços<br /> !Requisito<br /> !Exemplos de ferramentas e soluções possíveis ou candidatas<br /> |-<br /> |'''Controle de vulnerabilidades sobre as mensagens do BGP'''<br /> | rowspan=&quot;4&quot; |<br /> * Ferramentas e soluções de detecção e prevenção de intrusão<br /> * [https://www.andrisoft.com/software/wanguard Andrisoft Wanguard]<br /> * [https://www.kentik.com/solutions/network-monitoring-and-analytics-for-service-providers/ Kentik for Service Providers]<br /> * [https://br.netscout.com/arbor-ddos Arbor para Operadoras]<br /> * [https://wiki.brasilpeeringforum.org/w/UTRS_Registro_e_Configuracao Team Cymru UTRS]<br /> |-<br /> |'''Controle de incidentes de segurança lançados diretamente contra as sessões BGP'''<br /> |-<br /> |'''Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS'''<br /> |-<br /> |'''Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces'''<br /> |}<br /> Tão importante quanto disponibilidade, performance e visibilidade geral dos componentes associados ao funcionamento do BGP em um Sistema Autônomo, é o gerenciamento da segurança da infraestrutura como um todo, sendo que, neste caso, as questões mais diretamente ao roteamento do AS. Na questão de segurança &quot;geral&quot; do AS, muita coisa já foi discutida em outros artigos já publicados na Wiki do Brasil Peering Forum, tais como o [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] e [[Boas Praticas para Melhorar a Seguranca de seu Provedor|Boas Práticas para Melhorar a Segurança de seu Provedor]]. As soluções mencionadas na tabela acima são indicadas para a mitigação de incidentes de segurança e ataques DDoS lançados contra a rede do ISP e/ou de seu cone de clientes.<br /> <br /> === Modelos e ferramentas orientadas ao gerenciamento do BGP ===<br /> Saindo um pouco desse discurso de &quot;necessidades, requisitos, desafios, etc,&quot;, serão discutidas a seguir as possibilidades em termos de modelos e ferramentas de gerenciamento que podem ser consideradas e utilizadas para os nossos interesses com o BGP. Pois, afinal de contas, não adianta vislumbrar um mundo perfeito ao melhor estilo &quot;''imagine all the people...''&quot; se não há formas efetivas de executarmos aquilo que nós desejamos, certo? Isto significa que temos que por os pés no chão e analisarmos as possibilidades nada utópicas! Se dependesse de nossas mentes altamente criativas, conseguiríamos, num estalar de dedos, fazer tudo funcionar da maneira como as nossas brilhantes mentes sonham, e ter acesso a todo o tipo de informações e analíticos que, na prática, sequer sabemos se existem ou se podem ser recuperadas dos elementos de nossa rede. <br /> <br /> E, antes de discutirmos quais tipos de informações/dados podemos obter em nosso ambiente e determinarmos o que podemos fazer com estas informações, tentemos em um primeiro momento compreendermos os protocolos, serviços e procedimentos que podem ser utilizados para recuperarmos informações dos equipamentos e sistemas de nossa infraestrutura.<br /> <br /> ==== Modelo &quot;pull&quot; tradicional de recuperação de dados ====<br /> O modelo ''pull'' de recuperação de dados consiste no envolvimento de procedimentos onde estações de gerenciamento acessam os dispositivos para a obtenção de informações acerca de um ou mais objetos gerenciados. Os exemplos de procedimentos mais comuns são as consultas executadas com protocolos tais como ''Simple Network Management Protocol'' (SNMP), ''Remote Monitoring'' (RMON), ''Secure Shell'' (SSH) e ''Telnet''. <br /> <br /> Como o próprio termo sugere (''pull''), os sistemas de gerenciamento requisitam informações para os equipamentos da rede através de mecanismos de solicitação e resposta, como é o caso das mensagens ''GetRequest'', ''GetBulkRequest'' e ''GetBulkRequest'', do SNMP, sobre algum objeto gerenciado (''Object Identifier'' (OID)), devidamente especificado em uma biblioteca ''Management Information Base'' (MIB) apropriada, a qual deverá ser suportada por ambos o equipamento (ex: roteador) e o sistema da estação de gerenciamento em questão, sendo que as respostas para estas requisições são fornecidas por meios de mensagens ''Response'' deste protocolo.<br /> <br /> Outra possibilidade envolveria scripts devidamente organizados ou acomodados em estações de gerenciamento que executem conexões diretas com o interpretador de linha de comando (CLI) dos equipamentos da rede e execute operações com comandos específicos de interesse do administrador, tais como a obtenção de contadores de uma interface (&quot;''show interfaces''&quot;) para a checagem por eventuais problemas, ou a verificação de status das sessões BGP do roteador (&quot;''show bgp summary''&quot; e &quot;''show bgp neighbor''&quot;), a contabilização da quantidade de rotas anunciadas para determinado vizinho BGP (&quot;''show route advertising-protocol bgp x.x.x.x''&quot; no JUNOS, &quot;''show bgp neighbor x.x.x.x advertised-routes''&quot; no Cisco IOS XR), dentre muitas possibilidades. O &quot;output&quot; de uma operação envolvendo um destes comandos seria então mantido num arquivo temporário para que outros scripts e procedimentos possam ser executados para consumir estes dados e fornecer algum tipo de tratamento e interpretação posterior.<br /> <br /> ==== Modelo &quot;push&quot; tradicional de recuperação de dados ====<br /> O modelo ''push'' de recuperação de dados ocorre no sentido inverso ao modelo ''pull'': os equipamentos da rede encaminham as informações para as estações de gerenciamento, e isto pode ocorrer através de definições periódicas do serviço monitorado para o envio de informações ou baseado em eventos. Exemplos de procedimentos ''push'' incluem as mensagens ''Trap'' do protocolo SNMP onde as mensagens destes &quot;traps&quot; nestes casos acompanhariam duas variáveis primárias, sendo o ''sysUpTime'' e o ''snmpTrapOID'', juntamente com outras instruções para reportar alguma condição que tenha sido detectada sobre o monitoramento estabelecido de um OID, e havendo o reconhecimento por parte do coletor de eventos com o envolvimento da mensagem ''InformRequest-PDU''.<br /> <br /> Outro exemplo de modelo ''push'' seria com o serviço Syslog sobre uma das 24 &quot;''facilities''&quot; (de 0 a 23) especificadas pelo &lt;nowiki&gt;RFC 5424&lt;/nowiki&gt;, sendo algumas de uso reservado para aplicações e serviços específicos, enquanto outras são de uso local (podendo ser destinados praticamente para qualquer finalidade) em combinação com um dos 8 níveis de severidade (0=EMERGENCY, 1=ALERT, 2=CRITICAL, 3=ERROR, 4=WARNING, 5=NOTICE, 6=INFORMATIONAL, 7=DEBUG) para comunicar eventos específicos de acordo com esta combinação de ''Facility'' x ''Severity'' para uma estação coletora de Syslog. Sistemas bastante completos e flexíveis de correlação de eventos podem consumir e processar estas informações para reportar uma gama muito ampla de situações, além de permitir a derivação de métricas e analíticos. O uso de scripts podem ser por ações independentes projetadas pelo administrador, ou ainda como parte integrante de funções existentes de sistemas de gerenciamento propriamente ditos.<br /> <br /> Dentre outras possibilidades envolvendo este modelo ''push'', há as próprias ferramentas embarcadas nos sistemas operacionais / software dos roteadores e switches, dentre os quais recomendo o ''Cisco Embedded Event Manager'' (EEM), ''Junos Event Scripts'', assim como facilidades similares encontradas em plataformas de outros fabricantes, os quais permitem flexibilizar bastante como eventos e outras informações podem ser encaminhadas para outros sistemas residindo em servidores da rede.<br /> <br /> ==== Telemetria orientada a modelos ====<br /> Ou MDT. As ferramentas e procedimentos clássicos empregados nos modelos ''pull'' e ''push'' tradicionais, citados previamente, possuem algumas restrições e limitações, mas isto não significa que protocolos e procedimentos tais como SNMP, shell scripting, recursos de software de roteadores (Cisco EEM, Junos Event Scripts, Huawei OPS, etc.) serão descontinuados ou aposentados tão cedo, muito pelo contrário. Na verdade, a tendência é que sejam encontrados novos propósitos e finalidades para estes protocolos e serviços mais legados, ou ainda dedicando-os para coletas de instruções e operações bem mais específicas, e não tão generalistas como ocorre atualmente na maioria das redes, enquanto novas tecnologias estão ganhando espaço para conquistarmos melhores resultados para as nossas necessidades de gerenciamento de configurações, gerenciamento de performance, gerenciamento de falhas, analíticos, ''big data'' e afins. E é justamente aqui onde entra o conceito de '''''telemetria''''' na sua forma mais ampla e efetiva.<br /> <br /> A telemetria orientada à modelos embarca e combina procedimentos de &quot;''telemetria orientada a eventos''&quot; e, principalmente, como destaque, a &quot;''telemetria de streaming periódica''&quot;, para proporcionar os melhores resultados, e não apenas nas ações técnicas e operacionais que competem aos centros de gerência de redes, tais como gerenciamento FCAPS no geral, mas, principalmente, em termos de ''big data'', analíticos e afins, sendo o principal diferencial entre esta modalidade e os modelos tradicionais de gerenciamento no geral.<br /> <br /> A principal diferença entre as duas abordagens, a &quot;tradicional&quot; e a &quot;telemetria&quot;, é que o modelo tradicional, simplificando aqui, emprega o protocolo SNMP, além de outros procedimentos já citados. Para efeitos comparativos, operações com protocolos tais como o SNMP são executadas com o modelo ''pull'' diretamente sobre os elementos da rede, exceto quando considerando aqui os SNMP Traps, que são muito específicos para alertas e eventos, e que operam por método ''push''. Já na telemetria por streaming periódico os dados são enviados diretamente e em tempo real a partir dos elementos da rede para os coletores e sistemas de gerenciamento, ou seja, conceito &quot;''push''&quot; mesmo, mas com diferenças significativas em termos de capacidade, recursos e disponibilidade de informações, além da própria característica &quot;''tempo real''&quot;. No que diz respeito à telemetria orientada e eventos, um dos maiores exemplos é o recurso ''BGP Monitoring Protocol'' (BMP), que poderá encaminhar eventos praticamente em tempo real acerca da operação do protocolo BGP no seu ASN. Os ganhos e benefícios disto tudo serão discutidos posteriormente neste artigo.<br /> <br /> A ilustração a seguir exemplifica as diferenças e principais componentes empregados em cada um dos casos citados aqui:<br /> [[Arquivo:Bpf-gerbgp-comparativosger.jpg|centro|miniaturadaimagem|907x907px|Comparativos entre os modelos de gerenciamento factíveis para o BGP]]<br /> <br /> ==== Comparativos entre os diversos tipos de tecnologias (protocolos e serviços), suas capacidades, finalidades e propósitos, e suas respectivas categorizações ====<br /> A tabela a seguir certamente será muito útil para concentrarmos muitas informações importantes e bem relevantes para dissertarmos sobre os aspectos e possibilidades quanto ao gerenciamento do BGP.<br /> {| class=&quot;wikitable&quot;<br /> |+Tabela comparativa entre diversos tipos de protocolos e serviços, suas capacidades, finalidades e propósitos<br /> !Ferramenta<br /> <br /> (Protocolo e/ou Serviço)<br /> !Alguns exemplos de situações em que pode ser empregada<br /> |-<br /> |'''SNMP (operações &quot;Get&quot;)'''<br /> |Operações de recuperação e amostragem de informações obtidas por meios de operações &quot;get&quot; do SNMP.<br /> * Consultas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Identificação de propriedades de sessões BGP (ex: temporizadores) e capacidades suportadas<br /> * Identificação da quantidade de rotas aceitas de uma sessão BGP<br /> * Identificação da quantidade de rotas recusadas de uma sessão BGP<br /> * Identificação da quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Identificação de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> * Recuperação da tabela de roteamento (Ex: 1.3.6.1.2.1.4.21 - ipRouteTable)<br /> |-<br /> |'''SNMP Traps'''<br /> |Alertas que poderão ser recebidos por sistemas de gerenciamento com suporte às MIBs necessárias.<br /> * Alertas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP<br /> * Alertas de quantidade de rotas recebidas de uma sessão BGP<br /> * Alertas de quantidade de mensagens Update recebidas de uma sessão BGP<br /> * Alertas de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP<br /> |-<br /> |'''RMON'''<br /> |O RMON tem pouca ou nenhuma utilidade específica para os interesses de gerenciamento do BGP, mas suas capacidades e recursos poderão ser obtidas e combinadas para agregar valor ao propósito de gerenciamento como um todo.<br /> * Estatísticas em tempo real de utilização dos segmentos Ethernet envolvidos no transporte de sessões BGP (utilização, erros, colisões)<br /> * Fornecer histórico de estatísticas selecionadas, e com suporte ao uso de variáveis especificadas pelo usuário.<br /> <br /> * Encaminhamento de alarmes para RMON SNMP traps quando houver o cruzamento de determinados thresholds pré-definidos, inclusive com suporte a grupos de alarmes.<br /> * Monitoramento de hosts, tais como a quantidade de bytes e frames enviados e recebidos de vizinhos BGP.<br /> * Ordenamento de &quot;top hosts&quot; com coleta e manutenção de dados referentes a conexões ativas por um determinado período de tempo.<br /> * Matriz de tráfego entre dois roteadores envolvidos numa sessão BGP.<br /> * Filtragem de dados com base em padrões de interesse do administrador, tais como endereços MAC, e portas de protocolos de transporte.Captura de pacotes para análise posterior em depuradores.<br /> * Descoberta e estatísticas por protocolo.<br /> * Mapeamento entre endereços MAC e endereços IP referentes as sessões BGP<br /> * Estatísticas de tráfego L3 com ordenamento por host ou par de conversação (origem/destino), como complemento ao monitoramento do BGP.<br /> * Estatísticas de tráfego L7 por protocolo de aplicação e por host, como complemento ao monitoramento do BGP.<br /> |-<br /> |'''Syslog'''<br /> |Alertas que poderão ser recebidos por servidores syslog &quot;crus&quot; ou uma solução específica para correlação de eventos e processamento de analíticos.<br /> * Alertas de esgotamento de recursos de memória para algum processo ou ação do BGP<br /> * Alertas de problemas com a instalação de rotas BGP devido a inconsistências ou atributos inválidos<br /> * Alertas de falhas de semântica de políticas (route-map, route-policy, etc.) vinculadas a sessões BGP<br /> * Alertas de falhas nas estruturas internas dos processos BGP<br /> * Alertas de problemas de processamento de ações sobre atributos (ex: remoção de AS_PATH, modificação de NEXT_HOP)<br /> * Alertas de recebimento de prefixos inválidos (ex: Martians)<br /> |-<br /> |'''Shell scripting para invocação de CLI'''<br /> |Recuperação de qualquer informação possível por comandos na CLI do roteador.<br /> * Verificação do status de todas as vizinhanças BGP<br /> * Verificação detalhada de uma vizinhança BGP específica<br /> * Contadores de prefixos anunciados e recebidos por vizinho BGP<br /> * Detalhamento das rotas BGP anunciadas para um determinado vizinho BGP<br /> * Detalhamento das rotas BGP recebidas de um determinado vizinho<br /> * Consultas sobre a tabela BGP integral<br /> * Consultas sobre a tabela BGP com parâmetros de refinamento (expressão regular/regex, community, next-hop, policy...)<br /> * Consultas sobre a tabela BGP de rotas não filtradas (pré-policy) de um determinado vizinho (soft-reconfig inbound)<br /> |-<br /> |'''Cisco EEM'''<br /> |Componente do software de roteadores da Cisco, permitindo que você automatize tarefas, execute modificações e ajustes sobre diversos componentes lógicos, e crie ações alternativas. Dentre muitas possibilidades, e focando aqui no BGP, é possível:<br /> * Monitorar o estado operacional ou funcionamento de determinados protocolos e serviços e tomar ações automaticamente em função de algum evento pré-definido por você.<br /> * Implementar uma rotina de verificação de oscilação de sessões BGP, as quais, atingindo um determinado &quot;''threshold''&quot;, poderá invocar uma ação de notificação por Syslog, SNMP, Email (que poderá ser uma máscara de WhatsApp ou Telegram).<br /> * Em adição ao conceito acima, executar uma ação que poderá incluir a modificação de uma route policy para consequente redução do atributo LOCAL_PREF implementado sobre as rotas recebidas de um peer que está oscilando.<br /> * Em adição ao conceito acima, executar uma ação que poderá decidir por desabilitar administrativamente aquela sessão por um determinado período de tempo ou até que haja garantias de que a sessão esteja estável por &quot;x&quot; horas.<br /> * Implementar uma rotina de detecção de existência ou ausência de uma determinada rota BGP na tabela de roteamento (RIB), permitindo uma ação desejada que poderia incluir o estabelecimento de um túnel GRE ou TE, o &quot;shutdown&quot; ou &quot;no shutdown&quot; de uma interface, uma mudança de policy, etc.<br /> * Implementar uma rotina que vá coletar informações (tabela BGP, NLRIs com determinados atributos (ex: communities), rotas BGP da RIB, sessões, etc.) em intervalos periódicos, escrevendo os ''outputs''/dados em um arquivo em um servidor FTP.<br /> * &quot;Quem tem limites é município&quot;. O limite é virtualmente a capacidade criativa do administrador da rede; a sua imaginação. Experimente!<br /> |-<br /> |'''Juniper Event Scripts'''<br /> |Componente embarcado no sistema operacional JUNOS dos roteadores da Juniper Networks e com proposta similar ao Cisco EEM.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o Juniper Event Scripts propõe-se a fazer aquilo que o Cisco EEM faz, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas duas ferramentas.<br /> |-<br /> |'''Huawei Open Programmability System (OPS)'''<br /> |Componente embarcado no sistema operacional dos roteadores da Huawei e com proposta similar ao Cisco EEM e ao Juniper Event Scripts.<br /> Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o OPS propõe-se a fazer aquilo que o Cisco EEM e o Juniper Event Scripts fazem, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas três ferramentas.<br /> |-<br /> |'''OpenConfig, NETCONF, RESTCONF, gNMI, gRPC, e modelos YANG'''<br /> |O OpenConfig, padrão aberto para o desenvolvimento de interfaces programáticas, viabiliza um gerenciamento mais dinâmico das infraestruturas (ex: telemetria) utilizando como transporte os protocolos e procedimentos NETCONF, RESTCONF, gNMI ou gRPC, em combinação com repositórios de dados modelados pelo YANG, para proporcionar um novo universo de possibilidades em termos de gerenciamento.<br /> <br /> Uma de suas principais aplicabilidades envolve o chamado ''Model-Driven Telemetry'' ou MDT. Quando pensando em gerenciamento por este modelo de telemetria, as possibilidades chegam a surpreender, pois a entrada de dados por ser feita pelos protocolos supracitados, ou ainda por JSON, Kafka, Google Protocol Buffer (GPB), Google RPC (GRPC), dentre outros, a lista é interessante.<br /> <br /> Já a saída de dados poderá ser feita para Kafka, Prometheus, InfluxDB, JSON, XML, e outros, pois a lista é igualmente interessante, o que abre um leque realmente surpreendente de situações e possibilidades. Nunca as redes foram tanto &quot;''software-defined''&quot;: o MDT é um divisor de águas! <br /> * Modelagem e streaming periódico/contínuo de dados para a representação das rotas BGP da RIB com suporte a 5 RIBs lógicas por família de endereços.<br /> * Provimento de definições de dados para tabelas BGP, tipos, identidades, especificações, atributos, e afins, para o gerenciamento efetivo do BGP por OpenConfig.<br /> * Gerenciamento, automação e orquestração de sessões e políticas de roteamento.<br /> * Streaming contínuo de indicadores de performance do BGP, incluindo FSM das sessões, quantidade de sessões, quantidade de rotas total e aceitas/recusadas por neighbor, etc.<br /> * Streaming contínuo de indicadores de anomalias associadas ao BGP.<br /> |-<br /> |'''NetFlow / JFlow / sFlow'''<br /> |O emprego destas tecnologias correlacionam os registros dos fluxos de tráfego juntamente com as informações de roteamento BGP para que seja possível visualizar as conversações para a extração de diversos analíticos importantes.<br /> * Monitoramento em tempo real de registros de fluxos de conversações juntamente com as indicações de Sistemas Autônomos envolvidos.<br /> * Identificação através de pesquisas customizadas sobre fluxos de tráfego por origem, destino, par origem-destino, protocolo de transporte, marcação de QoS, Sistema Autônomo BGP, etc.<br /> * Identificação dos &quot;''top talkers''&quot; por uma variedade de critérios de consulta.<br /> |-<br /> |'''BGP Link-State (BGP-LS)'''<br /> |O BGP Link-State (LS) é uma extensão do protocolo BGP fornecida por meios de um ''Address Family Identifier'' (AFI) e ''Sub-address Family Identifier'' (SAFI) para transportar o ''Link-State Database'' (LSDB) de protocolos IGP (OSPF e IS-IS) através do BGP. <br /> <br /> O BGP-LS permite uma série de aplicações, desde o fornecimento de informações topológicas detalhadas da rede para servidores específicos orientados à otimização de tráfego de rede na camada de Aplicação (ALTO), suporte a Path Computation Element (PCE) para engenharia de tráfego, e outros.<br /> <br /> No que diz respeito ao monitoramento do BGP, o BGP-LS poderá atuar como um componente adicional para agregar mais informações em diversas bases e sistemas onde os dados específicos de BGP são coletados, mantidos, processados, e representados.<br /> * Fornecimento de informações topológicas detalhadas da rede.<br /> * Combinação e correlação dos dados topológicos com estruturas de dados fornecidas por outros meios de gerenciamento centrados na otimização e visibilidade do BGP, tais como sFlow/JFlow/NetFlow, BMP, CLI, e SNMP.<br /> * Visibilidade, correlação de eventos, aprimorar ações de planejamento de capacidades e de engenharia de tráfego, e detecção de incidentes de segurança.<br /> |-<br /> |'''BGP Monitoring Protocol (BMP)'''<br /> |Acesso de sistemas de gerenciamento ao Adj-RIB-In de peers BGP para o recebimento periódico de estatísticas do protocolo.<br /> * Recebimento periódico de estatísticas que possam ser usadas para monitorar as atividades específicas do BGP.<br /> * Recebimento de notificações acerca do estado operacional das sessões BGP.<br /> * Recebimento das tabelas BGP pré-policy, ou seja, antes que o roteador implemente os filtros de import/export sobre as rotas.<br /> * Recebimento das tabelas BGP pós-policy, ou seja, após o roteador ter filtrado e filtrado atributos associados às rotas.<br /> * Em combinação com validadores de IRR, poderá detectar route leaks gerados ou recebidos pelo AS local.<br /> * Em combinação com validadores de RPKI, poderá detectar violações de ASN de origem associados às rotas recebidas ou enviadas.<br /> * Poderá ser combinado para fornecer funcionalidade de Looking Glass.<br /> * Fornecimento de visibilidade histórica envolvendo estado de sessões.<br /> * Fornecimento de visibilidade e histórico de prefixos com refinamento por &quot;peer&quot;, &quot;ASN&quot; e &quot;prefixo&quot;.<br /> * Permite estudar através de uma linha temporal todos os anúncios e recebimentos realizados, incluindo rotas aceitas e recusadas.<br /> * Permite estudar através de uma linha temporal todas as modificações de atributos executadas sobre rotas aceitas.<br /> |}<br /> Como não dá para abordar tudo em um artigo - talvez outros artigos sobre o tema sejam disponibilizados na Wiki do BPF - procurarei demonstrar algumas coisas que podem ser feitas com algumas das ferramentas/opções listadas na tabela acima. Que tal focarmos em dois componentes aqui? SNMP e BMP. <br /> <br /> === Monitoramento do BGP com o Simple Network Management Protocol (SNMP) ===<br /> O monitoramento de infraestruturas de redes por SNMP não é novidade alguma para os profissionais da área, muito pelo contrário. E, no que diz respeito ao monitoramento do BGP, o SNMP tem sido amplamente utilizado por muitas empresas para cumprir com diversas das necessidades e desafios comentados previamente. Por ser algo um tanto difundido, talvez o único método de gerenciamento/monitoramento propriamente dito adotado por ISPs regionais de pequeno e médio portes, não desprenderei muito tempo nesta seção do artigo.<br /> <br /> Diversas plataformas baseadas em software podem ser utilizadas para monitorar o BGP, dentre os quais destaco os seguintes:<br /> * [https://www.zabbix.com/ Zabbix]<br /> * [https://www.librenms.org/ LibreNMS]<br /> * [https://www.observium.org/ Observium]<br /> * [https://www.nagios.com/ Nagios]<br /> * [https://www.cacti.net/ Cacti]<br /> * [https://www.opennms.com/ OpenNMS]<br /> * [https://www.solarwinds.com/pt/ Solarwinds]<br /> * [https://www.paessler.com/prtg PRTG]<br /> * Integrações de boa parte destas soluções com o [https://grafana.com/ Grafana] para a geração de dashboards<br /> * Soluções comercias de fabricantes tais como Cisco, Juniper e outros<br /> Está fora do escopo deste artigo tecer quaisquer comparativos (&quot;''qual é o melhor?''&quot;, etc.) dentre estas soluções.<br /> <br /> Independentemente de qual abordagem/solução seja escolhida por você para atender as suas necessidades, o fato é que você terá que assegurar o devido suporte a alguns componentes específicos para o monitoramento do BGP, em particular a '''''BGP4-MIB''''', conforme descrita no RFC 4273 (''Definitions of Managed Objects for BGP-4'') e RFC 4275 (''BGP-4 MIB Implementation Survey''). Você deverá considerar também eventuais MIBs que implementem OIDs proprietários de acordo com o fabricante do equipamento que você necessitar monitorar pela sua gerência SNMP, por exemplo a [https://www.juniper.net/documentation/en_US/junos/topics/reference/mibs/mib-jnx-bgpmib2.txt '''''Juniper-BGP-MIB'''''] e [https://mibs.cloudapps.cisco.com/ITDIT/MIBS/MainServlet?ReleaseSel=4669&amp;PlatformSel=269&amp;fsSel=348 '''''Cisco-BGP-MIBv2'''''] , e certificar-se que seus sistemas de gerenciamento (ex: Zabbix) implementem funções para operações de consulta sobre os OIDs desejados com estas MIBs. Além destas MIBs, muitos destes sistemas possuem plugins prontos para o monitoramento do BGP em condições diversas, por exemplo:<br /> * Zabbix<br /> ** [https://share.zabbix.com/network_devices/cisco/cisco-bgp-ipv4-ipv6-32-bit-asn Cisco BGP IPv4/IPv6 32-bit ASN]<br /> ** [https://share.zabbix.com/network_devices/juniper/juniper-mx-discovery-int-re-bgp4-ipv4-and-ipv6 Template SNMP Juniper MX discovery: int, RE, BGP4 ipv4 and ipv6]<br /> ** [https://share.zabbix.com/network_devices/mikrotik/zabbix-routeros-bgp-monitoring Zabbix RouterOS BGP Monitoring]<br /> * LibreNMS<br /> ** [https://docs.librenms.org/API/Routing/ Monitoramento de sessões BGP] e [https://docs.librenms.org/Alerting/Entities/ Entities]<br /> * Observium<br /> ** [https://docs.observium.org/config_options/ Monitoramento de sessões BGP]<br /> * Nagios<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check-BGP-neighbor-JunOS/details Check BGP Neighbor JunOS]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp/details check_bgp]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_counters/details check_bgp_counters]<br /> ** [https://exchange.nagios.org/directory/Plugins/Network-Protocols/BGP-2D4/check_bgp_v4_v6/details check_bgp_v4_v6]<br /> * Grafana<br /> ** [https://grafana.com/grafana/plugins/alexanderzobnin-zabbix-app Plugin para Zabbix]<br /> ** [https://grafana.com/grafana/plugins?orderBy=weight&amp;direction=asc Plugins para diversas finalidades e integrações]<br /> ** [https://grafana.com/grafana/dashboards?dataSource=alexanderzobnin-zabbix-datasource&amp;orderBy=name&amp;direction=asc Dashboards &quot;prontos&quot;]<br /> * Outros! basta pesquisar pelos recursos desejados junto à documentação do seu sistema de gerenciamento, entrar em contato com o suporte de desenvolvimento, contratar uma consultoria especializada, etc.<br /> O funcionamento do monitoramento do BGP por SNMP não é complexo, pois é um procedimento um tanto difundido entre os operadores de redes. As estações de gerenciamento são configuradas para executar consultas periódicas sobre os roteadores monitorados usando operações &quot;''Get''&quot; sobre os ''Object Identifiers'' (OID) desejados, os quais precisam ser especificados numa MIB apropriada (ex: BGP4-MIB), e cujo o suporte a esta MIB deverá existir tanto no roteador monitorado quanto no software em execução na estação de gerenciamento. O SNMP funciona neste caso como um mecanismo de solicitação e resposta, e as informações recuperadas por meios deste mecanismo são armazenadas nas bases de dados que acompanham estas soluções, e devidamente processadas para reportar alguma coisa em alguma função do sistema. Em adição, é possível consultar estes dados via integrações com outros sistemas (ex: Grafana) para finalidades de representação melhor elaboradas, como painéis/dashboards e afins. Por exemplo:<br /> [[Arquivo:Bpf-gerbgp-snmp.jpg|centro|miniaturadaimagem|900x900px|Exemplo de monitoramento do BGP por procedimento SNMP]]<br /> É importante frisar também que o gerenciamento do BGP para a questão de incidentes tais como oscilações de sessões (ou &quot;''flapping''&quot;) pode ser tratada por intermédio de mensagens ''SNMP trap''. O sistema de gerenciamento (chamamos aqui de software &quot;NMS&quot;), ao receber o evento por SNMP trap, buscará processar a informação de acordo com as diretivas que estiverem definidas para o elemento de rede gerenciado, permitindo destacar o evento da falha de forma visível nos painéis correspondentes oferecidos pelo software NMS. Apesar de isto não ser novidade alguma, acho que não custa nada deixar isto esclarecido para a eventualidade deste artigo ser consultado por indivíduos mais leigos.<br /> [[Arquivo:Bpf-gerbgp-snmptrap.jpg|centro|miniaturadaimagem|900x900px|SNMP traps para a funcionalidade de notificações e alertas do gerenciamento de falhas]]<br /> <br /> Nas mãos de profissionais caprichados, é possível construir painéis bastante interessantes com soluções relativamente simples, mas não menos interessantes, intuitivas ou funcionais, baseadas no SNMP, em especial quando envolvendo o Grafana para a produção destes painéis. Alguns casos de uso do Zabbix + Grafana para o monitoramento do BGP serão demonstrados aqui, sendo que, em alguns cenários, além do SNMP, outros procedimentos podem ser envolvidos para a recuperação e representação das informações desejadas para cada painel.<br /> <br /> No painel demonstrado a seguir, idealizado pelo Caio Ribeiro da [https://www.facebook.com/flowbix Flowbix], foi possível concentrar muita informação útil/relevante numa única tela: desde status das sessões BGP com seus respectivos ''uptimes'', total de prefixos IPv4 com indicadores de RIB e FIB, estado dos módulos ópticos do equipamento roteador BGP monitorado, a estatísticas de consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio1.jpg|centro|miniaturadaimagem|1280x1280px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também idealizado pela Flowbix, outra consolidação de dados importantes numa única tela, incluindo latência, índice de perda de pacotes, disponibilidade, uso de recursos tais como CPU, memória e espaço em disco, estado geral das sessões BGP monitoradas, e consumo de banda por porta/interface.<br /> [[Arquivo:Bpf-gerbgp-caio2.jpg|centro|miniaturadaimagem|967x967px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Neste outro painel, também elaborado pela Flowbix, temos estatísticas mais centradas no estado das sessões BGP, e em combinação com uma visão geral dos índices de latência registrados.<br /> [[Arquivo:Bpf-gerbgp-caio3.jpg|centro|miniaturadaimagem|900x900px|Exemplo de painel de monitoramento BGP (Fonte: Flowbix)]]<br /> Realmente, os limites em termos de construção de painéis para objetos gerenciados por SNMP com uma combinação NMS (ex: Zabbix) + Grafana, além de outros possíveis procedimentos, são um tanto amplos. Muita coisa de fato pode ser feita, desde que você possua os conhecimentos necessários para desenvolver estas integrações. Ou, então, por que você não investe em serviços de integração para o seu negócio?<br /> <br /> === Monitoramento por meios do BGP Monitoring Protocol (BMP) ===<br /> Muitos profissionais da área, incluindo engenheiros que atuam nas principais empresas de Internet do mundo, fabricantes e pesquisadores, chegaram a conclusão que era realmente necessário que tivessem acesso ao conteúdo das rotas mantidas nas tabelas BGP de roteadores, assim como uma visão do conteúdo das mensagens Update empregadas na troca de rotas entre sessões BGP. O grande desafio, porém, é que os modelos tradicionais de gerenciamento (ex: SNMP) praticamente inviabilizam o cumprimento de ações que fornecessem estas informações. Surgiu então o '''''BGP Monitoring Protocol''''', especificado originalmente no &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; (''BGP Monitoring Protocol (BMP)'') e complementado pelo &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)'').<br /> <br /> O BMP fornece meios de acesso ao ''Adj-RIB-In'' de uma sessão BGP de uma forma contínua em adição a um despejo periódico de dados estatísticos para uma estação coletora, devidamente equipada com software específico, para que os engenheiros do Sistema Autônomo possam analisar o funcionamento e o comportamento do BGP.<br /> <br /> Antes mesmo de você conhecer os benefícios do monitoramento do BGP com o protocolo BMP, você precisa saber identificar alguns componentes e conceitos fundamentais <br /> * '''''Adj-RIB-In''''': conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt; (''A Border Gateway Protocol 4 (BGP-4)''), o ''Adj-RIBs-In'' contém as informações de roteamento ainda não processadas que foram anunciadas pelo roteador BGP para seus vizinhos. É conhecido também pelo termo &quot;''pre-policy Adj-RIBs-In''&quot;. Na perspectiva do BMP, o ''Adj-RIB-In'' representa todas as rotas que foram recebidas pelo coletor antes destas informações terem sido processadas por uma policy inbound.<br /> * '''''Post-Policy Adj-RIBs-In''''': é o resultado de aplicação da política de roteamento inbound (ou &quot;import&quot;, como é conhecido em algumas plataformas), mas antes de ter ocorrido o processo de seleção de caminhos (best-path) do BGP para a composição da tabela de roteamento local. Na perspectiva do BMP, o ''post-policy Adj-RIB-In'' representa as informações que foram recebidas pelo coletor após a aplicação de policies inbound ou modificações de quaisquer atributos.<br /> Ou seja, a diferença entre ''pre-policy Adj-RIB-In'' e ''post-policy Adj-RIB-In'' é que, no primeiro caso, não houve a aplicação de quaisquer filtros sobre as rotas recebidas antes que estas informações fossem exportadas para o coletor BMP. E, no post-policy, as informações são encaminhadas para o coletor BMP após o roteador ter &quot;filtrado&quot; (e, potencialmente, modificado atributos) por meios de policies inbound, mas antes do roteador ter conduzido o processo de seleção de ''best path'' para posterior composição da RIB local referente a estas rotas BGP. O monitoramento de updates recebidos de um roteador antes da aplicação de policies inbound tem sido provavelmente a aplicação mais frequente envolvendo o BMP, enquanto o post-policy está mais centrado nas questões relacionadas à auditoria e validação das políticas de roteamento implementadas pela empresa.<br /> <br /> No entanto, o monitoramento apenas do ''Adj-RIB-In'' impõe uma restrição sobre quais dados estariam disponíveis ou acessíveis para os coletores BMP. Como a maioria dos Sistemas Autônomos não possui qualquer implementação de BMP e, quando possuem, não disponibilizam estas informações para terceiros (ex: acesso leitura-apenas ao painel da estação coletora BMP), a sua empresa fica sem visibilidade sobre de fato o que foi anunciado e aceito para os peers de ASs vizinhos. Tudo bem que a consulta destas informações por Looking Glass (que não são baseados em BMP) até permite que você consiga de fato ver se um determinado anúncio encontra-se presente nas tabelas BGP do AS vizinho, mas, no entanto, sem quaisquer dados históricos e facilidades deste tipo, os quais estariam disponíveis com o BMP, ou na alçada deste. E é justamente aí que entra outra proposta, que é o &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; (''Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)''). Este RFC introduz alguns argumentos e facilidades adicionais para o BMP, dentre os quais:<br /> * '''''Adj-RIB-Out:''''' conforme definido pelo &lt;nowiki&gt;RFC 4271&lt;/nowiki&gt;, o ''Adj-RIB-Out'' contém as rotas designadas para anúncios para os peers BGP por intermédio das mensagens UPDATE.<br /> * '''''Pre-policy Adj-RIB-Out''''': é o resultado de representação dos prefixos que serão anunciados pelas mensagens UPDATE antes da aplicação de policies outbound (ou &quot;export&quot;). Geralmente é a mesma coisa que encontra-se no momento na RIB local do roteador.<br /> * '''''Post-policy Adj-RIB-Out:''''' é o resultado do envio de prefixos através de anúncios (UPDATE) após o processamento das informações pelas policies outbound. É a representação do que de fato está sendo anunciado para um peer BGP específico.<br /> O ''BGP Monitoring Protocol'' (BMP) opera sobre uma sessão TCP entre o roteador monitorado e a estação coletora BMP. A configuração da sessão é um tanto flexibilizada, com possibilidade de conexão passiva (iniciada pelo roteador apenas) e mecanismos de backoff de tentativas de conexão com intervalos configuráveis, assim como outros parâmetros para o controle de fluxo de informações entre o roteador e a estação coletora BMP. Nenhuma mensagem BMP é enviada da estação coletora para o roteador, mas nada impede que o administrador da rede configure uma policy inbound para recusar quaisquer anúncios (que sabemos que nunca serão enviados) vindos da estação coletora BMP. Com relação às mensagens empregadas pelo BMP, o &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt; especifica as seguintes:<br /> * '''''Type 0: Route Monitoring (RM)''''': é usado para fornecer um dump inicial de todas as rotas recebidas a partir de um peer, e atua também como um mecanismo contínuo para relatar, de forma incremental, as rotas que são anunciadas e revogadas (''withdrawn)'' por um peer para a estação coletora BMP. A mensagem ''Route Monitoring'' consiste de ''Common Header'' + ''Per-Peer Header'' + mensagem BGP ''UPDATE'' na íntegra.<br /> * '''''Type 1: Statistics Report (SR)''''': fornece um despejo periódico de estatísticas que podem ser utilizadas pelo coletor BMP para relatar as atividades específicas do BGP realizadas pelo roteador. A mensagem ''Stats Reports'' consiste de ''Common Header'' + ''Per-Peer Header'' + um campo de 4 bytes indicando a quantidade de contadores, sendo que cada contador é codificado na forma de um TLV. Stats são informados como ''Counters'' (32-bit) ou ''Gauges'' (64-bit).<br /> * '''''Type 2: Peer Down Notification''''': uma mensagem que é enviada para indicar que uma sessão BGP foi desconectada, fornecendo ainda o motivo para esta desconexão. A mensagem ''Peer Down Notification m''enciona um dos 5 motivos indicativos do encerramento de uma sessão BGP do roteador (''Reason'' 1 a ''Reason'' 5).<br /> * '''''Type 3: Peer Up Notification''''': uma mensagem que informa que uma sessão BGP ficou Up ou &quot;Established&quot;. Esta mensagem inclui informações importantes sobre o que ficou negociado entre os roteadores participantes desta sessão (conteúdo da mensagem OPEN) e também dados referentes à sessão BGP. A mensagem ''Peer Up Notification'' consiste de ''Common Header'' + ''Per-Peer Header'' + a mensagem (BGP) ''OPEN'' enviada + a mensagem ''OPEN'' que foi recebida + informações sobre o peer (opcional)<br /> * '''''Type 4: Initiation Message''''': fornece um mecanismo de indicação para o coletor BMP sobre o roteador BGP, incluindo o fabricante/modelo, versão de software, etc., funcionando como uma espécie de controle de inventário. A mensagem ''Initiation Message'' consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' contendo informações acerca do roteador monitorado, sendo que ''sysDescr'' e ''sysName'' são obrigatórios, enquanto os demais são opcionais.<br /> * '''''Type 5: Termination Message''''': fornece um mecanismo utilizado para informar que a sessão BMP entre o roteador e o coletor BMP foi interrompida. A mensagem ''Termination Message'' consiste de ''Common Header'' + 2 ou mais ''Information TLVs'' descrevendo um dos 5 motivos (''Reason'' 0 a Reason 4) pela ''terminação'' da sessão BMP com o roteador monitorado.<br /> * '''''Type 6: Route Mirroring Message''''': um mecanismo para o roteador monitorado enviar duplicatas literalmente de mensagens conforme são recebidas. Pode ser usado para espelhar exatamente uma sessão BGP monitorada, assim como ser usado para relatar PDUs malformados do protocolo BGP. A mensagem ''Route Mirroring'' consiste de ''Common Header'' + ''Per-Peer Header'' + conjuntos de TLVs que descrevem as mensagens, sendo que 2 bytes informam o código do tipo de mensagem (ex: Type 0 = ''BGP Message'', Type 1 = ''Information'', Type 1 Code 0 = ''Errored PDU'' e Type 1 Code 1 = ''Messages Lost''), 2 bytes o campo de comprimento, e um campo de valor de comprimento variável.<br /> O &lt;nowiki&gt;RFC 8671&lt;/nowiki&gt; por sua vez implementa algumas modificações nas estruturas destas mensagens para acomodar as situações ''Adj-RIB-In'' e ''Adj-RIB-Out'', tais como flag O assinalado para &quot;0&quot; em mensagens BMP com cabeçalho ''per-peer'', e os flags necessários para denotar especificamente ''Adj-RIB-In'' ou ''Adj-RIB-Out'' para as mensagens ''Route Monitoring'' e ''Route Mirroring''.<br /> [[Arquivo:Bpf-gerbgp-bmpheaders.jpg|centro|miniaturadaimagem|900x900px|Cabeçalhos do BMP conforme &lt;nowiki&gt;RFC 7854&lt;/nowiki&gt;]]Acredito que você já esteja entendendo melhor as funcionalidades básicas proporcionadas pelo ''BGP Monitoring Protocol'' (BMP)! Que tal apresentarmos um caso prático envolvendo o monitoramento do BGP por esta tecnologia?<br /> <br /> ==== Caso de uso: monitoramento por BGP Monitoring Protocol (BMP) com o Streaming Network Analytics System (SNAS) ====<br /> O caso apresentado a seguir é uma das diversas possibilidades associadas ao monitoramento do BGP em um Sistema Autônomo com o BMP. Para encurtarmos uma dissertação excessivamente prolongada deste caso, optei por elaborar um simples &quot;canvas&quot; para representar um conceito de solução proposta baseada no ''Streaming Network Analytics System'' (SNAS). O modelo canvas mostrado a seguir tem uma estrutura modificada/customizada para refletir as características gerais do conceito de solução proposto da maneira que eu gostaria de fornecer, ou seja, colocando numa única página, a relação de ''Problemas/Necessidades'', ''Solução'', ''Argumentos de Adoção'', ''Vantagens'', ''Desvantagens'', ''Resultados'', ''Características de Extensibilidade e Integração'' e um ''Bloco Representativo da Solução''. Este arranjo ou customização do modelo canvas deve ser eficiente o bastante para esclarecer esta solução.<br /> [[Arquivo:Bpf-gerbgp-openbmp.jpg|centro|miniaturadaimagem|900x900px|Canvas model do conceito de solução factível com base numa derivação do SNAS para o gerenciamento com o BGP Monitoring Protocol ]]<br /> Apenas para constar, a solução é composta pelos seguintes componentes, cada qual com uma função bastante especifica, e devidamente &quot;empacotados&quot; para implementação em containers com Docker: <br /> * '''openBMP:''' servindo como coletor de BMP. Uma sessão BMP é estabelecida entre este coletor e cada roteador onde desejamos monitorar ou coletar os dados referentes ao BGP.<br /> * '''Apache Kafka:''' o Kafka atua como uma plataforma de processamento de streaming de alta capacidade e baixa latência para o tratamento de dados em tempo real. A presença do Kafka no projeto permite conectar múltiplos ''publishers'' e ''subscribers'' para a disseminação de dados de forma bastante rápida, sendo um ótimo diferencial para as questões de integração e compartilhamento de dados de nossa solução com outros sistemas. Esta instalação inclui ainda o '''''Zookeeper''''', um software também desenvolvido pela Apache e que atua como um serviço centralizado, sendo usado para manter os dados de nomenclatura e configuração e para fornecer sincronização flexível e robusta nos sistemas distribuídos. O ''Zookeeper'' controla o status dos nós do cluster Kafka e também rastreia os tópicos, partições, etc.<br /> * '''PostgreSQL:''' O projeto SNAS original emprega como banco de dados o MySQL/MariaDB, isto tem servido bem aos propósitos por um bom tempo. Todavia, os desenvolvedores entenderam que estava na hora de substituí-lo por um banco de dados mais eficiente em função de algumas das limitações do MariaDB, tais como gerenciamento manual de partições de dados de séries temporais, recuperação de espaço em disco e requerimentos de memória do InnoDB, suporte fraco a JSON, dentre outras. O PostgreSQL resolve estas limitações e ainda adiciona algumas facilidades consideradas interessantes pelos desenvolvedores do SNAS, sendo que o consumidor dos dados implementa todas as APIs de análise do barramento de mensagens via o Kafka. Nesta implementação, o container inclui ainda os seguintes: '''''TimescaleDB''''', '''''RPKI Validator''''', e consultas às bases IRR por procedimento '''''Whois'''''. O ''TimescaleDB'' é um banco de dados de código aberto desenvolvido para tornar o SQL escalável para dados de séries temporais, e é aqui empacotado como uma extensão do PostgreSQL para fornecer o particionamento automático através do tempo e espaço (chave de particionamento). O ''RPKI Validator'', por sua vez, é acionado em rotinas próprias para a verificação do status ROA de cada prefixo mantido na base de dados da solução, enquanto o ''Whois'' é invocado em outras rotinas para a recuperação de informações nas bases IRR.<br /> * '''Grafana:''' o SNAS original possui o seu próprio front end WebUI, obviamente não baseado no Grafana, o qual é compatível somente com a instalação original baseada no MySQL/MariaDB. Esta WebUI não é compatível com o PostgreSQL, tampouco o Grafana, nas novas implementações, é compatível com o MariaDB. Caso você queira reaproveitar esta WebUI original com novas instalações já baseadas no PostgreSQL ao invés do MariaDB, ou utilizar como WebUI o Grafana sobre o MariaDB, ao invés da WebUI original, você realmente terá que &quot;por a mão na massa&quot; e fazer todos os ajustes de códigos necessários, etc. Atualmente existem 12 dashboards &quot;prontos&quot; para atuar especificamente sobre a base de dados desta solução por openBMP/SNAS, mas nada impede que você construa os seus próprios dashboards para atender as suas necessidades mais específicas!<br /> * '''Docker:''' a implementação do SNAS ou de qualquer customização derivada a partir deste não depende exclusivamente do Docker! Você pode montar a solução do zero e do jeito que bem entender. Só vejo que há benefícios associados à separação destas aplicações com a abordagem por containers. Sem contar que, para um setup inicial rápido para fins de conhecer o potencial do SNAS, você poderá clonar uma instalação literalmente pronta e colocá-la para rodar em questão de minutos! Lá na frente você então poderá decidir-se como deverá ser a sua instalação definitiva em ambiente de produção, podendo ser em Docker ou não.<br /> [[Arquivo:Bpf-gerbgp-snasdocker.jpg|centro|miniaturadaimagem|900x900px|Cenário: SNAS em containers Docker]]<br /> Apesar de termos basicamente uma solução &quot;pronta&quot; contendo os componentes acima, é possível conceber diversos tipos de integrações com sistemas desenvolvidos internamente ou com soluções comerciais, os quais, por sua vez, podem consumir os dados fornecidos pelo BMP, seja com streaming nativamente por BMP ou então com acesso direto às informações já armazenadas num banco de dados, sem contar ainda o potencial de distribuição de dados em tempo real via a facilidade introduzida com o Kafka. Os desenvolvedores do SNAS inclusive sugerem este e outros cenários de integração em diversas áreas de sua documentação. Um destes cenários destaco a seguir:<br /> [[Arquivo:Bpf-gerbgp-snas.jpg|centro|miniaturadaimagem|900x900px|Exemplo de cenário de integração do SNAS]]Todavia, a solução que será apresentada a seguir é baseada integralmente (e somente) no SNAS, contemplando duas possibilidades para o banco de dados: instalação original baseada no MariaDB + frontend WebUI do SNAS, e instalação baseada no PostgreSQL e integração com o Grafana, juntamente com os dashboards específicos para os nossos objetivos de monitoramento. Em termos de funcionamento desta integração envolvendo as duas possibilidades em termos de bancos de dados e os frontends WebUI original e Grafana, a ilustração a seguir poderá prover uma elucidação adequada:<br /> [[Arquivo:Bpf-gerbgp-snasio.jpg|centro|miniaturadaimagem|900x900px|Coletor, DB e Frontend do SNAS.io (Fonte: snas.io)]]'''Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos'''<br /> <br /> Um caso real aqui obtido com um ISP que realiza o monitoramento por BMP juntamente com painéis por Grafana. Uma realidade é como o seu Sistema Autônomo (você) enxerga o mundo, e outra coisa é como as demais empresas com presença na Internet enxergam o seu AS (você). Uma facilidade muito interessante de um dos 12 dashboards &quot;prontos&quot; para o SNAS é a capacidade de visualização de qualquer ASN na perspectiva das tabelas BGP do seu ASN (você). Uma vez que o coletor BMP (''openbmp'') recebe/coleta as mensagens vindas dos roteadores monitorados, os dados contidos nestas mensagens são reorganizados e repassados diretamente para o Kafka que as comunica/repassa para a base SQL. Este dashboard do Grafana então realiza consultas sobre as diversas tabelas, constrói e representa as informações que destacam como um determinado ASN - e você pode consultar praticamente qualquer ASN neste dashboard - é visto a partir do ASN da sua empresa (você). O dashboard plotará algumas informações bem relevantes, tais como as relações de upstreams e downstreams do ASN pesquisado, juntamente com a resolução correspondente às bases IRR, incluindo os objetos route/route6 identificados para aquele ASN.<br /> <br /> Esta ferramenta poderá ser muito útil não apenas para você, administrador do AS da sua empresa, mas para que os demais ASs possam ter a liberdade de estudar como são vistos a partir do AS da sua empresa, ou seja, um bom esforço de cooperação para facilitar a vida de outros profissionais/empresas quando estes estiverem diagnosticando eventuais problemas relacionados ao roteamento de/para o seu AS.<br /> [[Arquivo:Bpg-gerbgp-bmpasvniew.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para funcionalidade Looking Glass'''<br /> <br /> Looking Glass não é novidade alguma, muito pelo contrário. Mas me surpreende a quantidade de ASNs que não disponibilizam esta ferramenta, à título de &quot;esforço de cooperação&quot;, para que terceiros (outros profissionais e empresas) possam consultá-lo no intuito de diagnosticar e resolver problemas de roteamento associados aos anúncios por BGP. Inacreditável!<br /> <br /> Embora Looking Glasses sejam bastante úteis e conhecidos, há uma limitação aqui: ao consultar um Looking Glass sobre um determinado prefixo/rota, a resposta será sempre aquilo que estiver constando no momento em que você estiver realizando aquela consulta. Perde-se o tato no que concerne ao que poderia ou pode ter acontecido com relação ao prefixo consultado: &quot;''quantas vezes houve alterações nas propriedades desta rota?''&quot;, &quot;''esta rota estava presente neste LG ontem a noite, quando meus usuários reclamaram problemas de acesso?''&quot;, &quot;''qual é a frequência de oscilações das minhas rotas neste ASN por um determinado upstream?''&quot;, e coisas deste tipo. E é justamente nessas horas que este dashboard com funcionalidade estilo Looking Glass poderá ser extremamente útil.<br /> <br /> Este dashboard, também produzido com o Grafana, permite que você possa pesquisar sobre um prefixo e obter, através de uma linha temporal, todo o histórico de mudanças associadas ao anúncio deste prefixo/rota pesquisado, e isto certamente deverá responder a muitos de seus questionamentos. Infelizmente não é possível fazer pesquisas sobre outras propriedades da rota, tais como pesquisas sobre os atributos, principalmente sobre o AS_PATH. Mas creio que isto seja viável no ponto de vista de implementação, cabendo a você estudar toda a estrutura de dados mantida na base SQL, &quot;acertar&quot; a mão nas ''queries'', e desenvolver o seu próprio dashboard para uma consulta por expressão regular e afins!<br /> [[Arquivo:Bpg-gerbgp-bmplg.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]<br /> [[Arquivo:Bpg-gerbgp-bmplg2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos'''<br /> <br /> Outro dashboard montado com o Grafana que oferece uma utilidade tremenda: a capacidade de consultar o histórico de anúncios originados a partir de um determinado ASN! Na verdade, são 3 dashboards distintos que oferecem visibilidades sobre prefixos com ordenamento &quot;''por prefixo''&quot;, &quot;''por peer''&quot;, &quot;''por ASN''&quot;.<br /> <br /> Este tipo de consulta pode ser muito útil quando desejamos compreender as frequências de alterações nas rotas originadas em um ASN, em particular quando seus usuários estiverem reclamando de problemas de acesso a conteúdos vinculados a estas redes. Isto inclusive poderá ser muito útil para saber quais de seus upstreams diretos são mais &quot;estáveis&quot;, já que alterações frequentes e recorrentes destes anúncios por um determinado peer podem indicar que um dos seus upstreams está passando por alguma dificuldade, por exemplo, ou executando manobras nas políticas de roteamento em um determinado horário, ocasionando em oscilações e instabilidades na convergência do seu BGP.<br /> <br /> As pesquisas podem ser realizadas sobre um destes 3 dashboards designados para esta finalidade, conforme:<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas especificamente a um prefixo qualquer:''''' você poderá usar o dashboard &quot;''Prefix History (by Prefix)''&quot; para visualizar todas as mudanças associadas ao prefixo em questão, tais como a data/hora, tipo de evento (''advertised'', ''withdrawn''), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, o prefixo/rota consultado, o ASN de origem, a lista de AS-Path associada ao prefixo, e as communities associadas a cada prefixo identificado neste período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a quaisquer prefixos originados especificamente em um ASN qualquer:''''' você poderá usar o dashboard &quot;''Prefix History (by ASN)''&quot; para determinar características tais como data/hora, tipo de evento (''advertised'', ''withdrawn''), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, os prefixos/rotas deste ASN identificados neste período, o ASN de origem consultado, a lista de AS-Path associada a cada um dos prefixos identificados neste período, e as communities associadas a cada prefixo identificado neste período.<br /> * '''''Você está interessado em conhecer o histórico de mudanças associadas a eventos referentes a quaisquer prefixos e de quaisquer ASNs, coletados a partir de um roteador monitorado combinado com cada peer:''''' você poderá usar o dashboard &quot;''Prefix History (by Peer)''&quot; para filtrar a origem dos eventos conforme coletados pelos roteadores monitorados pelo coletor BMP, incluindo data/hora, tipo de evento (''advertised'', ''withdrawn''), roteador monitorado, peer externo, prefixo, lista de AS-Path, e communities associadas à cada rota identificada neste período conforme reportado pelo roteador monitorado.<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por ASN]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por Peer]]<br /> [[Arquivo:Bpg-gerbgp-bmppfxhis3.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por prefixo]]'''Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos'''<br /> <br /> Um dashboard mais &quot;cosmético&quot; ou &quot;visual&quot;, mas não menos importante. Com este painel você será capaz de identificar, através de seus gráficos, eventuais anomalias associadas às sessões BGP e de suas respectivas atividades relacionadas a anúncios, tais como volume e frequência de eventos ''advertised'' e ''withdrawn'', anúncios (''advertised'') por roteador, retiradas (''withdrawn'') por roteador, ''Updates'' por peer e ''Withdraws'' por peer.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmptop.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos]]'''Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de de incidentes de segurança como BGP'''<br /> <br /> Conforme comentado anteriormente, o container que oferece o componente '''''openbmp_psql''''' (PostgreSQL) não contém apenas o PostgreSQL: há ainda a presença do ''TimescaleDB'' e de um '''''validador de RPKI'''''. Na medida em que os dados coletados pelo ''openbmp'' são armazenados na base de dados via o interfaceamento com o ''Kafka'', rotinas são executadas em segundo plano para identificar os registros ROA ''Valid'', ''Unknown'' ou ''Invalid'' referentes a cada um dos prefixos mantidos nas diversas tabelas acomodadas pela solução. Este dashboard permite apresentar um &quot;mapa&quot; de quantos ou quais prefixos um ASN possui erros de validação do RPKI. E, em adição, rotinas secundárias são invocadas para a realização de consultas sobre as bases de ''Internet Routing Registry'' (IRR) referentes a estes mesmos prefixos armazenados na base de dados da solução.<br /> <br /> Consequentemente, através deste dashboard por Grafana, você passa a ter condições de identificar potenciais incidentes relacionados a sequestro de prefixos (''hijacks'') e vazamento de rotas (''route leaks'') associados a um ASN específico sobre o qual você poderá realizar esta consulta. Isto poderá ser útil para visualizar problemas em potencial envolvendo os anúncios de prefixos, os quais podem ser recusados tanto pelas políticas de roteamento do seu próprio ASN quanto pelas políticas de roteamento de upstreams, pois, cada vez mais, as empresas tem adotado certo grau de automação na hora de implementar os filtros necessários para o envio e recebimento de anúncios envolvendo seu cone de clientes, ou seja, filtros de rotas que fatoram o estado de validação do RPKI (descarte de ROA inválido) e também o validação por IRR. <br /> <br /> Apesar de não ser &quot;perfeito&quot; e nem 100% garantido, este dashboard pode ser particularmente útil quando estamos interessados em observar o estado geral da segurança do roteamento BGP no que tange à validade dos anúncios por RPKI e IRR, com maior foco na deteção de ''hijacks'' e ''route leaks''.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de Hijacks e Route Leaks]]<br /> [[Arquivo:Bpf-gerbgp-incidents.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento incidentes de segurança do BGP (Fonte: snas.io)]]<br /> <br /> '''Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR'''<br /> <br /> Este painel aproveita grande parte dos componentes citados no painel anterior (validador RPKI e consultas ao IRR) para fornecer uma visualização mais simplificada de quantos prefixos mantidos na base apresentam algum problema de validação RPKI ou IRR.<br /> <br /> [[Arquivo:Bpg-gerbgp-bmpbgpsec2.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR]]'''Caso de uso: monitoramento de sessão BGP por BMP com a WebUI nativa do SNAS.io''' <br /> <br /> O monitoramento por BMP possibilita a extração de algumas informações que atendem a diversas das demandas operacionais do cotidiano do ISP, como, por exemplo, a verificação do estado e demais informações relacionadas às sessões BGP, com resultado parecido com aquele que você obteria com um comando &quot;''show bgp neighbor''&quot; de um roteador.<br /> <br /> [[Arquivo:Bpf-gerbgp-snaspeer info.png|centro|miniaturadaimagem|800x800px|Caso de uso: Peer Info com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: painel Top 20 de prefixos anunciados e removidos com a WebUI nativa do SNAS.io''' <br /> <br /> Com funcionalidade similar ao que foi mostrado no painel AS View com o Grafana, a interface WebUI original do SNAS.io provê uma visibilidade geral do AS numa relação &quot;Top 20&quot;.<br /> [[Arquivo:Bpf-gerbgp-snastop20.png|centro|miniaturadaimagem|800x800px|Caso de uso: Top 20 prefixos anunciados e removidos com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: análise de segurança com a WebUI nativa do SNAS.io''' <br /> <br /> Com visibilidade similar ao que foi demonstrado em alguns painéis anteriores, esta facilidade permite uma rápida visualização acerca da quantidade de ASNs com problemas de validação do RPKI.<br /> [[Arquivo:Bpf-gerbgp-snastsecurity report.png|centro|miniaturadaimagem|800x800px|Caso de uso: análise de segurança com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snasrpki drill down.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatório de violação de RPKI com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: integração e visibilidade com BGP Link-State (BGP-LS)'''<br /> <br /> Para atender à necessidade de aplicações que exijam visibilidade topológica em áreas IGP ou mesmo em sistemas autônomos, uma AFI/SAFI para o BGP foi definida para permitir que este protocolo carregue em si as informações detalhadas sobre os estados de links, ou seja, a topologia da rede é codificada nos NLRI e as propriedades de objetos são codificadas em atributos do BGP-LS. Esta função do SNAS.io permite mostrar os detalhamentos topológicos transportados pelo BGP para que engenheiros de rede compreendam como melhor otimizar o fornecimento de determinados perfis de conteúdos.<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate map traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> [[Arquivo:Bpf-gerbgp-snaslinkstate SPF and traces.png|centro|miniaturadaimagem|800x800px|Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> '''Caso de uso: relatórios por Sistema Autônomo com a WebUI nativa do SNAS.io'''<br /> <br /> Como o próprio nome sugere, por esta interface podemos informar um número de AS e obtermos informações detalhadas incluindo os registros correspondentes das bases IRR, os prefixos originados pelo ASN pesquisado, e, conforme o entendimento do BGP, a relação de upstreams e downstreams daquele ASN.<br /> [[Arquivo:As view.png|centro|miniaturadaimagem|800x800px|Caso de uso: relatórios por AS com o WebUI original do SNAS.io (Fonte: snas.io)]]<br /> <br /> ==== Caso de uso: monitoramento, analíticos e big data com o Streaming Network Analytics System (SNAS/openBMP) em combinação com o Platform for Network Data Analytics (PNDA) ====<br /> A combinação do PNDA com o SNAS funciona como uma espécie de &quot;''unha e carne''&quot;, pois agrega muitas facilidades que trazem à tona os padrões de visibilidade e transparência acerca do comportamento geral do BGP, em particular as métricas que mais nos preocupam no cotidiano para a tomada de decisões estratégicas. O combo &quot;PNDA + SNAS&quot; abre as portas do '''''big data''''' para as necessidades de BGP ou do roteamento do AS propriamente dito!<br /> <br /> Nesta solução, o SNAS captura os eventos BGP dos roteadores com o uso do ''BGP Monitoring Protocol'' (BMP), exatamente conforme demonstrado anteriormente, só que, em seguida, o SNAS encaminha os eventos coletados via ''Logstash'' para o cluster PNDA através de uma interface que o SNAS mantém com o Kafka - daí uma das aplicabilidades de termos inserido o Kafka neste contexto. O HDFS do PNDA oferece a capacidade de registrar e manter grandes quantidades de dados históricos de eventos, portanto a solução é bem escalável. Na sequência, uma aplicação baseada no Spark cria as consultas que são executadas sobre os dados, extraindo as informações desejadas. Os resultados são então armazenados no componente HBase do PNDA e expostos por meios de uma API REST, onde os usuários/administradores poderão usar uma interface Web amigável para visualizar estes resultados.<br /> <br /> Para os propósitos aqui discutidos, o PNDA executa os seguintes procedimentos com as suas respectivas tecnologias embarcadas:<br /> * Entrada de dados por uma infinidade de opções, incluindo '''''Logstash''''', '''''Open Daylight''''', '''''Bulk Ingest''''' tool, '''''SNAS.io''''', '''''SNMP''''', '''''pmacct''''', '''''Cisco IOS XR Telemetry''''', etc.<br /> * Distribuição de dados por '''''Apache Kafka''''' e '''''Zookeeper'''''.<br /> * Processamento de stream em alta velocidade com '''''Spark Streaming'''''.<br /> * Processamento em lote de alto volume com '''''Spark'''''.<br /> * Exploração de dados de forma livre com o '''''Jupyter'''''.<br /> * Consulta estruturada sobre big data com '''''Impala'''''.<br /> * Manipulação de séries temporais com '''''OpenTSDB''''' e '''''Grafana'''''.<br /> O PNDA é bastante sofisticado no que diz respeito às tecnologias que são disponibilizadas. Uma instalação padrão inclui os seguintes:<br /> * '''''SaltStack:''''' é um software de código aberto baseado em Python para automação de TI orientada a eventos, execução remota de tarefas e gerenciamento de configurações.<br /> * '''''OpenStack Heat templates:''''' o Heat implementa um mecanismo de orquestração para ativar vários aplicativos de nuvem compostos com base em modelos na forma de arquivos de texto que podem ser tratados como código.<br /> * '''''AWS CFN templates:''''' o AWS CloudFormation oferece uma linguagem comum para modelar e provisionar recursos de aplicativos da AWS e terceirizados em um ambiente de nuvem.<br /> * '''''Apache Kafka:''''' é literalmente a &quot;porta da frente&quot; para a entrada dos fluxos dados originados pelos equipamentos da rede.<br /> * '''''Bulk Ingest:''''' atuando como alternativa ao Kafka para acomodar cenários de migração de dados existentes para o PNDA.<br /> * '''''Zookeeper for Kafka:''''' é utilizado pelo Kafka para descoberta e requisições de busca junto aos brokers referentes às partições que deseja consumir.<br /> * '''''JMX Proxy:''''' usado para, dentre outras coisas no PNDA, a exposição de todos os atributos MBean disponíveis em uma determinada JVM por meio de uma simples solicitação HTTP.<br /> * '''''Apache Impala:''''' atuando como um mecanismo de execução paralelo para consultas SQL com acesso de baixa latência e exploração interativa de dados no HDFS e HBase. O Impala permite que os dados sejam armazenados em formato bruto, com a agregação realizada no momento da consulta, sem a necessidade de agregação inicial de dados.<br /> * '''''CMAK (aka &quot;Kafka Manager&quot;):''''' como ferramenta de gerenciamento de clusters Kafka.<br /> * '''''ELK''''' (Logserver)<br /> * '''''Logstash:''''' um dos componentes da arquitetura de logs empregada pelo PNDA, usado para receber dados de inúmeras fontes, transformação e compartilhamento de dados.<br /> * '''''Elasticsearch:''''' um dos componentes da arquitetura de logs empregada pelo PNDA.<br /> * '''''Kibana:''''' um dos componentes da arquitetura de logs empregada pelo PNDA, atuando como plugin de visualização de dados do Elasticsearch.<br /> * '''''Jupyter Hub''''' e '''''Jupyter Notebook:''''' atua como um aplicação que permite criar e compartilhar documentos que contêm código ativo, equações, visualizações e texto explicativo. No PNDA, ele suporta a exploração e apresentação de dados do HDFS e HBase.<br /> * '''''OpenTSDB:''''' atua como um banco de dados escalável de séries temporais que permite armazenar e fornecer grandes quantidades de dados de séries temporais, sem perder granularidade. <br /> * '''''Grafana:''''' atua como construtor de gráficos e painéis para visualizar métricas de séries temporais do PNDA.<br /> * '''''Anaconda:''''' o Anaconda é uma distribuição gratuita e de código aberto das linguagens de programação Python e R para computação científica. Usado para diversas funções do PNDA.<br /> * '''''Consul.io:''''' para gerenciamento de endpoints e descoberta de serviços.<br /> * '''''Apache Flink:''''' atua como uma estrutura e um mecanismo de processamento distribuído para cálculos com estado em fluxos de dados ilimitados e limitados. O Flink foi projetado para executar em todos os ambientes comuns de cluster, executar cálculos na velocidade da memória e em qualquer escala.<br /> * '''''Apache Knox:''''' atua como gateway de aplicativo para interagir com as APIs REST e as UIs das implantações do Apache Hadoop, fornecendo um ponto de acesso único para todas as interações REST e HTTP com os clusters do Apache Hadoop.<br /> O PNDA de fato propõe-se a ser uma plataforma escalável e aberta de big data, com a finalidade de suportar análises operacionais e de inteligência de negócios para redes e serviços, e não sendo uma ferramenta restrita ou específica apenas para ambientes ISP. Algumas destas tecnologias supracitadas dependem de qual distribuição Hadoop for escolhida, sendo que o PNDA pode ser implantado usando Cloudera CDH ou Hortonworks HDP. Dependendo de qual for a distribuição, componentes/pacotes adicionais serão exigidos (ex:, para uma instalação baseada no Cloudera CDH PNDA, são exigidos também Apache Avro + Crunch + DataFu + Hadoop + HBase + Hive + Hue + Impala + Kite SDK + Mahout + Parquet + Pig + Spark + Sqoop/Sqoop2 + ZooKeeper, e outros). <br /> A ilustração a seguir mostra as tantas possibilidades de recebimento de eventos e streaming com o PNDA. Note que o SNAS.io é mencionado como uma das formas de recebimento de dados:<br /> [[Arquivo:Bpf-gerbgp-pnda.jpg|centro|miniaturadaimagem|900x900px|Visão geral do PNDA (Fonte: PNDA.io)]]<br /> <br /> A integração do ''OpenBMP'' ou ''SNAS'' com o ''PNDA'' poderá ser feita usando o ''Logstash''. Conforme já demonstrado anteriormente, os roteadores monitorados enviam as mensagens BMP para o ''OpenBMP/SNAS'', o qual envia estes dados para o ''Kafka''. Por sua vez, o barramento de dados do ''Kafka'' oferece a muitos aplicativos em lote ou streaming a capacidade de acessar feeds BMP existentes de qualquer número de roteadores. A proposta aqui então é a de produzir estes dados BMP no coletor ''OpenBMP/SNAS'' e encaminhá-los para o ''Kafka'' para que possam ser consumidos pelo ''Logstash'' da instalação PNDA. Esta integração está comentada neste link&lt;nowiki/&gt;https://github.com/SNAS/openbmp/blob/master/docs/LOGSTASH.md.<br /> <br /> A interação dos administradores da rede com estes dados poderá ser feita por APIs ou por qualquer outra aplicação que seja pensada para consumir estes dados.<br /> <br /> '''Caso de uso: monitoramento, analíticos e big data com SNAS.io e PNDA.io'''<br /> <br /> Caso você ainda esteja se questionando sobre as vantagens e benefícios de incorporar conceitos de telemetria para o monitoramento do seu BGP, talvez esta seção do artigo possa convencê-lo. Um dos maiores atrativos da telemetria baseada orientada a modelos (eventos + streaming periódico) é que permite obter dados em tempo real e com flexibilidade e granularidade muito superiores aos modelos de gerenciamento tradicionais, já discutidos previamente neste artigo. Quando combinando este modelo de gerenciamento com as soluções certas baseadas em software, você passa a ter acesso a praticamente tudo aquilo que você não conseguia conceber com os modelos tradicionais.<br /> <br /> Nunca foi tão viável entrar no mundo de analíticos e big data com foco nas questões de rede, neste caso aqui o BGP. A combinação de SNAS.io e PNDA.io pode destravar a inteligência que está faltando na grande maioria dos Sistemas Autônomos que correspondem aos ISPs e pequeno e médio portes. Ou seja, big data não é mais luxo de grandes operadores de redes!<br /> <br /> Dentre tantas ações viáveis com big data sobre o BGP, é possível classificar e filtrar todo o histórico de anúncios originados e anunciados por AS, o que por sua vez permite compreender melhor como as mudanças realizadas por upstreams podem estar afetando a convergência do roteamento BGP do seu AS. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda1.png|centro|miniaturadaimagem|900x900px|Análise de prefixos originados e anunciados por AS (Fonte: pnda.io)]]Outra possibilidade é poder consultar informações detalhadas sobre qualquer AS que estiver mencionado em qualquer anúncio que tenha sido registrado e armazenado na base de dados da solução, e isto, por si só, já economiza um tempo bastante razoável, pois você não precisaria ter que recorrer a sistemas ou websites externos para obter estas informações. E sem contar que estas informações sobre estes AS podem ser processadas para representar uma infinidade de analíticos e relatórios adicionais. Isto é mostrado na ilustração a seguir:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda2.png|centro|miniaturadaimagem|900x900px|Informações detalhadas por AS (Fonte: pnda.io)]]Uma das necessidades mais críticas no que diz respeito aos projetos mais elaborados de engenharia de tráfego com o BGP é contar com uma visibilidade bastante aprofundada das relações entre os Sistemas Autônomos na visão do AS da sua empresa, pois isto é o que permite estudar a cadeia de relações com propriedade e conduzir - com auxílio de outros procedimentos - os estudos sobre as matrizes de tráfego, dentre outras coisas. A obtenção destas informações pelos métodos tradicionais é praticamente inviável. Por exemplo, não é viável com SNMP. Já por CLI/Scripting visando a recuperação, ''parsing'' e armazenamento destas informações numa base de dados para consultas posteriores, enfim, seria ao mesmo tempo frágil, pouco escalável, e com elevados requerimentos computacionais, ou seja, praticamente inviável. Por sua vez, o monitoramento do BGP por telemetria, combinado com soluções de software especializadas no processamento e tratamento destes dados, habilita todo um big data sobre como o AS da sua empresa se relaciona com os demais AS da Internet. Com funções inteligentes de pesquisa de baixíssimo esforço você poderá compreender como o seu AS se relaciona com os demais AS da Internet. A ilustração a seguir mostra isso:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda3.png|centro|miniaturadaimagem|900x900px|Análise de relações entre os AS associados aos anúncios mantidos na base de dados (Fonte: pnda.io)]]Outra aplicação muito útil: imagine que você precise estudar os caminhos de AS_PATH associados a determinados destinos, por exemplo, entre dois ASs quaisquer. Como você faria isto pelas vias normais? Você simplesmente teria que acessar diversos roteadores e estudar &quot;na unha&quot;, um por um, todos os anúncios em combinação com cada opção de caminho entre a origem e o destino desejados. Se você conhece bem o BGP e atua em uma operadora ou ISP de maior porte, certamente já teve que fazer este tipo de trabalho um bocado de vezes. Demanda muito tempo, foco, atenção! Pois bem, numa plataforma de analíticos &amp; big data com dados de BGP você não teria dificuldade em estudar todos os caminhos entre a origem e o destino pretendidos, e com &quot;ridículos&quot; cliques identificar quais são os caminhos ativos, quais são os caminhos de menor comprimento de AS_PATH, e quais são os caminhos de maior comprimento de AS_PATH. E tudo isto numa fração de minuto! Isto é demonstrado na ilustração a seguir:[[Arquivo:Bpf-gerbgp-pnda4.png|centro|miniaturadaimagem|900x900px|Análise caminhos &quot;ativo, mais curto, mais longo&quot; entre dois AS (Fonte: pnda.io)]]Nem tudo são flores na parte de segurança do BGP, em especial anomalias associadas a prefixos e atributo AS_PATH. Uma vez que todas as informações do BGP estão armazenadas em bases de dados bastante otimizadas para analíticos, com pouco esforço você conseguirá identificar problemas relacionados à segurança do BGP. A ilustração a seguir demonstra esta facilidade:<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda5.png|centro|miniaturadaimagem|900x900px|Análise de anomalias associadas a prefixos e AS_PATH (Fonte: pnda.io)]]Mais uma funcionalidade interessante aqui: você poder estudar cada ASN identificado na base de dados da solução, consultar informações detalhadas de casa ASN, obter um histórico dos anúncios enviados e recebidos de/para cada ASN, estudar a lista de AS_PATH associada aos anúncios, pesquisar por problemas que podem estar assolando o roteamento BGP do seu AS, dentre outras necessidades.<br /> <br /> [[Arquivo:Bpf-gerbgp-pnda6.png|centro|miniaturadaimagem|900x900px|Análise de caminhos por AS (Fonte: pnda.io)]]<br /> <br /> Por ser uma solução em grande parte baseada em software de código aberto, entendo que o potencial de customização seja absurdo. Na mão de times de desenvolvimento experientes, a sua empresa poderá customizar a solução como bem desejar, incorporando elementos diversos, ajustando, refinando, até que obtenha-se os resultados desejados pelas diversas áreas internas do negócio que possam beneficiar-se com as funções, relatórios e analíticos do monitoramento BGP.<br /> <br /> Para concluir o tema SNAS.io + PNDA.io, caso você queira experimentar uma versão minimalista (com algumas limitações e não recomendado para ambientes de produção), recomendo o [https://github.com/pndaproject/red-pnda Red PNDA]! Você poderá baixar a OVA e rodá-la como uma máquina virtual em uma sandbox para explorar e aprender a desenvolver sobre um ambiente PNDA propício.<br /> <br /> === Conclusão do artigo e próximos passos ===<br /> O tema gerenciamento por si só é algo absolutamente muito extenso, mesmo que eu tenha focado apenas no gerenciamento/monitoramento do BGP. Infelizmente, não há como realmente dissertar livremente sobre o tema em um único artigo. Todavia, está no radar de próximos artigos, aqui na wiki do BPF, conteúdos relacionados ao gerenciamento/monitoramento do BGP com os seguintes:<br /> * Aplicabilidades do ''Multi-Threaded Routing'' (MRT)<br /> * Gerenciamento e monitoramento por telemetria com exemplos de soluções (ex: Cisco IOS XR Telemetry, Pipeline, e outros)<br /> * Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang<br /> * Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)<br /> * Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO<br /> * Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manage (EPN-M)<br /> Siga acompanhando os trabalhos do Brasil Peering Forum! Espero que você tenha curtido este artigo; divulgue-o!<br /> <br /> [[Categoria:Roteamento]]</div>

Leonardo.furtado