Skip to content

net-gateway: time reserved DNS upstream connects - #898

Draft
nikhilbirmiwal-pplx wants to merge 1 commit into
mainfrom
nikhilb/netgw-reserved-dns-connect-timing
Draft

nikhilbirmiwal-pplx wants to merge 1 commit into
mainfrom
nikhilb/netgw-reserved-dns-connect-timing

Conversation

@nikhilbirmiwal-pplx

Copy link
Copy Markdown
Collaborator

Why

During sandbox startup, the node's NetworkPolicy agent can switch a pod's egress to "policies applied" before the rule that allows internet egress is programmed. A DNS-over-TLS dial made in that window gets no SYN-ACK, RST or ICMP. Hickory reports it as a plain Timeout, which looks the same as an upstream that connected and never answered.

We need to know whether the gateway starts upstream DNS work inside that window. A companion change to the node agent emits per-pod egress_probe_isolated / egress_probe_allowed events. This PR adds the gateway side of the join.

What

  • reserved DNS upstream connection failed now carries:
    • connect_ms: time from the start of the dial to the failure.
    • established_before: false until a connection to that upstream has succeeded in this gateway process.
  • New info event reserved DNS upstream first connection established. It's logged once per upstream per gateway process, with connect_ms. Its timestamp minus connect_ms is when the gateway first dialed that upstream.
  • Docs: docs/observability.md § Reserved DNS upstream connections.

Behavior is unchanged: there are no new retries or timeouts. Info volume is at most one line per upstream per gateway process. Idle reconnects don't log the info event.

Testing

  • cargo check and cargo clippy --tests -D warnings on pplx-space-net-gateway
  • cargo test -p pplx-space-net-gateway --lib reserved_dns: 24 passed

Log connect_ms and established_before on reserved DNS upstream connection
failures, and log the first established connection per upstream once per
gateway process with its connect_ms. Together they place the gateway's
first upstream dial against the node's per-pod egress policy timeline, so
a dial that started while pod egress was isolated is distinguishable from
an upstream that accepted the connection and never answered.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant