[j-nsp] What does AS path attribute problem mean?

[Kevin Hodle]

Hi Markus/Mark,

  Most of our backbone consists of Cisco 7600s running SRD, as well as
Brocade NI/XMRs running IW 5.1 with a small handful of older Juniper
M-series and Cisco 12ks (non of them directly terminating eBGP
session). We saw no issues on any other platform except M-series
Junipers running various incantations of JUNOS 9.[2|3]. In some cases,
(m20/m40) we either cannot (due to hardware limitations), or it is not
financially worthwhile to upgrade the routers beyond their current
JUNOS versions.

    Also, speaking only for myself, I have absolutely no problem
filtering the /24 originated by SaudiTel (or not carrying it in my
backbone RIBs at all). I have no doubt the originators of the prefix
have received a multitude of feedback from operators around the world,
and despite this still originated the prefix with the offending
attribute. If they were at all concerned with global visibility of the
prefix, they would have remedied the issue:  While I have not seen a
decode/pcap of the UPDATE in question (if you have one, I would love
to have look!), from the logging/debugging that I saw, the attribute
in question causing the problems is path attribute 128 (ATTR_SET)
defined in draft-marques-l3vpn-ibgp-02, intended for use in CE-PE
scenarios to encapsulate customer set path attributes on l3vpn
sessions and preserve them in the provider iBGP core. From what I
gleaned from the draft, when these prefixes are advertised on eBGP
sessions, path attributes are set to the attributes contained within
the ATTR_SET, and the as-path contained within the ATTR_SET is
prepended on the externally advertised AS-PATH. Following this logic -
I do not believe the ATTR_SET attribute should ever be visible in the
DFZ. Please understand, I'm not saying that bgp stacks shouldn't
gracefully handle the presence of this attribute in an eBGP learned
UPDATE, and if I could easily update my JUNOS code to remedy the
situation I would. But in this case, I won't lose any sleep filtering
this prefix on my eBGP borders.

Cheers!
Kevin

On Sat, Sep 10, 2011 at 7:09 AM, Markus <universe at truemetal.org> wrote:
> For what it's worth, I heard from someone that it also affected Foundry and
> Microtik, and in one case, Cisco. All routers were running older software
> releases and in the case of Microtik, upgrading to the latest software fixed
> it.
>
>
> Am 10.09.2011 06:56, schrieb Chris Adams:
>>
>> Once upon a time, Mark Tinka<mtinka at globaltransit.net>  said:
>>>
>>> On Saturday, September 10, 2011 03:20:34 AM Chris Adams
>>> wrote:
>>>>
>>>> I've got an M10i running JUNOS 9.3R4.4 that is logging
>>>> the same error about that prefix, but it does not cause
>>>> the BGP session to flap.  I'm not seeing any unusual
>>>> behavior beyond the log message itself.
>>>
>>> Junos 9.3R2.8 is affected.
>>
>> Sorry, I was confusing two different odd BGP announcements of the day.
>> I saw:
>>
>> rpd[1117]: x.x.x.x (External AS x) Received BAD update for family
>> inet-unicast(1), prefix 212.118.142.0/24
>>
>> which is not causing any problems on my routers.  I guess that's a
>> different prefix (and apparently a different problem) than what is being
>> talked about here (saw the messages about the above prefix on NANOG and
>> confused the two threads).
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
================================================================
 :: :: Kevin Hodle | http://www.linkedin.com/in/kevinhodle
 :: :: PGP Key ID  | fingerprint
 :: :: 0x803F24BE  | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE

"Elegance is not a dispensable luxury but a factor that decides
between success and failure. "
-Edsger Dijkstra
================================================================