Dev-Knot
Posts Tags Categories Contact
Dev-Knot

Dual ISPs BGP – Palo Alto Networks

 

 

First things first! I passed the BGP Exam for the Nokia SRA Certification. I am now planning to deviate a bit and obtain my Sec+ and see where that takes me.. Anyways..

I’ve been very interested in Palo Alto Networks lately and I’m low-key starting to think about the certification path for PA.  I want to take some time and go over a Dual ISP connection utilizing a PA at the edge. I’m hoping to provide some insight from both a Service Provider  and Enterprise standpoint. The goal is to have a highly redundant WAN connection utilizing the PA.

Something I want to start keeping in mind:

<td>
  16 bit
</td>

<td>
  Reserved for use in documenation & sample code.
</td>

<td>
  [<a href="http://www.iana.org/go/rfc5398">RFC5398</a>]
</td>

Topology:

ISP 1 ( AS 64511 ) will be adveritising a default-route via 172.16.65.0/31 interconnect with the PA on eth1/4.

ISP 2 ( AS 64496 ) will be adveritising a default-route via 172.16.64.0/31 interconnect with the PA on eth1/1.

The Enterprise LAN will be peering with the PA via iBGP on Gi0/0 and eth1/7 on the PA from Autonomous System 64500

—————————————————————————————————————————————————————-

From ISP 1 – a VPRN (VRF) 100 is configured, advertising a default-route.

From ISP 2 – a VPRN (VRF) 200 is configured, advertising a default-route.

Here is a snippet from the Nokia VRF that’s providing internet service connection to the Palo Alto. A similar configuration exisist on the ISP 1 router.

From the Palo Alto – The initial steps to take are the following:

  1. Create an “Untrust” zone. This zone will be facing the Internet (ISP1 & ISP2).

Normally, I would suggest micro-segmenting these zones, but this requires a bit more policy creation. Example would be, 1 zone for ISP 1 and a different zone for ISP 2 for an absolute zero-trust architecture.

  1. Create a Management Profile which simply allows ICMP (pings) for troubleshooting and verification purposes.

Here is what the Layer 3 Interfaces look like:

We should have IP connectivity between our Palo-Alto and both of our ISP’s! We’re officially connected to the internet… sort of.

Now for the fun stuff, BGP connections!

Lets start with the Palo-Altos.

  1. Select the  “Virtual Routers’ setion under the Network tab.
  2. Select the “BGP” tab.
  3. ENABLE the BGP protocol by checking the box.
  4. Assign a Router ID. This can be one of the two IP’s on the interfaces facing our WAN services or a loopback (preffered).
  5. Input your local AS Number.
  6. Make sure to UN-CHECK “Reject Default Route”
    1. Both ISP’s will be advertising us Default-Routes. We’ll select one with BGP techniqures as a primary.
  7. Make sure to CHECK “Install Route”
    1. This is necessary if we want to install routes from BGP / Local FIB into the Global Routing Table on the Palo Alto.
  8. Depending on what model Palo-Alto you have, I would suggest creating a BFD profile and enabling this on your WAN connection for a fast-fail over detection to minimize downtime for your internal users.
    1. To create a BFD Profile:
      1. Network > Network Profiles > BFD Profile.
  9. This should be enough for the “General” Tab.

let’s move over to the “Peer Group”

  1. Add a new Peer Group, lets call this ISP 1 – Re-create the steps for ISP 2.
    1. Name: ISP 1
    2. Type: EBGP
  2. Add a new peer.
    1. Name: WAN-ISP-1
    2. Peer-AS: 64511
    3. Select the appropriate Interface / IP Address
    4. Input the appropriate /31 peer IP of the WAN connection.
    5. Under Advanced, make sure the Inherit Protocol’s Global BFD Porifle is selected.
    6. Select OK and commit.

Here is what the BGP Peer Group section should look like at this point:

Now, verify our BFD sessions..

All looks good!  Lets verify we’re seeing a default-route from both peers:

From the Local-RIB (And the Route Table) under the “More Runtime Stats” we are installing the default-route from our peer at ISP 1 – 172.16.65.0.

What if that peer is a 1G connection, but our Peer at ISP 2 should be our Primary WAN interface, as it’s a 10G interface? Let’s play with BGP now.

First, lets make sure all our outgoing traffic is going out or preffered exit path ( ISP 2) – let’s change our Local Pref on routes from ISP 2 to be more prefferd over ISP 1.

Navigate to BGP > Import and Add a new policy.

  1. Create a new rule that’s used by ISP-2.
  2. Under the Match tab, select the “From Peer’ – “WAN-ISP-2.”
  3. Unde the Action tab, up the Local Preference to 200 and select OK .
  4. Repeat the steps above and hard set the LP to 100 on WAN-ISP-1.
  5. Commit and let’s compare the route-table from our previous snippet.

Here is the Local-RIB, selecting the default-route from ISP-2.

And verifying the Global Route Table as our preffered exit point:

Looks good! All traffic is now routing out 172.16.64.0, which is our preffered 10G WAN interface to ISP-2.

Now how do we influence traffic to come into our AS via ISP 2 in hopes of avoiding asymmetrical routing? Well.. we can prepend if we’re advertising routes or advertise a more specific route to the prefferred neighbor and aggregate the routes advertised to the less preffered neighbor. The MED values are not helpful in this case, as we are peering with two separate providers.

We won’t worry about this for now, as we are not adveritisng any public routes to our providers, we simply need internet for our business.

Lets go ahead and redestribute the default route to our Enterprise core router.

But first.. lets peer with it.

I established a peering session with our Enterprise router and set it inside the “Trust” zone.

  • This is just an example design. Depending on the business, a Router will be at the edge and the firewall will sit behind it which is not true in this scenario.

The BGP session has been established with our Enterprise Cisco Router.

A new Peer Group should be created with a peer defined as the internal router.

ENT-ROUTER#show ip bgp summary BGP router identifier 192.168.1.2, local AS number 64500 BGP table version is 1, main routing table version 1 1 network entries using 144 bytes of memory 1 path entries using 80 bytes of memory 1/0 BGP path/bestpath attribute entries using 152 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 400 total bytes of memory BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.1.1 4 64500 4 4 1 0 0 00:00:21 1

  • An internal BGP session isn’t necessary, as a static default route would be plenty. However, for lab purposes lets continue with more BGP FUN.

We can create static routes that point the two /31 interconnects to our directly connected interface from our Cisco to the Palo. This way, the default route that’s re-advertised by default is actually installed into our routing table.

Network Next Hop Metric LocPrf Weight Path * i 0.0.0.0 172.16.64.0 200 0 64496 ?

Total number of prefixes 1 ENT-ROUTER#

Again, we’re not installing this route, because our local router has no idea where 172.16.64.0 lives.

Create the two static routes for 172.16.64.0/31 and 172.16.65.0/31 and the magic happens:

 

Our Enterprise router now has a way out to the world! Don’t forget to create the inter-zone policy to allow traffic from the Trust to Untrust zone. Also, in a real deployment – there will be a NAT rule out to the inter-webz on the PA, but that’s out of scope for this lab, as I wanted to focus attention to the WAN facing configuration on the Palo Alto.

Palo Alto Documentation on NAT