docs: clarify underlay connectivity requirements

docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx

@@ -42,6 +42,10 @@ In Underlay mode, Kube-OVN bridges a physical NIC to OVS and sends packets direc
 
   - For service access traffic, Pods will first send packets to the gateway, which must have the ability to forward packets back to the local subnet.
 
+  - You are responsible for ensuring connectivity for Pods on the Underlay network. Configure routes, firewalls, security groups, and other physical network policies to allow all traffic required by your workloads. The following common paths must be allowed as applicable:
+    - HTTP, TCP, and gRPC probes are initiated by the kubelet on the node that hosts the Pod. Every node on which the Pod can run must be able to reach the Pod IP and the configured probe endpoint, protocol, and port.
+    - For DNS resolution, Pods must be able to reach the DNS server configured for the cluster, such as an endpoint backing the `kube-dns` Service. Allow the protocols and ports configured for that DNS server. For `kube-dns` endpoints, follow the actual EndpointSlice or Endpoints configuration; do not assume that an endpoint uses the same port as the Service. Return traffic must also be allowed.
+
   - When the switch or bridge has Hairpin functionality enabled, **Hairpin must be disabled**. If using a VMware virtual machine environment, set **Net.ReversePathFwdCheckPromisc** on the VMware host to **1**, and Hairpin does not need to be disabled.
 
   - The bridging NIC **cannot** be a **Linux Bridge**.

docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx

@@ -7,6 +7,15 @@ If a cluster has both Underlay and Overlay subnets, by default, Pods under the O
 
 To achieve automatic interconnection between Underlay and Overlay subnets, you can manually modify the YAML file of the Underlay subnet. Once configured, Kube-OVN will also use an additional Underlay IP to connect the Underlay subnet and the ovn-cluster logical router, setting the corresponding routing rules to enable interconnection.
 
+## Node-to-Pod Traffic Path
+
+With ACP 4.4 defaults, enabling `u2oInterconnection` does not automatically route traffic from cluster nodes to Underlay Pods through `ovn0`:
+
+- Traffic from a node to an Underlay Pod follows the node's Linux routing table and normally relies on the physical network path. Kube-OVN installs a route for the Underlay CIDR through `ovn0` only when the Underlay subnet belongs to the default VPC, U2O is enabled, load balancing is disabled for the subnet, and no conflicting route exists.
+- An Underlay Pod uses the U2O interconnection IP as its logical gateway. For traffic from the Pod to a cluster node InternalIP, Kube-OVN routes the packet to the Underlay physical gateway and sends it through the ProviderNetwork bridge and physical NIC. The same policy applies to the local node and other nodes, and to IPv4 and IPv6.
+
+Configure physical routes and firewall policies to allow bidirectional traffic between every required node address and Underlay Pod CIDR. This is required for node-originated traffic such as kubelet HTTP, TCP, or gRPC probes.
+
 ## Procedure
 
 1. Go to **Administrator**.