[quagga-dev 10532] bgp and Multiprotocol Extension Capability
chris.hall.list at highwayman.com
Mon May 13 21:10:34 BST 2013
If a neighbour sends no Multiprotocol Extension Capability (MP-Ext) at
all, Quagga will happily assume that the neighbour supports all the
afi/safi it is configured for.
This strikes me as broken. RFC4760 says that one or more MP-Ext
capabilities implies that the BGP speaker "uses Multiprotocol
Extensions". The RFC does not specify what the absence of any MP-Ext
means, but I think it reasonable to assume a BGP speaker that does not
"use Multiprotocol Extensions" is implicitly an unadorned IPv4 Unicast
Does anyone think it is unreasonable to treat current behaviour as a
I guess most BGP implementations these days send MP-Ext for every
afi/safi supported, even if that is only IPv4 Unicast ? I note that
BIRD has an option:
advertise ipv4 switch
Advertise IPv4 multiprotocol capability. This is not a correct
behavior according to the strict interpretation of RFC 4760,
but it is widespread and required by some BGP implementations
(Cisco and Quagga). This option is relevant to IPv4 mode with
enabled capability advertisement only.
It seems to me that if (say) IPv6 Unicast is announced by MP-Ext, and
if IPv4 Unicast is also required, then it must also be announced by
MP-Ext. But, if IPv4 Unicast is the only afi/safi required, then I
agree that an MP-Ext is not, strictly, required.
In the long-ago, it seems there was broken-ness in capabilities in
general and (perhaps) MP-Ext in particular. So, there is "neighbor nn
capability-override" to ignore what the neighbour said (or did not
say) MP-Ext-wise. So... in the absence of "capability-override", I
don't see why Quagga should make the assumption that no MP-Ext means
all the afi/safi it wants !
More information about the Quagga-dev