istioctl proxy-config route <pod-name[.namespace]> --name 9080

  # Retrieve full route dump for route 9080
  istioctl proxy-config route <pod-name[.namespace]> --name 9080 -o json

  # Retrieve route summary without using Kubernetes API
  ssh <user@hostname> 'curl localhost:15000/config_dump' > envoy-config.json
  istioctl proxy-config routes --file envoy-config.json
`,
		Aliases: []string{"routes", "r"},

  // ingress supports SNI.
  // +optional
  repeated IngressTLS tls = 2;

  // rules is a list of host rules used to configure the Ingress. If unspecified, or
  // no rule matches, all traffic is sent to the default backend.
  // +optional
  repeated IngressRule rules = 3;
}

// IngressStatus describes the current state of the Ingress.
message IngressStatus {

  // ingress supports SNI.
  // +listType=atomic
  // +optional
  repeated IngressTLS tls = 2;

  // rules is a list of host rules used to configure the Ingress. If unspecified,
  // or no rule matches, all traffic is sent to the default backend.
  // +listType=atomic
  // +optional
  repeated IngressRule rules = 3;
}

// IngressStatus describe the current state of the Ingress.
message IngressStatus {

        "ips": [
            {
                "version": "4",
                "address": "10.0.0.2/24",
                "gateway": "10.0.0.1",
                "interface": 0
            }
        ],
        "routes": []

    },
    "log_level": "debug",
    "cni_event_address": "%s",
    "ambient_enabled": %t,
    "kubernetes": {
        "k8s_api_root": "APIRoot",
        "kubeconfig": "testK8sConfig",

turns the above inputs into the actual types consumed by the connected XDS clients (typically Envoy). This is done by `Generators`, which register a function to build a given type. For example, there is a `RouteGenerator` responsible for building `Routes`. Along with the core Envoy XDS types, there are a few custom Istio types, such as our `NameTable` type used for DNS, as well as debug interfaces.

`Generators` get as input the `Proxy` (a representation of the current client), the current...

VirtualService: bookinfo
   Route to host "productpage" with weight 30%
   Route to host "productpage2" with weight 20%
   Route to host "productpage3" with weight 50%
   Match: /prefix*
--------------------
Exposed on Ingress Gateway http://1.1.1.1
Exposed on Ingress Gateway http://2.2.2.2
VirtualService: bookinfo
   Route to host "productpage" with weight 30%
   Route to host "productpage2" with weight 20%

    docker exec "${C1_NODE}" ip route add "${C2_POD_CIDR}" via "${C2_DOCKER_IP}"
    docker exec "${C1_NODE}" ip route add "${C2_SVC_CIDR}" via "${C2_DOCKER_IP}"
    docker exec "${C2_NODE}" ip route add "${C1_POD_CIDR}" via "${C1_DOCKER_IP}"
    docker exec "${C2_NODE}" ip route add "${C1_SVC_CIDR}" via "${C1_DOCKER_IP}"
  fi
}

function install_calico {

            {{- end }}
            - containerPort: 15090
              protocol: TCP
              name: http-envoy-prom
          args:
          - proxy
          - router
          - --domain
          - $(POD_NAMESPACE).svc.{{ .Values.global.proxy.clusterDomain }}
        {{- if .Values.global.proxy.logLevel }}
          - --proxyLogLevel={{ .Values.global.proxy.logLevel }}

          name: status-port
          protocol: TCP
        - containerPort: 15090
          protocol: TCP
          name: http-envoy-prom
        args:
        - proxy
        - router
        - --domain
        - $(POD_NAMESPACE).svc.{{ .Values.global.proxy.clusterDomain }}
        - --proxyLogLevel
        - {{ annotation .ObjectMeta `sidecar.istio.io/logLevel` .Values.global.proxy.logLevel | quote}}

This only applies for selector-based policies; namespaced and global policies can be handled without needing to list them out in the Workload API.

## Redirection

As ztunnel aims to transparently encrypt and route users traffic, we need a mechanism to capture all traffic entering and leaving "mesh" pods.
This is a security critical task: if the ztunnel can be bypassed, authorization policies can be bypassed.