Roteamento Inter SA9 e SA4

Antes de nos termos desviado para o tema de redundância, estávamos precisamente a falar da passagem de conhecimentos do SA9 para o SA3. Até aqui fez-se roteamento dentro da SA9, mas agora o roteamento vai passar para o exterior da SA9, portanto para fora do domínio da NetByCabo. A SA9, ou o ISP NetByCabo, será tipicamente o caso de um ISP que cobre todos os níveis, desde o nível 2 até ao de nível de acesso.

Do outro lado da nossa viagem, considerámos o SA4 em tudo idêntica ao SA9, com o mesmo número de endereços, a mesma subdivisão, etc. Só o nome muda. Vamos chamar-lhe ClientInNet, que se subdividirá em ClientInNet 1 a 8, que por sua vez se subdividirá em CIN 1.1 a 8.8. Claro que qualquer um destes ISP que se fazem anunciar como redes de 18 bits, dispondo só de 2¹⁴=16.384 endereços, definido como um ISP de nível 2, pertence ao campo do imaginário, mas cumpre o objetivo de melhor fazer entender os vários aspetos relacionados com roteamento.

Entre o SA9 e o SA4 vamos no nosso exemplo entregar o roteamento a ISP de nível 1, portanto que só prestam serviços de Backbone. Este roteamento poderia passar pelos caminhos menos imagináveis, saltando entre os diversos ISP (SA) de nível 2 através dos seus roteadores de borda sem mesmo nunca utilizar um ISP de nível 1. Todas essas linhas de comunicação são possíveis e podem ser utilizadas, desde que por questões técnicas ou comerciais os administradores das diversas redes deem preferência a determinadas rotas, atribuindo-lhes por isso menores custos e derivando assim o roteamento para elas. Mas, como facilmente se entende, se colocássemos no nosso esquema gráfico todas as possíveis linhas de roteamento Inter SA, o esquema tornar-se-ia ilegível, o que está longe de ser o nosso propósito.

SA de Backbone – ISP de Nível 1 – Protocolo eBGP

Os SA3, SA2 e SA1 são ISP de Backbone, portanto ISP de nível 1. Nos seus roteadores de borda, os restantes SA passam-lhes os endereços de redes que conhecem e que se encarregam de encaminhar. Esses endereços são carregados em tabelas de roteamento que podem incluir outros elementos, como o AS-PATH, ou o NEXT-HOP.

• O AS-PATH é constituído pelo conjunto dos ID dos SA que são atravessadas, até chegar ao roteador de borda que passa a informação para o SA a que pertence o roteador que está a preencher a tabela. De cada vez que um SA passa a informação o outro SA, inclui o seu ID no AS-PATH.
• NEXT-HOP ou roteador de Próximo Salto, é utilizado pelo roteador que preenche a tabela para registar o endereço do roteador que passou uma determinada informação. Ao passar este valor o roteador que o passa está a dizer ao roteador que o recebe, que foi ele quem passou aquela rota, pois nessa rota ele é o próximo salto. Outra rota para o mesmo destino pode ter sido apresentada por outro roteador. Desta forma o roteador que recebe consegue identificar o roteador que lhe passou o caminho por si escolhido e associá-lo a uma sua interface. Convém não esquecer que cada roteador guarda na tabela de roteamento uma só rota para cada destino.

O caminho entre dois roteadores terminais é feito sempre com roteamento HOP-by-HOP ou SALTO-a-SALTO. O roteamento salto-a-salto é uma das principais características da camada de rede  em contraste com a ligação fim a fim da camada de transporte. Desde que haja consistência entre as tabelas dos roteadores, a entrega salto-a-salto, portanto a entrega ao próximo salto, garante sempre a chegada ao destino. A consistência das tabelas e a defesa contra os loops de roteamento foram algumas das inovações trazidas pelo BGP sobre o anterior.

O nosso objetivo é agora entendermos como é que o roteador de borda A(SA9), relativamente ao qual já entendemos a forma como consegue saber como fazer-nos chegar ao nosso destino, consegue fazer chegar essa informação ao roteador de borda A(SA4), onde se encontra o cliente que solicita uma página ao servidor que está no SA9. Já percebemos que é através do protocolo BGP que o vai fazer, mas para conseguirmos entender bem como é que o BGP faz com que tal aconteça resolvemos juntar um gráfico baseado nas ligações entre SA4 e SA9 da  figura 1 dos artigos anteriores (cuja inserção não vamos repetir aqui), construindo para o mesmo efeito quadros representativos de todos os nós de duas rotas básicas que escolhemos, ilustrando como é que cada um recebe a informação dos seus vizinhos e constrói a sua tabela de roteamento baseado nas mesmas.

Porque esse quadro não cabia numa só figura, encontra-se aqui representado nas figura 1 e 2, que aqui deixamos. Relativamente a estas aconselhamos o mesmo procedimento, isto é a sua abertura em janelas separadas para com as mesmas poderem acompanhar a descrição. Para facilitar a leitura e interpretação dos quadros incluídos nas figuras referidas, juntamos já de seguida uma legenda da tabela de roteamento na figura 3 que descreveremos já de seguida,  após enunciarmos alguns pressupostos que assumimos para a elaboração desses quadros.

Assim, assumimos que só iríamos considerar a construção das tabelas nos roteadores de duas rotas básicas definidas pelo AS-PATH SA4-SA1-SA2-SA3-SA9 e pelo AS-PATH SA4-SA1-SA3-SA9, embora consideremos sempre em cada um desses roteadores a construção do destino para os SA5, SA6 e SA7. Considerámos portanto que os roteadores E1, E2, F2, E3 e F3 (reparem nos novos nomes dos roteadores, de acordo com os novos gráficos) não seriam analisados, contribuindo para o conjunto unicamente com a informação que cada um  fornece sobre o caminho para os SA5, SA6 e SA7. Também os roteadores B2 e C2 não serão considerados na construção das tabelas, tornando para o efeito  o trânsito proibido em cada um dos enlaces que a eles ligam, colocando o custo de cada um dos saltos a 255.

Escolha de uma Rota

Em BGP, cada roteador só permite a existência de uma única rota para cada sub-rede, sendo esta escolhida de entre todas as possíveis que lhe são anunciados pelos seus vizinhos, por um critério que privilegia o custo da rota. Os administradores de rede dos ISP usam a atribuição de custos a enlaces como forma de fazer com que certos percursos sejam privilegiados em relação a outros. Esta é a forma de atribuição de custos a um caminho por aprendizagem com os vizinhos, que vão sucessivamente transmitindo o custo da rota deles até ao destino, sempre por aprendizagem com  os mesmos.

Os custos atribuídos a um enlace vão de 0 a 255, sendo que 255 equivale a um sinal de trânsito proibido. A atribuição de custos aos diferentes enlaces de cada ISP é feita manualmente pelos administradores da rede desse ISP. Parâmetros tais como a fiabilidade e outros critérios de filtragem preestabelecidos serão tidos em conta no estabelecimento destas métricas. Os administradores de rede de um ISP podem também atribuir custos diretos a uma rota num determinado roteador, por forma a que a mesma seja preferencial ou não aceitável. É importante notar que na escolha de uma rota influem questões de política comercial entre os diversos ISP intervenientes na mesma. Este já é um método em que o roteador não aprende através dos outros mas por si próprio, passando assim a ignorar a informação que os  outros lhe fornecem relativamente aos custos.

A melhor rota para um mesmo destino pode diferir de roteador para roteador, dependendo das possibilidades que os seus vizinhos lhe anunciem e da sua opção. O certo é que em cada roteador do percurso a rota escolhida e portanto a que é anunciada, é sempre a melhor das possíveis

• A de menor custo, ou se os custos forem iguais
• A do menor AS-PATH, ou se ainda forem iguais
• A do roteador de 1º salto com o menor custo.

Na construção das tabelas do nosso caso várias destas opções serão verificadas.

A Legenda das Tabelas

Todos os roteadores das zonas de Backbone envolvidos no protocolo eBGP têm conhecimento do melhor caminho para cada um dos SA anunciados ao BGP. No nosso caso os SA  de prestação de serviços que fornecem dados à região de Backbone, na qual já possuem roteadores, são os SA4, SA5, SA6, SA7 e SA9.
Portanto as tabelas de roteamento de todos os nós (roteadores) que serão considerados no nosso trabalho disporão de informação sobre estas áreas nas suas tabelas. Só que, como já dissemos, os caminhos enunciados por cada um deles pode ser diferente, dependendo das regras estabelecidas e dos valores que lhe são comunicados.
Assim, resolvemos afetar cada nó de uma tabelacomo a da Figura 3, em que se verificam duas zonas distintas e várias indicações:

• A zona 4 contendo os valores que lhe são transmitidos por cada um dos vizinhos, agrupados em blocos e com uma etiqueta identificando o vizinho transmissor, dentro de uma zona evidenciada em azul claro.
• A zona 5 contendo os valores pelo mesmo escolhidos de acordo com as regras atrás enunciadas que passa a anunciar a todos os seus vizinhos. Esta zona 5 é aquela que constitui a Tabela de Roteamento desse nó e é representada dentro de uma zona destacada e evidenciada com cores diferentes para cada um dos roteadores no quadro.
• As informações recebidas por um nó e assinaladas com  2 correspondem às que lhe são fornecidas por nós que dispõem de tabelas próprias descritas nos quadros.
• As informações assinaladas com 3 provêm de roteadores que não considerámos para a elaboração das tabelas, intervindo somente com a indicação das redes que se responsabilizam por endereçar.
• As setas assinaladas com 1 indicam o sentido de propagação da informação, isto é, a tabela de roteamento que é levada ao conhecimento dos vizinhos.

Um roteador ignora a informação que lhe é fornecida  por outro e que corresponde àquela que ele próprio forneceu, tendo sido por esse escolhida como a preferencial e como tal incluída na Tabela agora anunciada ao próprio emissor. Esta forma de ciclo repetitivo é fácil de evitar e detetar. Basta verificar que a rota indicada é a mesma que o próprio indicou. Mas a causa efetiva de ciclos repetitivos (loops) infindos resulta de informação que já passou por um roteador de um SA e que volta a esse mesmo SA por outro roteador de borda. Para este efeito, o BGP tem uma propriedade que permite a um roteador rejeitar uma informação que no AS-PATH já inclua o seu próprio SA.

Os campos da Tabela de Roteamento são como segue:

• O  campo6 refere-se ao endereço da sub-rede de destino da rota indicada  nessa linha da tabela.
• O campo 7 indica a interface do roteador que faz parte do enlace que liga ao roteador de 1º salto da rota anunciada.
• O campo 8 indica o AS-PATH da rota anunciada. No caso corrente indica que a informação sobre a rota anunciada foi enviada por um roteador de borda da SA9 um outro do SA3, que por sua vez a fez chegar ao SA2, a qual a passou para o SA em que este roteador se inclui. A identificação da sua SA não faz parte do AS-PATH. O SA ID é incluído no AS-PATH por qualquer SA quando passa a informação a outro. Se  o SA1 fizesse parte deste AS-PATH, estaríamos perante um ciclo repetitivo e então seria descartada, conforme a propriedade já enunciada do BGP.
• O campo 9 identifica o endereço do roteador de 1º salto, que aqui é representado pela sua ID em letra e número. Corresponde ao Gateway presente na interface indicada.
• O campo 10 corresponde ao registo dos saltos efetuados até este roteador. Este elemento não faz habitualmente parte das tabelas de roteamento mas foi por nós incluído para possibilitar um melhor entendimento daquilo que cada roteador vê e anuncia. O critério usado para a sua formação foi idêntico ao usado para os SA, isto é, cada roteador que o transmite insere o seu ID no SALTO-a-SALTO.
• O campo 11 indica o custo total da rota desde este roteador até ao destino.

Análise da Formação das Tabelas de Roteamento

Todos os roteadores envolvidos no roteamento BGP têm conhecimento das mesmas sub-redes e das rotas preferenciais para as mesmas. Só que , para cada um essa rota é diferente.

Como é que o roteador de borda A1 da SA1 toma conhecimento das rotas que o roteador de borda D3 da SA3 anuncia e vice-versa?

A resposta a esta questão está precisamente na forma de construção das Tabelas de Roteamento. Primeiro temos que entender o alcance de tal afirmação. Um roteador de borda de SA de um ISP de nível 2 da Austrália conhece as mesmas sub-redes que um roteador de borda de um SA de um ISP de nível 2 de Portugal. Isto significa que todas as redes anunciadas por roteadores de borda de backbone BGP são conhecidas por todos os roteadores abrangidos pelo mesmo protocolo BGP. O resultado deste facto são tabelas de roteamento com centenas de milhares de entradas, apesar de só serem anunciados endereços de redes, CIDRizados portanto e agregados sempre que possível.

A informação sobre o conhecimento do roteador do ISP de Portugal é passada aos seus vizinhos e assim sucessivamente salto-a-salto até chegar ao roteador do ISP da Austrália. Da mesma forma a informação deste é passada até chegar ao primeiro. Pelo caminho ambas vão recolhendo informações de outros destinos a quem passam também as suas. Quando dizemos que as tabelas de roteamento têm centenas de milhares de entradas, isto significará que há centenas de milhares de informações provenientes de cada roteador para os seus vizinhos que, depois de escolherem as que mais lhes convêm, passam essas mesmas centenas de milhares aos seus vizinhos, mas já sob o seu ponto de vista.

Como se pode perceber, disto resulta uma monstruosa interligação que deve estar equilibrada e estável até dar origem à tabela de cada roteador. Enorme complexidade, sempre dinâmica e em constante atualização. Um roteador que é conectado ou desconectado da rede, uma nova sub-rede que é anunciada, são suficientes para gerar um movimento enorme de informações. Felizmente apenas a informação atualizada é transmitida por cada roteador para os seus vizinhos. Estarão agora a entender a razão de termos limitado o número de roteadores que fazem parte da construção da tabela. Anulámos uns e transferimos para outros a qualidade de roteadores de borda de alguns. Só os roteadores que têm assinaladas as interfaces farão parte da rede que se vai analisar. E mesmo assim foram precisas quatro páginas para alojar a informação resultante de uma forma percetível.

É nosso objetivo perceber como funciona. Para isso nada melhor do que fazer funcionar, mas a uma escala tão reduzida quanto possível, para que a dispersão e a imensidão não conduzam ao efeito contrário. Como já se percebeu, é indiferente por que lado começamos, pois no final todas as tabelas vão ter que estar preenchidas para que a informação esteja completa. Assim sendo, vamos começar pelos dois lados, propagando até ao centro a informação que se vai recolhendo em cada um dos percursos, onde cada um deles transmitirá ao outro a informação que entretanto recolheu. Depois cada um regressa ao seu ponto de partida propagando a nova informação que adquiriu. É precisamente esta divisão que está refletida nos dois quadros da figura 1 (do SA4 ao SA2) e da figura 2 (do SA9 ao SA2). Só que, nos quadros já está refletida a totalidade da informação de cada tabela.

Começamos por atribuir custos a todos os enlaces e numerar as interfaces dos roteadores que vão fazer parte da construção das tabelas de roteamento. Agora vamos olhar para a tabela do roteador A9. Como se pode ver, tal como já se encontra, ele vê nos roteadores vizinhos informação sobre toda a rede e já coloca na sua tabela as rotas que escolhe para todas as sub-redes anunciadas. Mas comecemos por admitir que nada disto lá está. Só a informação que vem das Áreas da sua SA é para já conhecida e vai ser anunciada aos vizinhos C3 e D3. Então há que escrever nos blocos referentes à informação que estes roteadores veem em A9 os seus endereços de rede, mas agora agregados.

Agora, os roteadores C3 e D3 também passam a anunciar a sua rota para A9. Mas C3 vê D3 e D3 vê C3. Então há que preencher nos blocos em que estará a informação por cada um deles visualizada no outro, estas rotas. Mas não será anunciada na tabela, pois ambos já têm uma melhor rota para A9.
De notar que o D3 também vê o E3 e por seu intermédio A7. Então há que registar na devida interface a informação que lhe é fornecida por E3, que é única e definitiva, pois E3 não vai ter tabela. E esta informação deve passar para a tabela de D3 e consequentemente para C3.

Entretanto ambas as informações das tabelas de D3 e C3 passam para os respetivos locais de visualização de G3 e B3. Mas G3 vê B3 , A3, F3 e E3. As informações que os mesmos transmitam serão registadas nos referidos locais e as selecionadas serão registadas na tabela de roteamento.

E assim sucessivamente, sempre rodando toda a informação por todos os vizinhos, corrigindo ou acrescentando os que estão para trás se chega aos roteadores que vão funcionar de fronteira virtual entre os dois caminhos:

• Os que veem de A4, com fronteiras em A2 e C1
• Os que veem de A9 com fronteiras em D2 e B3.

A2 e D2 transmitem as suas informações a F2, recolhem do mesmo as informações transmitidas pelo lado oposto, escolhem a melhor rota para SA6 e propagam as novas informações da mesma forma até A4 e A9 respetivamente. C1 e B3 trocam informações entre si e de seguida propagam-nas da mesma forma até A4 e A9 da mesma forma que o fizeram no sentido contrário.

Não vamos certamente descrever como foi construída toda a tabela passo a passo. Deixamos a estratégia para que o tentem fazer, mas sempre tendo em atenção a necessidade de manter a consistência entre todas as tabelas. Isso significa que cada roteador tem que ver sempre toda a informação dos vizinhos, mesmo que a mesma possa parecer inútil, para no fim tomar a decisão correta. Só mais umas notas.

De notar por exemplo que C1 vê os SA6 e SA5 através de B3 atravessando o SA2, como se pode ver na zona 4 da tabela de construção desse roteador. Basta alterar as métricas de alguns enlaces para que essa possa ser a rota preferencial de C1 para esses SA.

De notar a forma como B1 escolhe o melhor caminho para A7 de entre dois com métricas iguais, precisamente optando por aquele com menor AS-PATH.

De notar que a rota preferencial de B1 para A5 atravessa o SA4. Só após essa rota se ter registado na tabela de A4 e se propagar para B1, este a registou como sua nova rota preferencial para A5, diferente da utilizada até então.

Suponhamos que o ISP da SA1 não tem autorização para atravessar o SA4 com qualquer tráfego que a ele se não destine, talvez porque ainda não negociou tal direito. Então, o seu administrador vai ter que rever as métricas de vários enlaces, por forma a que tal não aconteça, mas sempre tendo em atenção que quaisquer alterações ao propagarem-se poderão provocar outras alterações que a ele não interessem. São todos estes pressupostos e muitos mais, que devem ser tidos em conta ao criar as tabelas de roteamento de uma rede. Evidentemente tais pressupostos não foram tidos em conta no nosso caso de estudo.

Vamos ficar por aqui com a descrição. Ficam os quadros, a legenda e a estratégia. Certamente que ao tentarem entender fazendo algum percurso, esclarecerão muito mais dúvidas do que agora escrevendo muito mais sobre o que já se tornou transparente e legível, pelo que se aconselha uma tentativa.

Entretanto, a informação sobre a rede onde se encontra o servidor procurado, chegou ao roteador de borda do SA onde se encontra o cliente que vai pedir a página.

Dirigida a informação por iBGP até ao roteador de borda da Área do referido cliente, é a mesma levada até ao roteador de Gateway da sua rede pelo protocolo OSPF, conforme a Figura 4. Dispensamo-nos de mais esta descrição, uma vez que a mesma seria idêntica à já feita anteriormente para o percurso inverso.

Vimos como operam as principais funcionalidades da camada de rede, endereçamento e roteamento. Vimos como funciona o protocolo IP, como se constrói o cabeçalho do seu datagrama, como se atribui um endereço e como se encontra o caminho para esse endereço.

Estamos em condições de enviar o datagrama para a camada inferior e ir atrás dele.