Conversation
Securebit added AS215932 to AS-SBAG:AS-CH-ZUR on 2026-09-10. RIS looking-glass on 2026-09-14 shows both /48s at 360 peer-paths via cr1-ch1, with AS6939 and AS174 upstream of 58057 — the #517 success criterion. The /48 more-specific strategy can now steer return traffic off the degraded Servperso links. Also corrects the 1.6% reach misdiagnosis still on main, and the verification recipe that compared a more-specific against our equally-filtered aggregate. Closes #517 Assisted-by: pi-coding-agent:grok-4.6
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d4557bf31d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # Count rrcs[].peers[] and read the as_paths. Read the ASN immediately BEFORE | ||
| # ours in each path — that is the upstream actually carrying us, and its absence |
There was a problem hiding this comment.
Skip origin prepends when identifying the upstream
When checking the aggregate paths exported through nl1/de1, the AS path ends with several consecutive 215932 entries because those routers prepend the origin ASN three times. Reading the ASN immediately before an occurrence of “ours” can therefore report 215932 itself rather than the actual adjacent upstream (34872), causing the verification recipe to misclassify paths; instruct readers to skip the complete trailing origin-AS run and select the first distinct ASN before it.
Useful? React with 👍 / 👎.
| | `2a0c:b641:b50::/48` | 6 | — | 6 | | ||
| | `2a0c:b641:b51::/48` | 6 | — | 6 | | ||
| | `2a0c:b641:b50::/44` | 6 | 365 (prepended) | 372 | | ||
| | `2a0c:b641:b50::/44` | 6 | 368 (prepended) | 374 | |
There was a problem hiding this comment.
Separate the July and August propagation measurements
This row rewrites the documented 2026-07-25 result from 365 / 372 to 368 / 374 while line 222 says the July and August measurements were identical with no drift. The same commit retains the original July values in docs/blog/asymmetric-return-path-as215932.md:140-150, so the repository now gives two different results for that measurement; record the August result separately or explain why the original July count was corrected.
Useful? React with 👍 / 👎.
| |---|---|---|---| | ||
| | `2a0c:b641:b50::/48` | 360 | — | 360 | | ||
| | `2a0c:b641:b51::/48` | 360 | — | 360 | | ||
| | `2a0c:b641:b50::/44` | 293 | 77 (prepended) | 368 | |
There was a problem hiding this comment.
Reconcile the current /44 peer-path totals
Under the adjacent-upstream classification described above, the cr1-ch1 and AS34872 buckets are mutually exclusive, but this row reports 293 and 77 paths while giving a total of 368 rather than 370. This makes at least one of the headline reach numbers or its classification incorrect and prevents the table from serving as a reproducible verification record; correct the counts or explicitly define and explain overlapping buckets.
Useful? React with 👍 / 👎.
| Re-measured 2026-09-14 via RIS real-time looking-glass (23 collectors): | ||
|
|
||
| | prefix | peer-paths via cr1-ch1 (`58057`/`56755`) | via nl1/de1 | total | | ||
| | prefix | peer-paths via cr1-ch1 (`58057`/`56755`) | via nl1/de1 (`34872`) | total | |
There was a problem hiding this comment.
Include the second de1 transit in path classification
When the aggregate propagates through cr1-de1's configured AS210233 session, its adjacent external ASN is 210233, not 34872, but both new measurement tables label the entire nl1/de1 bucket as AS34872. Those paths therefore cannot be classified using the documented columns and may be omitted or folded into the wrong total; include AS210233 in the de1 classification or narrow the column label to what was actually counted.
Useful? React with 👍 / 👎.
| the /48s in the DFZ via Securebit; whether return *bytes* actually moved off | ||
| Servperso still needs a capture on rtr (`src net 2a04:4e42::/32 and inbound`) | ||
| and a native-IPv6 download against the 52.7 KB/s baseline. Tracked in #351. | ||
| - **Single preferred upstream.** #517 landing means Securebit now carries most |
There was a problem hiding this comment.
Avoid claiming the unmeasured traffic shift
This says Securebit now carries most inbound traffic even though the immediately preceding bullet explicitly states that only route visibility was verified and that return-byte movement still requires a packet capture and throughput test. A 360-peer RIS footprint does not establish traffic volume, since peer paths are not weighted by bytes, so this turns the unverified outcome into a documented fact; describe Securebit as the preferred path or defer the traffic claim until the planned measurement is completed.
Useful? React with 👍 / 👎.
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
PR Code Suggestions ✨No code suggestions found for the PR. |
Verified the claim: Securebit added
AS215932to their transit as-set, and the/48 more-specifics now propagate through their cone instead of dying at their
border. That is what lets return traffic leave the degraded Servperso links.
Closes #517. Supersedes #518 (same diagnosis, never merged, now also stale
against the 2026-09-10 membership).
What was verified (2026-09-14)
RIPE object
AS-SBAG:AS-CH-ZUR,last-modified: 2026-09-10T00:48:56Z, nowlists
AS215932. Nesting isAS-SBAG→AS-SECUREBIT→AS-SBAG:AS-CH-ZUR.RIS real-time looking-glass, 23 collectors:
58057/56755)34872)2a0c:b641:b50::/482a0c:b641:b51::/482a0c:b641:b50::/44AS6939 sits immediately upstream of 58057 on 245 /48 peer-paths, AS174 on 34.
That is the #517 success criterion (6 → ~350, with HE and Cogent appearing).
The /44 still has Servperso paths because it is announced from all three cores;
that is the failover, not a leak of the more-specifics.
What this PR changes
Docs only. No FRR, no route-map.
docs/bgp-policy.md— current reach table, membership recipe, correctedverification control (single-homed unfiltered prefix, not our own aggregate),
historical 6-peer-path diagnosis kept so it is not re-derived.
docs/blog/asymmetric-return-path-as215932.md— addendum so the published1.6% reach ending is not left as current truth.
Not claimed
Looking-glass shows the routes are in the DFZ via Securebit. Whether return
bytes have actually moved off Servperso still needs a capture on rtr
(
src net 2a04:4e42::/32 and inbound) and a native-IPv6 download against the52.7 KB/s baseline — still #351.
Aut-num
import/exportlines still omit AS58057. Hygiene, not a blocker.