Configuring global service entities with CLI
This section provides information to create subscriber (customer) accounts and configure Service Distribution Points (SDPs) using the command line interface.
Service model entities
The Nokia service model uses logical entities to construct a service. The service model contains four main entities to configure a service:
subscribers (customers)
SDPs
services
Circuit Emulation services (Cpipe)
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide for more information.
Ethernet Pipe (Epipe) services
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide for more information.
IP Interworking VLL (Ipipe) services
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide for more information.
Virtual Private LAN Service (VPLS)
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide for more information.
Internet Enhanced Service (IES)
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN for more information.
Virtual Private Routed Network (VPRN) service
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN for more information.
Service Access Points (SAPs)
Ethernet Pipe (Epipe) services
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide for more information.
VPLS SAP
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide for more information.
IES SAP
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN for more information.
VPRN Interface SAP
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN for more information.
Basic configurations
The most basic service configuration must have the following:
-
a customer ID
-
a service type
-
a service ID
This is an optional service name that can be configured in addition to the service ID. Service names are optional. All services are required to assign a service ID to initially create a service. However, either the service ID or the service name can be used to identify and reference a specific service when it is initially created.
-
a SAP identifying a port and encapsulation value
-
an interface (where required) identifying an IP address, IP subnet, and broadcast address
-
for distributed services, an associated SDP
The commands in the following contexts provide nodes for basic configurations.
configure service customer
configure service sdp
configure service service typeCommon configuration tasks
This section provides a brief overview of the tasks that must be performed to configure a customer account and an SDP.
Configuring customers
The most basic customer account must have a customer ID. Optional configurations include:
description
contact name
telephone number
multi-service site
Customer information
The following example shows a basic customer account configuration.
A:node-2config>service# info
-------------------------------------------
...
customer 5
description "Nokia Customer"
contact "Technical Support"
phone "650 555-1212"
exit
...
-------------------------------------------Configuring multi-service-sites
Multi-service sites create a virtual scheduler hierarchy and making it available to queues and, at egress only, policers on multiple Service Access Points (SAPs). The ingress and egress scheduler-policy commands on the SAP are mutually exclusive with the SAP multi-service-site command. The multi-service customer site association must be removed from the SAP before local scheduler polices may be applied.
After a multi-service site is created, it must be assigned to a chassis slot or port.
Use the following CLI command to configure customer multi-service site information.
configure service customer multi-service-site Configuring an SDP
The most basic SDP must have the following:
a locally unique SDP identification (ID) number
the system IP address of the originating and far-end routers
an SDP encapsulation type, either GRE or MPLS
SDP configuration tasks
This procedure provides a brief overview of the tasks that must be performed to configure a basic SPD.
Consider the following SDP characteristics:
-
SDPs can be created as either GRE or MPLS.
-
Each distributed service must have an SDP defined for every remote router to provide VLL, VPLS, and VPRN services.
-
A distributed service must be bound to an SDP. By default, no SDP is associated with a service. After an SDP is created, services can be associated with that SDP.
-
An SDP is not specific or exclusive to any one service or any type of service. An SDP can have more than one service bound to it.
-
The SDP IP address must be an Nokia router system IP address.
-
To configure an MPLS SDP, LSPs must be configured first and then the LSP-to-SDP association must be explicitly created. Auto-LSPs such as one-hop-p2p and mesh-p2p, and PCE initiated LSPs cannot be used by a configured MPLS SDP.
-
In the SDP configuration, automatic ingress and egress labeling (targeted LDP) is enabled by default. Ingress and egress VC labels are signaled over a TLDP connection between two Nokia nodes.
Note: If signaling is disabled for an SDP, then services using that SDP must configure ingress and egress vc-labels manually.
- Specify an originating node.
- Create an SDP ID.
- Specify an encapsulation type.
- Specify a far-end node.
Configuring an SDP
Use the following CLI commands to create an SDP and select an encapsulation type. If gre or mpls is not specified, the default encapsulation type is gre.
When an configuring MPLS SDP, specify an LSP or enable LDP. There cannot be two methods of transport in a single SDP except if the mixed-lsp-mode command is specified. If an LSP name is specified, then RSVP is used for dynamic signaling within the LSP.
LSPs are configured in the configure router mpls context. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide MPLS Configuration Guide for configuration and command information.
Use the commands in the following context to create a GRE SDP or an MPLS SDP:
- MD-CLI
configure service sdp delivery-type [gre | mpls] - classic
CLI
configure service sdp sdp-id [gre | mpls]
The following displays examples of a GRE SDP, an LSP-signaled MPLS SDP, and an LDP-signaled MPLS SDP configuration.
MD-CLI
A:admin@node-2#
...
sdp 2 {
description "GRE-10.10.10.104"
keep-alive {
admin-state disable
}
far-end {
ip-address 10.10.10.104
}
}
sdp 8 {
description "MPLS-10.10.10.104"
delivery-type mpls
keep-alive {
admin-state disable
}
far-end {
ip-address 10.10.10.104
}
lsp "to-104" { }
}
}
sdp 104 {
description "MPLS-10.10.10.94"
delivery-type mpls
ldp true
keep-alive {
admin-state disable
}
far-end {
ip-address 10.10.10.94
}
}classic CLI
A:node-2>config>service# info
-------------------------------------------
...
sdp 2 create
description "GRE-10.10.10.104"
far-end 10.10.10.104
keep-alive
shutdown
exit
no shutdown
exit
sdp 8 mpls create
description "MPLS-10.10.10.104"
far-end 10.10.10.104
lsp "to-104"
keep-alive
shutdown
exit
no shutdown
exit
sdp 104 mpls create
description "MPLS-10.10.10.94"
far-end 10.10.10.94
ldp
keep-alive
shutdown
exit
no shutdown
exit
...
-----------------------------------------Configuring a mixed-LSP SDP
Use the following command to configure an SDP with mixed LSP mode of operation:
- MD-CLI
configure service sdp delivery-type mpls mixed-lsp-mode - classic
CLI
configure service sdp mpls mixed-lsp-mode
The primary is backed up by the secondary. Two combinations are possible: primary of RSVP is backed up by LDP and primary of LDP is backed up by 8277 BGP.
The no form of this command disables the mixed LSP mode of operation. The user first has to remove one of the LSP types from the SDP configuration or the command fails.
The user can also configure the time the service manager must wait before it must revert the SDP to a higher priority LSP type when one becomes available by using the following command:
- MD-CLI
configure service sdp delivery-type mpls mixed-lsp-mode revert-time - classic
CLI
configure service sdp mpls mixed-lsp-mode revert-time
A special value of the timer dictates that the SDP must never revert to another higher priority LSP type unless the currently active LSP type is down:
- MD-CLI
configure service sdp delivery-type mpls mixed-lsp-mode revert-time never - classic
CLI
configure service sdp mpls mixed-lsp-mode revert-time infinite
The BGP LSP type is allowed. The bgp-tunnel command can be configured under the SDP with the lsp or ldp commands.
The mixed LSP SDP allows for a maximum of two LSP types to be configured within an SDP. A primary LSP type and a backup LSP type. An RSVP primary LSP type can be backed up by an LDP LSP type.
An LDP LSP can be configured as a primary LSP type which can then be backed up by a BGP LSP type.
At any time, the service manager programs only one type of LSP in the line card that activates it to forward service packets according to the following priority order:
With RSVP or LDP SDP, the service manager programs the NHLFEs for the active LSP type preferring the RSVP LSP type over the LDP LSP type. If no RSVP LSP is configured or all configured RSVP LSPs go down, the service manager reprograms the line card with the LDP LSP if available. If not, the SDP goes operationally down.
When a higher priority type LSP becomes available, the service manager reverts back to this LSP at the expiry of the revert time timer or the failure of the currently active LSP, whichever comes first. The service manager then re-programs the line card accordingly.
The SDP reverts to the highest priority type LSP only if the currently active LSP failed when the following commands were configured:
- MD-CLI
configure service sdp delivery-type mpls mixed-lsp-mode revert-time never - classic
CLI
configure service sdp mpls mixed-lsp-mode revert-time infinite
If the value of the revert-time timer is changed, it takes effect only at the next use of the timer. Any timer which is outstanding at the time of the change is restarted with the new value.
If class based forwarding is enabled for this SDP, the forwarding of the packets over the RSVP LSPs is based on the FC of the packet as in current implementation. When the SDP activates the LDP LSP type, then packets are forwarded over the LDP ECMP paths using the regular hash routine.
With LDP/BGP SDP, the service manager prefers the LDP LSP type over the BGP LSP type. The service manager re-programs the line card with the BGP LSP if available otherwise it brings down the SDP operationally.
The following are differences in behavior between the LDP/BGP SDP and the RSVP/LDP SDP. For a specific /32 prefix, only a single route exists in the routing table: the IGP route or the BGP route. Therefore, either the LDP FEC or the BGP label route is active at any time. The impact of this is that the tunnel table needs to be re-programmed each time a route is deactivated and the other is activated. Furthermore, the SDP revert-time cannot be used because there is no situation where both LSP types are active for the same /32 prefix.
- RSVP LSP type
Up to 16 RSVP LSPs can be entered by the user and programmed by the service manager in ingress line card to load balance service packets. This is the highest priority LSP type
- LDP LSP type
One LDP FEC programmed by service manager but ingress line card can use up to 16 LDP ECMP paths for the FEC to load balance service packets when ECMP is enabled on the node.
- BGP LSP type
One RFC 8277-labeled BGP prefix programmed by the service manager. The ingress line card can use more than one next-hop for the prefix.