CCNA / WANs

Questão CCNA sobre “Wide Area Networks” (WAN):

“Why won’t the serial link between the Corp router and the Remote router come up?

Corp#sh int s0/0

Serial0/0 is up, line protocol is down

Hardware is PowerQUICC Serial

Internet address is 10.0.1.1/24

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 254/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Remote#sh int s0/0

Serial0/0 is up, line protocol is down

Hardware is PowerQUICC Serial

Internet address is 10.0.1.2/24

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 254/255, txload 1/255, rxload 1/255

Encapsulation HDLC, loopback not set

A. The serial cable is faulty.

B. The IP addresses are not in the same subnet.

C. The subnet masks are not correct.

D. The keepalive settings are not correct.

E. The layer 2 frame types are not compatible.”

Avaliando cada um dos itens, temos que a letra “A” não pode ser verdadeira porque, se assim o fosse, a mensagem após o comando “sh int s0/0” (ou melhor, “show interface serial0/0”) indicaria que a interface Serial0/0 estaria “down” e não “up” (“Serial0/0 is up”). Tal informação indicaria uma falha física, como um cabo serial desconectado ou com defeito – contudo as coisas parecem funcionar na linha física serial. Apenas após a vírgula vemos algo mais esclarecedor; há uma mensagem indicativa dizendo “line protocol is down”. O protocolo estar não-funcional, mas a linha serial estar perfeita, nos faz levantar 2 hipóteses possíveis: se estivéssemos trabalhando com mecanismos de roteamento dinâmico, divergências em parâmetros de sincronização do tipo “Dead timers” (como os encontrados no RIP e no EIGRP) que especificam o tempo em que uma mensagem permanece válida até ser automaticamente descartada dentro do tempo determinado (estratégia usada para evitar loops de roteamento), poderia causar problemas de comunicação e gerar mensagens de “protocol is down”; caso não estejamos lidando com algoritmos de roteamento, inúmeros utilitários do Cisco IOS poderiam ser úteis aqui, mas das telas podemos deduzir de forma direta o que pode estar ocorrendo de ruim...

Acontece que os protocolos PPP e HDLC não são inteiramente compatíveis. Para não conhecedores das plataformas Cisco, isso pode parecer um contra-senso, porque o protocolo PPP prevê o uso do HDLC para encapsular datagramas sobre linhas seriais. Acontece que o HDLC ao qual a listagem acima se refere diz respeito a uma versão proprietária do High-Level Data Link Control, que funciona com um formato diferente de frame HDLC, incluindo um campo a mais chamado “Proprietary”. Esse belo fruto da inovação Cisco é incompatível com o padrão ISO HDLC, e acaso você queira interligar roteadores de diferentes fabricantes, vai ser melhor optar por um formato padrão de encapsulamento como o PPP.

Voltando ao mostrado no enunciado, e do acima exposto, temos que os roteadores acima estão utilizando formatos diferentes e incompatíveis de roteamento: HDLC no roteador Remote, e PPP no roteador Corp. Trocar o formato de um ou de outro já resolveria o problema, e portanto a letra “E” esclarece exatamente a razão do problema, porque ambos HDLC e PPP são protocolos de enlace de dados, ou seja, de camada 2 (layer 2).

Access Control Lists - ACLs

Tópicos que tem ocorrido com mais freqüência são aqueles relacionados com segurança, apesar de ser um assunto mais freqüente em exames mais avançados como o CCNP e o CCIE. Na questão abaixo, um exemplo básico com Access Control Lists (ACLs), retirado do livro “CCNA Study Guide, Sixth Edition”, do Todd Lammle:

“You configure the following access list:

access-list 110 deny tcp 10.1.1.128 0.0.0.63 any eq smtp

access-list 110 deny tcp any eq 23

int ethernet 0

ip access-group 110 out

What will the result of this access list be?

A. Email and Telnet will be allowed out E0.

B. Email and Telnet will be allowed in E0.

C. Everything but email and Telnet will be allowed out E0.

D. No IP traffic will be allowed out E0.”

Na questão, uma lista de comandos do roteador é apresentada, e pede-se o resultado da execução de tal lista num roteador hipotético. Aqui deve-se ter sempre em mente uma interpretação recorrente nas provas da Cisco: que o que não constar da relação de comandos, presume-se que foi omisso. Ou melhor, a lista de comandos começa exatamente com a primeira sentença de “access-list ...”, e termina com “ip access-group 110 out”. O trecho então não é parte de uma entrada do administrador de rede, mas sim uma sequência completa e indivisível de comandos.

Os comandos de access-lists na questão acima são no formato “extended”, ou seja, são no formato que começa com a definição da ação (“deny” ou “permit”), o intervalo de hosts de origem, o intervalo de hosts destino e, possivelmente, condições que especificam em que porta a restrição vai se impor. As listas extended são numeradas com identificadores de 100 a 199, e com elas é possível filtrar pacotes por campos IP de camada 3 e até alguns serviços de camada 4 ou maior (WWW, Telnet, SMTP, etc.), o que amplia o espectro de usos possíveis para as ACLs, como por exemplo mitigar ataques Denial-of-Service (DoS), DoS Smurfs, IP Spoofing, etc. É possível estabelecer regras que serão aplicadas especificamente a pacotes TCP com a flag SYN setada, por exemplo, o que serve de ajuda contra ataques de SYN flood. Certo, apenas “mitigar”, não necessariamente impedir tais ataques, dada a dificuldade em definir regras sobre grupos de pacotes suspeitos num universo tão grande de possibilidades de ataques. Mas a utilidade das ACLs ainda assim é muito bem vinda e quebra alguns galhos.

Quando é preciso definir regras que se apliquem a apenas um par de hosts, como a sentença “access-list 110 deny ip host 172.16.10.3 host 172.16.20.5”, por exemplo, que bloqueia pacotes IP com campo de origem 172.16.10.3 e destino para 172.16.20.5, a tarefa é imediata. Contudo, é mais comum, na definição das regras de ACLs, quando é necessário que sejam aplicadas regras a um intervalo de hosts numa sub-rede, pode-se recorrer aos wildcards. Vamos dizer que queiramos aplicar determinada regra ao conjunto de hosts nas sub-redes de 192.168.113.0 até 192.168.140.0. Primeiro, calcule quantas sub-redes existem entre os endereços anteriores; diminuindo 113 de 140 (140 – 113), obtemos 27. Agora é preciso achar uma potência de 2 que seja maior ou igual a esse intervalo; temos que 32 é maior que 27 (16 é outra potência de 2, mas é menor que 27), e portanto nos serve para esse propósito. Esse valor é 32 é o tamanho do bloco, e quando diminuído de 1, nos traz o endereço de wildcard. Nesse caso, temos que o endereço de wildcard para esse intervalo é 0.0.31.255. O terceiro octeto, que guarda informações das sub-redes onde serão aplicadas a regra de ACL, tem valor 31, representado um bloco de 32 (192.168.113.0 até 192.168.145.0). Esse intervalo é maior do que o que o intervalo que queremos, mas serve ao propósito. O quarto octeto contêm um valor de 255, que permite a presença de qualquer valor, e nos garante que todos os hosts nessas sub-redes sejam também contemplados com a regra ACL.

De volta à questão, a primeira sentença aplica a regra de que será descartado qualquer pacote SMTP (porta 25) com origem em quaisquer dos hosts em 10.1.1.128 até 10.1.1.192 (wildcard = 0.0.0.63, bloco igual a 64). A segunda regra descarta todos os pacotes com destino ao serviço de Telnet (porta 23). Logo a seguir, essas 2 regras são aplicadas à interface E0 (ethernet0) para saída (“out”), ou seja, em “post-routing”, após o pacote ter sido roteado localmente no roteador e estar prestes a ser encaminhado para a interface de saída, as regras são aplicadas. A princípio, até aí tudo bem, temos 2 regras, uma que nega totalmente serviços para a porta 23, e outra que nega serviço SMTP (porta 25) para um conjunto de hosts. A alternativa C parece convidativa, mas algo vai errado na lista de acesso: se era esse o fim almejado pelo administrador (negar pacotes para serviços portas 23 e 25), ele deveria ter incluído a regra “permit ip any” no final da lista de acesso, porque a última regra é “deny ip any”, o que faria com que qualquer pacote tivesse o repasse concedido pela interface ethernet0. Devido à omissão dele, a interface E0 vai perder comunicação com o mundo. Alternativa D é a correta.