When adding IPv6 routing information exchange feature to BGP. There were some proposals. IETF (Internet Engineering Task Force) IDR (Inter Domain Routing) WG (Working group) adopted a proposal called Multiprotocol Extension for BGP. The specification is described in RFC2283. The protocol does not define new protocols. It defines new attributes to existing BGP. When it is used exchanging IPv6 routing information it is called BGP-4+. When it is used for exchanging multicast routing information it is called MBGP.
bgpd supports Multiprotocol Extension for BGP. So if remote
peer supports the protocol,
bgpd can exchange IPv6 and/or
multicast routing information.
Traditional BGP did not have the feature to detect remote peer’s
capabilities, e.g. whether it can handle prefix types other than IPv4
unicast routes. This was a big problem using Multiprotocol Extension
for BGP to operational network. RFC2842, Capabilities
Advertisement with BGP-4 adopted a feature called Capability
bgpd use this Capability Negotiation to detect
the remote peer’s capabilities. If the peer is only configured as IPv4
bgpd does not send these Capability
Negotiation packets (at least not unless other optional BGP features
require capability negotation).
By default, Quagga will bring up peering with minimal common capability for the both sides. For example, local router has unicast and multicast capabilitie and remote router has unicast capability. In this case, the local router will establish the connection with unicast only capability. When there are no common capabilities, Quagga sends Unsupported Capability error and then resets the connection.
If you want to completely match capabilities with remote peer. Please
Strictly compares remote capabilities and local capabilities. If capabilities are different, send Unsupported Capability error then reset connection.
You may want to disable sending Capability Negotiation OPEN message
optional parameter to the peer when remote peer does not implement
Capability Negotiation. Please use
command to disable the feature.
Suppress sending Capability Negotiation as OPEN message optional parameter to the peer. This command only affects the peer is configured other than IPv4 unicast configuration.
When remote peer does not have capability negotiation feature, remote peer will not send any capabilities at all. In that case, bgp configures the peer with configured capabilities.
You may prefer locally configured capabilities more than the negotiated
capabilities even though remote peer sends capabilities. If the peer
is configured by
received capabilities then override negotiated capabilities with
Override the result of Capability Negotiation with local configuration. Ignore remote peer’s capability value.