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.
  1. Specify an originating node.
  2. Create an SDP ID.
  3. Specify an encapsulation type.
  4. 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.

Note: When specifying the far-end IP address, a tunnel is created. The path from Point A to Point B is created. When configuring a distributed service, an SDP ID must be specified. Use the show service sdp command to display the qualifying SDPs.

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.

Note: LDP uses a tunnel down damp timer which is set to three seconds by default. When the LDP LSP fails, the SDP reverts to the RSVP LSP type after the expiry of this timer. For an immediate switchover this timer must be set to zero; use the config>router>ldp>tunnel-down-damp-time command.

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.