Contagem de saltos: maneira correta de contar saltos: contagem do roteador vs contagem do roteador +1 [fechado]

1

Estou muito confuso e confuso sobre a definição da contagem de saltos, especialmente relacionado à métrica RIP. A contagem de saltos deve refletir a contagem de links ou a contagem de roteadores? Aqui estão duas possibilidades:

Declaração A:
. contagem de saltos = número de roteadores cruzados
. contagem de saltos para um host na mesma sub-rede = 0
. Métrica RIPv1 = contagem de saltos + 1 (assumindo custo de rede = 1)

Declaração B:
. contagem de saltos = número de roteadores cruzados + 1 . contagem de saltos para um host na mesma sub-rede = 1
. Métrica RIPv1 = contagem de saltos (assumindo custo de rede = 1)

Qual afirmação é verdadeira?

Aqui está a minha topologia de rede:

(192.168.2.0/24) - Roteador2 - (192.168.1.0/24) - Roteador1 - (192.168.0.0/24) - InternetGateway - z -

Parece haver uma ambiguidade na contagem de saltos: número de roteadores cruzados versus número de links usados.

citação do wikipedia: “Em redes de computadores, um salto é uma parte do caminho entre a origem e o destino. Pacotes de dados passam através de roteadores e gateways no caminho. Cada vez que os pacotes são passados para o próximo dispositivo, ocorre um salto. Ver quantos hops são necessários para ir de um host a outro, os comandos ping ou traceroute / tracepath podem ser usados. "

O destinatário final é considerado um 'próximo dispositivo', o que implica um salto?

Aqui está um traceroute local do host 192.168.2.30, através de dois roteadores:

test@ubuntu:~$ sudo traceroute -I 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 60 byte packets
1  192.168.2.1 (192.168.2.1)  0.868 ms  0.831 ms  2.565 ms
2  192.168.1.1 (192.168.1.1)  3.451 ms  3.450 ms  3.438 ms
3  Gateway (192.168.0.1)  5.213 ms  5.219 ms  5.945 ms
test@ubuntu:~$ 

1,2,3 .. é que 3 saltos? O formato traceroute está me intrigando.

mais, aqui está minha tabela de roteamento subnet2 (incluindo entradas RIP):

test@ubuntu:~$ ip -4 route show
default via 192.168.2.1 dev eth0  proto zebra  metric 2 
192.168.0.0/24 via 192.168.2.1 dev eth0  proto zebra  metric 3 
192.168.0.1 via 192.168.2.1 dev eth0  proto zebra  metric 3 
192.168.1.0/24 via 192.168.2.1 dev eth0  proto zebra  metric 2 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.201  metric 1 
192.168.3.0/24 dev eth2  proto kernel  scope link  src 192.168.3.201  metric 1 
test@ubuntu:~$ 

Temos uma métrica 3 para a sub-rede 0 (ou seja, cruzando dois roteadores).

Deste lado, nós temos uma noção de hop count = link-count

Por outro lado, a página da wikipedia exibe uma imagem em linha de dois roteadores com este comentário: "Uma ilustração de saltos em uma rede. A contagem de saltos entre os computadores neste caso é 2."

Mais, ele é vinculado a uma página que afirma claramente que devemos contar os saltos nos roteadores, e não nos links:

Aqui, temos claramente uma noção de contagem de saltos = número de roteadores cruzados.

Qual é a maneira correta de calcular a contagem de saltos? Como isso se relaciona com a métrica do RIP?
  fontes:
link
link

Notas: citações relevantes na RFC 1058 (RIPv1 RFC):

Em redes simples, é comum usar uma métrica que simplesmente conta    quantos gateways uma mensagem deve passar. ...

O principal requisito é que    deve ser possível representar a métrica como uma soma de "custos" para    lúpulo individual.

Formalmente, se é possível obter da entidade i para a entidade j diretamente    (ou seja, sem passar por outro gateway entre), então um custo,    d (i, j) está associado ao salto entre i e j. No normal    caso em que todas as entidades de uma determinada rede são consideradas    mesmo, d (i, j) é o mesmo para todos os destinos em uma determinada rede, e    representa o custo de usar essa rede.

Para obter a métrica de um    rota completa, um só acrescenta os custos do lúpulo individual    que compõem a rota. Para os fins deste memorando, assumimos    que os custos são inteiros positivos.

...

     A-----B
         \   / \
          \ /  |
           C  /    all networks have cost 1, except
           | /     for the direct link from C to D, which
           |/      has cost 10
           D
           |<=== target network

Cada gateway terá uma tabela mostrando uma rota para cada rede.

No entanto, para fins desta ilustração, mostramos apenas as rotas    de cada gateway para a rede marcada na parte inferior do diagrama.

        D:  directly connected, metric 1
        B:  route via D, metric 2
        C:  route via B, metric 3
        A:  route via B, metric 3    

...

A métrica de uma rede é um número inteiro entre 1 e 15    inclusive. Está definido de alguma maneira não especificada neste protocolo.    A maioria das implementações existentes sempre usa uma métrica de 1. ...

Presume-se que cada host que implementa o RIP tenha uma tabela de roteamento.    Esta tabela tem uma entrada para cada destino acessível    através do sistema descrito pelo RIP. Cada entrada contém pelo menos    as seguintes informações:

  - The IP address of the destination.

  - A metric, which represents the total cost of getting a
    datagram from the host to that destination.  This metric is
    the sum of the costs associated with the networks that
    would be traversed in getting to the destination.    

...

A métrica para uma rede conectada diretamente é definida como    custo dessa rede. Em implementações de RIP existentes, 1 é sempre    usado para o custo. Nesse caso, a métrica RIP reduz a um simples    contagem de saltos.

    
por networkIT 12.02.2015 / 17:52

1 resposta

1

Ao citar a Wikipédia, você deve ter percebido essa pista:

To see how many hops it takes to get from one host to another ping or traceroute/tracepath commands can be used.

O traceroute funciona normalmente enviando pacotes UDP, TCP ou ICMP (o que importa é que o protocolo em uso é encapsulado em um datagrama IP e que uma resposta neste mesmo protocolo pode ser entregue no endereço IP de destino) com um O campo TTL no cabeçalho IP é igual a 1 e, em seguida, incrementado por um após cada tentativa até que a resposta recebida seja diferente de um pacote ICMP tipo código 0 11 (tipo ICMP 11 = Tempo excedido , código 0 = TTL expirou em trânsito ).

Isso usa essa parte da RFC 1812:

The Time-to-Live (TTL) field of the IP header is defined to be a
timer limiting the lifetime of a datagram. It is an 8-bit field and
the units are seconds. Each router (or other module) that handles a
packet MUST decrement the TTL by at least one, even if the elapsed
time was much less than a second. Since this is very often the case,
the TTL is effectively a hop count limit on how far a datagram can
propagate through the Internet.

[...]

If the TTL is reduced to zero (or less), the packet MUST be
discarded, and if the destination is not a multicast address the
router MUST send an ICMP Time Exceeded message, Code 0 (TTL Exceeded
in Transit) message to the source

Quase todas as implementações interpretam o decréscimo do TTL em um como diminui o TTL em um e a medida do salto é globalmente considerada como a quantidade de roteadores que você enviou até chegar ao seu destino.

    
por 12.02.2015 / 19:45