PAN-OS BGP Route Redistribution for PCNSE Candidates

Welcome PCNSE candidates! This guide focuses on a critical networking topic for the Palo Alto Networks Certified Network Security Engineer exam: BGP Route Redistribution . Understanding how to effectively and safely redistribute routes into BGP on a PAN-OS firewall is essential for controlling network reachability and implementing traffic engineering policies.

Route redistribution is the process of taking routes learned via one routing source (like OSPF, RIP, static routes, or connected interfaces) and advertising them into another routing protocol, in this case, BGP. On a PAN-OS firewall, this is commonly done to announce internal network segments or specific static routes to external BGP peers, such as ISPs or partner networks.

This article leverages information primarily from the Palo Alto Networks official documentation and knowledge base, focusing on practical configuration, potential pitfalls, and exam-relevant tips.

Core Concepts: What is BGP Redistribution and Why Use It?

What is Route Redistribution?

At its core, route redistribution involves teaching one routing domain about routes known by another. Imagine you have internal networks running OSPF, some critical servers reached via static routes, and you need your internet service providers (ISPs), who speak BGP with you, to know how to reach these networks. Redistribution is the bridge.

• Source Protocol/Origin: The routing information source (e.g., OSPF, Static, Connected, RIP).
• Destination Protocol: The routing protocol receiving the redistributed routes (in our case, BGP).
• Redistribution Point: The device performing the translation – the PAN-OS firewall's Virtual Router (VR).

Why Redistribute Routes into BGP on PAN-OS?

Common use cases include:

1. Advertising Internal Networks: Making internal subnets (learned via OSPF, connected interfaces, etc.) reachable from the outside world via your BGP-speaking ISPs.
2. Announcing Specific Services: Advertising static routes for specific publicly accessible services hosted behind the firewall.
3. Multi-homing & Traffic Engineering: Controlling how external networks reach your internal resources when you have multiple BGP connections (e.g., primary/backup ISP links). This is achieved by manipulating BGP attributes during redistribution.
4. Replacing Default Routes: Instead of relying solely on default routes from ISPs, advertise your specific public IP ranges via BGP for more granular control and redundancy.

Sequence of a route being redistributed into BGP.

Core Concepts: PAN-OS Components for BGP Redistribution

In PAN-OS, BGP redistribution is configured within the Virtual Router (VR) settings. The key component is the Redistribution Profile .

Virtual Router (VR)

The VR is the fundamental routing instance on the firewall. All routing protocols (BGP, OSPF, RIP, Static) operate within the context of a VR. Redistribution rules bridge these protocols *within the same VR*.

• You configure BGP neighbors within the VR.
• You configure other routing protocols (like OSPF) or static routes within the same VR.
• You configure Redistribution Profiles within this VR to link them.

Redistribution Profile

This is the central object for controlling redistribution into BGP (and other protocols). You create one or more profiles within the VR.

Location: Network > Virtual Routers > (Select your VR) > Redistribution Profiles

Key elements of a Redistribution Profile:

• Name: A descriptive name (e.g., `Redist-Static-to-BGP`).
• Priority: Crucial! Determines the order of processing if multiple profiles could match a route. Lower numbers have higher priority (processed first). If a route matches a profile with an "Allow" action, processing stops for that route. If it matches a "No Redistribute" profile, it's blocked. Ranges from 1 to 255.
• Action:
  • redist (Allow): Allows matching routes to be redistributed.
  • no-redist (Deny): Prevents matching routes from being redistributed by this or lower-priority profiles. Often used at the top (low priority number) to block specific routes explicitly.
• Filter Type: Specifies the source of routes to consider:
  • Static
  • Connect (Directly connected interfaces included in the protocol)
  • OSPF (Specify OSPF route types: Intra-Area, Inter-Area, Ext-1, Ext-2)
  • RIP
  • BGP (Used for redistributing *from* BGP *to* other protocols, less common for our focus)
• Filter (Address Objects/Prefixes): Defines *which* specific routes (prefixes) from the selected source type should match this rule. You can use Address Objects, Address Groups, or manually define prefixes. This is where you prevent unwanted route leaks!
• Set Origin (for BGP): When redistributing *into* BGP, this sets the BGP Origin attribute. Default is usually `Incomplete` (?) or `IGP` (i) depending on the source. You can manually set it.
• Set Metric/MED (for BGP): Sets the Multi-Exit Discriminator (MED) value for redistributed routes. Used to influence inbound traffic preference for external peers. Lower MED is generally preferred.
• Set Local Preference (for BGP): Sets the Local Preference attribute. Used to influence outbound path selection *within your own AS*. Higher Local Preference is preferred.
• Set Community (for BGP): Allows tagging redistributed routes with BGP communities (standard or extended) for policy application by downstream peers or internally.
• Set AS Path Limit / Prepend (for BGP): Allows prepending your own AS number to the AS_PATH attribute to make the path less desirable for specific scenarios.

Configuration: Creating a Redistribution Profile

Let's walk through creating a basic Redistribution Profile to advertise a specific static route into BGP.

Steps:

1. Navigate to the Virtual Router: Go to Network > Virtual Routers and click on the name of the VR where your BGP instance and static route reside.
2. Go to Redistribution Profiles: Select the Redistribution Profiles tab on the left.
3. Add a New Profile: Click the Add button at the bottom.
4. Configure Basic Settings:
   • Name: Enter a descriptive name, e.g., `Redist-Static-WebServer-to-BGP`.
   • Priority: Assign a priority. For specific advertisements, a mid-range priority like `100` might be suitable unless you need it to override others. Lower numbers are higher priority.
   • Action: Select `redist` (Allow).
5. Configure Filters:
   • Filter Type: Select `Static` from the dropdown.
   • Address Based Filter: Click Add .
     • Select "Address Objects" or "IP Prefixes".
     • If using prefixes, enter `172.16.100.0/24`. You could also create an Address Object for this network and select it.
     • Set Match Type to `Exact` if you only want this specific prefix, or `Contains` if it's part of a larger aggregate you might define elsewhere (less common for specific static routes). Stick with `Exact` for this scenario.
6. Configure BGP Specific Settings (Optional but Recommended):
   • Expand the BGP section.
   • Set Origin: Choose `IGP` or `Incomplete`. `IGP` (i) generally indicates the route originated within your AS. `Incomplete` (?) often implies redistribution. Check Palo Alto defaults and best practices; `IGP` is often preferred over `Incomplete` if possible.
   • Set Metric (MED): If you have multiple BGP peers and want to influence incoming traffic, set a MED value here (e.g., `100` for primary, `200` for backup).
   • Set Local Preference: If you learn routes from multiple internal sources and want to prefer this path outbound *within your AS*, set a higher Local Preference (e.g., `150`). Default is often `100`.
   • Set Community: Add any communities if needed for signaling (e.g., `no-export`).
7. Click OK: Save the Redistribution Profile configuration.
8. Commit: Commit the changes to the firewall ( Commit > Commit ).

Flowchart: Creating a Basic Redistribution Profile.

Configuration: The Critical Role of Filtering

Filtering is arguably the most important aspect of route redistribution. Without proper filtering, you risk:

• Advertising Unintended Routes: Leaking internal private IP space (RFC1918) or routes you don't own to the internet.
• Creating Routing Loops: Especially with mutual redistribution or complex topologies.
• Overwhelming BGP Peers: Sending thousands of unnecessary specific internal routes instead of aggregates.
• Security Risks: Exposing internal network structure.

How Filtering Works in PAN-OS Redistribution Profiles:

1. Priority Matters First: Profiles are checked in order of priority (lowest number first).
2. Match Criteria: Within a profile, the firewall checks if a route existing in the VR's RIB matches the Filter Type (e.g., OSPF Ext-2) and the Address Based Filter (e.g., prefix list).
3. Action Taken:
   • If a match occurs and the Action is redist , the route is marked for redistribution (with specified attributes), and no further profiles are checked for this route .
   • If a match occurs and the Action is no-redist , the route is explicitly blocked from redistribution, and no further profiles are checked for this route .
   • If a route doesn't match any profile, it is not redistributed by default . There is no implicit "permit all".

Filtering Best Practices:

• Be Specific: Only redistribute the exact prefixes you intend to advertise. Use `Exact` match type where possible.
• Use `no-redist` Explicitly: Consider creating a high-priority (low number) profile with `no-redist` action to explicitly block known problematic ranges (e.g., RFC1918, default routes, loopbacks learned via IGP) before allowing specific routes in lower-priority profiles.
• Leverage Address Objects/Groups: For managing multiple prefixes, use Address Objects and Groups for easier maintenance.
• Filter by Source Type: Be granular with OSPF types (Intra, Inter, Ext-1, Ext-2) if needed. You might only want to advertise stable internal routes (Intra/Inter) and not externally learned ones.
• Aggregate When Possible: If advertising a large block of contiguous prefixes, consider summarizing them with a static route and redistributing the summary static route instead of all the specifics (requires careful planning).

State Diagram: Route Processing Through Example Redistribution Profiles.

Configuration: Setting BGP Attributes During Redistribution

Simply advertising routes isn't always enough. You often need to influence how those routes are treated by BGP peers (affecting incoming traffic) or how your own network prefers paths (affecting outgoing traffic). Redistribution profiles are where you set the *initial* BGP attributes for these routes.

Key attributes configurable within the Redistribution Profile's BGP section:

• Set Origin:
  • Purpose: Indicates how the route entered BGP. Part of the BGP best path selection.
  • Values: `IGP` (i - learned via IGP within originating AS), `EGP` (e - learned via EGP, historical), `Incomplete` (? - learned via redistribution).
  • Preference: `IGP` > `EGP` > `Incomplete`.
  • PCNSE Note: Know the preference order. Setting `IGP` is often desirable for redistributed routes if appropriate.
• Set Metric (MED - Multi-Exit Discriminator):
  • Purpose: Influences how a neighboring AS chooses to enter *your* AS if multiple entry points exist. It's a suggestion sent *to* your neighbor.
  • Behavior: Lower MED value is preferred (by default). Only compared among routes received from the *same neighboring AS*.
  • Use Case: Send a lower MED (e.g., 100) for routes redistributed towards your primary ISP and a higher MED (e.g., 200) towards your backup ISP for the same prefix.
  • PCNSE Note: Understand MED influences *incoming* traffic and lower is better.
• Set Local Preference:
  • Purpose: Influences path selection *within your own AS* for traffic going *out* towards the destination.
  • Behavior: Higher Local Preference value is preferred. Propagated throughout your entire AS via iBGP.
  • Use Case: If you learn the *same* prefix from multiple internal BGP routers (perhaps one path redistributed from OSPF, another from static), you can set a higher Local Pref on the redistributed route you prefer your AS to use for outbound traffic. Setting Local Pref during redistribution *to* eBGP peers is less common, as LP is typically used *within* an AS. However, you might set it if the firewall also has iBGP peers. More often, LP is set via Import policies for routes *learned* via eBGP.
  • PCNSE Note: Understand Local Pref influences *outgoing* traffic *within* your AS, and higher is better. Default is often 100.
• Set Community:
  • Purpose: Tags routes with community values for policy application. Can be informational or trigger actions in downstream routers (if they are configured to act on them).
  • Values: Standard (e.g., `no-export`, `no-advertise`) or custom Extended Communities.
  • Use Case: Tagging routes with `no-export` prevents your ISP from advertising them further. Tagging with custom communities like `65001:100` could signal a specific traffic treatment policy.
  • PCNSE Note: Know common standard communities and understand that communities are transitive (usually) unless filtered.
• Set AS Path Limit / Prepend:
  • Purpose: Manipulates the AS_PATH attribute to influence BGP path selection.
  • Behavior: Prepending your own AS number makes the path appear longer and thus less preferable to external peers.
  • Use Case: To make a backup path less desirable, prepend your AS number multiple times (e.g., `3` times) for routes advertised to the backup ISP.
  • PCNSE Note: AS Path Prepending influences *incoming* traffic (by making your path look longer to others), and shorter AS Path is preferred.

Traffic Engineering: Overview with Redistribution

Traffic Engineering (TE) in the context of BGP redistribution on PAN-OS primarily involves manipulating BGP path attributes for routes you *originate* (or inject via redistribution) to influence path selection, both for incoming and outgoing traffic.

Goals of BGP Traffic Engineering:

• Load Sharing/Balancing: Distributing traffic across multiple ISP links (often asymmetrical).
• Primary/Backup Links: Ensuring traffic prefers a primary link and only uses the backup upon failure.
• Policy Compliance: Directing specific types of traffic over particular links based on cost, latency, or agreements.
• Optimizing Performance: Selecting paths with better performance characteristics (though BGP itself mainly focuses on policy, not performance metrics like latency).

How Redistribution Enables TE:

When you redistribute routes (e.g., your public IP space announced via static routes) into BGP, the PAN-OS firewall becomes the point of origin for these routes in the BGP world. This gives you the power to set the initial BGP attributes:

• Influencing Inbound Traffic (How others reach you):
  • AS Path Prepending: Make paths look longer/less desirable via specific peers.
  • MED (Multi-Exit Discriminator): Suggest to a *single* neighbor which link they should prefer to reach you (lower MED preferred).
  • Community Signaling: Use communities that your ISP acts upon (e.g., a community to request lower preference within their network). Requires ISP cooperation.
• Influencing Outbound Traffic (How you reach others - Less direct via redistribution):
  • Local Preference: Primarily set via *Import* policies on learned routes to prefer one exit point over another *within your AS*. While you *can* set LP during redistribution, it's more relevant if you have iBGP peers on the firewall or complex internal routing affecting the choice *before* redistribution.
  • Selective Redistribution: Only redistributing certain prefixes towards specific peers can influence outbound path selection indirectly, but BGP best path on *learned* routes is the primary outbound control.

Traffic Engineering using MED and AS Path Prepending set during redistribution to influence inbound traffic.

Traffic Engineering: Using Attributes (MED, LP, AS_PATH)

Let's dive deeper into how specific attributes set during redistribution achieve TE goals.

1. Influencing Inbound Traffic (How others reach you)

• Multi-Exit Discriminator (MED):
  • Mechanism: Set different MED values in the redistribution profiles applied towards different eBGP peers for the *same prefixes*.
  • Goal: Make one path more attractive to your neighbor(s).
  • Configuration: In the Redistribution Profile's BGP settings, enter a numeric value in the `Set Metric (MED)` field.
  • Example: - Profile `Redist-to-ISP-A` (Primary): Set MED `100`. - Profile `Redist-to-ISP-B` (Backup): Set MED `200`.
    (Note: PAN-OS doesn't apply profiles directly to peers; you filter/set attributes within the profile itself. You might need separate profiles if attributes differ significantly per peer group or use Export rules for peer-specific manipulation *after* redistribution.)
    Correction/Clarification: While you set MED in the profile, applying *different* MEDs for the *same prefix* advertised to *different* peers usually requires BGP Export Rules applied to the peer groups/peers, which can modify attributes *after* redistribution. However, the initial MED is set here. If you only have one profile redistributing the route, all peers get that MED initially.
  • Gotcha: MED is non-transitive (only relevant between adjacent ASes) and is considered late in the BGP best-path selection process. A neighbor might ignore MED or prefer a path for other reasons (e.g., shorter AS_PATH, higher Local Preference set internally by them).
• AS Path Prepending:
  • Mechanism: Artificially lengthen the AS_PATH by adding your own AS number multiple times in the redistribution profile's BGP settings.
  • Goal: Make a path significantly less attractive globally (shorter AS_PATH is preferred).
  • Configuration: In the Redistribution Profile's BGP settings, use the `Set AS Path Limit` field (often used for prepending, e.g., enter '3' to prepend your AS 3 times). Check PAN-OS specific field name/behavior.
  • Example: Profile `Redist-to-ISP-B` (Backup): Set AS Path Prepend 3 times. The path will look like `65001 65001 65001` instead of just `65001`.
  • Gotcha: Effective but blunt. Can significantly impact reachability if the primary path fails and the prepended path is too long compared to other alternatives peers might have.

2. Influencing Outbound Traffic (How you reach others)

• Local Preference (LP):
  • Mechanism: Set a high LP value on routes you want your AS to prefer when sending traffic out.
  • Goal: Control exit point from your AS.
  • Configuration: In the Redistribution Profile's BGP settings, set `Set Local Preference`.
  • Relevance during Redistribution: As mentioned, LP is most effective when set on routes *learned* from eBGP peers (via Import Policy). Setting it during redistribution *to* eBGP peers has limited effect on the peer itself (LP is non-transitive between eBGP peers). It matters *if* the firewall propagates this route via iBGP to other routers *within your AS*, which might then use the LP to choose the firewall as their exit point.
  • Example: If firewall redistributes static route P with LP 150, and another internal router learns P via a different means with default LP 100, internal routers *within your AS* (learning via iBGP from the firewall) might prefer the firewall's path for P.
  • PCNSE Focus: Understand LP applies *within* the AS and higher is better. Primary tool for outbound TE is setting LP on *learned* routes via Import policy.

Traffic Engineering: Redistribution Examples

PCNSE Exam Focus: BGP Redistribution Tips & Tricks

Here are key takeaways and potential exam pitfalls related to PAN-OS BGP Redistribution:

• Configuration Location: Know it's under Network > Virtual Routers > [VR Name] > Redistribution Profiles .
• Profile Priority: Crucial! Lower number = higher priority. Processing stops for a route once it matches a profile (allow or deny). Understand how multiple profiles interact based on priority.
• Default Action: If a route doesn't match *any* redistribution profile, it is NOT redistributed . There's no implicit permit.
• Filtering is Paramount:
  • Know how to filter by Source Protocol/Type (Static, Connect, OSPF Intra/Inter/Ext1/Ext2, etc.).
  • Know how to filter by Prefix using Address Objects/Groups or direct IP Prefixes (`Exact` vs. `Contains` match types).
  • Understand the use of `no-redist` profiles (with high priority/low number) to explicitly block unwanted routes *before* allowing specific ones.
• Attribute Manipulation:
  • Origin: Know the types (`IGP`, `EGP`, `Incomplete`) and their preference order (`IGP` > `EGP` > `Incomplete`). Understand what PAN-OS might set by default and how to override it.
  • MED: Influences *incoming* traffic (neighbor's choice), lower is better, non-transitive between ASes.
  • Local Preference: Influences *outgoing* traffic (your AS's choice), higher is better, propagates within the AS (iBGP). Primarily set via Import Policy for TE.
  • AS Path Prepending: Influences *incoming* traffic (global choice), makes path longer/worse.
  • Communities: Know common standard communities (`no-export`, `no-advertise`) and their purpose.
• Redistribution vs. Export Policy: Understand that Redistribution Profiles handle the initial injection and attribute setting. BGP Export Policies (`Network > Virtual Routers > [VR] > BGP > Export`) are applied *later* and can *modify* attributes on a per-peer or per-peer-group basis before sending the BGP UPDATE. Exam questions might test this interaction.
• Verification Commands: Be familiar with basic CLI verification:
  • show routing protocol bgp redist-profile (See potential routes matched by a profile)
  • show routing route type static (or ospf, connect) (Verify the source route exists)
  • show routing protocol bgp rib-out (See routes BGP intends to advertise)
  • show routing protocol bgp neighbor advertised-routes (See exactly what was sent to a neighbor)
  • show routing fib (Check the Forwarding Information Base)
  admin@PA-FW> show routing protocol bgp neighbor 192.0.2.2 advertised-routes
  virtual-router: default
  peer: ISP-A-Peer (192.0.2.2)
  --------------------------------------------------
  Network Next Hop Metric LocPrf Weight Path
  *> 203.0.113.0/24 192.0.2.1 100 100 0 i <-- Redistributed Static
  Total routes advertised to neighbor 192.0.2.2: 1
• Common Mistakes/Gotchas:
  • Forgetting to Commit changes.
  • Incorrect filter logic (e.g., wrong prefix, wrong match type).
  • Priority conflicts between profiles.
  • Redistributing RFC1918 or other unwanted routes.
  • Expecting MED set during redistribution to work differently on different peers without using Export rules.
  • Troubleshooting without checking if the source route exists and is active in the main routing table (`show routing route`). Redistribution only considers active routes.

PCNSE Style Quiz: BGP Redistribution

Test your knowledge with these 20 questions covering PAN-OS BGP redistribution concepts.