MX Services Control Gateway - Juniper Networks · PDF fileConfiguring the PCRF ... The Service...

Delivering Customized Services with MX Series Routers and Service Control Gateway Application Suite Configuration Example

January 2017

Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. The information in this document is current as of the date on the title page. Copyright © 2017, Juniper Networks, Inc. All rights reserved.

Table of Contents Overview ................................................................................................................................................................................. 4

Introducing the SCG ........................................................................................................................................................... 4 Terminology ........................................................................................................................................................................ 5

Operational Overview .............................................................................................................................................................. 6 Network Topology ............................................................................................................................................................... 6 Session Setup ..................................................................................................................................................................... 7 Outbound (Uplink) Traffic .................................................................................................................................................... 8 Return (Downlink) Traffic .................................................................................................................................................... 9

Solution Configuration ........................................................................................................................................................... 12 Configuring the BNG ......................................................................................................................................................... 12 Configuring the PCRF ....................................................................................................................................................... 13 Service Chain Configuration ............................................................................................................................................. 17 SCG Configuration ............................................................................................................................................................ 18 Configuring Contrail .......................................................................................................................................................... 20 TDF Configuration ............................................................................................................................................................ 28

Verification ............................................................................................................................................................................. 36 Initial Verification ............................................................................................................................................................... 36 Verifying Initial Subscribers .............................................................................................................................................. 39 Verify Connectivity ............................................................................................................................................................ 42 Use Case - Change Service ............................................................................................................................................. 42 Use Case - Upgrade Existing Service .............................................................................................................................. 44

Conclusion ............................................................................................................................................................................. 46 Appendix A – BNG, SCG, vSRX Configuration .................................................................................................................... 47

Configuration Example: Delivering Customized Services with the MX Series Routers and Service Control Gateway Application Suite

© 2017 Juniper Networks, Inc.

Overview Introducing the SCG The Service Control Gateway (SCG) Application Suite runs on MX Series 3D Universal Edge Routers, giving service providers the ability to apply customized services to individual broadband subscribers, mobile subscribers, and enterprises. The SCG implements the Traffic Detection Function (TDF), as defined by the Third-Generation Partnership Project (3GPP) specification, which enables it to analyze the subscriber’s applications, determine the subscriber type, device type, and location. Based on this information, the SCG can apply and enforce service policy rules that are controlled by an external RADIUS or Policy Charging and Rules Function (PCRF) server.

Using the MS-MPC module in the MX Series router, the SCG can apply services including integrated Layer 4 through Layer 7 deep packet inspection, HTTP content management, and rate limiting. Also, one of the key elements of the solution is the SCG’s ability to apply services to subscriber traffic using Network Functions Virtualization (NFV). Traffic is steered to a service chain consisting of one or more virtual network functions (VNFs); for example, Juniper vSRX, which is implemented and controlled using Juniper Contrail. These services can be combined with services, such as stateful firewall and carrier-grade NAT (CGNAT), that are also implemented on the MS-MPC.

This configuration example is a basic demonstration of the SCG to help you gain an understanding of how the solution fundamentally works. It provides a baseline configuration on top of which additional components of the solution can be configured.



Terminology Much of the terminology used in the SCG configuration and documentation is based on the technical specifications defined for 3GPP mobile technology. However, the SCG can be applied to wireline subscribers as well. The most frequently used acronyms are:

• BNG - Broadband Network Gateway

• SCG - Service Control Gateway. Juniper MX Series router with SCG software installed and an MS-MPC that identifies and steers individual subscriber sessions so that the appropriate services are applied.

• Gx - reference point or interface between PCRF and PCEF.

• PCEF - Policy and Charging Enforcement Function. This function runs on the SCG, specifically on the MS-MPC module. It applies, or enforces, policies to the subscriber traffic. Multiple PICs on the MS-MPC are used to implement PCEF:

o Session PIC for control plane function

o Service PIC for data plane policy application

• PCC - Policy and Charging Control. A set of rules or policies that specify the actions to take on packets that match a particular condition.

• PCRF - Policy and Charge Rules Function. This function runs on an external device and contains a set of policy rules (PCC) for each subscriber. The policy rules are pushed to the SCG, that is the PCEF, using the Gx interface.

• TDF - Traffic Detection Functionality. Describes the ability to identify subscribers and analyze their applications and content. This functionality is present on the SCG.

• mif - mobile interface. A logical interface defined in Junos that is configured in a virtual router that also contains the access interface towards the subscribers. This interface is used by TDF to stitch subscriber traffic flows from the access interface to the service PIC where services can be applied to a set of subscribers.



Operational Overview Before configuring the SCG we will familiarize you with the network topology, show how subscribers are identified, and show how traffic flows through the SCG.

Network Topology In this example, an MX240 is in the role of a BNG that terminates PPPoE subscribers. The BNG transmits all subscriber traffic to the SCG.

There are two address pools:

• The first pool is for subnet range 10.168/16, and is used to assign IP address to 4000 PPPoE subscribers simulated by the Spirent TestCenter interface. The SCG applies NAT to traffic from these subscribers and forwards it to the Internet. TDF is not applied to this traffic.

• The second pool, 10.169/16, is used for the two Windows 7 based PPPoE subscribers. Traffic from these subscribers is steered to either the Green or Blue service chain, then NAT is applied, and the traffic is forwarded to the Internet.

SCG

lo0 2.2.2.2

MX960 – SCGPerforms Policing, Steering of subscriber traffic to Green and Blue service chains, and Source NAPT to IP address 192.168.186.20.

Access VR- interfaces xe-0/0/0.20, ge-1/3/0.0- Apply TDF to address-pool 10.169/16- Static Routes to subscribers

xe-0/0/0BNG

lo0 1.1.1.1

xe-1/0/0xe-1/2/0

MX240 – BNGPool1 – 10.168/16 for 4k PPPoEPool2 – 10.169/16 for service chain subscribers Send RADIUS Accounting Start to 10.20.20.2

Spirent 9/44k PPPoE

subscribers10.168/16

Contrail

vSRX

Internet

ge-1/2/0192.168.186.10

Win7 Host ‘A’lice10.169/16Maps to Service “Green”

Win7 Host ‘C’arlos10.169/16Maps to Service “Blue”

10.20.20/24 (V20,User)10.21.21/24 (V21,RADIUS)

PCRF10.255.2.2

xe-1/1/0

EX4300

RADIUS 10.8.158.250Returns address pool name

xe-0/1/0

ge-1/3/0

.1 .2

Gxfxp0

ControllervSRX

10.12.2.0/31

The SCG is also configured to ensure that return traffic from the Internet passes through the service chains, if necessary, and ultimately forwarded towards the subscriber.



Session Setup The session PIC is the key element on the SCG for performing subscriber session setup and management. The session PIC establishes a session with the PCRF so that it can receive PCC rules and then selects the service PIC for data processing.

16

The session setup works as follows:

1. Once the BNG has successfully authenticated a new PPPoE subscriber, it sends a copy of the RADIUS Accounting-Start message to the SCG.

2. The Ingress PFE identifies the RADIUS Accounting-Start packet and forwards it to the session PIC.

3. The SCG is configured with one or more address pool ranges that correspond to the subscriber traffic that will be handled by the TDF. If the subscriber’s IP address in the RADIUS Accounting-Start packet matches this pool, then the session PIC, using the Diameter protocol, queries the PCRF server.

The PCRF server returns the set of policies (that is, PCC rules) to be applied to the subscriber session. In this case, the PCRF server uses the subscriber’s username to determine the policy. Note that the policies or rules themselves are configured on the SCG, the PCRF instructs the SCG which rules to apply and/or remove.

4. The service PIC is programmed with the subscriber session and policy information.

5. RADIUS Accounting-Response is sent back to AAA client on BNG.



Outbound (Uplink) Traffic Initially the SCG is configured with one or more address pool ranges that correspond to the subscriber traffic that will be handled by the TDF. These source address ranges are programmed in the PFE of the access interface contained in the access virtual router (VR). In this example, the SCG-Access VR.

The key element on the SCG for performing application-aware and subscriber-aware policy enforcement and traffic steering is the service PIC. The service PIC stores the configured PCC rule, stores the subscriber records and rules from the session PIC, and applies various services including application detection and control, HTTP redirect, and rate limiting.

MS-MPC SCG

vSRX

inet.0DR to Internet

ge-1/2/0

Green-Left192.168.10/24

Session PIC (ms-5/0/0)Gx interface to PCRF

SCG-Access- Address-Pool 10.169/16

- Receives subscriber traffic, steers via ‘mif’ interface to Services PIC- Forwarding table filter to steer

Source IP 10.168/16 to ‘VR-NAT’- Static routes to subscribers

VR-NATDefault Route to ‘inside’ service

interface for CGNAT.

VR-GREEN-IN Learns Default Route via

IBGP from Contrail.

Service PIC (ms-5/1/0) Apply subscriber aware

services (ex. policing) and steering

PCRF Server10.255.2.2

ms-5/2/0.1(inside)

ms-5/2/0.2(outside)

To BNG

data path for 10.169/16 subscribers

Green-Right192.168.11/24

VR-GREEN-OUTDefault Route to VR-NAT

To Internet

Data path for 10.168/16 subscribers

ge-1/3/0 xe-0/1/0 10.12.2.0/31

Contrail

SCG MX960

10.20.20.2 (V20)

‘Green’ Service

10.255.2.1/24

xe-0/0/0.20

.201 .200

Receive subscriber data plane traffic from BNG

Non-SCG subscriber service

1 23

Steer to external service

4 Services applied by virtual appliance

5Traffic directed to internal NAT service

6Route NAT’d traffic to Internet

Outbound traffic is processed as follows:

1. Traffic enters the access VR, SCG-Access. If the source IP address matches the configured address-pool 10.169/16, the TDF rules in the PFE direct the traffic to the mif interface. If the source address is not to be serviced by the TDF, it is forwarded to the VR-NAT virtual router (see step 6).

2. The mif interface is in the SCG-Access VR and is configured with a service set that directs traffic to the service PIC.



3. The service PIC applies any configured subscriber services, rate limiting in this case, and then steers traffic to an inbound VPN routing and forwarding routing (VRF) routing instance that corresponds to the service chain assigned to the subscriber traffic. In this example, traffic is directed to the VR-GREEN-IN VRF, which peers using IBGP with the Contrail controller (not shown in diagram).

4. The VR-GREEN-IN VRF contains a default route that forwards all traffic towards the Contrail service chain. This default route was configured in the VR-GREEN-OUT VRF and learned via the IBGP peering session with the Contrail controller. The Green service chain consists of a single vSRX. Note that another set of VRFs and vSRX is configured for the Blue service (not shown in diagram).

5. The default route in VR-GREEN-OUT VRF is used to forward traffic to the VR-NAT virtual router routing instance.

6. The VR-NAT VR forwards traffic to unique MS-MPC NPU, or PIC, for CGNAT. Traffic is then forwarded to Internet using the inet.0 routing table.

Return (Downlink) Traffic One of the important configuration elements for properly handling return, or downlink, traffic is distributing the IP subnets corresponding to the subscriber address pools to the appropriate VR and VRF forwarding tables. Specifically, the 10.168/16 and 10.169/16 subnets are initially defined as static routes in VR SCG-Access and then imported, using RIB groups, into the VR-NAT and VR-GREEN-IN forwarding tables. This ensures that downlink traffic follows the reverse path of the uplink traffic, which is especially important when applying bi-directional and stateful services.



MS-MPC SCG

vSRX

inet.0NAT host routes

automatically added

ge-1/2/0

Green-Left192.168.10/24

Session PIC (ms-5/0/0)Gx interface to PCRF

SCG-Access- Send traffic from VR-NAT with DIP 10.169/16 to Service PIC.

- Send traffic from VR-NAT with DIP 10.168/16 to BNG (no match).- Send traffic from VR-GREEN-IN with DIP 10.169/16 to BNG due to

‘skip-services’ filter action.

VR-GREEN-INHas subscriber routes to

SCG-Access.Forwarding Table filter matches DIP 10.169/16

with action “skip-services”

Service PIC (ms-5/1/0) Subscriber flow table

PCRF Server10.255.2.2

To BNG


VR-GREEN-OUTLearns subscriber

routes via IBGP from Contrail.

Return traffic from Internet

Data path for all return traffic

ge-1/3/0xe-0/1/010.12.2.0/31

Contrail

SCG MX960

10.20.20.2 (V20)

‘Green’ Service

10.255.2.1/24

.201 .200

ms-5/2/0.1(inside)

ms-5/2/0.2(outside)

VR-NATLearns subscriber

routes to SCG-Access via import-rib

1

2

4

5

3

6 Services applied to return traffic by virtual appliance

Steer to external service

Service PIC (ms-5/1/0) Apply subscriber aware services (policing) and

steering

xe-0/0/0.20

Steered via ‘mif’ to Service PIC

7 SCG-Access VR forwards to BNG using static routes

8

Return traffic is processed as follows:

1. Return traffic from the Internet is received via inet.0.

2. The CGNAT feature on the MX Series router automatically adds host routes corresponding to the public NAT address to the forwarding table of the outside interface, or inet.0 in this case. Therefore, the return traffic is forwarded to the outside service interface of the MS-MPC.

3. NAT is removed from traffic, and the VR-NAT VR receives the traffic. Based on the destination IP address, the imported subscriber address pool routes are used to forward traffic to the SCG-Access VR

4. Based on the destination IP address the SCG-Access VR knows that the subscriber is reachable via the access interface. Because the access interface is bound to TDF, the TDF table applied to the access VR’s PFE evaluates the destination IP address and directs traffic destined to 10.169/16 to the service PIC over the mif interface. Traffic destined to 10.168/16 does not match and is routed directly back to the BNG.

5. The service PIC looks up the flow and applies any configured subscriber services, rate limiting in this case. It then directs traffic to the Out VRF that corresponds to the service chain assigned to the subscriber traffic. In this example traffic is directed to the VR-GREEN-OUT VRF.



6. The VR-GREEN-OUT VRF forwards traffic destined to the 10.169/16 subscriber to the service chain. The 10.169/16 route was initially added to the VR-GREEN-IN VRF via the import RIB group configuration mentioned above. This route was then advertised using IBGP to the Contrail controller (not shown) and subsequently advertised to the VR-GREEN-OUT VRF.

7. The traffic is received by the VR-GREEN-IN VRF. This VRF is configured with a forwarding table filter that matches the incoming downlink traffic and applies an action of skip-services. Based on the destination IP address, the imported subscriber address pool routes are used to forward traffic to the SCG-Access VR.

8. Similar to Step 4, based on the destination IP address the access VR knows that the subscriber is reachable via the access interface. However, since the traffic is marked with the skip-services action in the previous step, the TDF table in the access VR PFE is bypassed and traffic is forwarded directly to the subscriber.

One design note is the return flow of traffic in the event that CGNAT is not configured. In this case, the subscriber subnets would also be imported into inet.0. Therefore, steps 2 and 3 above are skipped, and the downlink traffic is forwarded directly to the access VR.



Solution Configuration In the following sections, the initial focus is on the devices external to the SCG and any related SCG configuration including the BNG, PCRF, and service chaining. Then the TDF is configured on the SCG, which brings together the various elements. Refer to the diagrams in the previous section when performing the configuration.

In addition to installing the SCG software, the SCG requires a corresponding version of the jmobile code.

Configuring the BNG

Configuring RADIUS Accounting on the SCG 1. On the SCG define the source of the received RADIUS Accounting message that triggers the building of

the subscriber state on the services PIC.

The RADIUS packets will be exchanged on logical interface xe-0/0/0.21, which is connected to the BNG, and is mapped to the inet.0 table. The SCG receives the RADIUS Accounting-Start messages and sends them to the session PIC.

set interfaces xe-0/0/0 vlan-tagging set interfaces xe-0/0/0 unit 21 vlan-id 21 set interfaces xe-0/0/0 unit 21 family inet address 10.21.21.2/24

2. Next, define the RADIUS client. Specify the IP address of the source of the RADIUS Accounting packets,

which corresponds to the interface IP address in the duplicating VRF on the BNG. Then specify the SCG interface that receives the RADIUS packets from the BNG. Set the RADIUS secret to match the configuration on the BNG so that the RADIUS packets are accepted. The SCG will send an RADIUS Accounting response back to the BNG.

set access radius clients BNG address 10.21.21.1/32 set access radius clients BNG source-interface xe-0/0/0.21 set access radius clients BNG source-interface ipv4-address 10.21.21.2 set access radius clients BNG accounting secret radius commit

3. Optionally enable traceoptions. The name of the traceoptions file is appended with –msXY, where X is the

session PIC slot number and Y is the session PIC number. In this example, the session PIC is on ms-5/0/0 so the traceoptions filename is radius.log-ms50.

set access radius traceoptions file radius.log set access radius traceoptions file size 10m set access radius traceoptions file files 5 set access radius traceoptions level all set access radius traceoptions flag all set access radius traceoptions client BNG

Configuring the BNG The BNG must be configured to send a duplicate RADIUS Accounting-Start packet to the SCG. This requires configuring another access profile that is referenced in a virtual router whose only purpose is to transmit the RADIUS Accounting packet. The configuration of the BNG is outside the scope of this document. Please refer to the configuration of the BNG router in the Appendix.



The BNG uses an external RADIUS server to perform authentication and obtain the name of the address pool that is used to assign an IP address to the subscriber. The RADIUS server used by the BNG to authenticate PPPoE subscribers must be configured to return the Framed-IP-Netmask attribute with a value of 255.255.255.255. The SCG reports Malformed RADIUS Request packets if this is not set. This issue may be specific to the software version used for this configuration example, please keep this in mind when testing the SCG.

Configuring the PCRF

Configuring Diameter on the SCG On the SCG, configure the Diameter session to the PCRF server. Note that using the fxp0 interface to communicate with the PCRF interface is not supported.

1. Configure the local interface on the SCG, and place it in the access VR named SCG-Access:

set interfaces ge-1/3/0 unit 0 family inet address 10.255.2.1/24 set routing-instances SCG-Access instance-type virtual-router set routing-instances SCG-Access interface ge-1/3/0.0

2. Set the origin host and realm. These parameters must match the values configured on the PCRF server. Similarly, the network-element name, for example, PCRF-Server, must match the value configured on the PCRF server. Also, set the source IP address under transport and under peer configure the IP address of the PCRF server.

set system host-name SCG set access diameter origin realm example.com set access diameter origin host SCG set access diameter network-element PCRF-Server function pcc-gx set access diameter network-element PCRF-Server peer SCG-P1 priority 1 set access diameter transport SCG-T1 address 10.255.2.1 set access diameter transport SCG-T1 routing-instance SCG-Access set access diameter peer SCG-P1 address 10.255.2.2 set access diameter peer SCG-P1 connect-actively transport SCG-T1 set access diameter peer SCG-P1 connect-actively port 3868 commit

3. Optionally enable traceoptions. Note that the name of the traceoptions file specified is appended with -

msXY where X is the session PIC slot number and Y is the session PIC number. In this example the session PIC is on ms-5/0/0 so the traceoptions filename is diameter.log-ms50.

set access diameter traceoptions file diameter.log set access diameter traceoptions file size 10m set access diameter traceoptions level all set access diameter traceoptions flag all



Configuring the PCRF Server The PCRF Server used in this example is an executable that runs in FreeBSD. The first step is to create a VM using FreeBSD (version 8.4 was used in this example). Then copy the executable and the configuration file to the server.

There are 4 sections in the configuration file:

• Transport Profile - parameters required to establish Diameter connection to the SCG. The host names and realms must match the Diameter origin configuration on the SCG.

• Subscriber mapping - map each subscriber to Subscriber Profile. In this example the subscriber’s username is used to determine the Subscriber Profile.

• Subscriber Profile - maps to one or more charging rules.

• Charging Rules - install/remove the policy rules applied to subscriber. These rules map to the PCC rules configured on the SCG.

The PCRF configuration file used in this demonstration is displayed below. At the top is the Transport Profile where the host-name, host-realm, destination-host, and destination-realm matches the configuration on the SCG. At the bottom of the file is a list of subscriber names, for example alice, followed by the Subscriber Profile. The Subscriber Profiles list one or more PCC rules that are returned to the SCG. Remember that these rules are defined on the SCG and the PCRF instructs the SCG to install or remove them for the particular subscriber session.

edit jpcrf # ********************************************************* # ******** DO NOT USE ANY TAB IN THIS CONFIG FILE ********* # ********************************************************* # ============================ TRANSPORT PROFILES ========= edit transport-profile default set port 3868 set supported-vendor-id 10415 set host-name PCRF-Server set host-realm example.com set auth-app-id 16777238 set dictionary default set protocol tcp set destination-host SCG set destination-realm example.com set watch-dog-timer 900 set server-ep 10.255.2.2 set client-ep 10.255.2.1 exit #===============SUBSCRIBER PROFILES=============== edit subscriber-profile default set event-trigger 14 set cc-request-type 1 set charging-rule-profile Install_PCCRULE-GREEN-INITIAL exit # # GREEN edit subscriber-profile GREEN set event-trigger 14



set cc-request-type 1 set charging-rule-profile Install_PCCRULE-GREEN-INITIAL exit # # BLUE edit subscriber-profile BLUE set event-trigger 14 set cc-request-type 1 set charging-rule-profile Install_PCCRULE-BLUE-INITIAL exit # # GREEN-UPDATE-TO-BLUE edit subscriber-profile GREEN-UPDATE-TO-BLUE set event-trigger 14 set re-auth-request-type 0 set charging-rule-profile Remove_PCCRULE-GREEN-INITIAL set charging-rule-profile Install_PCCRULE-BLUE-INITIAL exit # # BLUE-UPDATE-TO-BLUE edit subscriber-profile BLUE-UPDATE-TO-BLUE set event-trigger 14 set re-auth-request-type 0 set charging-rule-profile Remove_PCCRULE-BLUE-INITIAL set charging-rule-profile Install_PCCRULE-BLUE-UPDATE exit # # BLUE-UPDATE-TO-GREEN edit subscriber-profile BLUE-UPDATE-TO-GREEN set event-trigger 14 set re-auth-request-type 0 set charging-rule-profile Remove_PCCRULE-BLUE-INITIAL set charging-rule-profile Install_PCCRULE-GREEN-INITIAL exit # =========================== CHARGING RULE PROFILES ======= #------------------------------------- # GREEN #------------------------------------- edit charging-rule-profile Install_PCCRULE-GREEN-INITIAL set charging-rule-name PCCRULE-GREEN-INITIAL set charging-rule-install 1 set enable-static-gx-rules 1 exit edit charging-rule-profile Remove_PCCRULE-GREEN-INITIAL set charging-rule-name PCCRULE-GREEN-INITIAL set charging-rule-remove 1 set enable-static-gx-rules 1 exit #------------------------------------- # BLUE #------------------------------------- edit charging-rule-profile Install_PCCRULE-BLUE-INITIAL set charging-rule-name PCCRULE-BLUE-INITIAL set charging-rule-install 1 set enable-static-gx-rules 1 exit # edit charging-rule-profile Remove_PCCRULE-BLUE-INITIAL set charging-rule-name PCCRULE-BLUE-INITIAL set charging-rule-remove 1 set enable-static-gx-rules 1 exit



# # BLUE Update edit charging-rule-profile Install_PCCRULE-BLUE-UPDATE set charging-rule-name PCCRULE-BLUE-UPDATE set charging-rule-install 1 set enable-static-gx-rules 1 exit edit charging-rule-profile Remove_PCCRULE-BLUE-UPDATE set charging-rule-name PCCRULE-BLUE-UPDATE set charging-rule-remove 1 set enable-static-gx-rules 1 exit # # =========================== SUBSCRIBERS MAPPING ========== edit subscriber-provisioning map subscription_id_data alice subscriber-profile GREEN map subscription_id_data bonita subscriber-profile GREEN map subscription_id_data carlos subscriber-profile BLUE map subscription_id_data daniel subscriber-profile BLUE exit # exit



Service Chain Configuration The sections below cover the SCG and Contrail configuration required to implement the service chains that apply services to the subscriber traffic. This document assumes the reader has basic knowledge of Contrail. Contrail version 2.1 is used in this example.

SCG to Contrail The Contrail network displayed below consists of two compute nodes and one controller/configuration node. The SCG is essentially a gateway router device from the perspective of Contrail. Therefore, an IBGP session is configured between the SCG and Contrail Controller to exchange MPLS L3VPN routing information between the Green and Blue Service VRFs and the virtual networks defined in Contrail.

A simple IP underlay network running OSPF provides connectivity between all of the elements. The overlay network communication requires the use of dynamic GRE tunneling between the SCG and the Contrail compute nodes for sending and receiving traffic to and from the service chains.

There is a second MX80 router that is used to provide connectivity to an out-of-band management network. This is used, for example, to access the management interface of the vSRX firewalls that are used in the Green and Blue service chains.

R4R9S04 - Compute em1 -10.8.128.94p6p1 – 10.11.94.94

QFX3500-215

p6p1

xe-1/0/0

patch 2/4/11 to 4/6/1

ge-1/2/0

R4R9S05 - Computeem1 - 10.8.128.95p6p1 – 10.12.95.95

p6p1

R4R9S06 – Contrail Controllerem1 - 10.8.128.96p6p1 – 10.12.96.96

p6p1

xe-0/0/10

MX80 Gateway to Mgmtlo0 = 10.100.21.21

QFX3500-214

xe-0/0/8

xe-1/1/0

xe-0/0/8xe-0/0/6

10.11.21/31

10.11.12/31

10.12.21/31

11 12

21

Layer 3 Underlay Network

xe-0/0/10 xe-0/0/12

10.11.94/24 10.12.95/24 10.12.96/24

patch 2/4/12 to 4/6/2

.1.1

.0

.0

em1 em1em1

10.8.128/25

Management Network

.8

POC Lab Management Network

SCG

10.12.2/31

.0

.1 xe-0/0/20

xe-0/1/0

OSPF Area 0

patch 2/6/5 to 4/6/5

SCG - MX960Data Plane - GRE Tunnels to Contrail Compute NodesControl Plane - IBGP to Contrail Controller

10.8.128/25

Access to Internet for subscribers

OSPF Area 0

SubscribersBNG



Below is a logical view of the Contrail network:

VR-GREEN-OUT

VR-GREEN-IN

MX SCG Gateway

MX80Gateway

L3VPN-1VRF with access to lab management network

Green-Left192.168.10/24


vRouter

R4R9S05 Compute

VN-Public10.8.134/25

vRouter

R4R9S04 Compute

VR-BLUE-OUTVR-BLUE-IN

Blue-Left192.168.12/24

Blue-Right192.168.13/24

Management Network

R4R9S06 ContrailController

IBGP (inet-vpn)

XMPP

IBGP(inet-vpn)

XMPPMPLSoUDP

Tunnel between vRouters

MPLSoGRE Tunnels between vRouters and MX SCG

MPLSoGRE Tunnels between vRouters and MX80 Gateway

SCG Configuration 1. Enable tunnel services on a PFE:

set chassis fpc 0 pic 1 tunnel-services 2. Configure the loopback interface and the interface connecting to the underlay network. Set the router ID

and enable OSPF on both interfaces: set interfaces lo0 unit 0 family inet address 10.100.2.2/32 set interfaces xe-0/1/0 unit 0 family inet address 10.12.2.0/31 set routing-options router-id 10.100.2.2 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface xe-0/1/0.0



3. Configure dynamic GRE tunnels to the Contrail compute nodes:

set routing-options dynamic-tunnels dyn_tunnel1 source-address 10.100.2.2 set routing-options dynamic-tunnels dyn_tunnel1 gre set routing-options dynamic-tunnels dyn_tunnel1 destination-networks 10.11.94.94/32 set routing-options dynamic-tunnels dyn_tunnel1 destination-networks 10.12.95.95/32

4. Configure an IBGP session to the Contrail to exchange unicast routes between VRFs. Note that the local-

address must match the GRE dynamic tunnel source-address: set routing-options route-distinguisher-id 10.100.2.2 set routing-options autonomous-system 64512 set protocols bgp log-updown set protocols bgp group Contrail type internal set protocols bgp group Contrail local-address 10.100.2.2 set protocols bgp group Contrail keep all set protocols bgp group Contrail family inet-vpn unicast set protocols bgp group Contrail neighbor 10.12.96.96 commit



Configuring Contrail The Contrail controller must also be configured to peer with the SCG. In the Contrail GUI, navigate to Configure > Infrastructure > BGP Peers and click + to create a new BGP peer. The IP address must match the local address configured for the MX Series router in the previous section. In addition, the Autonomous System number must match because it is an IBGP session.



Note that the Contrail controller must have reachability to the IP address. In this example, a static route to 10.100.2.2/32 was added to the routing table of the controller.

Configuring Service Virtual Routers Create the VRFs for routing traffic to and from Contrail. For each service chain there are two VRFs, an ingress VRF where traffic from the subscriber is redirected to the left interface of the service chain, and an egress VRF that is connected to the right interface of the service chain.

The ingress VRF is configured with a forwarding table firewall filter that matches incoming return, or downlink, traffic towards the subscriber. The purpose of the filter is to instruct the access interface to skip the TDF function and forward the traffic directly to the subscriber because services have already been applied. In the egress VRF there is a default route directing traffic to the routing table that has connectivity to the core network or Internet.

Here are the VRFs for the Green service chain:

set routing-instances VR-GREEN-IN description "GREEN Service Chain - Ingress" set routing-instances VR-GREEN-IN instance-type vrf set routing-instances VR-GREEN-IN vrf-target target:64512:1001 set routing-instances VR-GREEN-IN vrf-table-label set routing-instances VR-GREEN-IN forwarding-options family inet filter input Skip-TDF set routing-instances VR-GREEN-OUT description "GREEN Service Chain - Egress" set routing-instances VR-GREEN-OUT instance-type vrf set routing-instances VR-GREEN-OUT vrf-target target:64512:1002



set routing-instances VR-GREEN-OUT vrf-table-label set routing-instances VR-GREEN-OUT routing-options static route 0.0.0.0/0 next-table VR-NAT.inet.0 For Blue service chain:

set routing-instances VR-BLUE-IN description "BLUE Service Chain - Ingress" set routing-instances VR-BLUE-IN instance-type vrf set routing-instances VR-BLUE-IN vrf-target target:64512:2001 set routing-instances VR-BLUE-IN vrf-table-label set routing-instances VR-BLUE-IN forwarding-options family inet filter input Skip-TDF set routing-instances VR-BLUE-OUT description "BLUE Service Chain - Egress" set routing-instances VR-BLUE-OUT instance-type vrf set routing-instances VR-BLUE-OUT vrf-target target:64512:2002 set routing-instances VR-BLUE-OUT vrf-table-label set routing-instances VR-BLUE-OUT routing-options static route 0.0.0.0/0 next-table VR-NAT.inet.0 The firewall filter to skip processing of return traffic destined to subscribers assigned an address from the 10.169/16 address range. Note the skip-services action:

set firewall family inet filter Skip-TDF term 1 from destination-address 10.169.0.0/16 set firewall family inet filter Skip-TDF term 1 then skip-services set firewall family inet filter Skip-TDF term 1 then accept set firewall family inet filter Skip-TDF term default then accept Create VR-NAT, which is the next-table referenced by the service egress VRFs:

set routing-instances VR-NAT instance-type virtual-router commit

Service Chain The OpenStack/Contrail configuration steps for configuring the Green service chain are listed below. The steps are similar for configuring the Blue service chain. Each service chain consists of a single vSRX. The details of installing and configuring Contrail are outside the scope of this paper.

1. Using OpenStack create a new Project called SCG. Assign the appropriate users and permissions.

2. Using Contrail create the Virtual Networks (VNs) named Green-Left and Green-Right. When creating the VN it is important to specify the Route Target that matches the corresponding VRF configuration on the SCG. For example, the Green-Left VN route target must match the VR-GREEN-IN VRF route target configured on the SCG.



3. Using Contrail, create a Service template that corresponds to L3 vSRX if one does not already exist. The Service Mode must be set to In-Network so that routes are advertised between the VNs and SCG VRFs. This is very important because it allows the default route defined in the SCGs VR-GREEN-OUT VRF to be learned by the VR-GREEN-IN VRF. Similarly, it allows the subscriber subnet (10.169/16) to be learned by the VR-GREEN-OUT VRF.

The Service template also defines the interfaces of the service appliance. In this case the interfaces Management, Left, and Right correspond to interfaces ge-0/0/[0-2] on the vSRX.



4. Create a Service Instance referencing the L3 vSRX Service Template. Map the interfaces to the

appropriate VNs. This spawns the vSRX VM.



Once created the Status should be Active. Note that for scaling and resiliency purposes, multiple service instances can be created.

5. Using Contrail, define a Service Policy to map the VNs to communicate with each other via the service instance. In this example, the service chain consists of a single vSRX firewall but in practice multiple VNF devices can be serially chained.

6. Attach the policy to the VNs:

7. In this example the management network needs to connect to the lab management network so that it can

be managed by Junos Space. To do this, allocate a floating IP address and then associate it with the management interface of the Green-Firewall. Note that the network VN-Public was previously created by a Contrail network administrator as a shared, external network that provides external connectivity to the lab management network via the MX80 gateway router.



Management of the vSRX via SSH using the allocated floating IP address is confirmed from the MX80 gateway: user@MX80-Host> show route 10.8.134.104 table L3VPN-1.inet.0 L3VPN-1.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.8.134.104/32 *[BGP/170] 00:04:01, localpref 100, from 10.12.96.96 AS path: ?, validation-state: unverified > via gr-0/0/0.32770, Push 124 user@MX80-Host> ssh [email protected] routing-instance L3VPN-1 The authenticity of host '10.8.134.104 (10.8.134.104)' can't be established. RSA key fingerprint is 9d:0b:df:e2:a9:40:a5:1d:27:8b:0d:fd:4a:65:73:29. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.8.134.104' (RSA) to the list of known hosts. Password: --- JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC root@% root@% cli root>

vSRX Once the vSRX service instance is created it can be customized. The vSRX is similar to a branch office SRX, therefore it supports Unified Threat Management (UTM) features including web filtering. In this demonstration, the vSRX corresponding to the Green service chain filters some websites that start with the letter a, and the vSRX corresponding to the Blue service chain filters some websites that start with the letter c.



To configure, first create a list of URLs to block. Then reference the list under the web-filtering configuration. The vSRX supports different methods of web filtering including local filtering as well as integration with 3rd party services including Websense and Surfcontrol. In this example, type juniper-local is used and a custom message is configured. This message is displayed to the subscriber when a website is blocked.

edit security utm set custom-objects url-pattern URLs-to-Block value http://*.amazon.com set custom-objects url-pattern URLs-to-Block value http://*.alcatel-lucent.com set custom-objects url-pattern URLs-to-Block value http://*.apple.com set custom-objects custom-url-category Green-Blacklist value URLs-to-Block set feature-profile web-filtering url-blacklist Green-Blacklist set feature-profile web-filtering type juniper-local set feature-profile web-filtering juniper-local profile Green-Profile-1 default log-and-permit set feature-profile web-filtering juniper-local profile Green-Profile-1 custom-block-message "This site is blocked. Please consider upgrading to the Blue service" set utm-policy Green-URL-Filtering web-filtering http-profile Green-Profile-1 set utm-policy Green-URL-Filtering traffic-options sessions-per-client over-limit log-and-permit Finally, reference the UTM policy in the existing security policy:

set security policies from-zone left to-zone right policy left2right then permit application-services utm-policy Green-URL-Filtering The vSRX firewall for the Blue service chain is configured similarly.



TDF Configuration

Configuring the MS-MPC Various software service packages must be applied to the session and service PICs.

1. Configure the Service Interfaces, 1 for session PIC and 1 for service PIC. Note that multiple PICs can be pooled for redundancy.

set interfaces ms-5/0/0 description "Session PIC" set interfaces ms-5/0/0 unit 0 family inet set interfaces ms-5/1/0 description "Service PIC" set interfaces ms-5/1/0 unit 0 family inet

2. Associate the TDF gateway to the session and service PICs:

set unified-edge gateways tdf TDF-1 system session-pics interface ms-5/0/0 set unified-edge gateways tdf TDF-1 system service-pics interface ms-5/1/0

3. Specify the software packages to run on the session and service PICs and then apply them:

set groups TDF-SESSION chassis fpc 5 pic 0 adaptive-services service-package extension-provider package jservices-mobile set groups TDF-SESSION chassis fpc 5 pic 0 adaptive-services service-package extension-provider syslog external any set groups TDF-SESSION chassis fpc 5 pic 0 adaptive-services service-package extension-provider syslog daemon any set groups TDF-SESSION chassis fpc 5 pic 0 adaptive-services service-package extension-provider syslog kernel any set groups TDF-SERVICE chassis fpc 5 pic 1 adaptive-services service-package extension-provider package jservices-mss set groups TDF-SERVICE chassis fpc 5 pic 1 adaptive-services service-package extension-provider package jservices-jdpi set groups TDF-SERVICE chassis fpc 5 pic 1 adaptive-services service-package extension-provider package jservices-crypto-base set groups TDF-SERVICE chassis fpc 5 pic 1 adaptive-services service-package extension-provider package jservices-pcef set groups TDF-SERVICE chassis fpc 5 pic 1 adaptive-services service-package extension-provider package jservices-hcm set groups TDF-SERVICE chassis fpc 5 pic 1 adaptive-services service-package extension-provider syslog external any set groups TDF-SERVICE chassis fpc 5 pic 1 adaptive-services service-package extension-provider syslog daemon any set groups TDF-SERVICE chassis fpc 5 pic 1 adaptive-services service-package extension-provider syslog kernel any set chassis fpc 5 pic 0 apply-groups TDF-SESSION set chassis fpc 5 pic 1 apply-groups TDF-SERVICE commit



Configuring the Access Virtual Router

Interfaces The access VR contains multiple interfaces including the access interface that receives the subscriber traffic and the mif interface that stitches traffic to the service PIC and will be configured in a future step (see TDF Domain section below). On the SCG define the access interface connected to the BNG that will be receiving subscriber traffic. Place the interface in the access VR. set interfaces xe-0/0/0 vlan-tagging set interfaces xe-0/0/0.20 vlan-id 20 set interfaces xe-0/0/0.20 family inet address 10.20.20.2/24 set routing-instances SCG-Access instance-type virtual-router set routing-instances SCG-Access interface xe-0/0/0.20

Static Routes Configure static routes in the access VR to provide connectivity back to the subscribers. set routing-instances SCG-Access routing-options static route 10.168.0.0/16 next-hop 10.20.20.1 set routing-instances SCG-Access routing-options static route 10.169.0.0/16 next-hop 10.20.20.1

Subscriber Address Pool On the access VR define which IP addresses will get steered to the TDF on the session/service PICs. In this example there are 4k PPPoE clients that are assigned an IP address in the range 10.168/16 and that must not pass through the Contrail service chains. Other PPPoE clients are assigned an address in the range 10.169/16 and that must be steered through the service chains. The BNG assigns the IP addresses based on the Framed-Pool RADIUS return attribute, which corresponds to an IP pool defined on the BNG.

edit routing-instances SCG-Access access set address-assignment address-pools POOL1 service-mode maintenance set address-assignment address-pools POOL1 family inet network 10.169.0.0/16 external-assigned set address-assignment address-pools POOL1 default-pool commit

Configuring the TDF Domain A TDF domain is a set of the subscriber management criteria that apply to the subscribers associated to that domain. The domain is defined by the access VR or logical interface on which subscriber packets arrive and the RADIUS attributes that are used to select the domain.

1. Create the TDF domain. Specify the mif interface and the access-interfaces. Instruct the TDF to attach subscribers based on incoming RADIUS Accounting Start messages and use the username to identify the session. The pool is used to determine which incoming source IP addresses are directed to the TDF by the access interface’s PFE. The domain maps to a pcef-profile that represents a set of policy, or PCC, rules and actions to be applied (see next section).

edit unified-edge gateways tdf TDF-1 set domains SCG-domain-1 pcef-profile SCG-PCEF-PROFILE-1 set domains SCG-domain-1 tdf-interface mif.0 set domains SCG-domain-1 service-mode maintenance



set domains SCG-domain-1 access-interfaces xe-0/0/0.20 set domains SCG-domain-1 subscriber-attach-method radius-accounting set domains SCG-domain-1 subscription-id subscription-id-options id-username id-components use-username set domains SCG-domain-1 immediate-accounting-response disable set domains SCG-domain-1 subscriber-address inet pool POOL1 set domains SCG-domain-1 default-local-policy flow-action drop

2. Specify the RADIUS client that will be sending the RADIUS Accounting-Start packets to the SCG. This

creates a filter on the access PFE to direct the packet to the session PIC.

top set unified-edge gateways tdf TDF-1 aaa clients BNG

3. Optionally enable traceoptions. Note that the SCG appends a string representing the session PIC to the

configured file name. For example, if the session PIC is interface ms-5/0/0 then the traceoptions file created is TDF.log-ms50.

set unified-edge gateways tdf TDF-1 traceoptions file TDF.log size 100m set unified-edge gateways tdf TDF-1 traceoptions level all set unified-edge gateways tdf TDF-1 traceoptions flag all

4. The TDF domain can be selected based on various parameter corresponding to the RADIUS Accounting

AVPs. In this example, traffic is classified to domain SCG-domain-1 based on the source IP address:

edit unified-edge gateways tdf TDF-1 set domain-selection term 1 from framed-ip-address equals 10.169.0.0/16 set domain-selection term 1 from client BNG set domain-selection term 1 then domain SCG-domain-1

Configuring the PCEF Profile The PCEF profile is the set of PCC rules that can be applied to a subscriber in the TDF domain.

In the PCEF profile:

• Specify whether policies are applied dynamically or statically.

• Specify the PCRF server to communicate with using a Diameter profile and the Diameter version.

• Specify the set of PCC rules. These rules correspond to the charging-rule-names configured on the PCRF server. Each PCC rule is essentially a packet filter where the first part specifies the match criteria, or flow-descriptions. The action of the filter is defined in pcc-action-profiles, which specify the uplink/downlink data rates and the service VRs that traffic is steered to. Note that each PCC rule is also assigned a precedence that is used when multiple rules are applied to a given subscriber session. Here is a summary of the PCC rules configured:



Service Package

PCC Rules SCG Flow Description and Rule Action FW Policy on vSRX

Basic Security

PCCRULE-GREEN-INITIAL PCCRULE-BLUE-CHANGE-TO-GREEN

Flow Descriptors = any/any (Match All Traffic) Downlink = 640k, Uplink = 384k Precedence 100 Steering: uplink VR-GREEN-IN downlink VR-GREEN-OUT

Block URLs (Green): amazon.com apple.com alcatel-lucent.com

Advanced Security

PCCRULE-BLUE-INITIAL PCCRULE-GREEN-CHANGE-TO-BLUE

Flow Descriptors = any/any Downlink = 640k, Uplink = 384k Precedence 200 Steering: uplink VR-BLUE-IN downlink VR-BLUE-OUT

Block URLs (Blue): cnn.com columbia.com cisco.com

Advanced Security with more Bandwidth

PCCRULE-BLUE-UPDATE Flow Descriptors = any/any Downlink = 7000k, Uplink=1024k Precedence 210 Steering: uplink VR-BLUE-IN downlink VR-BLUE-OUT

Block URLs (Blue): cnn.com columbia.com cisco.com

Below is a graphical depiction of the various PCC rules and services applied to two different users. The Green circle represents the Green service or Basic Security offering by the service provider. Each Blue circle corresponds to traffic going through the Blue service chain, corresponding to an Advanced Security service provider offering, with two tiers of bandwidth. Again, this is a basic example as only one rule is applied to a subscriber at any given time.

Rate Limit all traffic 640k/384k

‘Green’ Service Chain

Rate Limit all traffic 640k/384k

‘Blue’ Service Chain

Rate Limit all traffic 7M/1M

‘Blue’ Service Chain

The corresponding SCG CLI configuration is as follows: top edit unified-edge pcef set profiles SCG-PCEF-PROFILE-1 unresolved-flow-action forward set profiles SCG-PCEF-PROFILE-1 dynamic-policy-control pcc-rules PCCRULE-GREEN-INITIAL precedence 100



set profiles SCG-PCEF-PROFILE-1 dynamic-policy-control pcc-rules PCCRULE-GREEN-CHANGE-TO-BLUE precedence 105 set profiles SCG-PCEF-PROFILE-1 dynamic-policy-control pcc-rules PCCRULE-BLUE-INITIAL precedence 200 set profiles SCG-PCEF-PROFILE-1 dynamic-policy-control pcc-rules PCCRULE-BLUE-UPDATE precedence 210 set profiles SCG-PCEF-PROFILE-1 dynamic-policy-control pcc-rules PCCRULE-BLUE-CHANGE-TO-GREEN precedence 220 set profiles SCG-PCEF-PROFILE-1 dynamic-policy-control diameter-profile SCG-GX-PROFILE-1 set profiles SCG-PCEF-PROFILE-1 dynamic-policy-control release r9 set flow-descriptions SDF_DNS direction both set flow-descriptions SDF_DNS protocol 17 set flow-descriptions SDF_DNS remote-ports 53 set flow-descriptions SDF_ICMP direction both set flow-descriptions SDF_ICMP protocol 1 set flow-descriptions SDF_any-any direction both set flow-descriptions SDF_port443 direction both set flow-descriptions SDF_port443 remote-ports 443 set flow-descriptions SDF_port80-8080 direction both set flow-descriptions SDF_port80-8080 protocol 6 set flow-descriptions SDF_port80-8080 remote-ports 80 set flow-descriptions SDF_port80-8080 remote-ports 8080 set pcc-action-profiles SCG-BLUE-INITIAL-ACTION maximum-bit-rate uplink 384 set pcc-action-profiles SCG-BLUE-INITIAL-ACTION maximum-bit-rate downlink 640 set pcc-action-profiles SCG-BLUE-INITIAL-ACTION burst-size uplink 15000 set pcc-action-profiles SCG-BLUE-INITIAL-ACTION burst-size downlink 150000 set pcc-action-profiles SCG-BLUE-INITIAL-ACTION steering routing-instance uplink VR-BLUE-IN set pcc-action-profiles SCG-BLUE-INITIAL-ACTION steering routing-instance downlink VR-BLUE-OUT set pcc-action-profiles SCG-BLUE-UPDATE-ACTION maximum-bit-rate uplink 1024 set pcc-action-profiles SCG-BLUE-UPDATE-ACTION maximum-bit-rate downlink 7000 set pcc-action-profiles SCG-BLUE-UPDATE-ACTION burst-size uplink 23000 set pcc-action-profiles SCG-BLUE-UPDATE-ACTION burst-size downlink 250000 set pcc-action-profiles SCG-BLUE-UPDATE-ACTION steering routing-instance uplink VR-BLUE-IN set pcc-action-profiles SCG-BLUE-UPDATE-ACTION steering routing-instance downlink VR-BLUE-OUT set pcc-action-profiles SCG-GREEN-INITIAL-ACTION maximum-bit-rate uplink 384 set pcc-action-profiles SCG-GREEN-INITIAL-ACTION maximum-bit-rate downlink 640 set pcc-action-profiles SCG-GREEN-INITIAL-ACTION burst-size uplink 15000 set pcc-action-profiles SCG-GREEN-INITIAL-ACTION burst-size downlink 150000 set pcc-action-profiles SCG-GREEN-INITIAL-ACTION steering routing-instance uplink VR-GREEN-IN set pcc-action-profiles SCG-GREEN-INITIAL-ACTION steering routing-instance downlink VR-GREEN-OUT set pcc-rules PCCRULE-BLUE-CHANGE-TO-GREEN from flows SDF_any-any set pcc-rules PCCRULE-BLUE-CHANGE-TO-GREEN then pcc-action-profile SCG-GREEN-INITIAL-ACTION set pcc-rules PCCRULE-BLUE-INITIAL from flows SDF_any-any set pcc-rules PCCRULE-BLUE-INITIAL then pcc-action-profile SCG-BLUE-INITIAL-ACTION set pcc-rules PCCRULE-BLUE-UPDATE from flows SDF_any-any set pcc-rules PCCRULE-BLUE-UPDATE then pcc-action-profile SCG-BLUE-UPDATE-ACTION set pcc-rules PCCRULE-GREEN-CHANGE-TO-BLUE from flows SDF_any-any set pcc-rules PCCRULE-GREEN-CHANGE-TO-BLUE then pcc-action-profile SCG-BLUE-INITIAL-ACTION set pcc-rules PCCRULE-GREEN-INITIAL from flows SDF_any-any set pcc-rules PCCRULE-GREEN-INITIAL then pcc-action-profile SCG-GREEN-INITIAL-ACTION Configure the Diameter profile referenced by the PCEF profile: top edit unified-edge diameter-profiles set gx-profile SCG-GX-PROFILE-1 targets t1 destination-realm example.com set gx-profile SCG-GX-PROFILE-1 targets t1 priority 1 set gx-profile SCG-GX-PROFILE-1 targets t1 network-element PCRF-Server



Configuring the Service PIC The service PIC was defined in a previous step (see Configuring the MS-MPC on page 28).

1. To complete the configuration, add the service PIC to the access VR.

top set routing-instances SCG-Access interface ms-5/1/0

2. Place the mif interface in the access VR. The mif interface is a logical interface that is used for stitching traffic between the access VR and the service PIC.

set routing-instances SCG-Access interface mif.0

To direct traffic to the service PIC, a service set is defined and applied to the mif interface, which is also in the access VR (see TDF Configuration on page 28). The service set can optionally contain the configuration for DPI and HTTP Content Management (HCM) related features. Note that these features are not included in this example.

3. In the service set configuration, enable subscriber-awareness and specify the service PIC. The PCEF profile is empty in this case meaning that profile is obtained from the external PCEF server.

set services service-set SCG-SERVICESET-1 service-set-options subscriber-awareness set services service-set SCG-SERVICESET-1 pcef-profile pcef-default set services service-set SCG-SERVICESET-1 interface-service service-interface ms-5/1/0 set services pcef profile pcef-default

4. Configure the mif interface and apply the service set to it. Note that an interface style service set is used in this configuration (as opposed to next-hop style). set interfaces mif unit 0 clear-dont-fragment-bit set interfaces mif unit 0 family inet service input service-set SCG-SERVICESET-1 set interfaces mif unit 0 family inet service output service-set SCG-SERVICESET-1 commit

Configuring Source NAT In this example port based source NAT is performed by a dedicated PIC on the MS-MPC. All subscriber traffic that goes through a service chain is processed by this PIC.

1. Define a pair of inside/outside service interfaces:

set interfaces ms-5/2/0 description "For NAT" set interfaces ms-5/2/0 unit 1 family inet set interfaces ms-5/2/0 unit 1 service-domain inside set interfaces ms-5/2/0 unit 2 family inet set interfaces ms-5/2/0 unit 2 service-domain outside

2. Place the inside interface in the VR-NAT virtual router. The outside interface is in the inet.0 table by

default. Also define a static default route to force all traffic to the MS-MPC PIC:



set routing-instances VR-NAT instance-type virtual-router set routing-instances VR-NAT interface ms-5/2/0.1 set routing-instances VR-NAT routing-options static route 0.0.0.0/0 next-hop ms-5/2/0.1

3. Configure NAT using these interfaces. Define the source NAT address pool, NAT rule, and service set:

set services nat pool Nat-Pool-1 address 192.168.186.20/32 set services nat pool Nat-Pool-1 port automatic random-allocation set services nat rule Nat-Rule-1 match-direction input set services nat rule Nat-Rule-1 term 10 from source-address 10.168.0.0/16 set services nat rule Nat-Rule-1 term 10 from source-address 10.169.0.0/16 set services nat rule Nat-Rule-1 term 10 then translated source-pool Nat-Pool-1 set services nat rule Nat-Rule-1 term 10 then translated translation-type napt-44 set services service-set SS-NAT nat-rules Nat-Rule-1 set services service-set SS-NAT next-hop-service inside-service-interface ms-5/2/0.1 set services service-set SS-NAT next-hop-service outside-service-interface ms-5/2/0.2 commit

Note that the service outside interface resides in inet.0. When NAT is performed, a route corresponding to the NAT IP address is placed in this route table. Therefore, return traffic is automatically routed back to the VR-NAT VR.

Configuring Non-SCG Subscribers In this example there are a set of PPPoE subscribers from the Spirent Tester to which we do not want to apply any services except for NAT on the MS-MPC. Traffic from these users enters the access VR on interface xe-0/0/0.20. They are steered using a forwarding table filter to a separate VR called VR-NAT. set firewall family inet filter Only-NAT term 1 from source-address 10.168.0.0/16 set firewall family inet filter Only-NAT term 1 then routing-instance VR-NAT set firewall family inet filter Only-NAT term 1 then accept set firewall family inet filter Only-NAT term default then accept set routing-instances SCG-Access forwarding-options family inet filter input Only-NAT commit Once the traffic reaches the VR-NAT virtual router source NAT is applied using the configuration in the Source NAT section above.

Configuring the Core VR The core VR is the global inet.0 table.

1. Configure the interface connected towards Internet. Proxy ARP is enabled in conjunction with NAT function:

set interfaces ge-1/2/0 description "To Internet DMZ" set interfaces ge-1/2/0 unit 0 proxy-arp set interfaces ge-1/2/0 unit 0 family inet address 192.168.186.10/24



2. Add a default route pointing to the Internet.

set routing-options static route 0.0.0.0/0 next-hop 192.168.186.254 commit

Distributing Subscriber Routes using RIB Groups As described in the Operational Overview section, it is required to populate the service In VRFs and the VR-NAT VR with routes corresponding to the subscribers. This allows return, or downlink, traffic from the Internet to be properly forwarded by the SCG to the subscribers.

1. The subscriber routes are first defined in the access VR as static routes. Place these static routes into a RETURN-TO-CLIENT RIB group along with the access VR’s interface routes for next-hop resolution.

set routing-instances SCG-Access routing-options rib SCG-Access.inet.0 static rib-group RETURN-TO-CLIENT set routing-instances SCG-Access routing-options interface-routes rib-group inet RETURN-TO-CLIENT

2. Redistribute the routes to the In VRFs for the Green and Blue service chains as well as the VR-NAT virtual

router:

set routing-options rib-groups RETURN-TO-CLIENT import-rib [SCG-Access.inet.0 VR-GREEN-IN.inet.0 VR-BLUE-IN.inet.0 VR-NAT.inet.0]

3. Let’s fine tune the configuration by defining a route policy such that the subnets corresponding to the

directly connected PCRF network are not redistributed to the service VRFs since they are not needed. Once the policy is created apply it to the RIB group as an import-policy:

edit policy-options set policy-statement Policy-Subscriber-Routes term Reject-PCRF-Network from protocol local set policy-statement Policy-Subscriber-Routes term Reject-PCRF-Network from protocol direct set policy-statement Policy-Subscriber-Routes term Reject-PCRF-Network from route-filter 10.255.2.0/24 orlonger set policy-statement Policy-Subscriber-Routes term Reject-PCRF-Network then reject set policy-statement Policy-Subscriber-Routes term Accept-All-Other then accept top set routing-options rib-groups RETURN-TO-CLIENT import-policy Policy-Subscriber-Routes commit

Making Configuration Changes The astute reader may have noticed that various portions of the SCG configuration contained a service-mode parameter. These parameters must be activated when making any configuration changes to the TDF domain and deactivated once the changes are complete. Now that the configuration above has been completed and committed, the SCG can be taken out of maintenance mode: deactivate routing-instances SCG-Access access address-assignment address-pools POOL1 service-mode deactivate unified-edge gateways tdf TDF-1 domains SCG-domain-1 service-mode commit



If any changes need to be made to the TDF domain, then re-activate these parameters and commit the changes: activate routing-instances SCG-Access access address-assignment address-pools POOL1 service-mode activate unified-edge gateways tdf TDF-1 domains SCG-domain-1 service-mode commit

Verification Initial Verification

Verifying the MS-MPC State Both the session and service PICs must be Active: user@host> show unified-edge tdf system interfaces Gateway: TDF-1 Interfaces Interface Members Operational Redundancy Type State Role ms-5/0/0 Session-PIC Active Standalone ms-5/1/0 Service-PIC Active Standalone

Verifying the PCRF From the SCG verify that the session to the PCRF is active: user@host> show unified-edge tdf diameter peer status Name FPC/PIC Address Port State Duration Watchdog SCG-P1 5/0 10.255.2.2 3868 I-Open 00:44:13 okay On the PCRF server, start the PCRF simulator and load the configuration using the commands below. The Diameter connection is up when the output Capabilities are exchanged. Connection up is displayed: root@pcrf-server:/usr/home/user/pcrf # ./jtdf-pcrf.exe mkdir: /var/jmobisim-logs/: File exists Signal block successful.JMOBISIM R2.0 build ** 18:29:33, May 14 2015 **Copyright (c) 2002-2003 Juniper Networks All rights reserved JSIM>load config pcrf-poc-lab.cfg JSIM>edit jpcrf JMS:JPCRF#start-pcrf Base Diameter is initialized JPCRF is initialized JMS:JPCRF# Capabilities exchanged. Connection up



Verifying BGP between SCG and Contrail From the SCG, verify that the BGP session to the Contrail controller is Established and that routes are learned for the corresponding to the Green and Blue service VRFs: user@host> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 126 126 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.12.96.96 64512 243 180 0 0 1:13:46 Establ bgp.l3vpn.0: 126/126/126/0 VR-BLUE-IN.inet.0: 3/3/3/0 VR-BLUE-OUT.inet.0: 5/5/5/0 VR-GREEN-IN.inet.0: 4/4/4/0 VR-GREEN-OUT.inet.0: 6/6/6/0

Verifying the Service In VRF Verify that the In service VRFs contain a default route pointing towards the Contrail; that is, via the GRE tunnel. This default route was learned via the IBGP session to the Contrail control node.

user@host> show route table VR-GREEN-IN.inet.0 0.0.0.0/0 exact VR-GREEN-IN.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:22:01, localpref 100, from 10.12.96.96 AS path: ?, validation-state: unverified > via gr-0/1/0.32769, Push 131 user@host> show route table VR-BLUE-IN.inet.0 0.0.0.0/0 exact VR-BLUE-IN.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:34:22, localpref 100, from 10.12.96.96 AS path: ?, validation-state: unverified > via gr-0/1/0.32769, Push 97 Looking at the details of the default route in the VR-GREEN-IN VRF shows that the IP address of the next-hop is 10.12.95.95. This is the IP address of the Contrail compute node that is hosting the VM that represents the service chain. For example, the Green vSRX.

user@host> show route table VR-GREEN-IN.inet.0 0.0.0.0/0 exact detail VR-GREEN-IN.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) 0.0.0.0/0 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 10.12.95.95:30 Next hop type: Indirect Address: 0x97383a0 Next-hop reference count: 12 Source: 10.12.96.96 Next hop type: Router, Next hop index: 773 Next hop: via gr-0/1/0.32769, selected



Label operation: Push 131 Label TTL action: prop-ttl Load balance label: Label 131: None; Session Id: 0x198 Protocol next hop: 10.12.95.95 Label operation: Push 131 Label TTL action: prop-ttl Load balance label: Label 131: None; Indirect next hop: 0x95f0550 1048582 INH Session ID: 0x199 State: <Secondary Active Int Ext ProtectionCand> Local AS: 64512 Peer AS: 64512 Age: 19:35 Metric2: 0 Validation State: unverified Task: BGP_64512.10.12.96.96+48766 Announcement bits (2): 0-KRT 2-RT AS path: ? AS path: Recorded Communities: target:64512:1001 target:64512:8000034 unknown iana 30c unknown iana 30c unknown iana 30c unknown type 8071 value fc00:15 Import Accepted VPN Label: 131 Localpref: 100 Router ID: 10.12.96.96 Primary Routing Table bgp.l3vpn.0 Because this MPLS L3VPN route was learned via BGP the next-hop is resolved in the ‘inet.3’ table. In this case the next-hop points to the dynamic GRE tunnel:

user@host> show route 10.12.95.95 table inet.3 inet.3: 2 destinations, 4 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.12.95.95/32 *[Tunnel/300] 00:37:21 > via gr-0/1/0.32769 [Tunnel/300] 13:17:15 Tunnel Next, verify that the In service VRFs contain a route to towards the subscriber network 10.169/16 and the access VR local interfaces required to send traffic to the BNG. These routes were imported to the VRF using a RIB group (see Distributing Subscriber Routes using RIB Groups on page 35). user@host> show route table VR-GREEN-IN.inet.0 10.169.0.0/16 VR-GREEN-IN.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.169.0.0/16 *[Static/5] 00:08:15 > to 10.20.20.1 via xe-0/0/0.20 user@host> show route table VR-GREEN-IN.inet.0 10.20.20.1 VR-GREEN-IN.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.20.20.0/24 *[Direct/0] 00:08:26 > via xe-0/0/0.20 user@host> show route table VR-BLUE-IN.inet.0 10.169.0.0/16



VR-BLUE-IN.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.169.0.0/16 *[Static/5] 00:08:51 > to 10.20.20.1 via xe-0/0/0.20 user@host> show route table VR-BLUE-IN.inet.0 10.20.20.1 VR-BLUE-IN.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.20.20.0/24 *[Direct/0] 00:09:01 > via xe-0/0/0.20

Verifying the Service Out VRFs Verify that the Out service VRFs contain the 10.169/16 route towards the subscribers. These routes were learned via the IBGP session to the Contrail control node, therefore the next-hop is the GRE tunnel towards the service chain:

user@host> show route table VR-GREEN-OUT.inet.0 10.169/16 VR-GREEN-OUT.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.169.0.0/16 *[BGP/170] 00:24:55, localpref 100, from 10.12.96.96 AS path: ?, validation-state: unverified > via gr-0/1/0.32769, Push 134 user@host> show route table VR-BLUE-OUT.inet.0 10.169/16 VR-BLUE-OUT.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.169.0.0/16 *[BGP/170] 00:10:01, localpref 100, from 10.12.96.96 AS path: ?, validation-state: unverified > via gr-0/1/0.32769, Push 100

Verifying Initial Subscribers

Verifying RADIUS Start a single PPPoE session from the Windows 7 Host with username alice. The RADIUS log and statistics should indicate that the SCG is sending Accounting Responses. There should be no errors. user@host> show unified-edge tdf aaa radius client statistics Client: BNG Gateway Name: TDF-1 Accounting Requests: 2 Start: 1 Stop: 0 Interim: 1 On: 0 Off: 0 Accounting Responses: 2 Start: 1



Stop: 0 Interim: 1 On: 0 Off: 0 Duplicate Requests: 0 Malformed Requests: 0 Bad Authenticators: 0 Unknown Types: 0 Dropped Packets: 0 The corresponding radius-log file output is attached to this document.

Verifying the TDF From TDF perspective the subscriber should be present. For user alice the initial rule name is PCCRULE-GREEN-INITIAL based on the configuration (see PCEF configuration section above):

user@host> show unified-edge tdf subscribers Gateway: TDF-1 MSISDN/name V4 Address V6 Address NAS-IP-Address Domain alice 10.169.0.29 None 10.21.21.1 SCG-domain-1 user@host> show unified-edge tdf subscribers detail Gateway: TDF-1 Subscriber Information: Subscriber Type : IP IMSI : None MSISDN/Username : alice IMEI : None State : Established Session Duration: 000000 hrs 04 mins 37 secs Domain : SCG-domain-1 Data VRF : SCG-Access NAS-IP-Addr: 10.21.21.1 NAS-ID : BNG APN name : None V4 Address : 10.169.0.29 V6 Address : None Session PIC: 5 /0 (FPC/PIC) Service PIC: 5 /1 (FPC/PIC) PCRF Event Triggers : None Revalidation due in : N/A Idle Timeout: 0 min Subscriber MBR: Uplink (kbps): 0 Downlink (kbps): 0 Subscriber burst: Uplink (bytes): 0 Downlink (bytes): 0 PCC Profile Name : SCG-PCEF-PROFILE-1 PCC Rule Information: Rule Name: PCCRULE-GREEN-INITIAL Type : Static Associated Rule Base: None Precedence: 100 Status: Active Activation due in : N/A Deactivation due in: N/A QoS Parameters: MBR Uplink (kbps): 384 MBR Downlink (kbps): 640 Burst size Uplink (bytes): 15000 Burst size Downlink (bytes): 150000 Charging Attributes: Rating Group: 0 Service ID: 0 Gating Status: enable-both AF Charging Id: None Charging Method: None Metering Method: None Usage Monitoring Key : NULL Services Attributes: Steering VRF Uplink: VR-GREEN-IN Downlink: VR-GREEN-OUT Logging Rule Name : NULL



Filter Attributes: Remote IP/Mask: any/any Protocol: any Direction: Both Local Ports: any Remote Ports: any For reference, a copy of the TDF traceoptions log is attached to this document. The log shows: • The session PIC receives the RADIUS accounting request

• The subscriber is associated with the domain SCG-domain-1

• The username, ex. alice, and IP address is decoded

• The service PIC is selected

• The PCEF Profile is selected

• The PCC Rule is applied in service PIC

• The subscriber is established

Verifying the PCRF - DIAMETER On the PCRF you can verify that the user alice is successfully mapped to the GREEN profile:

JMS:JPCRF#show session all Session-ID Subscription-ID State(0-inactive) Subscriber_Profile -------------------------------------------------------------------------------------------------------------- VP-05-0-SCG;0;1;1e00000c-0-0-003 alice (SUB-ID-DATA) 1 GREEN Total sessions: 1 For reference, the Diameter traceoptions log file is attached to this document.

Now, connect the second user carlos who is mapped to the Blue service. user@host> show unified-edge tdf subscribers Gateway: TDF-1 MSISDN/name V4 Address V6 Address NAS-IP-Address Domain alice 10.169.0.29 None 10.21.21.1 SCG-domain-1 carlos 10.169.0.30 None 10.21.21.1 SCG-domain-1 User carlos is initially mapped to the PCC rule named PCCRULE-BLUE-INITIAL. user@host> show unified-edge tdf subscribers v4-addr 10.169.0.30 routing-instance SCG-Access detail | match "pcc|blue" PCC Profile Name : SCG-PCEF-PROFILE-1 PCC Rule Information: Rule Name: PCCRULE-BLUE-INITIAL Steering VRF Uplink: VR-BLUE-IN Downlink: VR-BLUE-OUT



Verify Connectivity

Green Confirm via web browser that user alice cannot access http://apple.com and/or http://amazon.com.

Perform a speed test to verify that the subscriber traffic conforms to the configured uplink and downlink speeds associated with the applied policy. In this case the initial Green policy is configured for 640 kbps downlink and 384 kbps uplink. The test was performed using the website http://verizon.com/speedtest

Blue Confirm via web browser that user carlos cannot access http://cnn.com , http://columbia.com, and/or http://cisco.com. Perform a speed test to verify that the uplink and downlink speeds correspond to the initial Blue policy.

Use Case - Change Service User alice changes service from Green to Blue.

http://apple.com/

http://amazon.com/

http://verizon.com/speedtest

http://cnn.com/

http://columbia.com/

http://cisco.com/



In the lab the policy can be changed dynamically via Diameter using the PCRF simulator tool. Note, starting with SCG release 14.1X55-D25, a RADIUS CoA message can also be used to change policy dynamically.

First list the sessions in the PCRF tool to determine the Session-ID:

JMS:JPCRF#show se all Session-ID Subscription-ID State(0-inactive) Subscriber_Profile ------------------------------------------------------------------------------------------------------------------------------------ VP-05-0-SCG;0;8;1e00000e-0-0-003 carlos (SUB-ID-DATA) 1 BLUE VP-05-0-SCG;0;1;1e00000c-0-0-003 alice (SUB-ID-DATA) 1 GREEN Total sessions: 2 Next, issue the command to update the user session from service Green to service Blue:

JMS:JPCRF#send re-auth-request session-id VP-05-0-SCG;0;1;1e00000c-0-0-003 subscriber_profile GREEN-UPDATE-TO-BLUE Verify that the user alice is now using the rule PCCRULE-BLUE-INITIAL:

user@host> show unified-edge tdf subscribers v4-addr 10.169.0.29 routing-instance SCG-Access detail | find Rule PCC Rule Information: Rule Name: PCCRULE-BLUE-INITIAL Type : Static Associated Rule Base: None Precedence: 200 Status: Active Activation due in : N/A Deactivation due in: N/A QoS Parameters: MBR Uplink (kbps): 384 MBR Downlink (kbps): 640 Burst size Uplink (bytes): 15000 Burst size Downlink (bytes): 150000 Charging Attributes: Rating Group: 0 Service ID: 0 Gating Status: enable-both AF Charging Id: None Charging Method: None Metering Method: None Usage Monitoring Key : NULL Services Attributes: Steering VRF Uplink: VR-BLUE-IN Downlink: VR-BLUE-OUT Logging Rule Name : NULL Filter Attributes: Remote IP/Mask: any/any Protocol: any Direction: Both Local Ports: any Remote Ports: any <snip> Since alice is now in the Blue service, it was verified that she can now access the site http://amazon.com but can’t access http://cisco.com.

http://amazon.com/

http://cisco.com/



Use Case - Upgrade Existing Service User carlos has subscribed to the initial Blue service. He now wants more bandwidth and will upgrade his Blue service.

From the perspective of the SCG, this means that the policy applied to the subscriber must change from PCCRULE-BLUE-INITIAL to PCCRULE-BLUE-UPGRADE. Currently the rule PCCRULE-BLUE-INITIAL is applied to user carlos

user@host> show unified-edge tdf subscribers detail v4-addr 10.169.0.30 routing-instance SCG-Access | find Rule PCC Rule Information: Rule Name: PCCRULE-BLUE-INITIAL Type : Static Associated Rule Base: None Precedence: 200 Status: Active Activation due in : N/A Deactivation due in: N/A QoS Parameters: MBR Uplink (kbps): 384 MBR Downlink (kbps): 640 Burst size Uplink (bytes): 15000 Burst size Downlink (bytes): 15000 Charging Attributes: Rating Group: 0 Service ID: 0 Gating Status: enable-both AF Charging Id: None Charging Method: None Metering Method: None Usage Monitoring Key : NULL Services Attributes: Steering VRF Uplink: VR-BLUE-IN Downlink: VR-BLUE-OUT Logging Rule Name : NULL Filter Attributes: Remote IP/Mask: any/any Protocol: any Direction: Both Local Ports: any Remote Ports: any <snip> Issue the following commands on the PCRF server to update the service:

JMS:JPCRF#show se all Session-ID Subscription-ID State(0-inactive) Subscriber_Profile ------------------------------------------------------------------------------------------------------------------------------------ VP-05-0-SCG;0;8;1e00000e-0-0-003 carlos (SUB-ID-DATA) 1 BLUE VP-05-0-SCG;0;1;1e00000c-0-0-003 alice (SUB-ID-DATA) 1 GREEN-UPDATE-TO-BLUE Total sessions: 2 JMS:JPCRF#sen re-auth-request session-id VP-05-0-SCG;0;8;1e00000e-0-0-003 subscriber_profile BLUE-UPDATE-TO-BLUE



The TDF details now shows that the rule has been updated:

user@host> show unified-edge tdf subscribers detail v4-addr 10.169.0.38 routing-instance SCG-Access | find Rule PCC Rule Information: Rule Name: PCCRULE-BLUE-UPDATE Type : Static Associated Rule Base: None Precedence: 210 Status: Active Activation due in : N/A Deactivation due in: N/A QoS Parameters: MBR Uplink (kbps): 1024 MBR Downlink (kbps): 7000 Burst size Uplink (bytes): 15000 Burst size Downlink (bytes): 15000 Charging Attributes: Rating Group: 0 Service ID: 0 Gating Status: enable-both AF Charging Id: None Charging Method: None Metering Method: None Usage Monitoring Key : NULL Services Attributes: Steering VRF Uplink: VR-BLUE-IN Downlink: VR-BLUE-OUT Logging Rule Name : NULL Filter Attributes: Remote IP/Mask: any/any Protocol: any Direction: Both Local Ports: any Remote Ports: any Data plane statistics : Run the speed test to validate that the bandwidth has been upgraded:



Conclusion This configuration example demonstrates the basic function of SCG including identifying subscribers and applying custom services to their traffic flows, applying services using a combination of the MS-MPC and Contrail service chains, interacting with a PCRF server to initially obtain the policies to be applied to each subscriber, and using PCRF to update a subscriber’s service level in real-time.

A successful deployment of the SCG on the MX Series router requires careful planning. The configuration includes provisioning the SCG on the MX Series router itself as well as the other components including the BNG, PCRF, and Contrail. The goal is to provide a working example that can serve as a foundation for better understanding the SCG, producing similar configurations, and for building upon a baseline configuration to perform additional tests. Additional areas for testing include the DPI and HTTP content management services, introducing other VNFs into the service chains, and scaling the number of subscribers.



Appendix A – BNG, SCG, vSRX Configuration BNG:

version 13.3R6.5; groups { re0 { system { host-name router; domain-name host.example1.com; domain-search [ host.example1.com example1.com example2.com ]; backup-router 10.8.2.254 destination 0.0.0.0/0; time-zone America/New_York; root-authentication { encrypted-password "$ABC123"; ## SECRET-DATA } name-server { 10.8.4.105; } login { user user2 { uid 2006; class super-user; authentication { encrypted-password "$ABC123"; ## SECRET-DATA } } } services { ftp; ssh; telnet; } ntp { server 10.8.4.105; } } interfaces { fxp0 { unit 0 { family inet { address 10.8.2.132/24; address 10.8.2.134/24 { master-only; } } } } } routing-options { static { route 10.8.0.0/16 next-hop 10.8.2.254; route 172.16.0.0/12 next-hop 10.8.2.254; } } } re1 { system { host-name router; domain-name host.example1.com; domain-search [ host.example1.com example1.com example2.com ]; backup-router 10.8.2.254 destination 0.0.0.0/0; time-zone America/New_York; root-authentication { encrypted-password "$ABC123"; ## SECRET-DATA } name-server { 10.8.4.105; } login { user user1 { class super-user; authentication {

encrypted-password "$ABC123"; ## SECRET-DATA } } } services { ftp; ssh; telnet; } ntp { server 10.8.4.105; } } interfaces { fxp0 { unit 0 { family inet { address 10.8.2.133/24; address 10.8.2.134/24 { master-only; } } } } } routing-options { static { route 10.8.0.0/16 next-hop 10.8.2.254; route 172.16.0.0/12 next-hop 10.8.2.254; } } } } apply-groups [ re0 re1 ]; dynamic-profiles { auto-vlan { interfaces { demux0 { unit "$junos-interface-unit" { no-traps; proxy-arp; vlan-id "$junos-vlan-id"; demux-options { underlying-interface "$junos-interface-ifd-name"; } family inet { mac-validate loose; unnumbered-address lo0.0; } family pppoe { duplicate-protection; dynamic-profile prod-pppoe-base; short-cycle-protection; } } } } } auto-stacked-vlan { interfaces { demux0 { unit "$junos-interface-unit" { demux-source inet; no-traps; proxy-arp; vlan-tags outer "$junos-stacked-vlan-id" inner "$junos-vlan-id"; demux-options { underlying-interface "$junos-interface-ifd-name"; } family inet { mac-validate loose; unnumbered-address lo0.0; } family pppoe { duplicate-protection;



dynamic-profile prod-pppoe-base; max-sessions 1; short-cycle-protection; } } } } } prod-pppoe-base { interfaces { pp0 { unit "$junos-interface-unit" { ppp-options { chap; } pppoe-options { underlying-interface "$junos-underlying-interface"; server; } keepalives interval 5; family inet { unnumbered-address lo0.0; } } } } } } system { host-name BNG; services { ftp; ssh { max-sessions-per-connection 32; } } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } } commit synchronize; processes { general-authentication-service { traceoptions { file radius.log size 10m; flag all; } } } } access-profile AAA; interfaces { xe-1/0/0 { vlan-tagging; unit 20 { vlan-id 20; family inet { address 10.20.20.1/24; } } unit 21 { vlan-id 21; family inet { address 10.21.21.1/24; } } } xe-1/1/0 { description "pppoe & dhcp"; hierarchical-scheduler maximum-hierarchy-levels 2; flexible-vlan-tagging; auto-configure {

stacked-vlan-ranges { dynamic-profile auto-stacked-vlan { accept [ dhcp-v4 pppoe ]; ranges { any,any; } } } vlan-ranges { dynamic-profile auto-vlan { accept pppoe; ranges { any; } } } } mtu 2016; encapsulation flexible-ethernet-services; } xe-1/2/0 { description "pppoe & dhcp"; hierarchical-scheduler maximum-hierarchy-levels 2; flexible-vlan-tagging; auto-configure { stacked-vlan-ranges { dynamic-profile auto-stacked-vlan { accept [ dhcp-v4 pppoe ]; ranges { any,any; } } } vlan-ranges { dynamic-profile auto-vlan { accept pppoe; ranges { any; } } } } mtu 2016; encapsulation flexible-ethernet-services; } lo0 { unit 0 { family inet { address 10.100.1.1/32; } } unit 1 { description "loopback for RADIUS Accounting duplication"; family inet { address 10.1.1.1/32; } } } } routing-options { static { route 0.0.0.0/0 next-hop 10.20.20.2; } rib-groups { accounting-source { import-rib [ duplicate-accounting.inet.0 inet.0 ]; } } router-id 1.1.1.1; autonomous-system 64512; forwarding-table { export load-balance-per-packet; } } policy-options { policy-statement load-balance-per-packet { term 1 { then { load-balance per-packet;



} } } } access { profile AAA { authentication-order radius; radius { authentication-server 10.8.158.250; accounting-server 10.8.158.250; } radius-server { 10.8.158.250 { port 1812; secret "$ABC123"; ## SECRET-DATA timeout 10; retry 3; source-address 10.8.2.134; } } accounting { order radius; immediate-update; statistics volume-time; duplication; duplication-vrf { vrf-name duplicate-accounting; } } } profile DUP-ACCT { accounting-order radius; radius { accounting-server 10.21.21.2; } radius-server { 10.21.21.2 { secret "$ABC123"; ## SECRET-DATA source-address 10.21.21.1; } } accounting { order radius; statistics volume-time; } } address-assignment { pool pool1 { family inet { network 10.168.0.0/16; range r1 { low 10.168.0.1; high 10.168.16.254; } dhcp-attributes { name-server { 8.8.8.8; } } xauth-attributes { primary-dns 8.8.4.4/32; } } } pool pool2 { family inet { network 10.169.0.0/16; range r1 { low 10.169.0.1; high 10.169.16.253; } dhcp-attributes { name-server { 8.8.8.8; } } xauth-attributes { primary-dns 8.8.4.4/32; } } }

} radius-options { revert-interval 0; request-rate 4000; } } routing-instances { duplicate-accounting { instance-type virtual-router; access-profile DUP-ACCT; interface xe-1/0/0.21; interface lo0.1; routing-options { interface-routes { rib-group inet accounting-source; } } } }



SCG configuration:

version 14.1X55-D25.3; groups { re0 { system { host-name scg; domain-name host.example1.com; domain-search [ host.example1.com example1.com example2.com ]; backup-router 10.8.2.254 destination 0.0.0.0/0; time-zone America/New_York; root-authentication { encrypted-password "$ABC123"; ## SECRET-DATA } name-server { 10.8.4.105; } login { user user1 { uid 2006; class super-user; authentication { encrypted-password "$ABC123"; ## SECRET-DATA } } } services { ftp; ssh; telnet; xnm-clear-text; } ntp { server 10.8.4.105; } } interfaces { fxp0 { unit 0 { family inet { address 10.8.2.150/24; address 10.8.2.152/24 { master-only; } } } } } routing-options { static { route 10.8.0.0/16 next-hop 10.8.2.254; route 172.16.0.0/12 next-hop 10.8.2.254; } } } re1 { system { host-name scg; domain-name host.example1.com; domain-search [ host.example1.com example1.com example2.com ]; backup-router 10.8.2.254 destination 0.0.0.0/0; time-zone America/New_York; root-authentication { encrypted-password "$ABC123"; ## SECRET-DATA } name-server { 10.8.4.105; } login { user user1 { class super-user; authentication { encrypted-password "$ABC123” ## SECRET-DATA }

} } services { ftp; ssh; telnet; xnm-clear-text; } ntp { server 10.8.4.105; } } interfaces { fxp0 { unit 0 { family inet { address 10.8.2.151/24; address 10.8.2.152/24 { master-only; } } } } } routing-options { static { route 10.8.0.0/16 next-hop 10.8.2.254; route 172.16.0.0/12 next-hop 10.8.2.254; } } } TDF-SESSION { chassis { fpc 5 { pic 0 { adaptive-services { service-package { extension-provider { package jservices-mobile; syslog { external any; daemon any; kernel any; } } } } } } } } TDF-SERVICE { chassis { fpc 5 { pic 1 { adaptive-services { service-package { extension-provider { package jservices-mss; package jservices-jdpi; package jservices-crypto-base; package jservices-pcef; package jservices-hcm; syslog { external any; daemon any; kernel any; } } } } } } } } } apply-groups [ re0 re1 ]; system { host-name scg; root-authentication {



encrypted-password "$ABC123"; ## SECRET-DATA } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } } commit synchronize; } chassis { fpc 0 { pic 1 { tunnel-services; } } fpc 5 { pic 0 { apply-groups TDF-SESSION; } pic 1 { apply-groups TDF-SERVICE; } } } services { service-set SCG-SERVICESET-1 { service-set-options { subscriber-awareness; } pcef-profile pcef-default; interface-service { service-interface ms-5/1/0; } } service-set SS-NAT { nat-rules Nat-Rule-1; next-hop-service { inside-service-interface ms-5/2/0.1; outside-service-interface ms-5/2/0.2; } } nat { pool Nat-Pool-1 { address 192.168.186.20/32; port { automatic { random-allocation; } } } rule Nat-Rule-1 { match-direction input; term 10 { from { source-address { 10.168.0.0/16; 10.169.0.0/16; } } then { translated { source-pool Nat-Pool-1; translation-type { napt-44; } } } } } } pcef { profile { pcef-default; }

} } interfaces { xe-0/0/0 { vlan-tagging; unit 20 { vlan-id 20; family inet { address 10.20.20.2/24; } } unit 21 { vlan-id 21; family inet { address 10.21.21.2/24; } } } xe-0/1/0 { unit 0 { family inet { address 10.12.2.0/31; } } } ge-1/2/0 { description "To Internet DMZ"; unit 0 { proxy-arp; family inet { address 192.168.186.10/24; } } } ge-1/3/0 { unit 0 { family inet { address 10.255.2.1/24; } } } ms-5/0/0 { description "Session PIC"; unit 0 { family inet; } } ms-5/1/0 { description "Service PIC"; unit 0 { family inet; } } ms-5/2/0 { description "For NAT"; unit 1 { family inet; service-domain inside; } unit 2 { family inet; service-domain outside; } } lo0 { unit 0 { family inet { address 10.100.2.2/32; } } } mif { unit 0 { clear-dont-fragment-bit; family inet { service { input { service-set SCG-SERVICESET-1; } output { service-set SCG-SERVICESET-1;



} } } } } } routing-options { static { route 0.0.0.0/0 next-hop 192.168.186.254; } rib-groups { RETURN-TO-CLIENT { import-rib [ SCG-Access.inet.0 VR-GREEN-IN.inet.0 VR-BLUE-IN.inet.0 VR-NAT.inet.0 ]; import-policy Policy-Subscriber-Routes; } } router-id 10.100.2.2; route-distinguisher-id 10.100.2.2; autonomous-system 64512; dynamic-tunnels { dyn_tunnel1 { source-address 10.100.2.2; gre; destination-networks { 10.11.94.94/32; 10.12.95.95/32; } } } } protocols { bgp { log-updown; group Contrail { type internal; local-address 10.100.2.2; keep all; family inet-vpn { unicast; } neighbor 10.12.96.96; } } ospf { area 0.0.0.0 { interface lo0.0; interface xe-0/1/0.0; } } } policy-options { policy-statement Policy-Subscriber-Routes { term Reject-PCRF-Network { from { protocol [ local direct ]; route-filter 10.255.2.0/24 orlonger; } then reject; } term Accept-All-Other { then accept; } } } firewall { family inet { filter Skip-TDF { term 1 { from { destination-address { 10.169.0.0/16; } } then { skip-services; accept; } } term default { then accept;

} } filter Only-NAT { term 1 { from { source-address { 10.168.0.0/16; } } then accept; } term default { then accept; } } } } access { radius { clients { BNG { address 10.21.21.1/32; source-interface xe-0/0/0.21 ipv4-address 10.21.21.2; accounting { secret "$ABC123"; ## SECRET-DATA } } } } diameter { origin { realm example.com; host SCG; } network-element PCRF-Server { function pcc-gx; peer SCG-P1 { priority 1; } } transport SCG-T1 { address 10.255.2.1; routing-instance SCG-Access; } peer SCG-P1 { address 10.255.2.2; connect-actively { transport SCG-T1; port 3868; } } } } routing-instances { SCG-Access { instance-type virtual-router; access { address-assignment { address-pools { POOL1 { family inet { network { 10.169.0.0/16 { external-assigned; } } } default-pool; } } } } interface xe-0/0/0.20; interface ge-1/3/0.0; interface ms-5/1/0.0; interface mif.0; routing-options { interface-routes { rib-group inet RETURN-TO-CLIENT; }



rib SCG-Access.inet.0 { static { rib-group RETURN-TO-CLIENT; } } static { route 10.168.0.0/16 next-hop 10.20.20.1; route 10.169.0.0/16 next-hop 10.20.20.1; } } forwarding-options { family inet { filter { input Only-NAT; } } } } VR-BLUE-IN { description "BLUE Service Chain - Ingress"; instance-type vrf; vrf-target target:64512:2001; vrf-table-label; forwarding-options { family inet { filter { input Skip-TDF; } } } } VR-BLUE-OUT { description "BLUE Service Chain - Egress"; instance-type vrf; vrf-target target:64512:2002; vrf-table-label; routing-options { static { route 0.0.0.0/0 next-table VR-NAT.inet.0; } } } VR-GREEN-IN { description "GREEN Service Chain - Ingress"; instance-type vrf; vrf-target target:64512:1001; vrf-table-label; forwarding-options { family inet { filter { input Skip-TDF; } } } } VR-GREEN-OUT { description "GREEN Service Chain - Egress"; instance-type vrf; vrf-target target:64512:1002; vrf-table-label; routing-options { static { route 0.0.0.0/0 next-table VR-NAT.inet.0; } } } VR-NAT { instance-type virtual-router; interface ms-5/2/0.1; routing-options { static { route 0.0.0.0/0 next-hop ms-5/2/0.1; } } } } unified-edge { diameter-profiles { gx-profile { SCG-GX-PROFILE-1 { targets {

t1 { destination-realm example.com;

priority 1; network-element PCRF-Server; } } } } } gateways { tdf TDF-1 { system { session-pics { interface ms-5/0/0; } service-pics { interface ms-5/1/0; } } domains { SCG-domain-1 { pcef-profile SCG-PCEF-PROFILE-1; tdf-interface mif.0; access-interfaces { xe-0/0/0.20; } subscriber-attach-method radius-accounting; subscription-id { subscription-id-options { id-username { id-components use-username; } } } immediate-accounting-response disable; subscriber-address { inet { pool POOL1; } } default-local-policy { flow-action drop; } } } domain-selection { term 1 { from { client { BNG; } framed-ip-address equals 10.169.0.0/16; } then { domain SCG-domain-1; } } } aaa { clients { BNG; } } } } pcef { flow-descriptions { SDF_DNS { direction both; protocol 17; remote-ports 53; } SDF_ICMP { direction both; protocol 1; } SDF_any-any { direction both;



} SDF_port443 { direction both; remote-ports 443; } SDF_port80-8080 { direction both; protocol 6; remote-ports [ 80 8080 ]; } } pcc-action-profiles { SCG-BLUE-INITIAL-ACTION { maximum-bit-rate uplink 384 downlink 640; burst-size { uplink 15000; downlink 150000; } steering { routing-instance uplink VR-BLUE-IN downlink VR-BLUE-OUT; } } SCG-BLUE-UPDATE-ACTION { maximum-bit-rate uplink 1024 downlink 7000; burst-size { uplink 23000; downlink 250000; } steering { routing-instance uplink VR-BLUE-IN downlink VR-BLUE-OUT; } } SCG-GREEN-INITIAL-ACTION { maximum-bit-rate uplink 384 downlink 640; burst-size { uplink 15000; downlink 150000; } steering { routing-instance uplink VR-GREEN-IN downlink VR-GREEN-OUT; } } } pcc-rules { PCCRULE-BLUE-CHANGE-TO-GREEN { from { flows { SDF_any-any; } } then { pcc-action-profile SCG-GREEN-INITIAL-ACTION; } } PCCRULE-BLUE-INITIAL { from { flows { SDF_any-any; } } then { pcc-action-profile SCG-BLUE-INITIAL-ACTION; } } PCCRULE-BLUE-UPDATE { from { flows { SDF_any-any; } } then { pcc-action-profile SCG-BLUE-UPDATE-ACTION; } } PCCRULE-GREEN-CHANGE-TO-BLUE {

from { flows { SDF_any-any; } } then { pcc-action-profile SCG-BLUE-INITIAL-ACTION; } } PCCRULE-GREEN-INITIAL { from { flows { SDF_any-any; } } then { pcc-action-profile SCG-GREEN-INITIAL-ACTION; } } } profiles { SCG-PCEF-PROFILE-1 { unresolved-flow-action forward; dynamic-policy-control { pcc-rules { PCCRULE-GREEN-INITIAL precedence 100; PCCRULE-GREEN-CHANGE-TO-BLUE precedence 105; PCCRULE-BLUE-INITIAL precedence 200; PCCRULE-BLUE-UPDATE precedence 210; PCCRULE-BLUE-CHANGE-TO-GREEN precedence 220; } diameter-profile SCG-GX-PROFILE-1; release r9; } } } } }



vSRX configuration (for Green Firewall):

version 12.1X47-D15.4; system { host-name GreenFW; root-authentication { encrypted-password "$ABC123"; ## SECRET-DATA } login { user user3 { uid 2002; class super-user; authentication { encrypted-password "$ABC123"; ## SECRET-DATA } } } services { ssh; web-management { http { interface ge-0/0/0.0; } } } syslog { user * { any emergency; } file messages { any any; authorization info; } file interactive-commands { interactive-commands any; } } license { autoupdate { url https://ae1.example1.com/junos/key_retrieval; } } } interfaces { ge-0/0/0 { description management; unit 0 { family inet { dhcp; } } } ge-0/0/1 { description left; unit 0 { family inet { filter { input left2right; } dhcp; } } } ge-0/0/2 { description right; unit 0 { family inet { filter { input right2left; } dhcp; } } } } security { utm { custom-objects { url-pattern {

URLs-to-Block { value [ http://*.amazon.com http://*.alcatel-lucent.com http://*.apple.com ]; } } custom-url-category { Green-Blacklist { value URLs-to-Block; } } } feature-profile { web-filtering { url-blacklist Green-Blacklist; type example-local; example-local { profile Green-Profile-1 { default log-and-permit; custom-block-message "This site is blocked. Please consider upgrading to the Blue service"; } } } } utm-policy Green-URL-Filtering { web-filtering { http-profile Green-Profile-1; } traffic-options { sessions-per-client { over-limit log-and-permit; } } } } screen { ids-option untrust-screen { icmp { ping-death; } ip { source-route-option; tear-drop; } tcp { syn-flood { alarm-threshold 1024; attack-threshold 200; source-threshold 1024; destination-threshold 2048; timeout 20; } land; } } } policies { from-zone left to-zone right { policy left2right { match { source-address any; destination-address any; application any; } then { permit { application-services { utm-policy Green-URL-Filtering; } } } } } } zones { functional-zone management { interfaces { ge-0/0/0.0 { host-inbound-traffic { system-services { all;



} } } } } security-zone left { interfaces { ge-0/0/1.0 { host-inbound-traffic { system-services { ping; dhcp; } } } } } security-zone right { interfaces { ge-0/0/2.0 { host-inbound-traffic { system-services { dhcp; ping; } } } } } } } firewall { family inet { filter left2right { term any { then { routing-instance RIGHT-VR; } } } filter right2left { term any { then { routing-instance LEFT-VR; } } } } } routing-instances { LEFT-VR { instance-type virtual-router; interface ge-0/0/1.0; } RIGHT-VR { instance-type virtual-router; interface ge-0/0/2.0; } }

Date post:	09-Mar-2018
Category:	Documents
Upload:	trinhnga
View:	259 times
Download:	6 times

MX Services Control Gateway - Juniper Networks · PDF fileConfiguring the PCRF ... The Service...

Documents