anchor.diff:  * *External Machine:* Traffic is going from a local pod outside the cluster (1 to 3)
   * *Local Docker:* Traffic is going from a local pod to a local docker container that is not managed by Kubernetes (1 to 4)
   
  +Of course the opposite traffic flows are also possible.
  +
   === Debugging Steps
   
   ==== Is IP Forwarding Enabled?
  
positive.code: and if you can't, it doesn't mean all pods aren't reachable.  It just
  tells you the status of the /one/ that kubproxy hooked you up to.
  
  Let's test the service anyway:
  ....
  curl -kv http://172.30.243.225:5000/bar                  # Replace the argument with your service IP address and port
  ....
  
negative.code: Then test connectivity at the node (host) level (using the address from
  `HostIP`):
  
  * `ping -c 3 _address_`: This should show a response, but if it
    doesn't it is possible that an intermediate router is eating the
    ICMP traffic.
  * `tracepath _address_`: This will show the IP route taken to the
    target (if ICMP packets are returned by all hops)
  
  If both `tracepath` and `ping` failed, then you need to look for
  connectivity issues with your local network (or any containing VMs, if
  any).
  
  Things to check for the local networking:
  
  * `ip route get _address_`: Prints the route the packet will take out of the box to the target address
  ....
  # ip route get 192.168.122.202
    192.168.122.202 dev ens3  src 192.168.122.46
      cache
  ....
  ** In this case it says it will go out the interface named `ens3` with
     the source address of 192.168.122.46 and go directly to the target.
     Is that what you expected?
  *** If so, use `ip a show dev ens3` to get the interface details and
      make sure that is the expected interface
  ** The other possibility is that it might say:
  ....
  # ip route get 192.168.122.202
  