|
The reflection related configuration is quite flexible. Besides common configuration, in order to strengthen the robustness and flexibility of the reflection, we can also configure redundant reflectors and nested reflector:
As the logic structure changes in the AS domain, the reflector becomes the bottleneck of the route released, once the reflector get a problem, the transmission of the routing in the entire domain will be greatly affected, in this case, we can configure redundant reflector to resolves this ,i.e., a group can exist more than one reflector, each of reflector CLUSER_ID is the same and is fully connected with the customer, when the problem occurs in one reflector, the other reflector still work properly. The redundant reflector concept can further reference below.
In addition, we can configure nested reflector that is to configure a reflection group within a group, the reflection group ID is different from the group CLUTER_ID. Nested reflectors is usually used in the VPNV4, for example, in the MPLS L3vpn environment, multi-level reflection can share the pressure of PE.
To avoid routing loops, we can quote originator-id attributes and cluster-list attributes, originator-id attribute is generated by the reflector, whose value is the router-id of neighbors of the route originated from ; cluster-list is also generated by the reflector, if reflector find cluster-list attributes in update packet, it will add the cluster-list attributes to the end; If not, reflector will create a cluster-list attributes, put its own cluster-id on above, and then advertise to other neighbors; if the cluster-id is the same with local cluster-id ,reflector will discard the route to avoid loop. The value of cluster-id can be configured on the reflector, if not, it will be configured by default to use router-id of the reflector.
|
|
|
|
|
|
