Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    New Features in JUNOS Release 10.2 for M Series, MX Series, and T Series Routers

    The following features have been added to JUNOS Release 10.2. Following the description is the title of the manual or manuals to consult for further information.

    Class of Service

    • Support for Layer 2 policers at the VLAN level on Trio MPC/MIC interfaces (MX Series platforms with Trio MPC/MIC interfaces)—Layer 2 policers at the VLAN level are supported on an MX Series router with Trio MPCs/MICs.

      [Class of Service]

    • Different classifiers for different virtual circuits (ATM interfaces)—Enables you to combine Layer 2 and Layer 3 classifications on ATM interfaces where some VCs are part of a VPLS instance and other belong to an L3VPN. To configure, include the classifiers statement at the [edit class-of-service interfaces at-x/y/zunit logical-interface-number] hierarchy level.

      [Class of Service]

    • DSCP classification for VPLS at ingress PE (M320 with Enhanced Type III FPC and M120)—Enables you to configure DSCP classification for VPLS at ingress PE for encapsulation types vlan-vpls (IQ2 or IQ2E PICs) or ATM II IQ PIC. To configure, define the DSCP classifier at the [edit class-of-service classifiers dscp dscp-name] hierarchy level and apply the DSCP classifier at the [edit interfaces at-fpc-pic-port unit-logical-unit-number classifiers] hierarchy level. The ATM interface must be included in the routing instance.

      [Class of Service]

    High Availability

    • Nonstop active routing support for Layer 2 VPN and Layer 3 VPN over RSPV-TE LSPs—Starting with Release 10.2, the JUNOS Software extends the nonstop active routing support to Layer 2 VPN and Layer 3 VPN over RSVP-TE LSPs. JUNOS Release 10.2 also extends the nonstop active routing support for Layer 3 VPNs to cover the following OSPF features and configurations:

      • domain-id domain-id statement at the [edit routing-instances routing-instance-name protocols (ospf | ospf3)] hierarchy level
      • domain-vpn-tag number statement at the [edit routing-instances routing-instance-name protocols (ospf | ospf3)] hierarchy level
      • metric number statement at the [edit routing-instances routing-instance-name protocols ospf area area-id sham-link-remote] hierarchy level
      • sham-link local address statement at the [edit routing-instances routing-instance-name protocols ospf] hierarchy level
      • sham-link-remote address <metric number> statement at the [edit routing-instances routing-instance-name protocols ospf area area-id] hierarchy level

    Interfaces and Chassis

    • List of Supported Software Features for MX Series MPCs—The following link contains a high level list of software features for MX Series MPCs. For information about MPC support for subordinate statements of these software features see the Junos Layer 2 Configuration Guide.

      https://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/
      general/mpc-mx-series-features.html

    • New 2-port MIC with XFP (model number MIC-3D-2XGE-XFP)—This MIC can be installed into the new Type 1 MPCs (supported on MX240, MX480, MX960 routers) or can be installed directly into two slots in a modular MX80 chassis. For a list of supported MICs and MPCs, see the MX Series Line Card Guide.
    • New 30-Gigabit Ethernet queuing MPC (model number MX-MPC1-3D-Q)—Supported on MX240, MX480, and MX960 routers. For a list of supported MPCs, see the MX Series Line Card Guide.
    • New 30-Gigabit Ethernet MPC (model number MX-MPC1-3D)—Supported on MX240, MX480, and MX960 routers. For a list of supported MPCs, see the MX Series Line Card Guide.
    • New 40-port dual-wide Tri-rate MIC (model number MIC-3D-40GE-TX)—Supported on the MX Series routers. The Tri-rate MIC contains 40 autonegotiating 10Base-T, 100Base-TX, or 1000Base-T Megabit Ethernet ports. The Tri-rate MIC installs into both slots of an MPC in a MX240, MX480, and MX960 routers or directly into two slots in a modular MX80 chassis. For a list of supported MICs and MPCs, see the MX Series Line Card Guide.
    • Modular Port Concentrators (MPCs) on MX240, MX480 and MX960 routers—Provide tunnel support parity, replacing traditional tunnel and services PICs with tunnels that were supported on a "virtual" port on MX240, MX480, and MX960 PFEs. MX240, MX480, MX960 routers support a virtual PIC and a virtual port, visible for tunnel configuration, and eliminating the need for a tunnel PIC. Traditional tunnel PIC features are supported, including:
      • GRE keys
      • GRE Clear-dont-fragment

      Certain services PIC features are not supported. On MPCs there are no tunnel PICs. Instead some bandwidth is taken off the WAN ports from the MX240, MX480, and MX960 routers and reserved for tunneling. In the presence of tunnel traffic, all WAN ports are affected in case of oversubscription.

      On MX240, MX480, and MX960 routers, the following types of tunnel ports are supported:

      • A 1–Gbps tunnel port on 10x1GE PFE complex
      • A 10–Gbps tunnel port on 1x10GE PFE complex

      On MX240, MX480, and MX960 routers, tunnel services can be enabled by configuring tunnel-services bandwidth on a particular virtual PIC. For example:


      user@host# show chassis
        fpc 0 {
          pic 0 {
              tunnel-services {
                  bandwidth 1g;
              }
          }
      
          pic 1 {
              tunnel-services {
                  bandwidth 1g;
              }
          }
      
        }

      This enables tunnel services with a bandwidth of 1–Gbps on FPC 0 and PIC 0. Correspondingly, chassisd can create devices such as the following:

      • vt-0/0/10, ip-0/0/10, etc. for pic0
      • vt-0/1/10 ip-0/1/10 etc. for pic1

      Currently supported bandwidth values are 1 Gbps and 10 Gbps. Devices are created with port 10 for 1-Gbps tunnels and port 0 for 10-Gbps tunnels.

      These tunnels with their associated configurations work when an MX-DPC is replaced by an MPC. This means the router creates tunnel devices based on the tunnel services configuration. This means that although the same PFE supports vt-0/0/10 and vt-0/1/10, two devices must be created to be compatible with the above configuration. The MPC allows you to configure four tunnel MICs per MPC (to support vt-0/0/10, vt-0/1/10, vt-0/2/10, and vt-0/3/10), although in reality there are only two physical MICs. This is achieved by creating logical MICs on MPCs.

      In addition, you can add physical interfaces to the MPC because no MICs are associated with these tunnel physical interfaces.

      [Services Interfaces]

    • Restrictions on NAT configuration on DPCs (MX Series platforms with Multiservices DPC service interfaces)—If you configure a basic 1:1 destination NAT rule with address prefixes in the pool, NAT will not work as expected. Also, if you configure port allocation for all NAT translations with a redundancy services (RSP) interface, NAT will not work as expected.

      [Services Interfaces]

    • Voice over IP (VoIP) services—In JUNOS Release 10.2, MX Series MPCs support Border Gateway Function (BGF) and Integrated Multi-Service Gateway (IMSG). For a list of supported protocols and applications, see the MX Series Line Card Guide.
    • Support for Layer 2 Ethernet OAM (MX Series routers with Trio MPC/MIC Ethernet interfaces)—MX Series routers with Trio MPC/MIC Ethernet interfaces supports parity of all Layer 2 OAM for 802.1ag for inet family features supported by MX Series routers as of JUNOS Release 9.1.

      [Network Interfaces]

    • Support for MPC tunnel features with other DPC types (MX Series platforms with Trio MPC/MIC interfaces)—If you configure tunnels on an MX Series router with both Trio MPCs/MICs and DPCs, all tunnel functions support parity with JUNOS Release 9.2.

      [Network Interfaces]

    • Enhanced IQ (IQE) PICs for M7i and M10i routers—M7i and M10i routers now support the following Enhanced IQ (IQE) PICs:
      • 4-port Channelized DS3 and E3 Enhanced IQ (IQE)PIC (PE-4CHDS3-E3-IQE-BNC)
      • 10-port Channelized E1/T1 Enhanced IQ (IQE) PIC (PE-10CHE-T1-IQE-RJ48)
      • 2-port Channelized OC3/STM1 Enhanced IQ (IQE) PIC with SFP (PE-2CHOC3-STM1-IQE-SFP)
      • 1-port Channelized OC12/STM4 Enhanced IQ (IQE) PIC with SFP (PE-1CHOC12STM4-IQE-SFP)
      • 4-port DS3/E3 Enhanced IQ (IQE)PIC (PE-4DS3-E3-IQE-BNC)
      • 4-port SONET/SDH OC3/STM1 Enhanced IQ (IQE) PIC with SFP (PE-4OC3-STM1-IQE-SFP)
      • 1-port SONET/SDH OC12/STM4 Enhanced IQ (IQE) PIC with SFP (PE-1OC12-STM4-IQE-SFP)

      The IQE PICs support the same features as the existing IQ PICs, as well as enhanced CoS and diagnostic features. The valid configuration statements are also the same, but the limits and range of values for some options are different to support augmented capabilities.

      [M7i PIC Guide, M10i PIC Guide, Class of Service, Network Interfaces]

    • New MX80 Ethernet services router—There are two MX80 routers: one with a modular chassis and one with a fixed chassis. Each router is a compact Ethernet-optimized edge router that provides provide switching and carrier class Ethernet routing. Both provide up to 40 gigabits per second (Gbps) full duplex, high-density Ethernet interfaces and high capacity switching throughput. Both use the Trio chipset for increased scalability of L2/L3 packet forwarding, buffering, and queuing. Each router supports parity in software features supported by other MX Series routers as of JUNOS Release 9.2. To view JUNOS Release 9.2 documentation, see: https://www.juniper.net/techpubs/software/junos/junos92/index.html. The show chassis family of commands has been updated to provide information about MX80 routers.

      Note: The MX80 router with fixed configuration does not support hierarchical queuing, congestion dropping, or statistics.

      The MX80 router with modular configuration includes four built-in 10-Gigabit Ethernet ports and two slots that support the following Modular Interface Cards (MICs):

      • 20-port Gigabit Ethernet MIC with SFP
      • 2-port 10-Gigabit Ethernet MIC with XFP
      • 40-port Gigabit Ethernet MIC (dual-wide)

      The MX80 router with fixed configuration includes 4 built-in 10-Gigabit Ethernet ports and 48 built-in 10/100/1000Base-TX-RJ45 ports.

      The MX80 router is a single-board router with a built-in Routing Engine and one Packet Forwarding Engine (PFE), which can have up to two Modular Interface Cards (MICs). (A Services PIC slot is currently not supported.) The PFE has two “pseudo” Flexible PIC Concentrators (FPC 0 and FPC1). Because there is no switching fabric, the single PFE takes care of both ingress and egress packet forwarding.

      On both routers, the four built-in 10-Gigabit Ethernet ports are mapped to FPC 0. On the MX80 router with modular configuration, the MIC slots are mapped to FPC 1. On the MX80 router with fixed configuration, the 48 built-in 10/100/1000Base-TX-RJ45 ports are mapped to FPC 1.

      [MX80 Hardware]

    • Tunable XFP support (MX960, MX480, MX240, T640, and T1600)—Provides support for wavelength tunable non-OTN (optical transport network) 10–Gigabit Ethernet XFPs. All forwarding, OAM, and control plane features supported on the current DPCs, MICs, and PICs are supported on the above routers. This feature is not supported on MX80 and T320 routers.

      You can use the existing wavelength statement to configure the wavelength of the optics at the [edit interfaces interface-name optic-options] hierarchy level.

      The following existing configuration mode commands are supported for tunable XFPs:

      • show chassis hardware
      • show chassis pic
      • show interfaces

      [Network Interfaces]

    • Support for external clock synchronization on T Series routers (T320, T640, T1600)—The T320, T640, and T1600 routers support external clock interfaces on the Sonic Clock Generators (SCG). When external clock synchronization is configured, this clock is distributed through the FPCs to each PIC interface.

      To configure external clock synchronization, include the following statements at the [edit chassis] hierarchy level:

      synchronization { primary (external-a | external-b);secondary (external-s | external-b);switching-mode (revertive | non-revertive);validation-interval seconds;}

      [System Basics]

    • Support for 802.1ag Ethernet OAM for VPLS extended to M320 (with Enhanced III FPC), M120, and to M10i and M7i (with CFEB) routers with Gigabit Ethernet IQ2, IQ2E, and IQ2E PICs—Extends the 802.1ag VPLS functionality to the specified routers. 802.1ag was previously supported only on Layer 2 circuits, Layer 2 VPNs, and routable interfaces on the specified router, FPC, and interface combinations.

      Configuration for this feature is performed in the same way as the existing OAM VPLS CLI feature configuration on MX Series routers. To configure CFM, include the connectivity-fault-management statement and substatements at the [edit protocols oam ethernet] hierarchy level

      [Network Interfaces]

    • Quality-of-service (QoS) support for ATM on circuit emulation PICs—On M7i, M10i, M40e, M120, and M320 routers, the Channelized OC3/STM1 Circuit Emulation PICs (PB-4CHOC3-CE-SFP and PE-4CHOC3-CE-SFP) and E1/T1 Circuit Emulation PICs (PB-12T1E1-CE-TELCO and PE-12T1E1-CE-TELCO) provide QoS features that match or exceed those of the ATM-II PIC.

      Circuit Emulation PICs provide ingress and egress direction traffic shaping. Policing is performed by monitoring the configured parameters on the incoming traffic and is also referred to as ingress shaping. Egress shaping uses queuing and scheduling to shape the outgoing traffic. This is an enhancement over the ATM-II PIC, which only provides egress shaping. Classification is provided per virtual circuit (VC).

      The following features are supported:

      • Port-level egress shaping
      • Support for CBR, rtVBR, nrtVBR, and UBR
      • Policing on a per VC basis
      • Independent PCR and SCR policing
      • Counting, tagging, or discard policing actions

      CLI configuration is similar to that of QoS features for the ATM-II PIC. To configure shaping for logical interfaces in port promiscuous mode, use the shaping statement and its substatements at the [interfaces at-fpc/pic/port unit] hierarchy level.

      [Network Interfaces]

    • Enhanced graceful Routing Engine switchover (GRES) support for PD-5-10XGE-SFPP PICs (T640 routers connected to a TX Matrix router)—JUNOS Release 10.2 extends GRES support for 10-port 10-Gigabit Ethernet Oversubscribed Ethernet PIC (PD-5-10XGE-SFPP) in T640 routers connected to a TX Matrix router.
    • Targeted broadcast support for virtual routing and forwarding (VRF) (M Series, MX Series, and T Series routers)—Enables IP packets destined for a Layer 3 broadcast address to transit to an egress interface on a router. The packets are broadcast only if the egress interface is a LAN interface. This feature is useful when the Routing Engine is flooded with packets to process.

      Targeted broadcast enables a broadcast packet destined for a remote network to transit across networks until the destination network is reached. In the destination network, the broadcast packet is broadcast as a normal broadcast packet.

      To configure targeted broadcast on a broadcast interface, include the targeted-broadcast statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level.

      You can configure targeted broadcast in two ways:

      • To forward broadcast packets to both the egress interface and the Routing Engine, include the forward-and-send-to-re statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level.
      • To forward broadcast packets to the egress interface only, include the forward-only statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level.

      When you do not include the targeted-broadcast statement, a copy of each broadcast packet is sent to the Routing Engine. When you include the targeted-broadcast statement without either the forward-and-send-to-re or forward-only statement, broadcast packets are discarded.

      [Network Interfaces]

    • High availability hot-standby for FRF.15 (MLFR) and FRF.16 (MFR) configurations on Multiservices PICs and DPCs (M Series, MX Series, and T Series routers)—Extends support for the hot-standby option to FRF.15 and FRF.16 on redundant paired LSQ interfaces. This feature is supported on Multiservices PICs and DPCs.

      Provides a switchover time of 5 seconds or less for FRF.15, and provides a maximum of 10 seconds switchover time for FRF.16.

      To configure redundant LSQ hot-standby functionality for FRF.15, configure the hot-standby statement at the [edit interfaces rlsqnumber redundancy-options] hierarchy level and the multilink-frame-relay-end-to-end statement at the [edit interfaces rlsqnumber unit logical-unit-number encapsulation] hierarchy level.

      To configure redundant LSQ hot-standby functionality for FRF.16, include the hot-standby statement at the [edit interfaces rlsqnumber:number encapsulation multilink-frame-relay-uni-nni redundancy-options] hierarchy level.

      [Services Interfaces]

    • M7i, M10i, M120, and M320 routers (with Enhanced III FPC) support ATM scheduler for RFC1483 bridged interface—Extends ATM scheduler support for RFC1483 bridged interface functionality to the specified routers.

      [Network Interfaces]

    • Support for xSTP on Trio MPC/MIC interfaces (MX Series platforms with Trio MPC/MIC interfaces)—All types of xSTPs are supported on an MX Series router with Trio MPCs/MICs.

      [Layer 2 Configuration Guide]

    • Support for targeted broadcast for virtual routing and forwarding (VRF) instances on MX Series routers—The MX960, MX480, and M240 routers now support targeted broadcast which IP packets destined for a Layer 3 broadcast address to transit to an egress interface on a router. The packets are broadcast only if the egress interface is a LAN interface. This feature is supported on aggregated Ethernet interfaces and is useful when the Routing Engine is flooded with packets to process.

      Targeted broadcast enables a broadcast packet destined for a remote network to transit across networks till the destination network is reached. In the destination network, the broadcast packet is broadcast as a normal broadcast packet.

      To configure targeted broadcast on a broadcast interface, include the targeted-broadcast statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level.

      You can configure targeted broadcast in two ways:

      • To forward broadcast packets to both the egress interface and the Routing Engine, include the forward-and-send-to-re statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level.
      • To forward broadcast packets to the egress interface only, include the forward-only statement at the [edit interfaces interface-name unit logical-unit-number family inet targeted-broadcast] hierarchy level.

      When you do not include the targeted-broadcast statement, a copy of each broadcast packet is sent to the Routing Engine. When you include the targeted-broadcast statement without either the forward-and-send-to-re or forward-only statement, broadcast packets are discarded.

      [Network Interfaces]

    • New statement to sync the FPC that is brought online with other active FPCs (M320, T320, T640, T1600, TX Matrix, and TX Matrix Plus routers)—M320, T320, T640, T1600, TX Matrix, and TX Matrix Plus routers now support the fpc-resync configuration statement at the [edit chassis] hierarchy level. When you bring a Flexible PIC Concentrator (FPC) online, the sequence number on the FPC may not be synchronized with the other active FPCs in the router, which may result in the loss of a small amount of initial traffic. To avoid any traffic loss, include the fpc-resync statement at the [edit chassis] hierarchy level. This ensures that the sequence number of the FPC that is brought online is resynchronized with the other active FPCs in the router.

      [System Basics]

    JUNOS XML API and Scripting

    • New JUNOS XML API operational request tag elementsTable 1 lists the JUNOS Extensible Markup Language (XML) operational request tag elements that are new in JUNOS Release 10.2, along with the corresponding CLI command and response tag element for each one.

      Table 1: JUNOS XML Tag Elements and CLI Command Equivalents New in JUNOS 10.2

      Request Tag Element

      CLI Command

      Response Tag Element

      <clear-service-bsg-registrations> clear_service_bsg_registrations

      clear services border-signaling-gateway registrations

      <clear-service-bsg-registrations>

      <clear-service-bsg-registrations-statistics> clear_service_bsg_registrations_statistics

      clear services border-signaling-gateway registrations statistics

      <clear-service-bsg-registrations>

      <clear-services-bsg-registrations-subscription> clear_services_bsg_registrations_subscription

      clear services border-signaling-gateway registrations subscription

      <clear-services-bsg-registrations-subscription>

      <get-syslog-facility-information> get_syslog_facility_information

      help syslog facility

      <syslog-tag-information>

      <request-ping-rsvp-dynamic-bypass-lsp> request_ping_rsvp_dynamic_bypass_lsp

      ping mpls rsvp dynamic-bypass

      NONE

      <request-ping-rsvp-manual-bypass-lsp> request_ping_rsvp_manual_bypass_lsp

      ping mpls rsvp manual-bypass

      NONE

      <request-logout-user> request_logout_user

      request system logout

      <logout-user>

      <get-environment-
      power-supply-unit-
      information> get_environment_
      power_supply_unit_information

      show chassis environment power-supply-unit

      <environment-component-information>

      <get-fm-topology> get_fm_topology

      show chassis fabric map

      <fm-topology>

      <get-fm-plane-location-information> get_fm_plane_location_information

      show chassis fabric plane-location

      <fm-plane-location-information>

      <get-fru-power-on-sequence> get_fru_power_on_sequence

      show chassis power sequence

      <fru-power-on-sequence>

      <get-power-budget-information> get_power_budget_information

      show chassis power-budget-statistics

      <power-budget-information>

      <get-tfeb-information> get_tfeb_information

      show chassis tfeb

      <scb-information>

      <get-vcpu-information> get_vcpu_information

      show chassis vcpu

      <vcpu-information>

      <get-cos-service-session-information> get_cos_service_session_information

      show class-of-service service-session

      <cos-service-session-information>

      <get-gre-ka-information> get_gre_ka_information

      show oam gre-keepalive

      <oamd-information>

      <get-pppoe-session-information> get_pppoe_session_information

      show pppoe sessions

      <pppoe-session-information>

      <get-r2cp-interface-information> get_r2cp_interface_information

      show r2cp interfaces

      <r2cp-interface-information>

      <get-r2cp-radio-information> get_r2cp_radio_information

      show r2cp radio

      <r2cp-radio-information>

      <get-r2cp-session-information> get_r2cp_session_information

      show r2cp sessions

      <r2cp-session-information>

      <get-r2cp-statistics> get_r2cp_statistics

      show r2cp statistics

      <r2cp-statistics>

      <get-service-
      accounting-error-
      inline-jflow-
      information> get_service_
      accounting_error_
      inline_jflow_
      information

      show services accounting errors inline-jflow

      <service-accouting-inline-jflow-error-infomation>

      <get-service-
      accounting-status-inline-
      jflow-flow-information> get_service_
      accounting_status_
      inline_jflow_
      flow_information

      show services accounting flow inline-jflow

      <service-accouting-inline-jflow-flow-infomation>

      <get-service-
      accounting-status-inline-
      jflow-information> get_service_
      accounting_status_
      inline_jflow_
      information

      show services accounting status inline-jflow

      <service-accouting-inline-jflow-information>

      <get-service-
      border-signaling-
      gateway-address-
      of-record> get_service_
      border_signaling_
      gateway_address_
      of_record

      show services border-signaling-gateway address-of-record

      <bsg-address-of-records>

      <get-service-border-
      signaling-gateway-
      address-of-
      record-bindings> get_service_
      border_signaling_
      gateway_address_
      of_record_
      bindings

      show services border-signaling-gateway address-of-record bindings

      <bsg-address-of-record-bindings>

      <get-service-
      border-signaling-gateway-
      statistics-calls-by-server> get_service_border_
      signaling_gateway_
      statistics_calls_
      by_server

      show services border-signaling-gateway calls by-server

      NONE

      <get-service-
      border-signaling-
      gateway-statistics-
      calls-by-sp> get_service_
      border_signaling_
      gateway_statistics_
      calls_by_sp

      show services border-signaling-gateway calls by-service-point

      NONE

      <get-service-
      border-signaling-gateway-
      statistics-calls-duration
      -by-server> get_service_border_
      signaling_gateway_
      statistics_calls_
      duration_by_server

      show services border-signaling-gateway calls-duration by-server

      NONE

      <get-service-
      border-signaling-gateway-
      statistics-calls-duration-by-
      sp> get_service_border_signaling
      _gateway_statistics_calls_
      duration_by_sp

      show services border-signaling-gateway calls-duration by-service-point

      NONE

      <get-service-
      border-signaling-gateway-
      statistics-failed-
      calls-by-server> get_service_
      border_signaling_gateway_
      statistics_failed_calls_by_
      server

      show services border-signaling-gateway calls-failed by-server

      NONE

      <get-service-border-signaling-gateway
      -statistics-failed-
      calls-by-sp> get_service_
      border_signaling_gateway
      _statistics_failed_calls_
      by_sp

      show services border-signaling-gateway calls-failed by-service-point

      NONE

      <get-service-
      bsg-registrations> get_service_
      bsg_registrations

      show services border-signaling-gateway registrations

      <bsg-registrations>

      <get-service-
      bsg-registrations-
      realm-statistics> get_service_bsg_
      registrations_
      realm_statistics

      show services border-signaling-gateway registrations realm

      <bsg-registrations-realm>

      <get-service-
      bsg-registrations-
      statistics> get_service_
      bsg_registrations_
      statistics

      show services border-signaling-gateway registrations statistics

      <bsg-registrations>

      <get-service-border-
      signaling-gateway-
      routing-blacklist> get_service_
      border_signaling_
      gateway_routing_
      blacklist

      show services border-signaling-gateway routing-blacklist

      <bsg-routing-blacklist>

      <get-service-
      softwire-table-
      information> get_service_
      softwire_table_
      information

      show services softwire

      <service-softwire-table-information>

      <get-service-
      fwnat-flow-
      table-information>
      get_service_
      fwnat_flow_table_
      information

      show services softwire flows

      <service-fwnat-flow-table-information>

      <get-subscribers-
      summary> get_subscribers_
      summary

      show subscribers summary

      <subscriber>

      <get-system-
      storage-partitions> get_system_
      storage_partitions

      show system storage partitions

      <system-storage-information>

      <get-system-
      virtual-memory-
      information> get_system_
      virtual_memory_information

      show system virtual-memory

      <system-virtual-memory-information>

      [JUNOS XML API Operational Reference]

    Layer 2 Ethernet Services

    • Ethernet Ring Protocol (ERP) support for multiple ring instances on the same physical ring (MX240, MX480, and MX960 routers)—This Layer 2 feature extends Ethernet Ring Protocol (ERP) support to include multiple ring instances on the same physical ring on MX960, MX480, and MX240 routers. Each ring instance will control a set of virtual LAN (VLAN) IDs. For a physical ring, traffic between two nodes usually follows the same path. By creating multiple ring instances, some traffic passes through one path, while other traffic can pass through a different path. The result is improved load-balancing of traffic in the physical ring.

      To configure multiple ring instances, include the data-channel configuration statement with VLAN ID options at the [edit protocols protection-group ethernet-ring group-name] hierarchy level.

      New operational mode commands support this feature. To display data channel information for all Ethernet ring protection groups, use the show protection-group ethernet-ring data-channel command. To display data channel information for a specific Ethernet ring protection group, use the show protection-group ethernet-ring data-channel groupname command. To display data channel VLAN information for all Ethernet ring protection groups, use the show protection-group ethernet-ring vlan command. To display data channel VLAN information for a specific Ethernet ring protection group, use the show protection-group ethernet-ring vlan groupname command.

      [Layer 2 Configuration, Interfaces Command Reference]

    MPLS Applications

    • Switching LSPs away from a network node—You can configure the router to switch active LSPs away from a network node by using a bypass LSP enabled for an interface. This feature can be used in maintenance of active networks when a network device needs to be replaced without interrupting traffic passing through the network. The LSPs can be either static or dynamic. You need to first configure either link or node protection for the traffic that needs to pass around the network device you intend to disable. To function properly, the bypass LSP must use a different logical interface, rather than the protected LSP.

      To configure the router to switch traffic around a network node, configure the always-mark-connection-protection-tlv statement at the [edit protocols mpls interface interface-name] hierarchy level. This statement marks all OAM traffic transiting this interface in preparation for switching the traffic to an alternate path based on the OAM functionality. Next, configure the switch-away-lsps statement at the [edit protocols mpls interface interface-name] hierarchy level. This statement switches the traffic from the protected LSP to the bypass LSP, effectively bypassing the default downstream network device. The actual link is not brought down by this procedure itself. This feature is supported on MX Series routers only.

      [MPLS]

    • Hello acknowledgements for non-session RSVP neighbors—You can now acknowledge hello messages sent from non-session RSVP neighbors with a hello acknowledgement message by including the hello-acknowledgements statement at the [edit protocols rsvp hello-acknowledgements] hierarchy level. When hellos are received from non-session neighbors, an RSVP neighbor relationship is created and periodic hello messages can now be received from the non-session neighbor. Interface-based neighbors are not automatically aged out.

      [MPLS]

    Multicast

    • Load-balancing multicast tunnel interfaces among available PICs—For draft-rosen Layer 3 VPNs, enables you to manually load-balance multicast tunnel interfaces across a configured list of tunnel-capable PICs. To configure the list, include the tunnel-devices statement at the [edit routing-instances instance-name protocols pim] hierarchy level. In some cases, you might need to manually force a rebalanced state. To do this, run the request pim multicast-tunnel rebalance command with or without the instance option.

      [Multicast]

    • Automatic Multicast Tunneling (AMT) support—Automatic Multicast Tunneling (AMT) facilitates dynamic multicast connectivity between multicast enabled networks across islands of unicast-only networks. This enables service providers, content providers, and their customers that do not have multicast connectivity end-to-end, to participate in delivering multicast traffic.

      AMT dynamically establishes unicast-encapsulated tunnels between well-known multicast-enabled relay points (AMT relays) and network points reachable only through unicast (AMT gateways).

      The AMT protocol provides for discovery and handshaking between relays and gateways to establish tunnels dynamically without requiring explicit per-tunnel configuration.

      AMT relays are typically routers with native IP multicast connectivity that aggregate a potentially large number of AMT tunnels.

      AMT gateways are devices that require connection to the IP multicast network but lack multicast routing capability or direct connection to multicast-capable routers. Gateways may be either individual hosts or routers that are partitioned from the larger multicast infrastructure.

      AMT is described in detail in Automatic IP Multicast Without Explicit Tunnels (AMT), draft-ietf-mboned-auto-multicast-09.txt.

      Note: Multicast sources located behind AMT gateways are not supported.

      To configure the AMT protocol, include the amt configuration statement at the [edit protocols] hierarchy level.

      amt {traceoptions {file ...flag all; flag errors;flag normal;flag packets; flag tunnels;}relay { family {inet {local-address ip-address;anycast-prefix ip-prefix/ip-prefix-len;}}secret-key-timeout minutes; tunnel-limit number;}}}

      To configure the IGMP attributes of AMT relay tunnels, include the amt configuration statement at the [edit protocols igmp] hierarchy level.

      igmp { amt {relay {defaults {(accounting | no-accounting);group-policy [ policy-names ];ssm-map ssm-map-name;version version-number;query-interval interval-seconds;query-response-interval interval-seconds;robust-count count;}}}}}

      AMT logical interfaces are created dynamically and have an interface identifier in the format ud-FPC/PIC/port.unit.

      To display tunnel state information for active AMT tunnels, use the show amt tunnel operational mode command.

      To display AMT protocol message counts and error statistics, use the show amt statistics operational mode command.

      To display the multicast source and group addresses for an interface, use the show igmp group terse operational mode command.

      To display gateway IP addresses and UDP port numbers for AMT logical interfaces, use the show interfaces detail operational mode command.

      To display default parameters for active AMT interfaces, use the show igmp interface operational mode command.

      To clear AMT tunnel states, use the clear amt tunnel operational mode command.

      [Multicast, Network Interfaces]

    • Internet Group Management Protocol (IGMP) snooping support for multichassis link aggregation group (MC-LAG) interfaces—Multichassis link aggregation group (MC-LAG) enables a device to form a logical LAG interface with two or more network devices. You can use multicast snooping over MC-LAG interfaces to replicate join and leave messages between MC-LAG peer devices to facilitate faster recovery of membership information after a service interruption.

      Add the multichassis-lag-replicate-state statement at the [edit multicast-snooping-options] hierarchy level to enable snooping for MC-LAG interfaces. This feature supports dual-link MC-LAG interfaces in an active-standby mode, in which only one link is in active mode and the other is in standby mode at any given time.

      In MC-LAG, if a standby link takes over as the active link, it can recover the membership information of the interface from the network by generating an IGMP query. However, this recovery can take between 1 and 10 seconds, which is too long for some applications. To keep service restoration time to a minimum, the active link can use IGMP snooping to replicate membership information to the standby link.

      In the active-standby mode, join and leave messages are sent only through the active member link. Once the messages are received by the active link, they are flooded to all router interfaces, and forwarding entries are built for the received messages. Additionally, the messages are replicated from the active link to the standby link, using an Interchassis Communication Protocol (ICCP) connection. The standby link applies routine processing to the replicated packet, except that it does not add itself as the next hop for any route, and it does not send the replicated packet to the network.

      After a failover, the multicast membership status of the link can be recovered within a few seconds or less by retrieving the replicated messages. This recovery is much faster than the 10–second outage that can occur if the recovery procedure relies only on IGMP queries.

      When this feature is enabled, multicast snooping automatically identifies the active link during initialization and failover, and runs without any administrator intervention.

      If the user deletes the configuration of IGMP snooping or deletes the multichassis-lag-replicate-state statement, this feature is disabled on that MC-LAG link or on the whole IGMP snooping domain. The active device stops replicating IGMP messages to the peer, and the IGMP data already installed on the standby device times out.

      Use the show igmp snooping interface and show igmp snooping membership commands to display group information on both the active side and the standby side of an MC-LAG interface.

      If the ICCP connection is lost, both links of the MC-LAG transition to the active state, and the client device starts load-balancing traffic between the two links. In this situation, the IGMP messages are not replicated.

      [Multicast, Network Interfaces]

    • Internet multicast using ingress replication provider tunnels—A new routing instance type uses existing JUNOS Software technology and ingress replication provider tunnels to carry IP multicast data between routers through an MPLS cloud. This enables a faster path for multicast traffic between sender and receiver routers in large-scale implementations. This configuration is available under PIM and multicast virtual private network (MVPN) infrastructure.

      The topology consists of routers on the edge of the IP multicast domain that have a set of IP interfaces and a set of MPLS core-facing interfaces. Internet multicast traffic is carried between the IP routers using ingress replication provider tunnels (data plane) and a full-mesh IGBP session (control plane) through the MPLS cloud.

      The new mpls-internet-multicast routing instance type is configured for the default master instance on each router to support internet multicast over MPLS. When using PIM as the multicast protocol, the mpls-internet-multicast configuration statement is also included at the [edit protocols pim] hierarchy level in the master instance to associate PIM with the mpls-internet-multicast routing instance.

      The mpls-internet-multicast routing instance is a non-forwarding instance used only for control plane procedures; it does not support any interface configurations. All multicast and unicast routes used for internet multicast are associated only with the master instance (inet.0), not with the routing instance.

      Each router participating in internet multicast must be configured for BGP MPLS-based internet multicast for control plane procedures. Support for an ingress replication provider tunnel is also configured on all routers to form a full mesh of MPLS point-to-point label-switched paths (LSPs) for the data provider tunnel. The technology standard used is BGP/MPLS IP MVPN, sometimes referred to as “next generation.”

      The multicast IP traffic is encapsulated by the routers and carried to other routers over the LSPs formed by the ingress replication provider tunnel. These LSPs can be existing LSPs or triggered dynamically when the routers use autodiscovery. The ingress replication tunnel can be inclusive or selective, depending on the provider tunnel configuration in the routing instance. Additionally, the ingress replication provider tunnel can be configured to create a new tunnel or to use an existing tunnel when an application requests to add a destination.

      [Multicast]

    Multiplay

    • Integrated Multi-Service Gateway (IMSG) access mode support (VoIP subscriber management)—The border signaling gateway (BSG) now provides access mode support, which includes:
      • Recording of subscriber registrations
      • Tracking of subscriber address of record (AOR)

      Access mode support enables the deployment of the BSG in a service provider’s border with large business enterprises, small offices, and home networks. The BSG enables endpoints and IPBXs to register for SIP service with the carrier/service provider’s registrar. Access mode support also enables new transaction policies to filter incoming messages based on their registration state.

      You can now configure additional filtering of incoming messages by entering the uri-hiding and registration-state statements for contacts and request URIs at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name from] hierarchy level.

      Signaling realms are assigned to the messages handled by service points. The default signaling realm for a subscriber’s messages is the ingress service point of their register message, so it is not usually necessary to explicitly define signaling realms. However, you may want to assign signaling realms to accumulate information about messages flowing through different service points used by the same customer. When a customer receives services through multiple service points, information on the overall service provided can be accumulated by assigning the same signaling realm to new transaction policies at each service point.

      You configure signaling realms that can be used in new transaction policies by entering the signaling-realms statement at the [edit services border-signaling-gateway gateway-name sip] hierarchy level. You configure how messages are associated with a signaling realm by entering the signaling-realms statement at the [edit services border-signaling-gateway gateway-name sip new-transaction-policy term term-name] hierarchy level.

      You can display information about subscriber registrations, address of record, and signaling realm assignments by using one of the following commands:

      • show services border-signaling-gateway address-of-record bindings
      • show services border-signaling-gateway registrations

      You can clear registration statistics by using the following commands:

      • clear services border-signaling-gateway registrations statistics
      • show services border-signaling-gateway registrations subscription

      [Multiplay Solutions, Services Interfaces, System Basics and Services Command Reference]

    • Integrated Multi-Service Gateway (IMSG) redirection of messages to contact address—When the border signaling gateway (BSG) receives a 3XX response, it now sends a redirected request using a request URI based on the contact information in the 3XX response. You can specify the maximum number of recursive redirection attempts allowed before sending a 408 timeout response by entering the recursion-limit statement at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name then on-3xx-response] hierarchy level. Requests are not redirected for 380 responses.

      [Multiplay Solutions, Services Interfaces]

    • Integrated Multi-Service Gateway (IMSG) support for up to four border signaling gateways (BSGs) on a router—You can now configure up to four border signaling gateways on a router. Each BSG must be defined on a separate MS-PIC.

      [Session Border Control Solutions]

    • Integrated Multi-Service Gateway (IMSG) border signaling gateway (BSG) server clusters—Server clusters allow routing incoming transactions to one of several possible next-hops, thus providing load balancing and server redundancy. Server clusters are defined in the CLI and can be used as route policy actions.

      You define server clusters by entering the server-cluster statement at the [edit services border-signaling-gateway gateway gateway-name sip routing-destinations] hierarchy level. Each cluster consists of configured servers. In order to configure server clusters, you must first configure individual servers and server availability checking by entering statements at the [edit services border-signaling-gateway gateway gateway-name sip routing-destinations] hierarchy level. After configuring routing-destinations, you can configure routing of transactions to a particular server cluster by entering the server-cluster statement at the [edit services border-signaling-gateway gateway gateway-name sip new-transaction-policy policy-name term term-name then route] hierarchy level.

      You can display call activity by server by entering the show services border-signaling-gateway calls command with the by-server option. If you do not use the by server option, you must use the by-service-point option. You can no longer use the show services border-signaling-gateway calls command without specifying one of these two options.

      You can display unavailable servers by entering the show services border-signaling-gateway routing-blacklist command.

      [Session Border Control Solutions, Services Interfaces, Systems Basics and Services Command Reference]

    • Integrated Multi-Service Gateway (IMSG) support on M7i and M10i routers—M7i and M10i routers now support the IMSG running on an MS-100 PIC.

      [Session Border Control Solutions]

    • Border Gateway Function (BGF) virtual BGF scability—You can now configure up to 32 virtual BGFs on a router. Previously, you could configure a maximum of eight virtual BGFs on a router. Those eight virtual BGFs had to reside on a single MS-PIC. As of JUNOS Release 10.2, eight virtual BGFs can be configured on each of four MS-PICs.

      [Session Border Control Solutions]

    Routing Policy and Firewall Filters

    • Support for MPC firewall filter features (MX Series platforms with Trio MPC/MIC interfaces)—If you configure and apply firewalls to an MX Series router with Trio MPCs/MICs, some match conditions are not supported. Generally, all firewall functions are supported through JUNOS Release 9.2.

      [Layer 2 Configuration]

    • Removal of input-list and output-list statements for firewall filters for the ccc and mpls protocol families applied to loopback, internal Ethernet, and USB modem interfaces—The input-list filter-names and output list filter-names statements for firewall filters for the ccc and mpls protocol families have been removed for these interfaces: management and internal Ethernet interfaces (fxp), loopback interfaces (lo), and USB modem interfaces (umd). Configuration of input lists and output lists for firewall filters for the ccc and mlps protocol families applied to other interfaces are not affected.

      [Policy Framework]

    • Support for the discard action for the tricolor marking policer applied to a firewall filter—The discard action was not previously supported for the tricolor marking policer applied to a firewall filter. With this support for the discard action, the tricolor marking policer no longer needs to include the logical-interface-policer statement at the [edit firewall three-color-policer name] hierarchy level. This change applies only to the following routers: M120, M320 with Enhanced-III FPCSs, MX Series, and M7i and M10i with Enhanced CFEB (CFEB-E).

      [Policy Framework]

    • Support for the match condition prefix-list for firewall filters for the protocol family VPLS—This match condition is already supported for IPv4 and IPv6 protocol families. To enable the prefix-list firewall filters match condition for VPLS, include the prefix-list prefix-list-name match condition at the [edit firewall family vpls filter filter-name term term-name from] hierarchy level.

      [Policy Framework]

    • Option to enable enhanced jtree memory allocation for Layer 3 VPNs (T640 and T1600 routers with Enhanced Scaling FPC3 and Enhanced Scaling FPC4)—To utilize memory across segments, JUNOS Release 10.2 extends support for allocating jtree memory for Layer 3 VPNs in different segments. To enable jtree memory allocation, use the route-memory-enhanced statement at the [edit chassis] hierarchy level, and reboot all affected FPCs to activate the configuration. To verify the configuration, use the show pfe fpc slot detail command.

      Note: For T Series routers only. With JUNOS Release 10.2, enhanced jtree memory allocation is turned OFF by default. To enable jtree memory allocation, use the route-memory-enhanced statement at the [edit chassis] hierarchy level, and reboot all affected FPCs to activate the configuration. For JUNOS Release 9.3 to 10.1, the default routing tables (inet.0 and inet6.0) use both memory segments by default.

      [System Basics]

    • Layer 2 Gigabit Ethernet logical interface policing support extended to MX Series routers—Enables you to configure the following policer types on the input and output interfaces:
      • Single-rate two color
      • Two-rate color-blind three color
      • Two-rate color-aware three color
      • Single-rate color-blind three color
      • Single-rate color-aware three color

      To configure, create the policer at the [edit firewall] hierarchy level. In addition to the policer condition and action, you must include the logical-interface-policer statement. To apply the policer to the input or output interface, include the layer2-policer statement at the [edit interface ge-fpc/pic/port unit logical-unit-number] hierarchy level.

      [Network Interfaces, Class of Service, Policy]

    Routing Protocols

    • Only the system log notes failure to add routes to the Trio MPC/MIC (MX Series platforms)—For Layer 3 and MPLS features, the Trio MPC/MIC is compatible with JUNOS Release 9.2. However, the syslog process is the only mechanism that records failure to add routes to the MPC.

      [Routing Protocols]

    • Keepalive support for GRE interfaces (ichip based M Series and MX Series)—Enables GRE tunnel interfaces to detect when a tunnel interface is down. This feature is needed in static routing environments in which the keepalive mechanism in a dynamic routing protocol cannot be relied upon to detect a link down condition. To configure keepalives on GRE tunnel interface, include both the keepalive-time statement and the hold-time statement at the [edit protocols oam gre-tunnel interface interface-name] hierarchy level.

      Note: For proper operation of keepalives on a GRE interface, you must also include the family inet statement at the [edit interfaces interface-name unit unit] hierarchy level. If you do not include this statement, the interface is marked as down.

      [Services Interfaces, Interfaces Command Reference]

    • Support for OSPF database protection for OSPF and OSPFv3—Enables you to limit the number of link-state advertisements (LSAs) not generated by the router in a given OSPF instance. This feature is particularly useful for networks configured with VPN routing and forwarding on provider edge and customer edge routers using the OSPF routing protocol. By limiting LSAs not generated by the router, the link-state database in your network is protected from being overrun by excessive LSAs from sources other than your router. To enable database protection, include the database-protection statement at the [edit protocols (ospf | ospf3)] hierarchy level. This feature also supports routing instances, logical systems, and OSPFv3 realms. Besides configuring the maximum number of LSAs not from the router, you can specify parameters to determine how your network will respond when certain conditions are met. These parameters include a warning threshold for issuing warning messages, an ignore count to limit the number of times the database can enter the ignore state before it goes into the isolate state, and a reset time for resuming normal operations if the database has avoided being in the ignore or isolate state for the specified period of time. However, once the link-state database enters the isolate state, a command to reset the database must be issued before normal operations can be resumed. In support of this feature, the clear ospf database-protection command has been added, and the output for the show ospf overview command has been enhanced to show the current database protection status.

      [Routing Protocols]

    • Revert time for redundant Layer 2 pseudowires—You can now modify the behavior for redundant Layer 2 circuit and VPLS pseudowires by configuring a revert time. When a primary pseudowire fails and traffic is switched to an alternate pseudowire, the revert time specifies how long the router should wait before attempting to switch the traffic back to the primary pseudowire. The router does not attempt to switch traffic back to the primary pseudowire if the primary pseudowires has not been restored. To configure a revert time for redundant Layer 2 pseudowires, specify a time, in seconds, using the revert-time statement at the [edit protocols l2circuit neighbor address interface interface-name] hierarchy level for Layer 2 circuit configurations, and at the [edit routing-instances routing-instance-name protocols vpls neighbor address] hierarchy level for VPLS configurations.

      [VPNs]

    • Support for having the algorithm that determines that the single best path skip the step that evaluates an AS path—By default, the third step of the algorithm that determines the active route evaluates the length of an AS path. To enable the JUNOS Software to skip this step, include the as-path-ignore statement at the [edit protocols bgp path-selection] hierarchy level. You cannot configure this statement for a specific routing instance.

      [Routing Protocols]

    Services Applications

    • Inline flow monitoring support (MX240, MX480, and MX960 only)—Adds the capability to support flow monitoring and sampling services inline in the data path, without the need for a services PIC, on MX Series Modular Port Concentrators (MPCs).

      To configure inline flow monitoring, include the inline-jflow statement at the [edit forwarding-options sampling instance instance-name family inet output] hierarchy level. Inline sampling exclusively supports a new format called version-ipfix that uses UDP as the transport protocol. When you configure inline sampling, you must include the version-ipfix statement at the [edit forwarding-options sampling instance instance-name family inet output flow-server address] hierarchy level and also at the [edit services flow-monitoring] hierarchy level. The following operational commands include new inline fpc keywords to display inline configuration information: show services accounting errors, show services accounting flow, and show services accounting status.

      [Services Interfaces, System Basics and Services Command Reference]

    • AACL statistics for dynamic packet-triggered subscribers—Provide support for packet-triggered subscribers and policy control (PTSP) statistics collection in a flat file using the local policy decision function (L-PDF). If you specify in the rule that statistics collection and reporting are based on application or application group for each subscriber, then this flat file method is used.

      To specify that PTSP statistics are reported, include the flag pstp-statistics statement at the [edit system services local-policy-decision-function traceoptions] hierarchy level. To configure the AACL statistics profile to support PTSP statistics collection, include the record-mode interim-active-only statement at the [edit system services local-policy-decision-function aacl-statistics-profile profile-name] hierarchy level and include all-fields at the [edit system services local-policy-decision-function aacl-statistics-profile profile-name aacl-fields] hierarchy level. The following operational commands display information about the packet-triggered subscribers: show services subscriber bandwidth, show services subscriber dynamic-policies, show services subscriber flows, show services subscriber sessions, and show services subscriber statistics.

      [Services Interfaces, System Basics and Services Command Reference, Subscriber Access]

    Subscriber Access Management

    • Support for subscriber management features on Trio MPC/MIC interfaces (MX Series routers)—Enables support for all subscriber management features introduced in JUNOS Release 10.1 and lower-numbered releases on Trio MPC/MIC interfaces available on MX Series routers.

      For a list of the subscriber management features and other protocols and applications supported on the MX Series MPCs, see Protocols and Applications Supported by MX Series MPCs in the MX Series 3D Universal Edge Routers Line Card Guide.

      [Subscriber Access, MX Series Line Card ]

    • Subscriber secure policy traffic mirroring on Trio MPC/MIC interfaces on MX Series routers—Enables you to configure subscriber secure policy traffic mirroring to provide RADIUS-initiated mirroring for subscribers on interfaces that are running over Trio MPC/MIC interfaces on MX Series routers.

      [Subscriber Access]

    • Support for frame and cell-shaping mode and byte adjustments on static and dynamic subscriber interfaces (MX Series routers)—Enables you to configure frame-based and cell-based shaping mode and byte adjustments on static or dynamic subscriber interfaces in a broadband access network. This feature is supported on Trio MPC/MIC interfaces on MX Series routers.

      In a broadband access network, ATM traffic can be passed downstream from other customer premise equipment (CPE) to the MX Series router. Managing the bandwidth of downstream ATM traffic to Ethernet interfaces can be difficult because of the different Layer 2 encapsulations.

      You can configure the shaping mode to shape downstream ATM traffic based on either frames or cells. In frame shaping mode, shaping is based on the number of bytes in the frame, without regard to cell encapsulation or padding overhead. Frame is the default shaping mode on the router.

      In cell shaping mode, shaping is based on the number of bytes in cells and accounts for the ATM cell encapsulation and padding overhead. When you specify cell shaping, the resulting traffic stream conforms exactly to the policing rates configured in downstream ATM switches, reducing the number of packet drops in the Ethernet network.

      In addition, you can account for the different byte sizes per encapsulation by configuring a byte adjustment value for the shaping mode. For example, you can configure frame shaping mode and a byte adjustment value to account for differences in Layer 2 protocols for downstream Ethernet traffic.

      To configure the shaping mode, include the new overhead-accounting (frame-mode | cell-mode) statement at the [edit class-of-service traffic-control-profiles profile-name] hierarchy level or the [edit dynamic-profiles class-of-service traffic-control-profiles profile-name] hierarchy level.

      To configure byte adjustments, include the bytes byte-value option with the overhead-accounting (frame-mode | cell-mode) statement. We recommend that you configure the byte-value that represents the difference between the CPE protocol overhead and the BRAS protocol overhead. The configurable range is -120 to 124 bytes.

      [Subscriber Access, Class of Service]

    • Support for dynamic distribution of excess bandwidth among different subscriber services on subscriber interfaces (MX Series routers with Trio MPC/MIC interfaces)—Enables you to control the distribution of excess bandwidth sharing on dynamic subscriber interfaces on Trio MPC/MIC interfaces available on MX Series routers. In earlier releases, excess bandwidth sharing was supported on EQ DPCs only.

      Service providers often used tiered services that must utilize excess bandwidth as traffic patterns vary. By default, excess bandwidth between a configured guaranteed rate and shaping rate is shared equally among all queues with the same excess priority value, which might not be optimal for all subscribers to a service.

      To configure the excess rate for a traffic control profile in a dynamic profile, include the excess-rate statement at the [edit dynamic-profiles profile-name class-of-service traffic-control-profiles profile-name] hierarchy level and apply the traffic control profile at the [edit dynamic-profiles profile-name class-of-service interfaces interface-name] hierarchy level. To configure the excess rate for a queue, include the excess-rate and excess-priority statements at the [edit dynamic-profiles profile-name class-of-service scheduler scheduler-name] hierarchy level.

      [Subscriber Access]

    • Support for MAC address validation on Trio MPC/MIC interfaces on MX Series routers—Enables MAC (source address) validation to use filters over Trio MPC/MIC interfaces on MX Series routers. MAC validation is the process of verifying that the origin of the MAC address received matches the origin present in the router ARP entry table. You can enable MAC validation in either strict or loose mode on static or dynamic demux interfaces using dynamic profiles.

      [Subscriber Access]

    • Support for IP demux subscriber secure policy and MAC validate configuration on Trio MPC/MIC interfaces—Enables the configuration of subscriber secure policy and MAC validation using dynamic IP demux interfaces over Trio MPC/MIC physical interfaces on MX Series routers.

      [Subscriber Access]

    • Support for dynamic 802.1Q VLAN interface configuration for PPPoE over Trio MPC/MIC interfaces on MX Series routers—Enables you to configure dynamic 802.1Q VLANs for PPPoE on Trio MPC/MIC interfaces on MX Series routers. This support includes an enhancement to the accept statement to include a new pppoe VLAN Ethernet packet type. You can specify this packet type at the [edit interfaces interface-name auto-configure vlan-ranges dynamic-profile profile-name] and the [edit interfaces interface-name auto-configure stacked-vlan-ranges dynamic-profile profile-name] hierarchy levels. The pppoe VLAN Ethernet packet type option is supported only for Trio MPC/MIC interfaces on MX Series routers.

      [Subscriber Access]

    • Support for IPv6 demux configuration on Trio MPC/MIC interfaces on MX Series routers—Enables dynamic IPv6 demux configuration on Trio MPC/MIC interfaces on MX Series routers.

      [Subscriber Access]

    • Support for dynamic CoS for IP demux interfaces on Trio MPC/MIC interfaces (MX Series routers)—Enables you to configure dynamic CoS for a static or dynamic IP demultiplexing (demux) subscriber interface on the Trio MPC/MIC interfaces available on MX Series routers. In earlier releases, dynamic CoS for IP demux interfaces was supported on EQ DPCs only.

      Hierarchical CoS for aggregated Ethernet interfaces is now supported on the Trio MPC/MIC family when a static or dynamic demux subscriber interface is the underlying interface. In earlier releases, hierarchical CoS for aggregated Ethernet was only supported on the Trio MPC/MIC family when a static or dynamic VLAN was the underlying interface.

      [Subscriber Access]

    • Support for non-hierarchical dynamic CoS configurations on subscriber interfaces (MX Series routers)—Enables you to dynamically configure per-unit scheduling for subscriber interfaces configured on EQ DPCs and Trio MPC/MIC interfaces on MX Series routers and Ethernet Enhanced IQ2 (IQ2E) PICs on M120 and M320 routers.

      In earlier releases, you had to enable hierarchical scheduling prior to configuring a dynamic access or service profile with CoS parameters. In per-unit scheduling configurations, each Layer 3 scheduler node is allocated a dedicated set of queues. If you do not explicitly configure CoS parameters, a default traffic profile with queues is attached to the logical interface. Interfaces are not dynamically created with a new set of queues when the existing queue limit is reached.

      To enable per-unit scheduling for the subscriber interface, include the per-unit-scheduler statement at the [edit interfaces interface-name] hierarchy level. You can then configure dynamic CoS parameters at the [edit dynamic-profiles profile-name class-of-service] hierarchy level and the remaining static parameters at the [edit class-of-service] hierarchy level.

      [Subscriber Access]

    • PPPoE service name table enhancements (M120, M320, and MX Series routers)—Support the following new and enhanced features for PPPoE service name tables:
      • Configuration of any service.

        The any service acts as a default service for non-empty service entries that do not match the empty or named service entries configured in the PPPoE service name table on the router. The any service is useful when you want to match the agent circuit ID and agent remote ID information for a PPPoE client, but do not care about the service name tag that is transmitted in the control packet.

        To configure the any service, include the service any statement at the [edit protocols pppoe service-name-table table-name] hierarchy level.

      • Association of agent circuit identifier/agent remote identifier (ACI/ARI) pairs with empty or any service.

        Associating an ACI/ARI pair with an empty or any service enables you to identify the DSLAM interface that initiated the service request (agent circuit ID string) and the subscriber on the DSLAM interface that initiated the service request (remote ID string). In lower-numbered releases, you could not associate ACI/ARI pairs with the empty service.

        To configure an ACI/ARI pair for an empty or any service, include the agent-specifier statement at the [edit protocols pppoe service-name-table table-name service ( empty | any )] hierarchy level.

      • Association of a PPPoE dynamic profile with a named service, empty service, any service, or ACI/ARI pair.

        You can associate a previously configured PPPoE dynamic profile with a named, empty, or any service entry in the PPPoE service name table, or with an ACI/ARI pair defined for these services. The router uses the attributes defined in the profile to instantiate a dynamic PPPoE interface to handle the PPPoE session. The dynamic profile associated with the PPPoE service name table entry overrides the dynamic profile assigned to the underlying Ethernet interface.

        To associate a dynamic profile with a named, empty, or any service, include the dynamic-profile statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level.

        To associate a dynamic profile with an ACI/ARI pair, include the dynamic-profile statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any ) agent-specifier aci circuit-id-string ari remote-id-string] hierarchy level.

      • Association of routing instance with named service, empty service, any service, or ACI/ARI pair.

        To specify the routing instance in which the router should create the dynamic PPPoE interface, you can associate a previously configured routing instance with a named, empty, or any service entry in the PPPoE service name table, or with an ACI/ARI pair defined for these services. The routing instance associated with the PPPoE service name table entry overrides the routing instance associated with the underlying Ethernet interface.

        To associate a routing instance with a named, empty, or any service, include the routing-instance statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level.

        To associate a routing instance with an ACI/ARI pair, include the routing-instance statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any ) agent-specifier aci circuit-id-string ari remote-id-string] hierarchy level.

      • Association of static PPPoE interface with ACI/ARI pair.

        You can associate a previously configured static PPPoE interface with an ACI/ARI pair defined for a named, empty, or any service entry configured in the PPPoE service name table. The router reserves the specified static interface for use only with the matching service name table entry.

        To associate a static PPPoE interface with an ACI/ARI pair, include the static-interface statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any ) agent-specifier aci circuit-id-string ari remote-id-string] hierarchy level.

      • Configurable maximum sessions limit for named service, empty service, or any service.

        You can configure the maximum number of active PPPoE sessions using either dynamic or static PPPoE interfaces that the router can establish with the specified service name table entry, in the range from 1 through the platform-specific maximum for your router. The default value is equal to the maximum number of PPPoE sessions supported on your router. The maximum sessions value associated with the PPPoE service name table entry is used in conjunction with the maximum sessions value configured for the underlying Ethernet interface.

        To configure the maximum sessions limit for a named, empty, or any service, include the max-sessions statement at the [edit protocols pppoe service-name-table table-name service ( service-name | empty | any )] hierarchy level.

      • Option to globally advertise named services in PPPoE Active Discovery Offer (PADO) control packets.

        By default, advertisement of named services in PADO control packets sent by the router is disabled. You can enable advertisement of named services in the PADO packet when you define the PPPoE protocol. If you do so, make sure the number and length of the named service entries advertised in the PADO packet do not exceed the MTU size of the underlying Ethernet interface.

        To enable advertisement of named services in PADO control packets sent by the router, include the pado-advertise statement at the [edit protocols pppoe] hierarchy level.

      • Increased system maximums for PPPoE service name tables, named service entries, and ACI/ARI pairs.

        You can now configure a maximum of 32 PPPoE service name tables per M120, M320, or MX Series router; a maximum of 512 named service entries (excluding empty and any service entries) per PPPoE service name table; and a maximum of 8000 ACI/ARI pairs per PPPoE service name table.

      To verify the PPPoE service name table configuration, use the following new and updated operational commands:

      • To display information about all active PPPoE sessions and optionally filter the output by service name, agent circuit ID string, or remote ID string, issue the new show pppoe sessions command.
      • To display configuration information for a PPPoE service name table, issue the show pppoe service-name-tables command. This command has been updated to include information about the any service, maximum sessions, and active sessions. This command also displays information about the dynamic profile, routing instance, and static interface attributes, if configured.
      • To display session-specific information about PPPoE interfaces, issue the show pppoe interfaces command. This command has been updated to include the service name, agent circuit ID string, and agent remote ID string used to establish the active PPPoE session on the interface.

      [Network Interfaces, Interfaces Command Reference, Subscriber Access]

    • Maximum queues for static and dynamic subscriber interfaces on Trio MPC modules (MX240, MX480, and MX960 routers)—Enable you to scale to a maximum number of dedicated queues for static and dynamic subscriber interfaces configured on certain Trio MPC modules.

      The following table lists the number of dedicated queues per module.

      MPC Name

      Number of Dedicated Queues

      20–Gigabit Ethernet Queuing MPC

      64,000 egress

      40–Gigabit Ethernet Queuing MPC

      128,000 egress

      40–Gigabit Ethernet Enhanced Queuing MPC

      512,000 egress

      These values are supported for static CoS configurations configured at the [edit class-of-service] hierarchy level and dynamic CoS configurations configured at the [edit dynamic profiles profile-name class-of-service] hierarchy level. Hierarchical scheduling must be enabled on the interface, and per-unit scheduling is not supported.

      When the maximum number of queues on the module is reached, a new system log message, COSD_OUT_OF_DEDICATED_QUEUES, is generated. All subsequent subscriber interfaces are not provided a dedicated set of queues. In hierarchical scheduling configurations, traffic from these logical interfaces is considered unclassified and attached to a common set of queues that are shared by all subsequent logical interfaces. These common queues are the default port queues that are created for every port. You can configure common queues for the physical interface by including the output-traffic-control-profile-remaining statement at the [edit class-of-service interfaces] hierarchy level.

      The output of the show class-of-service interface interface-name operational command has been extended to display the traffic profile that is attached to the specified logical interface. In addition, the output displays the number of queues that have been consumed by the logical interfaces configured over a specific physical interface.

      [Class of Service, Subscriber Access]

    • Dynamic profile and enhanced RADIUS support for MLPPP subscriber services (M120 and M320 routers)—RADIUS can now dynamically assign IPv4 addresses for MLPPP connections. The same address is allocated to all links in a bundle. AAA disconnects any link that is allocated an address different than the address previously allocated to member links in the bundle. The IP address is released for reallocation when the last member link in a bundle logs out.

      The Acct-Multi-Session-Id attribute enables RADIUS to link multiple related sessions into a single log file. RADIUS uses the session database (SDB) bundle session ID for the value of Acct-Multi-Session-Id. This bundle ID enables RADIUS to initiate a disconnect for an entire bundle. By tracking the member link sessions, RADIUS is also able to disconnect the individual member links in a bundle.

      The Acct-Link-Count [51] attribute records the number of links present in a multilink session at the time the accounting record is generated.

      Include the dynamic-profiles profile-name statement at the [edit] hierarchy level to define a dynamic profile that specifies attributes to be applied dynamically to MLPPP bundle interfaces.

      The dynamic-profile profile-name statement at the [edit interfaces interface-name unit logical-unit-number ppp-options] hierarchy level now supports certain LSQ interfaces. Include this statement to assign the dynamic profile to the LSQ MLPPP bundle interface.

      These MLPPP subscriber access features are supported only on the Channelized DS3/E3 Enhanced IP PIC (PB-4CHDS3-E3-IQE-BNC) on M120 and M320 routers. The MLPPP subscriber services are available only on LSQ interfaces configured on Adaptive Services PICs or Multiservices PICs.

      [Subscriber Access]

    • Address-assignment pool linking (MX Series routers)—Subscriber management enables you to link an address-assignment pool to a second pool. Linking enables you to provide a backup address pool in the event that all addresses in the primary address-assignment pool are allocated. The router automatically begins allocating addresses from the secondary (linked) address-assignment pool when the primary pool is fully allocated.

      Both IPv4 and IPv6 address-assignment pools support linking. However, the secondary pool must be the same family type as the primary pool. You cannot link an IPv4 address-assignment pool to an IPv6 pool, or vice versa.

      You use the link statement at the [edit access address-assignment pool pool-name] hierarchy level to specify the secondary address-assignment pool.

      You use the show network-access aaa statistics address-assignment pool command to display information about an address-assignment pool, such as the percentage of the pool that has been allocated.

      [Subscriber Access]

    • Distinguishing DHCP duplicate clients by subinterface (MX Series routers)—You can now optionally configure DHCP to include the client subinterface when distinguishing between duplicate DHCP clients (clients with the same MAC or client ID) in the same subnet.

      By default, DHCP distinguishes clients by subnet. However, when multiple subinterfaces share the same underlying loopback interface with the same preferred source address, the subinterfaces appear to be on the same subnet, and DHCP is unable to differentiate between duplicate clients. The optional configuration enables DHCP to use the client subinterface to differentiate between the duplicate clients within the subnet.

      Distinguishing DHCP clients by subinterface is supported on DHCPv4 only, and is supported per logical system routing instance.

      • To enable duplicate client subinterface support for DHCP local server, include the duplicate-clients-on-interface statement at the [edit system services dhcp-local-server] hierarchy level.
      • To enable duplicate client subinterface support for DHCP relay agent, include the duplicate-clients-on-interface statement at the [edit forwarding-options dhcp-relay] hierarchy level. Also, DHCP relay must be configured to insert option 82 Agent Circuit ID with the interface name, and the DHCP local server must echo this option 82 in its reply.

      [Subscriber Access]

    • Sending a DHCP relay and relay proxy release message (MX Series routers)—You can configure DHCP relay and relay proxy to generate and send a release message to the DHCP server whenever DHCP relay or relay proxy delete a client. This release message sent by DHCP relay and relay proxy includes option 82 information. By default, no release message is sent.

      To configure DHCP relay and relay proxy to send a release message, include the send-release-on-delete statement at the following hierarchy levels:

      • Global configuration—[edit forwarding-options dhcp-relay overrides]
      • Named group configuration—[edit forwarding-options dhcp-relay group group-name overrides]
      • Per interface configuration—[edit forwarding-options dhcp-relay group group-name interface interface-name overrides]

        Note: In earlier releases, if the client-discover-match statement was configured, DHCP relay sent a release message to the DHCP server when a client was deleted. This is no longer the case. To configure DHCP to send the release message, you must configure the send-release-on-delete statement.

      [Subscriber Access]

    • SNMP trap support for subscriber secure policy (MX Series routers)—Subscriber secure policy supports the use of SNMPv3 traps to capture and report packet mirroring information to an external mediation device. The traps map to messages defined in the Lawfully Authorized Electronic Surveillance (LAES) for IP Network Access, American National Standard for Telecommunications.

      You use standard configuration methods, as described in the JUNOS Network Management Configuration Guide, to configure the mediation device to receive the SNMPv3 trap information. Your configuration must include the authentication and privacy keys.

      The SNMPv3 traps, which are provided in the Juniper Packet Mirroring MIB, jnx-js-packet mirror.mib, are described in the following table:

      Table 2: SNMP Traps for Subscriber Secure Policy

      Trap

      Description

      jnxPacketMirrorLiSubscriberLoggedIn

      Subscriber, who is identified to have a mirrored service that is activated at login, has successfully logged in.

      jnxPacketMirrorSessionLiSubscriberLogInFailed

      Subscriber, who is identified to have a mirrored service that is activated at login, has failed to log in.

      jnxPacketMirrorInterfaceLiSubscriberLoggedOut

      Subscriber, who had an active mirrored service, has logged out.

      jnxPacketMirrorInterfaceLiServiceActivated

      Mirrored session has been activated.

      jnxPacketMirrorSessionLiServiceActivationFailed

      Mirrored session for a subscriber has failed.

      jnxPacketMirrorSessionLiServiceDeactivated

      Mirrored session for an established subscriber has been deactivated.

      jnxPacketMirrorMirroringFailure

      Mirrored service request failed due to an invalid value in the request.

      Note: This trap is not related to LAES messages.

      [Subscriber Access]

    • DTCP support for subscriber secure policy (MX Series routers)—DTCP now supports subscriber secure policy, and you no longer need to configure the flow-tap service. You use the radius-flow-tap statement to configure subscriber secure policy directly on DTCP.

      In previous releases, subscriber secure policy ran on top of the flow-tap service infrastructure. This required that you configure the flow-tap service before configuring subscriber secure policy support.

      To configure subscriber secure policy on DTCP:

      1. Configure the DTCP-over-SSH service—Include the flow-tap-dtcp ssh statement at the [edit system services] hierarchy level.
      2. Allocate the tunnel interfaces that the DTCP service can use for subscriber secure policy mirroring—Include the fpc slot-number pic number tunnel-services bandwidth statement at the [edit chassis] hierarchy level.
      3. Configure the tunnel interfaces—Include the interface-name unit number family inet statement at the [edit interfaces] hierarchy level.
      4. Assign the tunnel interface that DTCP uses for subscriber secure policy mirroring—Include the radius-flow-tap interfaces interface-name statement at the [edit services] hierarchy level.
      5. Specify the source IP address that DTCP uses for mirroring—Include the radius-flow-tap source-ipv4-address ipv4–address statement at the [edit services] hierarchy level.

      [Subscriber Access]

    • Support for new RADIUS parameters to dynamically distribute excess bandwidth on subscriber interfaces (MX Series routers)—Enables you to configure predefined variables for controlling excess bandwidth on subscriber interfaces. The RADIUS server supplies values for these variables to the router when subscribers log in.

      The Juniper Networks VSA for CoS scheduling and queuing parameter values (attribute 26–146) has been updated to include three new predefined variables for the excess-rate, shaping-rate, and excess-priority parameters. To configure the predefined variables, include the excess-rate percent $junos-cos-scheduler-excess-rate statement, the shaping-rate percent $junos-cos-scheduler-shaping-rate statement, or the excess-priority $junos-cos-excess-priority statement at the [edit dynamic-profiles profile-name class-of-service scheduler scheduler-name] hierarchy level.

      The Juniper Networks VSA for CoS traffic shaping parameter values (attribute 26–108) has been updated to include one new predefined variable attribute for the excess rate parameter. To configure the predefined variable, include the excess-rate percent $junos-cos-excess-rate statement at the [edit dynamic-profiles profile-name class-of-service scheduler scheduler-name] hierarchy level.

      [Subscriber Access]

    • Overriding DHCP settings on specific interfaces (MX Series routers)—You can now override DHCP local server, DHCPv6 local server, and DHCP relay configuration options for a specific interface or for a range of interfaces. The interface or range of interfaces must be configured in a DHCP group. Previously, you could override DHCP options globally or for a specific named group. An override configuration for a specific interface or range of interfaces takes precedence over a group or global override configuration.

      To override DHCP options for an interface or range of interfaces, include the overrides statement at the following hierarchies. The configuration is also supported at the [edit logical-systems], [edit logical-systems logical-system-name routing-instance], and [edit routing-instance] hierarchy levels.

      • For a DHCP local server—[edit system services dhcp-local-server group group-name interface]
      • For a DHCPv6 local server—[edit system services dhcp-local-server dhcpv6 group group-name interface]
      • For a DHCP relay agent—[forwarding-options dhcp-relay group group-name interface]

      [Subscriber Access]

    • Support for demux VLAN interface configuration on Ethernet and aggregated Ethernet Trio MPC/MIC interfaces—Enables the static or dynamic creation of demux VLAN interfaces with an underlying interface of aggregated Ethernet or Gigabit/10–Gigabit Ethernet. You can configure either single-tag or stacked demux VLAN interfaces.

      When configuring single-tagged, static VLAN demux interfaces, specify a VLAN ID for the vlan-id statement at the [edit interfaces demux0 unit unit-number] hierarchy level. When configuring stacked (dual-tagged), static VLAN demux interfaces, specify an inner and outer tag at the [edit interfaces demux0 unit unit-number vlan-tags] hierarchy level. For both single-tagged and stacked VLAN interfaces, you must also specify the underlying device name for the underlying-interface statement at the [edit interfaces demux0 unit unit-number demux-options] hierarchy level.

      When configuring single-tagged, dynamic VLAN demux interfaces, specify the VLAN ID variable ($junos-vlan-id) for the vlan-id statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number] hierarchy level. When configuring stacked (dual-tagged), dynamic VLAN demux interfaces, specify an inner and outer tag at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number vlan-tags] hierarchy level. For both single-tagged and stacked VLAN interfaces, you must also specify the underlying device name variable ($junos-interface-ifd-name) for the underlying-interface statement at the [edit dynamic-profiles profile-name interfaces demux0 unit unit-number demux-options] hierarchy level.

      Note: IP demux over VLAN, demux stacking is not supported.

      [Subscriber Access]

    • Specifying the DHCP source address used for IP packets (MX Series routers)—By default, when communicating with clients, DHCP uses the IP address of the interface as the source address that is included in IP packets. You can now explicitly specify the source address by configuring the server identifier in the DHCP address-assignment pool. The address you specify is also used in DHCP option 54, and is included in DHCP forcerenew, DHCP offer, DHCP ACK, and DHCP NAK messages.

      To specify the source IP address for DHCP local server, configure the server identifier as a DHCP attribute for the DHCP address-assignment pool. Include the server-identifier statement at the [edit access address-assignment pool pool-name family inet dhcp-attributes] hierarchy level. This feature is supported for the IPv4 DHCP local server only.

      [Subscriber Access]

    • Diameter base protocol support for packet-triggered subscribers and policy control (PTSP) (MX Series routers)—The Diameter base protocol provides basic services to one or more applications (also called functions) that each runs in a different Diameter instance. The individual application provides the extended functionality. To support PTSP, a new application is added. To configure the PTSP application, you must include the function packet-triggered-subscribers statement at the [edit diameter network-element element-name forwarding route dne-route-name] hierarchy level.

      You can use the PTSP application to interact with the Juniper Networks Session and Resource Control (SRC) software to support dynamic packet-triggered subscribers. The SRC software runs on a Juniper Networks C Series Controller and provides a central administrative point for managing subscribers and their services. The SRC software uses the Diameter protocol for communications between the PTSP application acting as the local peer on an MX Series router and the remote SRC peer (the service activation engine or SAE) on a C Series Controller. The PTSP application is a Juniper Networks-specific Diameter application registered with the IANA as Juniper JGx, with an ID of 16777273. PTSP and the SAE exchange Diameter protocol messages that include a variety of attribute-value pairs (AVPs) to convey state information and identify actions requested or performed. Both standard Diameter AVPs and Juniper Networks vendor-specific AVPs (ID 2636) are employed.

      [Subscriber Access]

    • PTSP supports dynamic and static policy rules (MX Series routers)—You can use the packet-triggered subscribers and policy control (PTSP) application to interact with the Juniper Networks Session and Resource Control (SRC) software to apply dynamic policy rules to packet-triggered subscribers.

      To enable the SRC peer to download PTSP policies to the MX Series router using Diameter and apply the dynamic PTSP rules to the packet-triggered subscribers, create and assign a PTSP partition. To create the PTSP partition, include the partition statement at the [edit system services packet-triggered-subscribers] hierarchy level. To configure the partition, include the diameter-instance, destination-host, and destination-realm statements at the [edit system services packet-triggered-subscribers partition partition-name] hierarchy level. To assign the PTSP partition, include the packet-triggered-subscribers-partition statement at the [edit system] hierarchy level.

      You can also create static PTSP rules to apply policies to distinct source IP addresses flowing through a given interface. To configure static PTSP rules, include the service-set and ptsp statements at the [edit services] hierarchy level. Dynamic PTSP policies take precedence over static PTSP policies.

      If you specify in the rule that statistics collection and reporting are based on the rule for each subscriber, then Diameter is used to report the statistics. If you specify in the rule that statistics collection and reporting are based on application or application group for each subscriber, then the flat file method is used to report the statistics. The flat file method requires you to configure AACL statistics for packet-triggered subscribers. All rules in a given service set must specify the same type of statistics collection and reporting; you cannot mix and match types. The following operational commands display information about the packet-triggered subscribers: show services subscriber bandwidth, show services subscriber dynamic-policies, show services subscriber flows, show services subscriber sessions, and show services subscriber statistics. You can use the clear services subscriber session client-id client-id command to request subscriber logout.

      [Subscriber Access, System Basics and Services Command Reference]

    • PTSP support for application identification services (MX Series routers)—You can use packet-triggered subscribers and policy control (PTSP) with the application identification (APPID) services. To configure match conditions that support application identification, include the application or application-group statements at the [edit services ptsp rule rule-name term precedence from] hierarchy level. We recommend that you avoid using these match conditions with the forwarding-instance action at the [edit services ptsp forward-rule forward-rule-name term precedence then] hierarchy level because your network topology might lead to unexpected behavior.

      [Subscriber Access]

    • Support for show subscribers command enhancements—Provides the following enhancements to the show subscribers CLI command:

      • Changes to the count option, enabling the option to function with search filters to provide total/active subscribers that match the filter criteria (address, interface, logical-system, and so on).
      • Added client-type, mac-address, and subscriber-state search filter options.
      • A terse display change that changes the “IP Address” column to “IP Address/VLAN ID” where the client IP address is shown for DHCP subscriber sessions and the VLAN ID is shown for dynamic-vlan (auto-sensed VLAN) sessions.
      • An added terse display “LS:RI” column to show the logical system and routing instance of the subscriber.
      • Detail display modifications to include any service sessions associated with the subscriber.
      • Detail display enhancements to support IPv6 address and prefix fields.
      • An added extensive display option to provide more information for each subscriber than the detail display. The additional information includes service session and filter data.
      • A new summary display that provides subscriber summaries by session state, client type, LS:RI, or all of these.
      [System Basics and Services Command Reference]
    • JUNOS subscriber access scaling values (M120, M320, and MX Series routers)—A spreadsheet is available online that lists the DCHP, PPP, and PPPoE scaling values supported for JUNOS subscriber management beginning with JUNOS Release 10.1. Access the spreadsheet from the Downloads box at https://www.juniper.net/techpubs/en_US/junos10.2/information-products/pathway-pages/
      subscriber-access/index.html.

    VPNs

    • VRF table label support added for Enhanced Intelligent Queuing (IQE) Type-1 PICs on M320 routers with E3 FPCs—Provides an alternative for Layer 3 VPN applications to perform egress IP filtering at the egress PE router, or for the case when the CE is a Layer 2 switch with no IP capabilities, without the need of a tunnel PIC to loopback the packet.

      This enhancement adds VRF table label support for the following IQE Type-1 PICs:

      • PB-1OC12-STM4-IQE-SFP
      • PB-4OC3-STM1-IQE-SFP
      • PB-4DS3-E3-IQE-BNC
      • PB-2CHOC3-STM1-IQE-SFP with no partition to a SONET interface
      • PB-1CHOC12-STM4-IQE-SFP with no partition to a SONET interface

      To configure VRF table label support on the listed IQE Type-1 PICs, use the vrf-table-label statement at either the [edit logical-systems logical-system-name routing-instances routing-instance-name] or the [edit routing-instances routing-instance-name] hierarchy level.

      [VPNs, Network Interfaces, Interfaces Command Reference]

    • Static VPLS—You can now configure a VPLS domain using static pseduowires. A VPLS domain consists of a set of PE routers that act as a single virtual Ethernet bridge for the customer sites connected to these routers. By configuring static pseudowires for the VPLS domain, you do not need to configure the LDP or BGP protocols that would normally be used for signaling. Static pseudowires require that you configure a set of in and out labels for each pseudowire configured for the VPLS domain. You still need to configure a VPLS identifier and neighbor identifiers for a static VPLS domain. You can configure both static and dynamic neighbors within the same VPLS routing instance.

      To configure a static pseudowire for a VPLS neighbor, include the static statement at the [edit routing-instances routing-instance-name protocols vpls neighbor address] hierarchy level. You must also configure an incoming and outgoing label for the static pseudowire using the incoming-label and outgoing-label statements, configured at the [edit routing-instances routing-instance-name protocols vpls neighbor address static] hierarchy level. You can also configure the static statement for a backup neighbor (if you configure the neighbor as static the backup must also be static) at the [edit routing-instances routing-instance-name protocols vpls neighbor address backup-neighbor address] hierarchy level, and for a mesh group at the [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address] hierarchy level. If you issue a show vpls connections command, static neighbors are displayed with "SN" next to their addresses in the command output.

      To enable static VPLS on a router, you need to either configure a virtual tunnel interface (requires the router to have a tunnel PIC) or a label switching interface (LSI). To configure an LSI, include the no-tunnel-services statement at the [edit protocols vpls static-vpls] hierarchy level.

      [VPNs]


    Published: 2010-09-28