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
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=610We 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),
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.
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
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...
<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
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
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-02
[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