
reflector would be configured with other route reflectors as nonclient peers (thus, all route reflectors are fully
meshed). The clients are configured to maintain iBGP sessions with only the route reflector in their cluster.
Usually, a cluster of clients has a single route reflector. In that case, the cluster is identified by the router ID
of the route reflector. To increase redundancy and avoid a single point of failure, a cluster might have more
than one route reflector. In this case, all route reflectors in the cluster must be configured with the cluster ID
so that a route reflector can recognize updates from route reflectors in the same cluster. All route reflectors
serving a cluster should be fully meshed and all of them should have identical sets of client and nonclient
peers.
By default, the clients of a route reflector are not required to be fully meshed and the routes from a client are
reflected to other clients. However, if the clients are fully meshed, the route reflector need not reflect routes
to clients.
As the iBGP learned routes are reflected, routing information may loop. The route reflector model has the
following mechanisms to avoid routing loops:
• Originator ID is an optional, nontransitive BGP attribute. It is a 4-byte attributed created by a route
reflector. The attribute carries the router ID of the originator of the route in the local autonomous system.
Therefore, if a misconfiguration causes routing information to come back to the originator, the information
is ignored.
• Cluster-list is an optional, nontransitive BGP attribute. It is a sequence of cluster IDs that the route has
passed. When a route reflector reflects a route from its clients to nonclient peers, and vice versa, it appends
the local cluster ID to the cluster-list. If the cluster-list is empty, a new cluster-list is created. Using this
attribute, a route reflector can identify if routing information is looped back to the same cluster due to
misconfiguration. If the local cluster ID is found in the cluster-list, the advertisement is ignored.
Remotely Triggered Blackhole Filtering with RPL Next-hop Discard
Configuration
Remotely triggered black hole (RTBH) filtering is a technique that provides the ability to drop undesirable
traffic before it enters a protected network. RTBH filtering provides a method for quickly dropping undesirable
traffic at the edge of the network, based on either source addresses or destination addresses by forwarding it
to a null0 interface. RTBH filtering based on a destination address is commonly known as Destination-based
RTBH filtering. Whereas, RTBH filtering based on a source address is known as Source-based RTBH filtering.
RTBH filtering is one of the many techniques in the security toolkit that can be used together to enhance
network security in the following ways:
• Effectively mitigate DDoS and worm attacks
• Quarantine all traffic destined for the target under attack
• Enforce blocklist filtering
Configuring Destination-based RTBH Filtering
RTBH is implemented by defining a route policy (RPL) to discard undesirable traffic at next-hop using
set
next-hop discard
command.
RTBH filtering sets the next-hop of the victim's prefix to the null interface. The traffic destined to the victim
is dropped at the ingress.
Routing Configuration Guide for Cisco NCS 6000 Series Routers, IOS XR Release 6.4.x
34
Implementing BGP
Remotely Triggered Blackhole Filtering with RPL Next-hop Discard Configuration