[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When adding IPv6 routing information exchange feature to BGP. There were some proposals. IETF IDR working group finally take 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 does not have the feature to detect remote peer's
capability whether it can handle other than IPv4 unicast routes. This
is a big problem using Multiprotocol Extension for BGP to operational
network. draft-ietf-idr-bgp4-cap-neg-04.txt is proposing a
feature called Capability Negotiation. bgpd
use this Capability
Negotiation to detect remote peer's capabilities. If the peer is only
configured as IPv4 unicast neighbor, bgpd
does not send these Capability
Negotiation packets.
By default, Zebra 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, Zebra sends Unsupported Capability error and then resets the connection.
If you want to completely match capabilities with remote peer. Please
use strict-capability-match
command.
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 dont-capability-negotiate
command to disable the feature.
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 override-capability
, bgpd
ignores received
capabilities then override negotiated capabilities with configured values.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |