Understanding BGP on Palo Alto Networks Firewalls

Border Gateway Protocol (BGP) is the standard exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the Internet. Palo Alto Networks firewalls implement BGP within their Virtual Router instances (or Logical Routers in Advanced Routing mode), allowing them to participate in complex routing environments. This document covers key BGP concepts as implemented on PAN-OS.

This guide primarily uses terminology consistent with the legacy Virtual Router (VR) interface unless otherwise specified. Concepts are generally applicable to the Advanced Routing Engine (ARE) Logical Routers (LR) as well, though configuration paths might differ.

Core BGP Configuration

• Location: BGP is configured within a specific Virtual Router instance on the firewall ( Network > Virtual Routers > [Your VR Name] > BGP ). It's not a global device setting.
• Mandatory Settings: To enable BGP, you must configure:
  • Router ID: A unique 32-bit identifier for the BGP speaker within the AS, typically an IP address on the firewall (often a loopback). Must be unique within the BGP domain.
  • Local AS: The Autonomous System number the firewall belongs to.
• Enable: The BGP process must be explicitly enabled via a checkbox within the Virtual Router's BGP general settings ( Network > Virtual Routers > [Your VR Name] > BGP > Basic > Enable ).

Peering: eBGP vs. iBGP

Peering is the process of establishing a TCP session (port 179) between two BGP routers to exchange routing information.

• eBGP (External BGP): Used for peering between routers in different Autonomous Systems.
  • Typically used for connections to ISPs or other organizations.
  • Default Administrative Distance (AD) on PAN-OS is 20 (highly trusted).
  • By default, assumes peers are directly connected (TTL=1).
• iBGP (Internal BGP): Used for peering between routers within the same Autonomous System.
  • Used to propagate external routes throughout your own network and maintain consistent exit policies.
  • Default AD on PAN-OS is 200 (less trusted than IGPs like OSPF/RIP or static routes).
  • Does not assume direct connection; TCP session must be established.
  • Subject to the iBGP Split Horizon rule (needs full mesh, Route Reflectors, or Confederations).

Route Advertisement and Filtering

Controlling which routes are learned and advertised is crucial. PAN-OS (especially in legacy VR mode) uses specific profiles and rules:

• Redistribution Profiles:
  • Used to inject routes learned from other sources (like static routes, OSPF, connected interfaces) into BGP so they can be advertised to peers.
  • Found under Network > Virtual Routers > [Your VR Name] > Redistribution Profiles .
  • You define a profile, select the source protocols, set default metrics/tags, and optionally apply a Route Map for fine-grained control.
• Export Rules (Peer Group Level):
  • Control which routes from the firewall's BGP table are advertised out to specific BGP peers or peer groups.
  • Applied under Network > Virtual Routers > [Your VR Name] > BGP > Peer Group > [Group Name] > Export Rules .
  • Filters (using "Match") can target prefixes (via Prefix List), AS paths, communities, etc.
  • Action is typically "Allow" or "Deny". The first matched rule applies.
  • Can also set attributes (like MED, community, AS Path Prepend) on exported routes using the "Action" part.
• Import Rules (Peer Group Level):
  • Control which routes received from BGP peers are accepted into the BGP table and potentially installed into the firewall's main routing table (RIB).
  • Applied under Network > Virtual Routers > [Your VR Name] > BGP > Peer Group > [Group Name] > Import Rules .
  • Filters ("Match") are similar to Export rules.
  • Action is typically "Allow" or "Deny".
  • Can also set attributes influencing local path selection (like Weight, Local Preference) on imported routes.
• Conditional Advertisement:
  • A specific type of Export rule that allows advertising a prefix *only if* another specified prefix (the "non-suppress-filter" or "exist map" equivalent) exists in the firewall's BGP table or main RIB.
  • Configured within an Export Rule by enabling "Conditional Adv" and selecting the filter matching the dependency route.
  • Useful for advertising connectivity based on the availability of an underlying path.

Understanding the difference between Import (filtering/modifying received routes) and Export (filtering/modifying advertised routes) is critical for exam scenarios involving BGP policy.

BGP Peer Groups

Configuring multiple BGP peers, especially those with similar characteristics (like multiple peers within the same neighboring AS or multiple iBGP peers), can become repetitive. Peer Groups simplify this process significantly.

• Purpose: To group multiple BGP neighbors that share identical configuration parameters.
• Mechanism: You define a peer group template with common settings (e.g., peer type [iBGP/eBGP], remote AS, update source, timers, import/export rules, authentication). Then, you assign individual peer IP addresses to this group.
• Benefits:
  • Reduces Configuration Complexity: Avoids repeating the same parameters for each peer.
  • Improves Performance: The firewall can generate and send BGP updates more efficiently for members of the same group.
  • Easier Management: Changes applied to the peer group template automatically propagate to all member peers.
• Configuration Location: Network > Virtual Routers > [VR Name] > BGP > Peer Group

BGP Multihop

By default, eBGP peers expect to be directly connected (sharing the same subnet), meaning the neighbor IP address should be reachable in one Layer 3 hop (TTL=1). iBGP does not have this direct connection requirement, but the TCP session still needs to establish.

• Purpose: To allow BGP sessions to establish between peers that are *not* directly connected (separated by one or more intermediate routers).
• Mechanism: You configure the BGP peering with a Time-To-Live (TTL) value greater than 1. This allows the TCP packets forming the BGP session to traverse the necessary number of router hops without being discarded due to TTL expiry.
• Common Use Cases:
  • iBGP: Very common when iBGP peers within an AS are connected via multiple Layer 3 devices (e.g., peering between loopback interfaces). You typically set a reasonably high TTL (e.g., 64, 255).
  • eBGP: Less common but possible in specific scenarios (e.g., peering across a Layer 2 transport service where direct connection isn't feasible, certain IXP setups). Requires careful consideration of security and reachability. For eBGP multihop, you usually also need to disable the next-hop reachability check or use static routes, as the default check might fail.
• Configuration Location: Within the specific peer configuration under Network > Virtual Routers > [VR Name] > BGP > Peer Group > [Group Name] > Peer > [Peer Name] > Connection Options > Multihop . You specify the TTL value here.

BGP Attributes and Path Selection Overview

BGP uses attributes carried within Update messages to learn about network reachability and select the best path when multiple paths to the same destination exist. Understanding the key attributes and the order they are evaluated in is fundamental.

Knowing the main attributes and their preference order (Weight -> LP -> AS_PATH -> Origin -> MED -> etc.) is essential for the exam.

• Weight: Palo Alto/Cisco specific, locally significant only (not advertised). Highest weight preferred. Useful as a first-check preference on a single router.
• Local Preference: Used within an AS to choose the exit point. Higher is better. Standard mechanism for outbound traffic engineering. Default 100.
• Locally Originated: Routes injected via `network` or redistribution are preferred over learned routes.
• AS_PATH: List of ASes traversed. Shorter path length is preferred. Primary attribute for loop prevention and often for basic path selection.
• Origin Code: How the route entered BGP. Order of preference: IGP (i) > EGP (e) > Incomplete (?).
• MED (Multi-Exit Discriminator): Suggests entry point preference to a neighbor AS. Lower is better. Compared only among paths from the *same* neighboring AS by default.
• eBGP vs iBGP: eBGP learned routes are preferred over iBGP learned routes.
• IGP Metric to Next-Hop: If multiple paths tie up to this point, prefer the path whose BGP next-hop is closest according to the internal IGP metric.
• (ECMP): If enabled, multiple paths that are equal up to the IGP metric check can be used simultaneously.
• Oldest Path / Stability: Prefer the most stable (oldest) eBGP path.
• Router ID: Lowest BGP Router ID of the advertising peer is preferred.
• Neighbor IP Address: Lowest neighbor IP address is preferred.

BGP Best Path Selection Process

When a BGP router receives multiple paths for the same network prefix, it runs a deterministic algorithm to select a single "best" path to install in its routing table and advertise to peers. The process stops as soon as one path is determined to be better than the others based on the current step.

1. Discard paths where the N ext-Hop is inaccessible (cannot be resolved in the RIB).
2. Prefer highest W eight (Palo Alto/Cisco specific, local significance).
3. Prefer highest L ocal Preference (Highest is better, AS-wide).
4. Prefer path locally O riginated (network, redistribute, aggregate).
5. Prefer path with shortest A S_PATH length.
6. Prefer path with lowest O rigin code (IGP < EGP < Incomplete).
7. Prefer path with lowest M ED (Multi-Exit Discriminator) - requires comparison between paths from the same neighboring AS by default.
8. Prefer E BGP paths over IBGP paths.
9. Prefer path with the lowest I GP metric to the BGP next-hop router.
10. (If ECMP is enabled and configured) Mark multiple paths as eligible for M ultipath load sharing if they are equal up to step 9.
11. Prefer the oldest (most stable) E BGP path.
12. Prefer path from the BGP peer with the lowest Router ID .
13. Prefer path from the BGP peer with the lowest neighbor IP address.

Route Selection Mnemonic

Remembering the order can be tricky. Here's a mnemonic (adapt or create your own!):

BGP Attribute: Weight

Understanding the Impact of Setting BGP Weight

The BGP Weight attribute is a vendor-specific parameter (supported by Cisco, Palo Alto Networks, and others, but not part of the BGP standard RFCs) used to influence path selection on a single, local router . It provides a simple way to prefer one path over another *before* considering more standard BGP attributes.

• Primary Goal: To influence OUTBOUND Traffic Preference on the LOCAL ROUTER ONLY .
• Mechanism:
  • Weight is a numerical value assigned locally on the router where BGP paths are being evaluated.
  • Higher weight values are more preferred .
  • It is configured via local policy (e.g., Import Rules on Palo Alto, route maps on Cisco) applied to routes learned from specific neighbors.
  • Crucially, Weight is locally significant only ; it is **NOT** advertised or propagated to any other BGP peers (neither iBGP nor eBGP).
• Effect on Traffic:
  • Outbound Flow (Local Router): If a router learns multiple paths to the same destination, it will prefer the path with the highest Weight value *before* considering any other standard BGP attributes like Local Preference or AS Path length. This directly controls the outbound path choice *for traffic processed by that specific router*.
  • Outbound Flow (AS-Wide): Because Weight is not advertised, it has NO effect on the path selection decisions of other routers within your AS. Different routers might choose different paths if they don't have consistent Weight settings (or if Weight isn't the deciding factor).
  • Inbound Flow: Setting Weight locally has NO impact whatsoever on how external networks choose to send traffic *into* your network.
• Key Considerations:
  • Weight is the very first attribute checked in the BGP Best Path Selection algorithm (after checking next-hop reachability) on platforms that support it, making it the most powerful *local* influence.
  • Its primary use case is often to prefer a specific path learned directly on an edge router without needing to configure AS-wide policies like Local Preference immediately.
  • Because it's not propagated, using Weight alone can lead to inconsistent routing policies or potential routing loops within your AS if not carefully managed. Local Preference is generally preferred for consistent AS-wide outbound policy.
  • On Palo Alto firewalls, routes originated locally (via network statement or redistribution) are assigned a default weight of 32768 . Routes learned from peers have a default weight of 0 unless modified by an Import rule.

BGP Attribute: Local Preference

Understanding the Impact of Setting Local Preference

Setting BGP Local Preference (LP) is the standard and most effective method used *within* an Autonomous System (AS) to control outbound path selection. It allows an administrator to define which exit point the entire AS should prefer for traffic destined for external networks.

• Primary Goal: To influence OUTBOUND Traffic Preference (AS-Wide).
• Mechanism:
  • Local Preference is a well-known, discretionary BGP attribute, significant *only within* your local AS (it's passed between iBGP peers but not typically advertised to eBGP peers).
  • It's a numerical value where higher values are more preferred . The default value on most platforms (including Palo Alto) is 100 .
  • You typically set the Local Preference using an Import Rule (or route policy) applied to routes as they are *received* from your eBGP neighbors (e.g., your ISPs).
  • When an edge router learns routes from an external peer and applies a higher LP, it advertises this route with the higher LP to its iBGP neighbors within the AS.
  • All iBGP routers within the AS will compare the LP values for routes to the same destination and will prefer the path associated with the highest LP value.
• Effect on Traffic:
  • Outbound Flow: This directly controls which link *your AS* uses to send traffic *out* towards external destinations. If routes learned via ISP-A have LP 200 and routes learned via ISP-B have LP 100, your internal routers will choose the path via ISP-A to send traffic.
  • Inbound Flow: Setting Local Preference *within your AS* has NO direct impact on how external networks (like your ISPs or other ASes) choose to send traffic *into* your network. External peers do not see or typically care about your internal LP settings.
• Key Considerations:
  • Local Preference is evaluated very early in the BGP Best Path Selection algorithm (typically after Weight, if used), making it a very powerful and decisive factor.
  • It provides a consistent exit path policy across your entire AS (assuming LP is propagated correctly via iBGP).
  • It's the standard method for designating primary and backup internet connections for *outbound* traffic.

BGP Attribute: MED (Multi-Exit Discriminator)

Understanding the Impact of Changing Advertised MED

Modifying the MED (Multi-Exit Discriminator) value you send in your BGP advertisements is a specific technique used for traffic engineering. It's crucial to understand which direction of traffic flow it influences.

• Primary Goal: To influence INBOUND Traffic Preference (How others enter your AS).
• Mechanism:
  • You configure an Export Rule on your firewall to set a specific MED value on routes advertised TO an eBGP neighbor (e.g., ISP-A).
  • MED is an optional, non-transitive attribute; lower values are considered more preferable by default.
  • If your neighbor (ISP-A) has multiple connections to your AS and receives your advertisements over these connections, they *should* compare the MED values received *from you* for the same prefix.
  • ISP-A will prefer the path associated with the lowest MED value to send traffic back TO your network.
• Effect on Traffic:
  • Inbound Flow: You are providing a hint or suggestion to your neighbor about which link *they* should prefer when sending traffic *into* your AS. By advertising a lower MED on Link 1 and a higher MED on Link 2 (both to the same neighbor), you make Link 1 the preferred entry point *from that neighbor's perspective*.
  • Outbound Flow: Changing the MED you *advertise* has NO direct impact on how *your* firewall selects the best path to send traffic *out* to external networks. Your outbound path choice is determined by evaluating attributes (like Local Preference, AS Path) on routes you *receive* from your neighbors.
• Key Considerations:
  • MED is most reliably effective when influencing preference between multiple links connecting your AS to the SAME adjacent AS .
  • The neighboring AS must be configured to compare and honor MED values received from peers. Not all ISPs do, or they may only do it under specific peering agreements. ( Always Compare MED setting on the receiving router can force comparison across different peer ASNs, but is less common).
  • MED is lower in the BGP best-path selection order compared to Local Preference and AS Path Length.

Attribute Types: Transitive vs. Non-Transitive

BGP attributes carry information about routes, influencing path selection. They are categorized based on whether BGP routers are required to pass them along to other peers, especially if the router doesn't fully understand or implement the specific attribute. This is crucial for ensuring information propagates correctly across different Autonomous Systems.

Transitive Attributes

• Definition: An attribute that SHOULD be passed along (remain with the route update) even by BGP speakers that do not recognize the attribute type code.
• Purpose: To ensure that path information or policy signaling intended for downstream ASes reaches them, even if intermediate ASes don't actively use that specific information.
• Propagation: If a router receives a route with an unrecognized transitive attribute, it should mark the update as having a "partial" understanding but still forward the attribute unchanged to its peers.
• Types:
  • Well-known Transitive: Must be recognized by all BGP implementations and passed along (e.g., AS_PATH , NEXT_HOP ).
  
  • Optional Transitive: Not required to be recognized by all implementations, but if received, *should* be passed along if unrecognized (e.g., COMMUNITY , AGGREGATOR ).
  
• Analogy: Think of it like a package with special handling instructions written on it. Even if an intermediate mail carrier doesn't know what the instructions mean, they are obligated to keep the instructions attached to the package as it moves towards its destination.

Non-Transitive Attributes

• Definition: An attribute that MUST be discarded if the receiving BGP speaker does not recognize the attribute type code.
• Purpose: Used for signaling that is generally only relevant between directly adjacent ASes or within a single AS. There's no requirement for this information to propagate further if it's not understood.
• Propagation: If a router receives a route with an unrecognized non-transitive attribute, it simply removes that attribute before advertising the route to other peers.
• Types:
  • Optional Non-Transitive: Always optional (cannot be well-known). If unrecognized, it's discarded. If recognized, the router processes it according to its local policy. (e.g., MED - Multi-Exit Discriminator , ORIGINATOR_ID - used by Route Reflectors).
  
• Analogy: Think of it like a sticky note attached to a package meant only for the very next person handling it. If that person doesn't understand the note, they just remove it and pass the package along without it.

Common BGP Scenarios & Traffic Engineering

BGP Scenario: Influencing Outbound Traffic with Local Preference

Goal: Control which ISP link or path your internal users (within your Autonomous System - AS) prefer when sending traffic out towards external destinations.

Primary Tool: BGP LocalLP) . This is the standard and most effective attribute for this purpose within your own Autonomous System (AS).

Mechanism:

1. Local Preference is typically set using Import Rules (or route maps/policies) applied to routes as they are received from your external BGP peers (e.g., your ISPs) at your edge routers.
2. LP is a numerical value; higher values are preferred . The default is often 100 .
3. Assign a higher LP value (e.g., 200 ) to routes learned from your preferred ISP (ISP-A).
4. Assign a lower or default LP value (e.g., 100 ) to routes learned from your backup ISP (ISP-B).
5. Your edge routers advertise these routes (with their assigned LP values) to your internal BGP (iBGP) routers .
6. All iBGP routers within your AS compare the LP for routes to the same destination and choose the path associated with the highest LP as the best path.
7. This selected path dictates which edge router (and therefore which ISP link) is used for sending outbound traffic.

Example Scenario:

• Your Network: AS 65000
• Connection 1: Preferred ISP-A (AS 100) via Edge Router A
• Connection 2: Backup ISP-B (AS 200) via Edge Router B
• Policy on Edge Router A: Import Rule -> Set Local Preference = 200 for routes from ISP-A.
• Policy on Edge Router B: Import Rule -> Set Local Preference = 100 for routes from ISP-B.
• Result: All internal routers in AS 65000 will choose the path via Edge Router A to exit the network when both paths are available.

Effect on Traffic Flow:

This directly controls the OUTBOUND path selection for your entire AS. It dictates which link *your* network uses to send traffic *out*.

Setting Local Preference within your AS has NO direct impact on how external networks choose to send traffic INBOUND to your network.

What to Look For in Questions:

The question asks how to make your network prefer one path out over another. It involves comparing routes received from different external peers and applying policy as those routes enter your AS.

Visualizing the Flow:

Common BGP Scenarios & Traffic Engineering

Common BGP Scenarios & Traffic Engineering

Common BGP Scenarios & Traffic Engineering

Common BGP Scenarios & Traffic Engineering

iBGP Scalability: Confederations vs. Route Reflectors

The iBGP split-horizon rule (routes learned from one iBGP peer are not advertised to another iBGP peer) necessitates a full mesh of connections between all iBGP speakers within an AS. This doesn't scale well in large networks. Two primary solutions exist:

• Route Reflectors (RR): (Often preferred for simplicity)
  • An RR is an iBGP speaker allowed to break the split-horizon rule.
  • It reflects routes learned from one iBGP client peer to other iBGP client peers.
  • Clients only need to peer with the RR(s), drastically reducing the number of iBGP sessions required.
  • RRs introduce attributes like ORIGINATOR_ID and CLUSTER_LIST to prevent loops within the reflection topology.
• Confederations:
  • Purpose: To divide a single large AS into multiple smaller, private sub-ASes (confederation members).
  • Mechanism:
    • Within each sub-AS, a full mesh of iBGP peers (or Route Reflectors) is still required, but the mesh size is much smaller.
    • Peering *between* sub-ASes uses a modified form of eBGP (often called "Confederation eBGP" or EBGP).
    • Crucially, when routes cross sub-AS boundaries, BGP attributes like NEXT_HOP, MED, and Local Preference are preserved as if it were iBGP, unlike standard eBGP.
    • To the outside world (peers external to the confederation), the entire collection of sub-ASes still appears as the single, original public AS number. The sub-AS numbers are stripped from the AS_PATH when advertised externally.
  • Complexity: Generally considered more complex to design and configure than Route Reflectors.
  • Configuration Location: Sub-AS definition under Network > Virtual Routers > [VR Name] > BGP > Basic ; peer configuration specifies the peer's sub-AS.

Operational Aspects

• BGP States: Indicate the status of a peer session:
  • Idle : Initial state, no resources allocated.
  • Connect : Attempting to establish TCP connection (Client role).
  • Active : TCP connection failed, trying again (Server role, listening).
  • OpenSent : TCP established, OPEN message sent, waiting for peer's OPEN.
  • OpenConfirm : OPEN received, waiting for KEEPALIVE or NOTIFICATION.
  • Established : Peering successful, UPDATE messages can be exchanged. This is the desired state.
• Timers:
  • Keep Alive Interval: How often Keepalive messages are sent (Default: 30 seconds).
  • Hold Time: How long a router waits for a Keepalive or UPDATE from a peer before declaring it down (Default: 90 seconds, typically 3x Keepalive). Must be negotiated; the lower value proposed by either peer is used.
• High Availability (HA): In an Active/Passive setup, only the Active firewall establishes and maintains BGP sessions. Configuration is synchronized, allowing the Passive firewall to take over quickly if failover occurs. BGP Graceful Restart can help minimize disruption during failover if supported by peers.
• MP-BGP (Multiprotocol BGP): An extension allowing BGP to carry routing information for multiple network layer protocols (Address Families) beyond just IPv4 unicast, such as IPv6 unicast, VPNv4 (for MPLS VPNs), etc. Enabled under BGP > Basic > Enable MP-BGP . Requires specific AFI/SAFI configuration in Peer Groups/Peers (or Profiles in ARE).
• Route Dampening: A mechanism to penalize flapping (unstable) routes, suppressing them for a period to improve overall network stability. Configured globally under Network > Virtual Routers > [VR Name] > BGP > Dampening and applied via Import Rules. Use with caution as it can delay reconvergence.
• Graceful Restart: Allows a BGP speaker undergoing a restart (e.g., software upgrade, process restart) to signal its peers to temporarily retain its routes, avoiding widespread routing instability during the restart. Configured under BGP > Basic > Graceful Restart . Peers must also support Graceful Restart Helper mode.

Verification (CLI Commands)

Useful CLI commands for troubleshooting and verification (execute in operational mode):

• show routing protocol bgp summary : Displays a summary of all BGP peers, their state, uptime, and prefix counts. Quickest way to check peering status. (Use show routing protocol bgp peers for slightly more detail per peer).
• show routing protocol bgp peer : Shows detailed information about a specific peer, including configured options, timers, state, and counters.
• show routing protocol bgp rib-in peer : Shows routes received from a specific peer *before* import policies are applied. Essential for verifying what the neighbor is actually sending.
• show routing protocol bgp rib-out peer : Shows routes advertised *to* a specific peer after export policies are applied. Essential for verifying your advertisements.
• show routing route protocol bgp : Shows BGP routes that have been successfully selected as best paths and installed into the main IP routing table (RIB).
• show routing fib protocol bgp : Shows BGP routes programmed into the hardware forwarding plane (Forwarding Information Base). Useful to confirm if the data plane matches the control plane.
• show routing protocol bgp policy peer prefix : Simulates the effect of import or export policies on a specific prefix for a given peer, showing which rule matched and the outcome. Very useful for debugging policy rules.

Remember to use the correct Virtual Router context if multiple VRs exist: set system setting target-vsys before running VR-specific commands, or specify the VR in some commands (check command syntax).

Interactive BGP Quiz

Test your knowledge of Palo Alto BGP Concepts. Please answer all questions before submitting.