WAN com Frame-Relays no CCNA

Continuando com a explanação acerca dos objetivos e sobre a forma como as questões são cobertas na avaliação CCNA, irei mostrar alguns exemplos parecidos com os da prova. Pra começar, na questão abaixo, vemos um tema recorrente nos últimos exames, que são aqueles assuntos envolvendo WAN e redes Frame-Relay:

From the network configuration below, both the Matriz and Filial offices are configured as shown below:

Matriz# show running-config
Filial# show running-config



interface Serial0/0 interface Serial0/0
ip address 10.0.8.1 255.255.248.0 ip address 10.0.15.2 255.255.248.0
encapsulation frame-relay encapsulation frame-relay
frame-relay map ip 10.0.15.2 200 frame-relay map ip 10.0.8.1 100
! !
router rip router rip
network 10.0.0.0 network 10.0.0.0

The Filial router can be successfully pinged from the Matriz office, but the Filial users can't access the server at the Matriz office.
Based on the output above, what do you suspect is the cause of this problem?

A. The Frame Relay PVC is down.
B. The IP addressing on the Central/Remote serial link is incorrect.
C. RIP routing information is not being forwarded.
D. Frame Relay inverse-ARP is not properly configured.

Como muitas das questões encontradas no exame, é comum o uso da técnica de eliminar as alternativas menos prováveis (ou absurdas) primeiro. Avaliando as alternativas na ordem, vemos as letras A e B não se configuram como causas para o problema citado na questão, uma vez que, de acordo como o enunciado, é possível obter resultados positivos com as respostas aos pacotes ICMP enviados pelo utilitário "ping". Do suposto no enunciado, está estabelecida sim uma PVC, e as interfaces estão todas funcionando a contento (caso contrário, seriam obtidas mensagens do tipo "Host Unreachable" na resposta ao ping).
A alternativa D refere-se a um recurso chamado Inverse Address Resolution ProtocolIARP) (, que é usado para estabelecer, dinamicamente, números DLCI a endereços IP de interfaces no roteador que serve de ponta a Permanent Virtual Connections (PVCs). Com o IARP, se torna desnecessário estabelecer rotas estáticas para os canais Frame-Relay, mas da leitura do resultado do comando show running-config, vemos que é feito o uso de comandos "frame-relay map", que fazem exatamente a mesma coisa, só que de forma estática. Por não depender do IARP, a afirmativa contida na alternativa D também não explica o mal-funcionamento da rede.
Da remoção das 3 outras alternativas, a alternativa C aponta como a única correta. Revendo a situação proposta, percebemos que as interfaces em questão não estão permitindo broadcast/multicast, o que invalida a atuação do algoritmo RIP de roteamento, uma vez que ele usa de endereços broadcast, na versão 1 do protocolo, e endereços do tipo multicast, na versão 2. O protocolo RIP faz uso de broadcast/multicast para gerar as relações de vizinhança com roteadores próximos, e assim criar a sua topologia de roteamento. E Frame-Relay, por padrão, não repassa broadcasts. Bastaria acrescentar-se a opção broadcast ao comando frame-relay map para se corrigir o defeito de roteamento.