RIP Troubleshooting

Continuando na linha dos enunciados que abranjam o maior número de conceitos, temos essa questão, que apresenta pontos importantes e que costuma marcar presença nas seções da prova CCNA relacionadas a troubleshooting e protocolos de roteamento:

“Which of the following is true regarding the following output? (Choose two.)

04:06:16: RIP: received v1 update from 192.168.40.2 on Serial0/1

04:06:16: 192.168.50.0 in 16 hops (inaccessible)

04:06:40: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (192.168.30.1)

04:06:40: RIP: build update entries

04:06:40: network 192.168.20.0 metric 1

04:06:40: network 192.168.40.0 metric 1

04:06:40: network 192.168.50.0 metric 16

04:06:40: RIP: sending v1 update to 255.255.255.255 via Serial0/1 (192.168.40.1)

A. There are three interfaces on the router participating in this update.

B. A ping to 192.168.50.1 will be successful.

C. There are at least two routers exchanging information.

D. A ping to 192.168.40.2 will be successful.”

Um ponto que merece destaque nessa questão é procurar listar o que ela quer que você saiba, a partir da situação exposta. Na assertiva A, o que ela procura saber sobre a quantidade de interfaces de rede. As assertivas B e D, sobre a conectividade com as redes 192.168.40.0 e 192.168.50.0, ou melhor, se pacotes ICMP “ping” podem ser enviados e recebidos com sucesso para essas redes. A letra D pede o número mínimo de roteadores na transação acima.

Para saber exatamente quantas interfaces estão participando no cenário acima, é útil olhar cuidadosamente nos trechos do log que mencionam atualizações (updates) de tabelas de roteamento RIP, saindo do roteador atual para o mundo externo. As linhas 3 e 8, do log em negrito, anunciam envios (sending) para atualização de tabelas de rotas, que passam respectivamente, “via FastEthernet0/0” e “via Serial0/1”. Como não existem mais mensagens desse tipo (“sending v1 update”), do acima exposto podemos deduzir que apenas 2 interfaces de rede são apresentadas. A assertiva A é falsa, pois alega um mínimo de 3 (o mínimo é 2).

Dos questionamentos sobre o número de interfaces no roteador, partimos para a quantidade de roteadores que participam das mensagens de debug do RIP, anunciando e/ou recebendo rotas novas. Se mensagens do tipo “sending v1 update” nos ajudaram a encontrar as interfaces de rede, as mensagens “received...” vão nos dizer quais (e principalmente quantos) roteadores participam do handshake do RIP pra estabelecimento dinâmico de rotas, uma vez que apenas roteadores podem anunciar e atualizar rotas. Do parágrafo anterior, vemos que esse roteador anuncia (mensagens “sending...”) através de 2 interfaces (Serial0/1 e FastEthernet0/0), e recebe uma atualização de rotas através da Serial0/1 (do roteador 192.168.40.2). Temos 2 roteadores, um que é o roteador local (a partir do qual temos acesso à mensagem de log), e outro que emite uma mensagem de anúncio de rotas (192.168.40.2, via interface Serial0/1). A letra C está certa.

Restam-nos as letras B e D. As linhas 2 e 7 nos dizem a mesma coisa, ou seja, que a rota para a rede 192.168.50.0 é “alcançada” após 16 hops, e portanto inalcançável (linha 2). A linha 7 nos descreve que essa mesma rede tem métrica 16, o que significa a mesma coisa, em vista do fato de que o RIP tem métrica máxima de 15, para rotas possíveis e roteáveis. Métrica 16 é rota inacessível, desligada pelo administrador ou “envenenada” pelo próprio algoritmo do RIP, para evitar anúncios de circulares de rotas impossíveis (estratégia conhecida como “poisonous routing”, envenena a rota e anuncia ela desse jeito, para que as outras redes a enxerguem como proibida e assim evitar que outros roteadores na área administrativa anunciem essa rota inválida a outros roteadores). Como esse host 192.168.50.1 faz parte da rede 192.168.50.0, e como essa rede é métrica 16, um ping para esse host retornaria uma mensagem de inalcançável. Letra “B” está errada.

A letra D quer saber se um ping para o host 192.168.40.2 pode ser alcançável, e a resposta é sim, e temos 2 evidências para garantir isso: primeiro, que na linha 6 vemos que quando o roteador vai construir as entradas da tabela de roteamento, momento no qual algumas rotas dinâmicas externas são reconhecidas e acrescentadas, a rota para a rede 192.168.40.0 apresenta-se com métrica 1 – isso quer dizer que a rota para essa rede passará primeiro pelo “next hop router”, ou seja, o roteador vizinho, conectado pela interface Serial0/1. Uma métrica ótima, que perde apenas para as métricas de rotas estáticas e para as diretamente conectadas (as com flag “S” e as com métrica 0, respectivamente). Isso serviria para garantir que a rede 192.168.40.0 é acessível, mas não que um ping para o host 192.168.40.2 pode ser realizado com sucesso. Contudo, a primeira linha de log nos garante isso, porque o anúncio da tabela de rotas para essa rede veio exatamente do roteador de endereço IP 192.168.40.2. Uma coisa legal com roteamento dinâmico é que as rotas são configuradas nas 2 direções, e se recebemos uma mensagem de 192.168.40.2, certamente que poderemos enviar mensagens para lá também (a menos que uma ACL tenha sido colocada de barreira, impedindo tráfego ICMP de saída no roteador conectado à S0/1). A letra D está correta também.

Respostas: C e D

Sub-redes e Roteadores

Uma questão do exame CCNA muito interessante, que resume muitos dos conceitos sobre as funções básicas dos dispositivos de roteamento e segmentação em sub-redes:

“A router receives a packet on interface 172.16.45.66/26. The source IP of the packet is 172.16.45.127/26 and the destination is 172.16.46.191/26. How will the router handle the packet?

A. The destination is a host on another subnet, so the router will not forward the packet.

B. The destination is a host on the same subnet, so the router will forward the packet.

C. The destination is a broadcast address, so the router will not forward the packet.

D. The destination is a network address, so the router will forward the packet.”

A princípio, percebemos que todos os endereços IP são /26, ou seja, os 2 bits iniciais do quarto octeto são usados para identificação de sub-redes (24 < 26 < 32, ou seja, quarto octeto), e os 6 restantes são usados para host, o que nos dá um total de 4 sub-redes (2 bits de rede, elevado a 2) e 62 hosts (contando os endereços reservados para a base da rede, e para o broadcast da respectiva sub-rede, teríamos um total de 64). Como o número de sub-redes é bastante restrito, convêm que listemos cada um desses intervalos, para averiguarmos as condições de chegada desse pacote:

172.16.46.0 à 172.16.46.63 (0-63)

172.16.46.64 à 172.16.46.127 (64-127)

172.16.46.128 à 172.16.46.191 (128-191)

172.16.46.192 à 172.16.46.255 (192-255)

A matemática básica para a enumeração desses intervalos de sub-redes é simples: basta obter o comprimento de cada intervalo, calculando o espaço reservado para os hosts no endereço base acima: ou seja, 6 bits denotam um espaço de representação de 64, então a primeira sub-rede iniciará no IP terminado em 0, e terminará no IP terminado em 63 (63 – 0 + 1 = total de 64). O endereço inicial da próxima sub-rede será o último endereço válido para a sub-rede antecedente mais 1, ou melhor, 172.16.46.64 (63 + 1), e o endereço final será 64 (endereço inicial) mais o número de hosts nesse intervalo (64, igual para todas as sub-redes), menos 1, porque começamos a numeração com 0, desde o primeiro subintervalo. E assim, prossegue-se até que todos os intervalos tenham sido listados.

A partir da lista de sub-redes que fizemos, percebemos que o endereço de destino 172.16.46.191 é um endereço de broadcast. O endereço de broadcast será sempre o último numa dada sub-rede (por isso mesmo, não contabilizamos esse endereço na atribuição de um host válido dentro de uma determinada sub-rede – ele será sempre reservado para broadcast). Ora, temos que os roteadores segmentam as redes em domínios de broadcast, e por isso, não perpetuam pacotes incidentes em suas portas que tenham um endereço de broadcast como destino (popularmente falando, endereços de broadcast não são roteáveis). A letra C é a resposta.

Uma observação: veja que o endereço fonte do pacote direcionado pelo roteador, pertence à mesma sub-rede da interface do roteador, ou seja, a sub-rede de 172.16.46.64 até 172.19.46.127 ( 64 < 66 < 127 ). O que aconteceria se isso não fosse verdadeiro, se o endereço fonte estivesse em um segmento de rede divergente da que a interface do roteador pertença?

Segmentação em Sub-redes

Uma matéria comum às questões do exame CCNA, refere-se aos cálculos de sub-rede. A maior parte das questões não obriga a realização de cálculos extensivos, mas envolvem prática com as regras de segmentações em sub-redes, saber discernir entre endereços de escopo privado e público, bem como ter alguma noção do sistema de numeração binário. Ainda, noções básicas sobre Teoria dos Números, principalmente no que diz respeito à divisibilidade, pode ser bastante útil (mas não imprescindível).

Na questão abaixo, apresenta-se um endereço IP válido e pede-se qual a sub-rede que envolve o endereço dado:

“What is the subnet address of the host with an IP address of 172.16.159.159/22?

A. 172.16.128.0

B. 172.16.156.0

C. 172.16.159.128

D. 172.16.159.0

E. 172.16.192.0

F. 172.16.0.0”

A princípio, percebemos que só serão válidos endereços de sub-rede nas assertivas acima que se refiram à classe B – por ser um endereço de rede /22, e sendo 22 maior que 16 (segundo octeto) e menor que 24 (que se referiria ao quarto octeto), decorre disso que foi expandido o espaço de 16 bits de rede originais da classe B, para 22 bits de rede. Ou seja, com 6 bits (22 – 16) mascarados no terceiro octeto destinados a identificação de sub-redes, e com 10 bits (32 – 22) restantes para referência a host, deduz-se facilmente que são permitidas 64 sub-redes nessa configuração, com 1022 (2 elevado a 10, menos 2) hosts possíveis em cada uma das sub-redes (elimina-se 2 do total de hosts, simplesmente porque um dos endereços é para identificar a própria sub-rede, e o outro endereço não contabilizado como host é o endereço de broadcast, também único para cada sub-rede).

Voltando ao que é necessário ao enunciado, precisamos saber qual sub-rede engloba o host referido. A máscara de rede é de classe B, mas com 2 bits mascarados para host no terceiro octeto, mais 8 desses bits no quarto e último octeto. Esses 2 bits do terceiro octeto são pertinentes para nossa solução, porque são exatamente eles que conferirão mobilidade para a quantidade de sub-redes, por conta do seguinte: 6 bits do terceiro octeto podem variar indistintamente, mas os outros 2 bits são fixos, ou invariáveis, no que se refere à numeração de sub-redes, porque esses 2 bits se referem a hosts, e não são contabilizados na seqüência de sub-redes disponíveis. Isso significa dizer que, sempre que formos atribuir uma sub-rede válida a essa máscara, devemos notar que os 6 bits denotam livremente uma sub-rede, mas os 2 bits do terceiro octeto não podem ser “invadidos” pelos bits de sub-rede (pois pertencem a hosts). Essa é a lógica na criação de sub-redes: alguns bits válidos da seção original de host são desperdiçados para que possam então ser criadas mais sub-redes, e facilitar a segmentação dos hosts, o que traz diversas vantagens, como a departamentalização da rede e o incremento em segurança, por exemplo. No nosso caso, com uma máscara de classe B, teríamos 16 bits para rede, e 16 bits para host: em alguns casos, 16 bits para os hosts pode ser demasiado, portanto alguns desses bits poderiam ser usados para segmentação de redes (no nosso caso, expandimos para mais 6 bits de sub-redes). Por exemplo, a seqüência a seguir compõe-se de sub-redes válidas para a máscara /22 (255.255.252.0): 172.16.148.0, 172.16.152.0, 172.16.156, e assim por diante, sempre de 4 em 4, por conta dos 2 bits de host que são invariáveis, exclusivamente no que diz respeito à numeração de sub-redes.

Já que o terceiro octeto dos endereços de sub-rede que fazem parte da rede 172.16.0.0 denota parte da sub-rede, com 6 bits, e parte do host, com 2 bits, a faixa de endereços disponíveis para sub-redes inicia-se em 0 no terceiro octeto, e vai saltando de 4 em 4 (por conta do total de combinações dos 2 bits reservados para hosts). A faixa de endereços válidos é então: 172.16.0.0, 172.16.4.0, 172.16.8.0, 172.16.12.0, ..., 172.16.252.0 (num total de 64 sub-redes). Dessas 64 sub-redes, apenas uma delas engloba o endereço 172.16.159.159. Para que a encontremos, teremos que encontrar o primeiro número inteiro menor do que 159, e que seja divisível por 4. Aplicando esse processo na prática, pegamos o número 159 (terceiro octeto, que nos interessa), e dividimos por 4 – daí, vemos que dessa divisão decorre um número fracionário (39,75), ou seja, retorna resto, portanto, não divisível por 4. Passamos então para o número imediatamente anterior (158), dividimos por 4, o que nos dá 39,5, que também não é o que queremos. Continuando nesse processo, percebemos que 156 divide 4 (sem resto). E é exatamente essa a resposta: 172.16.156.0, a sub-rede referente ao endereço de host 172.16.159.159 (/22). Resposta: letra “B”.

Mais um assunto típico de prova, mas que do ponto de vista do dia-a-dia do profissional de redes, implica na maior parte apenas curiosidade típica de “hackers”, que se interessem por saber a qual sub-rede pertença um dado host – um gerente de redes competente mantém sempre uma documento com as faixas de sub-redes configuradas. Mas, é lógico, automatizar mentalmente o cálculo de faixas de redes é sempre uma ajuda...