[quagga-dev 10533] Re: bgp and Multiprotocol Extension Capability

Balaji G balajig81 at gmail.com
Tue May 14 04:45:38 BST 2013


Hi Chris

>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.

Do you mean to say if we don't enable the neighbor in the specific SAFI
mode (multicast/mpls-vpn) quagga assumes that the neghbor is enabled for
all SAFIs and gives all the capabilities to the bgp speaker ? Have i
understood your question ?

>Does anyone think it is unreasonable to treat current behaviour as a
>bug ?

If the above behavior is what you observe then this is a bug because by
default the unicast SAFI is alone enabled and the other SAFIs are
capabilities which are negotiated in the open message.

>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
>BGP speaker.

AFAI Multiprotocol extensions are optional because IPv6 is also termed as
MultiProtocol and hence you got to enable the neighbor in the ipv6 unicast
mode which by itself is a capability .

Let me know your thoughts.

Thanks,
Cheers,
  - Balaji


On Tue, May 14, 2013 at 1:40 AM, Chris Hall
<chris.hall.list at highwayman.com>wrote:

> 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
> BGP speaker.
>
> Does anyone think it is unreasonable to treat current behaviour as a
> bug ?
>
> 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.
>
>   Default: on.
>
> 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 !
>
> Chris
>
>
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130514/bc97bd48/attachment-0001.html>


More information about the Quagga-dev mailing list