Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Hi all,
I would like to share with you all about the case that is currently happen in ID .
There is an ISP here, that are currently announcing their IP Address to some different upstream provider. Please see some of our queries on the looking glasses below.
We found this case, after they announced to us that they want us to stop announcing the following prefixes (especially on our Internet eXchange): 202.173.91.0/24, 202.173.92.0/24, 202.173.94.0/24, 202.173.95.0/24
And after we checked to the upstream providers, why they are doing this, they mentioned that they received a permission letter, signed by this ISP's from their customer that are "holding" this IP Address. Just to note you that this customers are not connecting directly to this ISP's.
I would like to have your opinion on this: do we have to put it back to the FREE POOL, the whole IP Address ?? or only their AS Number that are currently being allocated to this members because of this ??
Our reason are: 1. This case are contriary with the goals of the assignment and allocation policies, especially on Aggregation and routability.
2. Announcing their IP Address not in the same ASN (I'm not sure where I can find this policy??). After we consult with some routing expert here in Indonesia, they mentioned, that if some IP Blocks are being announced under a different ASN, that means that this ISP's have broke their own routing table's.
I would like to have your share on this unique case. ========================================
CASE 1: ISP's with IP Address 202.173.95.0/24, we used looking glass RIS http://www.ris.ripe.net/cgi-bin/lg/index.cgi =====================================
BGP routing table entry for 202.173.95.0/24 Paths: (11 available, best #6, table Default-IP-Routing-Table) Advertised to non peer-group peers: 194.109.197.245 3741 701 4761 4800 168.209.255.2 from 168.209.255.2 (168.209.255.245) Origin IGP, localpref 100, valid, external Last update: Fri May 28 19:12:49 2004
513 3320 1239 701 4761 4800 192.65.184.3 from 192.65.184.3 (192.65.184.3) Origin IGP, localpref 100, valid, external Last update: Fri May 28 06:01:19 2004
traceroute 202.173.95.2 traceroute to 202.173.95.2 (202.173.95.2), 30 hops max, 38 byte packets 1 ip-82-81.neuviz.net.id (203.128.82.81) 0.321 ms 0.230 ms 0.218 ms 2 ip-95-33.neuviz.net.id (203.128.95.33) 1.465 ms 1.247 ms 1.047 ms 3 218.100.4.65 (218.100.4.65) 1.399 ms 2.858 ms 1.283 ms 4 218.100.4.13 (218.100.4.13) 2.925 ms 4.522 ms 3.118 ms 5 218.100.4.168 (218.100.4.168) 4.840 ms 5.096 ms 2.219 ms 6 peering-fa0-0.jkt.idola.net.id (202.152.0.67) 63.539 ms 88.414 ms 25.091 ms 7 silver-fa0-0.jkt.idola.net.id (202.152.0.69) 7.687 ms 27.197 ms 8.371 ms 8 202.152.43.6 (202.152.43.6) 53.826 ms 63.498 ms 62.682 ms 9 IP-69-88-24-226.HAWAIITELEPORT.COM (69.88.24.226) 143.339 ms 47.913 ms 80.704 ms 10 202.173.95.42 (202.173.95.42) 190.736 ms 48.784 ms 98.561 ms 11 202.173.95.2 (202.173.95.2) 56.204 ms 51.258 ms 59.008 ms
% [whois.apnic.net node-2] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
route: 202.173.95.0/24 descr: Route object of PT Elga Yasa Media descr: Internet Service Provider descr: Indonesia country: ID origin: AS23695 notify: admin@elga.net.id mnt-by: MAINT-ID-ELGA changed: hostmaster@elga.net.id 20040211 source: APNIC
CASE 2: from the same ISP's, from IP Address 202.173.94.0/24: we found: =====================================================
BGP routing table entry for 202.173.94.0/24 Paths: (11 available, best #11, table Default-IP-Routing-Table) Advertised to non peer-group peers: 194.109.197.245 202.12.28.190 3741 7018 25625 30362 18379 168.209.255.2 from 168.209.255.2 (168.209.255.245) Origin IGP, localpref 100, valid, external Last update: Fri May 28 12:01:39 2004
513 3320 7018 25625 30362 18379 192.65.184.3 from 192.65.184.3 (192.65.184.3) Origin IGP, localpref 100, valid, external Last update: Fri May 28 06:01:16 2004
traceroute 202.173.94.1 traceroute to 202.173.94.1 (202.173.94.1), 30 hops max, 38 byte packets 1 ip-82-81.neuviz.net.id (203.128.82.81) 0.322 ms 0.228 ms 0.211 ms 2 ip-95-33.neuviz.net.id (203.128.95.33) 2.366 ms 4.029 ms 1.423 ms 3 218.100.4.65 (218.100.4.65) 1.370 ms 4.323 ms 1.618 ms 4 218.100.4.13 (218.100.4.13) 10.336 ms 8.790 ms 9.297 ms 5 218.100.4.137 (218.100.4.137) 7.834 ms 7.296 ms 14.254 ms 6 * Se1-0-1-ckr-core-router.csmnap.net (202.123.226.9) 69.293 ms 76.723 ms 7 Se2-3-hwii-core-router.csmnap.net (202.123.226.14) 649.966 ms 719.549 ms 1070.533 ms 8 hssi3-0-hwii-core2-router.csmnap.net (202.123.226.18) 627.831 ms 656.619 ms 698.836 ms 9 hssi3-0-hwii-core1-router.csmnap.net (202.123.226.17) 610.567 ms 633.327 ms 626.799 ms 10 hssi3-0-hwii-core2-router.csmnap.net (202.123.226.18) 598.292 ms .....[LOOPING]
% [whois.apnic.net node-2] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
route: 202.173.94.0/24 descr: Route object of PT Elga Yasa Media descr: Internet Service Provider descr: Indonesia country: ID origin: AS23695 notify: admin@elga.net.id mnt-by: MAINT-ID-ELGA changed: hostmaster@elga.net.id 20040211 source: APNIC
CASE 3: from the same ISP's from the IP address: 202.173.65.0/24 ================================================== When we take a look at the looking glass IXP , Indonesian Internet eXchange, we found: http://www.apjii.or.id/tools/lg.php?lang=eng
Router : 218.100.4.2 Query : bgp Addr : 202.173.65.0
BGP routing table entry for 202.173.65.0/24, version 81039 Paths: (2 available, best #1) Advertised to non peer-group peers: 202.150.85.5 202.162.195.6 218.100.4.10 218.100.4.14 218.100.4.98 218.100.4.100 218.100.4.102 218.100.4.103 218.100.4.104 218.100.4.105 218.100.4.106 218.100.4.108 218.100.4.130 218.100.4.131 218.100.4.134 218.100.4.135 218.100.4.136 218.100.4.137 218.100.4.138 218.100.4.139 218.100.4.140 218.100.4.141 218.100.4.142 218.100.4.143 218.100.4.144 218.100.4.145 218.100.4.146 218.100.4.148 218.100.4.149 218.100.4.150 218.100.4.151 218.100.4.152 218.100.4.153 218.100.4.154 218.100.4.156 218.100.4.157 218.100.4.158 218.100.4.159 218.100.4.160 218.100.4.161 218.100.4.162 218.100.4.163 218.100.4.164 218.100.4.165 218.100.4.166 218.100.4.167 218.100.4.168 218.100.4.169 218.100.4.170 218.100.4.171 218.100.4.172 218.100.4.173 218.100.4.174 218.100.4.175 218.100.4.176 218.100.4.177 218.100.4.178 218.100.4.179 218.100.4.180 218.100.4.181 218.100.4.182 218.100.4.183 218.100.4.184 218.100.4.185 218.100.4.187 218.100.4.198 218.100.4.206 218.100.4.214 218.100.4.230 218.100.4.242 218.100.4.246 23695 218.100.4.133 from 218.100.4.133 (202.173.64.144) Origin IGP, metric 0, localpref 100, valid, external, best 23695, (received-only) 218.100.4.133 from 218.100.4.133 (202.173.64.144) Origin IGP, metric 0, localpref 100, valid, external
Regards, Ahmad Alkazimy
Hi Ahmad,
Apologies for the delay in responding to your question.
Any customer assignments or sub-allocations that your members make to their customers are NON-PORTABLE. This means that when a customer ceases to receive connectivity from your member, then the customer has no choice but to return the address space.
In this particular case that you are referring to, when APNIC made the allocation the following piece of standard information was included:
[snip] APNIC strongly recommends you include in your standard connectivity contract provisions that require customers to return address space back to you when they change service providers. Such wording will help to reduce the growth in the number of global routing tables, thus aiding the continuation of global connectivity for all networks. [/snip]
How this case is proceeded with depends on the contractual agreement APJII has with it's members. Your member may wish to ask the other upstream who is currently announcing the /24s to stop announcing them.
In any case, should your member come back for another allocation it should not be approved if non-portable address space is being used in the wrong manner. You may need to remove route or other objects from the whois database if you are having problems stopping the routing of these assignments.
If your member does not understand the policy fully, it would be good if APJII can educate them on this. You should also suggest to your members that when they are making assignments to their customers they should have some agreement so that when the customers are disconnected from the network they should return the resource.
I hope this information is of assistance.
Cheers, Tim.
Activity Summary
- 7098 days inactive
- 7098 days old
- sig-nir@lists.apnic.net
- 2 participants
- 1 comments