Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring Services Interfaces

Services Interface Naming Overview

Each interface has an interface name, which specifies the media type, the slot the FPC is located in, the location on the FPC that the PIC is installed in, and the PIC port. The interface name uniquely identifies an individual network connector in the system. You use the interface name when configuring interfaces and when enabling various functions and properties, such as routing protocols, on individual interfaces. The system uses the interface name when displaying information about the interface, for example, in the show interfaces command.

The interface name is represented by a physical part, a logical part, and a channel part in the following format:

The channel part of the name is optional for all interfaces except channelized DS3, E1, OC12, and STM1 interfaces.

The physical part of an interface name identifies the physical device, which corresponds to a single physical network connector. This part of the interface name has the following format:

type is the media type, which identifies the network device. For service interfaces, it can be one of the following:

  • ams—Aggregated multiservices (AMS) interface. An AMS interface is a bundle of services interfaces that can function as a single interface. An AMS interface is denoted as amsN in the configuration, where N is a unique number that identifies an AMS interface (for example, ams0). The member interfaces in an AMS interface are identified in the configuration with an mams- prefix (for example, mams-1/2/0).

  • cp—Flow collector interface.

  • es—Encryption interface.

  • gr—Generic routing encapsulation tunnel interface.

  • gre—This interface is internally generated and not configurable.

  • ip—IP-over-IP encapsulation tunnel interface.

  • ipip—This interface is internally generated and not configurable.

  • ls—Link services interface.

  • lsq—Link services intelligent queuing (IQ) interface; also used for voice services.

  • mams—Member interface in an AMS interface.

  • ml—Multilink interface.

  • mo—Monitoring services interface. The logical interface mo-fpc/pic/port.16383 is an internally generated, nonconfigurable interface for router control traffic.

  • ms—Multiservices interfaces on multiservices modular interfaces card (MS-MIC) and multiservices modular port concentrators (MS-MPC).

  • mt—Multicast tunnel interface. This interface is automatically generated, but you can configure properties on it if needed.

  • mtun—This interface is internally generated and not configurable.

  • rlsq—Redundancy LSQ interface.

  • rsp—Redundancy adaptive services interface.

  • si—Services inline interface, configured on MX3D Series routers only.

  • sp—Adaptive services interface. The logical interface sp-fpc/pic/port.16383 is an internally generated, nonconfigurable interface for router control traffic.

  • tap—This interface is internally generated and not configurable.

  • vt—Virtual loopback tunnel interface.

Enabling Service Packages

For AS PICs, Multiservices PICs, Multiservices DPCs, and the internal Adaptive Services Module (ASM) in the M7i router, there are two service packages: Layer 2 and Layer 3. Both service packages are supported on all adaptive services interfaces, but you can enable only one service package per PIC, with the exception of a combined package supported on the ASM. On a single router, you can enable both service packages by installing two or more PICs on the platform.

Note:

Graceful Routing Engine switchover (GRES) is automatically enabled on all services PICs and DPCs except the ES PIC. It is supported on all M Series, MX Series, and T Series routers except for TX Matrix routers. Layer 3 services should retain state after switchover, but Layer 2 services will restart. For IPsec services, Internet Key Exchange (IKE) negotiations are not stored and must be restarted after switchover. For more information about GRES, see the Junos OS High Availability User Guide.

You enable service packages per PIC, not per port. For example, if you configure the Layer 2 service package, the entire PIC uses the configured package. To enable a service package, include the service-package statement at the [edit chassis fpc slot-number pic pic-number adaptive-services] hierarchy level, and specify layer-2 or layer-3:

To determine which package an AS PIC supports, issue the show chassis hardware command: if the PIC supports the Layer 2 package, it is listed as Link Services II, and if it supports the Layer 3 package, it is listed as Adaptive Services II. To determine which package a Multiservices PIC supports, issue the show chassis pic fpc-slot slot-number pic-slot slot-number command. The Package field displays the value Layer-2 or Layer-3.

Note:

The ASM has a default option (layer-2-3) that combines the features available in the Layer 2 and Layer 3 service packages.

After you commit a change in the service package, the PIC is taken offline and then brought back online immediately. You do not need to manually take the PIC offline and online.

Note:

Changing the service package causes all state information associated with the previous service package to be lost. You should change the service package only when there is no active traffic going to the PIC.

The services supported in each package differ by PIC and platform type. Table 1 lists the services supported within each service package for each PIC and platform.

On the AS and Multiservices PICs, link services support includes Junos OS CoS components, LFI (FRF.12), MLFR end-to-end (FRF.15), MLFR UNI NNI (FRF.16), MLPPP (RFC 1990), and multiclass MLPPP. For more information, see Layer 2 Service Package Capabilities and Interfaces and Layer 2 Service Package Capabilities and Interfaces.

Note:

The AS PIC II for Layer 2 Service is dedicated to supporting the Layer 2 service package only.

Table 1: AS and Multiservices PIC Services by Service Package, PIC, and Platform

Services

ASM

AS/AS2 PICs and Multiservices PICs

AS/AS2 and Multiservices PICs

AS2 and Multiservices PICs

AS2 and Multiservices PICs

Layer 2 Service Package (Only) M7i M7i, M10i, and M20 M40e and M120 M320, T320, and T640 TX Matrix

Link Services:

         
  • Link services

Yes

Yes

Yes

Yes

No

  • Multiclass MLPPP

Yes

Yes

Yes

Yes

No

Voice Services:

         
  • CRTP and LFI

Yes

Yes

Yes

Yes

No

  • CRTP and MLPPP

Yes

Yes

Yes

Yes

No

  • CRTP over PPP (without MLPPP)

Yes

Yes

Yes

Yes

No

Layer 3 Service Package (Only) M7i M7i, M10i, and M20 M40e and M120 M320, T320, and T640 TX Matrix

Security Services:

         
  • CoS

Yes

Yes

Yes

Yes

No

  • Intrusion detection system (IDS)

Yes

Yes

Yes

Yes

No

  • IPsec

Yes

Yes

Yes

Yes

No

  • NAT

Yes

Yes

Yes

Yes

No

  • Stateful firewall

Yes

Yes

Yes

Yes

No

Accounting Services:

         
  • Active monitoring

Yes

Yes

Yes

Yes

Yes

  • Dynamic flow capture (Multiservices 400 PIC only)

No

No

No

Yes

No

  • Flow-tap

Yes

Yes

Yes (M40e only)

Yes

No

  • Passive monitoring (Multiservices 400 PIC only)

No

Yes

Yes (M40e only)

Yes

No

  • Port mirroring

Yes

Yes

Yes

Yes

Yes

LNS Services:

         
  • L2TP LNS

Yes

Yes (M7i and M10i only)

Yes (M120 only)

No

No

Voice Services:

         
  • BGF

Yes

Yes

Yes

Yes

No

Layer 2 and Layer 3 Service Package (Common Features) M7i M7i, M10i, and M20 M40e and M120 M320, T320, and T640 TX Matrix

RPM Services:

         
  • RPM probe timestamping

Yes

Yes

Yes

Yes

No

Tunnel Services:

         
  • GRE (gr-fpc/pic/port)

Yes

Yes

Yes

Yes

Yes

  • GRE fragmentation (clear-dont-fragment-bit)

Yes

Yes

Yes

No

No

  • GRE key

Yes

Yes

Yes

Yes

No

  • IP-IP tunnels (ip-fpc/pic/port)

Yes

Yes

Yes

Yes

Yes

  • Logical tunnels (lt-fpc/pic/port)

No

No

No

No

No

  • Multicast tunnels (mt-fpc/pic/port)

Yes

Yes

Yes

Yes

Yes

  • PIM de-encapsulation (pd-fpc/pic/port)

Yes

Yes

Yes

Yes

Yes

  • PIM encapsulation (pe-fpc/pic/port)

Yes

Yes

Yes

Yes

Yes

  • Virtual tunnels (vt-fpc/pic/port)

Yes

Yes

Yes

Yes

Yes

Layer 2 Service Package Capabilities and Interfaces

When you enable the Layer 2 service package, you can configure link services. On the AS and Multiservices PICs and the ASM, link services include support for the following:

  • Junos CoS components—Layer 2 Service Package Capabilities and Interfaces describes how the Junos CoS components work on link services IQ (lsq) interfaces. For detailed information about Junos CoS components, see the Junos OS Class of Service User Guide for Routing Devices.

  • LFI on Frame Relay links using FRF.12 end-to-end fragmentation—The standard for FRF.12 is defined in the specification FRF.12, Frame Relay Fragmentation Implementation Agreement.

  • LFI on MLPPP links.

  • MLFR UNI NNI (FRF.16)—The standard for FRF.16 is defined in the specification FRF.16.1, Multilink Frame Relay UNI/NNI Implementation Agreement.

  • MLPPP (RFC 1990)

  • MLFR end-to-end (FRF.15)

For the LSQ interface on the AS and Multiservices PICs, the configuration syntax is almost the same as for Multilink and Link Services PICs. The primary difference is the use of the interface-type descriptor lsq instead of ml or ls. When you enable the Layer 2 service package, the following interfaces are automatically created:

Interface types gr, ip, mt, pd, pe, and vt are standard tunnel interfaces that are available on the AS and Multiservices PICs whether you enable the Layer 2 or the Layer 3 service package. These tunnel interfaces function the same way for both service packages, except that the Layer 2 service package does not support some tunnel functions, as shown in Table 1.

Interface type lsq-fpc/pic/port is the physical link services IQ (lsq) interface. Interface types lsq-fpc/pic/port:0 through lsq-fpc/pic/port:N represent FRF.16 bundles. These interface types are created when you include the mlfr-uni-nni-bundles statement at the [edit chassis fpc slot-number pic pic-number] option. For more information, see Layer 2 Service Package Capabilities and Interfaces and Link and Multilink Services Interfaces User Guide for Routing Devices.

Note:

Interface type sp is created because it is needed by the Junos OS. For the Layer 2 service package, the sp interface is not configurable, but you should not disable it.

Services Configuration Procedure

You follow these general steps to configure services:

  1. Define application objects by configuring statements at the [edit applications] hierarchy level.
  2. Define service rules by configuring statements at the [edit services (ids | ipsec-vpn | nat | stateful-firewall) rule] hierarchy level.
  3. Group the service rules by configuring the rule-set statement at the [edit services (ids | ipsec-vpn | nat | stateful-firewall)] hierarchy level.
  4. Group service rule sets under a service-set definition by configuring the service-set statement at the [edit services] hierarchy level.
  5. Apply the service set on an interface by including the service-set statement at the [edit interfaces interface-name unit logical-unit-number family inet service (input | output)] hierarchy level. Alternatively, you can configure logical interfaces as a next-hop destination by including the next-hop-service statement at the [edit services service-set service-set-name] hierarchy level.
    Note:

    You can configure IDS, NAT, and stateful firewall service rules within the same service set. You must configure IPsec services in a separate service set, although you can apply both service sets to the same PIC.

Example: Service Interfaces Configuration

The following configuration includes all the items necessary to configure services on an interface:

Configuring Default Timeout Settings for Services Interfaces

You can specify global default settings for certain timers that apply for the entire interface. There are three statements of this type:

  • inactivity-timeout—Sets the inactivity timeout period for established flows, after which they are no longer valid.

  • open-timeout—Sets the timeout period for Transmission Control Protocol (TCP) session establishment, for use with SYN-cookie defenses against network intrusion.

  • close-timout—Sets the timeout period for Transmission Control Protocol (TCP) session tear-down.

To configure a setting for the inactivity timeout period, include the inactivity-timeout statement at the [edit interfaces interface-name services-options] hierarchy level:

The default value is 30 seconds. The range of possible values is from 4 through 86,400 seconds. Any value you configure in the application protocol definition overrides the value specified here; for more information, see Configuring Application Properties.

To configure a setting for the TCP session establishment timeout period, include the open-timeout statement at the [edit interfaces interface-name services-options] hierarchy level:

The default value is 5 seconds. The range of possible values is from 4 through 224 seconds. Any value you configure in the intrusion detection service (IDS) definition overrides the value specified here; for more information, see Configuring IDS Rules on an MS-DPC.

To configure a setting for the TCP session teardown timeout period, include the close-timeout statement at the [edit interfaces interface-name services-options] hierarchy level:

The default value is 1 second. The range of possible values is from 2 through 300 seconds.

Use of Keep-Alive Messages for Greater Control of TCP Inactivity Timeouts

Keep-alive messages are generated automatically to prevent TCP inactivity timeouts. The default number of keep-alive messages is 4. However, you can configure the number of keep-alive messages by entering the tcp-tickles statement at the [edit interaces interface-name service-options] hierarchy level.

When timeout is generated for a bidirectional TCP flow, keep-alive packets are sent to reset the timer. If number of consecutive keep-alive packets sent in a flow reaches the default or configured limit, the conversation is deleted. There are several possible scenarios, depending on the setting of the inactivity-timer and the default or configured maximum number of keep-alive messages.

  • If the configured value of keep-alive messages is zero and inactivity-timeout is NOT configured (in which case the default timeout value of 30 is used), no keep-alive packets are sent. The conversation is deleted when any flow in the conversation is idle for more than 30 seconds.

  • If the configured value of keep-alive messages is zero and the inactivity-timeout is configured, no keep-alive packets are sent, and the conversation is deleted when any flow in the conversation is idle for more than the configured timeout value.

  • If the default or configured maximum number of keep-alive messages is some positive integer, and any of the flows in a conversation is idle for more than the default or configured value for inactivity-timeout keep-alive packets are sent. If hosts do not respond to the configured number of consecutive keep-alive packets, the conversation is deleted. The interval between keep-alive packets will be 1 second. However, if the host sends back an ACK packet, the corresponding flow becomes active, and keep-alive packets are not sent until the flow becomes idle again.

Configuring System Logging for Services Interfaces

You specify properties that control how system log messages are generated for the interface as a whole. If you configure different values for the same properties at the [edit services service-set service-set-name] hierarchy level, the service-set values override the values configured for the interface. For more information on configuring service-set properties, see Configuring System Logging for Service Sets.

Note:

Starting with Junos OS Release 14.2R5, 15.1R3, and 16.1R1, for multiservices (ms-) interfaces, you cannot configure system logging for PCP and ALGs by including the pcp-logs and alg-logs statements at the [edit services service-set service-set-name syslog host hostname class] hierarchy level. An error message is displayed if you attempt to commit a configuration that contains the pcp-logs and alg-logs options to define system logging for PCP and ALGs for ms- interfaces.

To configure interface-wide default system logging values, include the syslog statement at the [edit interfaces interface-name services-options] hierarchy level:

Configure the host statement with a hostname or an IP address that specifies the system log target server. The hostname local directs system log messages to the Routing Engine. For external system log servers, the hostname must be reachable from the same routing instance to which the initial data packet (that triggered session establishment) is delivered. You can specify only one system logging hostname.

Starting with Junos OS release 17.4R1, you can configure up to a maximum of four system log servers (combination of local system log hosts and remote system log collectors) for each service set for ms interface under [edit interfaces interface-name services-options] hierarchy.

Table 2 lists the severity levels that you can specify in configuration statements at the [edit interfaces interface-name services-options syslog host hostname] hierarchy level. The levels from emergency through info are in order from highest severity (greatest effect on functioning) to lowest.

Table 2: System Log Message Severity Levels

Severity Level

Description

any

Includes all severity levels

emergency

System panic or other condition that causes the router to stop functioning

alert

Conditions that require immediate correction, such as a corrupted system database

critical

Critical conditions, such as hard drive errors

error

Error conditions that generally have less serious consequences than errors in the emergency, alert, and critical levels

warning

Conditions that warrant monitoring

notice

Conditions that are not errors but might warrant special handling

info

Events or nonerror conditions of interest

We recommend setting the system logging severity level to error during normal operation. To monitor PIC resource usage, set the level to warning. To gather information about an intrusion attack when an intrusion detection system error is detected, set the level to notice for a specific interface. To debug a configuration or log Network Address Translation (NAT) functionality, set the level to info.

For more information about system log messages, see the System Log Explorer.

To use one particular facility code for all logging to the specified system log host, include the facility-override statement at the [edit interfaces interface-name services-options syslog host hostname] hierarchy level:

The supported facilities include authorization, daemon, ftp, kernel, user, and local0 through local7.

To specify a text prefix for all logging to this system log host, include the log-prefix statement at the [edit interfaces interface-name services-options syslog host hostname] hierarchy level:

Configuring the TLS Syslog Protocol on MS-MPC and MS-MIC

Transport Layer Security (TLS) Overview

Starting with Junos OS Release 19.1R1, you can configure Transport Layer Security (TLS) for syslog messages generated by the services that run on the MS-MPC or MS-MIC service cards in an MX router. The services may be one of the following:

  • Junos Address Aware (formerly referred to as NAT feaures)

  • Junos VPN Site Secure (formerly referred to as IPsec features)

  • Junos Network Secure (formerly referred to as Stateful Firewall features)

Transport Layer Security (TLS) is an application-level protocol that provides encryption technology for the Internet. TLS relies on certificates and private-public key exchange pairs for this level of security. It is the most widely used security protocol for the applications that require data to be securely exchanged over a network, such as file transfers, VPN connections, instant messaging, and voice over IP (VoIP).

TLS protocol is used for certificate exchange, mutual authentication, and negotiating ciphers to secure the stream from potential tampering and eavesdropping. TLS is sometimes called as Secure Sockets Layer (SSL). TLS and SSL are not interoperable, though TLS currently provides some backward compatibility.

Benefits of TLS

TLS ensures the secure transmission of data between a client and a server through a combination of privacy, authentication, confidentiality, and data integrity.

Three Essential Services of TLS

The TLS protocol is designed to provide three essential services to the applications running above it: encryption, authentication, and data integrity.

  • Encryption—In order to establish a cryptographically secure data channel, the server and the client must agree on which cipher suites are used and the keys used to encrypt the data. The TLS protocol specifies a well-defined handshake sequence to perform this exchange. TLS uses public key cryptography, which allows the client and server to negotiate a shared secret key without having to establish any prior knowledge of each other, and to do so over an unencrypted channel.

  • Authentication—As part of the TLS handshake, the protocol allows both server and the client to authenticate their identity. Implicit trust between the client and the server (because the client accepts the certificate generated by the server) is an important aspect of TLS. It is extremely important that server authentication is not compromised; however, in reality, self- signed certificates and certificates with anomalies are in abundance. Anomalies can include expired certificates, instances of common name not matching a domain name, and so forth.

  • Integrity—With encryption and authentication in place, the TLS protocol does message framing mechanism and signs each message with a Message Authentication Code (MAC). The MAC algorithm does the effective checksum, and the keys are negotiated between the client and the server.

TLS Handshake

Each TLS session begins with a handshake during which the client and server agree on the specific security key and the encryption algorithms to use for that session. At this time, the client also authenticates the server. Optionally, the server can authenticate the client. Once the handshake is complete, transfer of encrypted data can begin.

Encrypting Syslog Traffic with TLS

TLS protocol ensures the syslog messages are securely sent and received over the network. TLS uses certificates to authenticate and encrypt the communication. The client authenticates the server by requesting its certificate and public key. Optionally, the server can also request a certificate from the client, thus mutual authentication is also possible.

A certificate on the server that identifies the server and the certificate of certificate authority (CA) issued by the server must be available with the client for TLS to encrypt syslog traffic.

For mutual authentication of client and the server, a certificate with the client that identifies the client and the certificate of CA issued by client must be available on the server. Mutual authentication ensures that the syslog server accepts log messages only from authorized clients.

TLS is used as a secure transport to counter all the primary threats to syslog listed below:

  • Confidentiality to counter disclosure of the message contents.

  • Integrity-checking to counter modifications to a message on a hop-by-hop basis.

  • Server or mutual authentication to counter masquerade.

TLS Versions

Following are the versions of TLS:

  • TLS version 1.0—Provides secure communication over networks by providing privacy and data integrity between communicating applications

  • TLS version 1.1—This enhanced version of TLS provides protection against cipher-block chaining (CBC) attacks.

  • TLS version 1.2 — This enhanced version of TLS provides improved flexibility for negotiation of cryptographic algorithms.

TLS Transport Protocol for Syslog Messages Configuration Overview

Starting with Junos OS Release 19.1R1, you can configure an MX series router to use Transport Layer Security (TLS) for syslog messages generated by services that run on the MS-MPC or MS-MIC service cards in an MX series router.

The following services packages are preinstalled and preconfigured on MS-MICs and MS-MPCs:

  • Junos Traffic Vision (formerly referred to as Jflow)

  • Junos Address Aware (formerly referred to as NAT features)

  • Junos VPN Site Secure (formerly referred to as IPsec features)

  • Junos Network Secure (formerly referred to as the Stateful Firewall feature)

  • Junos Services Crypto Base PIC Package

  • Junos Services Application Level Gateways

You can configure a maximum of four syslog servers for each set of services and send encrypted data to the servers.

Syslog messages are sent over a dedicated connection created for a given set of unique configuration parameters:

  • Source IP address

  • Destination IP address (TCP/TLS server)

  • Port

  • SSL profile name (For TLS connection)

    Note:

    If the ssl-profile is not configured under the tcp-log hierarchy, then it is a non-TLS TCP transport.

Note:

If there are multiple service sets that have the TCP/TLS logging configuration with the same parameters as mentioned above, the logs generated from the sessions from all those service sets share the same connection.

This feature supports both IPv4 and IPv6.

Note:

The configured TCP/TLS connection remains up until the configuration is present even if there are no logging events.

TCP/TLS sylog configuration support is provided for secure and reliable logging only on the data plane.

For Aggregated Multi Service (AMS) with multiple active members, each member creates a separate TCP/TLS connection and syslogs generated by each member PIC are sent via their unique connections.

Configuring TCP/TLS for Syslog Messages

You can use the TCP/TLS transport protocols to send syslog messages in a reliable and secure manner to external syslog servers.

To configure the TCP/TLS protocols for syslog messages:

  1. Configure the SSL initiation profile.
    Note:

    Configuration of SSL initiation profile is optional if you are not using the TLS/TCP option for syslog messages.

    protocol-version—Default is set to all. When set to all SSL version 3 and TLSL version 1 is handled. Default is recommended.

    preferred-ciphers—strong—ciphers with key strength >= 168-bits. Use of strong ciphers is recommended.

    See initiation (Services) for configuring all the parameters of the initiation statement.

  2. Configure the TCP log parameters.

    source-address—Source address for tcp logging.

  3. Configure SSL profile for TCP logging.

    ssl-profile—SSL profile name for tcp logging

    See profile (SSL Initiation) for configuring all the options for ssl-profile.

  4. [Optional] Configure routing instance name for tcp logging.

    vrf-name—Routing instance name for tcp logging.

  5. Commit the configuration.

    After the commit, the configuration creates a new TCP connection with TLS connection if the SSL profile is configured.

  6. Verify the configuration by using the show services tcp-log connections command:

    TCP/TLS syslog connection is established with MS-MPC’s services L4 data sessions infrastructure and the session’s status can be tracked with following command:

    Note:

    The session-id in both the commands should match as highlighted in bold above.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
14.2R5
Starting with Junos OS Release 14.2R5, 15.1R3, and 16.1R1, for multiservices (ms-) interfaces, you cannot configure system logging for PCP and ALGs by including the pcp-logs and alg-logs statements at the [edit services service-set service-set-name syslog host hostname class] hierarchy level.