Exibir código-fonte para Construção de Redes de Gerenciamento OOB para o ISP

=== Construção de Redes de Gerenciamento OOB para ISP ===

==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====
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]].

'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''

=== Introdução ===
Este artigo vai um pouco além: esclarece um bocado sobre processos de gerenciamento em infraestruturas de redes de ISPs, até mesmo para você perceber a importância e o valor inestimável que um projeto deste tipo poderá representar para o seu ISP!

As ações de gerenciamento de infraestruturas de redes constituem procedimentos operacionais da mais suma importância para que o operador de redes consiga manter bem sustentáveis os níveis de serviço do ISP. Muito há o que se discutir sobre o tema “gerenciamento” em uma rede, em especial redes de provedores de serviços de Internet e afins, e isto será diluído em diversos artigos a serem publicados aqui na Wiki do Brasil Peering Forum (BPF). Começando por este aqui!

Este artigo em particular foca em uma única questão deste tema, que é a aplicabilidade e a viabilidade do '''''Gerenciamento Fora de Banda''''', do inglês “''Out-of-Band Management''", suas vantagens e benefícios, e quais considerações o ISP deverá levar em conta quando projetando as duas redes de gerenciamento, tanto ''In-Band'' quanto ''Out-of-Band'' (OOB). Para completar o eixo e proposições de ideias, este artigo fornece ainda uma visão um pouco melhor elaborada acerca das questões relacionadas ao gerenciamento das infraestruturas de redes.

=== Como o Gerenciamento é Tipicamente Conduzido na Infraestrutura do ISP ===
O operador de redes tem uma série de obrigações no que tange as ações de cunho operacional, e isto inclui o ''gerenciamento de configurações'' - provisionamento de novos clientes e configurações de elementos em projetos nas áreas de concessão e de expansão – assim como o ''gerenciamento de falhas/incidentes'', o ''gerenciamento de desempenho/performance'', o ''gerenciamento de segurança''; ''bilhetagem e tarifação de tráfego'', ''planejamento de capacidades'', etc. Para cada uma destas necessidades, o operador de redes emprega uma diversidade de tecnologias que englobam processos, políticas, protocolos, serviços, software e todo o aparato tecnológico e processual necessário para orquestrar e manter os indicadores gerenciáveis da organização.

Nos ambientes de ISPs de pequeno e médio portes, <u>tudo isto é normalmente executado através da mesma rede L1/L2/L3 que também transporta todas as comunicações e serviços de clientes</u>, no que chamamos de '''''Gerenciamento In-Band'''''. Alguns exemplos de ações de ordem operacional que são conduzidas pela mesma infraestrutura “quente” (''In-Band'') onde também percorre o tráfego de assinantes/clientes:

==== Gerenciamento de Configurações ====
Acesso do operador de redes para os elementos de rede gerenciados. Os times de operação do cliente acessam os dispositivos da rede (ex: OLT, switch, roteador, etc.) via protocolos tais como o Telnet (não recomendado) e o SSH para configurar os elementos funcionais necessários para provisionar um assinante, habilitar um novo serviço na infraestrutura, ativar um novo POP, etc. Em muitos casos, a configuração do elemento pode ser orquestrada por uma plataforma de gerenciamento com módulos especializados para as cadeias de automação do provisionamento de clientes e serviços, e isto fluindo por SNMP ou Netconf. Em adição, operadores de redes “sensatos” implementam o controle de acesso centralizado por TACACS+ (que permite autenticação, autorização e o ''accounting'' dos comandos realizados pelo operador na CLI) ou RADIUS (que implementa apenas a autenticação do operador), um conceito que será abordado em outro artigo aqui da Wiki do BPF.

''Protocolos identificados que percorrem a infraestrutura “In-Band”:'' Telnet, SSH, SNMP, Netconf/XML com SSH/BEEP/SOAP over HTTP, TACACS+ ou RADIUS.

==== Gerenciamento de falhas ====
Exemplos aqui incluem a consulta periódica dos elementos de rede por parte dos sistemas de gerenciamento via procedimentos tais como o SNMP ou scripts. Em suma, os equipamentos na rede possuem as suas respectivas MIBs que descrevem os objetos gerenciados (OIDs), os quais são consultados e interpretados pelas mesmas MIBs suportadas também pelo sistema de gerenciamento. Em muitos casos o operador de redes está interessado em consumir dados estatísticos quanto aos contadores de erros registrados nas interfaces, além da consulta de outras métricas tais como a utilização dos processadores (CPU) do dispositivo, utilização de memória RAM, consulta dos valores relacionados a temperatura de módulos do equipamento, saúde dos sistemas de ventilação, leitura do consumo energético, e uma infinidade de outros objetos gerenciados.

Ou seja, periodicamente o sistema de gerenciamento faz o “''polling''” de OIDs das MIBs suportadas por ambos os equipamentos e o próprio sistema, o que seria um modelo “''pull''” de consulta. Há também o envio dos chamados “''traps''”, que são alertas encaminhados pelo próprio equipamento para o sistema de gerenciamento quando ocorrerem eventos específicos, por exemplo, a indisponibilidade de uma interface ou a falha de um componente do equipamento, ou seja, um modelo “''push''” de encaminhamento/recebimento de eventos. Isto pode ocorrer tanto por SNMP quanto por SYSLOG, ou ainda NETCONF, quando o operador de redes já tiver evoluído os seus conceitos de gerenciamento...

''Protocolos identificados que percorrem a infraestrutura “In-Band”:'' SNMP, Syslog, Netconf.

==== Gerenciamento de desempenho ====
Basicamente atuando nos mesmos moldes do modelo supracitado, os sistemas de gerenciamento podem realizar consultas periódicas (“''polling''”) sobre ''Object Identifiers'' (OID) de uma MIB específica com o intuito de recuperar valores que possam caracterizar métricas de desempenho de interesse da organização, tais como os volumes de tráfego (pacotes, octetos) registrados sobre interfaces físicas ou lógicas do roteador, para que o sistema de gerenciamento possa em seguida consumir estes valores e interpretá-los conforme definições mantidas pelo operador de redes (percentual de ocupação do enlace, cálculo de 95th percentile, etc.). Além das capacidades de gerenciamento de performance por SNMP e/ou Netconf, muitos operadores utilizam o protocolo/serviço NETFLOW para fornecer analíticos sobre as matrizes de tráfego e conversações da rede, em particular com o objetivo de contribuir significativamente para o planejamento de capacidades, planejamento da engenharia de tráfego, e até mesmo para contribuir para a detecção de anomalias de tráfego e também na questão da segurança da informação.

''Protocolos identificados que percorrem a infraestrutura “In-Band”:'' SNMP, Netconf, NetFlow.

==== Gerenciamento de segurança: ====
Aqui o operador de redes realiza o gerenciamento de segurança de suas infraestruturas e em uma diversidade de situações. Por exemplo, a implementação do protocolo RADIUS para a autenticação de assinantes de Internet Banda Larga (por PPPoE/IPoE), ou ainda o RADIUS ou o TACACS+ para serviços de VPN baseadas em IPsec ou SSL/TLS, assim como o TACACS+ para o gerenciamento e controle de acesso aos equipamentos da rede do provedor por parte de seus funcionários e operadores habilitados.

''Protocolos identificados que percorrem a infraestrutura “In-Band”:'' RADIUS e TACACS+.

O grande "X" da questão de todo o exposto acima está no fato que a maioria esmagadora dos ISPs de pequeno e médio portes <u>implementa todas as suas funções de gerenciamento juntamente com todo o restante do tráfego da rede</u>, e normalmente sem qualquer segregação física ou lógica. Ou seja, todo o tráfego de gerenciamento discutido acima percorre sobre os mesmos enlaces físicos e lógicos das redes que servem os clientes do provedor.

Em outras palavras, é o que chamamos de “''Gerenciamento In-Band''” (dentro da banda). 

=== Desafios e Complicações acerca do Gerenciamento In-Band ===
Não que eu esteja condenando a prática do gerenciamento In-Band, muito pelo contrário! Mas torna-se necessário avaliarmos os prós e contras disto, além de termos muitos cuidados aqui, certo? O gerenciamento de configurações, falhas, desempenho, segurança e afins, quando ocorrendo através da mesma infraestrutura física e lógica do provedor que fornece serviços para os assinantes e todo o resto, incorre nos seguintes desafios:

==== Segurança da Infraestrutura do Provedor ====
Uma vez que todos os pacotes compartilham as mesmas redes lógicas onde são transportadas as comunicações dos assinantes/clientes, há um risco de interceptação não autorizada destes pacotes e mensagens de gerenciamento, o que poderia expor severamente a segurança de toda a infraestrutura. No entanto (e felizmente), alguns profissionais de redes compreendem isto com bastante clareza e tomam algumas medidas de mitigação destes riscos, por exemplo:
* Abandonam por completo o uso do Telnet para acesso aos equipamentos, optando apenas pelo SSHv2 para este procedimento. Em adição, listas de controle de acesso e outros procedimentos periféricos contribuem para filtrar quais subredes de origem podem realizar este tipo de acesso nos equipamentos.
* Não utilizam uma Community de Read-Write do SNMP, fazendo apenas o uso de Community de leitura-apenas (Read-Only).
* Configuram os elementos de rede com uma lista de controle de acesso indicando quais endereços IP de origem (que deverão ser apenas os dos sistemas de gerenciamento) podem fazer consultas e sobre quais SNMP Communities habilitadas no equipamento.
* Optam por implementar o SNMPv3 ao invés do SNMPv2c, pois o v3 implementa mecanismos razoavelmente bem confiáveis de autenticação, integridade e confidencialidade.
* Configuram os sistemas de gerenciamento para aceitar mensagens SNMP (mensagens ''get'' e ''trap'') apenas de elementos pré-cadastrados e autorizados pelo sistema.
* Separam o tráfego de gerenciamento do tráfego de “produção” por VLANs (ex: VLANs dedicadas exclusivamente para o tráfego de gerenciamento) e/ou por ''Virtual Routing and Forwarding'' (VRFs), que seriam redes IP completamente isoladas das redes IP (da tabela de roteamento global/default) que caracterizam os serviços de trânsito dos assinantes.
* Configuram seus coletores de NetFlow, tanto os associados ao gerenciamento de desempenho quanto os de guarda e retenção de logs de traduções de NAT, para descartar pacotes originados de elementos desconhecidos.
* Dentre outras iniciativas.
O exposto acima são apenas alguns exemplos de iniciativas que devem ser consideradas e tomadas pelo operador de redes quando visando proteger o seu tráfego de gerenciamento ''in-band''. A proposta é viabilizar o gerenciamento ''in-band'' de forma mais segura e segregada com relação ao tráfego de trânsito geral.

Então, na questão de segurança, temos ótimas soluções e práticas para o gerenciamento ''In-Band''. Então, haveria outro problema ou o risco a ser discutido neste artigo? Continuemos a leitura.

==== Inabilidade de Efetuar Suporte Emergencial em Áreas Indisponíveis por Falhas ====
Entenda que uma rede de gerenciamento ''In-Band'' ficará completamente indisponível se ocorrerem falhas na rede que inviabilizem a conectividade IP exigida entre o analista de suporte (ex: NOC do provedor) e os elementos de rede afetados pela falha. Isto é verdadeiro porque os mesmos protocolos de resiliência L2 e/ou os protocolos de roteamento IP mantém a integridade topológica e a conectividade IP de toda a infraestrutura que compreende tanto os serviços de trânsito dos assinantes quanto todos os mecanismos de gerenciamento e suporte dos elementos da rede efetuados pelo NOC/Suporte do provedor.

Para exemplificar, suponhamos que um enlace de transporte entre duas regiões de sua rede fique indisponível por causa de um rompimento na rede. Você será incapaz de acessar os equipamentos remotamente até que este enlace de rede seja restabelecido. Fato. Mas este não é o pior dos problemas. O que será comentado a seguir é bem pior.

Agora imagine que há um problema de ordem lógica na sua rede, e sem qualquer relação com a disponibilidade da rede física. Este é o cenário. Exercitemos uma situação clássica aqui:<blockquote>'''''Um funcionário do seu NOC ou do setor de ativações acidentalmente configurou um parâmetro incorreto que provocou uma convergência igualmente incorreta nos protocolos da rede, e que isto provocou a perda de conectividade L2 e/ou L3 na sua rede, afetando imediatamente muitos clientes, ou até mesmo partes inteiras da sua rede. Esta configuração foi realizada num equipamento remoto, só que, no momento, você não consegue acessá-lo por conta desta indisponibilidade. Óbvio. Para piorar a situação, o equipamento está localizado a pelo menos 100 km de distância do técnico capacitado mais próximo possível em condições de responder ou atuar sobre este incidente. O que você ou este técnico teria que fazer? Não restará outra opção a não ser o deslocamento até este o local onde este equipamento se encontra, e acessá-lo diretamente a partir de sua porta de console, certo?'''''</blockquote>
[[Arquivo:Bpf-oob-1.png|centro|miniaturadaimagem|900x900px|Motivadores quanto a adoção do gerenciamento fora-de-banda (OOB)]]

Compreende agora a situação?

=== Motivadores para a construção de uma rede de gerenciamento OOB ===
O problema está justamente neste risco de ocorrer alguma indisponibilidade na sua rede e que isole uma parte dela, e você ficar completamente refém e incapaz de completar um diagnóstico ou de prosseguir com o suporte remotamente, se vendo forçado ir até o local onde encontra-se o equipamento para acessá-lo localmente. Dependendo da distância onde este equipamento estiver instalado, isto poderá levar muito tempo e certamente provocará diversos aborrecimentos para o ISP e para seus clientes.

==== O que os Provedores devem Fazer para Evitar os Traumas de um Downtime deste Porte e nas Condições supracitadas ====
Alguns operadores de redes tratam isto de forma bem profissional e buscam antecipar-se à ocorrência destas fatalidades, e adotando iniciativas que incluem:
# Instauração de processos consistentes de gestão de mudanças (GMUD) com base em orientações regidas por modelos ITIL/COBIT. Afinal de contas, o ser humano fatora por mais da metade dos incidentes que provocam downtime.
# Controle de qualidade nas propostas de configurações de elementos de rede, com controle de versão, revisão em duas ou mais camadas, cadeias de aprovação de mudanças, interpretação do risco da mudança, programação da janela de manutenção para o lançamento das configurações desejadas, plano de comunicação, plano de ''rollback'', etc.

===== Quando os elementos de rede suportam facilidades de commit ou checkpointing de configurações, o ISP deve fazer o uso adequado e extensivo das facilidades =====
Quando os equipamentos suportam ''commit'' com ''rollback'' automático em caso de isolamento do analista do equipamento, a coisa fica mais suave: uma configuração errada não te isolará por muito tempo! O problema ficaria cabuloso apenas se fosse um bug no software do equipamento ou problemas mais graves nos protocolos de resiliência ou de roteamento, aí somente mesmo acessando a porta de console do equipamento remoto para poder diagnosticar o problema! 

Já quando os elementos de rede não suportam mecanismos de ''commit''/''checkpoint'' com ''rollback'' automático, o profissional de ISP deve tomar medidas cautelosas extras tais como a validação do ticket de configuração, implementação primeiro em modo off-line para somente depois lançar as configurações no equipamento ("CTRL-C/CTRL-V"), mas não sem antes deixar um “''reboot''” automático agendado para os próximos 10 minutos ou algo parecido, pois seria o máximo de downtime + tempo de reboot + tempo de convergência dos protocolos que os clientes experimentariam – o que já seria desastroso! E não se esqueça de cancelar o ''reboot'' automático, caso a configuração tenha sido aplicada com êxito!

Ou...

... '''<u>o ISP projeta e implementa uma infraestrutura fora-de-banda (OOB)</u>''', que é justamente o foco deste artigo!

=== O que é uma Rede de Gerenciamento Fora de Banda (OOB) ===
Uma rede OOB é um ambiente construído à parte onde percorrem os pacotes relacionados às funções de gerenciamento do ambiente, promovendo ótima separação entre o tráfego de trânsito/produção e, obviamente, o tráfego de gerenciamento. Geralmente a rede OOB é utilizada somente como contingência para acesso aos equipamentos de rede remotos - o que atende muito bem a maioria dos casos - mas há outras possibilidades também, as quais serão discutidas a seguir.

Embora seja perfeitamente possível ou viável separar o tráfego de trânsito do tráfego de gerenciamento por meios de VLANs e/ou VRFs dedicadas para gerenciamento, isto não necessariamente constitui uma rede OOB, pois os enlaces físicos são compartilhados tanto pelo tráfego de produção quanto pelo tráfego de gerenciamento. Aliás, não somente os enlaces físicos, mas os protocolos de resiliência e os protocolos de roteamento IP são responsáveis por manter as topologias das duas redes (produção e gerenciamento). Isto significa que um loop na camada 2, ou um loop na camada 3 (roteamento), ou informações incorretas nas estruturas de comutação L2 (endereços MAC) e de camada 3 (rotas) inviabilizaria qualquer tentativa de diagnóstico e suporte remoto aos equipamentos afetados. Por isto que compreendo que uma rede onde a separação do tráfego de gerenciamento se dá por VLANs e/ou VRFs não constitui necessariamente uma rede de gerenciamento fora-de-banda.

==== Como uma Rede de Gerenciamento OOB é composta ====
Há muitas possibilidades e customizações cabíveis aqui, portanto tentarei exercer algumas destas situações.

Uma possibilidade seria a construção de uma rede em paralelo relativamente simples em termos de elementos de rede – podendo ser equipamentos “mais em conta” – mas desde que usando enlaces físicos dedicados. E considerando que esta rede de fato não compartilhe as mesmas rotas físicas e nem as mesmas instâncias de protocolos L2 e L3 da rede de produção.

===== Cenário 1: uma Rede OOB Dedicada para Todas as Funções de Gerenciamento =====
<u>Desafios aqui:</u> em suma, seriam "custos, complexidades excessivas e paranóia". Embora perfeitamente viável no ponto de vista de uma instalação de um site, POP, numa LAN, enfim, esta abordagem é quase inviável numa rede metropolitana em função de seu alto custo de implementação quando considerando uma malha de conexões externas do próprio provedor. Ou seja, é financeiramente viável implementar uma rede física completamente segregada dentro de um prédio ou site, mas fica realmente muito difícil estender essa rede/abordagem para outros (muitos) sites remotos através da rede metropolitana, exceto se, talvez, compartilhando as mesmas rotas óticas, por exemplo, mas aí o cenário perderia muitos de seus benefícios propostos. O fator complicador aqui são as rotas externas, que incorrem em custos elevados, além da complexidade de integração deste setup. Nesta abordagem, conectamos as portas de gerenciamento Ethernet dedicadas (''Ethernet Out-of-Band'' (''EOBC'')) nos elementos de rede (ex: switches, roteadores, etc.) dedicados para OOB do site, e os uplinks saindo destes elementos obviamente transportando este tráfego ao longo de toda a rede OOB entre os sites/POPs em rotas físicas dedicadas. Em adição, as portas de console dos roteadores seriam conectadas em servidores de terminais para maior flexibilidade e redução de MTTR caso o operador tenha que imediatamente acessar um dispositivo remoto pela porta de console. Não expandirei mais este conceito, pois o cenário "3" a seguir é indiscutivelmente mais interessante, fácil e viável. 

===== Cenário 2: extensão de uma Rede OOB Dedicada através da Internet Banda Larga de Terceiros ou por Conexão 3G/4G =====
Outra possibilidade seria o provedor manter em cada site uma rede física OOB completamente segregada dentro deste local, a exemplo do que foi discutido no cenário anterior, mas fazendo a extensão ou interconexão destas redes através de acessos de Internet banda larga contratados de outros provedores de acesso de Internet, ou por conexões 3G/4G. Ou ainda por acesso discado (v.92) para acesso remoto apenas. Ou seja, cada site contaria com um ou dois links de Internet banda larga e/ou 3G/4G, de baixa capacidade e de baixo custo mesmo, para ter uma contingência de acesso remoto aos equipamentos do site. Para projetos mais complexos e que exijam uma segregação completa, a rede OOB atenderia também para as funções gerais de gerenciamento.

É um modelo interessante e um dos que mais me agrada devido ao balanceamento entre viabilidade técnica e custos associados a este tipo de implantação. Em adição, as soluções de SD-WAN disponíveis no mercado dariam conta facilmente de promover esta rede de gerenciamento OOB com comodidade, flexibilidade e segurança.

Nesta abordagem, o tráfego de gerenciamento poderia fluir por interfaces dos dispositivos que sejam dedicadas paras as funções de gerenciamento, ou seja, portas ''Ethernet Out-of-Band'' (EOBC) conectadas nesta rede OOB em um site ou POP, e este site/POP se comunicando com o NOC do ISP através de uma VPN em um dispositivo clássico específico ou, melhor ainda, nestas novas soluções baseadas em SD-WAN, ou seja, assegurando aqui autenticidade, integridade e confidencialidade nas comunicações de gerenciamento, além da flexibilidade do cenário. Em adição, as portas de console dos equipamentos nos sites/POPs seriam conectadas para servidores de terminais para garantir que haverá sempre uma forma de acessar os equipamentos, mesmo que haja problemas na rede de produção ou na rede OOB onde conectam-se as interfaces EOBC. 

<u>Desafios aqui:</u> o maior problema com esta abordagem está na eventual e frequente (in)disponibilidade/ausência de portas Ethernet dedicadas para gerenciamento (EOBC), pois muitos equipamentos presentes nos ISPs não dispõem deste recurso. Outro desafio poderá ser o custo associado a abordagem, pois cada site exigirá uma conexão com a Internet - que felizmente não precisa ser um circuito de alta capacidade - além do fato de você ter que gerenciar e monitorar a própria rede OOB, assegurando que a mesma esteja disponível sempre que precisar. No entanto, no que diz respeito ao acesso remoto através das conexões com as portas de console dos equipamentos em um servidor de terminais, felizmente, você não terá problemas aqui!

===== Cenário 3: uma Rede In-Band Segregada por VLAN/VRF para Gerenciamento Geral combinada com uma Rede OOB apenas para Acesso Remoto =====
Esta abordagem é essencialmente o modelo anterior, só que bem mais simplificado. Praticamente todas as funções de gerenciamento (configurações, falhas, desempenho, etc.) fluem apenas através da rede ''In-Band'' através de uma segregação lógica por VLANs e VRFs, enquanto o acesso aos equipamentos possui uma contingência pela rede OOB e, neste caso do acesso remoto, ambas a porta EOBC (se cada equipamento possuir) e a porta de console de cada equipamento ficariam disponíveis a partir do servidor de terminais presentes no site remoto. Desta forma, caso ocorram falhas na rede de produção e de forma impeça o acesso do analista ao equipamento remoto, em razão de uma configuração incorreta realizada por um operador, ou ainda por alguma condição de pane/bug no software de algum equipamento, ou falha de convergência dos protocolos da rede, o analista de redes conseguiria acessar os equipamentos a partir da rede OOB (pela porta de console ou pela porta EOBC) para fazer diagnósticos, suporte e efetiva correção do problema.

É um modelo bastante interessante e que atende a maioria dos cenários de contingenciamento dos operadores de redes. É particularmente o modelo que eu prefiro trabalhar na maioria dos meus projetos, pois assegura o acesso ao equipamento em situações de pane geral na rede e também acesso "''Lights-Out-Management''" (LOM) de dispositivos críticos do site remoto. Exceto onde outras circunstâncias fatorarem por abordagens diferentes e/ou com necessidades mais específicas.

A ilustração a seguir mostra todos os três setups discutidos acima.
[[Arquivo:Bpf-oob-2.png|centro|miniaturadaimagem|900x900px|Exemplos de cenários possíveis com redes OOB]]

==== Uma Rede OOB para Contingência de Acesso aos Equipamentos Remotos ====
Conforme citado anteriormente, há diversas possibilidades na questão de construção de uma rede OOB. Alguns projetistas precisam conceber ambientes OOB mais complexos e completos em função dos requerimentos tecnológicos do negócio. Todavia, a maioria dos casos tende a ser mais simples, e exigindo uma rede OOB muito simplificada apenas para o viabilizar o acesso remoto aos equipamentos em caso de falhas na rede ''In-Band''. Nestes casos, uma solução bem competitiva poderia contar com dispositivos especializados para o estabelecimento da conectividade do analista de suporte para as portas de console dos equipamentos remotos. 

Um exemplo deste tipo de solução está demonstrado logo abaixo. No mercado há ofertas de diversos modelos, que variam entre densidade de portas e algumas capacidades ou funcionalidades mais específicas, como é o caso das soluções Avocent/ Vertiv. Não quero realmente me limitar a vendors aqui, pois a diversidade de opções é muito grande para este tipo de solução, incluindo a própria Vertiv, os network appliances DM8630 da Datacom, além de Mikrotik e outros. Ou ainda soluções customizadas em ''bare metal'' com OS Linux embarcado.
[[Arquivo:Bpf-oob-3.png|centro|miniaturadaimagem|900x900px|Uso de servidores de terminais para acesso remoto à console de equipamentos em um site remoto]]

==== Dissertando um pouco sobre Ethernet Out-Of-Band Channel (EOBC) ====
Uma porta Ethernet EOBC não é uma porta "de roteador" convencional, no sentido que ela é sistemicamente apartada das funções L3 gerais do equipamento, Para exemplificar, uma porta EOBC não possui qualquer conectividade IP com outras portas físicas do roteador, e isto significa que nenhum tráfego que entre por uma porta comum será roteado através da porta EOBC, e vice-versa. Como o próprio nome sugere, é uma porta dedicada única e exclusivamente para funções de gerenciamento.

Vejamos alguns exemplos destas portas EOBC em alguns dos principais equipamentos usados no mercado de ISPs:
[[Arquivo:Bpf-oob-4.png|centro|miniaturadaimagem|900x900px]]
Estas portas podem ser conectadas para redes Ethernet Fora-de-Banda (OOB) dedicadas, ou para redes In-Band com separação do tráfego de gerenciamento por VLAN+VRF..

==== Outras Aplicações para Redes OOB ====
Para manter o foco e a principal utilidade deste artigo, não estenderei muito esta seção. Apenas gostaria de informar que a rede OOB poderá ser utilizada para a recuperação de desastres e contingenciamento de outros tipos de dispositivos que não apenas roteadores, switches e afins. Um exemplo bem clássico disto é a tecnologia '''''Lights-Out Management''''' ('''''LOM''''') embarcada/disponível em muitos servidores e até mesmo em equipamentos de rede de missão Data Center! Servidores da Dell são equipados com o ''Controlador de Acesso Remoto Dell'' (''iDRAC''). A HP possui o ''HPE Integrated Lights Out'' (''ILO''), assim como a IBM possui o seu ''integrated Lights Out'' (''iLO'') ou ''Integrated Management Module'' (''IMM''). Os servidores da Cisco possuem ''Cisco Integrated Management Controller'' (''CIMC''), a Intel possui o seu ''RMM2'', a Sun o ''DRAC''. O que importa é você compreender que estas capacidades existem e que estes recursos podem me explorados para a redução do tempo de reparo de incidentes/falhas na rede!

=== Vídeos sobre o Tema de Redes OOB ===
Vídeo relacionado a este artigo, no canal do YouTube do Brasil Peering Forum (BPF): '''[https://youtu.be/9aQaCo_yDkU Vídeo Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP].'''

Confira a palestra do Fernando Frediani GTER 44: '''[https://youtu.be/w-CiHVEYZN8 Construindo Sua Rede Out of Band Sem Complicação].''' Ele consegue sintetizar muito bem a proposta abordada por este artigo.

Espero que este artigo tenha sido útil! E até o próximo!

'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''
[[Categoria:Roteamento]]