Annotate your routing output
============================

Commands
========
    - netq resolve [vrf <vrf>] [around <time>] [json]

Usage
=====
netq can be used to provide insight into mapping interfaces to IPv4 and
IPv6 addresses. By piping any output into netq resolve the output can
be enhanced.

Take for example this normal routing table output:

     cumulus@leaf03:~$ ip route show
     10.1.20.0/24 via 169.254.0.1 dev swp52  proto bgp  metric 20 onlink
     10.3.20.0/24 dev bridge.20  proto kernel  scope link  src 10.3.20.253
     10.254.0.7 via 169.254.0.1 dev swp52  proto bgp  metric 20 onlink

By piping it into netq resolve, the interfaces are now mapped to the
addresses, providing insight into where each of the routes are originated.

     cumulus@leaf03:~$ ip route show | netq resolve
     10.1.20.0/24 (leaf02:bridge.20) via 169.254.0.1 dev swp52  proto bgp  metric 20 onlink
     10.3.20.0/24 (leaf03:bridge.20) dev bridge.20  proto kernel  scope link  src 10.3.20.253 (leaf03:bridge.20)

netq resolve can also be used to get a more intelligent traceroute.

     cumulus@torc-12:mgmt-vrf:~$ traceroute 27.0.0.21 | netq resolve
     traceroute to 27.0.0.21 (tor-1:lo), 30 hops max, 60 byte packets
     1  27.0.0.20 (spine-3:swp4)  0.404 ms  0.364 ms  0.355 ms
     2  27.0.0.21 (tor-1:lo)  0.841 ms  0.888 ms  0.894 ms
     Path MTU is 9202
     cumulus@torc-12:mgmt-vrf:~$

In the presence of unnumbered interfaces, we get the next hop
switch name and the egress interface to nexthop. Path MTU checking
is also done in this mode. As long as the ingress and egress interfaces
have a matching MTU, the intermediate interfaces can have a larger
MTU than the first hop interface. This helps cases such as VXLAN where the
end host links have a lower MTU than the inter-switch links to account for
the VXLAN header added by the switch VTEP.
