JN0-637 Advanced Policy-Based Routing (APBR)

Advanced Policy-Based Routing (APBR) Detailed Explanation

Overview

Traditional routing decisions are based solely on the destination IP address. Advanced Policy-Based Routing (APBR) enhances this by enabling custom routing decisions based on multiple criteria, such as source IP, application, or protocol. This provides granular traffic control, optimizing network utilization and meeting specific business requirements.

Core Concepts

1. Traffic Selection

Definition

Traffic selection involves identifying specific packets based on predefined criteria and applying custom routing rules to them.

Match Criteria

1. Source/Destination IP or Subnet:
   • Direct traffic from certain IP ranges to specific routing paths.
2. Application:
   • Match based on protocols (e.g., HTTP, FTP) or specific applications like video streaming.
3. Specific Ports:
   • Match packets based on source or destination port numbers (e.g., TCP 80 for HTTP).

Use Case

• Route video streaming traffic (e.g., Netflix) through a high-bandwidth ISP while routing general web browsing through a cost-effective ISP.

2. Routing Instance

Definition

APBR enables traffic to be forwarded into specific routing instances instead of the default routing table.

Features

• Segregated Routing Instances:
  • Each instance has its own routing table and policies.
• Custom Next-Hops:
  • Traffic can be directed to specific gateways based on policies.

Use Case

• A company with multiple ISPs may direct business-critical traffic through one ISP and less critical traffic through another.

3. Policy-Based Decisions

Definition

Policy-based decisions allow administrators to customize traffic routing behaviors beyond traditional routing protocols.

Capabilities

• Redirect traffic to a specific next-hop or routing instance.
• Apply differentiated routing for specific applications or users.

Use Case

• Optimize performance by routing latency-sensitive applications like VoIP through a low-latency ISP.

Configuration Examples

1. Basic APBR Configuration

This example routes HTTP traffic through a specific routing instance (ISP1).

Steps:

1. Define the policy statement:

   set policy-options policy-statement apbr-policy term http-traffic from protocol tcp
   set policy-options policy-statement apbr-policy term http-traffic from destination-port 80
   set policy-options policy-statement apbr-policy term http-traffic then routing-instance ISP1
   

2. Apply the policy to the relevant interface:

   set firewall filter filter-name term 1 from protocol tcp
   set firewall filter filter-name term 1 then accept
   set firewall filter filter-name term default then discard
   

2. Match by Source IP

Redirect traffic from a specific subnet (192.168.1.0/24) to a different routing instance (ISP2).

Steps:

1. Define the policy statement:

   set policy-options policy-statement apbr-policy term subnet-traffic from source-address 192.168.1.0/24
   set policy-options policy-statement apbr-policy term subnet-traffic then routing-instance ISP2
   

2. Apply the policy to the interface:

   set firewall filter source-filter term 1 from source-address 192.168.1.0/24
   set firewall filter source-filter term 1 then accept
   

3. Multiple Routing Instances

Use multiple routing instances to segregate traffic types (e.g., HTTP traffic to ISP1 and FTP traffic to ISP2).

Steps:

1. Define routing instances:

   set routing-instances ISP1 instance-type forwarding
   set routing-instances ISP2 instance-type forwarding
   

2. Define APBR policy:

   set policy-options policy-statement apbr-policy term http-traffic from destination-port 80
   set policy-options policy-statement apbr-policy term http-traffic then routing-instance ISP1
   
   set policy-options policy-statement apbr-policy term ftp-traffic from destination-port 21
   set policy-options policy-statement apbr-policy term ftp-traffic then routing-instance ISP2
   

3. Apply the policy globally or on specific interfaces.

Troubleshooting APBR

1. Policy Verification

Check the configured policies to ensure correctness.

Command:

show policy-options policy-statement apbr-policy

What to Verify:

• Ensure the match criteria align with the intended traffic.
• Confirm the next-hop or routing instance specified in the policy.

2. Session Monitoring

Verify if sessions are being routed correctly as per the APBR policy.

Command:

show security flow session

Key Output Fields:

• Policy Name: The APBR policy applied to the session.
• Routing Instance: The routing instance handling the session.

3. Trace Options

Enable trace options to debug APBR behavior.

Steps:

1. Enable trace options:

   set routing-options traceoptions file apbr-trace
   set routing-options traceoptions flag policy
   

2. View trace logs:

   show log apbr-trace
   

3. Look for entries showing policy evaluations and routing decisions.

Best Practices for APBR

1. Define Specific Policies:

   • Use precise match conditions to avoid unintended traffic redirection.

2. Test in a Lab Environment:

   • Validate APBR policies in a test environment before deploying in production.

3. Monitor Regularly:

   • Use session monitoring and logs to ensure policies function as intended.

4. Keep Policies Organized:

   • Use descriptive names for policies and terms for better manageability.

Advanced Policy-Based Routing (APBR) (Additional Content)

1. Application-Based PBR – Feature Dependency on AppSecure

Junos SRX supports Application-Based Policy-Based Routing, where traffic is routed based on identified applications such as Netflix, Zoom, or YouTube.

Important Requirement:

Application-based PBR requires AppSecure features (specifically AppID) to be enabled and properly licensed.
Without AppID, any reference to application or application-set in APBR match conditions will be ignored or ineffective.

Configuration Enablement:

set security policies default-policy permit-all
set applications application <app-name> ...
set security flow advanced-options appid-enable

Exam Reminder:

• Expect questions like:

  “Why isn’t application-based PBR matching Netflix traffic?”
  Correct answer: AppID is not enabled or not properly licensed.

2. APBR Packet Flow – Executed After Security Policy Evaluation

APBR does not take effect immediately upon packet arrival at the SRX. Instead, it is applied after the packet is accepted by the security policy engine.

Traffic Processing Order:

1. Packet Ingress

2. Zone and Interface Determination

3. Security Policy Evaluation (allow/deny decision)

4. Session Creation

5. APBR Match and Routing-Instance Selection

6. Forwarding Decision

Key Clarification:

APBR cannot override security policies. If the traffic is not allowed by a zone-based or global policy, PBR will not be evaluated.

Example Misconception:

• “Can APBR forward blocked traffic?”
  → No. Security policies must allow traffic first.

3. Interface-to-Routing Instance Binding – Required for Multi-ISP Scenarios

When using multiple routing instances (e.g., ISP1, ISP2) in APBR scenarios, interfaces must be explicitly bound to their corresponding routing instances.

Example Configuration:

set routing-instances ISP1 instance-type forwarding
set interfaces ge-0/0/1 unit 0 routing-instance ISP1

Without this binding, traffic may not exit through the intended routing instance, even if APBR correctly matches.

Common Scenario:

You have two ISPs and use PBR to direct VoIP traffic over ISP1 and web browsing over ISP2. Each egress interface must be assigned to the correct routing-instance.

4. Common Exam Pitfalls and Clarifications

Misconception	Why It’s Incorrect	Correct Understanding
APBR replaces routing policy	Misunderstands the design of APBR	APBR complements routing policy; both can coexist, but APBR provides flow-level control
Routing instance is always a VRF	Confuses APBR usage with MPLS VPNs	APBR uses forwarding-type routing-instances, not MPLS-based VRFs
Policies are global by default	Assumes APBR rules affect all traffic universally	APBR policies only apply to interfaces where they are explicitly attached
Application match always works	Ignores licensing and feature dependencies	App-based matching requires AppID, which must be enabled and licensed
All traffic is PBR-controlled	Misunderstands default fallback behavior	Only matched traffic is routed by PBR; others use the default routing table

Recommended Operational Commands – Summary Table

Objective	Command	Purpose
View session routing instance	show security flow session	See which routing instance is used per session
Check applied policy terms	show policy-options policy-statement <name>	View match and action structure for PBR policies
Debug routing decisions	set routing-options traceoptions flag policy	Enables tracing of policy-based routing evaluations
Monitor trace output	show log apbr-trace	Review routing-instance decision logic
Interface-instance binding check	`show interfaces terse	match routing-instance`

Quick Knowledge Check

1. Is APBR evaluated before or after security policy matching?
   → After.

2. Does APBR apply globally by default?
   → No. You must attach it to specific interfaces.

3. Can APBR override security zones or firewall policies?
   → No. It only influences routing after the policy allows the session.

4. Is AppID required for application-based routing?
   → Yes. AppSecure and AppID must be active and licensed.