Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

Juniper Networks security 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)

Security 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 Application Tracking 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:

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

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

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 security 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

Bypassing Application Services in an APBR Rule

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 on security devices. URL category-based routing enables you to identify and selectively route Web traffic (HTTP and HTTPS) to a specified destination or to another device where further inspection on the Web traffic is required. In such cases, you can select not to apply or bypass application services on the session that is to be forwarded to the device for further inspection.

Starting in Junos OS Release 19.1R1, you can bypass application services for a session that is re-routed using the APBR rule.

The following sequences are involved in bypassing the application services:

  1. APBR uses the application details to look for a matching rule in the APBR profile (application profile).

  2. If a matching APBR rule is found, the traffic is redirected to the specified routing instance for the route lookup.

  3. If you configure the option to bypass application services on the sessions in an APBR rule, then an attempt is done to bypass the application services to the session.

  4. A log message is generated or updated to indicate the bypassing of the application services on the session.

You can bypass the application services including security policies, application quality of service (AppQoS), Juniper Sky ATP, IDP, Security Intelligence (SecIntel) and UTM using the APBR rule.

For bypass to be effective, it is required that the APBR rule is matched in the first packet. If the rule is matched after the first packet, and the rule has a bypass option configured, the bypass option is ignored and the application services are not bypassed.

ALG Service is not bypassed due to this feature as bypassing the ALG could potentially result in the correlated (data) session not being matched to appropriate security policy.

Example: Bypassing Application Services by Using APBR Rule

This example shows you how to bypass application services on the session using APBR rule. Using URL category-based routing, you can identify and selectively route Web traffic (HTTP and HTTPS) to a specified destination or to another device. Here, you can configure to bypass the application services on the session where further inspection on the Web traffic could be performed.

Requirements

This example uses the following hardware and software components:

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

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

Before you begin:

  • Define routing instance and RIB group.

  • Appropriate security policies to enforce rules for the transit traffic, to specify what traffic can pass through the device, and the actions that need to take place on the traffic as it passes through the device.

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 and bypass the application services on the same session.

In this example, you complete the following configurations:

  • Define the APBR profile and associate it to a APBR policy. The APBR profile includes the rules to match the traffic with applications and URL categories.

  • Next, specify the action of the APBR profile rule. That is, to redirect the matching traffic to the specified routing instance for the route lookup.

  • Specify application bypass option for the matching traffic.

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. All traffic destined for the static route is transmitted to the next-hop address for transit to a specific device or to an interface. Since you configured application bypass option for the matching traffic, the traffic forwarded to the specific device at next-hop address is not applied with application services.

Configuration

This section provides steps to configure URL category-based routing by using enhanced Web filtering (EWF) and also enable by passing application services on the traffic.

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).

Configuring the APBR Rule

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.

  3. Specify the bypassing application services for the traffic matching the APBR rule.

    In this step, you are specifying that the traffic that matches the apbr-pr1 rule is to be bypassed application services.

Configuring 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. Also application services are bypassed for the session as specified in 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]

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

  • The number of times the application services are bypassed for the session

Support for User Source Identity in APBR Policies

Starting in Junos OS Release 19.1R1, you can configure advanced policy-based routing (APBR) policies by defining user source identity as one of the match criteria along with source addresses, destination addresses, and applications. After a successful match, the APBR profile configured with the APBR policy is applied as an application service for the session. The source identity enables you to leverage user information stored in a repository such as user identification table (UIT).

The source-identity field specifies the users and roles to which the policy applies. When the source-identity field is specified in a policy as a matching criterion, user and role information must be retrieved before policy lookup can proceed. Using the source-identity option as a matching criterion in the APBR policy is optional. If the value in the source-identity field is configured as any or there is no entry in the source-identity field, user information and role information are not required and the other match criteria are used for policy lookup.

You can specify one or more users or user roles using the source-identity field with the following keywords:

  • authenticated-user—Users that have been authenticated.

  • unauthenticated-user—Users that have not been authenticated.

  • any—All users regardless of authentication status. If the source-identity field is not configured or is set to any, only other matching criteria are used for matching

  • unknown-user—Users that can not be authenticated due to an authentication server disconnection, such as a power outage.

On your security device, the user identification table (UIT) provides user and role information for an active user who has already been authenticated. Each entry in the table maps an IP address to an authenticated user and any role.

UIT contains the IP address, username, and role information for all authenticated user. The entries in the user identification table are ordered by IP address.

On your security device, the type of UIT supported is local authentication table. The local authentication table serves as the authentication source for the information required by APBR policies. Local authentication table is a static UIT created on the device either manually or programmatically using CLI commands. All users included in the local authentication table are considered authenticated users. To retrieve user and role information, a search is performed in the authentication table for an entry with an IP address corresponding to the traffic. When a matching IP address is found, user and role information is retrieved from the table entry and are associated with the traffic. If not found, the user is classified as an unauthenticated user.

User and role information can be created on the device manually or ported from a third-party authentication server, but the data in the local authentication table is not updated in real time.

During APBR policy lookup, if a user and user role that are configured in the APBR policy, but the entry is not present in the local authentication table, then the policy does not match. Hit count value that display the utility rate of security policies according to the number of hits they receive, does not increment.

For more information on user role retrieval and the policy lookup process, see User Role Firewall Security Policies.

Benefits

  • Enables you to define the routing behavior at more granular levels to ensure safe enforcement of policy on the application traffic traversing the network.

  • Provides more flexible traffic-handling capabilities and offers granular control for forwarding packets based on the roles and business requirements of users.

Local Authentication Table

You can manage the local authentication table with CLI commands that add or delete entries. You can add IP addresses, usernames, and roles from a third-party authentication source to the local authentication table programmatically using CLI commands. If an authentication source defines users and groups, the groups can be configured as roles and associated with the user as usual.

Use the following command to add an entry to a local authentication table. The entries in the table are entered using the IP address.

Example:

Use the following command to delete an entry by IP address or by username.

Use the following command to clear the local authentication table:

Use the following command to display the content of the local authentication table:

For more information, see Local Authentication Table.

Example: Configuring Advanced Policy-Based Routing Policies with Source Identity

This example shows how to configure an APBR policy with source identity and how to apply the APBR profile on a session that matches the APBR policy rules.

Requirements

This example uses the following hardware and software components:

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

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

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 a routing instance and a RIB group.

  • Create an ABPR profile.

  • 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 add an entry to a local authentication table.

  1. Enter the username, IP address, and user role details.

Step-by-Step Procedure

To apply APBR on traffic that matches 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 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 advance-policy-based-routing detail command.

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

Meaning

The command output displays the source identity details in the Source identities field.

Using DSCP as Match Criteria in APBR Rules

This topic includes the following sections:

Introduction

Application identification techniques rely on deep packet inspection (DPI). There are some cases where DPI engine might not be able to identify the application, for example—encrypted traffic. If you apply APBR rules on such traffic, the traffic undergoes normal processing without APBR functionality applied on it.

Starting in Junos OS release 19.3R1, SRX Series devices support configuring DSCP values in an APBR rule as match criteria to perform APBR functionality on the DSCP-tagged traffic.

You can configure DSCP value in addition to the other matching criteria of the APBR rule such as dynamic application, and dynamic application group.

By configuring the DSCP value in an APBR rule, you can extend the APBR service to the traffic with the DSCP markings.

Use Case

You can use APBR rules with DSCP as match criteria for the encrypted traffic.

Limitation

  • Support not available for configuring rules with DSCP value and URL category in a single APBR profile.

APBR Rule Lookup When Using a DSCP Value as Match Criteria

In a APBR rule, you can configure a DSCP value or dynamic applications or combination of both.

If you have configured both DSCP and dynamic application in a APBR rule, the rule is considered as match if the traffic matches all the criteria specified in the rule. If there are multiple DSCP values present in the APBR rule, then if any one criteria matches, it is considered as match.

A APBR profile can contain multiple rules, each rule with a variety of match conditions.

In case of multiple APBR rules in a APBR profile, the rule lookup uses the following priority order:

  1. Rule with DSCP + dynamic application

  2. Rule with dynamic application

  3. Rule with DSCP value

If a APBR profile contains multiple rules, the system performs rule lookup and applies the rule in the following order:

  • System applies the DSCP-based rules for the first packet of the session.

  • System continues to check if any application information available either from DPI classification or application system cache (ASC).

  • In the middle of the session, if DPI identifies a new application, the system performs a rule lookup and applies new rule (application-based rule or DSCP-based rule or combination of both) as applicable.

  • Identifying application and rule lookup continues till the DPI identifies an application as the final application or maximum reroute value is reached.

  • If the rule lookup does not match any rule, no further action is taken.

Lets understand how APBR performs rule lookup and applies the rules with the following two examples:

Example 1

In this example, you configure three APBR rules with— one with DSCP value 30, next rule with application as HTTP, and the third rule with both DSCP value as 30 and application as HTTP. Configure maximum route change value as 1 (default value).

Table 4 shows how APBR performs rule lookup and applies the rules.

Table 4: APBR Rules with DSCP and Dynamic Application

Session

Traffic Type

ASC Cache

DPI Classification

Matching Rule

First session

DSCP=30

NA

NA

Rule 1

Midstream session

DSCP=30

Application = HTTP

Yes

HTTP

Rule 3

The traffic switches because rule lookup matched the new rule.

When traffic switches based on rule change in the middle of the session, the count for maximum route change reduces to 0. Now no further route change takes place in this scenario.

Example 2

In this example, you configure three APBR rules with— one with DSCP value 30, next rule with DSCP value 60, and the third rule with both DSCP value as 30 and application as HTTP.

Table 5 shows how APBR performs rule lookup and applies the rules.

Table 5: APBR Rules with Only DSCP Values

Session

Traffic Type

ASC Cache

DPI Classification

Matching Rule

First session

DSCP=30

NA

NA

Rule 1

Midstream session

DSCP=60

Application = HTTP

Yes

DSCP=60

HTTP

Rule 2

Rule 3 does not match with traffic because DSCP value is changed from 30 to 60 in midstream.

Configure APBR Rules with DSCP Values as Match Criteria

This example shows how to configure APBR rules with DSCP values as match criteria.

Requirements

This example uses the following hardware and software components:

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

  • Any supported SRX Series device.

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

Overview

In this example, you want to forward HTTP traffic and traffic tagged with DSCP value 56 and DSCP value 46 to a specific device or interfaces at Site 1, Site 2, and Site 3 respectively. Security device forwards the traffic based on an application or DSCP value to a preferred route by using APBR feature.

When traffic arrives at the trust zone, APBR matches the traffic with configured APBR profile rules. If the traffic matches the rule, APBR forwards the traffic to the specific destination as defined in the APBR rule.

For example, you configure APBR to route the traffic to different destinations based on the type of the application as specified below:

  • Rule 1—Forward HTTP traffic from Client 1 to the Site 1 using next-hop address 192.0.2.254.

  • Rule 2—Forward traffic with DSCP value 56 and HTTP application to Site 2 using next-hop device 192.0.3.254.

  • Rule 3—Forward traffic with DSCP value 46 to Site 3 using the next-hop device 192.0.4.254.

Figure 4 shows the topology used in this example.

Figure 4: Topology for Advanced Policy-Based Routing (APBR) Configuration
Topology
for Advanced Policy-Based Routing (APBR) Configuration

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

Table 6: Configuration Parameters

Parameter

Value

Associated Parameter

Description

APBR profile

P1

Name of the APBR profile.

Configure the profile with rules to match the applications and DSCP values and specify destination (example: routing-instances) for the matching traffic.

RIB group

RI1.inet.0

Associated routing instance—RI1

Configure the RIB group to import interface route entries from inet.0, RI1.inet.0, RI2.inet.0, and RI3.inet.0.

RI1.inet.2

Associated routing instance—RI2

RI1.inet.3

Associated routing instance—RI3

Routing instance

RI1

  • Static route— 192.0.0.0/16

  • Next-hop—192.0.2.254

Configure the routing instances to include next-hop IP address. APBR forwards the qualified traffic destined for the static route to the next-hop device address in Site 1, Site 2, and Site 3.

RI2

  • Static route—192.0.0.0/16

  • Next-hop—192.0.3.254

RI3

  • Static route—192.0.0.0/16

  • Next-hop—192.0.4.254

APBR Rule

R1

  • Matching application—junos:HTTP

  • Associated routing instance—RI1

Configure the APBR rules and specify dynamic application or DSCP values as matching criteria.

APBR forwards the matching traffic to the associated routing instance.

R2

  • matching DSCP value— 56 and application—junos:HTTP.

  • Associated routing instance—RI2

R3

  • matching DSCP value— 46

  • Associated routing instance—RI3

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.

Configure APBR rule with DSCP and dynamic application as match criteria.

  1. Define security zones and interfaces.
  2. Define interface and security zones for the ingress interface connecting the client device.
  3. Configure the routing instances.
  4. Group one or more routing tables to form a RIB group called apbr-group and import routes into the routing tables.
  5. Define the APBR rule with dynamic application HTTP as match criteria.

    APBR routes the traffic matching the HTTP application to the routing instance RI1.

  6. Create another rule for DSCP and HTTP application.

    APBR routes the traffic matching the DSCP value 56 to the routing instance RI2.

  7. Define one more rule with DSCP value 46.

    APBR routes the traffic matching the DSCP value 46 to the routing instance RI3.

  8. Apply the APBR profile to the security zone.

Results

From configuration mode, confirm your configuration by entering the show security advance-policy-based-routing, 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.

Once you complete the configuration, 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.

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 application traffic or DSCP-tagged traffic matches the APBR profile.

  • The number of times traffic is switched to different route in the midstream.

Verifying Advanced Policy-Based Routing Sessions

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.

Release History Table
Release
Description
Starting in Junos OS release 19.3R1, SRX Series devices support configuring DSCP values in an APBR rule as match criteria to perform APBR functionality on the DSCP-tagged traffic
Starting in Junos OS Release 19.1R1, you can bypass application services for a session that is re-routed using the APBR rule.
Starting in Junos OS Release 19.1R1, you can configure advanced policy-based routing (APBR) policies by defining user source identity as one of the match criteria along with source addresses, destination addresses, and applications
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.