Você conhece os fundamentos básicos de control plane e data plane?
Este artigo tem como principal proposta sanear muitas das dúvidas que profissionais de redes possuem acerca da arquitetura de roteadores, principalmente no que tange o Plano de Controle (Control Plane) e Plano de Dados (Data Plane), e como as diversas funções de programabilidade ocorrem numa plataforma sofisticada de roteamento. Vejamos:
Control Plane
O Control Plane é a parte da arquitetura dos roteadores que hospeda os protocolos de roteamento e emprega os PDUs destes para o estabelecimento de vizinhanças ou adjacências, com a posterior troca de informações sobre as redes atendidas por cada protocolo de roteamento participante. Os PDUs são as unidades de pacotes de dados, ou simplesmente “pacotes”, sendo que cada protocolo emprega os seus PDUs de acordo com as suas respectivas necessidades e funções. Fornecendo alguns exemplos aqui, mas sem entrar em muitos detalhes – até mesmo porque este não é o foco deste artigo – com a exceção do OSPF:
Protocolo de roteamento OSPF:
- Tipos de pacotes
- Packet Type 1 “Hello”: usado para descobrir roteadores OSPF vizinhos, estabelecer uma comunicação bidirecional e formar adjacências.
- Packet Type 2 “Database Description” (DBD): usado para fornecer um resumo do LSDB para que dois roteadores iniciem a troca de seus LSAs.
- Packet Type 3 “Link-State Request” (LSR): usado para que um roteador requisite o LSA detalhado para o roteador vizinho.
- Packet Type 4 “Link-State Update” (LSU): usado para propagar LSAs para roteadores OSPF adjacentes.
- Packet Type 5 “Link-State Ack” (LSAck): usado para realizar o Acknowledgement de LSAs recebidos.
- Tabelas e estrutura de dados
- Tabela de roteadores adjacentes
- Link-State Database (LSDB)
Protocolo de roteamento EIGRP:
- Tipos de pacotes
- Hello/Acks:
- Updates
- Queries
- Replies
- Requests
- Tabelas e estruturas de dados
- Tabela de roteadores vizinhos
- Topology table
Protocolo de roteamento BGP:
- Tipos de pacotes (o BGP emprega “mensagens”)
- Open Message
- Update Message
- Keepalive Message
- Notification Message
- Tabelas e estruturas de dados
- BGP Table
Protocolo Cisco Discovery Protocol (CDP), o qual emprega “Tupples” (Type, Length and Values, ou “TLV”).
- Device-ID TLV, Address TLV, Port-ID TLV, Capabilities TLV, Version TLV, Platform TLV, IP Network Prefix TLV, VTP Management Domain TLV, Native VLAN TLV, Full/Half Duplex TLV
Protocolo Spanning Tree Protocol
- Emprega o Bridge Protocol Data Unit (BPDU). No Rapid STP (802.1w), por exemplo, 6 bits do byte Flag indicam diversas funções (Topology Change, Proposal, Port Role, Learning, Forwarding, Agreement, Topology Change Ack)
Podemos parar por aqui! Obviamente o foco do artigo não é detalhar os protocolos, e tudo o que tentei explicar aqui é que o Control Plane é a área sistêmica onde rodam os processos de serviços de software tais como protocolos de roteamento e outros, e que cada um destes protocolos emprega uma diversidade de tipos de pacotes em adição às suas próprias estruturas de dados.
É no Control Plane que encontramos protocolos tais como Spanning Tree, REP, RIPv2, RIPng, OSPF, OSPFv3, ISIS, BGP, LDP, RSVP, LACP, UDLD, BFD, CDP, LLDP, e tantos outros. E o Control Plane também mantém as estruturas de dados elaboradas e mantidas por cada um destes protocolos, conforme demonstrado acima, sendo que cada protocolo de roteamento ofertará as suas melhores opções de caminhos para que sejam publicadas na, talvez, a tabela mais importante de todas: a tabela de roteamento (ou Routing Information Base, “RIB”).
Data Plane
O Data Plane é a parte da arquitetura dos roteadores que é responsável pelas ações de encaminhamento de pacotes e a implementação de quaisquer recursos ou serviços associados aos pacotes. Dentre as diversas ações, podemos exemplificar aqui o processamento de Access Control Lists (ACL), Quality of Service (QoS), Network Address Translation (NAT), dentre outros.
E no Data Plane é onde o roteador mantém as estruturas de dados referentes aos prefixos para o devido encaminhamento de pacotes, a chamada Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), e tabelas de adjacências (ADJ). No Data Plane é onde ocorrem as programações necessárias para a execução da “determinação de caminhos” (para onde entregar o pacote, por qual interface, e através de qual adjacência IP?), o “encaminhamento de pacotes”, e também o acionamento de quaisquer facilidades ou serviços sobre os pacotes (ex: uRPF, QoS, ACL, NAT, etc.).
A interação entre Control Plane e Data Plane
Tecnicamente falando, a Routing Information Base ou “RIB” é essencialmente idêntica a Forwarding Information Base ou “FIB”, pelo menos no que diz respeito aos prefixos de rede listados na tabela de roteamento. Ou seja, os mesmos prefixos de rede listados na RIB deverão existir na FIB.
Obviamente, no que tange ao formato, estrutura e apresentação de dados, as diferenças são bastante significativas entre a ambas. A FIB é projetada para ser computacionalmente mais eficiente do que a RIB, ou seja, mesmo que consultas fossem realizadas por processos de software, as consultas sobre uma FIB teriam sido mais eficientes do que as mesmas consultas realizadas sobre a RIB.
Sem entrar em muitos detalhes sobre o CEF e suas estruturas FIB e ADJ, a proposta deste mecanismo (o que chamamos de switching path) é possuir informações pré-computadas para permitir procedimentos muito mais eficientes de consultas sobre prefixos e a posterior reescrita dos cabeçalhos de enlace de dados.
Onde residem as estruturas de dados RIB e FIB?
A grande diferença sistêmica, no entanto, é que a RIB reside no Control Plane, enquanto a FIB reside no Data Plane. Reforço aqui a idéia de que há efetivamente uma separação sistêmica entre os dois planos, e o objetivo disto é permitir o encaminhamento de pacotes em hardware especializado sem que o pacote tenha que ser processado por software. A proposta é bem simples, e significa que o roteador deva encaminhar os pacotes de trânsito integralmente através do Data Plane, sem “tocar” nos componentes de Control Plane. Esta separação entre Control Plane e Data Plane lá atrás, no início, ainda era uma coisa que usava substancialmente alguns recursos de software, o que limitava de certa forma a capacidade de vazão de pacotes por segundo de roteadores, afetando o desempenho de comutação/encaminhamento de pacotes do equipamento (que para transmissões L2 era bem rápido, porém bem menor quando transmitindo por L3 (roteamento)).
As estruturas de dados usadas no Control Plane e no Data Plane
Não entrarei em detalhes do fator histórico e a evolução disto (Process Switching, Fast Switching, Optimum Switching, Silicon Switching, e, ultimamente, o Cisco Express Forwarding (CEF)). O fato é que as arquiteturas de roteadores evoluíram muito, e nos dias atuais há opções de plataformas de roteamento que oferecem uma completa separação sistêmica entre as duas principais áreas funcionais do roteador: o CONTROL PLANE e o DATA PLANE.
Pois bem, conforme citado anteriormente, há estruturas de dados que são mantidas no Control Plane, tais como, por exemplo, BGP Table (Tabela BGP), OSPF LSDB, EIGRP Topology, Tabelas de Vizinhanças de cada protocolo (ex: adjacências de OSPF e neighbors de EIGRP, BGP…), RIB (Tabela de Roteamento), LIB (Label Information Base) ou LSD (Label Switching Database), dentre outros, inclusive uma versão da FIB baseada em Software, enquanto outras estruturas são mantidas no DATA PLANE e programadas em hardware especializado, tais como FIB e ADJ.
Os componentes onde estas estruturas de dados do Data Plane são mantidas depende muito do hardware em questão. Por exemplo, num Cisco ASR 9000 seria no complexo das NPU de cada Line Card, num Cisco CRS seria nas PSE Tx e Rx dos MSC/LSP/FP, num Cisco Catalyst 6500 no Policy Feature Card (PFC3 ou PFC4), que é acoplado ao módulo Supervisor; nos switches Cisco ME 3600X/3800X nos Carrier Ethernet ASIC assim como no caso do Cisco ASR 903 e 920. No Cisco ASR 1000 no complexo QuantumFlow Processor (QFP) dos módulos físicos Embedded Services Processors (ESP). E, pra finalizar a lista de exemplos, num Cisco Nexus com módulo F, isto ocorreria sobre a arquitetura SoC destes módulos de I/O.
Os benefícios dos componente de Data Plane das arquiteturas de roteamento mais vigentes
A tecnologia empregada por cada tipo de arquitetura, cada qual no seu equipamento, é diferente, mas a proposta é a mesma: fazer com que o tráfego de trânsito – aqueles pacotes que não possuam como destino o próprio equipamento – seja processado integralmente em hardware dedicado ou especializado, sem qualquer envolvimento do Control Plane para o processamento e encaminhamento do pacote. Obviamente isto significa a não consulta da RIB no Control Plane. E isto significa também que as ações de reescrita dos cabeçalhos se dê por instruções pré-computadas e mantidas em hardware especializado, novamente, sem envolvimento de processos de software para as ações de packet rewrite.
Ao detalharmos esta proposta de arquitetura para o processamento e encaminhamento de pacotes, indicamos que os “lookups” (as consultas) de prefixos mais específicos visando o encaminhamento de pacotes não devam ocorrer na tabela de roteamento, e sim sobre uma estrutura de dados que por si só é mais eficiente ou computacionalmente menos onerosa, e que ainda por cima esta estrutura possa ser programada sobre um hardware mais especializado. Ou seja, a FIB em hardware. Desta forma, mesmo que a FIB seja tratada como um “espelho” da RIB, há estas diferenças de performance estruturais e o fato da FIB estar hospedada em um hardware muito diferenciado.
O aumento do desempenho, a redução do overhead decorrente do processamento de pacotes sobre estruturas de dados em hardware especializado…
Isto é o que fomenta a elevada taxa de encaminhamento de pacotes para estas arquiteturas avançadas, pois os procedimentos de determinação de caminhos e reescrita de pacotes (ou path determination e packet switching) deixou de ser realizado por software. Em raras circunstâncias é necessário haver algum processamento por software, dependendo do hardware empregado, tais como pacotes com algumas Options no cabeçalho IP ou pacotes fragmentados.
Por outro lado, quando há pacotes com destino o próprio router, uma parte do processamento destes pacotes é feita por hardware especializado (nos Line Cards ou Módulos de I/O dos equipamentos), e outra parte é realizada por software, uma vez o pacote chegando no complexo do Control Plane (os Line Cards tem alguns, poucos, componentes de control plane, e a maior parte disto fica na RP/RSP/SUP). Geralmente há um serviço para lidar com isto, como é o caso do Local Packet Transport Services (LPTS) do Cisco IOS XR. Exemplos de pacotes que caem nesta categoria incluem acessos de gerenciamento para o próprio roteador (ex: SSH, Telnet, SNMP…) e principalmente os PDUs dos protocolos de roteamento (os pacotes ou mensagens destes protocolos).
Em linhas gerais, como estas estruturas de dados são programadas no Data Plane?
Componentes de comunicação entre processos (interprocess communication ou IPC) são responsáveis por sincronizar a FIB com base nos dados da RIB. Como isto funciona exatamente depende do hardware e do sistema operacional do equipamento. No caso de um Cisco IOS XR, por exemplo, o serviço é o Bulk Content Downloader (BCDL) que usa um IPC proprietário baseado em Multicast chamado Group Services Process (GSP), que por sua vez é responsável por transportar os dados do processo “produtor” da informação (ex: ipv4_mgr, que mantém as rotas IPv4 na RIB no RSP/RP) para o processo “consumidor” nos Line Cards (ex: fib_mgr, que mantém a FIB nos Line Cards). Agentes de Gerenciamento (MA) nos Line Cards trabalham com os dados recebidos e os Agentes de Execução (EA) programam estas estruturas no hardware do Line Card.
Logo, isto reforça novamente o fato que a FIB possui os mesmos dados (prefixos/rotas) da RIB, pois a cada rota que entra ou sai no Control Plane gera a atualização correspondente no Data Plane – tipicamente uma programação de hardware, por exemplo, um TreeBitmap Control atualizando PLUs e TLUs correspondentes no hardware especializado, como no caso do Cisco CRS. Como isto é exatamente realizado, varia de acordo com o tipo de equipamento.
O Data Plane possui instruções adicionais para lidar com os pacotes. Por exemplo, operação com labels, NAT, marcação de QoS e outros, e não somente os prefixos de rede que foram consumidos a partir dos IPCs que divulgaram estes prefixos a partir da RIB no Control Plane.
O Control Plane de plataformas de arquiteturas distribuídas
Para finalizar, algumas plataformas mais sofisticadas empregam alguns componentes de Control Plane diretamente no hardware da Line Card, justamente visando aliviar ainda mais o processamento dos módulos RP/RSP, o que chamamos de “Offload” de CPU. É o caso de protocolos tais como UDLD, BFD, ARP, ICMP, CDP, LLDP, NetFlow sendo processados diretamente por CPUs dedicadas nos Line Cards, o que mantém as ASICs dos Line Cards fazendo o que sabem fazer de melhor: processar pacotes em trânsito enquanto fazendo o “offloading” da CPU dos módulos de supervisão e controle (ex: RP/RSP). Equipamentos que suportam esta distribuição do Control Plane incluem o Cisco ASR 9000, Cisco CRS, Cisco NCS 6000, e outros.
Espero que este artigo tenha esclarecido muitas dúvidas!
O Gifará Serviços Avançados em TIC é especializado em treinamentos avançados que tratam exclusivamente de temas tais como a arquitetura de plataformas de roteadores, switches, servidores, SAN, etc., e capacita os estudantes para projetar, implantar, e operar sofisticadas infraestruturas de redes para Service Providers, Corporativo, e Data Centers.
Consulte-nos!
Leonardo Furtado
