iForte Solusi Infotek - eXchange: PeeringDB fix list

AS137367 · peeringdb.com/net/17980

PeeringDB

3 things to fix in iForte Solusi Infotek - eXchange's PeeringDB record, from what its exchanges publish: 1 to add, 1 to correct, 1 to check. As of 2026-10-08 20:58 UTC.

Make the changes on iForte Solusi Infotek - eXchange's PeeringDB page: sign in, choose Edit, and find the exchanges under Public Peering Exchange Points. Speeds go in as megabits per second.

Add these exchanges (1)

On the exchange's own member list, but not in iForte Solusi Infotek - eXchange's PeeringDB record. Add one entry per connection with these values.

  1. Singapore SGIX Singapore, Singapore · PeeringDB 429From its IX-F export and website members list
    IPv4103.16.102.161
    IPv62001:de8:12:100::161
    Speed10000 Mbps (10G)
    RS peerYes

Correct these entries (1)

Addresses or port speeds in PeeringDB that differ from the exchange's IX-F export. The changes below follow the export; if the export is the one that's wrong, tell the exchange instead.

  1. United Kingdom LINX LON1 London, United Kingdom · PeeringDB 18
    ProblemPeeringDB hasThe export has
    Port speed differs10G3G
    • In the entry with IPv4 195.66.226.124: set Speed to 3000 (3G) (now 10000).

Check these entries (1)

In PeeringDB, but on none of the exchange's own lists. If iForte Solusi Infotek - eXchange has left, delete the entry; if it's still connected, the exchange's list is wrong: ask the exchange to fix it.

  1. Japan JPIX TOKYO Tokyo, Japan · PeeringDB 30Not on its website members list
    IPv4210.171.225.158
    IPv62001:de8:8::13:7367:1
    Speed10000 Mbps (10G)

    This exchange only publishes a website list, and some leave out members who ask not to be listed.

From ixreport.com/net/137367/: PeeringDB against each exchange's IX-F export and website members list. Exchanges whose lists couldn't be read on this update aren't included.