ASN to prefixes

[acoul]

when querying an ASN for their prefixes, for example:
asn -n 38457

the result (from HNS-AS-AP Honesty Net Solution I Pvt Ltd, IN) is:

103.245.100.0/22
120.88.33.0/24
120.88.42.0/24
120.88.43.0/24
120.88.44.0/24
120.88.45.0/24
120.88.46.0/24
120.88.47.0/24
123.108.224.0/21

when using bgpview.io for the same query, we get:
curl https://api.bgpview.io/asn/38457/prefixes | sed 's/parent":{"prefix":"/\n/g' | grep ^[1-9] | cut -d "\"" -f 1 | sort -u | sed 's/\\//'

103.245.100.0/22
117.192.0.0/10
120.88.32.0/20
123.108.224.0/21

with the exception of the inclusion of the actual parent (provider) prefixes of that given ASN, which I haven't figured out (yet) a way to filter out:

117.192.0.0/10

bgpview.io provides one additional valid prefix for that given ASN

120.88.32.0/20

which is a valid parent of some of the /24 prefixes that the HNS-AS-AP provides

apparently, HNS-AS-AP seems to be missing the following valid prefixes:

120.88.32.0/24
120.88.34.0 -120.88.41.0 /24

[nitefood]

Hey @acoul,

I see your point. On one hand, asn output does only give you the right parents, but filters out unannounced prefixes (120.88.32.0/24, 120.88.34.0 -120.88.41.0 /24).

On the other hand, BGPView "hallucinates" and gives you a bad parent (117.192.0.0/10).

I would argue that one good solution in this scenario would be something like this oneliner: asn=38457; parentslist=""; for pfx in $(curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=$asn" | jq -r '.data.prefixes[].prefix' | sort -n); do echo -n "prefix: $pfx, parent: "; parent=$(curl -s "https://stat.ripe.net/data/whois/data.json?resource=$pfx" | jq -r '.data.irr_records | map(from_entries) | first | .route'); parentslist="${parentslist}\n${parent}"; echo "$parent"; done; echo -e "\nAggregated list of parents:"; echo -e "$parentslist" | sort -un

which delivers what you're after:

prefix: 103.245.100.0/24, parent: 103.245.100.0/22
prefix: 103.245.101.0/24, parent: 103.245.100.0/22
prefix: 103.245.102.0/24, parent: 103.245.100.0/22
prefix: 120.88.33.0/24, parent: 120.88.32.0/20
prefix: 120.88.42.0/24, parent: 120.88.32.0/20
prefix: 120.88.43.0/24, parent: 120.88.32.0/20
prefix: 120.88.44.0/24, parent: 120.88.32.0/20
prefix: 120.88.45.0/24, parent: 120.88.32.0/20
prefix: 120.88.46.0/24, parent: 120.88.32.0/20
prefix: 120.88.47.0/24, parent: 120.88.32.0/20
prefix: 123.108.224.0/24, parent: 123.108.224.0/21
prefix: 123.108.225.0/24, parent: 123.108.224.0/21
prefix: 123.108.226.0/24, parent: 123.108.224.0/21
prefix: 123.108.227.0/24, parent: 123.108.224.0/21
prefix: 123.108.228.0/24, parent: 123.108.224.0/21
prefix: 123.108.229.0/24, parent: 123.108.224.0/21
prefix: 123.108.230.0/24, parent: 123.108.224.0/21
prefix: 123.108.231.0/24, parent: 123.108.224.0/21

Aggregated list of parents:

103.245.100.0/22
120.88.32.0/20
123.108.224.0/21

This is a suboptimal solution though, from a performance standpoint: it introduces a new API call to query IRR records for each and every prefix, which may become a nightmare for larger autonomous systems. This is why initially I went for a lighter approach (whois INETNUM deaggregation), which is sadly more error prone.

If you have faster approaches or ideas, I'm open to suggestions!

[acoul]

Hey @acoul,

I see your point. On one hand, asn output does only give you the right parents, but filters out unannounced prefixes (120.88.32.0/24, 120.88.34.0 -120.88.41.0 /24).

appreciate so much your input, clarifications & technical detail

I am still astound by the verity & usefulness asn packs & offers as a tool (utilizing various open services of the wonder netland)

thank you

[acoul]

Hey @acoul,

I see your point. On one hand, asn output does only give you the right parents, but filters out unannounced prefixes (120.88.32.0/24, 120.88.34.0 -120.88.41.0 /24).

On the other hand, BGPView "hallucinates" and gives you a bad parent (117.192.0.0/10).

I haven't researched this thoroughly, but what is impressive about BGPView is the speed of the replies and the fact that it discovers registered network prefixes rather that just advertised ones (a bug or a feature depending what you are after)

This is a suboptimal solution though, from a performance standpoint: it introduces a new API call to query IRR records for each and every prefix, which may become a nightmare for larger autonomous systems.

I see and fully agree with your point

let me provide some additional feedback, but if I am getting O.T. let me know and I will restrain myself

trying to find the ASN of an IP with asn I get quite a quick response:
asn -n 185.201.17.34

185.201.17.34 ┌PTR out13-34.antispamcloud.com
├ASN 174 (COGENT-174, US)
├RNK #3 TOP 10 AS
├ORG Cogent Communications
├NET 185.201.17.0/24 (NET-185-201-17-0-2)
├ABU abuse@spamexperts.com
├ROA ✓ VALID (2 ROAs found)
├TYP DC i3d.net (NL-ZH)
├GEO Eindhoven, North Brabant (NL)
├CPE [APP: f5:nginx]
├POR Open ports: 80, 143, 443, 993
├TAG starttls
└REP ✓ NONE

issuing though a query for analyzing ASN 179 is where the nightmare starts:
asn -n 174

it tries to retrieve & analyze information for 6217 prefixes which is a mission close (if you have the patience) to impossible

of-course it works & after some time it properly displays correct & detailed information, but in my case it's an overkill.

I find the following (not so professional) approach:

ASN="179"
regex_pref="185.201."
curl https://api.bgpview.io/asn/$ASN/prefixes | sed 's/{"prefix":"/\n/g' | grep ^[1-9] | cut -d """ -f 1 | sort -u | sed 's/\//' | awk -F "/" '$2<24' grep $regex_pref

.>185.201.16.0/22

FWIW more handy

[nitefood]

what is impressive about BGPView is the speed of the replies

That's because they have the results cached on a server-side db, not fetched in real time. That's a minor tradeoff, but depending on your use case it may be absolutely acceptable.

and the fact that it discovers registered network prefixes rather that just advertised ones (a bug or a feature depending what you are after)

BGPView is an amazing tool, but as I said earlier, it can give you misleading information when it comes to parent prefixes.
Both tools try to give you INETNUM aggregation (i.e. registered, rather than announced) prefix data when querying by asn. And it's a feature and not a bug (at least I can speak for asn), because the purpose here is to list resources available to the target AS, not just the ones it actively uses.
This is subject to some limitations (as you found out in the case of AS38457), that depend on the way the tool retrieves the data it needs.
Yet, asn tends to err on the safe side, while BGPView does the opposite. It will happily feed you a wrong parent in the spirit of "aggregate at all costs".

Take for example output for AS 5505:

ASN output:

BGPView output

Single prefixes:

➜ curl -s "https://api.bgpview.io/asn/5505/prefixes" | jq -r '.data.ipv4_prefixes[].prefix'
185.123.204.0/24
185.123.205.0/24
185.123.206.0/24
185.123.207.0/24
185.210.225.0/24
185.210.226.0/24
185.210.227.0/24
188.130.247.0/24

Unique parents:

➜ curl -s "https://api.bgpview.io/asn/5505/prefixes" | jq -r '[.data.ipv4_prefixes[].parent.prefix] | unique[]'
185.123.204.0/22
185.210.224.0/22
188.130.240.0/20

Let's break those results down and compare the information we can derive from them:

• 185.123.204.0/22
  This prefix is correctly identified by both tools
• 185.210.224.0/22
  BGPView lists this as a parent prefix, but both itself and asn only list three /24 networks in this range: 225.0/24, 226,0/24 and 227.0/24. This means that, while from a strict subnetting point of view 185.210.224.0/22 is indeed a supernet for those three /24s, asn correctly identifies 224.0 as not being part of AS5505's resources (upon further inspection it is infact announced by a different, austrian AS), and therefore avoids giving you a wrong parent prefix, while BGPView throws it in (thus "tainting" its aggregated resources list already)
• 188.130.240.0/20
  This is where BGPView gets wild: according to its "single prefixes" output, only the 188.130.247.0/24 network is part of this parent. Upon further inspection, we can notice that the vast majority of the networks in the 188.130.240.0/24 -> 188.130.255.0/24 range are announced by totally different and unrelated ASNs.
  Furthermore, asn not only correctly identified 188.130.247.0/24, but could also identify the unannounced 188.130.254.0/24 prefix, which is indeed part of AS5505's resources. BGPView totally misses this.

Unfortunately when building asn the main tradeoff I had to make was to sacrifice speed for accuracy. I wish there was a faster way (or a faster yet precise API to query), but I haven't gotten around to finding it. As you can see BGPView's API is very straightforward to parse, and I could integrate it very quickly, but those erratic reports are what's setting me back for the time being.

As always, I'm fully open to suggestions or ideas! Thanks for the constructive issue.

[acoul]

the quality of the feedback reminds me my good old University days ! thank you

accuracy & reliability comes first undoubtedly

really grateful for the asn tool. I tend to use it when all quick alternatives fail and I am in a kind of a dead end state

[acoul]

I rushed to close this "ticket" overlooking the enhancement tag, thereof I am reopening it for further reference to whom it may concern as it also contains high quality information

cheers

[nitefood]

I've converted this issue to a discussion, I think it's a more appropriate place for anyone to contribute with ideas or APIs to improve this lookup workflow

[acoul]

my acquaintance with asn happened on a quest of trying to find ways to fight (or actually defend from) spam and various malicious port scans

FWIW, I would like to share two more findings (for me at least) that I bumped today for resolving IPs to ASNs along with their relative netblocks

whois -h riswhois.ripe.net 45.89.233.214

and

whois -h whois.cymru.com -v 45.89.233.214

[nitefood]

Yes, asn uses both to perform IP->ASN lookup. The logic is:

1. query RIPE first (more accurate and up-to-date)
2. fallback to Cymru if no match on RIPE
3. fallback to generic WHOIS if no match on Cymru

Note DNS is faster than WHOIS when querying Cymru, so you may want to use that for faster lookup