Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Advanced Policy-Based Routing on NFX Devices

 

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. Juniper devices support advanced policy-based routing (APBR) to address these challenges.

This topic includes the following sections:

Application Identification

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

Juniper 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

Juniper devices 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 require 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.

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:

  • 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 NFX Series device.

Requirements

This example uses the following hardware and software components:

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

  • NFX150 device with Junos OS Release 18.2 or later.

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

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 NFX Series device.

  • NFX 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.