Minha jornada até o CCIE RS — RIP

Published in

TechRebels

8 min readAug 27, 2018

Este é o quarto artigo da série com anotações acumuladas durante anos de estudos até passar no lab de CCIE RS. Quase 400 páginas de caderno com informações e observações que considerei importantes ao trabalhar com Routing and Switching quase 15 anos.

Acredito que estas informações ajudam não somente a passar em certificações, mas no dia-a-dia de outras pessoas (assim como eu) ao lidar com infraestrutura Cisco.

Para quem não leu os artigos anteriores, seguem os 3 links sobre “Switching”, “PPP” e “IP Routing”. Abaixo segue a parte sobre “RIP” e uma lista de comandos “show” básicos.

Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)

RIP

Protocolo de roteamento IGP que usa distance vector.
UDP 520
RIP não tem visão completa da topologia e só conhece os prefixos divulgados pelos neighbors diretamente conectados. A falta de visão da topologia pode causar problemas, principalmente durante a redistribuição.

OBS: Qualquer protocolo que usa VLSM é essencialmente classless.

RIP v1

Classful — não possui campo de tamanho do prefixo (subnet mask).
Por isso, todas as redes dentro da mesma rede principal precisam usar a mesma mask.
Usa broadcast para updates (todo mundo recebe e processa).

RIP v2

Classless — possui campo para subnet mask (suporta VLSM).
Usa multicast 224.0.0.9 para propagar updates.

RIP é configurado sem número de AS ou qualquer ID, portanto só pode haver um único processo RIP rodando no router.

OBS: Ao usar VRFs, podemos ter um processo RIP por VRF.

OBS: Comando <network> especifica quais interfaces irão participar do processo RIP. Como este comando só aceita redes principais, se quiser habilitar para uma determinada interface enquanto proibimos para outras da mesma rede principal tem que usar passive-interface, filtros, etc… Comando <network> não especifica qual endereço é propagado.

RIP v2 apesar de ser classless, herdou sumarização classful automática por default.

Updates (default):

Envia v1
Escuta v1 e v2

Redes Principais (classes)

0XXX — A
10XX — B
110X — C
1110 — D
1111 — E

VLSM é suportado dentro da mesma rede principal. Atualizações entre as fronteiras das redes principais são resumidas como classful. Isso pode resultar em black holes porque não se sabe exatamente onde estão as redes individuais.

OBS: Não é a tabela de roteamento que realiza load balancing. A RIB apenas apresenta as possibilidades de caminho para o “switching path”, mas cabe ao switching path determinar como será realizado o load-balancing entre esses caminhos.

DOC: Cisco IOS Switching Paths Overview

Distância Administrativa (DA) do RIP pode ser manipulada globalmente, por prefixo ou por neighbor.

RIP encaminha por default as rotas da mesma rede principal que tenham mesma subnet mask da interface ou auto-summary classful das rotas com mask de tamanho diferente da interface.

OBS: uma exceção para RIP v1 é que ele permite propagar rotas host (/32) com tamanho de mask diferente da interface, mas somente dentro da mesma rede principal.

Se utilizarmos redes principais diferentes com auto-summary habilitado (RIPv1 e RIPv2) provavelmente teremos problemas de roteamento. Roteadores receberão múltiplas rotas sumarizadas através de múltiplos neighbors sobre a mesma rede principal. Ex: roteadores podem propagar summary para suas redes loopback, que geralmente pertencem a uma rede principal separada.

Split Horizon

Updates recebidos em uma interface não são encaminhados de volta pela mesma interface.

OBS: Esse comportamento é indesejado em redes partial mash NBMA.

Split horizon é habilitado por default em todas as interfaces exceto em interface principal Frelay.

OBS: Em topologias Hub-and-Spoke sempre tome cuidado porque pode parecer que a rede tem conectividade total, mas uma falha pode interromper a conectividade de forma específica.

Timers

Update — 30 seg
Invalid — 180 seg — mostra “possibly down” na tabela de roteamento
Holddown — 180 seg — durante esse período aceita rotas de mesma métrica ou melhor para evitar loops
Flush — 240 seg — rotas são removidas da tabela de roteamento

Os timers no RIP não precisam concordar entre os neighbors. Timers não são 100% precisos porque o RIP usa jitter. O jitter evita o envio sincronizado das atualizações todas de uma vez através da interface e portanto evita envio sincronizado das atualizações na rede. Em determinados casos os roteadores estão sincronizados e enviam atualizações todos ao mesmo tempo. Por este motivo os tempos são altos (para variar bastante).

Como qualquer protocolo, RIP tem um limite máximo de prefixos por atualização (pacote).

Tipos de Updates

Broadcast
— RIP v1 — default
— RIP v2 — opcional
Multicast
— RIP v2 — default
Unicast
— RIP v1 e v2 — opcional

Para utilizar somente updates unicast é necessário especificar neighbors unicast e habilitar passive-interface, bloqueando multicast e broadcast (checar com <debug ip rip>).

OBS: Lembre-se que RIP por default propaga summaries classful, além das rotas com mesma subnet mask da interface e rotas host.

OBS: Direct-broadcast é desabilitado por questão de segurança. Umas das falhas possíveis é o “Smurf Attack” (https://pt.wikipedia.org/wiki/Ataque_Smurf).

Uma security feature é desabilitar multicast e broadcast em uma interface LAN e habilitar somente updates unicast. Isso garante que os updates não sejam replicados para outras portas LAN baseado na MAC table.

Métricas no RIP

RIP usa métrica de hop-count, contanto 1 hop por interface.
16 hops significa infinito (portanto máximo é 15)
RIP incrementa a métrica quando o router propaga os prefixos outbound.

Offset-list é a maneira do RIP alterar a métrica das rotas. Pode ser usado Inbound ou Outbound, globalmente ou por prefixo. Offset-list tem 2 funções principais:

“Traffic engineering”, manipulando caminhos que o tráfego deve tomar.
Filtrar prefixos ultrapassando 15 hops (16 = infinito).

OBS: Se um router receber rota com 15 hops, ele usará a rota mas irá propagá-la com 16 (infinito).

OBS: “Transient loops” são falhas temporárias devido a “desacordos” entre os roteadores. Sabe aquele período que a gente espera convergir e as métricas não param de mudar?

Offset-list usa ACL standard. Portanto, RIP não consegue distinguir prefixos iguais mas com máscaras de tamanhos de diferentes porque o processo só realiza match na parte do endereço, não da máscara.

Ao manipular rotas, a sugestão é sempre prefix-list (e não ACL), porque prefix-list realiza match no prefixo e na mask ao mesmo tempo.

Autenticação no RIP

RIP suporta autenticação clear text ou MD5.

OBS: Repare na diferença entre Autenticação e Criptografia.

Autenticação é utilizada para validar se as informações de roteamento (payload) vieram do neighbor correto.
Criptografia é utilizada para criptografar o payload no caminho de trânsito.

RIP e EIGRP usam sistema Key Chain, permitindo usar múltiplas senhas entre os neighbors, desde que o mesmo “key number” entre os neighbors.

RIP ignora updates recebidos com autenticação inválida. Neste caso não aparece nem os prefixos no debug, apenas “invalid authentication”.

OBS: Cuidado ao usar question mark (?) quando definir senha porque “espaço” é um caracter. Portanto sempre checar key-chain depois de implementar:

<sh key chain>
<sh run | se key chain> e destacar a senha para checar se há espaços

Sumarização

Pelo menos uma subrede deve estar na RIB database.

Não é possível resumir além da rede principal. Portanto, se tentar resumir diferentes redes principais não adianta nada. Um workaround para esta limitação é criar uma rota estática para o resumo apontando para NULL 0 e redistribuir no RIP.

Um bom modo de testar a sumarização é checar na tabela de roteamento se o destino que se quer sumarizar aponta para o summary. Ex: <sh ip route x.x.x.x> -> mostra que o caminho é através do summary.

Best practice: Sempre ter uma rota igual ao summary que está divulgando apontando para NULL, para evitar loops de roteamento. Ex de loop: rota específica -> summary -> rota default -> rota específica (volta) -> …

Inbound Route Filtering

Pode ser realizado através de:

Distribute-list usando:
— ACL standard
— ACL estendida — neste caso, a “origem” é a origem do update (neighbor) e o “destino” é o prefixo da rota (endereço).
— Prefix-list
Offset-list — usando métrica 16 (infinito)
Distância Administrativa
— DA 255 é infinito
— Pode ser por prefixo e por neighbor

Exemplos de prefix-list

<128.0.0.0/2 ge 16 le 16> — todas as rotas classe B (/16)
<192.0.0.0/3 ge 24 le 24> — todas as rotas classe C (/24)
<128.0.0.0/2 le 32> — qualquer subrede classe B
<0.0.0.0/0 ge 32> — qualquer rota host
<224.0.0.0/4 le 32> — qualquer rota multicast

Sempre usar prefix-list ao trabalhar e manipular roteamento onde o objetivo é realizar match em rotas (control plane).

ACLs padrão ou estendida são usadas para filtrar traffic flow (data plane).

Distribute-list:

Com ACL padrão só faz match no prefixo (não na mask).
Com ACL estendida funciona de forma diferente para BGPs e IGPs:
— Para BGP, origem significa “prefixo” e destino significa “mask”.
— Para IGP, a “origem” é o neighbor de onde veio (chamado “route source”) e o “destino” é o prefixo da rota (endereço).

Na saída <sh ip route x.x.x.x> podemos constatar que no RIP o “next-hop” é o mesmo que “route source”. Para os outros protocolos, estes dois campos podem ser diferentes através do “Routing Descriptor Block”:

“A.A.A.A; from B.B.B.B”

A.A.A.A = next-hop
B.B.B.B = route-source

OBS: O route-source é o “router ID” dos protocolos IGP.

OBS: Sempre que criar ACL, prefix-list, qualquer coisa que seja identificado com NOME ou NÚMERO, cheque antes de criar e evitar sobrescrever alguma configuração já criada.

Distribute-list utilizando prefix-list possui opção específica para definir o prefixo e o “route-source”, e pode ser IN ou OUT.

Outra opção é alterar a DA para 255 (infinito) para um neighbor específico.

RIP possui uma séria limitação para manipular rotas VLSM.

Default Routing

Default-network foi desenvolvido para IGRP, pode ser utilizado com protocolos IGP apontando para uma rede classful que não esteja diretamente conectada. Mas há soluções mais simples.

<default-Information originate> utiliza rota default!!!

OBS: 169.254.0.X é considerado um endereço link-local para IPV4 e portanto não é roteável. Ótimo endereço para usar como “placeholder”.

Conditional Advertisement (Reliable): <default-information originate> pode ser ajustado com route-map para realizar conditional advertisement especificando as interfaces para qual divulgar e/ou basear na disponibilidade de algum prefixo. Neste caso podemos adicionar tracking, garantindo confiabilidade fim-a-fim ao divulgar a rota default. Olha o combo:

IP SLA -> tracking -> Rota Estática (placeholder) -> prefix-list -> Route-map -> Default-information originate… ufa!

Se entender a sequência dos fatos é muito show! Também é muito interessante utilizar a saída de todos os comandos relacionados para explicar:

sh run | in sla|track|route-map|prefix|static|default|router rip

OBS: Um ponto negativo dessa gambiarra toda é que o tempo de convergência ainda é obviamente maior que o de um protocolo dinâmico.

IP RIP Triggered

RIP suporta supressão de updates periódicos (similar ao “OSPF demand circuit”) originalmente criado para linha discada. Neste caso, updates são enviados se ocorrerem mudanças.

Source Validation

Por default, atualizações RIP só são aceitas quando vem de neighbors na mesma subrede da interface que recebeu. Portanto neighbors com subredes diferentes no mesmo link não trocam updates (“ignored update from a bad source”).

OBS: Source-validation não funciona com interfaces “unnumbered” porque a funcionalidade é desabilitada.

Comandos Show para RIP

sh ip int bri | ex una

sh ip route rip

sh ip rip data

sh ip prot

sh key chain

Esse conteúdo de RIP te ajudará no dia-a-dia?

Faltou alguma coisa importante?

Fala pra gente nos comentários?

Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)

Sobre o autor:

Giuliano Barros é Network Consultant & Founder da Control Plane — Network Services.

Graduado em Ciência da Computação, certificado CCIE RS pela Cisco Systems e trabalha há 15 anos em projetos para grandes e médias empresas. linkedin.com/in/giulianobarros