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@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@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
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
2914 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@kramse.org hlk@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.