Como o próximo salto é definido na tabela de roteamento?

Question

O que uma tabela de roteamento contém, apenas o endereço da LAN de destino com o próximo salto? Mas o que este próximo salto significa, porque olhando para este exemplo

Não vejo a regra geral de como um próximo salto é definido. (para o destino de rede 10.0.0.0, 11.0.0.0, 13.0.0.0 eu entendo, mas não os outros)

Eu também uso um comando 'ip route add < > src < > via < > , o que deve estar na < & gt ;? Eu uso o Linux Ubuntu como uma máquina virtual no virtualbox

    

Answer 1

Meu palpite é que o erro "resposta do rtnetlink: argumento inválido" é porque o endereço IP, a máscara e o gateway não são da mesma classe (classe A ou B ou C); ou porque um endereço "estático" entra em conflito com alguns intervalos de endereços DHCP.

A tabela para R8 no seu esquema não é uma tabela de roteamento, mas descreve o que R8 fará com endereços. Onde se diz, por exemplo, 10.0.0.0, isto deve ser entendido como significando Segmento de rede 10.0.0.0/24 em vez do endereço IP.

Para sub-redes não acessíveis diretamente a partir da R8, como 16.0.0.0/24, a tabela de roteamento irá direcionar a mensagem para o roteador que é o mais próximo para a rede de destino, e esse roteador passará a mensagem de acordo para sua própria tabela de roteamento. Neste caso, as mensagens endereçadas para 16.0.0.X é passado para o gateway 10.0.0.2, que é o endereço do R7, que os encaminhará para o destinatário certo.

O comando de roteamento executado no R8 deve ser semelhante a:

ip route add 16.0.0.0/24 via 10.0.0.2 src 10.0.0.1

O parâmetro src é usado ao adicionar uma rota a um host com hospedagem múltipla, ter controle sobre o endereço IP de origem do qual seu host está enviando. Pode ser omitido em casos simples. Isso garantirá que a mensagem de retorno retornará através do 10.0.0.0/24 sub-rede, mas outros valores podem ser usados se preferirmos R7, por algum motivo, não devolver a mensagem através dessa sub-rede.

Observe que o src que você está dando afetaria apenas o tráfego originado no seu final. Se um pacote externo está sendo roteado, obviamente ele já teria um endereço IP de origem, então seria normalmente passado inalterado (a menos que usando NAT, e isso também pode ser substituído).

Noto que, em geral, não é necessário fornecer rotas para cada destino. Assim como um computador pode especificar um gateway padrão em seu roteamento tabela, que é um endereço pega-tudo que recebe todas as mensagens para endereços que ele não sabe, o mesmo acontece com um roteador tem sua própria tabela de roteamento que pode conter um gateway. O endereço do gateway do roteador é representado pela rota padrão de 0.0.0.0 .

Observe que é totalmente possível até mesmo configurar um circuito de gateways na rede, por exemplo:
R1 ➝ R4 ➝ R8 ➝ R7 ➝ R6 ➝ R2 ➝ R1.
O número de saltos não está otimizado aqui, mas as mensagens ainda serão obtidas de todos os sub-rede para todas as outras sub-redes. Um bom design de rede normalmente incluirá um ou mais roteadores centralizados, a fim de minimizar o número de saltos.

    

Answer 2

Os outros estão a mais de um salto (roteador) de distância. No que diz respeito ao roteador R8, ele só quer saber a interface a ser usada e o IP do próximo roteador em linha para alcançar a rede de destino, então ele vai para o próximo roteador e esse roteador usa sua própria tabela de roteamento para determinar a próxima pulo. Então, para chegar à rede 15.0.0.0, a tabela de roteamento define a interface 3, que é 13.0.0.4, e o hop é o próximo roteador, que é o 13.0.0.2. Uma vez que o tráfego é recebido por R2, o R2 usará sua própria tabela de roteamento para determinar a melhor rota para a rede 15.0.0.0, que estaria fora da interface 15.0.0.1.

    

Answer 3

Não sei de onde vem sua tabela de design e roteamento. De qualquer forma, em um ambiente como o seu, as rotas para as redes remotas são geralmente definidas através de protocolos de roteamento (isto é, roteamento dinâmico); o uso de rotas estáticas (definidas pelo usuário / admin), com todos os caminhos redundantes que você possui, causará loops de roteamento ou buracos negros eventualmente.

Em outras palavras, cada sub-rede do seu diagrama pode ser acessada através de todas as interfaces do R8, dependendo da configuração dos outros roteadores.

Por exemplo: se você definir a interface 1 de R8 como o próximo salto para 14.0.0.0 (significando que os pacotes destinados a qualquer IP da sub-rede 14.0.0.0/? serão enviados pela interface 1), e se R4 (o próximo salto real fora da interface 1 de R8) tem outra estática de 14.0.0.0 a R1, seu pacote passará por R8- > R4- > R1- > Destino. Por outro lado, se neste exemplo você ainda enviar seu pacote para 14.0.0.0 para R4, mas R4 estiver configurado com uma estática diferente para 14.0.0.0 que aponte para R8, você terá um loop de roteamento e seu pacote irá saltar entre R8 e R4 até que seu TTL expire.

A mesma teoria é aplicável a qualquer outra rede remota como 12.0.0.0, onde é menos óbvio se o R8 deve encaminhar seu pacote para R2 ou R4.

A principal coisa a lembrar é que pacotes IP não têm memória , eles são encaminhados apenas avaliando seu destino (ou seja, roteadores não se preocupam com a interface de onde o pacote foi recebido - a menos que você use coisas como roteamento de origem, mas não é o caso aqui).

A tabela que você postou não mostra se o roteamento estático ou dinâmico é usado (também perde a sub-rede dessas redes), mas a menos que este seja um exercício teórico particular, o roteamento dinâmico é o que você precisa.

O roteamento dinâmico pode definir o melhor caminho de um roteador para uma rede de destino, usando diferentes parâmetros como número de saltos, largura de banda, latência e assim (dependendo do protocolo de roteamento dinâmico específico). Além disso, eles podem gerenciar falhas de links redundantes adequadamente.

Como outro exemplo, se você decidir colocar uma estática para 12.0.0.0 apontando para falhas do roteador R3 e R3, continuará a encaminhar pacotes destinados a 12.0.0.5 (por exemplo) para um buraco negro. Se você decidir balancear a carga para 12.0.0.0 com 2 rotas (com a mesma métrica) através de R3 e R4, se R4 cair (ou uma de suas interfaces estiver quebrada), o R8 continuará a encaminhar o pacote 1 para R3, o pacote 2 a R4, o pacote 3 a R3 e assim por diante. Isto causará coisas aparentemente aleatórias, porque se os pacotes usarem TCP, os perdidos serão retransmitidos, tornando menos óbvio que metade do seu tráfego seja descartado (por exemplo, perda intermitente de linha de alguns serviços, lentidão, etc.).

Se você estiver usando o Linux, o Quagga pode ser o software usado para o roteamento dinâmico, mas a suposição é de que outros roteadores estejam executando um protocolo de roteamento dinâmico.

No entanto, se seu objetivo é definir uma rota estática, esses comandos devem funcionar (estou assumindo / 24, mas se for classful, pode ser um / 8):

ip route add 14.0.0.0/24 dev eth3

mesmo de:

ip route add 14.0.0.0/24 via 13.0.0.2

De qualquer forma, o segundo é geralmente preferido em uma rede multiacesso (sem tráfego multicast / broadcast necessário, sem toneladas de solicitações ARP, etc.).