[j-nsp] Juniper BGP invalid attributes

[Richard A Steenbergen]

On Tue, Mar 17, 2009 at 08:46:06PM -0700, Andy Vance wrote:
> Richard,
> 
> Appears these are the releases that it has been fixed in.
> 
> 8-1-4p0-4, 8-2-4p0-7, 9-0-2p0-1, 9-1-2p0-1, 9-2-1p0-1, 9-3-0p0-1, 10-0-0

Now that things have calmed down, I've got a few more updates on this
incident and some corrections from previous e-mails.

There appear to be 3 main issues:

1) Routers shouldn't be leaking confederation information into AS4_PATH. 
This is the issue that Juniper covers under PSN-2009-01-200, and all
code built after 2009-01-26 appears to be fixed in this regard. This is
the same issue that was reported back in December. The root issue
tonight is an AS4_PATH of "( 65490 65410 ) 8758 196621" associated with
prefix 193.5.68.0/23, and the BGP update is captured here:

http://www.paste-it.net/public/p698b04/

2) Some routers will drop the BGP session upon receipt of an AS4_PATH
with the leaked confederation information. I've heard quite a few
reports of this behavior causing impact to DSL users connected to
Juniper ERX/E-series boxes running JUNOSe. I'm not an ERX user myself,
but I'm told one way to work around this issue is to configure "neighbor
x.x.x.x lenient".

3) There appears to be another unrelated issue under JUNOS 9.1R1 (and
possibly other versions, but NOT 9.2 images as originally thought)
wherein the router accepted the invalid AS4_PATH attribute, but then
propagated an extremely corrupted version of the update to its
neighbors, causing them (all bgp neighbors, even non-AS4 speakers) to
drop the BGP session with the 9.1R1 routers upon receipt. This is what
was captured here:

http://www.paste-it.net/public/o83f44b/

Everything else that went wrong tonight appears to be the result of the
churn caused by either issues 2) or 3) above, as far as I can tell. 
Apologies to any innocent platforms/OS versions which may have been 
incorrectly blamed before (though they're not all entirely innocent :P).

I've heard reports that there might be a Quagga issue which is the same
as the JUNOS issue in 1), but I have no information as to whether JUNOS
or Quagga was the cause of this particular issue.

Also FYI, adding 193.5.68.0/23 to routing-options martians appears to be 
an effective way of blocking this issue on all JUNOS versions. Clearly 
not the preferred way to do it, but better than propagating invalid 
attributes which cause sessions to flap endlessly.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)