Henning Brauer wrote:
* Claudio Jeker <[EMAIL PROTECTED]> [2008-08-25 17:27]:
On Mon, Aug 25, 2008 at 03:54:27PM +0200, Henning Brauer wrote:
* Graeme Lee <[EMAIL PROTECTED]> [2008-08-25 03:28]:
Yes but the safi's are handled during capability negotiation (in function
parse_capabilities in session.c)
Do I need to do more than just ignore the unknown safi's? Currently, the
return (-1) in the mp_safi test never allows the connection to establish.
Removing this at least allows the bgp session to function, but I'm not sure
if that's all that's needed, or even if it's safe to do so.
I don't remember exactly what the RFCs demanded. IThere is one for
capabilties negotiation and one for the multiprotocol extensions. I
guess the latter is the relevant one. if you could check what it says
about the unknown safi case and it allows us to ingore them I am very
willing to make that change :)
RFC 2858 Section 7:
A speaker that supports multiple <AFI, SAFI> tuples includes them as
multiple Capabilities in the Capabilities Optional Parameter.
To have a bi-directional exchange of routing information for a
particular <AFI, SAFI> between a pair of BGP speakers, each such
speaker must advertise to the other (via the Capability Advertisement
mechanism) the capability to support that particular <AFI, SAFI>
routes.
I would say that unknown safi should be accepted in the capabilities but
not during a bgp update. That would mean that your diff is not correct.
huh? that is exactly wgat my diff does. it doesn't change the way we
handle safis in updates - which means we might have to ignore unknown
safis there too, didn't check wether we do that already.
Previously the check (and subsequent return (-1)) was a show stopper.
bgpd works fine for the rest of the time.
Reading over RFC3397, section 3 covers the error handling. This is how
I read it:
If you don't understand capabilities advertisements at all, you should
terminate, and re-establish with no capabilities options.
If you don't understand a particular capability, you may choose to
terminate, and send a message back to say which capability isn't
supported (goto section 7). However, any particular capability is only
supported if both peers advertise the same capability to each other.
I have applied the patch supplied by Henning, and now get the following
in my bgpctl show neighbor
Neighbor capabilities:
Multiprotocol extensions: IPv4 Unicast (previously was unknown (128))
Route Refresh
