Vyatta NOS documentation

Learn how to install, configure, and operate Vyatta Network Operating System (Vyatta NOS), which helps to drive our virtual networking and physical platforms portfolio.

protocols bgp <asn> neighbor <id> address-family ipv4-unicast route-reflector-client

Specifies this neighbor as a route reflector client for IPv4 routes.

set protocols bgp asn neighbor id address-family ipv4-unicast route-reflector-client
delete protocols bgp asn neighbor id address-family ipv4-unicast route-reflector-client
show protocols bgp asn neighbor id address-family ipv4-unicast

Disabled.

asn
The number for the AS in which this router resides. The numbers ranges from 1 through 4294967295.
id
The IPv4 or IPv6 address of a BGP neighbor.

Configuration mode


protocols {
    bgp asn {
        neighbor id {
            address-family {
                ipv4-unicast {
                    route-reflector-client
                }
            }
        }
    }
}

Use the set form of this command to make the local router a BGP route reflector, and to designate the specified neighbor as a route reflector client.

Another technology designed to help ASs with large numbers of iBGP peers is route reflection. In a standard BGP implementation, all iBGP peers must be fully meshed. because of this requirement, when an iBGP peer learns a route from another iBGP peer, the receiving router does not forward the route to any of its iBGP peers, since these routers should have learned the route directly from the announcing router.

In a route reflector environment the iBGP peers are no longer fully meshed. Instead, each iBGP peer has an iBGP connection to one or more route reflectors (RRs). Routers configured with a connection to an RR server are referred to as RR clients. Only the RR server is configured to be aware that the RR client is part of an RR configuration; from the RR client's point of view, it is configured normally, and does not have any awareness that it is part of a RR configuration.

In route reflection, internal peers of an RR server are categorized into two types:

  • Client peers. The RR server and its client peers form a cluster. Within a cluster, client peers need not be fully meshed, but must have an iBGP connection to at least one RR in the cluster.
  • Non-client peers. Non-client peers, including the RR server, must be fully meshed.

An RR environment is unlike a regular environment, where iBGP peers never forward a route update to other iBGP peers (which is the reason why each iBGP peer must peer with all other peers). When an RR server receives an iBGP update from an RR client, these route updates can also be sent to all other RR clients. When an RR server receives a route update from a peer, it selects the best path based on its path selection rule. After the best path is selected, the RR server chooses its action depending on the type of the peer from which it learned the best path.

  • If the route was learned from a client peer, the RR reflects the route to both client and non-client peers. All iBGP updates from client peers are reflected to all other client peers in the cluster. This is done regardless of whether the update was the best path for the RR itself.
  • If the route was learned from a non-client iBGP peer, it is reflected out to all RR client peers.
  • If the route was learned from an eBGP peer, the route is reflected to all RR clients and all non-clients.

Use the delete form of this command to remove the neighbor as a route reflector client.

Use the show form of this command to view BGP neighbor configuration settings.