Advanced Policy-Based Routing

 

Advanced policy-based routing (APBR) also known as application-based routing, a new addition to Juniper Networks suite, provides the ability to forward traffic based on applications. For more information, see the following topics:

Understanding Advanced Policy-Based Routing

The relentless growth of voice, data, and video traffic and applications traversing on the network requires that networks recognize traffic types to effectively prioritize, segregate, and route traffic without compromising performance or availability.

Starting with Junos OS Release 15.1X49-D60, SRX Series Services Gateways support advanced policy-based routing (APBR) to address these challenges.

This topic includes the following sections:

Application Identification

SRX Series devices support application identification (AppID) using deep packet inspection (DPI) technology. Junos OS application identification recognizes Web-based and other applications and protocols at different network layers using characteristics other than port number. Applications are identified by using a protocol bundle containing application signatures and parsing information. The identification is based on protocol parsing and decoding and session management. An application system cache (ASC) is maintained, where the applications identified are cached based on server (destination) IP address and port and logical system identification.

ASC saves the mapping between an application type and the corresponding destination IP address, destination port, protocol type, and service. Once an application is identified, its information is saved in the ASC so that only one matching entry is required for an application running on a particular system. When the cache entry is present and it is valid, the identified application is picked from cache, thereby expediting the identification process.

Filter-Based Forwarding or Policy-Based Routing (PBR)

SRX Series devices support filter-based forwarding, also known as policy-based routing (PBR), in which data packets are forwarded and routed based on the defined policies or filters. PBR includes a mechanism for selectively applying policies based on access list, packet size, or other criteria and routing the packets on user-defined routes.

When a device receives a packet, it routes the packets based on the information present in the packet header such as destination port, source IP address, and incoming interfaces. While processing an incoming packet, the device performs a routing table lookup to find the appropriate interface that leads to the destination address.

However, in some cases, you might need to forward the packet based on other criteria. In filter-based forwarding, you must create a filter that will match the type of traffic that you are going to direct to a different next hop. You can define matching criteria such as IP address, port, protocol, TCP flags, and much more. Once you have defined your term to include the match criteria, the action will be to send the traffic to an appropriate route and corresponding interface.

For example, perhaps you want to offer services to your customers, and the services reside on different servers. You can use filter-based forwarding to send traffic to the servers by applying a match condition in the packet header such as destination port, source IP address, and incoming interfaces, and send the packets to a certain outgoing interface that is associated with the appropriate server.

Advanced Policy-Based Routing

Advanced policy-based routing is a type of session-based, application-aware routing. This mechanism combines the policy-based routing and application-aware traffic management solution. APBR implies classifying the flows based on applications’ attributes and applying filters based on these attributes to redirect the traffic. The flow-classifying mechanism is based on packets representing the application in use.

APBR implements:

  • Deep packet inspection and pattern-matching capabilities of AppID to identify application traffic or a user session within an application

  • Lookup in ASC for application type and the corresponding destination IP address, destination port, protocol type, and service for a matching rule

If a matching rule is found, the traffic is directed to an appropriate route and the corresponding interface or device.

Benefits of APBR

  • Enables you to define the routing behavior based on applications.

  • Provides more flexible traffic-handling capabilities and offers granular control for forwarding packets based on application attributes.

Understanding How APBR Works

The following steps are involved in APBR:

  • Create an APBR profile (also referred to as an application profile in this document) that will match the type of traffic that you are going to direct to a different next hop. The profile includes multiple rules. Each rule can contain multiple applications or application groups. If the application matches any of the application or application groups of a rule in a profile, the application profile rule is considered as a match.

  • Associate a routing instance with the application profile rule. When the traffic on the ingress zone and interface matches an application profile, the associated static route and next hop defined in the routing instance is used to route the traffic for the particular session.

  • Associate the application profile to the ingress traffic The application profile can be attached to a security zone or it can be attached to a specific logical or physical interface associated with the security zone. If the application profile is applied to a security zone, then all interfaces belonging to that zone are attached to the application profile by default unless a specific configuration already exists for that interface.

Figure 1 shows the sequence in which APBR techniques are applied.

Figure 1: APBR Flow Diagram
APBR Flow Diagram
  1. APBR evaluates the packets based on incoming interface to determine if the session is candidate for application-based routing. If the traffic has not been flagged for application-based routing, it undergoes normal processing (non-APBR route).

  2. If the session needs application-based routing, APBR queries the application system cache (ASC) module to get the application attributes details (IP address, destination port, protocol type, and service).

    If the ASC is found, it is further processed for a matching rule in the APBR profile (see Step 3). If the ASC is not found and the application signature is installed and ASC is enabled, application identification for the session is enabled so that ASC can be populated for use by subsequent sessions for the destination tuple.

  3. APBR uses the application details to look for a matching rule in the APBR profile (application profile). If a matching rule is found, the traffic will be redirected to the specified routing instance for the route lookup.

Advanced Policy-Based Routing Midstream Support

Starting with Junos OS Release 15.1X49-D110 and Junos OS Release 17.4R1, SRX Series Services gateways support advanced policy-based routing (APBR) with an additional enhancement to apply the APBR in the middle of a session (which is also known as midstream support). With this enhancement, you can apply APBR for a non-cacheable application and also for the first session of the cacheable application. The enhancement provides more flexible traffic-handling capabilities that offer granular control for forwarding packets.

Figure 2 shows the sequence in which APBR techniques with midstream support are applied.

Figure 2: APBR with Midstream Support Flow Diagram
APBR
with Midstream Support Flow Diagram

  • Step 1: APBR evaluates the packets based on incoming security zone to determine if the session is candidate for application-based routing. If this is first packet of the new session and traffic is not flagged for application-based routing, it undergoes normal processing (non-APBR route) step 6.

  • Step 2: If the session needs application-based routing, APBR queries the application system cache (ASC) module to get the application attributes details (IP address, destination port, protocol type, and service). If the ASC is found, it is further processed to determine if the application match using ASC is final (see Step 3). APBR could also identify applications using ALG for the data sessions. If the application is matched using the ALG it is considered as final match. If the final application has not been identified, the DPI engine is engaged for the session to identify the application. The existing session undergoes normal processing (non-APBR route) step 6.

  • Step 3: If an application has been identified, it is further processed for a matching rule in the APBR profile (see Step 4).

  • Step 4: APBR uses the application details to look for a matching rule in the APBR profile (application profile). If a matching rule is found, the traffic will be redirected to the specified routing instance for the route lookup. If matching rule is not found, it undergoes normal processing (non-APBR route) (see step 6).

  • Step 5: Traffic is routed through the specified routing instance for the destination. Step 6: Traffic traverses through a default route (non-APBR route) to the destination.

For a new session, when application cannot be identified based on first packet information the traffic traverses through a default route (non-APBR route) to the destination. At the same time, APBR is applied and the rest of the session packets passes through the route as per the rules defined in the APBR profile. This means that, APBR rules are applied as and when an application is identified by AppID. For first packet of session, always go through midstream re-routing case. That is, when the application is not yet identified, the traffic traverses through a default route (non-APBR route) to the destination. At the same time, application identification is enabled for that session. This continues still application signatures identify the application and APBR is applied and the rest of the session packets passes through the route as per the rules defined in the APBR profile. The traffic traverses through a non-APBR route till application signatures or ALG identify the application.

You can enable, AppTrack to inspect traffic and collect statistics for application flows in the specified zone. See Understanding AppTrack for more details.

Advanced Policy-Based Routing Options For Streamlining Traffic Handling

You can streamline the traffic handling with APBR by using the following options:

  • Limit route change- Some sessions go through continuous classification in the middle of the session as application signatures identify the application. Whenever an application is identified by the application signatures, APBR is applied, and this results in a change in the route of the traffic. You can limit the number of times a route can change for a session by using the max-route-change option of the tunables statement.

    set security advance-policy-based-routing tunables max-route-change value

    Example:

    In this example, you want to limit the number of route changes per session to 5. When there is a change in the route in the middle of the session, this count is reduced to 4. This process continues until the count reaches 0. After that, APBR is not applied in the middle of the session.

    If an identified application has an entry in the ASC, then, the count is not reduced for that session, because the session started with the specified route according to the APBR configuration.

  • Terminate session if APBR is bypassed–You can terminate the session if there is a mismatch between zones when APBR is being applied in the middle of the session. When you want to apply APBR in the middle of a session, both new egress interface and existing egress interface must be part of the same zone. If you change the zone for an interface in the middle of a session, then, by default, APBR is not applied, and the traffic continues to traverse through the existing interface. To change this default behavior, you can terminate the session entirely, instead of allowing traffic to traverse through the same route bypassing APBR, by using the drop-on-zone-mismatch option of the tunables statement.

    Example:

  • Enable logging—You can enable logging to record events that occur on the device, for instance, when APBR is bypassed because of a change in the zones for interfaces. You can use the enable-logging option of the tunables statement to configure the logging.

    Example:

  • Enable reverse reroute—For deployments that requires traffic symmetry for ECMP routes, and the incoming traffic needs to switch in the middle of session, the rerouting can be achieved using the option enable-reverse-reroute specific to a security zone as follows:

    Example:

    [edit]

    set security zones security-zone zone-name enable-reverse-reroute

    When the above configuration is enabled for a security zone, where an incoming packet arrives on an interface and has a different outgoing/return interface, a change in the interface is detected and triggers a reroute. A route lookup is performed for the reverse path, and the preference will be given to the interface on which the packet has arrived.

    Further processing stops for a particular session when a route lookup fails for the traffic on reverse path.

    Support for reverse rerouting is available starting in Junos OS Release 15.1X49-D130 and later releases.

Use Case

  • When multiple ISP links are used:

    • APBR can be used for selecting high-bandwidth, low-latency links for important applications, when more than one link is available.

    • APBR can be used for creating a fallback link for important traffic in case of link failure. When multiple links are available, and the main link carrying the important application traffic suffers an outage, then the other link configured as the fallback link can be used to carry traffic.

    • APBR can be used for segregating the traffic for deep inspection or analysis. With this feature, you can classify the traffic based on applications that are required to go through deep inspection and audit. If required, such traffic can be routed to a different device.

Limitations

APBR has the following limitations:

  • Redirecting the route for the traffic depends on the presence of an entry in the application system cache (ASC). Routing will succeed only if the ASC lookup is successful. For the first session, when the ASC is not present for the traffic, the traffic traverses through a default route (non-APBR route) to the destination (this limitation is applicable only for the releases before Junos OS 15.1X49-D110).

  • APBR does not work if an application signature package is not installed or application identification is not enabled.

  • APBR does not work for Layer 3 and Layer 4 applications, because the Layer 3 and Layer 4 applications custom signatures are not maintained in the ASC.

APBR with midstream support has the following limitations:

  • APBR works only for forward traffic.

  • APBR does not work for data sessions initiated by an entity from the control session, such as active FTP.

  • When using different NAT pools for source NAT and midstream APBR is applied, the source IP address of the session continues to be the same as the one with which the session has been using before applying the midstream APBR.

  • APBR with midstream support works only when all egress interfaces are in the same zone. Because of this, only the forwarding and virtual routing and forwarding (VRF) routing instances can be used to avail APBR midstream support.

Example: Configuring Advanced Policy-Based Routing for Application-Aware Traffic Management Solution

This example shows how to configure APBR on an SRX Series device.

Requirements

This example uses the following hardware and software components:

  • Valid application identification feature license installed on an SRX Series device.

  • SRX Series device with Junos OS Release 15.1X49-D60 or later. This configuration example is tested for Junos OS Release 15.1X49-D60.

Overview

In this example, you want to forward HTTP, social networking, and Yahoo traffic arriving at the trust zone to a specific device or interface as specified by the next-hop IP address.

When traffic arrives at the trust zone, it is matched by the APBR profile, and if a matching rule is found, the packets are forwarded to the static route and next hop as specified in the routing instance. The static route configured in the routing table is inserted into the forwarding table when the next-hop address is reachable. All traffic destined for the static route is transmitted to the next-hop address for transit to a specific device or interface.

Figure 3 shows the topology used in this configuration example.

Figure 3: Topology For Advanced Policy-Based Routing (APBR)
 Topology
For Advanced Policy-Based Routing (APBR)

Table 1 provides the details of the parameters used in this example.

Table 1: APBR Configuration Parameters

Parameter

Name

Description

Routing Instance

  • Instance name—R1

  • Instance type— forwarding

  • Static route— 1.0.0.254/8

  • Next-hop— 1.0.0.1

Routing instance of type forwarding is used for forwarding the traffic.

All the qualified traffic destined for the static route (example: 5.0.0.0/8) is forwarded to the next-hop device (example: with 7.0.0.1 address on its interface).

 
  • Instance name—R2

  • Instance type— forwarding

  • Static route— 2.0.0.254/8

  • Next-hop— 2.0.0.1

 

RIB Group

apbr_group

Name of the routing information base (RIB) (also known as routing table) group.

This RIB group is configured to import interface route entries from inet.0, RI1.inet.0, RI2.inet.0, and RI3.inet.0.

APBR Profile

profile-1

Name of the APBR profile. This profile matches applications and application groups and redirects the matching traffic to the specified routing instance (example: R1) for the route lookup. The profile includes multiple rules.

Rule

  • Rule name—ruleApp1

  • matching application—junos:HTTP

  • Associated routing instance—R1

Define the rules for the APBR profile. Associate the rule with one or more than one application (example: for HTTP) or application groups. If the application matches any of the application or application groups of a rule in a profile, the application profile rule is considered as a match and the traffic will be redirected to the routing instance (example: R1) for the route lookup.

  • rule name—ruleApp2

  • matching application—junos:web:social-networking

  • Routing instance— R2

 

Zone

trust

Specify the source zone to which the APBR profile can be applied.

Note

To use the APBR for redirecting the traffic based on applications, importing interface routes might be required from one routing instance to another routing instance. You can use one of the following mechanisms:

  • RIB groups to import interface routes

  • Routing policy to import interface routes

When you use routing policy to import interface routes, it might cause management local routes (using fxp0) to leak to non-default routing instance, if the appropriate action is not used for the routing policy. When devices are in chassis cluster mode, such scenarios might result in RG0 failover due to limitations. We recommend not configure fxp0 local route in the routing table of non-default routing instance. Following sample depicts a sample configuration of policy options. Note that the reject action helps in eliminating the routes that are not required. You can use specific routes to reject the fxp0 routes.

Note

APBR is used for routing the packets in a forward path. For return traffic to arrive over the same path, we recommend to configure the remote SRX Series device with ECMP configuration along with load balance routing policy as shown in the following sample configuration:

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Configuring Advanced Policy-Based Routing

Step-by-Step Procedure

To configure APBR:

  1. Create routing instances.
  2. Group one or more routing tables to form a RIB group called apbr_group and import routes into the routing tables.
  3. Create the APBR profile and define the rules.
  4. Apply the APBR profile to the security zone.

Results

From configuration mode, confirm your configuration by entering the show routing-instances and show security zones commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Advanced Policy-Based Routing Statistics

Purpose

Display the statistics for APBR such as the number of sessions processed for the application-based routing, number of times the APBR is applied for the session, and so on.

Action

From configuration mode, enter the show security advance-policy-based-routing statistics command.

Meaning

The command output displays the following details:

  • Sessions processed for the application-based routing.

  • The number of times the application traffic matches the APBR profile and APBR is applied for the session.

  • The number of times AppID was consulted to identify application traffic.

See show security advance-policy-based-routing statistics for more details.

Verifying Advanced Policy-Based Routing

Purpose

Display information about the sessions and packet flows active on the device, including detailed information about specific sessions.

Action

From configuration mode, enter the show security flow session command to display information about all currently active security sessions on the device.

Meaning

The command output displays the following details:

  • All active sessions and packet flows on your device

  • List of incoming and outgoing IP flows, including services

  • Security attributes associated with a flow, for example, the policies that apply to traffic belonging to that flow

  • Session timeout value, when the session became active, how long the session has been active, and if there is active traffic on the session

Configuring Advanced Policy-Based Routing Policies

Starting in Junos OS Release 18.2R1, you can configure advanced policy-based routing (APBR) policies by defining source addresses, destination addresses, and applications as match conditions; and after a successful match, the configured APBR profile is applied as an application services for the session. In the previous releases of Junos OS, an APBR profile could be attached to an incoming security zone of the ingress traffic, and the APBR was applied per security zone basis. Now, with support of APBR policies, you can apply different set of APBR rules on the traffic based on incoming security zone, source address, destination address and application

This enhancement provides more flexible traffic-handling capabilities that offer granular control for forwarding packets.

Supported match criteria includes source addresses, destination addresses, and applications. The applications can be used to support the matching condition based on protocol and Layer 4 ports.

If one or more APBR policy is configured for the security zone, then the policy is evaluated during session creating phase. The policy lookup is terminated once the policy, matching the session, is selected. After a successful match, the APBR profile configured with the APBR policy is used for the session.

How APBR Policy Works?

APBR policies are defined for a security zone. If there is one or more APBR policy associated with a zone, the session that is initiated from the security zone goes through the policy match.

The following sequences are involved in matching the traffic by an APBR policy and applying advanced policy-based routing to forward the traffic, based on the defined parameters/rules:

  • When traffic arrives at the ingress zone, it is matched by the APBR policy rules. The policy match condition include the source address, destination address and application.

  • When the traffic matches the security policy rules, the action of the APBR policy is applied to the traffic. You can enable APBR as an application service in the APBR policy action by specifying the APBR profile name.

  • The APBR profile configuration incudes the set of rules that contains set of dynamic applications and dyamic application groups as match condition. The action part of those rules contain the routing instance through which traffic needs to be forwarded. The routing instance can include configuration of static routs or dynamic learned routes.

  • All traffic destined for the static route is transmitted to the next-hop address for transit to a specific device or interface.

APBR policy rules are terminal, which means that once the traffic is matched by a policy, it is not processed further by the other policies.

If an APBR policy has the matching traffic and APBR profile does not have any traffic matching the rule, then the traffic matching the APBR policy traverses through a default routing-instance [inet0] to the destination.

Legacy APBR Profile Support

Prior to the Junos OS Release 18.2R1, APBR profile was applied at security zone-level. With the support for APBR policy, APBR configuration at security-zone level is deprecated future, rather than being immediately removed in order to provide backward compatibility and a chance to bring your configuration into compliance with the new configuration.

However, if you have configured a zone-based APBR, and you attempt to add an APBR policy for the particular security zone, commit might fail. You must delete the zone-based configuration in order to configure the APBR policy for the zone. Similarly if an APBR policy is configured for a security zone, and you attempt to configure zone-based APBR, results in commit error.

Limitation

  • When using specific address or address set in the APBR policy rule, we recommend to use the global address book. Because, zone specific rules might not be applicable for destination address, as the destination zone is not known at time of policy evaluation.

  • Configuring APBR policy for the security zone junos-host zone is not supported.

Example: Configuring Advanced Policy-Based Routing Policies

This example shows how configure an APBR policy and apply the APBR profile on the session that matches the APBR policy rules.

Requirements

This example uses the following hardware and software components:

  • Valid application identification feature license installed on an SRX Series device.

  • SRX Series device with Junos OS Release 18.2R1 or later. This configuration example is tested on Junos OS Release 18.2R1.

Overview

In this example, you want to forward HTTP traffic arriving at the trust zone to a specific device or interface as specified by the next-hop IP address.

When traffic arrives at the trust zone, it is matched by the APBR policy. When the traffic matches the policy, the configured APBR rule is applied on the permitted traffic as application services. The packets are forwarded based on the APBR rule to the static route and next hop as specified in the routing instance. The static route configured in the routing table is inserted into the forwarding table when the next-hop address is reachable. All traffic destined for the static route is transmitted to the next-hop address for transit to a specific device or interface.

In this example, you must complete the following configurations:

  • Define routing instance and RIB group.

  • Create an ABPR profile.

  • Create a security zone.

  • Create an APBR policy and attach the APBR profile to it.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Configuring Advanced Policy-Based Routing

Step-by-Step Procedure

To apply APBR on the traffic matching the APBR policy:

  1. Create routing instances.
  2. Group one or more routing tables to form a RIB group called apbr_group and import routes into the routing tables.
  3. Create the APBR profile and define the rules.
  4. Create a security zone.
  5. Create an APBR policy and apply the APBR profile to the security zone.

Results

From configuration mode, confirm your configuration by entering the show routing-instances and show security zones commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Advanced Policy-Based Routing Statistics

Purpose

Display the statistics for APBR such as the number of sessions processed for the application-based routing, number of times the APBR is applied for the session, and so on.

Action

From configuration mode, enter the show security advance-policy-based-routing statistics command.

Meaning

The command output displays the following details:

  • Sessions processed for the application-based routing.

  • The number of times the application traffic matches the APBR profile and APBR is applied for the session.

  • The number of times AppID was consulted to identify application traffic.

See show security advance-policy-based-routing statistics for more details.

Verifying APBR Policy Configuration

Purpose

Display information about the APBR policy, associated APBR profile and to display information about the APBR policy hit count.

Action

From configuration mode, enter the show security advanced-policy-based-routing command.

user@host> show security advanced-policy-based-routing policy-name SLA1

From configuration mode, enter the show security advanced-policy-based-routing hit-count command.

user@host> show security advanced-policy-based-routing hit-count

Meaning

The command output displays the following details:

  • Details such as status of the policy, associated APBR profile.

  • Display the utility rate of policies according to the number of hits they receive.

Understanding URL Category-Based Routing

Starting in Junos OS Release 18.3 R1, URL category-based routing is supported on SRX Series devices and vSRX instances. URL category-based routing enables you to use URL categories as match criteria in an APBR profile. The URL categories are based on the destination server IP address, and the category identification is leveraged from the Enhanced Web Filtering (EWF) and local Web filtering results obtained from the unified threat management (UTM) module.

URL category-based routing enables you to identify and selectively route Web traffic (HTTP and HTTPS) to a specified destination.

Web filtering classifies websites into the categories according to host, URL, or IP address, and performs the filtering based on those categories. You can configure APBR profiles by specifying a URL category as the match condition in the rule. The APBR profile rule matches the traffic with specified match criteria, and after a successful match, the configured APBR profile is applied as the application service for the session. For example, suppose you want to route all the traffic belonging to a specific website category, such as social media, through a specific next hop. In this case, you can create a new APBR profile with the list of URL categories such as Enhanced_Social_Web_Facebook, Enhanced_Social_Web_Linkedin, Enhanced_Social_Web_Twitter or Enhanced_Social_Web_Youtube or any other custom URL as match criteria in the policy. The traffic that matches one of the defined URL categories in the rule is forwarded using the routes of the specific routing instance.

When an APBR profile matches the traffic against the URL categories included in the rule, APBR queries the Web filtering module to get the URL category details. If the URL category is not available in the URL filtering cache, then the SRX Series device sends a request to the private cloud configured with Web filtering for the categorization details. If the traffic does not match any URL categories, the request is uncategorized, and the session undergoes normal processing (non-APBR route).

Note

If the private cloud configured with EWF does not respond to the URL category request within an interval of 3 seconds, then the session undergoes normal processing (non-APBR route).

Rule Processing in an APBR Profile

You can provide advanced policy-based routing by classifying the traffic based on applications’ attributes and applying policies based on these attributes to redirect the traffic. To do this, you must define the APBR profile and associate it to a APBR policy. You can create an APBR profile to include multiple rules with either dynamic applications, application groups or both, or a URL category as match criteria. The rules configured in the APBR profile can include either of the following:

  • One or more applications, dynamic applications, or application groups

  • URL category (IP destination address)—EWF or local Web filtering.

In an APBR profile, rule lookup is performed for both the match criteria. If only one match criteria is available, the rule lookup is done based on the available match criteria.

The APBR profile includes the rules to match the traffic with applications or URL categories and the action to redirect the matching traffic to the specified routing instance for the route lookup.

In Junos OS Release18.3R1, the URL category match is done based on the destination IP address; because of this, URL category-based rule match is terminated at the first packet of the session. As a dynamic application might be identified in the middle of the session, the matching process for the dynamic application rules continues until the process of application identification is complete.

Benefits of URL Category-Based Routing

  • Using URL-based categories enables you to have granular control over Web traffic. The traffic belonging to specific categories of websites is redirected through different paths, and based on the category, it is subjected to further security processing, including SSL decryption for HTTPS traffic.

  • Traffic-handling capabilities based on URL categories enable you to use different paths for selected websites. Using different paths results in better quality of experience (QoE) and also enables you to utilize the available bandwidth effectively.

  • SD-WAN solutions can utilize URL category-based routing in addition to the dynamic application-based routing.

  • URL category-based routing can be used for local Internet breakout solutions as it can work with source NAT configuration changes.

Limitations of URL Category-Based Routing

Using URL categories in an APBR profile has the following limitations:

  • Only the destination IP address is used for the URL category identification in an APBR profile. URL categories based on the host, or on the URL or the SNI field are not supported.

  • You can configure either a dynamic application or a URL category as the match condition in an APBR profile rule. Configuring a rule with both URL category and dynamic application results in a commit error.

Example: Configuring URL Category-Based Routing

This example shows you how to configure URL category-based routing.

Requirements

This example uses the following hardware and software components:

  • SRX Series device with Junos OS Release 18.3 R1 or later. This configuration example is tested on Junos OS Release 18.3 R1.

  • Valid application identification feature license installed on the SRX Series device.

  • The Enhanced Web Filtering (EWF) option requires you to purchase a Juniper Networks Web filtering license. No license is required for local Web filtering.

Overview

This example shows how to configure APBR on your SRX Series device to forward social media traffic arriving at the trust zone to a specific device or to an interface using URL category-based routing.

When traffic arrives, it is matched by the APBR profile, and if a matching rule is found, the packets are forwarded to the static route and next-hop IP address as specified in the routing instance. The static route configured in the routing table is added to the forwarding table when the next-hop address is reachable. All traffic destined for the static route is transmitted to the next-hop address for transit to a specific device or to an interface.

In this example, you complete the following configurations:

  • Enable either of the following types of Web filtering:

    • Enhanced Web Filtering (EWF)—When you enable EWF on the device, the EWF engine intercepts the HTTP and the HTTPS requests and categorizes the URL into one of the 95 or more predefined categories and also provides site reputation information. See Configuring URL-Based Routing by Using Local Web Filtering.

    • Local Web filtering—When you enable local Web filtering, you can configure custom URL categories with multiple URL lists and apply them to a UTM Web filtering profile with actions such as permit, permit and log, block, and quarantine. To use local Web filtering, you must create a Web filtering profile and ensure that category custom is part of the profile. See Configuring URL Category-Based Routing by Using EWF.

  • Define the routing instances and the routing information base (RIB; also known as routing table group.)

  • Define the APBR profile and associate it to an APBR policy.

Configuring URL Category-Based Routing by Using EWF

This section provides the steps to configure URL category-based routing using EWF. Table 2 provides the details of the parameters used in this example.

Table 2: Configuration Parameters for URL Category-Based Routing Using EWF

Parameters

Name

Description

APBR profile

apbr-pr1

Name of the APBR profile.

APBR policy

p1

Name of the APBR policy.

Rule

  • Rule name—rule rule-social-nw

  • Matching URL category—Enhanced_Facebook_Apps

  • Policy action—associate with routing instance RI1

Name of the APBR profile rule.

The APBR profile rule matches the traffic to the defined URL categories and redirects the matching traffic to the specified routing instance (example: RI1) for the route lookup.

Category

Enhanced_Social_Web_Facebook

Category defined in the APBR profile rule for matching the traffic.

Routing instance

  • Instance name—RI1

  • Instance type—forwarding

  • Static route—1.0.0.254/8

  • Next-hop—1.0.0.1

Routing instance of type forwarding is used for forwarding the traffic.

All the qualified traffic destined for the static route (with IP address 1.0.0.254/8) is forwarded to the next-hop device (with IP address 1.0.0.1).

RIB group

apbr_group

Name of the RIB group.

The RIB group shares interface routes with the forwarding routing instances. To ensure that the next hop is resolvable, interface routes from the main routing table are shared through a RIB group with the routing tables specified in the routing instances.

To perform URL category-based routing using EWF, you must complete the following procedures:

Enabling Enhanced Web Filtering

Step-by-Step Procedure

To use URL categories as match criteria in an APBR profile, you must enable EWF in UTM.

Note

The EWF option requires you to purchase a Juniper Networks Web filtering license. No license is required for local Web filtering.

  1. Enable EWF by specifying the Web filtering type as juniper-enhanced.
  2. Set the cache size as 500 and cache timeout as 1800 seconds for the configured EWF engine.

    For more information about EWF configuration, see Enhanced Web Filtering (EWF).

Defining the Routing Instance and the RIB Group

Step-by-Step Procedure

Define routing instance and the RIB group.

  1. Create the routing instance to forward traffic to the different next hops. In this step, you configure the static route 1.0.0.254/8, and the next-hop address as 1.0.0.1.

  2. Create a RIB group.

    Interface routes from the main routing table (inet.0) are shared through a RIB group with the routing table specified in the routing instance RI1.inet.0.

Configuring the APBR Profile

Step-by-Step Procedure

Create a rule for the Facebook applications and forward the matching traffic to the routing instance RI1.

  1. Create the APBR profile and define the match criteria for the URL category.

    The APBR profile rule matches the traffic to the defined URL category—that is, the Facebook application in this example.

  2. Specify the action for the traffic matching the URL category.

    In this step, you are specifying that the traffic that matches the apbr-pr1 rule is to be redirected to the routing instance RI1.

Configuring the APBR Policy and Attaching the APBR Profile

Step-by-Step Procedure

Associate the application profile to the APBR policy to enable URL category-based routing.

  1. Define the APBR policy. Specify the policy match condition as any for the source address, destination address, and application.

    When traffic arrives, it is matched by the APBR policy rules.

  2. Attach the APBR profile to the policy.

    When the traffic matches the APBR policy (p1) rules, the APBR profile apbr-pr1 is applied to the traffic as the action of the APBR policy. The traffic that matches the Facebook application is redirected to the routing instance RI1 according to the APBR profile rule rule-social-nw.

Results

From configuration mode, confirm your configuration by entering the show commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

[edit security]

[edit]

[edit]

If you are done configuring the device, enter commit from configuration mode.

Configuring URL-Based Routing by Using Local Web Filtering

This section provides the steps to configure URL category-based routing by using local Web filtering.

Table 3 provides the details of the parameters used in this example.

Table 3: APBR Configuration Parameters for URL Category-Based Routing Using Local Web Filtering

Parameters

Name

Description

APBR profile

apbr-pr2

Name of the APBR profile.

APBR policy

p2

Name of the APBR policy.

Rule

  • Rule name—rule2

  • Matching URL category—custom

  • Policy action—associate with routing instance RI2

Name of the APBR profile rule.

The APBR profile rule matches the traffic to the defined URL categories and redirects the matching traffic to the specified routing instance (example: RI2) for the route lookup.

Custom Category (URL Pattern)

203.0.113.0

203.0.113.10

Category defined in the APBR profile rule for matching the traffic.

Routing instance

  • Instance name—RI2

  • Instance type—forwarding

  • Static route—5.0.0.10

  • Next-hop—9.0.0.1

Routing instance of type forwarding is used for forwarding the traffic.

All the qualified traffic destined for the static route (with IP address 5.0.0.10) is forwarded to the next-hop device (with IP address 9.0.0.1).

RIB group

apbr_group2

Name of the RIB group.

The RIB group shares interface routes with the forwarding routing instances. To ensure that the next hop is resolvable, interface routes from the main routing table are shared through a RIB group with the routing tables specified in the routing instances.

To perform URL category-based routing using local Web filtering, you must complete the following procedures:

Enabling Local Web Filtering

Step-by-Step Procedure

To use URL categories as match criteria in an APBR profile, you must enable local Web filtering in UTM.

  1. Enable local Web filtering by specifying the Web filtering type as juniper-local.
  2. Create custom objects and URL pattern lists.

    In this step, a pattern that matches the IP address 203.0.113.0 or 203.0.113.10 on HTTP is created.

  3. Configure the custom URL category list.

    The URL category specified in this example is custom, where you can add URL lists. In this step, you are adding the URL list local1, which includes the patterns matching the addresses 203.0.113.1 and 203.0.113.10 that are created in step 2.

  4. Configure a Web filtering profile.

    A Web filtering profile includes a user-defined category with a permit action.

    For more information about local Web filtering configuration, see Local Web Filtering.

Defining the Routing Instance and the RIB Group

Step-by-Step Procedure

Define the routing instance and the RIB group.

  1. Create the routing instance to forward traffic to the different next hops. In this example, you configure the static route 5.0.0.0/10, using the next-hop address of 9.0.0.1.

  2. Create a RIB group.

    Interface routes from the main routing table (inet.0) are shared through a RIB group with the routing table specified in the routing instance (RI2.inet.0).

Configuring the APBR Profile

Step-by-Step Procedure

Create a rule to forward the traffic matching the custom URL pattern to the routing instance RI2.

  1. Create the APBR profile and define the match criteria for the URL category.

    The APBR profile rule matches the traffic to the defined custom URL category—that is, traffic with URL patterns matching the addresses 203.0.113.1 and 203.0.113.10 in this example.

  2. Specify the action for the traffic matching the URL category.

    In this step, you are specifying that the traffic that matches the rule is to be redirected to the routing instance RI2.

Configuring APBR Policy and Attaching the APBR Profile

Step-by-Step Procedure

Associate the APBR profile to the APBR policy to enable URL category-based routing.

  1. Define the APBR policy. Specify the policy match condition as any for the source address, destination address, and application.

    When traffic arrives, is matched by the APBR policy rules.

  2. Attach the APBR profile to the policy.

    When the traffic matches the APBR policy (p2) rules, the APBR profile apbr-pr2 is applied to the traffic as the action of the APBR policy. The traffic that matches the Facebook application is redirected to the routing instance RI2 according to the APBR profile rule rule2.

Results

From configuration mode, confirm your configuration by entering the show commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

[edit security]

[edit]

[edit]

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying APBR Statistics

Purpose

Display the statistics for APBR, such as the number of sessions processed for the application-based routing, the number of times the APBR is applied for the session, and so on.

Action

From configuration mode, enter the show security advance-policy-based-routing statistics command.

user@host> show security advance-policy-based-routing statistics

Meaning

The command output displays the following details:

  • Sessions processed for the application-based routing

  • The number of times the presence of an entry in the application system cache (ASC) is found

  • The number of times the application traffic matches the APBR profile and APBR is applied for the session

  • The number of times application identification (AppID) was consulted to identify application traffic

  • The number of times the APBR is applied for the session

Example: Configuring Schedulers for Advanced Policy-Based Routing Policy

This example shows how to configure schedulers for an APBR policy for a specified time slot.

Before you begin:

Overview

Starting in Junos OS Release 18.4R1, support for configuring policy schedulers for an advanced policy-based routing (APBR) policy is available. Using policy scheduler, you can schedule APBR policy execution for a specified duration.

Schedulers allow you to activate or deactivate an APBR policy for a specified duration (time and date). You can define schedulers for a single (nonrecurrent) or recurrent time slot within which a policy remains active. You can create schedulers irrespective of a policy, and other policies can refer the scheduler.

To use a scheduler for an APBR policy, you must create a scheduler and refer the scheduler in your APBR policy configuration. When the scheduler times out, the associated policy is deactivated. All the sessions associated with the policy are subsequently timed out.

Schedulers allow you define a time period for the policy to be active. You can restrict access to a resource for a period of time or remove a restriction by applying policy based on time or a day, such as policies enforced during business hours.

The following rules apply to the policy scheduling:

  • An APBR policy can refer only one scheduler in the configuration.

  • Multiple policies can reference a single scheduler.

  • A scheduler must be referenced in an APBR policy to become active.

  • An APBR policy always remains active if a defined scheduler is not referenced within the policy. The default behavior of the policy is to execute at all times.

In this example, you complete the following steps to create and apply the scheduler:

  • Create the scheduler, scheduler-1, that allows a policy, which refers to it, to be used for packet match checks every day, from 8:00 AM to 5:00 PM, except Sunday.

  • Create an APBR policy SLA1 and associate the scheduler to the policy.

When you refer the scheduler in the APBR policy, the policy is enforced for the matching traffic every day, from 8:00 AM to 5:00 PM, except Sunday.

Table 4 provides details of the parameters used in this example.

Table 4: Parameters Used in Configuring Scheduler for APBR Policy

Parameter

Name

Scheduler name

scheduler-1

Schedule

Every day, from 8:00 AM to 5:00 PM

Exception

Sundays

This example assumes that following configurations are already completed:

  • APBR policy

  • APBR Profile

For example on configuring the APBR policy and APBR profile, see Example: Configuring Advanced Policy-Based Routing Policies .

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

  1. To configure a scheduler:
  2. Create an APBR policy and apply the APBR profile to the security zone.
  3. Associate the scheduler to the policy.

Results

From configuration mode, confirm your configuration by entering the show security advance-policy-based-routing and show schedulers commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Purpose

Confirm that the scheduler is enabled in the APBR policy.

Action

From operational mode, enter the show security advance-policy-based-routing detail command.

user@host> show security advance-policy-based-routing detail

Meaning

The command output displays the following details:

  • Details such as status of the policy (SLA1), associated APBR profile (profile1).

  • Display the associated scheduler (scheduler-1).

Release History Table
Release
Description
Starting in Junos OS Release 18.4R1, support for configuring policy schedulers for an advanced policy-based routing (APBR) policy is available
Starting with Junos OS Release 15.1X49-D110 and Junos OS Release 17.4R1, SRX Series Services gateways support advanced policy-based routing (APBR) with an additional enhancement to apply the APBR in the middle of a session (which is also known as midstream support)
Starting with Junos OS Release 15.1X49-D60, SRX Series Services Gateways support advanced policy-based routing (APBR)
Support for reverse rerouting is available starting in Junos OS Release 15.1X49-D130 and later releases.