Mailing List Archive

Saudi Telecom sending route with invalid attributes 212.118.142.0/24
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.

Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
AS path: 6453 39386 25019 I Unrecognized Attributes: 39
bytes
AS path: Attr 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
Accepted Multipath


-Jonas
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
Hi!

> 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.
>
> Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
> 6-Resolve tree 2
> AS path: 6453 39386 25019 I Unrecognized Attributes: 39
> bytes
> AS path: Attr 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
> Accepted Multipath

Exactly the same here.

Sep 8 20:24:04 BBD-RC02 rpd[1334]: Received BAD update from
94.228.128.57 (External AS 41887), aspath_attr():3472
PA4_TYPE_ATTRSET(128) => 1 times IGNORED, family inet-unicast(1), prefix
212.118.142.0/24

Bye,
Raymond.
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
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.
>
> Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
> 6-Resolve tree 2
> AS path: 6453 39386 25019 I Unrecognized Attributes: 39
> bytes
> AS path: Attr 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
> Accepted Multipath
>
>
> -Jonas
>
>
Yup! We're seeing the same thing too, and we're filtering it out.
Originating AS is 25019

-Clay
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
Is this announcement still showing up this way (no easy way to check
myself).

-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.
> >
> > Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
> > 6-Resolve tree 2
> > AS path: 6453 39386 25019 I Unrecognized Attributes: 39
> > bytes
> > AS path: Attr 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
> > Accepted Multipath
> >
> >
> > -Jonas
> >
> >
> Yup! We're seeing the same thing too, and we're filtering it out.
> Originating AS is 25019
>
> -Clay
>
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
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.
>> >
>> >               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
>> > 6-Resolve tree 2
>> >                AS path: 6453 39386 25019 I Unrecognized Attributes: 39
>> > bytes
>> >                AS path:  Attr 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
>> >                Accepted Multipath
>> >
>> >
>> > -Jonas
>> >
>> >
>> Yup! We're seeing the same thing too, and we're filtering it out.
>> Originating AS is 25019
>>
>> -Clay
>>
>
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
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". Not 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.
>>> >
>>> >               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
>>> > 6-Resolve tree 2
>>> >                AS path: 6453 39386 25019 I Unrecognized Attributes: 39
>>> > bytes
>>> >                AS path:  Attr 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
>>> >                Accepted Multipath
>>> >
>>> >
>>> > -Jonas
>>> >
>>> >
>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>> Originating AS is 25019
>>>
>>> -Clay
>>>
>>
>
>
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
with in the span of couple of hours this prefix was originated from 3 ASN
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.com>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". Not 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.
> >>> >
> >>> > Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
> >>> > 6-Resolve tree 2
> >>> > AS path: 6453 39386 25019 I Unrecognized Attributes:
> 39
> >>> > bytes
> >>> > AS path: Attr 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
> >>> > Accepted Multipath
> >>> >
> >>> >
> >>> > -Jonas
> >>> >
> >>> >
> >>> Yup! We're seeing the same thing too, and we're filtering it out.
> >>> Originating AS is 25019
> >>>
> >>> -Clay
> >>>
> >>
> >
> >
>
>
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
On Sun, Sep 11, 2011 at 8:49 AM, Aftab Siddiqui
<aftab.siddiqui@gmail.com> wrote:
> with in the span of couple of hours this prefix was originated from 3 ASN
> 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.

For example, AS_CONFED_SEQUENCE and/or AS_CONFED_SET in AS4_PATH again..;(

> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes@gmail.com>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".  Not 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.
>> >>> >
>> >>> >               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
>> >>> > 6-Resolve tree 2
>> >>> >                AS path: 6453 39386 25019 I Unrecognized Attributes:
>> 39
>> >>> > bytes
>> >>> >                AS path:  Attr 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
>> >>> >                Accepted Multipath
>> >>> >
>> >>> >
>> >>> > -Jonas
>> >>> >
>> >>> >
>> >>> Yup! We're seeing the same thing too, and we're filtering it out.
>> >>> Originating AS is 25019
>> >>>
>> >>> -Clay
>> >>>
>> >>
>> >
>> >
>>
>>
>



--
SY, Jen Linkova aka Furry
RE: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
Could be this..?

http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/configuration-statement/independent-domain-edit-routing-options.html

"unrecognized transitive attributes" depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled. Ideally you accept and pass the route and log it. The problem is with devices that aren't so graceful.. dropping sessions and wreaking 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 ASN 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.com>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". Not 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.
> >>> >
> >>> > Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
> >>> > 1 6-Resolve tree 2
> >>> > AS path: 6453 39386 25019 I Unrecognized Attributes:
> 39
> >>> > bytes
> >>> > AS path: Attr 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
> >>> > Accepted Multipath
> >>> >
> >>> >
> >>> > -Jonas
> >>> >
> >>> >
> >>> Yup! We're seeing the same thing too, and we're filtering it out.
> >>> Originating AS is 25019
> >>>
> >>> -Clay
> >>>
> >>
> >
> >
>
>
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 [ In reply to ]
Actually just started seeing these problems again today. Is anyone else seeing this today from something other than 212.118.142.0/24? Looks like 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/configuration-statement/independent-domain-edit-routing-options.html
>
> "unrecognized transitive attributes" depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled. Ideally you accept and pass the route and log it. The problem is with devices that aren't so graceful.. dropping sessions and wreaking 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 ASN 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.com>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". Not 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.
>>>>>>
>>>>>> Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>>>>>> 1 6-Resolve tree 2
>>>>>> AS path: 6453 39386 25019 I Unrecognized Attributes:
>> 39
>>>>>> bytes
>>>>>> AS path: Attr 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
>>>>>> Accepted Multipath
>>>>>>
>>>>>>
>>>>>> -Jonas
>>>>>>
>>>>>>
>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>> Originating AS is 25019
>>>>>
>>>>> -Clay
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
RE: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 - Redux [ In reply to ]
Seeing it again here too.. Has anyone contacted them?

..and for folks who are choosing to blackhole the prefix in order to supress the route, please remember not to export it!

AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
AS8866 BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08 18:35:14 UTC 2011-09-19 19:15:42 UTC
AS10026 PACNET Pacnet Global Ltd 2011-09-11 02:41:40 UTC 2011-09-19 16:00:00 UTC
AS8767 MNET-AS M-net AS 2011-09-14 12:13:01 UTC 2011-09-14 12:14:00 UTC
AS3561 SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18 UTC
AS3549 GBLX Global Crossing Ltd. 2011-09-09 16:13:15 UTC 2011-09-09 17:05:38 UTC
AS1239 SPRINTLINK - Sprint 2011-09-09 03:18:28 UTC 2011-09-09 15:56:41 UTC
AS65000 -Private Use AS- 2011-09-08 18:34:28 UTC 2011-09-08 18:34:29 UTC

--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@nanog.org
Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24

Actually just started seeing these problems again today. Is anyone else seeing this today from something other than 212.118.142.0/24? Looks like 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 you are running... What's more important is how the unrecoginized attribute is handled. Ideally you accept and pass the route and log it. The problem is with devices that aren't so graceful.. dropping sessions and wreaking 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 ASN 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.com>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". Not 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.
>>>>>>
>>>>>> Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>>>>>> 1 6-Resolve tree 2
>>>>>> AS path: 6453 39386 25019 I Unrecognized Attributes:
>> 39
>>>>>> bytes
>>>>>> AS path: Attr 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
>>>>>> Accepted Multipath
>>>>>>
>>>>>>
>>>>>> -Jonas
>>>>>>
>>>>>>
>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>> Originating AS is 25019
>>>>>
>>>>> -Clay
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 - Redux [ In reply to ]
In the off chance that no one already attempted an email to the folks
nominally in charge there:

person: Hejji almazroua
address: SaudiNet
address: P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
phone: +9661 218 0300
fax-no: +9661 218 0311
e-mail: info@irnetco.net
nic-hdl: Ha125-RIPE
mnt-by: irnetco-ripe-mnt
source: RIPE # Filtered

person: Suliman I. Al-Zain
address: Saudi Telecom Co. (SaudiNet)
address: P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
phone: +9661 218 2034
fax-no: +9661 218 0311
e-mail: suliman.alzain@saudi.net.sa
nic-hdl: SA702-RIPE
source: 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 supress the route, please remember not to export it!
>
> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet     2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
> AS8866  BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08 18:35:14 UTC 2011-09-19 19:15:42 UTC
> AS10026 PACNET Pacnet Global Ltd        2011-09-11 02:41:40 UTC 2011-09-19 16:00:00 UTC
> AS8767  MNET-AS M-net AS        2011-09-14 12:13:01 UTC 2011-09-14 12:14:00 UTC
> AS3561  SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18 UTC
> AS3549  GBLX Global Crossing Ltd.       2011-09-09 16:13:15 UTC 2011-09-09 17:05:38 UTC
> AS1239  SPRINTLINK - Sprint     2011-09-09 03:18:28 UTC 2011-09-09 15:56:41 UTC
> AS65000 -Private Use AS-        2011-09-08 18:34:28 UTC 2011-09-08 18:34:29 UTC
>
>  --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@nanog.org
> Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
>
> Actually just started seeing these problems again today.  Is anyone else seeing this today from something other than 212.118.142.0/24?  Looks like 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 you are running... What's more important is how the unrecoginized attribute is handled.  Ideally you accept and pass the route and log it.  The problem is with devices that aren't so graceful.. dropping sessions and wreaking 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 ASN 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.com>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".  Not 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.
>>>>>>>
>>>>>>>              Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>>>>>>> 1 6-Resolve tree 2
>>>>>>>               AS path: 6453 39386 25019 I Unrecognized Attributes:
>>> 39
>>>>>>> bytes
>>>>>>>               AS path:  Attr 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
>>>>>>>               Accepted Multipath
>>>>>>>
>>>>>>>
>>>>>>> -Jonas
>>>>>>>
>>>>>>>
>>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>>> Originating AS is 25019
>>>>>>
>>>>>> -Clay
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 - Redux [ In reply to ]
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:         Hejji almazroua
> address:        SaudiNet
> address:        P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> phone:          +9661 218 0300
> fax-no:         +9661 218 0311
> e-mail:         info@irnetco.net
> nic-hdl:        Ha125-RIPE
> mnt-by:         irnetco-ripe-mnt
> source:         RIPE # Filtered
>
> person:       Suliman I. Al-Zain
> address:      Saudi Telecom Co. (SaudiNet)
> address:      P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> phone:        +9661 218 2034
> fax-no:       +9661 218 0311
> e-mail:       suliman.alzain@saudi.net.sa
> nic-hdl:      SA702-RIPE
> source:       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 supress the route, please remember not to export it!
>>
>> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet     2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
>> AS8866  BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08 18:35:14 UTC 2011-09-19 19:15:42 UTC
>> AS10026 PACNET Pacnet Global Ltd        2011-09-11 02:41:40 UTC 2011-09-19 16:00:00 UTC
>> AS8767  MNET-AS M-net AS        2011-09-14 12:13:01 UTC 2011-09-14 12:14:00 UTC
>> AS3561  SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18 UTC
>> AS3549  GBLX Global Crossing Ltd.       2011-09-09 16:13:15 UTC 2011-09-09 17:05:38 UTC
>> AS1239  SPRINTLINK - Sprint     2011-09-09 03:18:28 UTC 2011-09-09 15:56:41 UTC
>> AS65000 -Private Use AS-        2011-09-08 18:34:28 UTC 2011-09-08 18:34:29 UTC
>>
>>  --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@nanog.org
>> Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
>>
>> Actually just started seeing these problems again today.  Is anyone else seeing this today from something other than 212.118.142.0/24?  Looks like 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 you are running... What's more important is how the unrecoginized attribute is handled.  Ideally you accept and pass the route and log it.  The problem is with devices that aren't so graceful.. dropping sessions and wreaking 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 ASN 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.com>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".  Not 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.
>>>>>>>>
>>>>>>>>              Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>>>>>>>> 1 6-Resolve tree 2
>>>>>>>>               AS path: 6453 39386 25019 I Unrecognized Attributes:
>>>> 39
>>>>>>>> bytes
>>>>>>>>               AS path:  Attr 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
>>>>>>>>               Accepted Multipath
>>>>>>>>
>>>>>>>>
>>>>>>>> -Jonas
>>>>>>>>
>>>>>>>>
>>>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>>>> Originating AS is 25019
>>>>>>>
>>>>>>> -Clay
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
RE: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 - Redux [ In reply to ]
Hi Chris,

I've send an email to the person I know within STC responsible for
international transit.

Let's hope he can assist.

Regards,
Erik Bais

> -----Original Message-----
> From: Christopher Morrow [mailto:morrowc.lists@gmail.com]
> Sent: Monday, September 19, 2011 10:58 PM
> To: Schiller, Heather A; info@irnetco.net
> Cc: Jonas Frey (Probe Networks); nanog@nanog.org
> Subject: Re: Saudi Telecom sending route with invalid attributes
> 212.118.142.0/24 - Redux
>
> 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:         Hejji almazroua
> > address:        SaudiNet
> > address:        P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> > phone:          +9661 218 0300
> > fax-no:         +9661 218 0311
> > e-mail:         info@irnetco.net
> > nic-hdl:        Ha125-RIPE
> > mnt-by:         irnetco-ripe-mnt
> > source:         RIPE # Filtered
> >
> > person:       Suliman I. Al-Zain
> > address:      Saudi Telecom Co. (SaudiNet)
> > address:      P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> > phone:        +9661 218 2034
> > fax-no:       +9661 218 0311
> > e-mail:       suliman.alzain@saudi.net.sa
> > nic-hdl:      SA702-RIPE
> > source:       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
> supress the route, please remember not to export it!
> >>
> >> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet
> 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
> >> AS8866  BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08
> 18:35:14 UTC 2011-09-19 19:15:42 UTC
> >> AS10026 PACNET Pacnet Global Ltd        2011-09-11 02:41:40 UTC
> 2011-09-19 16:00:00 UTC
> >> AS8767  MNET-AS M-net AS        2011-09-14 12:13:01 UTC 2011-09-14
> 12:14:00 UTC
> >> AS3561  SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18
> UTC
> >> AS3549  GBLX Global Crossing Ltd.       2011-09-09 16:13:15 UTC
> 2011-09-09 17:05:38 UTC
> >> AS1239  SPRINTLINK - Sprint     2011-09-09 03:18:28 UTC 2011-09-09
> 15:56:41 UTC
> >> AS65000 -Private Use AS-        2011-09-08 18:34:28 UTC 2011-09-08
> 18:34:29 UTC
> >>
> >>  --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@nanog.org
> >> Subject: Re: Saudi Telecom sending route with invalid attributes
> 212.118.142.0/24
> >>
> >> Actually just started seeing these problems again today.  Is anyone
> else seeing this today from something other than 212.118.142.0/24?
>  Looks like 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 you are running... What's more important is how the
> unrecoginized attribute is handled.  Ideally you accept and pass the
> route and log it.  The problem is with devices that aren't so
> graceful.. dropping sessions and wreaking 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 ASN 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.com>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".  Not 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.
> >>>>>>>>
> >>>>>>>>              Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
> >>>>>>>> 1 6-Resolve tree 2
> >>>>>>>>               AS path: 6453 39386 25019 I Unrecognized
> Attributes:
> >>>> 39
> >>>>>>>> bytes
> >>>>>>>>               AS path:  Attr 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
> >>>>>>>>               Accepted Multipath
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -Jonas
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Yup! We're seeing the same thing too, and we're filtering it
> out.
> >>>>>>> Originating AS is 25019
> >>>>>>>
> >>>>>>> -Clay
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1410 / Virus Database: 1520/3906 - Release Date: 09/19/11
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 - Redux [ In reply to ]
On Mon, Sep 19, 2011 at 5:17 PM, Erik Bais <ebais@a2b-internet.com> wrote:
> Hi Chris,
>
> I've send an email to the person I know within STC responsible for
> international transit.
>
> Let's hope he can assist.

excellent! :)

>> -----Original Message-----
>> From: Christopher Morrow [mailto:morrowc.lists@gmail.com]
>> Sent: Monday, September 19, 2011 10:58 PM
>> To: Schiller, Heather A; info@irnetco.net
>> Cc: Jonas Frey (Probe Networks); nanog@nanog.org
>> Subject: Re: Saudi Telecom sending route with invalid attributes
>> 212.118.142.0/24 - Redux
>>
>> 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:         Hejji almazroua
>> > address:        SaudiNet
>> > address:        P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
>> > phone:          +9661 218 0300
>> > fax-no:         +9661 218 0311
>> > e-mail:         info@irnetco.net
>> > nic-hdl:        Ha125-RIPE
>> > mnt-by:         irnetco-ripe-mnt
>> > source:         RIPE # Filtered
>> >
>> > person:       Suliman I. Al-Zain
>> > address:      Saudi Telecom Co. (SaudiNet)
>> > address:      P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
>> > phone:        +9661 218 2034
>> > fax-no:       +9661 218 0311
>> > e-mail:       suliman.alzain@saudi.net.sa
>> > nic-hdl:      SA702-RIPE
>> > source:       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
>> supress the route, please remember not to export it!
>> >>
>> >> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet
>> 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
>> >> AS8866  BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08
>> 18:35:14 UTC 2011-09-19 19:15:42 UTC
>> >> AS10026 PACNET Pacnet Global Ltd        2011-09-11 02:41:40 UTC
>> 2011-09-19 16:00:00 UTC
>> >> AS8767  MNET-AS M-net AS        2011-09-14 12:13:01 UTC 2011-09-14
>> 12:14:00 UTC
>> >> AS3561  SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18
>> UTC
>> >> AS3549  GBLX Global Crossing Ltd.       2011-09-09 16:13:15 UTC
>> 2011-09-09 17:05:38 UTC
>> >> AS1239  SPRINTLINK - Sprint     2011-09-09 03:18:28 UTC 2011-09-09
>> 15:56:41 UTC
>> >> AS65000 -Private Use AS-        2011-09-08 18:34:28 UTC 2011-09-08
>> 18:34:29 UTC
>> >>
>> >>  --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@nanog.org
>> >> Subject: Re: Saudi Telecom sending route with invalid attributes
>> 212.118.142.0/24
>> >>
>> >> Actually just started seeing these problems again today.  Is anyone
>> else seeing this today from something other than 212.118.142.0/24?
>>  Looks like 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 you are running... What's more important is how the
>> unrecoginized attribute is handled.  Ideally you accept and pass the
>> route and log it.  The problem is with devices that aren't so
>> graceful.. dropping sessions and wreaking 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 ASN 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.com>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".  Not 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.
>> >>>>>>>>
>> >>>>>>>>              Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>> >>>>>>>> 1 6-Resolve tree 2
>> >>>>>>>>               AS path: 6453 39386 25019 I Unrecognized
>> Attributes:
>> >>>> 39
>> >>>>>>>> bytes
>> >>>>>>>>               AS path:  Attr 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
>> >>>>>>>>               Accepted Multipath
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> -Jonas
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> Yup! We're seeing the same thing too, and we're filtering it
>> out.
>> >>>>>>> Originating AS is 25019
>> >>>>>>>
>> >>>>>>> -Clay
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1410 / Virus Database: 1520/3906 - Release Date: 09/19/11
>
>
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 - Redux [ In reply to ]
I got an email response on 11th Sep when made a complaint for the same, they
said, it is one of our customer's prefix. THATS IT.

They didn't share any reason for rogue attributes, for them it is more
likely a Juniper box their client is using.

Very helpfull info though :)

Regards,

Aftab A. Siddiqui


On Tue, Sep 20, 2011 at 2:24 AM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> On Mon, Sep 19, 2011 at 5:17 PM, Erik Bais <ebais@a2b-internet.com> wrote:
> > Hi Chris,
> >
> > I've send an email to the person I know within STC responsible for
> > international transit.
> >
> > Let's hope he can assist.
>
> excellent! :)
>
> >> -----Original Message-----
> >> From: Christopher Morrow [mailto:morrowc.lists@gmail.com]
> >> Sent: Monday, September 19, 2011 10:58 PM
> >> To: Schiller, Heather A; info@irnetco.net
> >> Cc: Jonas Frey (Probe Networks); nanog@nanog.org
> >> Subject: Re: Saudi Telecom sending route with invalid attributes
> >> 212.118.142.0/24 - Redux
> >>
> >> 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: Hejji almazroua
> >> > address: SaudiNet
> >> > address: P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> >> > phone: +9661 218 0300
> >> > fax-no: +9661 218 0311
> >> > e-mail: info@irnetco.net
> >> > nic-hdl: Ha125-RIPE
> >> > mnt-by: irnetco-ripe-mnt
> >> > source: RIPE # Filtered
> >> >
> >> > person: Suliman I. Al-Zain
> >> > address: Saudi Telecom Co. (SaudiNet)
> >> > address: P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> >> > phone: +9661 218 2034
> >> > fax-no: +9661 218 0311
> >> > e-mail: suliman.alzain@saudi.net.sa
> >> > nic-hdl: SA702-RIPE
> >> > source: 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
> >> supress the route, please remember not to export it!
> >> >>
> >> >> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet
> >> 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
> >> >> AS8866 BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08
> >> 18:35:14 UTC 2011-09-19 19:15:42 UTC
> >> >> AS10026 PACNET Pacnet Global Ltd 2011-09-11 02:41:40 UTC
> >> 2011-09-19 16:00:00 UTC
> >> >> AS8767 MNET-AS M-net AS 2011-09-14 12:13:01 UTC 2011-09-14
> >> 12:14:00 UTC
> >> >> AS3561 SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18
> >> UTC
> >> >> AS3549 GBLX Global Crossing Ltd. 2011-09-09 16:13:15 UTC
> >> 2011-09-09 17:05:38 UTC
> >> >> AS1239 SPRINTLINK - Sprint 2011-09-09 03:18:28 UTC 2011-09-09
> >> 15:56:41 UTC
> >> >> AS65000 -Private Use AS- 2011-09-08 18:34:28 UTC 2011-09-08
> >> 18:34:29 UTC
> >> >>
> >> >> --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@nanog.org
> >> >> Subject: Re: Saudi Telecom sending route with invalid attributes
> >> 212.118.142.0/24
> >> >>
> >> >> Actually just started seeing these problems again today. Is anyone
> >> else seeing this today from something other than 212.118.142.0/24?
> >> Looks like 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 you are running... What's more important is how the
> >> unrecoginized attribute is handled. Ideally you accept and pass the
> >> route and log it. The problem is with devices that aren't so
> >> graceful.. dropping sessions and wreaking 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 ASN 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.com>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". Not 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.
> >> >>>>>>>>
> >> >>>>>>>> Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
> >> >>>>>>>> 1 6-Resolve tree 2
> >> >>>>>>>> AS path: 6453 39386 25019 I Unrecognized
> >> Attributes:
> >> >>>> 39
> >> >>>>>>>> bytes
> >> >>>>>>>> AS path: Attr 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
> >> >>>>>>>> Accepted Multipath
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> -Jonas
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> Yup! We're seeing the same thing too, and we're filtering it
> >> out.
> >> >>>>>>> Originating AS is 25019
> >> >>>>>>>
> >> >>>>>>> -Clay
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >> -----
> >> No virus found in this message.
> >> Checked by AVG - www.avg.com
> >> Version: 10.0.1410 / Virus Database: 1520/3906 - Release Date: 09/19/11
> >
> >
>
>