I observed my local topology: three interfaces connecting to Uni (customer), AS2 (peer), and EveLink (customer), with loopback 4.2.2.1/32 and a DNS resolver on port 53. I also observed ACM returning 503 errors, and via tcpdump on AS1-eth2, identified a slowloris DoS attack from EveLink (10.0.5.2) flooding ACM with `GET /slow` requests.

I decided to install explicit routes for AS2's loopback and ACM's prefixes (rather than relying on the default route), source all diagnostics from my loopback address, investigate locally before escalating the WHY request, and contact EveLink directly to stop the attack instead of applying autonomous edge filtering.

These choices were justified because explicit routes ensure deterministic forwarding and aren't susceptible to default-route changes; loopback sourcing avoids false negatives since link addresses aren't advertised network-wide; local investigation first avoids unnecessary cross-domain escalation; packet capture on my EveLink-facing interface was the key evidence since I'm uniquely positioned at the ingress point; and per admin approval policy, filtering a paying customer's traffic requires approval, so remediating at the source was the appropriate response. The incident was resolved after EveLink killed the malicious script and I confirmed via bounded tcpdump (0 packets) and curl (HTTP 200) that service was restored.