Edge-Core AS5700-54X, Справочное руководство CLI, Страница: 915 / 1116

Chapter 29
| IP Routing Commands
Border Gateway Protocol (BGPv4)
– 915 –
connected to its designated route reflector. Once all iBGP routing sessions are
established, routing advertisements must follow these rules:
◆
Announcements received by a route reflector from another reflector are passed
to its clients.
◆
Announcements received by a route reflector from a reflector client are passed
to other route reflectors in the cluster.
◆
Announcements received by a route reflector from an eBGP speaker are passed
to all route reflectors in the cluster and to its own clients.
It can now be seen that routing information learned from an iBGP speaker can be
passed to another iBGP speaker. This breaks the normal rules for a fully meshed
iBGP autonomous system, and other steps are now required to avoid routing loops.
These include the addition of the following new attributes:
◆
Originator-ID – When a route reflector learns about a route from one of its
clients, it adds this attribute to the announcement before reflecting it to other
speakers. If a route reflector receives an announcement about a route with an
Originator-ID that matches its own router ID, it should drop it.
◆
Cluster-List – This is a list of the clusters through which a route announcement
has passed. When a route reflector passes on an announcement, it must
prepend the local Cluster-ID to this list. The Cluster-List thereby serves a similar
function to the AS-Path attribute in detecting routing loops.
Configuration Guidelines
1.
Route reflection from this router is enabled by default. If it has been disabled,
use the
bgp client-to-client reflection command to restore route reflection via
this router.
2.
If more than one route reflector is used, use the bgp cluster-id command to
configure the cluster identifier.
3.
Use the neighbor route-reflector-client command configure a neighboring
router as a client.
Confederations
Confederations simply divides an autonomous system into smaller groups. It splits
up an AS into multiple sub-ASes, where full mesh connections are maintained only
within each sub-As, and sub-ASes are connected by eBGP. The overall AS is known
as a confederation, while the sub-ASes may also be referred to as member ASes.
The entire confederation has a unique AS number, while the member ASes may
have AS numbers obtained from public AS number space, or use AS number from
private AS number space.