Objective: This article will record the steps taken and scenarios simulated during BGP lab sessions involving the PA 5020.
Scenario 1: A single ISP, with an eBGP peering between the PaloAlto and a CISCO ISP router.
The above network diagram shows the basic setup. The objective of this scenario is to advertise the “public” IP range “owned” by the company, which for the purposes of the lab will be the 10.70.0.0/16 range. This range should be visible to a client on the internet as being reachable via AS 65531 and 65532
The relevant config on the cisco ISP router is standard BGP configuration as follows:
router bgp 6553
no synchronization
bgp log-neighbor-changes
neighbor 10.69.1.1 remote-as 65531
no auto summary
The above configuration is staple amount cisco routers. Further cisco configuration is omitted throughout this document since it is very similar to the above.
The next section explores the PA configuration. However not much depth is provided since this is written in the PA official documentation [1]
1. First we define e1/1 as being our WAN facing ethernet interface. We define a normal L3 interface, with appropriate IPs, zones, and so on. Due to step 2, ensure that under the “advanced > other info” tab, you enable “untagged subinterface”
2. We next need to define an untagged interface eth1.1 containing the “public” IP range 10.70.0.0/16. This is necessary since the BPG process on the PA needs to know which routes to import from the IP routing table into the BGP RIB [Routing Information Base]. Since in our scenario the 10.70.0.0/16 subnet is terminated directly on the firewall (and NAT is used to direct traffic to the servers), we need some way of inserting a route containing the range into the routing table. This is achieved by defining the subinterface as eth1.1, with no tagging, as a normal Layer 3 interface, containing an IP in the range, in our case 10.70.0.1/16. The end result should be similar to the following:
3. Next, we configure the BGP process to setup an adjacency with the ISP cisco router. This is done under “Network > Virtual Routers > Default > BGP”
a. Enable BGP
b. Fill in the correct router ID (normally this is the same as the WAN interface IP) and local AS number (in our case 65531 as per network diagram)
4. Move to the “Peer Group” tab, and create a new peer group. Add a new neighbor and fill in the appropriate peer details such as neighbor IP, AS and so on. Most of the options can be left as default.
a. Commit the changes and see if the BGP adjacency is formed. This can be checked from “network > virtual routers > more runtime stats > bgp > peer”. A status of established means a successful adjacency
5. As mentioned in step 2, we need to inform the BGP process which routes to advertise from the IP routing table. This is done via redistribution profiles. Create a new redistribution profile. In this lab, only connected routes need be used:
Apply the redistribution profile to BGP by going to “Network > Virtual Routers > Default > BGP > redist rules”. All options can be set as default. Once commited, the connected routes should be visible under the local RIB tab under “more runtime stats” for BGP.
6. Last, we need to need to inform BGP which routes from the local RIB to advertise to neighbors. In our case, this would be the 10.70.0.0/16 range. This is done via export rules, which is configurable from “Network > Virtual Routers > Default > BGP > Export”. Select the peer group defined earlier, and under the match tab, enter the value of 10.70.0.0/16.
Once committed, you will see the route advertised to the peer under the RIB OUT tab of the BGP section of “more runtime stats”:
7. Apply any NAT and firewall rules to the 10.70.0.0/16 range as is normally done
Scenario 2: Dual ISPs, with 2x eBGP peerings between the PaloAlto and CISCO ISP routers.
As the above network diagram shows, we now have two ISPs communicating with the PaloAlto, each in its own AS. In this case, both ISPs are terminated on the same eth1 of the Palo Alto. Normally in real life these would be two separate interfaces, each with it’s own public IP. Before any BGP configuration is performed, dual ISP documentation as outlined in [2] should be tested, to ensure outbound traffic paths are also redundant.
The palo alto configuration for this scenario is very similar to the previous scenario. However there are several points of note:
1. When configuring the second BGP neighbor (the second ISP), make sure to place this neighbor in a separate peer group. This gives more flexibility when configuring route maps as we do later on, at the cost of some additional configuration. In this scenario, we arrive at this configuration:
2. Unlike normal firewall deployments, where symmetric routing is very important, in BGP scenarios like the one just described, asymmetric routing is the norm. There is a very distinct difference between outbound routes, and inbound routes. The outbound routes are determined by the default route, but the inbound route is determined by the BGP process. In such a situation, it is very possible to have traffic incoming from ISP_A, only to be routed out of ISP_B. This is to be expected.
3. However, even with the above taken into consideration, the company will want to be able to influence which path incoming traffic takes. While outgoing traffic is within our complete control, and we can choose which ISP to send it to, incoming traffic is a different issue since 3rd party ISPs control traffic flow. In order to influence incoming traffic to prefer eg. ISP_A, we need to lengthen the number of AS in the path that is sent to ISP_B. Since other BGP routers look at the number of AS in the path, ISP_B will look less attractive and ISP_A will be used.
This is achieved by perpending the local AS (65531) multiple times to the route before sending to ISP_B. In the palo alto, this is done via export rules, using the AS Path section. In our case, we prepended our local AS twice, to seem and advertised this to our secondary ISP
This is where keeping the two ISP peers in seperate peer groups comes in handy. When defining export rules like the one above, you can only specify which peer group it will be applied to, but not to each individual neighbor.
So in essence, one needs to define two export rules, one with no AS path options, and the other with 1 or more as “prepend” under AS Path as shown above. The first export rule will be bound to the primary ISP peer group, while the second export rule will be bound to the secondary ISP peer group. This will cause the same route to be advertised differently to different ISPs, as can be seen in the RIB OUT section of the palo alto:
Important: the above will only work if the ISPs themselves do not filter out duplicate AS numbers in the AS path.
References:
David Vassallo's Blog 
Question on the sub-interface and route distribution rule on Scenario2:
how can I have a connected route to put into RIBout when I’m advertising the same AS through both ISP interfaces? Should I have an Ip address on each ISP interface on the PAN from that AS IP block (10.70.0.0/16) ?
I trying to test this in a lab, at the moment I have 1 interface with ISP1 addressed assigned, and sub-interface with an address from the AS IP block (10.70.0.0/16) assigned. if the interface on ISP1 goes down then I lose my connected route to distribute to ISP 2.
answering my own question – I found this article by Palo Alto: https://live.paloaltonetworks.com/t5/Configuration-Articles/BGP-Redistribution-Rules-to-Explicitly-Advertise-Host-Routes-and/ta-p/63123
I decided to try it but basically use my ARIN IP block (in my case it’s a /24 but you can use a /16 or whatever you have).
There key here is to go to the BPGP menu, then click on the last tab and instead of giving the redistribution rule a name, just give it the network address with subnet mask e.g. 192.168.1.0/24