This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[members-discuss] Problem transit traffic
- Previous message (by thread): [members-discuss] Problem transit traffic
- Next message (by thread): [members-discuss] Problem transit traffic
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sven Olaf Kamphuis
sven at cb3rob.net
Wed Feb 15 15:41:35 CET 2012
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 at 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 at 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 at kramse.org hlk at 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. >
- Previous message (by thread): [members-discuss] Problem transit traffic
- Next message (by thread): [members-discuss] Problem transit traffic
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]