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, allowing them to participate in complex routing environments. This document covers key BGP concepts as implemented on PAN-OS.

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

Peering: eBGP vs. iBGP

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 .
iBGP (Internal BGP): Used for peering between routers within the same Autonomous System. Used to propagate external routes throughout your own network. Default AD on PAN-OS is 200 .
Peer Groups: These are highly recommended for simplifying configuration. They allow you to group peers with similar configuration parameters (like AS number, timers, authentication, route policies) instead of configuring each peer individually.
Multihop: For iBGP peers that are not directly connected (multiple L3 hops away), you need to configure BGP Multihop under the peer configuration, specifying a TTL value greater than 1. This allows the BGP TCP session to establish across intermediate routers.

Route Advertisement and Filtering

Controlling which routes are learned and advertised is crucial. PAN-OS 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 .
Export Rules: Control which routes from the firewall's BGP RIB (Routing Information Base) are advertised out to specific BGP peers or peer groups. Filters can match on prefixes, AS paths, communities, etc. Action is typically "Allow" or "Deny".
Import Rules: Control which routes received from BGP peers are accepted and potentially installed into the firewall's main routing table (RIB). Filters are similar to Export rules. Action is typically "Allow" or "Deny".
Conditional Advertisement: A specific type of Export rule that allows advertising a prefix *only if* another specified prefix (the "exist map") exists in the firewall's routing table. Useful for advertising connectivity based on the availability of an underlying path.

Note on Order: For incoming routes, Dampening (if configured) is applied first, followed by Import Rules. For outgoing routes, Export Rules determine what is sent.

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 .
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.
- 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*.
- 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.
- 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.
- MED is lower in the BGP best-path selection order compared to Local Preference and AS Path Length.

In Summary: Advertise MED to influence how others enter your network (Inbound). Use Local Preference (on received routes) to influence how you exit your network (Outbound).

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

In Summary: Set Local Preference (via Import Rules on received routes) to control how your AS exits towards external networks (Outbound). Use MED or AS Path Prepending (via Export Rules on advertised routes) to influence how others enter your network (Inbound).

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.

In Summary: Use Weight for strong local outbound preference on a single router. Use Local Preference for consistent AS-wide outbound preference . Use MED/Prepending to influence inbound preference .

Common BGP Scenarios & Traffic Engineering

BGP provides numerous attributes that allow network administrators to influence routing decisions. Understanding these scenarios is key to managing traffic flow effectively.

Scenario: Influencing Outbound Traffic (Your Egress Choice)

Goal: Control which ISP or path your internal users take to reach external destinations.

Primary Tool: Local Preference (LP) . Set via Import Rules on routes learned from peers. Higher LP is preferred.

Mechanism: By assigning a higher LP value (e.g., 200) to routes learned from your preferred ISP (ISP-A) compared to the backup ISP (ISP-B, default 100), you tell all routers within your AS to use ISP-A as the exit point when both paths are available.

What to Look For: The question asks how to make *your network* prefer one path *out* over another. It involves comparing routes *received* from different peers.

Scenario: Influencing Inbound Traffic (Neighbor's Ingress Choice)

Goal: Control which of your links external networks use to send traffic *to* your network.

Primary Tools:

AS Path Prepending: Set via Export Rules towards the *less* preferred peer(s). Shorter path length is preferred globally.
MED (Multi-Exit Discriminator): Set via Export Rules . Lower MED is preferred. Primarily effective between you and a *single adjacent AS* with multiple links between you. Less reliable globally.

Mechanism (Prepend): You advertise your prefixes to the backup ISP (ISP-B) with your AS number repeated several times (e.g., 65000 65000 65000 ). External networks see this longer path and prefer the shorter path advertised via your primary ISP (ISP-A, e.g., 65000 ).

Mechanism (MED): Advertise your prefix to the same neighbor ISP over two links, setting MED 100 on the primary link and MED 200 on the backup link. The neighbor ISP (if they honor MED) will prefer the link where they received the lower MED.

What to Look For: The question asks how to make *other networks* prefer sending traffic *to you* via one link over another. It involves modifying attributes on routes you *advertise*. Look for keywords like "inbound," "attract," "less preferred entry point."

Scenario: Using BGP Communities for Policy

Goal: Tag routes with specific values to signal policy intentions to BGP peers (or for internal use).

Primary Tool: Community Attribute . Set via Export Rules , matched via Import/Export Rules.

Mechanism: You attach a specific community value (e.g., well-known like no-export FFFF:FF01, no-advertise FFFF:FF03, or custom values) to a route advertisement. The receiving peer, if configured to recognize that community, performs a specific action (e.g., does not advertise the route further to eBGP peers).

What to Look For: The question mentions tagging routes, signaling actions to peers, or preventing propagation based on agreed-upon signals.

Scenario: Conditional Route Advertisement

Goal: Advertise a prefix only if a specific condition is met, typically the existence of another route.

Primary Tool: Conditional Advertisement feature within Export Rules , using an "Exist Map".

Mechanism: You configure an Export Rule to advertise Prefix A. Within the rule, you enable Conditional Advertisement and point it to an "Exist Map" that matches Prefix B. The firewall checks its routing table (RIB); if Prefix B exists, Prefix A is advertised. If Prefix B is not present, Prefix A is withdrawn or not advertised.

What to Look For: The question states a requirement to advertise something *only if* something else is present (e.g., advertise my network only if I have a default route).

Scenario: Overriding BGP for Specific Traffic/Prefixes

Goal: Force traffic for a specific destination or traffic originating from the firewall itself down a path different from the BGP best path.

Primary Tools:

Static Routes: With a lower Administrative Distance (AD) than BGP (eBGP=20, iBGP=200).
Policy Based Forwarding (PBF): Can override routing table for specific flows based on source/destination/port etc. (Beyond BGP attributes).
Import Rules: Setting high Local Preference for *specific* learned prefixes.

Mechanism (Static): A static route with AD 10 will always be preferred over an eBGP route (AD 20) or iBGP route (AD 200) for the same prefix, useful for forcing firewall-originated traffic.

Mechanism (Import LP): Make a specific prefix learned via a non-default path more attractive using a higher LP just for that prefix.

What to Look For: The question involves overriding the normal BGP decision, handling specific destinations differently, or controlling traffic *from the firewall*. Mention of Administrative Distance often points towards Static Routes.

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

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.

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. You configure Enable Sender Side Loop Detection for eBGP multihop to prevent potential loops.
Configuration Location: Within the specific peer configuration under Network > Virtual Routers > [VR Name] > BGP > Peer Group > [Peer Group Name] > Peer > [Peer Name] > Connection Options > Multihop . You specify the TTL value here.

Important: When using multihop, especially for iBGP peering between loopback interfaces, ensure you have underlying IGP (like OSPF) or static routes providing reachability between those loopback addresses.

BGP Attributes and Path Selection

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.

Weight: Palo Alto 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.
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.

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

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.

Significance: This distinction is fundamental to how BGP operates across the diverse implementations on the internet. Transitivity ensures essential path information (like AS_PATH) and widely used optional information (like Communities) can traverse ASes that might not have the latest BGP features, while non-transitivity prevents misunderstood or locally-relevant information (like MED) from propagating unnecessarily.

Key Takeaway: Steps higher in the list are more significant. A path chosen because it has a higher Local Preference (Step 3) will win, even if another path has a shorter AS_PATH (Step 5).

Route Selection Mnemonic

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

N o W ay L azy O ld A nts O ften M ake E xcellent I nternet M aps, E xcept R arely I n P aris!

( N ext-Hop, W eight, L ocal Pref, O riginated Locally, A S_PATH, O rigin Code, M ED, E BGP>IBGP, I GP Metric, M ultipath(ECMP), E BGP Age, R outer ID, Neighbor IP )

Operational Aspects

BGP States: Indicate the status of a peer session:
- Idle : Initial state, no resources allocated.
- Connect : Attempting to establish TCP connection.
- Active : TCP connection failed, trying again.
- 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.
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).
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.
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 .
Route Dampening: A mechanism to penalize flapping (unstable) routes, suppressing them for a period to improve overall network stability. Configured globally under BGP > Dampening Profiles and applied via Import Rules.
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. Peers must also support Graceful Restart.

iBGP Specifics

Split Horizon Rule: To prevent loops within an AS, a route learned from one iBGP peer is *never* advertised to another iBGP peer.
Full Mesh Requirement: Because of the split horizon rule, all iBGP speakers in an AS must peer directly with each other to ensure all routers receive all iBGP-learned routes. This doesn't scale well.
Scalability Solutions:
- Route Reflectors (RR): An RR can reflect iBGP-learned routes to other iBGP peers (clients), breaking the split horizon rule in a controlled way. Clients only need to peer with the RR, not each other.
- Confederations: Divides a large AS into smaller sub-ASes, reducing the iBGP mesh requirement within each sub-AS. Appears as a single AS to external peers.

Verification (CLI Commands)

Useful CLI commands for troubleshooting and verification:

show routing protocol bgp peers or show routing protocol bgp summary : Displays the status of BGP peers (State, Uptime, Prefixes Received).
show routing protocol bgp peer detail : Shows detailed information about a specific peer.
show routing protocol bgp rib-in : Shows routes received from peers *before* import policies are applied.
show routing protocol bgp rib-out : Shows routes advertised *to* peers after export policies are applied.
show routing route protocol bgp : Shows BGP routes that have been successfully 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).

Understanding these concepts, attributes, and the selection process provides a solid foundation for configuring, managing, and troubleshooting BGP on Palo Alto Networks firewalls.