This section provides important information to describe the different configuration options used to populate the required BGP AD and generate the LDP generalized pseudowire-ID FEC fields. There are a large number of configuration options that are available with the this feature. Not all these configurations option are required to start using BGP AD. At the end of this section, it will be apparent that a very simple configuration will automatically generate the required values used by BGP and LDP. In most cases, deployments will provide full mesh connectivity between all nodes across a VPLS instance. However, capabilities are available to influence the topology and build hierarchies or hub and spoke models.
BGP AD automatically creates SDP-bindings using a template to configure SDP-binding configuration parameters. The l2-auto-bind command initiates a template that is used by BGP AD for PW instantiation under related VPLS instances.
The template may be referenced in the ‟service vpls bgp-ad” object and used subsequently to instantiate PWs to a remote PE and VSI instance advertised through BGP Auto-Discovery. Changes to these dynamically created objects cannot be performed directly through CLI or SNMP. There are two possible methods to initiate the change:
Configure a new ‟l2-auto-bind” association under service>vpls>bgp-ad. This method is used when the existing policy is used by multiple VPLS services and only one or a few require the change.
Change the parameters of the current template. This method is used when a change in parameter is required for the majority of VPLS services that use the template.
Changes are not automatically propagated to the instantiated objects and must be done through one of two tool commands:
— tools>perform>service# eval-pw-template policy-id [allow-service-impact]
— tools>perform>service>id# eval-pw-template policy-id [allow-service-impact]
This command forces evaluation of changes that were made in the l2-auto-bind template indicated in the command. This command can be applied to an individual VPLS service or all VPLS services that reference the template if no service is specified.
The parameters are divided into three classes.
class 1 - modified at create time only
class 2 - modified only when the object is administratively shutdown
class 3 - no restrictions
Parameters that fall into class 1 will destroy existing objects and recreate objects with the new values. Parameters in class 2 will momentarily shutdown the object, change the parameter, then re-enable the object. Class 3 can be changed without affecting the operational status of the objects of service.
For the l2-auto-bind template, the parameters are treated as follows:
class 1 - adding or removing a split-horizon-group, switching between a manual and auto SDP
class 2 - changing the vc-type {ether|vlan}
class 3 - all other changes
The keyword allow-service-impact enables service impacting changes. If this keyword is not configured, an error message is generated if the parameter changes are service impacting.