Skip to content
Register

Mapping provider network routes

General Discussion by Zurich1984 24 replies 2.6K views
Zurich1984

Member OP

#1

Tired of buying blind. Every provider says "premium blend" but nobody publishes actual paths. Thinking we crowdsource traceroutes from edge nodes, build open database.

I know, I know. Prices only go up, /24 will cost you a kidney, and nobody works for free. But the data asymmetry is killing small operators. We get sold "global anycast" that routes through somebody's basement in Sofia.

Need: volunteers with nodes at different providers, willingness to run scheduled mtr. Maybe auto-submit script so it's not manual drudgery.

Willing to seed with market data—what I pay for transit, which paths actually materialize. No names attached.

Who's in, or is this doomed?

/24 for sale. No lowballs.
SS

Member

#2

🗺️

Lol

Nice

GeorgeNmp

Member

AS64512

#3

Your methodology needs tightening before this generates useful data.

Traceroute alone won't distinguish hot-potato from cold-potato routing without BGP communities exposed, and most providers strip those. You'll want to correlate with IRR objects and validate RPKI for the prefixes you probe, otherwise you're mapping invalid or hijacked space. I use https://bgp.tools for that.

That said, the concept has merit for transit pricing transparency. I've seen "premium" blends that prepend three times to avoid settlement-free peers, artificially inflating path length. Documenting actual AS paths versus advertised paths would be valuable.

Auto-submit is essential. Manual collection at scale introduces selection bias—people only run tests when routes fail.

iBGP, eBGP, don't care, just peer
sarahjey

Member

#4

I thought those were internal

Also what is irr I tried googling but got confused.

This sounds really cool though I have a tiny vps at RackNerd I could run stuff from!

learning on $5 VPS and prayers
quinnbizz

Member

#5

IMO the auto-submit angle is what makes this workable. Manual projects die, YMMV but I've watched three similar efforts stall by month three.

Take it with a grain of salt, but I'd start smaller—maybe five providers, consistent methodology, then expand. Better to have clean limited data than messy comprehensive data.

I can contribute a node at bytemole if helpful. Nothing fancy, just a small VM.

...
annexbi

Member

#6

I could (finally) put my cron addiction to use here (you should see my home server (it's mostly cron (nested cron (don't ask)))) but seriously the auto-submit script is trivial (I've written worse (much worse (like that time I tried to parse bgp with sed))) though someone should probably review it (not me (definitely not me (I'm a menace)))

@GeorgeNmp would you sanity-check path validation logic if I prototype this?? (no pressure (except yes pressure (the good kind)))

push. done. coffee.
MA

Member

#7

That "basement in Sofia" line hit too close to home

GeorgeNmp

Member

AS64512

#8
annexbi said:
Would you sanity-check path validation logic if I prototype this??

Sure. Post a draft and I'll review. Focus on:

  • Filtering RFC1918 and documentation ranges before submission
  • Deduplicating on (source ASN, destination prefix, timestamp day) so one flapping path doesn't flood the DB
  • Stripping payload from mtr output—you don't want user data in a public corpus

For RPKI validation, avoid librpki unless you want to build it yourself. Routinator via their API is easier to script against.

@annexbi your nested cron made me physically recoil.

iBGP, eBGP, don't care, just peer
annexbi

Member

#9
GeorgeNmp said:
Your nested cron made me physically recoil

(thank you (it took years of practice (the recoil is the compliment)))

Draft this weekend (maybe (no promises (actually yes promises (the good kind))))

Leaning toward python + scapy for probe generation, jsonlines for output, curl for submit. The kind of stack you can debug at 3am without docs.

push. done. coffee.
giorgiauc

Member

#10

I don't pay for transit so my contribution is limited, but I can run probes from my edge in Tbilisi. The routing out of Caucasus is... special. You want to see a Turk Telekom prepend party, this is where to find it.

Also: nobody mentioned measurement frequency yet. Too often and you look like a slow DDoS. Too rare and you miss path changes. I'd suggest jittered intervals, 15-45 minutes, different per node.

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft