Detalhes

Categoria: Como fazer configurações

Atualização: Domingo, 12 Abril 2009 17:01

Autor: vovó Vicki

Acessos: 18341

ip route get

Este comando pega um rota única para um destino e mostra seu conteúdo exatamente como é visto pelo kernel.

ABREVIAÇÕES: get, g

Argumentos

• to ENDEREÇO (default): o endereço de destino.
• from ENDEREÇO: o endereço de origem.
• tos TOS
  dsfield TOS: o Tipo de Serviço (Type Of Service).
• iif NOME: o dispositivo do qual se espera o pacote.
• oif NOME: força o dispositivo de saída através do qual o pacote será roteado.
• connected: se não houver endereço de origem (opção from), reavaliar a rota com o endereço preferido obtido na primeira verificação da origem. Se estiver sendo usada uma política de roteamento, pode ser uma rota diferente.

Observe que esta operação não é equivalente a ip route show. O comando show mostra rotas existentes. Já o get resolve as rotas e cria novos clones se for necessário. Essencialmente, get equivale a enviar um pacote através deste caminho. Se o argumento iif não estiver presente, o kernel cria uma rota de saída para os pacotes na direção do destino requisitado. Isto equivale a fazer um ping no destino com um ip route ls cache subsequente, só que nenhum pacote é enviado. Com o argumento iif, o kernel simula que um pacote tenha chegado vindo desta interface e procura um caminho para redespachar o pacote.

O formato de saída deste comando é o mesmo do ip route ls.

Exemplos

Encontrar uma rota para redespachar pacotes para 193.233.7.82:

kuznet@amber:~ $ ip route get 193.233.7.82
193.233.7.82 dev eth0  src 193.233.7.65 realms inr.ac
    cache  mtu 1500 rtt 300
kuznet@amber:~ $

Encontrar uma rota para redespachar pacotes que chegam na eth0 de 193.233.7.82 e destinados para 193.233.7.82:

kuznet@amber:~ $ ip r g 193.233.7.82 from 193.233.7.82 iif eth0
193.233.7.82 from 193.233.7.82 dev eth0  src 193.233.7.65 \
  realms inr.ac/inr.ac 
    cache   mtu 1500 rtt 300 iif eth0
kuznet@amber:~ $

Este é o comando que criou a rota estranha de 193.233.7.82 com loop back para 193.233.7.82. Note a flag de redirecionamento.

Achar uma rota multicast para pacotes que chegam na eth0 do host 193.233.7.82 destinados para o grupo multicast 224.2.127.254 (um daemon de roteamento multicast precisa estar rodando. Neste caso é o pimd).

kuznet@amber:~ $ ip r g 224.2.127.254 from 193.233.7.82 iif eth0
multicast 224.2.127.254 from 193.233.7.82 dev lo  \
  src 193.233.7.65 realms inr.ac/cosmos 
    cache  iif eth0 Oifs: eth1 pimreg
kuznet@amber:~ $

Esta rota é diferente das vistas até agora. Ela possui uma parte "normal" e uma "multicast". A parte normal é usada para entregar (ou para não entregar) o pacote para ouvintes IP locais. Neste caso o roteador não é um membro deste grupo, de modo que a rota não tem uma flag local e apenas redespacha pacotes. O dispositivo de saída para registros deste tipo é sempre loopback. A parte multicast consiste de Oifs adicionais: listar mostrando as interfaces de saída.

Está na hora de um exemplo mais complicado. Vamos adicionar uma rota de gateway inválida para um destino que está realmente conectado diretamente

netadm@alisa:~ # ip route add 193.233.7.98 via 193.233.7.254
netadm@alisa:~ # ip route get 193.233.7.98
193.233.7.98 via 193.233.7.254 dev eth0  src 193.233.7.90
    cache  mtu 1500 rtt 3072
netadm@alisa:~ #

e testá-la com um ping:

netadm@alisa:~ # ping -n 193.233.7.98
PING 193.233.7.98 (193.233.7.98) from 193.233.7.90 : 56 data bytes
From 193.233.7.254: Redirect Host(New nexthop: 193.233.7.98)
64 bytes from 193.233.7.98: icmp_seq=0 ttl=255 time=3.5 ms
From 193.233.7.254: Redirect Host(New nexthop: 193.233.7.98)
64 bytes from 193.233.7.98: icmp_seq=1 ttl=255 time=2.2 ms
64 bytes from 193.233.7.98: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 193.233.7.98: icmp_seq=3 ttl=255 time=0.4 ms
64 bytes from 193.233.7.98: icmp_seq=4 ttl=255 time=0.4 ms
^C
--- 193.233.7.98 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.4/1.3/3.5 ms
netadm@alisa:~ #

O que foi que aconteceu? O roteador 193.233.7.254 entendeu que temos um caminho muito melhor para o destino e nos enviou uma mensagem ICMP de redirecionamento. Agora podemos tentar novamente um ip route para ver o que há nas tabelas de roteamento:

netadm@alisa:~ # ip route get 193.233.7.98
193.233.7.98 dev eth0  src 193.233.7.90 
    cache   mtu 1500 rtt 3072
netadm@alisa:~ #