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 type

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 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.
  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 commands 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 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
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 configure router ldp tunnel-down-damp-time command.

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.