Palo Alto Networks : Implementing Conditional Advertising in BGP

Palo Alto networks have an interesting feature in their BGP module called “Conditional Adv” – this is found in the Network > Virtual Routers > default > BGP > Conditional Adv tab of the GUI. There are no concrete examples in their KB of how to implement this, so here is a rundown of why and how you could use this feature. It is analogous to the cisco conditional BGP advertising feature.

Scenario:

Imagine that, due to availability requirements, you have two ISP points of presence in your network. Either two separate ISPs,  or maybe two different physical connections from the same ISP (the latter is my case). Each of these links has BGP running over them, normally each link would have a /30 subnet which contains only 2 IP addresses – your firewall IP and the ISP’s gateway IP. The idea is that you would like to have not only outbound traffic redundancy (that is relatively easy since you just need to configure a policy based route with monitoring to your primary ISP – lots of documentation on this scenario exists), but to also have incoming traffic redundancy. To give a concrete example, let’s say you own the public IP range 1.1.1.0/30. You would need this range to be primarily advertised over the primary ISP link. Should this link for any reason go down, you would then need to advertise the same range to the secondary ISP link. You could play around with BGP path attributes, and use the usual tricks like pre-pending your AS number multiple times to increase the BGP “weight” over the secondary link. However, this is not entirely reliable because an upstream BGP process may overwrite your carefully planned BGP attributes.

Diagrammatically:

You can see that we only want to advertise our public IP range to the “GM” peer, unless that link fails and we then need to advertise to the “GG” peer.

Configuration

The BGP configuration starts off pretty standard. See my previous blog post for some more details, a quick run-down follows:

1. On the palo alto external interface, define your public IP range

2. Under network > virtual routers > default, open the “redistribution profiles” tab and create a profile that will redistribute your IP range into the BGP routing process. Make sure the “redist” button is selected.

3. Move on to the BGP tab, and enter your appropriate router ID and AS number

4. On the “peer groups” sub-tab, enter the appropriate peer configuration:

As you can see above, we insert both GM and GG

5. Under the “redist rules” tab, define a rule that allows the PA to redistribute our previously configured redistribution profile into BGP:

6. In this case, I left the “import” tab empty since I’d like to accept routes the peers send

7. In the “export” tab we have an “allow” rule, advertising our public IP range, and a deny rule so we do not advertise anything else. 

Two points of note here. First, the deny rule at the bottom is quite important. You do not want to advertise more routes than you have to, failing to do so may lead to your WAN link becoming a “transit link” and passing traffic that isn’t generated by your organisation. Second, more importantly, note that in the export allow rule, I defined both GG and GM in the “used by” section

At this stage, if we now were to check the ISP routers, we’d see the 1.1.1.0/30 range advertised to both the routers… normal BGP operation up to this point. In fact, we can see the PA is advertising the route to both ISP routers:

8. Setting up conditional advertising, under the “Conditional Adv” tab. Create a new policy.

• In the “used by” section, select only the secondary ISP connection (GG in my case), since you would like the conditional advertising to only ever be applied to the secondary link.
• In the “non-exist filter” section, you need to specify which route from the local bgp rib you would like to monitor. (sidenote, to view the local bgp RIB you can do so from the GUI or by issuing show routing protocol bgp loc-rib). Unfortunately you are not allowed to monitor on the 0.0.0.0/0 route, so you have to arrange with your ISP to advertise at least one non-default route. In the case, the ISP is advertising an unused IP assigned to a loopback interface on their router, which is 2.2.2.1/32, as seen in my local RIB:

As long as the route 2.2.2.1/32 exists in the RIB, it means my primary ISP connection is up and I do not need to advertise to my secondary ISP. So we choose that route as the non-exist filter:

• Should the monitored route, fail, only then advertise my public range to GG, so we define our public IP range in the “advertise filters” tab

 

 

Commit the changes, and once done issue the command “show routing protocol bgp policy cond-adv”, which should output something similar to:

 

VIRTUAL ROUTER: default (id 1)
==========
Peer/Group: secondary
Suppress condition met: yes
Suppress condition (Non-exist filter):
name: GM_Loopback
AS pattern: 65532
Destination: 2.2.2.1
hit count: 2
Route filter (Advertise filter):
name: AdvertiseToGG
Destination: 1.1.1.0/30
hit count: 1
———-

Should you see “Suppress condition met: no”, you may need to disable the primary ISP bgp peer, commit, and re-enable the bgp peer. If you now check the routes that the PA is advertising, you will see it only advertising to our primary peer GM:

If I now purposely shut down the primary peer, the suppress condition will not be met and the public IP range is now advertised to the secondary peer GG:

And turning it back on reverses it, advertising only to GM, our primary peer.