Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuration Differences Between Adaptive Services and Next Gen Services on the MX-SPC3

Overview

Next Gen Services on the MX-SPC3 require you to configure services differently from what you are accustomed to with Adaptive Services, which run on MS type cards (MS-MPC, MS-MIC and MS-DPC). Configuring the MX-SPC3 services card more closely aligns with the way you configure the SRX Series services gateway. Once you are familiar with this more unified approach, you should be able to configure services on these two platforms in a more seamless fashion, ultimately resulting in less training overhead and lower risk of configuration error.

Aside from the CLI differences, you need to be aware of the basic hardware differences between multiservices (MS) type (MS-DPC, MS-MPC, and MS-MIC) cards and the MX-SPC3 services card. MS type cards contain four CPU complexes whereas the MX-SPC3 card, while more powerful, contains two CPU complexes. Each CPU complex services a single PIC, meaning that MS type cards support four PICs whereas the MX-SPC3 supports two PICs. MS type cards use special multiservices (MS) and adaptive services (AS) PICs, whereas the PICs on the MX-SPC3 card are integrated.

Because the number of PICs directly affects the number of interfaces (Table 1), you might need to add logical units to each interface on the MX-SPC3 to increase the number of interfaces to four. For example, if you currently use all four interfaces on the MS type card and you have a service set per interface, you can create two logical units per interface on the MX-SPC3 to bring the total number of interfaces to four, and then reassociate the four service sets to these four logical interfaces.

Table 1: Hardware Differences: MS Type Cards versus MX-SPC3 Card

MS-Cards

MX-SPC3

Number of CPU complexes

4

2

Number of PICs per CPU complex

1

1

Number of interfaces per PIC

1

1

Total number of interfaces on card

4

2
Note:

See the MX Series 5G Universal Routing Platform Interface Module Reference for more information on the MX-SPC3 hardware.

The following sections provide an overview of the basic configuration differences between services on the MS type cards and services on the MX-SPC3 card. The intent of these sections is to help you get started by using basic examples to illustrate the major changes. These examples show a subset of the CLI configuration options and do not replace the more formal treatment of the subject matter found in the Next Gen Services Interfaces User Guide for Routing Devices and the Junos OS CLI Reference Guide.

The configuration examples in these sections are presented side-by-side so you can easily see the differences between the two. The examples are intended to show you how to configure existing MS type card features on the MX-SPC3. The examples are not intended to show you how to configure new features only found on the MX-SPC3. For legibility and ease of comparison, the order of statements presented might differ slightly from the actual order of statements displayed in the CLI.

If you have a large set of existing adaptive services, we recognize that these changes might be an inconvenience to you. To help you migrate from MS type cards to the MX-SPC3, we suggest that you proceed as follows:

  • Look through the examples in this guide to get an overall view of the changes required.

  • Look through the set of configuration examples in knowledge base article KB35348.

  • Look through this guide and the Junos OS CLI Reference Guide to understand all the features, configuration options, and syntax.

  • Contact JTAC for help with your migration.

You do not need to make these configuration changes if you continue to run adaptive services on the MS type cards. However, once you deploy the MX-SPC3 on a router, you must replace all MS type cards on that router and reconfigure your services to align with the Next Gen Services configuration paradigm.

Interfaces

MS type cards use the interface naming convention ms-1/0/0, whereas you specify MX-SPC3 interfaces using the virtual multiservices or vms-1/0/0 interface naming convention. There are no changes to the names of ams and mams interfaces.

In addition, a number of parameters that are configured under services-options on an ms interface are configured under service-set-options in a service set.

Table 2 shows examples of these changes.

Table 2: Interfaces and Service Options

MS Type Cards

MX-SPC3

 
[edit interfaces]
ms-5/1/0 {
    <...>
}

[edit interfaces]
# Change interface name to vms.
vms-5/1/0 {
    <...>
}

[edit interfaces]
ms-5/1/0 {
    services-options {
        open-timeout 40;
        close-timeout 40;
        inactivity-tcp-timeout 10;
        inactivity-asymm-tcp-timeout 10;
        tcp-tickles 8;
        ignore-errors tcp;
    }
}

[edit services]
service-set sset1 {
    service-set-options {
        # Set tcp parameters under tcp-session.
        tcp-session {
            open-timeout 40;
            close-timeout 40;
            inactivity-tcp-timeout 10;
            inactivity-asymm-tcp-timeout 10;
            tcp-tickles 8;
            ignore-errors tcp;
        }
    }
}

[edit interfaces]
ms-5/1/0 {
    services-options {
        inactivity-non-tcp-timeout 40;
        session-timeout 10;
    }
}

[edit services]
service-set sset1 {
    # Set non-tcp parameters directly under 
    # service-set-options.
    service-set-options {
        inactivity-non-tcp-timeout 40;
        session-timeout 10;
    }
}

[edit interfaces]
ms-5/1/0 {
    services-options {
        fragment-limit 32;
        reassembly-timeout 3;
    }
}

These parameters are hardcoded as follows:

  • fragment-limit 62

  • reassembly-timeout 2

 
[edit interfaces]
ms-5/1/0 {
    services-options {
        session-limit {
            maximum 100;
            cpu-load-threshold 12;
            rate 10;
        }
    }
}

[edit services]
# Maximum number of sessions can be 
# specified per service-set.
service-set sset1 {
    service-set-options {
        session-limit {
            maximum 100;
        }
    }
}

[edit interfaces]
# All session-limit parameters continue to be 
# configurable per interface. If the maximum
# number of sessions is different from the associated 
# service-set, the smaller number takes effect.
vms-5/1/0 {
    services-options {
        session-limit {
            maximum 100;
            cpu-load-threshold 12;
            rate 10;
        }
    }
}

[edit interfaces]
ms-5/1/0 {
    services-options {
        pba-interim-logging-interval 10;
    }
}

[edit interfaces]
# Set interim-logging-interval under the nat branch.
nat {
    source {
        pool src-pool {
            port {
                block-allocation {
                    interim-logging-interval 10;
                }
            }
        }

[edit interfaces]
ms-5/1/0 {
    services-options {
        syslog {
            host {
                <...>
            }
        }
    }
}

See service-set syslog stream host.

 
[edit interfaces]
ms-5/1/0 {
    services-options {
        syslog {
            message-rate-limit 10;
        }
    }
}

[edit services]
service-set sset1 {
    syslog {
        event-rate 10;
    }
}

[edit interfaces]
ms-5/1/0 {
    services-options {
        ignore-errors alg;
        disable-global-timeout-override;
        trio-flow-offload {
            minimum-bytes 1000;
        }
    }
}

Not supported

Service Set

Table 3 shows minor changes in the way some service-set parameters are configured.

Table 3: Service Set

MS Type Cards

MX-SPC3

 
[edit services]
service-set sset1 {
    tcp-mss 1460;
    service-set-options {
        tcp-non-syn drop-flow-send-rst;
        tcp-fast-open drop;
    }
}

[edit services]
service-set sset1 {
    service-set-options {
        # Set tcp parameters under tcp-session.
        tcp-session {
            tcp-mss 1460;
            tcp-non-syn drop-flow-send-rst;
            tcp-fast-open drop;
        }
    }
}

[edit services]
service-set sset1 {
    replicate-services {
        replication-threshold 180;
    }
}

[edit interfaces]
# Set replication-threshold on the interface.
vms-5/1/0 {
    redundancy-options {
        replication-threshold 180;
    }
}

[edit services]
service-set sset1 {
    syslog {
        host 10.1.1.1 {
            port 514;
        }
    }
}

[edit services]
service-set sset1 {
    syslog
        # Process security logs in the dataplane.
        mode stream;
        stream s1 {
            # Specify host to send security logs to.
            host {
                10.1.1.1;
                port 514;
            }
        }
    }
}

[edit services]
service-set sset1 {
    syslog {
        host local;
    }
}

[edit services]
service-set sset1 {
    syslog
        # Process security logs in the control plane,
        # saving logs to local file specified by rtlog.
        mode event;
    }
}
rtlog {
    traceoptions {
        # Specify filename for logs.
        file rtlog size 1g;
        flag all;
    }
}

[edit services]
service-set sset1 {
    service-order  <...>
}

Service order is fixed.

 
[edit services]
service-set sset1 {
    sampling-service  <...>
}

J-Flow logging is supported inline.

 
[edit services]
service-set sset1 {
    tag-rule-sets <...>
    tag-rules  <...>
    hcm-profile  <...>
    hcm-url-rule-sets  <...>
    hcm-url-rules  <...>
    service-set-options {
        bypass-traffic-on-pic-failure;
    }
}

Currently unsupported

Stateful Firewall

Rules and Policies

Stateful firewall rules on the MX-SPC3 are structured slightly differently from stateful firewall rules for services on the MS type cards. On the MX-SPC3, you enclose the rules within a policies wrapper, and you define the match terms and actions for the rule in a policy contained within the rule.

Just like a stateful firewall service on the MS type card, you create a service set to associate an interface with a rule set. A rule set contains references to one or more rules. Rules are applied sequentially in the order that you list them until a match occurs and an action taken.

Each rule contains one or more pairs of match terms and actions. On the MX-SPC3, each pair of match terms and actions is called a policy. Policies are applied sequentially in the order that you specify them until a match occurs and an action taken.

Table 4 shows the configuration differences between stateful firewall rules on the MS card and the MX-SPC3. In particular, note the different definitions for the permit/deny/reject actions.

Table 4: Stateful Firewall Rules and Policies

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set s1 {
    stateful-firewall-rule-sets rule-set-basic-sfw;
    interface-service {
        service-interface ms-1/1/0;
    }
}

service-set s1 {
    stateful-firewall-rule-sets rule-set-basic-sfw;
    interface-service {
        service-interface vms-1/1/0;
    }
}

stateful-firewall {

# Enclose stateful firewall rules within the policies wrapper.
policies { 

    rule Rule1 {
        match-direction input;
        term ping-https-apps {
            from {
                source-address {
                    any
                }
                destination-address {
                    any
                }
                applications [junos-icmp-ping junos-https];
            }
            then {
                accept/reject/discard
                skip-ids;
                syslog;
            }
        }
        term accept {
            then {
                accept;
            }
        }
    } # end Rule1

    stateful-firewall-rule Rule1 {
        match-direction input;
        # Define match terms and actions in a policy.
        policy ping-https-apps { 
            # Unlike the from statement, the match statement (and
            # source-address, destination-address, and application)
            # are mandatory.
            match {
                source-address any;
                destination-address any;
                application [ junos-icmp-ping  junos-https ];
            }
            then {
                # permit = allow
                # deny = silently drop
                # reject = drop and send ICMP unreachable or TCP RST
                permit/deny/reject
                # skip-ids is not supported. One possible way of 
                # achieving this same goal is to create two 
                # service-sets, one with IDS and one without IDS, 
                # and route your next-hop-service
                # traffic to the desired service set via the associated
                # inside or outside interface.
                log;
            }
        }
        policy accept { 
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                permit;
            }
        }
    } # end Rule1

    rule Rule2 {
        match-direction output;
        term local {
            from {
                source-address {
                    10.1.3.2/32;
                }
                application-sets APPL-SET1;
            }
            then {
                accept;
            }
        }
    } # end Rule2

    stateful-firewall-rule Rule2 {
        match-direction output;
        policy local {
            match {
                source-address 10.1.3.2/32;
                destination-address any;
                # application can refer to an application set.
                application APPL-SET1;
            }
            then {
                permit;
            }
        } 
        
    } # end Rule2

    rule-set rule-set-basic-sfw {
        rule Rule1;
        rule Rule2;
    }
} # end stateful-firewall

    # Use the stateful-firewall-rule-set element to list the 
    # firewall rules in the order that you want them applied. 
    stateful-firewall-rule-set rule-set-basic-sfw {
        stateful-firewall-rule Rule1;
        stateful-firewall-rule Rule2;
    }
} # end policies

Address Lists and Ranges

Stateful firewall rules can contain match terms that refer to address ranges and lists.

On the MS card, you use source-address-range and destination-address-range elements to specify address ranges and prefix-list elements under policy-options to specify address lists. The prefix-list element is not for use solely for stateful firewall rules. You also use the prefix-list element to specify address lists for use within routing policies.

On the MX-SPC3, the prefix-list element is not used for stateful firewall rules. You use an address-book under services to define address lists and ranges for use within stateful firewall rules. The prefix-list element still exists, but is used exclusively for routing policies. You therefore need to configure both address-book and prefix-list elements if you are specifying address lists for stateful firewall rules and address lists for routing policies.

Table 5 shows the differences between how you specify addresses for stateful firewall rules on the MS card versus the MX-SPC3.

Table 5: Addresses

MS Card

MX-SPC3

 
[edit]
policy-options {
    prefix-list p1 {
        10.1.22.45/32;
        192.168.0.11/32;
    }
}

[edit services]
    stateful-firewall {
        rule sfw-rule {
            match-direction input;
            term banned-addresses {
                from {
                    source-prefix-list {
                        p1;
                    }
                    source-address-range {
                        low 10.1.22.100 high 10.1.22.109;
                    }
                }
                then {
                    reject;
                    syslog;
                }
            }
        <...>

[edit services]
# Define address lists and address ranges in an address book.
address-book {
    global {
        address-set p1 {
            address p1-a;
            address p1-b;
        }
        address p1-a 10.1.22.45/32;
        address p1-b 192.168.0.11/32;
        address p2 { 
            address-range 10.1.22.100/32 {
                to {
                    10.1.22.109/32;
                }
            } 
        } 
    } 
} # end address-book
policies { 
    stateful-firewall-rule sfw-rule {
    match-direction input;
        policy banned-addresses { 
            match {
                # Refer to the addresses defined in the address book.
                source-address [ p1 p2 ];
                destination-address any;
                application any;
            }
            then {
                deny;
                log;
            }
        <...>

Applications

The MX-SPC3 supports more built-in Junos applications than the MS card. You can match on these built-in applications when you create a stateful firewall rule.

To see the complete list of built-in applications, use the show groups junos-defaults applications configuration mode command. For example:

Traceoptions and Counters

Stateful firewalls for Next Gen Services on the MX-SPC3 support additional capabilities to help debug and count traffic:

  • traceoptions - Use to trace policy-related events such as policy lookups and rules-based events. The events are captured in the specified file for viewing.

  • count - Use to count traffic-related events such as incoming/outgoing bytes and packets. View the counters using show commands:

    • show services policies detail - the output includes traffic-related counters when you specify the count option in your policy

    • show services policies hit-count - the hit count is always available regardless of whether you use the count option in your policy or not

Table 6 shows how to use the traceoptions and count elements:

Table 6: Traceoptions and Count

MS Card

MX-SPC3

Not supported

 
[edit services]
policies { 
# Enable traceoptions to trace policy-related events.
    traceoptions {
        file policylogs size 10m files 5;
        flag all;
    }
    stateful-firewall-rule Rule1 {
        match-direction input;
        policy my-policy { 
            match {
                source-address any;
                destination-address any;
                application [ junos-dns-udp junos-dns-tcp ];
            }
            then {
                permit
                # Enable counting of traffic events.
                count;
            }
        } # end my-policy
    ...

Carrier Grade Network Address Translation (CGNAT)

Configuring NAT for Next Gen Services on the MX-SPC3 is different from configuring NAT on legacy services on the MS card in a number of ways:

  • On the MX-SPC3, you configure source NAT separately from destination NAT. You configure source NAT in the source branch of the configuration tree and you configure destination NAT in the destination branch of the configuration tree. Source NAT and destination NAT each has its own sets of address pools and rules in its respective branch of the configuration tree.

  • On the MX-SPC3, if you configure both source NAT and destination NAT, destination NAT applies first, and then source NAT applies to the destination NAT translated result. In other words, you write the source NAT rule not based on the original packet, but based on the destination NAT translated result.

  • On the MX-SPC3, you do not explicitly configure a translation-type. The type of translation is determined implicitly by your configuration.

  • On the MX-SPC3, port translation is the default behavior for dynamic mappings (where different pre-NAT addresses might map to the same post-NAT address over time). If you do not explicitly include the port statement in a pool definition, port translation takes place with a port range [1024, 65535], and the port is selected in a round robin fashion. If you do not want port translation to take place, you must add a port statement with the no-translation option. This default does not apply to static mappings where a pre-NAT address always maps to the same post-NAT address.

Table 7 through Table 19 show examples of how the different translation types are configured on the MX-SPC3.

Table 7: Example: Basic-NAT44

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-basic-nat44;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-basic-nat44;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.10.10.0/24;
    }

    
        pool src-pool {
            address {
                10.10.10.0/24;
            }
            # host-address-base indicates a type of static mapping 
            # where the base address 10.45.1.0/0 maps to the 
            # lowest address in the pool, namely 10.10.10.0/0,
            # and the other addresses map sequentially from there
            # e.g. 10.45.1.1 maps to 10.10.10.1, and so on.
            # Since this is a static mapping, there is no port translation
            # by default.
            # Note that host-address-base does not have to be the 
            # lowest address allowed by the subsequent source rule. 
            # Any packet with a source address allowed by the source rule
            # but is lower than the host-address-base is discarded. 
            host-address-base 10.45.1.0/0;
        }

    rule rule-basic-nat44 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    10.45.1.0/24
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    translation-type {
                        basic-nat44;
                    }
                }
            }
        }
    }

        rule-set rule-basic-nat44 {
            match-direction input;
            rule r1 {
                match {
                    source-address 10.45.1.0/24;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source
} # end nat
Table 8: Example: Basic-NAT66

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-basic-nat66;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-basic-nat66;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 2001:DB8:2222::0/96;
    }

    
        pool src-pool {
            address {
                2001:DB8:2222::0/96;
            }
        }

    rule rule-basic-nat66 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    2001:DB8:1111::0/96;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    translation-type {
                        basic-nat66;
                    }
                }
            }
        }
    }

        rule-set rule-basic-nat66 {
            match-direction input;
            rule r1 {
                match {
                    source-address 2001:DB8:1111:::0/96;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source
} # end nat
Table 9: Example: Dynamic-NAT44

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-dynamic-nat44;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-dynamic-nat44;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address-range low 10.10.10.2 high 10.10.10.10;
    }

    
        pool src-pool {
            address {
                10.10.10.2/32 to 10.10.10.10/32;
            }
            # Since this is implicitly a dynamic mapping, 
            # there is port translation by default , so we need to
            # explictly specify that we don’t want port translation.
            port {
                no-translation;
            }
        }

    rule rule-dynamic-nat44 {
        match-direction input;
        term t0 {
            from {
                applications junos-icmp-all;
            }
            then {
                no-translation;
            }
        }
        term t1 {
            from {
                destination-address {
                    10.99.0.2/32;
                }
                source-address-range {
                    low 10.45.0.2 high 10.45.0.10;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    translation-type {
                        dynamic-nat44;
                    }
                }
            }
        }
    }

        rule-set rule-dynamic-nat44 {
            match-direction input;
            rule r0 {
                match {
                    source-address 0.0.0.0/0;
                    application junos-icmp-all;
                }
                then {
                    source-nat {
                        off;
                    }
                }
            }
            rule r1 {
                match {
                    source-address-name addr1;
                    destination-address 10.99.0.2/32;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source
} # end nat


address-book {
    global {
        address addr1 {
            address-range 10.45.0.2/32 {
                to {
                    10.45.0.10/32;
                }
            }
        }
    }
}
Table 10: Example: NAPT-44

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-napt44;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-napt44;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.10.10.0/24;
        port {
            automatic;
        }
    }


    
        pool src-pool {
            address {
                10.10.10.0/24;
            }
            # Since this is implicitly a dynamic mapping,
            # and there is no explicit port statement
            # to indicate otherwise, the default port 
            # mapping behavior takes effect.
        }
    


    rule rule-napt44 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    10.45.1.0/24
                }
                application-sets accept-algs;
            }
            then {
                translated {
                    source-pool src-pool;
                    translation-type {
                        napt44;
                    }
                }
            }
        }
    }

    
        rule-set rule-napt44 {
            match-direction input;
            rule r1 {
                match {
                    source-address 10.45.1.0/24;
                    application accept-algs;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source
} # end nat
Table 11: Example: napt-66

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-napt66;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-napt66;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 2001:DB8:2222::0/112;
        port {
            range low 20000 high 30000;
        }
    }


    
        pool src-pool {
            address {
                2001:DB8:2222::0/112;
            }
            port {
                range {
                    20000;
                    to {
                        30000;
                    }
                }
            }
        }
    


    rule rule-napt66 {
        match-direction input;
        term t1 {
            from {
                source-address {
                     2001:DB8:1111::0/96;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    translation-type {
                        napt66;
                    }
                }
            }
        }
    }

    
        rule-set rule-napt66 {
            match-direction input;
            rule r1 {
                match {
                    source-address 2001:DB8:1111::0/96;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source
} # end nat
Table 12: Example: Deterministic NAT-44

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-dnat-44;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-dnat-44;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    destination {


    pool dest-pool {
        address 10.10.10.2/32;
    }

    
        pool dest-pool {
            address {
                10.10.10.2/32;
            }
        }

    rule rule-dnat-44 {
        match-direction input;
        term t1 {
            from {
                destination-address {
                    10.45.0.2/32
                }
            }
            then {
                translated {
                    destination-pool dest-pool;
                    translation-type {
                        dnat-44;
                    }
                }
            }
        }
    }

        rule-set rule-dnat-44 {
            match-direction input;
            rule r1 {
                match {
                    destination-address 10.45.0.2/32;
                }
                then {
                    destination-nat {
                        pool {
                            dest-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end destination
} # end nat
Table 13: Example: Stateful-NAT464

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-stateful-nat464;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-stateful-nat464-src;
    nat-rule-sets rule-stateful-nat464-dest;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.10.10.0/24;
        port {
            automatic;
        }
    }

    
        pool src-pool {
            address {
                10.10.10.0/24;
            }
            port {
                automatic {
                    round-robin;
                }
            }
        }

    rule rule-stateful-nat464 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    2001:DB8:1111::0/96;
                }
                destination-address {
                    2001:DB8:2222::0/96;
                }
                applications [junos-icmp-all junos-icmp-ping junos-traceroute junos-traceroute-ttl 1];
            }
            then {
                translated {
                    source-pool src-pool;
                    clat-prefix 2001:DB8:1111::0/96;
                    destination-prefix 2001:DB8:2222::0/96;
                    translation-type {
                        stateful-nat464;
                    }
                }
            }
        }
    }

    # This source rule applies after the destination rule.
        rule-set rule-stateful-nat464-src {
            match-direction input;
            rule r1 {
                match {
                    source-address 2001:DB8:1111::0/96;
                    # Since destination NAT happens first, the 
                    # destination IPv6 prefix has  been stripped off, 
                    # resulting in an IPv4 destination address.
                    destination-address 0.0.0.0/0;
                    application [junos-icmp-all junos-icmp-ping junos-traceroute junos-traceroute-ttl 1];
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                            }
                        clat-prefix 2001:DB8:1111::0/96;
                    }
                }
            }
        }

} # end nat

    
    } # end source


    destination {



    # This destination rule applies before the source rule.
        rule-set rule-stateful-nat464-dest {
            match-direction input;
            rule r1 {
                match {
                    destination-address 2001:DB8:2222::0/96;
                }
                then {
                    destination-nat {
                        destination-prefix 2001:DB8:2222::0/96;
                    }
                }
            }
        }


    
    } # end destination
} # end nat
Table 14: Example: Stateful-NAT64

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-stateful-nat64;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-stateful-nat64-src;
    nat-rule-sets rule-stateful-nat64-dest;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.10.10.0/24;
        port {
            automatic;
                random-allocation;
            }
        }
        mapping-timeout 500;
    }

    
        pool src-pool {
            address {
                10.10.10.0/24;
            }
            port {
                automatic {
                    random-allocation;
                }
            }
            mapping-timeout 500;
        }

    rule rule-stateful-nat64 {
        match-direction input;
        term t1 {
            from {
                destination-address {
                    2001:DB8:2222::0/64;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    destination-prefix 2001:DB8:2222::0/64;
                    translation-type {
                        stateful-nat64;
                    }
                }
            }
        }
        term t2 {
            from {
                destination-address {
                    2001:DB8:3333::0/64;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    destination-prefix 2001:DB8:3333::0/64;
                    translation-type {
                        stateful-nat64;
                    }
                }
            }
        }
    }

    # This source rule applies after the destination rule.
        rule-set rule-stateful-nat64-src {
            match-direction input;
            rule r1 {
                match {
                    source-address 0::/0;
                    # Since destination NAT applies first, the 
                    # destination address is now IPv4.
                    destination-address 0.0.0.0/0;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source


    destination {



    # This destination rule applies before the source rule.
        rule-set rule-stateful-nat64-dest {
            match-direction input;
            rule r1 {
                match {
                    destination-address 2001:DB8:2222::0/64;
                }
                then {
                    destination-nat {
                        destination-prefix 2001:DB8:2222::0/64;
                    }
                }
            }
            rule r2 {
                match {
                    destination-address 2001:DB8:3333::0/64;
                }
                then {
                    destination-nat {
                        destination-prefix 2001:DB8:3333::0/64;
                    }
                }
            }
        }


    
    } # end destination
} # end nat
Table 15: Example: Twice-Basic-NAT-44

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-twice-basic-nat-44;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-twice-basic-nat-44-src;
    nat-rule-sets rule-twice-basic-nat-44-dest;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.98.10.0/24;
    }
    pool dest-pool {
        address 10.99.10.0/24;
    }

    
        pool src-pool {
            address {
                10.98.10.0/24;
            }
            # host-address-base indicates a type of static mapping where
            # the base address 10.10.10.0/0 maps to the lowest 
            # address in the pool, namely 10.98.10.0/0,
            # and the other addresses map sequentially from there
            # e.g. 10.10.10.1 maps to 10.98.10.1, and so on.
            # Since this is a static mapping, there is no port translation 
            # by default.
            # Note that host-address-base does not have to be the 
            # lowest address allowed by the subsequent source rule. 
            # Any packet with a source address allowed by the source rule
            # but is lower than the host-address-base is discarded. 
            host-address-base 10.10.10.0/0;
        }

    rule rule-twice-basic-nat-44 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    10.10.10.0/24;
                }
                destination-address {
                    10.20.10.0/24;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    destination-pool dest-pool;
                    translation-type {
                        twice-basic-nat-44;
                    }
                }
            }
        }
    }

    # This source rule applies after the destination rule.
        rule-set rule-twice-basic-nat-44-src {
            match-direction input;
            rule r1 {
                match {
                    source-address 10.10.10.0/24;
                    # Since destination NAT happens first, the destination
                    # address refers to the NAT’d address.
                    destination-address 10.99.10.0/24;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source


    destination {



    
        pool dest-pool {
            address {
                10.99.10.0/24;
            }
        }


    # This destination rule applies before the source rule.
        rule-set rule-twice-basic-nat-44-dest {
            match-direction input;
            rule r1 {
                match {
                    destination-address 10.20.10.0/24;
                }
                then {
                    destination-nat {
                        pool {
                            dest-pool;
                        }
                    }
                }
            }
        }


    
    } # end destination
} # end nat
Table 16: Example: Twice-Dynamic-NAT-44

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-twice-dynamic-nat-44;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-twice-dynamic-nat-44-src;
    nat-rule-sets rule-twice-dynamic-nat-44-dest;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.98.10.0/24;
    }
    pool dest-pool {
        address 10.99.10.0/24;
    }

    
        pool src-pool {
            address {
                10.98.10.0/24;
            }
            port {
                no-translation;
            }
        }

    rule rule-twice-dynamic-nat-44 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    10.10.10.0/24;
                }
                destination-address {
                    10.20.10.0/24;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    destination-pool dest-pool;
                    translation-type {
                        twice-dynamic-nat-44;
                    }
                }
            }
        }
    }

    # This source rule applies after the destination rule.
        rule-set rule-twice-dynamic-nat-44-src {
            match-direction input;
            rule r1 {
                match {
                    source-address 10.10.10.0/24;
                    # Since destination NAT happens first, the destination
                    # address refers to the NAT’d address.
                    destination-address 10.99.10.0/24;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source


    destination {



    
        pool dest-pool {
            # By default, address mapping in destination pools is static.
            address {
                10.99.10.0/24;
            }
        }


    # This destination rule applies before the source rule.
        rule-set rule-twice-dynamic-nat-44-dest {
            match-direction input;
            rule r1 {
                match {
                    destination-address 10.20.10.0/24;
                }
                then {
                    destination-nat {
                        pool {
                            dest-pool;
                        }
                    }
                }
            }
        }


    
    } # end destination
} # end nat
Table 17: Example: Twice-NAPT-44

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-twice-napt-44;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-twice-napt-44-src;
    nat-rule-sets rule-twice-napt-44-dest;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.98.10.0/24;
        port {
            automatic;
            secured-port-block-allocation block-size 256 max-blocks-per-address 1 active-block-timeout 300;
        }
    }
    pool dest-pool {
        address 10.99.10.2/32;
    }

    
        pool src-pool {
            address {
                10.98.10.0/24;
            }
            port {
                automatic {
                    round-robin;
                }
                block-allocation {
                    block-size 256;
                    maximum-blocks-per-host 1;
                    active-block-timeout 300;
                }
            }
        }

    rule rule-twice-napt-44 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    10.10.10.0/24;
                }
                destination-address {
                    10.20.10.2/32;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    destination-pool dest-pool;
                    translation-type {
                        twice-napt-44;
                    }
                }
            }
        }
    }

    # This source rule applies after the destination rule.
        rule-set rule-twice-napt-44-src {
            match-direction input;
            rule r1 {
                match {
                    source-address 10.10.10.0/24;
                    # Since destination NAT happens first, the
                    # destination address refers to the NAT’d address.
                    destination-address 10.99.10.2/32;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source


    destination {



    
        pool dest-pool {
            address {
                10.99.10.2/32;
            }
        }


    # This destination rule applies before the source rule.
        rule-set rule-twice-napt-44-dest {
            match-direction input;
            rule r1 {
                match {
                    source-address 10.10.10.0/24;
                    destination-address 10.20.10.2/32;
                }
                then {
                    destination-nat {
                        pool {
                            dest-pool;
                        }
                    }
                }
            }
        }


    
    } # end destination
} # end nat
Table 18: Example: Deterministic-NAPT44

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-deterministic-napt44;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-deterministic-napt44;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.10.10.0/24;
        port {
            range low 1024 high 19999;
            deterministic-port-block-allocation block-size 256;
        }
        mapping-timeout 120;
    }

    
        pool src-pool {
            address {
                10.10.10.0/24;
            }
            port {
                range {
                    1024;
                    to {
                        19999;
                    }
                }
                deterministic {
                    block-size 256;
                    # host address specifies the subnet that you
                    # want to apply to this pool.
                    host address 10.2.0.0/20;
                }
            }
            mapping-timeout 120;
        }

    rule rule-deterministic-napt44 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    10.2.0.0/18;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    translation-type {
                        deterministic-napt44;
                    }
                    mapping-type endpoint-independent;
                }
            }
        }
    }

        rule-set rule-deterministic-napt44 {
            match-direction input;
            rule r1 {
                match {
                    source-address 10.2.0.0/18;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                        mapping-type endpoint-independent;
                    }
                }
            }
        }

} # end nat

    
    } # end source
} # end nat
Table 19: Example: Deterministic-NAPT64

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-deterministic-napt64;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-deterministic-napt64-src;
    nat-rule-sets rule-deterministic-napt64-dest;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.98.10.0/24;
        port {
            automatic;
            random-allocation;
            }
            deterministic-port-block-allocation block-size 256;
        }
    }

    
        pool src-pool {
            address {
                10.98.10.0/24;
            }
            port {
                automatic {
                    random-allocation;
                }
                deterministic {
                    block-size 256;
                    host address 2001:DB8:1111::1/120;
                }
            }
        }

    rule rule-deterministic-napt64 {
        match-direction input;
        term t1 {
            from {
                source-address {
                    2001:DB8:1111::1/120;
                }
            }
            then {
                translated {
                    destination-prefix 2001:DB8:2222::/96;
                    source-pool src-pool;
                    translation-type {
                        deterministic-napt64;
                    }
                }
            }
        }
    }

    # This source rule applies after the destination rule.
        rule-set rule-deterministic-napt64-src {
            match-direction input;
            rule r1 {
                match {
                    source-address 2001:DB8:1111::1/120;
                    # Since destination NAT happens first, the destination
                    # address refers to the NAT’d address.
                    destination-address 0.0.0.0/0;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source


    destination {



    
        pool dest-pool {
            address {
                10.99.10.2/32;
            }
        }


    # This destination rule applies before the source rule.
        rule-set rule-destination-napt64-dest {
            match-direction input;
            rule r1 {
                match {
                    destination-address 2001:DB8:2222::/96;
                }
                then {
                    destination-nat {
                        destination-prefix 2001:DB8:2222::/96;
                    }
                }
            }
        }


    
    } # end destination
} # end nat
Table 20: Example: napt-pt

MS Card

MX-SPC3

 
[edit services]

[edit services]

service-set sset1 {
    nat-rules rule-napt-pt;
    interface-service {
        service-interface ms-1/2/0;
    }
}

service-set sset1 {
    nat-rule-sets rule-napt-pt-src;
    nat-rule-sets rule-napt-pt-dest;
    interface-service {
        service-interface vms-2/0/0;
    }
}

nat {

nat {
    source {


    pool src-pool {
        address 10.10.10.2/32;
    }
    pool dest-pool {
        address 10.99.10.2/32;
    }

    
        pool src-pool {
            address {
                10.10.10.2/32;
            }
        }

    rule rule-napt-pt {
        match-direction input;
        term t1 {
            from {
                source-address {
                    2001:DB8:1111::2/128;
                }
                destination-address {
                    2001:DB8:2222::2/128;
                }
            }
            then {
                translated {
                    source-pool src-pool;
                    destination-pool dest-pool;
                    translation-type {
                        napt-pt;
                    }
                }
            }
        }
    }

        rule-set rule-napt-pt-src {
            match-direction input;
            rule r1 {
                match {
                    source-address 2001:DB8:1111::2/128;
                    destination-address 10.99.10.0/24;
                }
                then {
                    source-nat {
                        pool {
                            src-pool;
                        }
                    }
                }
            }
        }

} # end nat

    
    } # end source


    destination {



    
        pool dest-pool {
            address {
                10.99.10.2/32;
            }
        }


        rule-set rule-napt-pt-dest {
            match-direction input;
            rule r1 {
                match {
                    destination-address 2001:DB8:2222::2/128;
                }
                then {
                    destination-nat {
                        pool {
                            dest-pool;
                        }
                    }
                }
            }
        }


    
    } # end destination
} # end nat

Intrusion Detection System (IDS)

IDS rules for Next Gen Services on the MX-SPC3 are defined under the screen branch. There are minor differences in the naming of the various elements, but the main change is in the behavior for detecting packets with IPv4 options and IPv6 extensions:

  • For the IDS service on the MS Card, the default behavior is to detect and drop packets with IPv4 options and IPv6 extensions. If you want to allow these packets, you have to allow them explicitly through configuration.

  • For the IDS Next Gen Service on the MX-SPC3, the default behavior is to allow packets with IPv4 options and IPv6 extensions. If you want to detect and drop these packets, you have to disallow them explicitly through configuration.

Table 21 shows examples of the configuration differences.

Table 21: IDS Rules

MS Card

MX-SPC3

 
[edit services]
service-set sset1 {
    ids-rules r1;
    ids-rules r2;
}

[edit services]
service-set sset1 {
    # Replace ids-rules with ids-option.
    ids-option ids1;
    ids-option ids2;
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            <...>
        }
    }
}

[edit services]
# Define ids rules under the screen branch.
screen {
    # Replace rule with ids-option.
    ids-option ids1 {
        match-direction input;
        # Flatten hierarchy by removing term and placing 
        # contents directly under ids-option.
        <...>
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                allow-ip-options [ loose-source-route route-record router-alert security stream-id strict-source-route timestamp ];
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        # By default, all ip options are allowed.
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                <no allow-ip-options configured>
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        # Explicitly specify the disallowed options.
        ip {
            loose-source-route-option;
            record-route-option;
            security-option;
            stream-option;
            strict-source-route-option;
            timestamp-option;
            # router-alert option for IPv4 is not supported.
        }
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                allow-ipv6-extension-header [ ah dstopts esp fragment hop-by-hop mobility routing ];
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        # By default, all ipv6 extensions are allowed.
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                <no allow-ipv6-extension-header configured>
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        ip {
            # Explicitly specify the disallowed extensions.
            ipv6-extension-header {
                AH-header;
                ESP-header;
                fragment-header;
                hop-by-hop-header;
                mobility-header;
                routing-header;
                # dstoptions is not supported.
            }
        }
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                aggregation {
                    source-prefix 24;
                    destination-prefix 24;
                    source-prefix-ipv6 64;
                    destination-prefix-ipv6 64;
                }
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        aggregation {
            source-prefix-mask 24;
            destination-prefix-mask 24;
            source-prefix-v6-mask 64;
            destination-prefix-v6-mask 64;
        }
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                icmp-fragment-check;
                icmp-large-packet-check;
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        # Group icmp checks under icmp.
        icmp {
            fragment;
            large;
        }
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                land-attack-check;
                tcp-winnuke-check;
                tcp-syn-fragment-check;
                tcp-syn-defense;
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        # Group tcp checks under tcp.
        tcp {
            land;
            winnuke;
            syn-frag;
            # tcp-syn-defense is not supported.
        }
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                session-limit {
                    by-source {
                        maximum 100;
                        rate 10;
                        packets 1k;
                    }
                    by-destination {
                        maximum 100;
                        rate 10;
                        packets 1k;
                    }
                }
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        limit-session {
            by-source {
                maximum-sessions 100;
                session-rate 10;
                packet-rate 1k;
            }
            by-destination {
                maximum-sessions 100;
                session-rate 10;
                packet-rate 1k;
            }
        }
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                session-limit {
                    by-source {
                        by-protocol {
                            tcp {
                                maximum 100;
                                rate 10;
                                packets 1k;
                            }
                            udp {
                                maximum 100;
                                rate 10;
                                packets 1k;
                            }
                            icmp {
                                maximum 100;
                                rate 10;
                                packets 1k;
                            }
                        }
                }
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        limit-session {
            by-source {
                by-protocol {
                    tcp {
                        maximum-sessions 100;
                        session-rate 10;
                        packet-rate 1k;
                    }
                    udp {
                        maximum-sessions 100;
                        session-rate 10;
                        packet-rate 1k;
                    }
                    icmp {
                        maximum-sessions 100;
                        session-rate 10;
                        packet-rate 1k;
                    }
                }
            }
        }
    }
}

[edit services]
ids {
    rule r1 {
        match-direction input;
        term t1 {
            then {
                session-limit {
                    by-destination {
                        by-protocol {
                            tcp {
                                maximum 100;
                                rate 10;
                                packets 1k;
                            }
                            udp {
                                maximum 100;
                                rate 10;
                                packets 1k;
                            }
                            icmp {
                                maximum 100;
                                rate 10;
                                packets 1k;
                            }
                        }
                }
            }
        }
    }
}

[edit services]
screen {
    ids-option ids1 {
        match-direction input;
        limit-session {
            by-destination {
                by-protocol {
                    tcp {
                        maximum-sessions 100;
                        session-rate 10;
                        packet-rate 1k;
                    }
                    udp {
                        maximum-sessions 100;
                        session-rate 10;
                        packet-rate 1k;
                    }
                    icmp {
                        maximum-sessions 100;
                        session-rate 10;
                        packet-rate 1k;
                    }
                }
            }
        }
    }
}

Migrate from the MS Card to the MX-SPC3

Use this procedure to configure a router to support Next Gen Services.

You typically use this procedure to migrate a router supporting legacy services on the MS card to a router supporting Next Gen Services on the MX-SPC3, but this procedure applies even if the router that you are migrating from does not contain MS card cards.

Because Next Gen Services configuration is not compatible with legacy service provisioning, migrating a router to support Next Gen Services on the MX-SPC3 requires you to completely deprovision and reprovision your router . Furthermore:

  • You cannot install an MX-SPC3 card in a router that has MS cards.

  • You cannot configure Next Gen Services on a router equipped with MS cards.

  • You cannot configure legacy services on a router equipped with MX-SPC3 cards.

In other words, a router can run with either MS cards or MX-SPC3 cards but not both at the same time.

Note:

This procedure is service affecting. You are setting the router to factory default configuration.

  1. Upgrade the router to release 19.3R2.
  2. Back up the current router configuration to a remote host.
  3. Set the router to factory default configuration.
    1. Load the router with the factory default configuration:
    2. Configure the management interface with the same IP address as you had before you loaded the factory default configuration:
    3. Configure SSH so that you can continue to access the router. For example:
    4. Commit the changes.
  4. Enable Next Gen Services on the router.

    Junos OS provides a system-wide operational parameter that you enable if you want to configure Next Gen Services on a router. By default, this parameter is not enabled.

    From operational mode:

    Note:

    This setting is persistent and survives a reboot.

  5. Reboot the router.
  6. Replace the MS card cards with MX-SPC3 cards.
  7. Reprovision your router.

    As a starting point, you can restore the backup from step 2 but you might need to change this configuration to be compatible with Next Gen Services before you can commit.

See Also