Supported Platforms
Configuring Administrative Groups
Administrative groups, also known as link coloring or resource class, are manually assigned attributes that describe the “color” of links, such that links with the same color conceptually belong to the same class. You can use administrative groups to implement a variety of policy-based LSP setups.
Administrative groups are meaningful only when constrained-path LSP computation is enabled.
You can assign up to 32 names and values (in the range 0 through 31), which define a series of names and their corresponding values. The administrative names and values must be identical across all routers within a single domain.
![]() | Note: The administrative value is distinct from the priority. You configure the priority for an LSP using the priority statement. See Configuring Priority and Preemption for LSPs. |
To configure administrative groups, follow these steps:
- Define multiple levels of service quality by including
the admin-groups statement:
You can include this statement at the following hierarchy levels:
- [edit protocols mpls]
- [edit logical-systems logical-system-name protocols mpls]
The following configuration example illustrates how you might configure a set of administrative names and values for a domain:
[edit protocols mpls]admin-groups {gold 1; silver 2;copper 3;best-effort 4;} - Define the administrative groups to which an interface
belongs. You can assign multiple groups to an interface. Include the interface statement:
You can include this statement at the following hierarchy levels:
- [edit protocols mpls]
- [edit logical-systems logical-system-name protocols mpls]
If you do not include the admin-group statement, an interface does not belong to any group.
IGPs use the group information to build link-state packets, which are then flooded throughout the network, providing information to all nodes in the network. At any router, the IGP topology, as well as administrative groups of all the links, is available.
Changing the interface’s administrative group affects only new LSPs. Existing LSPs on the interface are not preempted or recomputed to keep the network stable. If LSPs need to be removed because of a group change, issue the clear rsvp session command.
- Configure an administrative group constraint for each
LSP or for each primary or secondary LSP path. Include the label-switched-path statement:label-switched-path lsp-name {to address;...admin-group { exclude [ group-names ];include-all [ group-names ];include-any [ group-names ];}primary path-name {admin-group { exclude [ group-names ];include-all [ group-names ];include-any [ group-names ];}}secondary path-name {admin-group { exclude [ group-names ];include-all [ group-names ];include-any [ group-names ];}}}
You can include the label-switched-path statement at the following hierarchy levels:
- [edit protocols mpls]
- [edit logical-systems logical-system-name protocols mpls]
If you omit the include-all, include-any, or exclude statements, the path computation proceeds unchanged. The path computation is based on the constrained-path LSP computation. For information about how the constrained-path LSP computation is calculated, see How CSPF Selects a Path.
Note: Changing the LSP’s administrative group causes an immediate recomputation of the route; therefore, the LSP might be rerouted.