Examples:

• Find a route to output packets to 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:~ $
  

• Find a route to forward packets arriving on eth0 from 193.233.7.82 and destined for 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 <src-direct,redirect>  mtu 1500 rtt 300 iif eth0
  kuznet@amber:~ $
  

  1cm NB. This is the command that created the funny route from 193.233.7.82 looped back to 193.233.7.82 (cf. NB on p.). Note the redirect flag on it.

• Find a multicast route for packets arriving on eth0 from host 193.233.7.82 and destined for multicast group 224.2.127.254 (it is assumed that a multicast routing daemon is running. In this case, it is 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 <mc> iif eth0 Oifs: eth1 pimreg
  kuznet@amber:~ $
  

  This route differs from the ones seen before. It contains a ``normal'' part and a ``multicast'' part. The normal part is used to deliver (or not to deliver) the packet to local IP listeners. In this case the router is not a member of this group, so that route has no local flag and only forwards packets. The output device for such entries is always loopback. The multicast part consists of an additional Oifs: list showing the output interfaces.

It is time for a more complicated example. Let us add an invalid gatewayed route for a destination which is really directly connected:

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:~ #

and probe it with 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:~ #

What happened? Router 193.233.7.254 understood that we have a much better path to the destination and sent us an ICMP redirect message. We may retry ip route get to see what we have in the routing tables now:

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