February 2012 - members-discuss

Re: [members-discuss] Surprise on renew fees
by LIR 18 Feb '12

18 Feb '12

Il 14/12/2011 07:56, Raymond Jetten ha scritto: > > > A large ISP does not neccesarily demand more work from the RIPE NCC > then a starting one, usually they (small ones) need more guidance in > the beginning. Also large ISP:s may have larger (amounts of) customers > then a small isp. We are paying for RIPE NCC membership services, not > solely for IP:s (imho) So this can be true for first years, not for life. Would more fair to put on same level all ISP after some years (but no more than three). > > Its the same case with the oil prices, oil is runnig out and will > become more expensive, also situations is different countries > (political, natural disasters) affect the oil price. Do you have the > same complaint when you fill up your car at the gasstation when the > price has gone up? When I fill up my car I do not pay gasoline depending on the year I bought my car. Regards, Tonino

9 10

whois mntner
by Richard Kojedzinszky 18 Feb '12

18 Feb '12

Dear members, Maybe a stupid question, but I am used to update objects via signed emails. Now, a mntner object cannot be queried fully, I got a filtered result always, even with the maintainer not containing md5 passwords. So I am missing the auth: fields. $ whois -T mntner -B -r MNT-RK1387-RIPE % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Information related to 'MNT-RK1387-RIPE' mntner: MNT-RK1387-RIPE descr: Maintainer of RK1387-RIPE admin-c: RK1387-RIPE upd-to: richardk(a)tvnetwork.hu mnt-by: MNT-RK1387-RIPE referral-by: MNT-RK1387-RIPE changed: richardk(a)tvnetwork.hu 20080417 changed: krichy(a)tvnetwork.hu 20090814 changed: krichy(a)tvnetwork.hu 20090814 source: RIPE # Filtered >From https://apps.db.ripe.net/webupdates/search.html altough I can query the full object: mntner: MNT-RK1387-RIPE descr: Maintainer of RK1387-RIPE admin-c: RK1387-RIPE upd-to: richardk(a)tvnetwork.hu auth: PGPKEY-8F59B1B7 auth: X509-2577 mnt-by: MNT-RK1387-RIPE referral-by: MNT-RK1387-RIPE changed: richardk(a)tvnetwork.hu 20080417 changed: krichy(a)tvnetwork.hu 20090814 changed: krichy(a)tvnetwork.hu 20090814 source: RIPE And as I am used to copy-paste the result, change what I like, and then send it back, this does not work anymore. Any suggestions are welcome. Regards, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt.

5 7

Re: [members-discuss] why is it proving impossible to gain IP sapce
by Brandon Butterworth 17 Feb '12

17 Feb '12

> Well I looked and saw that out of the top 45,000 Alexa ranked sites, > that 100 are on the IPV6 launch list, not exactly inspiring. I'd put the BBC on but the timing is bad. I was planning for the previously discussed 01-01-2013 which is easy in the post Olympic chill out. June isn't, everything is being finished ready for lock down. brandon

5 4

Re: [members-discuss] Surprise on renew fees
by poty＠iiat.ru 17 Feb '12

17 Feb '12

> -----Original Message----- > From: members-discuss-bounces(a)ripe.net [mailto:members-discuss- > bounces(a)ripe.net] On Behalf Of Comunicaciones ACOTELSA > Sent: Wednesday, December 14, 2011 2:18 PM > To: members-discuss(a)ripe.net > Subject: Re: [members-discuss] Surprise on renew fees > ... > > And I don´t like speak about the general meetings to deal the new > charge scheme because in my enterprise, with only one /26 IPv4, we > can´t pay the cost to go to the general meeting (travel, salary) and I > and imagine that there are more like us so only the big enterprise can > assist, negotiate and vote (although we can use the internet vote). Yes! You knew this! Why you don't use your vote rights through the Internet then? It doesn't rise you expenses and you have had the full ability to vote for all questions since this year! Many LIRs got the opportunity at the last meeting. Our company can't (like yours) go to each general meeting, but I took every opportunity for 3 year already to vote electronically! > > In resume, I can't understand why a foundation increase its expenses > year over year. If you don't take part in the community discussions and don't vote - you'll never know why. You can read all about last GM and learn that for the coming year RIPE NCC will publish expenses in more details. You can suggest to eliminate an activity to lower the overall cost and if you have support - the increases may stop! Regards, Vladislav Potapov Ru.iiat

3 2

Re: [members-discuss] why is it proving impossible to gain IP sapce
by Brandon Butterworth 16 Feb '12

16 Feb '12

> Google: chinese olympics ipv6 google UK olympics ipv6 > Happened in 2008 nuff said not happening in 2012, really lame (not just BBC site) > Every large site today being served by load balancers today can turn on ipv6 I know, we can, I had it running for v6 day. If we'd started a year ago it could have been in the plan for this June but Vint said 2013 and no other announcements were made until Jan. Too late, ops had already decided making it production wasn't high enough up their list until of stuff that really must work for the Olympics. Tough, would have been good to do. brandon

6 6

Re: [members-discuss] why is it proving impossible to gain IP sapce
by Brandon Butterworth 16 Feb '12

16 Feb '12

> > I'd put the BBC on but the timing is bad. I was planning for > > the previously discussed 01-01-2013 which is easy in the > > post Olympic chill out. June isn't, everything is being > > finished ready for lock down. > > So what about "tomorrow"? Or is this bad again, because it's Friday? There is that, it is also still before the Olympics (OK, you wanted a tl;dr explanation but that also can mean too long, didn't write) brandon

1 0

Re: [members-discuss] Problem transit traffic
by Sven Olaf Kamphuis 15 Feb '12

15 Feb '12

9198 smells like a potential pakistan telecom vs youtube 2.0 case anyway (just that the damage is limited to people "close to them" in terms of asn-hops) ppl that relay bgp announcements but not the corresponding traffic (unmodified even, except for ttl and checksum) break the internet. if they want to firewall stuff (or otherwise interfere with the content of individual packets), they should do it a layer -behind- any routers that pass on prefixes that are not theirs to other multihomed asn's On Wed, 15 Feb 2012, Chris Wilson wrote: > > No! > > What if there are single-homed networks behind 9198, or if your other full > table provider chooses 9198 routes as well? > > Given what you're trying to achieve, you cannot ignore these advertisements, > but need to make them less preferable when compared with other routes to the > same prefix range. > > > > Chris > > > > On Wed, 15 Feb 2012, Sven Olaf Kamphuis wrote: > >> >> neighbor 1.2.3.4 filter-list incoming-transits in >> >> (on each of your neighbors) >> ... >> >> ip as-path access-list incoming-transits deny _9198_ >> ip as-path access-list incoming-transits permit _9198$ >> ... >> >> >> should basically prevent your routers from sending outgoing traffic over >> any path that contains 9198, yet allowing 9198's own prefixes (as you do >> want to reach their customers i guess ;) but just make sure its them >> (9198) that are "broken" (and that you have a full table on the other one >> as well ;) >> >> >> >> >> -- >> Greetings, >> >> Sven Olaf Kamphuis, >> CB3ROB Ltd. & Co. KG >> ========================================================================= >> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >> D-13359 Registration: HRA 42834 B >> BERLIN Phone: +31/(0)87-8747479 >> Germany GSM: +49/(0)152-26410799 >> RIPE: CBSK1-RIPE e-Mail: sven(a)cb3rob.net >> ========================================================================= >> <penpen> C3P0, der elektrische Westerwelle >> http://www.facebook.com/cb3rob >> ========================================================================= >> >> Confidential: Please be advised that the information contained in this >> email message, including all attached documents or files, is privileged >> and confidential and is intended only for the use of the individual or >> individuals addressed. Any other use, dissemination, distribution or >> copying of this communication is strictly prohibited. >> >> >> On Wed, 15 Feb 2012, Sven Olaf Kamphuis wrote: >> >>> as he sees 2 routes, only one of which contains 9198, he could just >> filter >>> incoming routes which contain 9198 if that's the party sending prefixes >> and >>> then not relaying the traffic towards them (which kinda breaks things ;) >>> >>> alternatively just drop the 12997 neighbor sesssion alltogether, if a >>> significant number of routes they give you go over 9198, and 9198 is the >> one >>> breaking things. >>> >>> -- >>> Greetings, >>> >>> Sven Olaf Kamphuis, >>> CB3ROB Ltd. & Co. KG >>> >> ========================================================================= >>> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >>> D-13359 Registration: HRA 42834 B >>> BERLIN Phone: +31/(0)87-8747479 >>> Germany GSM: +49/(0)152-26410799 >>> RIPE: CBSK1-RIPE e-Mail: sven(a)cb3rob.net >>> >> ========================================================================= >>> <penpen> C3P0, der elektrische Westerwelle >>> http://www.facebook.com/cb3rob >>> >> ========================================================================= >>> >>> Confidential: Please be advised that the information contained in this >>> email message, including all attached documents or files, is privileged >>> and confidential and is intended only for the use of the individual or >>> individuals addressed. Any other use, dissemination, distribution or >>> copying of this communication is strictly prohibited. >>> >>> >>> On Wed, 15 Feb 2012, Gairat Ismoilzoda wrote: >>> >>>> Dear , >>> I think he want to say, the Kazakhtelecomm(AS9198) block gmail.com, >>> blogspot.com, livejournal.com >>> etc. Can the RIPE to solve this problem? >>>> >>>> On 15/02/2012, at 10.08, Azamat Soyuzbekov wrote: >>>> >>>>> >>>>> Our two path. (Our AS50223) Example: >>>>> *> 2.16.56.0/23 212.42.96. 0 260 0 8449 3216 >> 2914 >>>>> 4436 20940 20940 i >>>>> * 213.145.131. 0 255 0 12997 9198 >>>>> 20485 3549 20940 20940 i >>>>> by 8449 it works, but through the 12997 does not work. >>>>> 12997 says that 9198 blocks. On many forums, users are complaining >> that >>>>> the 9198 block sites. >>>>> On the request is silent and does not meet. >>>> >>>> Please try explaining with more words, having to do an interrogation by >> >>>> email is so annoying and >>>> slow. >>>> Even if your english skills are less than perfect, try :-) (I guess >> most of >>>> the RIPE participants >>>> don't have english as a native language anyway) >>>> >>>> So, from above I guess: >>>> >>>> you are AS50223 Alfa Telecom CJSC located in Kyrgyzstan peering with >> AS8449 >>>> Join Venture Company >>>> "ElCat" and AS12997 JSC Kyrgyztelecom >>>> >>>> According to bgp.he.net you announce these prefixes: >>>> 46.251.192.0/19 Alfa Telecom CJSC >>>> 46.251.200.0/22 Alfa Telecom CJSC >>>> 109.71.224.0/21 Alfa Telecom CJSC >>>> 109.71.224.0/22 Alfa Telecom CJSC >>>> 109.71.228.0/22 Alfa Telecom CJSC >>>> >>>> According to RIPE RIS you have these: >>>> Prefix Size Last seen First seen Whois Registry Peers seeing >>>> 46.251.200.0/22 22 2012-02-15 08:00:00 UTC 2011-10-19 >> 07:58:53 >>>> UTC W RIPE NCC 95 >>>> 109.71.228.0/23 23 2012-02-15 08:00:00 UTC 2011-04-30 >> 16:55:04 >>>> UTC W RIPE NCC 2 >>>> 109.71.228.0/22 22 2012-02-15 08:00:00 UTC 2012-01-19 >> 08:43:07 >>>> UTC W RIPE NCC 101 >>>> 109.71.224.0/22 22 2012-02-15 08:00:00 UTC 2011-10-14 >> 21:34:10 >>>> UTC W RIPE NCC 95 >>>> 109.71.224.0/21 21 2012-02-15 08:00:00 UTC 2011-10-14 >> 21:34:08 >>>> UTC W RIPE NCC 103 >>>> 109.71.230.0/23 23 2012-02-15 08:00:00 UTC 2011-10-14 >> 21:31:32 >>>> UTC W RIPE NCC 2 >>>> 46.251.192.0/19 19 2012-02-15 08:00:00 UTC 2011-10-14 >> 21:34:08 >>>> UTC W RIPE NCC 103 >>>> >>>> >>>> The route you mention >>>> route: 2.16.56.0/23 >>>> descr: Akamai Technologies >>>> origin: AS20940 >>>> and is part of 2.16.0.0/13 >>>> >>>> BTW I see these on some of my routers as: >>>> 2.16.56.0/23 *[BGP/170] 2d 09:41:05, MED 3593, localpref 110 >>>> AS path: 3549 20940 20940 I >>>> > to 64.211.195.225 via xe-5/0/0.0 >>>> [BGP/170] 4w0d 23:14:11, localpref 100 >>>> AS path: 16245 3292 20940 I >>>> > to 83.221.128.125 via xe-2/0/0.0 >>>> >>>> 2.16.56.0/23 *[BGP/170] 2d 09:41:14, MED 3593, localpref 110 >>>> AS path: 3549 20940 20940 I >>>> > to 109.238.48.254 via ae0.94 >>>> [BGP/170] 1w6d 08:06:05, MED 0, localpref 110 >>>> AS path: 3356 3549 20940 20940 I >>>> > to 213.242.108.9 via xe-2/0/0.0 >>>> So it would seem you have received these Akamai prefixes correctly, a >> good >>>> start >>>> >>>> Then hopefully we can get down to your problem. >>>> >>>> "I have to you have a question? If an ISP blocks the transit traffic is >> >>>> what rules they break, and >>>> if we can resolve this issue through Ripe?" >>>> >>>> and >>>> " >>>> Our two path. (Our AS50223) Example: >>>> *> 2.16.56.0/23 212.42.96. 0 260 0 8449 3216 >> 2914 >>>> 4436 20940 20940 i >>>> * 213.145.131. 0 255 0 12997 9198 >> 20485 >>>> 3549 20940 20940 i >>>> by 8449 it works, but through the 12997 does not work. >>>> 12997 says that 9198 blocks. On many forums, users are complaining that >> the >>>> 9198 block sites. >>>> On the request is silent and does not meet. >>>> " >>>> >>>> Do you have a problem reaching Akamai - do you have problems reaching >> other >>>> destinations? >>>> Do other have problems reaching you? >>>> >>>> Do you have problems with all your own prefixes/addresses? >>>> >>>> Can you use some traffic - like doing ping? but not UDP? or TCP? >>>> >>>> Include more information such as destination addresses tried, and >>>> traceroutes to known >>>> destinations that should work. >>>> - I would do the test from each of your own prefixes >>>> >>>> More information is need to help you :-) >>>> >>>> >>>> >>>> BTW I found most of this on: >>>> http://bgp.he.net/AS50223 >>>> http://bgp.he.net/AS9198 >>>> >>>> >>>> Let us know if there is something wrong in the things we guess, so we >> can >>>> get to the matter of the >>>> problem :-) >>>> >>>> >>>> Best regards >>>> >>>> Henrik >>>> >>>> -- >>>> Henrik Lund Kramshøj, Follower of the Great Way of Unix >>>> hlk(a)kramse.org hlk(a)solidonetworks.com >>>> +45 2026 6000 cand.scient CISSP CEH >>>> http://solidonetworks.com/ Network Security is a business enabler >>>> >>>> >>>> >>>> >>>> >>>> ---- >>>> If you don't want to receive emails from the RIPE NCC members-discuss >>>> mailing list, please log in to your LIR Portal account and go to the >>>> general page: >>>> https://lirportal.ripe.net/general/view >>>> >>>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From >>>> here, you can add or remove >>>> addresses. >>>> >>> >>> >>> -- >>> Best regards, >>> Ismoilov Gairatjon >>> ATK Telecomm Technology >>> Internet Service Provider >>> 734002,Tajikistan,Dushanbe str. Bokhtar 35/1 >>> tel.: (992 48) 7010045,7010043 >>> Mob.: (992 93)5002202 >>> >>> >>> >>> ---- >>> If you don't want to receive emails from the RIPE NCC members-discuss >>> mailing list, please log in to your LIR Portal account and go to the >> general >>> page: >>> https://lirportal.ripe.net/general/view >>> >>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From >> here, >>> you can add or remove addresses. >

1 0

Re: [members-discuss] Problem transit traffic
by Sven Olaf Kamphuis 15 Feb '12

15 Feb '12

On Wed, 15 Feb 2012, Chris Wilson wrote: > > No! > > What if there are single-homed networks behind 9198, or if your other full > table provider chooses 9198 routes as well? then i guess it's time for 9198 to learn not to relay prefixes and then not relay the packets for them :P nothin creates as much force on a telco as complaining customers *grin* (+/- 15 euros per support call or something ;) > Given what you're trying to achieve, you cannot ignore these advertisements, > but need to make them less preferable when compared with other routes to the > same prefix range. true, but that's slightly more complicated. > > > > Chris > > > > On Wed, 15 Feb 2012, Sven Olaf Kamphuis wrote: > >> >> neighbor 1.2.3.4 filter-list incoming-transits in >> >> (on each of your neighbors) >> ... >> >> ip as-path access-list incoming-transits deny _9198_ >> ip as-path access-list incoming-transits permit _9198$ >> ... >> >> >> should basically prevent your routers from sending outgoing traffic over >> any path that contains 9198, yet allowing 9198's own prefixes (as you do >> want to reach their customers i guess ;) but just make sure its them >> (9198) that are "broken" (and that you have a full table on the other one >> as well ;) >> >> >> >> >> -- >> Greetings, >> >> Sven Olaf Kamphuis, >> CB3ROB Ltd. & Co. KG >> ========================================================================= >> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >> D-13359 Registration: HRA 42834 B >> BERLIN Phone: +31/(0)87-8747479 >> Germany GSM: +49/(0)152-26410799 >> RIPE: CBSK1-RIPE e-Mail: sven(a)cb3rob.net >> ========================================================================= >> <penpen> C3P0, der elektrische Westerwelle >> http://www.facebook.com/cb3rob >> ========================================================================= >> >> Confidential: Please be advised that the information contained in this >> email message, including all attached documents or files, is privileged >> and confidential and is intended only for the use of the individual or >> individuals addressed. Any other use, dissemination, distribution or >> copying of this communication is strictly prohibited. >> >> >> On Wed, 15 Feb 2012, Sven Olaf Kamphuis wrote: >> >>> as he sees 2 routes, only one of which contains 9198, he could just >> filter >>> incoming routes which contain 9198 if that's the party sending prefixes >> and >>> then not relaying the traffic towards them (which kinda breaks things ;) >>> >>> alternatively just drop the 12997 neighbor sesssion alltogether, if a >>> significant number of routes they give you go over 9198, and 9198 is the >> one >>> breaking things. >>> >>> -- >>> Greetings, >>> >>> Sven Olaf Kamphuis, >>> CB3ROB Ltd. & Co. KG >>> >> ========================================================================= >>> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >>> D-13359 Registration: HRA 42834 B >>> BERLIN Phone: +31/(0)87-8747479 >>> Germany GSM: +49/(0)152-26410799 >>> RIPE: CBSK1-RIPE e-Mail: sven(a)cb3rob.net >>> >> ========================================================================= >>> <penpen> C3P0, der elektrische Westerwelle >>> http://www.facebook.com/cb3rob >>> >> ========================================================================= >>> >>> Confidential: Please be advised that the information contained in this >>> email message, including all attached documents or files, is privileged >>> and confidential and is intended only for the use of the individual or >>> individuals addressed. Any other use, dissemination, distribution or >>> copying of this communication is strictly prohibited. >>> >>> >>> On Wed, 15 Feb 2012, Gairat Ismoilzoda wrote: >>> >>>> Dear , >>> I think he want to say, the Kazakhtelecomm(AS9198) block gmail.com, >>> blogspot.com, livejournal.com >>> etc. Can the RIPE to solve this problem? >>>> >>>> On 15/02/2012, at 10.08, Azamat Soyuzbekov wrote: >>>> >>>>> >>>>> Our two path. (Our AS50223) Example: >>>>> *> 2.16.56.0/23 212.42.96. 0 260 0 8449 3216 >> 2914 >>>>> 4436 20940 20940 i >>>>> * 213.145.131. 0 255 0 12997 9198 >>>>> 20485 3549 20940 20940 i >>>>> by 8449 it works, but through the 12997 does not work. >>>>> 12997 says that 9198 blocks. On many forums, users are complaining >> that >>>>> the 9198 block sites. >>>>> On the request is silent and does not meet. >>>> >>>> Please try explaining with more words, having to do an interrogation by >> >>>> email is so annoying and >>>> slow. >>>> Even if your english skills are less than perfect, try :-) (I guess >> most of >>>> the RIPE participants >>>> don't have english as a native language anyway) >>>> >>>> So, from above I guess: >>>> >>>> you are AS50223 Alfa Telecom CJSC located in Kyrgyzstan peering with >> AS8449 >>>> Join Venture Company >>>> "ElCat" and AS12997 JSC Kyrgyztelecom >>>> >>>> According to bgp.he.net you announce these prefixes: >>>> 46.251.192.0/19 Alfa Telecom CJSC >>>> 46.251.200.0/22 Alfa Telecom CJSC >>>> 109.71.224.0/21 Alfa Telecom CJSC >>>> 109.71.224.0/22 Alfa Telecom CJSC >>>> 109.71.228.0/22 Alfa Telecom CJSC >>>> >>>> According to RIPE RIS you have these: >>>> Prefix Size Last seen First seen Whois Registry Peers seeing >>>> 46.251.200.0/22 22 2012-02-15 08:00:00 UTC 2011-10-19 >> 07:58:53 >>>> UTC W RIPE NCC 95 >>>> 109.71.228.0/23 23 2012-02-15 08:00:00 UTC 2011-04-30 >> 16:55:04 >>>> UTC W RIPE NCC 2 >>>> 109.71.228.0/22 22 2012-02-15 08:00:00 UTC 2012-01-19 >> 08:43:07 >>>> UTC W RIPE NCC 101 >>>> 109.71.224.0/22 22 2012-02-15 08:00:00 UTC 2011-10-14 >> 21:34:10 >>>> UTC W RIPE NCC 95 >>>> 109.71.224.0/21 21 2012-02-15 08:00:00 UTC 2011-10-14 >> 21:34:08 >>>> UTC W RIPE NCC 103 >>>> 109.71.230.0/23 23 2012-02-15 08:00:00 UTC 2011-10-14 >> 21:31:32 >>>> UTC W RIPE NCC 2 >>>> 46.251.192.0/19 19 2012-02-15 08:00:00 UTC 2011-10-14 >> 21:34:08 >>>> UTC W RIPE NCC 103 >>>> >>>> >>>> The route you mention >>>> route: 2.16.56.0/23 >>>> descr: Akamai Technologies >>>> origin: AS20940 >>>> and is part of 2.16.0.0/13 >>>> >>>> BTW I see these on some of my routers as: >>>> 2.16.56.0/23 *[BGP/170] 2d 09:41:05, MED 3593, localpref 110 >>>> AS path: 3549 20940 20940 I >>>> > to 64.211.195.225 via xe-5/0/0.0 >>>> [BGP/170] 4w0d 23:14:11, localpref 100 >>>> AS path: 16245 3292 20940 I >>>> > to 83.221.128.125 via xe-2/0/0.0 >>>> >>>> 2.16.56.0/23 *[BGP/170] 2d 09:41:14, MED 3593, localpref 110 >>>> AS path: 3549 20940 20940 I >>>> > to 109.238.48.254 via ae0.94 >>>> [BGP/170] 1w6d 08:06:05, MED 0, localpref 110 >>>> AS path: 3356 3549 20940 20940 I >>>> > to 213.242.108.9 via xe-2/0/0.0 >>>> So it would seem you have received these Akamai prefixes correctly, a >> good >>>> start >>>> >>>> Then hopefully we can get down to your problem. >>>> >>>> "I have to you have a question? If an ISP blocks the transit traffic is >> >>>> what rules they break, and >>>> if we can resolve this issue through Ripe?" >>>> >>>> and >>>> " >>>> Our two path. (Our AS50223) Example: >>>> *> 2.16.56.0/23 212.42.96. 0 260 0 8449 3216 >> 2914 >>>> 4436 20940 20940 i >>>> * 213.145.131. 0 255 0 12997 9198 >> 20485 >>>> 3549 20940 20940 i >>>> by 8449 it works, but through the 12997 does not work. >>>> 12997 says that 9198 blocks. On many forums, users are complaining that >> the >>>> 9198 block sites. >>>> On the request is silent and does not meet. >>>> " >>>> >>>> Do you have a problem reaching Akamai - do you have problems reaching >> other >>>> destinations? >>>> Do other have problems reaching you? >>>> >>>> Do you have problems with all your own prefixes/addresses? >>>> >>>> Can you use some traffic - like doing ping? but not UDP? or TCP? >>>> >>>> Include more information such as destination addresses tried, and >>>> traceroutes to known >>>> destinations that should work. >>>> - I would do the test from each of your own prefixes >>>> >>>> More information is need to help you :-) >>>> >>>> >>>> >>>> BTW I found most of this on: >>>> http://bgp.he.net/AS50223 >>>> http://bgp.he.net/AS9198 >>>> >>>> >>>> Let us know if there is something wrong in the things we guess, so we >> can >>>> get to the matter of the >>>> problem :-) >>>> >>>> >>>> Best regards >>>> >>>> Henrik >>>> >>>> -- >>>> Henrik Lund Kramshøj, Follower of the Great Way of Unix >>>> hlk(a)kramse.org hlk(a)solidonetworks.com >>>> +45 2026 6000 cand.scient CISSP CEH >>>> http://solidonetworks.com/ Network Security is a business enabler >>>> >>>> >>>> >>>> >>>> >>>> ---- >>>> If you don't want to receive emails from the RIPE NCC members-discuss >>>> mailing list, please log in to your LIR Portal account and go to the >>>> general page: >>>> https://lirportal.ripe.net/general/view >>>> >>>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From >>>> here, you can add or remove >>>> addresses. >>>> >>> >>> >>> -- >>> Best regards, >>> Ismoilov Gairatjon >>> ATK Telecomm Technology >>> Internet Service Provider >>> 734002,Tajikistan,Dushanbe str. Bokhtar 35/1 >>> tel.: (992 48) 7010045,7010043 >>> Mob.: (992 93)5002202 >>> >>> >>> >>> ---- >>> If you don't want to receive emails from the RIPE NCC members-discuss >>> mailing list, please log in to your LIR Portal account and go to the >> general >>> page: >>> https://lirportal.ripe.net/general/view >>> >>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From >> here, >>> you can add or remove addresses. >

1 0

FW: Problem transit traffic
by Azamat Soyuzbekov 15 Feb '12

15 Feb '12

Our two path. (Our AS50223) Example: *> 2.16.56.0/23 212.42.96. 0 260 0 8449 3216 2914 4436 20940 20940 i * 213.145.131. 0 255 0 12997 9198 20485 3549 20940 20940 i by 8449 it works, but through the 12997 does not work. 12997 says that 9198 blocks. On many forums, users are complaining that the 9198 block sites. On the request is silent and does not meet.

5 6

Re: [members-discuss] why is it proving impossible to gain IP sapce
by Sven Olaf Kamphuis 15 Feb '12

15 Feb '12

can someone provide an insight into wether ipv4 at ripe has actually run out now? how much is left.. etc :P and can someone at google and facebook and twitter and stuff provide a reason why ipv6 STILL isn't on on their stuff by default (the same goes for ALL german xdsl providers ;) it's not like you lot didn't have millions to spend and years to prepare for it :P On Tue, 14 Feb 2012, Bill Lewis wrote: > hi, > > We have a /21 IP4 and a /32 IP6 and need more IP4... We appreciate the > IP4 pool is very low...but... > > We have been trying to gain more IP4 , a /21 would be good, /20 idealy > as equipment vendors and partners are unfortunately not yet up to speed > with IP6 for production use here and therefore we need more IP4 to > bridge this gap. > > The issue is that it is proving impossible to gain any IP4, it is clear > that we have allocated all we have and are now forced to "rent" IP space > from other LIR's in order to bridge the gap. > > Can somebody tell me why we are paying to be an LIR but are unable to > gain modest extra resources above our initial allocation 3 years ago and > therefore having to resort to renting space privately? > > Perhaps somebody could clarify this please as the last request got to a > point where it was clarified that all the /21 is allocated and > then....nothing... We even were told we had last had an additional > allocation in 2010 which is not true as we joined in 2009 and that is > when we gained the initial and only blocks we have. > > Our first alloc just pushes us into the Small category on its own due to > being a recent-ish LIR and therefore an extra block is unlikely to > increase our fees, is this why? > > > cheers > > Bill > uk.kijoma > > ---- > If you don't want to receive emails from the RIPE NCC members-discuss > mailing list, please log in to your LIR Portal account and go to the general page: > https://lirportal.ripe.net/general/view > > Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. >

4 5