Hi,
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.
To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though.
So for those who have it configured - please rethink whether you really need it.
As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code.
Patch will be made available.
Please contact me for any further clarifications.
Regards,
Jeff
P.S. Warren has recently included AGGREGATOR in the draft, please see
2. Behavior
This document specifies that a BGP speaker MUST NOT originate or
propagate a route with an AS number of zero. 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 Aggregator.
Hi,
This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribute.
The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous.
If the network employs the "no-aggregator-id" knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about.
In other words, the "no-aggregator-id" knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute.
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 Aggregator.
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'.
This draft says that
...note it's a DRAFT, not a STANDARD...
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 Aggregator.
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'.
hence this old behavor
Hi Alexandre,
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 is closed.
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)
Regards,
Jeff
Hi Daniel,
I do understand the use of it however have my doubts about usability as such, I'd really like to see anyone using it for the reason below.
All of updates with ASN 0 I have seen in the past few years were there due to software bugs, not explicit configuration - same as this one.
Warren/ idr - I do support addition of AGGREGATOR in the draft
Regards,
Jeff
P.S. Jeffrey/John - this draft makes use of "no-aggregator-id" de facto illigal, are you (your customers) OK with it?
Thanks!
Can anyone familiar with this knob and its usage, answer a question:
Would anything break, in terms of use of that knob, if instead of
"zeroing" the AGGREGATOR, the local AS (as seen from the outside
world, in the case of confederations) were used?
Would the functionality of the knob, in reducing updates, be preserved?
Would routes be considered malformed or would it trigger any other bad behavior?
Perhaps this is a way of resolving the conflict between this knob and
the AS0 draft?
Brian
Aha, it looks that our Quebecer friends from Hostlogistic (AS46609) have again been advertising their now famous funny aggregate with their mad Brocade router, since yesterday 10pm UTC (that is 5pm in Quebec)...
Same route to 206.125.164.0/22, same AGGREGATOR attribute full of 0.
At least I can say that the patched Ericsson's bgpd stopped reseting the sessions.
regards,
Olivier
Olivier,
Thanks!
We've done our best to provide the fix ASAP.
Regards,
Jeff