Dev-Knot
Posts Tags Categories Contact
Dev-Knot

BGP Conditional Advertisement – Palo-Alto NGFW

Palo Alto BGP Condi Adv Documentation

This article will outline how to configure conditional advertisements when utilizing multiple up-links from a Palo-Alto acting as an edge device on your network. Conditional Advertisement is an advanced routing feature, which is introduced at a Cisco’s CCIE level. I will be re-using the LAB topology from my previous post, as it works perfectly with this scenario.

What is Conditional Advertisement ?

The Border Gateway Protocol (BGP) conditional advertisement feature provides additional control of route advertisement, depending on the existence of other prefixes in the BGP table.

– https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16137-cond-adv.html

A defined prefix must exist in the FIB in order to suppress the condition, therefore not advertising the desired routes to the less preferred neighbor. This is useful when you want full and definite control of ingress and egress traffic to your network when multi-homing to different ISPs. Both BGP sessions will be up simultaneously, however until the monitored prefix is no longer found in the route-table, the condition will be suppressed (Not Advertised). Once the prefix is not in the route-table, the condition will be met and the advertisement will be propagated to the secondary, less preferred neighbor.

ISP 1 = Most Preferred (Monitor received prefix 192.168.100.1/32 from ISP-1-B)

ISP 2 = Less Preferred

ISP 1 will be advertising a loop-back in which the Palo-Alto will monitor (utilizing ping checks). Contact your upstream provider and explain to one of their engineers what you’d like to do and the reason for your request. A simple RFC 1918 loopback /32 can be coordinated between your ISP and your organization to be advertised.  _PA’s do not allow a default-route to be monitored as part of the BGP Conditional advertisement. From a service-providers standpoint, this should not be a difficult request although it may take some work, as BOGONS are filtered in and out of global route tables. _You don’t have to depend on your service provider advertising a specific route though… feel free to get creative. After all, BGP only looks at the local-fib – you can monitor any route coming from any where (BGP,OSPF,ISIS).

Lets get to business! – Here is the advertisement routes from ISP-1 Router – (preferred ISP) – We somehow managed to get the ISP to advertise 192.168.100.1/32 and we will monitor this prefix under our cond-adv tab/bgp process on our edge PA.

Now, lets verify our IMPORT statement on our Palo-Alto. We are only allowing a default-route and prefix 192.168.100.1/32.

Lets talk about the EXPORT side. Create export statements specifying the Public IP of your public facing servers, etc. Even though we are advertising to both peers, the conditional advertisement SUPPRESSES the advertisement. At this point, since the condition hasn’t been configured, normal BGP behavior will send the routes to both peers.

Also, create a DENY policy to prevent any other routes from advertising (expected BGP behavior to re-advertise to other eBGP peers). Pay close attention to the ‘Used By’ section.

I’m selecting both PEERS to advertise the public route 2.2.2.2/32 and the DENY action for the ‘no-routes’ This is a common practice and the beauty of BGP; the full control. Put your security hat on and think of these export policies as actual firewall security policies. They are read from top to bottom in this case.

  1. Create an interface LOOPBACK, if the IP is a /32. Otherwise, create a secondary subnet on a L3 Interface. This is important as the default behavior of the PA will affect our advertisement.
  2. Create a re-distribution and specify either a profile or simply input the prefix.
    1. Redistribution is required as we’re literally bringing in a directly connected interface (Loopback) or a IP from an interface into BGP.

Lets select the “Conditional ADV” tab now.

It’s very important to specify the “USED BY” as the SECONDARY, LESS PREFERRED peer. Otherwise, this won’t work. As you can see, I have selected “ISP-2” as it’s my secondary peer. The “Non Exist Filters” specifies the IP Prefix that I am monitoring from ISP-1. If that peer session were to drop, the prefix 192.168.100.1/32 would disappear from my routing table, therefore the condition would be triggered and the route would be advertised to the Secondary-Peer, “ISP-2”.

Below, is the “Advertise Filters” tab. Here you will input the Public Server IP that you want to control advertisement of.  What this says, “Used By” – The peer that the prefix will be advertised to, once the ‘Non Exist Filters” prefix is non-existent in the routing table.

This out put displays the condition being SUPPRESSED, since the prefix 192.168.100.1/32 is PRESENT in the routing table.

admin@PA-VM> show routing protocol bgp loc-rib VIRTUAL ROUTER: default (id 1)

Prefix Nexthop Peer Weight LocPrf Org MED flap AS-Path 0.0.0.0/0 172.16.65.0 WAN-ISP-1 0 100 i/c 0 0 64511 *192.168.100.1/32 172.16.65.0 WAN-ISP-1 0 100 i/c 0 0 64511 > *0.0.0.0/0 172.16.64.0 WAN-ISP-2 0 200 i/c 0 0 64496 *192.168.1.0/24 192.168.1.2 Core-Router 0 100 igp 0 0 *2.2.2.2/32 Local 0 100 i/c 0 0

total routes shown: 5

admin@PA-VM> show routing protocol bgp policy cond-adv VIRTUAL ROUTER: default (id 1)

Peer/Group: WAN-ISP-2 Suppress condition met: yes Suppress condition (Non-exist filter): name: Loop-to-monitor AFI: bgpAfiIpv4 SAFI: unicast Destination: 192.168.100.1 hit count: 17 Route filter (Advertise filter): name: Routes-To-Advertise AFI: bgpAfiIpv4 SAFI: unicast Destination: 2.2.2.2 hit count: 3 ———- Peer/Group: ISP-2 Suppress condition met: yes Suppress condition (Non-exist filter): name: Loop-to-monitor AFI: bgpAfiIpv4 SAFI: unicast Destination: 192.168.100.1 hit count: 17 Route filter (Advertise filter): name: Routes-To-Advertise AFI: bgpAfiIpv4 SAFI: unicast Destination: 2.2.2.2 hit count: 3 ———-

Now, I will shut down the Peering Session from the BGP edge router at ISP-1. This will pull the prefix 192.168.100.1/32 from the Routing Table on the Palo Alto and will meet the condition, therefore advertising the public server IP out the Secondary-Peering session, ISP-2.

admin@PA-VM> show routing protocol bgp loc-rib VIRTUAL ROUTER: default (id 1)

Prefix Nexthop Peer Weight LocPrf Org MED flap AS-Path *0.0.0.0/0 172.16.64.0 WAN-ISP-2 0 200 i/c 0 0 64496 *192.168.1.0/24 192.168.1.2 Core-Router 0 100 igp 0 0 *2.2.2.2/32 Local 0 100 i/c 0 0

total routes shown: 3

admin@PA-VM> show routing protocol bgp policy cond-adv VIRTUAL ROUTER: default (id 1)

Peer/Group: WAN-ISP-2 Suppress condition met: no Suppress condition (Non-exist filter): name: Loop-to-monitor AFI: bgpAfiIpv4 SAFI: unicast Destination: 192.168.100.1 hit count: 19 Route filter (Advertise filter): name: Routes-To-Advertise AFI: bgpAfiIpv4 SAFI: unicast Destination: 2.2.2.2 hit count: 3 ———- Peer/Group: ISP-2 Suppress condition met: no Suppress condition (Non-exist filter): name: Loop-to-monitor AFI: bgpAfiIpv4 SAFI: unicast Destination: 192.168.100.1 hit count: 19 Route filter (Advertise filter): name: Routes-To-Advertise AFI: bgpAfiIpv4 SAFI: unicast Destination: 2.2.2.2 hit count: 3 ———-

Keep in mind that BGP offers many knobs to traffic-engineer IN-bound and OUT-bound traffic. Utilizing MED is a way to steer traffic inbound, although – this will work only when dual-homing to the same ISP AND must be enabled/allowed by the upstream ISP.

When the MED option isn’t viable, utilizing pre-pend will utilize AS-PATH as a way to discourage upstream routers from selecting the less-desired route.

Also, keep in mind that most providers will have BGP communities they will share with their customers. Make sure to review this with your upstream provider and find out what is the best option for you. Finally, never forgot about old-faithful for outbound-exiting traffic.: Local-pref.