[144812] in North American Network Operators' Group
Re: Saudi Telecom sending route with invalid attributes
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Mon Sep 19 16:59:27 2011
In-Reply-To: <CAL9jLaZr3rfPY4A4vb8cdy9N2hR_8-bB0pzp6o5XY2A1hzsm1Q@mail.gmail.com>
Date: Mon, 19 Sep 2011 16:58:00 -0400
From: Christopher Morrow <morrowc.lists@gmail.com>
To: "Schiller, Heather A" <heather.schiller@verizon.com>, info@irnetco.net
Cc: "Jonas Frey \(Probe Networks\)" <jf@probe-networks.de>,
"nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
suliman.alzain@saudi.net.sa - bounces :( Ripe folks (if listening)
perhaps you could ping the other live POC's there and request an
update? :)
On Mon, Sep 19, 2011 at 4:54 PM, Christopher Morrow
<morrowc.lists@gmail.com> wrote:
> In the off chance that no one already attempted an email to the folks
> nominally in charge there:
>
> person: =A0 =A0 =A0 =A0 Hejji almazroua
> address: =A0 =A0 =A0 =A0SaudiNet
> address: =A0 =A0 =A0 =A0P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> phone: =A0 =A0 =A0 =A0 =A0+9661 218 0300
> fax-no: =A0 =A0 =A0 =A0 +9661 218 0311
> e-mail: =A0 =A0 =A0 =A0 info@irnetco.net
> nic-hdl: =A0 =A0 =A0 =A0Ha125-RIPE
> mnt-by: =A0 =A0 =A0 =A0 irnetco-ripe-mnt
> source: =A0 =A0 =A0 =A0 RIPE # Filtered
>
> person: =A0 =A0 =A0 Suliman I. Al-Zain
> address: =A0 =A0 =A0Saudi Telecom Co. (SaudiNet)
> address: =A0 =A0 =A0P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> phone: =A0 =A0 =A0 =A0+9661 218 2034
> fax-no: =A0 =A0 =A0 +9661 218 0311
> e-mail: =A0 =A0 =A0 suliman.alzain@saudi.net.sa
> nic-hdl: =A0 =A0 =A0SA702-RIPE
> source: =A0 =A0 =A0 RIPE # Filtered
>
>
> Do the Saudi-Telecom folks have a method to suppress the /24
> (212.118.142.0/24) which is also covered by: 212.118.128.0/19
>
> it'd really help lots of other Internet folk if you'd suppress this /24 .=
..
>
> -chris
>
> On Mon, Sep 19, 2011 at 3:26 PM, Schiller, Heather A
> <heather.schiller@verizon.com> wrote:
>>
>> Seeing it again here too.. Has anyone contacted them?
>>
>> ..and for folks who are choosing to blackhole the prefix in order to sup=
ress the route, please remember not to export it!
>>
>> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet =A0 =A0 2011=
-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
>> AS8866 =A0BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08 18:=
35:14 UTC 2011-09-19 19:15:42 UTC
>> AS10026 PACNET Pacnet Global Ltd =A0 =A0 =A0 =A02011-09-11 02:41:40 UTC =
2011-09-19 16:00:00 UTC
>> AS8767 =A0MNET-AS M-net AS =A0 =A0 =A0 =A02011-09-14 12:13:01 UTC 2011-0=
9-14 12:14:00 UTC
>> AS3561 =A0SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18 UT=
C
>> AS3549 =A0GBLX Global Crossing Ltd. =A0 =A0 =A0 2011-09-09 16:13:15 UTC =
2011-09-09 17:05:38 UTC
>> AS1239 =A0SPRINTLINK - Sprint =A0 =A0 2011-09-09 03:18:28 UTC 2011-09-09=
15:56:41 UTC
>> AS65000 -Private Use AS- =A0 =A0 =A0 =A02011-09-08 18:34:28 UTC 2011-09-=
08 18:34:29 UTC
>>
>> =A0--heather
>>
>> -----Original Message-----
>> From: Ryan Gray [mailto:ryan@longlines.com]
>> Sent: Monday, September 19, 2011 3:09 PM
>> To: Schiller, Heather A
>> Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks); nanog@n=
anog.org
>> Subject: Re: Saudi Telecom sending route with invalid attributes 212.118=
.142.0/24
>>
>> Actually just started seeing these problems again today. =A0Is anyone el=
se seeing this today from something other than 212.118.142.0/24? =A0Looks l=
ike it started about two hours ago.
>>
>>
>> Regards,
>> Ryan Gray
>> Long Lines
>> www.longlines.com
>>
>>
>>
>>
>>
>> On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:
>>
>>>
>>> Could be this..?
>>>
>>> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi
>>> guration-statement/independent-domain-edit-routing-options.html
>>>
>>> "unrecognized transitive attributes" depend on whatever code version yo=
u are running... What's more important is how the unrecoginized attribute i=
s handled. =A0Ideally you accept and pass the route and log it. =A0The prob=
lem is with devices that aren't so graceful.. dropping sessions and wreakin=
g havoc:
>>>
>>> http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
>>>
>>> --Heather
>>>
>>> -----Original Message-----
>>> From: Aftab Siddiqui [mailto:aftab.siddiqui@gmail.com]
>>> Sent: Saturday, September 10, 2011 6:49 PM
>>> To: Richard Barnes
>>> Cc: Jonas Frey (Probe Networks); nanog@nanog.org
>>> Subject: Re: Saudi Telecom sending route with invalid attributes
>>> 212.118.142.0/24
>>>
>>> with in the span of couple of hours this prefix was originated from 3 A=
SN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians)=
.
>>>
>>> As per the STC it was orginated by one of their customer having Juniper=
router. but I still don't understand why/how they are adv this prefix with=
unrecog transitive attributes.
>>>
>>> Can any one suggest.
>>>
>>> Regards,
>>>
>>> Aftab A. Siddiqui
>>>
>>>
>>> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes@gmail.c=
om>wrote:
>>>
>>>> Looks like the RIS collectors are seeing it originating mostly from
>>>> STC and KACST ASNs:
>>>> <http://stat.ripe.net/212.118.142.0/24>
>>>>
>>>> Some of the "show ip bgp" reports on that screen are also showing
>>>> AS8866 "BTC-AS Bulgarian Telecommunication Company". =A0Not sure what'=
s
>>>> up with that.
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
>>>> <morrowc.lists@gmail.com> wrote:
>>>>> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle@gmail.com>
>>>> wrote:
>>>>>> Is this announcement still showing up this way (no easy way to
>>>>>> check myself).
>>>>>
>>>>> ripe ris?
>>>>>
>>>>>> -Kyle
>>>>>>
>>>>>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes
>>>>>> <chaynes@centracomm.net>
>>>> wrote:
>>>>>>
>>>>>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
>>>>>>> jf@probe-networks.de> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> anyone else getting a route for 212.118.142.0/24 with invalid
>>>>>>>> attributes? Seems this is (again) causing problems with some
>>>>>>>> (older) routers/software.
>>>>>>>>
>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Announcement bits (4): 0-KRT 3-KRT 5-Re=
solve tree
>>>>>>>> 1 6-Resolve tree 2
>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 AS path: 6453 39386 25019 I Unrecogniz=
ed Attributes:
>>>> 39
>>>>>>>> bytes
>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 AS path: =A0Attr flags e0 code 80: 00 =
00 fd 88 40
>>>>>>>> 01 01
>>>> 02
>>>>>>>> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40
>>>>>>>> 05
>>>> 04
>>>>>>>> 00 00 00 64
>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Accepted Multipath
>>>>>>>>
>>>>>>>>
>>>>>>>> -Jonas
>>>>>>>>
>>>>>>>>
>>>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>>>> Originating AS is 25019
>>>>>>>
>>>>>>> -Clay
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
