📘 PCNSE BGP Route Selection, Traffic Engineering, and Exam Preparation

1. BGP Route Selection Process in PAN-OS

Palo Alto Networks firewalls follow a specific sequence to select the best BGP route:

Next-Hop Reachability: If the next-hop is reachable and it's the only path, select this route.
Weight: Prefer the path with the highest weight.
Local Preference: If weights are equal, prefer the path with the highest local preference.
Originated Routes: Prefer routes originated by the local router.
AS Path Length: Prefer the path with the shortest AS path.
Origin Type: Prefer routes with the lowest origin type (IGP < EGP < Incomplete).
MED: Prefer the path with the lowest Multi-Exit Discriminator (MED).
eBGP over iBGP: Prefer external BGP routes over internal ones.
IGP Metric to Next Hop: Prefer the path with the lowest IGP metric to the BGP next hop.
Router ID: Prefer the path with the lowest BGP router ID.

For a detailed explanation, refer to the Palo Alto Networks Knowledge Base article: What is the BGP Best Path Selection Process?

2. Mnemonic for BGP Route Selection

To help remember the BGP best path selection process in PAN-OS, you can use the following mnemonic:

N ever W alk L azily, O r A ll O ranges M ight E scape I nto R ivers.

N ext-Hop Reachability
W eight
L ocal Preference
O riginated by local router
A S Path (shortest)
O rigin Type (IGP < EGP < Incomplete - lowest is preferred)
M ED (Multi-Exit Discriminator - lowest is preferred)
E BGP over iBGP
I GP Metric to Next Hop (lowest)
R outer ID (lowest BGP Router ID)

3. Influencing BGP Route Selection

Administrators can manipulate BGP attributes to influence route selection:

Weight: Locally significant; higher weight is preferred.
Local Preference: Higher value is preferred; used to influence outbound traffic within an AS.
AS Path Prepending: Add multiple instances of your AS number to make a path less attractive to other ASes for inbound traffic.
MED: Suggest to external neighbors which path to prefer for inbound traffic; lower MED is preferred. This requires cooperation from the neighboring AS.
Route Maps: Apply policies to modify attributes based on match conditions (e.g., prefix lists, community lists).

4. BGP Communities for Traffic Engineering

BGP communities are tags that can be attached to routes to signal routing preferences to peers:

Standard Communities: 32-bit values (often represented as AS:NN ) used to group routes for policy decisions.
Well-Known Communities:
- no-export : Do not advertise this route to eBGP peers (stays within the current AS or confederation).
- no-advertise : Do not advertise this route to any peer (eBGP or iBGP).
- local-as (or no-export-subconfed ): Do not advertise this route outside the local AS, not even to other sub-ASes within a BGP confederation.
Custom Communities: ISPs often define their own communities to allow customers to influence routing, such as setting local preference on the ISP side, controlling route propagation to specific peers, or signaling for blackholing.

By tagging routes with specific communities, administrators can influence how upstream providers handle their traffic, affecting both inbound and outbound routing decisions.

5. BGP Use Cases and Sequence Diagrams

Below are common BGP use cases for traffic engineering with conceptual sequence diagrams represented using Mermaid JS. These diagrams illustrate the flow of advertisements and decision-making.

Use Case 1: Primary/Backup Outbound Path with Local Preference

Scenario: Your AS (AS65000) has two connections to the internet via ISP A (AS100) and ISP B (AS200). You want all outbound traffic to prefer the link through ISP A. If ISP A's link fails, traffic should use ISP B.

Method: Set a higher Local Preference on routes learned from ISP A on your border routers connecting to ISP A. Local Preference is shared among iBGP peers within your AS.

Diagram: Influencing Outbound Traffic with Local Preference

Use Case 2: Influencing Inbound Path to ISP with MED

Scenario: Your AS (AS65000) has two links to the same ISP (AS100). You want the ISP to prefer sending traffic to your AS via Link 1 instead of Link 2.

Method: Advertise your prefixes to ISP A with a lower MED value over Link 1 and a higher MED value over Link 2. The ISP must agree to honor MEDs.

Diagram: Influencing Inbound Traffic with MED

Use Case 3: Depreferencing Path for Inbound Traffic with AS Path Prepending

Scenario: Your AS (AS65000) is multi-homed to ISP A (AS100) and ISP B (AS200). You want to make the path through ISP B less attractive for inbound traffic, effectively making ISP A the primary for incoming routes.

Method: When advertising your prefixes to ISP B, prepend your own AS number multiple times. This makes the AS Path appear longer and thus less preferable.

Diagram: Influencing Inbound Traffic with AS Path Prepending

Use Case 4: Limiting Route Propagation with `no-export` Community

Scenario: Your AS (AS65000) advertises a specific prefix to a partner AS (AS700). You want the partner AS to use this route but not advertise it to any of its other eBGP peers.

Method: Attach the `no-export` well-known community to the prefix when advertising it to AS700.

Diagram: Using `no-export` Community

Use Case 5: Restricting Routes Within an Organization using `local-as` Community

Scenario: Your AS (AS65000) uses BGP internally. For a specific prefix (e.g., a management network), you want to ensure it's advertised to all iBGP peers within AS65000 but never leaves AS65000, even to eBGP peers or other sub-ASes in a confederation.

Method: Attach the `local-as` (also known as `no-export-subconfed`) well-known community to the prefix. Note: The original HTML used local-as . Standard BGP often refers to this as NO_EXPORT_SUBCONFED . In PAN-OS, this is typically handled by the `no-export` for eBGP peers and confederation boundaries unless more specific confederation policies are in play. `local-as` is more stringent, ensuring it doesn't leave the originating AS at all, even to confederation peers. For simplicity, we'll illustrate its general intent to keep routes very local.

Diagram: Using `local-as` Community

6. Configuring BGP Communities in PAN-OS

To configure BGP communities in Palo Alto Networks firewalls:

Navigate to Network > Virtual Routers and select your virtual router.
Under BGP , configure the necessary Import and Export rules.
In the Export rule, under the Action tab, set the desired community attributes (e.g., "no-export", or custom values like "65000:100").
To add multiple community attributes to routes being redistributed into BGP from other routing protocols, configure a redistribution profile and specify the communities under the Set Community section.

Note: Multiple community attributes can be added primarily to routes that are being redistributed into BGP. For more details, refer to the Knowledge Base article: Add Multiple Community Attribute to BGP routes .

7. Filtering BGP Routes Using Communities

To filter BGP routes based on community attributes:

Navigate to Network > Routing > Routing Profiles > Filters and select Community Lists .
Create a new community list by specifying the name, type (Regular or Extended), and the community values to match.
Apply the community list in a route map (within BGP Import/Export policies or Redistribution Profiles) to permit or deny routes based on the matched communities.

For detailed steps, refer to the documentation: Configure a Filter Community List .

8. Typical PCNSE Exam Questions for BGP

Based on publicly available information and common BGP topics, PCNSE exam questions related to BGP might cover areas like:

BGP Best Path Selection Process: Understanding the order of attributes (Weight, Local Preference, AS Path, Origin, MED, etc.).
BGP Attribute Manipulation: How to influence inbound/outbound traffic using attributes like Local Preference, MED, and AS Path Prepending.
BGP Communities: Purpose and use of standard, well-known (no-export, no-advertise, local-as), and custom communities.
PAN-OS BGP Configuration:
- Setting up BGP peers (eBGP, iBGP).
- Configuring route maps for filtering and attribute modification.
- Route redistribution into BGP.
- Using import/export policies.
- Configuring BGP Timers and other specific BGP settings within PAN-OS.
BGP Troubleshooting in PAN-OS:
- Checking BGP neighbor states.
- Verifying received and advertised routes.
- Using CLI commands for BGP (e.g., show routing protocol bgp ... ).
- Interpreting BGP runtime stats.
Differences between BGP and IGPs (like OSPF).
Scenarios involving BGP for redundancy or specific routing policies.
BGP in HA (High Availability) scenarios.
Packet flow involving BGP learned routes.

BGP Attribute Transitivity and Significance

BGP path attributes are pieces of information that describe a route and are used in the BGP best path selection process. They are categorized based on whether they are well-known or optional, and whether they are transitive or non-transitive.

Well-Known Attributes

Well-known attributes are expected to be recognized by all BGP implementations.

Well-Known Mandatory: These attributes must be present in every BGP update message and recognized by all BGP routers.
- AS_PATH: Transitive. Lists the Autonomous Systems (ASes) a route has traversed.
- ORIGIN: Transitive. Indicates how BGP learned about a particular route (IGP, EGP, or Incomplete).
- NEXT_HOP: Transitive (within an AS, changes at eBGP border). Specifies the IP address of the next-hop router to reach the destination.
Well-Known Discretionary: These attributes must be recognized by all BGP routers but are not required to be in every update message .
- LOCAL_PREF (Local Preference): Transitive within an AS (iBGP) , but not advertised to eBGP peers (except in confederations).
- ATOMIC_AGGREGATE: Transitive. Informs BGP speakers that a more specific route has been aggregated.

Optional Attributes

Optional attributes may not be recognized by all BGP implementations.

Optional Transitive: If a BGP router does not recognize an optional transitive attribute, it should still accept the route and pass the attribute on to its BGP peers, marking it as partial.
- COMMUNITY: Transitive. A tag to group routes for applying common routing policies.
- AGGREGATOR: Transitive. Specifies the AS number and router ID of the BGP speaker that performed route aggregation.
- EXT_COMMUNITY (Extended Community): Transitive. Provides more capabilities than standard communities, often used for MPLS VPNs.
- AS4_PATH: Transitive. Carries 4-byte AS numbers.
Optional Non-Transitive: If a BGP router does not recognize an optional non-transitive attribute, it should quietly ignore and discard the attribute and not pass it on to other BGP peers.
- MULTI_EXIT_DISC (MED): Non-transitive between ASes . It is advertised to external neighbors but not propagated further to other ASes.
- ORIGINATOR_ID: Non-transitive. Used in route reflection environments to prevent loops.
- CLUSTER_LIST: Non-transitive. Used in route reflection to prevent loops by listing cluster IDs the route has passed through.

Significance of Transitivity

The transitivity of an attribute determines its scope and how it propagates through the BGP network:

Transitive attributes are designed to be passed along from one BGP speaker to another, even if an intermediate router doesn't understand the attribute.
Non-transitive attributes are generally intended for a more limited scope. If a BGP router doesn't recognize a non-transitive attribute, it must discard it and not pass it to other peers.

All well-known attributes are inherently transitive (their transitive bit is set to 1).

Influencing Traffic with BGP Communities

BGP Communities are optional transitive attributes that act like "tags" attached to BGP routes. This allows for more flexible and scalable traffic engineering and policy enforcement.

How Communities Influence Traffic:

Tagging Routes: An administrator configures their BGP router to attach specific community values to routes being advertised to BGP peers (e.g., an ISP).
Policy Matching on Receiving Router: The receiving BGP router (e.g., ISP's router) is configured with policies (often using route maps) that look for these community values.
Applying Actions: If a route matches a community value defined in a policy, the receiving router applies a predefined action. This action can modify other BGP attributes or control advertisement of the route.

Common Use Cases for Traffic Influence:

Influencing Inbound Traffic (via ISP):
- Setting Local Preference on ISP side: A customer tags a route with a community that signals their ISP to set a specific Local Preference for that route within the ISP's network. For example, community ISP_AS:70 might mean "set Local Preference to 70", while ISP_AS:120 means "set Local Preference to 120". This influences which of the customer's links the ISP prefers for traffic destined to the customer.
- AS Path Prepending by ISP: A customer can send a community that instructs the ISP to prepend its AS number multiple times when advertising the customer's routes to specific peers or regions, making that path less attractive. For instance, community 65001:XXX might mean "prepend once to AS XXX".
- Selective Advertisement/Blackholing: Communities can signal an ISP not to advertise a route to certain peers/regions (e.g., 35133:0:174 meaning "do not export to AS174") or to blackhole traffic for a specific prefix (often used in DDoS mitigation).
Influencing Outbound Traffic (within your AS):
- While Local Preference is the direct attribute for outbound traffic, communities received from an eBGP peer can be used internally to set Local Preference on your border routers differently for different learned routes.
Controlling Route Propagation (Well-Known Communities):
- NO_EXPORT : Prevents the route from being advertised to any eBGP peer outside the local AS (or confederation).
- NO_ADVERTISE : Prevents the route from being advertised to any BGP peer (iBGP or eBGP).
- LOCAL_AS (or NO_EXPORT_SUBCONFED ): Prevents the route from being advertised outside the local AS, including to other sub-confederations in a BGP confederation scenario. (Note: `LOCAL_AS` is often more restrictive, keeping it within the originating AS only).
Signaling for Specific Services:
- Communities can be used to tag routes that should receive special treatment, like QoS marking or specific firewall policies, as they traverse a network.

The effectiveness of influencing an ISP's traffic engineering using communities depends entirely on the ISP offering such a service and documenting the community values and their corresponding actions.

Always refer to the latest PCNSE blueprint and study materials from Palo Alto Networks for the most accurate exam topic coverage.

Palo Alto Networks BGP CLI Troubleshooting Commands

Troubleshooting BGP involves checking configuration, neighbor states, route advertisements, received routes, path selection, and underlying connectivity. Palo Alto Networks firewalls provide a range of CLI commands for this. Remember to execute commands within the correct Virtual Router (VR) context if you are not using the default VR.

Common Convention: Replace placeholders like , , , , and with your actual configuration values.

1. Checking BGP Configuration

First, ensure the BGP configuration is correct and loaded.

Show Running BGP Configuration (Specific VR): show config running xpath /config/devices/entry[@name='localhost.localdomain']/network/virtual-router/entry[@name=' ']/protocol/bgp
Displays the BGP section of the running configuration for the specified virtual router. Useful for a quick review.
Show Parsed BGP Configuration: show routing protocol bgp config vr
Shows how the system has interpreted and loaded the BGP configuration. Good for verifying settings like Router ID, AS number, peer details, and policies.

2. Checking BGP Neighbor Status

Verify if BGP sessions are established and stable.

Show BGP Peer Summary: show routing protocol bgp summary vr
Provides a quick overview of all BGP peers, their state (Idle, Connect, Active, OpenSent, OpenConfirm, Established), uptime, and prefix counts (PrefRcvd). 'Established' is the desired state.
Show Detailed BGP Peer Information: show routing protocol bgp peer vr
Gives extensive details for each peer, including state, timers, configured options, error codes (if any), capabilities negotiated, and counters for messages sent/received.
Show Specific BGP Peer Details: show routing protocol bgp peer-group peer vr
Focuses on a single peer, showing all the detailed information from the previous command but filtered for easier reading. Replace with the name defined in your BGP config.

3. Checking Received and Advertised Routes

Examine the BGP Routing Information Base (RIB) tables.

Show Routes Received from a Peer (Adj-RIB-In): show routing protocol bgp rib-in peer vr
Shows all routes received from a specific neighbor *before* any inbound policy/filtering is applied. Crucial to see what the neighbor is actually sending.
Show Specific Prefix Received from a Peer: show routing protocol bgp rib-in peer prefix vr
Filters the Adj-RIB-In for a specific prefix, showing its attributes (AS_PATH, NEXT_HOP, MED, LOCAL_PREF, Community, etc.) as received.
Show Routes Advertised to a Peer (Adj-RIB-Out): show routing protocol bgp rib-out peer vr
Shows all routes being advertised to a specific neighbor *after* outbound policy/filtering has been applied. Useful to verify your export policies.
Show Specific Prefix Advertised to a Peer: show routing protocol bgp rib-out peer prefix vr
Filters the Adj-RIB-Out for a specific prefix, showing its attributes as sent to the neighbor.
Show BGP Local RIB (Loc-RIB): show routing protocol bgp loc-rib vr
Shows the BGP routes that have passed inbound policies and are candidates for the main routing table. This includes routes from all peers and locally originated routes.
Show Specific Prefix in BGP Loc-RIB: show routing protocol bgp loc-rib prefix vr
Shows details for a specific prefix in the Loc-RIB, including all available paths considered by BGP and indicating which one was selected as the best path ('*' symbol) based on the BGP path selection process. This is key for troubleshooting path selection issues.

4. Checking the Main Routing Table

Verify if the best BGP routes are installed in the firewall's main RIB.

Show All Routes: show routing route vr
Displays the entire IP routing table for the VR. Look for flags indicating the protocol (e.g., 'B' for BGP).
Show Only BGP Routes in RIB: show routing route type bgp vr
Filters the routing table to show only routes learned via BGP that were selected as best and installed.
Show Route for Specific Destination: show routing route destination vr
Checks the routing table for a specific destination prefix to see which route is currently active.

5. Testing Connectivity

Ensure basic IP reachability to the BGP neighbor.

Ping Neighbor: ping vr host
Tests L3 connectivity to the BGP peer's IP address using the correct VR context.
Traceroute to Neighbor: traceroute vr host
Helps identify routing issues along the path to the neighbor.

6. BGP Debugging (Use with Caution)

Warning: Debugging can significantly impact CPU performance. Use it sparingly in production, only when necessary, and disable it immediately after troubleshooting.

Enable Basic Routing Debugs (Often a Prerequisite): debug routing basic on debug
Enable Specific BGP Debugs (Choose relevant options): debug routing bgp ?
List available BGP debug options. Common choices include:
- debug routing bgp all on debug (Very verbose, use as last resort)
- debug routing bgp errors on debug (Logs BGP protocol errors)
- debug routing bgp events on debug (Logs state machine transitions, connection attempts)
- debug routing bgp keepalives on debug (Logs keepalive messages)
- debug routing bgp notification on debug (Logs sent/received notification messages - indicates errors)
- debug routing bgp updates on debug (Logs sent/received update messages - can be very verbose)
- debug routing bgp state on debug (Focuses on state changes)
- debug routing bgp route on debug (Logs route processing/installation)
Example: debug routing bgp events on debug
View Debug Logs: less mp-log routed.log
View the routing process log file. Use spacebar to page down, 'q' to quit.
tail follow yes mp-log routed.log
Follow the log file in real-time (Ctrl+C to stop).
Disable Debugs (CRITICAL STEP): debug routing bgp all off debug debug routing basic off debug
Ensure you turn off ALL debugs you enabled.

7. Packet Capture (Use with Caution)

Warning: Packet captures can also impact performance, especially with broad filters or high traffic rates. Use specific filters and disable captures promptly.

Used to inspect the raw BGP packets being exchanged (TCP Port 179).

Configure Capture Filter (Example for BGP with neighbor 192.168.1.1): debug dataplane packet-diag set filter match source 192.168.1.1 destination-port 179 protocol 6 debug dataplane packet-diag set filter match destination 192.168.1.1 source-port 179 protocol 6
This sets up two potential match conditions for traffic *to* or *from* the neighbor on TCP port 179 (BGP). Adjust IPs and add interface filters if needed using `ingress-interface ` or `egress-interface ` within the `filter match` command. Use `debug dataplane packet-diag set filter on` to enable the filter.
Configure Capture Stages (Common stages for BGP): debug dataplane packet-diag set capture stage receive file rx_bgp.pcap debug dataplane packet-diag set capture stage transmit file tx_bgp.pcap debug dataplane packet-diag set capture stage drop file drop_bgp.pcap
Captures packets at different processing points. 'receive' (entering interface), 'transmit' (leaving interface), 'drop' (dropped by firewall).
Enable Capture: debug dataplane packet-diag set capture on
Show Capture Settings/Status: debug dataplane packet-diag show settings
Disable Capture (CRITICAL STEP): debug dataplane packet-diag set capture off
View/Export Capture Files:
Use an SCP client to copy the .pcap files from the firewall (usually located in `/opt/pancfg/mgmt/debug/` or similar, path might vary) or use TFTP/SCP export commands:
scp export debug-pcap from mp-log rx_bgp.pcap to @ : tftp export debug-pcap from mp-log rx_bgp.pcap to
Analyze the pcap files using Wireshark.

8. Clearing and Resetting BGP Sessions

Used to force route re-advertisement or reset a stuck session.

Soft Reset (Inbound): clear routing protocol bgp peer soft in vr
Requests the neighbor to resend its full RIB without tearing down the TCP session. Requires route-refresh capability negotiation.
Soft Reset (Outbound): clear routing protocol bgp peer soft out vr
Resends the local router's full RIB to the neighbor without tearing down the TCP session.
Hard Reset: clear routing protocol bgp peer vr
Tears down the BGP session (including the TCP connection) and attempts to re-establish it. More disruptive than a soft reset.

9. Checking System Resources

High CPU or memory usage can impact routing protocol performance.

Show System Resources: show system resources follow
Monitors CPU and memory usage in real-time. Look for high utilization in the `routed` (routing) process on the management plane or high dataplane CPU if captures/debugs are running. (Ctrl+C to stop).