You are right, the behavior is exactly as per RFC4271 section 6:
"When any of the conditions described here are detected, a
NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection
So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and close the connection.
Ideally it should be treated as "treat-as-withdraw" as per draft-chen-ebgp-error-handling, however please note - this
is still a draft,
not a normative document and with all my support it takes time to implement.
Once again, we understand the implications for our customers and hence going to disable ASN 0 check.
P.S. We have strong evidence that the update in question was caused by a bug on a freshly updated router (I'm not
going to disclose the vendor)
From: Alexandre Snarskii [mailto:snar () snar spb ru]
Sent: Friday, December 02, 2011 6:36 AM
To: Jeff Tantsura
Cc: nanog () nanog org
Subject: Re: bgp update destroying transit on redback routers ?
On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote:
Let me take it over from now on, I'm the IP Routing/MPLS Product
Manager at Ericsson responsible for all routing protocols.
There's nothing wrong in checking ASN in AGGREGATOR, we don't really
want see ASN 0 anywhere, that's how draft-wkumari-idr-as0
(draft-ietf-idr-as0-00) came into the worlds.
This draft says that
If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be
logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4
but observed behaviour was more like following:
If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message
Error' and subcode 'Error with optional attribute'.