[members-discuss] Problem transit traffic

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.
>