Olá galera, tudo bem?
Voltamos com mais um artigo nessa série compartilhando muitas anotações acumuladas durante anos de estudos até passar no CCIE Routing and Switching. Vale lembrar que foram centenas de páginas de cadernos com muitas informações e observações que ainda considero importantes, depois de 15 anos trabalhando com R&S.
O objetivo aqui é ajudar não apenas quem está estudando para certificações, mas no dia-a-dia de outros network engineers, assim como eu, a lidarem com infraestrutura Cisco. Para quem perdeu, seguem os links dos artigos anteriores sobre Switching, PPP e Roteamento IP. Abaixo segue a parte sobre “RIP” e uma lista de comandos “show” básicos.
Estejam a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do conteúdo, incentivo a informar que o conteúdo foi útil aqui na Comunidade Cisco, clicando "útil" ao final do post.
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):
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.
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) -> …
Continue lendo o resto do artigo no link abaixo:
