bgp update destroying transit on redback routers ?
Hi there, Since about 15:00u GMT we receive bgp updates from our transit which destroys the bgp sessions with them with message: send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte data. mxReadMs=610 We use redback smartedge routers (SE100) currently for BGP. Anyone who have seen this also? regards, Igor
On Thu, Dec 01, 2011 at 05:07:15PM +0100, Igor Ybema wrote:
Hi there, Since about 15:00u GMT we receive bgp updates from our transit which destroys the bgp sessions with them with message:
send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte data. mxReadMs=610
We use redback smartedge routers (SE100) currently for BGP.
Anyone who have seen this also?
Have a complaint from our customer too. On our side (juniper) this is logged as: NOTIFICATION received from <peer-ip> (External AS <peer-as>): code 3 (Update Message Error) subcode 9 (error with optional attribute), Data: c0 07 08 00 00 00 As far as I can decode this attribute this is: c0: optional, transitive, no partial, no extended-length 07: AGGREGATOR 08: attribute length is 8 bytes. I think attribute length may be a problem here, because per RFC AGGREGATOR is an optional transitive attribute of length 6. -- In theory, there is no difference between theory and practice. But, in practice, there is.
AGGREGATOR is an optional transitive attribute of length 6.
-- In theory, there is no difference between theory and practice. But, in practice, there is.
Typical, because: AGGREGATOR is an optional transitive attribute of length 6. The attribute contains the last AS number that formed the aggregate route (encoded as 2 octets), followed by the IP address of the BGP speaker that formed the aggregate route (encoded as 4 octets). Usage of this attribute is described in 5.1.7 And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. regards, Igor
And what to do with 4-byte AS-numbers then? That would explain the 8 bytes.
Looking futher: Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to propagate four-octet based AS path information cross BGP speakers that do not support the four-octet AS numbers. However this router is AS4 capable, but probably fails to understand a 4-byte AS in the normal AGGREGATOR attribute. If I understand correctly a AS4 capable router should understand when announcing that to it's peer. I'm I correct? Should I file this as a bug? (redback/ericsson is already looking also) regards, Igor
Hi all, A new update. A coder from ericsson told me that the problem is not 4-byte asn related. It is related to aggregator-asn=0 and aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and IP-address. The question is now, are all other vendors wrong in accepting this attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC stating 'which shall contain its own AS number and IP address') or is Ericsson being to strict? regards, Igor
On Thu, Dec 1, 2011 at 3:15 PM, Igor Ybema <igor@ergens.org> wrote:
Hi all,
A new update. A coder from ericsson told me that the problem is not 4-byte asn related. It is related to aggregator-asn=0 and aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and IP-address.
The question is now, are all other vendors wrong in accepting this attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC stating 'which shall contain its own AS number and IP address') or is Ericsson being to strict?
<http://tools.ietf.org/html/draft-wkumari-idr-as0-01> one of the reasons the above was written...
regards, Igor
<http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
one of the reasons the above was written...
That does not include when ASN=0 is used in the aggregator attribute. Could you add that? regards, Igor
On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema <igor@ergens.org> wrote:
<http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
one of the reasons the above was written...
That does not include when ASN=0 is used in the aggregator attribute. Could you add that?
that's a warren question...
On Dec 1, 2011, at 3:36 PM, Christopher Morrow wrote:
On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema <igor@ergens.org> wrote:
<http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
one of the reasons the above was written...
That does not include when ASN=0 is used in the aggregator attribute. Could you add that?
that's a warren question...
http://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it. Thanks all, W
Thanks Warren! I have already brought this to the list. Regards, Jeff -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net] Sent: Thursday, December 01, 2011 3:05 PM To: Christopher Morrow Cc: nanog@nanog.org Subject: Re: bgp update destroying transit on redback routers ? On Dec 1, 2011, at 3:36 PM, Christopher Morrow wrote:
On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema <igor@ergens.org> wrote:
<http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
one of the reasons the above was written...
That does not include when ASN=0 is used in the aggregator attribute. Could you add that?
that's a warren question...
http://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it. Thanks all, W
On 1 Dec 2011, at 23:04, Warren Kumari wrote:
tp://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it.
Whilst we are on the subject of relevant drafts - it should be noted that situations like this provide significant motivation for the work presented in both [0] and [1] (full disclosure: I am the editor of [0]). I'd really encourage the community to review both documents and comment on whether they provide benefit in this problem space. I'm very happy to take feedback on the requirements draft [0] particularly - since this aimed to describe this problem from an operator perspective. Essentially, until something is done in a more general sense in the protocol, we will continue to see threads liked this one popping up every few months. I'll post a further update to the nanog list when we have requested a working group last-call on the requirements draft asking for reviews. Thanks for your time, r. [0]: http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-0... [1]: http://tools.ietf.org/html/draft-ietf-idr-error-handling-00
<http://tools.ietf.org/html/draft-wkumari-idr-as0-01> one of the reasons the above was written... That does not include when ASN=0 is used in the aggregator attribute. Could you add that?
next rev
participants (7)
-
Alexandre Snarskii -
Christopher Morrow -
Igor Ybema -
Jeff Tantsura -
Randy Bush -
Rob Shakir -
Warren Kumari