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
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; an optional service name can also 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 following example provides an Epipe service configuration displaying the SDP and Epipe service entities. SDP ID 2 was created with the far-end node 10.10.10.104. Epipe ID 6000 was created for customer ID 6 which uses the SDP ID 2.
A:ALA-B>config>service# info detail
#------------------------------------------
...
sdp 2 gre create
description "GRE-10.10.10.104"
far-end 10.10.10.104
signaling tldp
no vlan-vc-etype
keep-alive
path-mtu 4462
keep-alive
shutdown
hello-time 10
hold-down-time 10
max-drop-count 3
timeout 5
no message-length
exit
no shutdown
exit
...
epipe 6000 name "customer-ABC-NW" customer 6 create
service-mtu 1514
sap 1/1/2:0 create
no multi-service-site
ingress
no scheduler-policy
qos 1
exit
egress
no scheduler-policy
qos 1
exit
no collect-stats
no accounting-policy
no shutdown
exit
spoke-sdp 2:6111 create
ingress
no vc-label
no filter
exit
egress
no vc-label
no filter
exit
no shutdown
exit
no shutdown
exit
...
#------------------------------------------
A:ALA-B>config>service#
Common 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 parameters include:
description
contact name
telephone number
multi-service site
Customer information
Use the following CLI syntax to create and input customer information:
config>service# customer customer-id [create]
— contact contact-information
— description description-string
— multi-service-site customer-site-name [create]
— assignment {port port-id | card slot}
— description description-string
— egress
— egress
— agg-rate
— burst-limit size [bytes | kilobytes]
— limit-unused-bandwidth
— queue-frame-based-accounting
— rate kilobits-per-second
— policer-control-policy name
— scheduler-override
— scheduler scheduler-name [create]
— parent {[weight weight] [cir-weight cir-weight]}
— rate pir-rate [cir cir-rate]
— scheduler-policy scheduler-policy-name
— ingress
— scheduler-override
— scheduler scheduler-name [create]
— parent {[weight weight] [cir-weight cir-weight]}
— rate pir-rate [cir cir-rate]
— scheduler-policy scheduler-policy-name
— phone phone-number
The following displays a basic customer account configuration.
A:ALA-12>config>service# info
-------------------------------------------
...
customer 5 create
description "Nokia Customer"
contact "Technical Support"
phone "650 555-5100"
exit
...
-------------------------------------------
A:A:ALA-12>config>service#
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 syntax to configure customer multi-service sites.
config>service# customer customer-id
— multi-service-site customer-site-name
— assignment {port port-id | card slot}
— description description-string
— egress
— agg-rate-limit agg-rate
— scheduler-policy scheduler-policy-name
— ingress
— scheduler-policy scheduler-policy-name
The following displays a customer’s multi-service-site configuration.
A:ALA-12>config>service# info
-------------------------------------------
..
customer 5 create
multi-service-site "EastCoast" create
assignment card 4
ingress
scheduler-policy "alpha1"
exit
exit
multi-service-site "WestCoast" create
assignment card 3
egress
scheduler-policy "SLA1"
exit
exit
description "Nokia Customer"
contact "Technical Support"
phone "650 555-5100"
exit
...
-------------------------------------------
A:ALA-12>config>service#
The following shows an example of a customer’s 7450 ESS multi-service-site configuration.
A:ALA-12>config>service# info
-------------------------------------------
..
customer 5 create
multi-service-site "EastCoast" create
assignment card 4
ingress
scheduler-policy "alpha1"
exit
exit
multi-service-site "WestCoast" create
assignment card 3
egress
scheduler-policy "SLA1"
exit
exit
description "Nokia Customer"
contact "Technical Support"
phone "650 555-5100"
exit
...
-------------------------------------------
A:ALA-12>config>service#
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 syntax to create an SDP and select an encapsulation type. If gre or mpls is not specified, the default encapsulation type is gre.
When specifying MPLS SDP parameters, specify an LSP or enable LDP. There cannot be two methods of transport in a single SDP except if the mixed-lsp command is specified. If an LSP name is specified, then RSVP is used for dynamic signaling within the LSP.
LSPs are configured in the config>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 following CLI syntax to create a GRE SDP or an MPLS SDP:
config>service>sdp sdp-id [gre | mpls] create
— adv-mtu-override
— description description-string
— far-end ip-address
— keep-alive
— hello-time seconds
— hold-down-time seconds
— max-drop-count count
— message-length octets
— timeout timeout
— no shutdown
— ldp (only for MPLS SDPs)
— lsp lsp-name [lsp-name] (only for MPLS SDPs)
— path-mtu octets
— signaling {off | tldp}
— no shutdown
The following displays an example of a GRE SDP, an LSP-signaled MPLS SDP, and an LDP-signaled MPLS SDP configuration.
A:ALA-12>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
...
-----------------------------------------
A:ALA-12>config>service#
Configuring a mixed-LSP SDP
Use the following command to configure an SDP with mixed LSP mode of operation:
config>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 how long 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:
config>service>sdp mpls>mixed-lsp-mode>sdp-revert-time seconds
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:
config>service>sdp mpls>mixed-lsp-mode>sdp-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:
In the case of the 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 re-programs the linecard 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 sdp-revert-time timer or the failure of the currently active LSP, whichever comes first. The service manager then re-programs the linecard accordingly. If the infinite value is configured, then the SDP reverts to the highest priority type LSP only if the currently active LSP failed.
If the value of the sdp-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.
In the case of the LDP/BGP SDP, the service manager prefers the LDP LSP type over the BGP LSP type. The service manager re-programs the linecard with the BGP LSP if available otherwise it brings down the SDP operationally.
Also note the following difference in behavior of the LDP/BGP SDP compared to that of an 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.