OSPF - Path Selection – Route Type – Cost – Redistribution

  

In this post, I wanted to go over the OSPF path selection and route types, as well as a couple redistribution points and examples.

First thing is, let’s take a look at the two External AS routers. Both routers 5 and 10 are ASBRs- Autonomous System Boundary Routers – and are redistributing routes from EIGRP and iBGP respectively into OSPF and vice-versa

You can see this by issuing the following command on each ASBR

show ip ospf

Router 5 redistribution config: eigrp\ospf

router eigrp 11

network 10.1.56.0 0.0.0.255

redistribute ospf 1 metric 1000000 10 255 255 1500

!

router ospf 1

router-id 5.5.5.5

auto-cost reference-bandwidth 10000

redistribute eigrp 11 subnets

network 10.1.35.0 0.0.0.255 area 2

network 10.1.50.0 0.0.0.255 area 2

Router 10 redistribution config: bgp\ospf

router ospf 1

router-id 10.10.10.10

auto-cost reference-bandwidth 10000

redistribute bgp 110 metric-type 1 subnets

network 10.1.40.0 0.0.0.255 area 2

network 10.1.50.0 0.0.0.255 area 2

!

router bgp 110

bgp log-neighbor-changes

bgp redistribute-internal

network 10.1.111.0 mask 255.255.255.0

redistribute ospf 1 match internal external 1 external 2

neighbor 10.1.111.11 remote-as 110

neighbor 10.1.111.11 description "External routes to ASBR"

neighbor 10.1.111.11 next-hop-self

Something to point out when redistributing iBGP into an IGP (OSPF in this case) is that the iBGP learned route (R10 learned about the 11.11.11.11 network from R11) will NOT by default be advertised to another iBGP peer OR, to an IGP. We need to add the bgp redistribute-internal command to our bgp instance. We don’t have another iBGP peer here, but we do want the 11.11.11.11 net to be advertised into OSPF at the R10 ASBR.

router bgp 110

bgp log-neighbor-changes

bgp redistribute-internal

When distributing into EIGRP, we need to have various values set to base EIGRP’s final metric on – as shown in the config on R5

router eigrp 11

redistribute ospf 1 metric 1000000 10 255 255 1500

The values are bandwidth(kb), delay, reliability, effective bandwidth (loading) and MTU

OSPF Path Selection

Administrative Distance being equal, OSPF will choose the best path first by route type, and then path\interface cost.

Route Type:

• Note the use of specifying type 1 external OSPF routes vs type 2 routes (the default). A type 1 route will give you the total cost, including the external (redistributed) and INTERNAL cost, while a type 2 route will just account for the external cost.
• Also, a type 1 (O E1) route will be chosen over a type 2 route (O E2) regardless of cost. See the difference below – from R8 – the route to 6.6.6.6 is a E2 route, while the route to 11.11.11.11 is a E1

Further, here is the order for OSPF route types – again, chosen over cost.

Intra-Area (O)

Inter-Area (O IA)

External Type 1 (E1)

NSSA Type 1 (N1)

External Type 2 (E2)

NSSA Type 2 (N2)

Also, I want R10 to be the next hop for all routes learned by R11, so the next-hop-self line was added to the neighbor statement on R10

router bgp 110

neighbor 10.1.111.11 next-hop-self

Cost:

OSPF bases cost on the link bandwidth with the formula:

Reference bandwidth value (Mb) / interface bandwidth

For example, in this lab, I set the reference bandwidth to 10,000 on each router and all interfaces are 1 Gbps.

auto-cost reference-bandwidth 10000

10000 Mbps (or 10 Gbps) \ 1 Gbps = 10 - so all links in this lab have a cost of 10.

Loopback interfaces here, since the reference bandwidth on all routers was modified, have a cost of 1. By default it would be cost 0.

From the perspective of R9, R8’s loopback, is 2 links and a loopback interface away ( 10+10+1=21)

I hope this OSPF reference was useful – in the next post I’ll cover OSPF area types and LSAs.

Thanks for reading!!

Dual Site to Site IPsec tunnels (Palo to Palo) with tunnel monitoring

 In this post, I wanted to add a second ipsec tunnel between sites 1 and 2…and use tunnel monitoring to route via the secondary tunnel should the primary go down.

Tunnel-1 (primary) will utilize ISP1 between both sites. Tunnel 2, the secondary, will use ISP2

The basic tunnel build can be found in this post

Site to Site IPsec tunnel (Palo to Palo) via single ISP with Static Routing

And here’s some reference from Palo Alto HERE

Another nice reference is vpn \ tunnel CLI commands that can come in handy 

Ok, so here is the topology – I’ve added ip address to the tunnels as well as shown in the screen shot…as they are necessary for monitoring.

Another thing to note, you want to add your tunnel interfaces to an interface management profile (tunnel-mgmt here), and allow ping, so they can be monitored. Also, both tunnel interfaces on each firewall are added to the tunnel-site x zone – which is part of a security rule allowing traffic to and from the tunnels - see below.

Here’s your IKE gateway config on site 1 firewall

And the ipsec tunnels

Next, you want to create your static routes in the default vr at each firewall, giving tunnel.1, the primary, a better metric so that’s preferred.

Next, you want to create a Monitor Profile – w the failover action - Network-Network Profiles-Monitor

And, the last thing is enable the tunnel monitor itself on the tunnels. I only enabled this on the Site 1 firewall, which should suffice with monitoring the ip address of the tunnel interfaces on the Site 2 end.

I will go ahead and kill the link on ISP 1 for site 1, and we should begin to route over the secondary tunnel.

The routing table on site 1 firewall now shows tunnel.2 as the path to site 2 – that’s great ! BUT, site 2 is still sending traffic via it’s primary tunnel, which is now down since site 1’s ISP 1 peer interface is not reachable, so we will indeed need to monitor on that end as well!

Ok, Now monitoring was added to the site 2 firewall tunnels , and the ISP 1 link at site 1 was taken down again.

You can now see, at site 2, both tunnels go down, and about a minute later, tunnel 2 is up

And you can see on site 2’s vr – tunnel 2 is now forwarding traffic to site 1 !

This is quite a cool little feature and provides resiliency and redundancy capabilities out of the box. There are other ways to accomplish this as well, and I’ll explore those in future posts Thanks for reading !..until next time.

Site to Site IPsec tunnel (Palo to Palo) via single ISP with Static Routing

In this post, I wanted to go over a typical IPsec tunnel between 2 Palo Alto Firewalls, using static routing, and a single ISP.

Referring to our lab topology below, we have our 2 ISPs, configured for redundancy for outbound traffic should one ISP fail. I want to connect the sites via only ISP1 at each site, with an IPsec tunnel

Perform the following on each firewall. Screen shots are from the Site 1 firewall unless otherwise noted

Step 1

Create Layer 3 Zones for your Outside \Untrust Traffic and add the appropriate interfaces if you haven’t already

Network-Zones – here I used “outside” to define my internet facing zone(s)

Step 2

Network-Zones- Create a Layer 3 Zone for the tunnel interfaces\traffic also – tunnel-site2 (tunnel-site1 on Site 2’s firewall) (See above)

Step 3

Define your IKE Crypto and IPSEC Crypto profiles – these values need to match exactly on both firewalls. I’m just using the defaults here, but in production you want to use the strongest supported authentication and encryption algorithms (see Palo recommendations HERE) – no DES,MD5 or SHA1 for certain ! – Choose the highest DH group number in general.

Network-Network Profiles-IPSec Crypto \ IKE Crypto

Step 4

Create a tunnel interface (tunnel.xx) and associate with the security zone you created earlier – also place the interface in the default router (in this example)

No ip address is needed for this method, so you can leave that blank

Network-Interfaces-Tunnel

Step 5

Create your IKE Gateway – Define your local \ peer interfaces \ ip address here. You also will want to define a preshared string value\key to use at both ends.

The peers in this topology are ethernet1/3 interfaces:

Site 1: 1.1.1.10 /29

Site 2: 2.2.2.10 /29

IKE-Gateway name: ike-gtwy-1

You would also want to use IKEv2 in production if supported

Network-Network Profiles- IKE Gateways

Note- this is where you would specify the IKE Crypto Profile you created earlier– again, using default here so there’s nothing specific to choose.

Step 6

Create your IPSec Tunnel- this is where the final “tie-in” happens.

Chose the IKE Gateway you created earlier – and the tunnel interface (tunnel.1 here) -again, the IPSec Crypto Profile is using the default

Network-IPSec Tunnels

Step 7

Create security policy rules to allow the tunnel traffic and IKE setup.

You’ll need to create a rule for the IKE application as it needs to be allowed inbound to the internet facing zone (Outside)- you could, and should, scope this rule further to only allow known peers - here I just allowed any source

And a “in-out” rule for your interzone traffic between the LAN facing zone (Inside) and Tunnel Zone (tunnel-sitexx) as shown below

Policies-Security

Step 8

Create routes to each site – in this network, site 1 is 10.1.x.x – site 2 is 10.2.x.x

Simply create a static route to each destination network on each site firewall in the default router, pointing to the respective tunnel interface we created (tunnel.1).

Network-Virtual Routers

This should do it … now send some traffic across sites– you should see the IKE setup (Phase1) -traffic below in Monitor-Traffic – to port 500

And your tunnel should turn green – and your pings or other traffic should be successful!

I hope this was a useful guide to a basic tunnel config on Palo Alto ! Next post I’ll cover redundant tunnels and failover – thanks for reading !!

Local Preference for outbound Palo Alto traffic – default route filtering – Dual ISPs

 In this post, I wanted to go over a typical dual isp topology with default routes learned via BGP, utilizing a Palo Alto gateway as an edge device.

Referencing the topology below, we have our 2 ISPs. Each ISP will send our firewall a default route via an eBGP peering. ISP1 will be our preferred path out, so we will want to make this route more attractive.

We can do this with Local Preference.

Remember the BGP path selection hierarchy. Weight is a Cisco only criteria (mostly – Palo does support it) but Local Presence is more suitable here.

This first thing I want to do is disable the injected default route I had setup on the Palo, and exported to CS1, as there will be no need for this now. I’ll just got to Default Router -BGP – Redist Rules and disable the rule.

We will configure the ISP 1 and 2 routers to export their default routes to the Palo, then create import policies on the Palo to change the local preference on those routes. The route with the higher preference will be used as the egress route.

ISP1-1 pertinent config lines:

Default-originate injects the default route for that specific neighbor (the Palo)- routes are scoped with a prefix list, which is refenced in a route-map. The route-map is used in the neighbor statement and applied to outbound routes. And, I added in the 5.5.5.5 route and applied a metric of 11 to it, just to illustrate how that is done also.

router bgp 1

bgp log-neighbor-changes

redistribute connected

redistribute static

neighbor 1.1.1.2 remote-as 5

neighbor 1.1.1.2 soft-reconfiguration inbound

neighbor 1.1.1.10 remote-as 65111

neighbor 1.1.1.10 description "ISP1-to-Palo-send default only-5.x route w metric of 11"

neighbor 1.1.1.10 default-originate

neighbor 1.1.1.10 route-map DEFAULT-ONLY out

!

ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0

ip prefix-list DEFAULT-ROUTE seq 7 permit 5.5.5.5/32

ip prefix-list DEFAULT-ROUTE seq 10 deny 0.0.0.0/0 le 32

!

route-map DEFAULT-ONLY permit 5

match ip address prefix-list DEFAULT-ROUTE

set metric 11

ISP1-2 pertinent config lines:

Same config here – just a different specific route

router bgp 11

bgp log-neighbor-changes

redistribute connected

redistribute static

neighbor 11.11.11.2 remote-as 55

neighbor 11.11.11.2 soft-reconfiguration inbound

neighbor 11.11.11.10 remote-as 65111

neighbor 11.11.11.10 description "ISP1-to-Palo-send default only-55.x route w metric of 11"

neighbor 11.11.11.10 default-originate

neighbor 11.11.11.10 route-map DEFAULT-ONLY out

!

ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0

ip prefix-list DEFAULT-ROUTE seq 7 permit 55.55.55.55/32

ip prefix-list DEFAULT-ROUTE seq 10 deny 0.0.0.0/0 le 32

!

route-map DEFAULT-ONLY permit 5

match ip address prefix-list DEFAULT-ROUTE

set metric 11

You can check what routes are being advertised with a specific neighbor with the command below:

Here are the peer groups (neighbor statements per se) on the Palo side: One group for each ISP router -and one for the LAN Core switch.

Next, we create an Import policy on the Palo for each ISP router – each router will have an import rule for their respective default route and specific route (5.x \ 55.x), with a deny at the end. ISP1 will have it’s Local Preference changed to 200 – making this the better goto path.

We also want to have an Export policy for the 0.0.0.0 default route sent to CS1. Since this route is learned from an eBGP speaker (ISP routers to Palo) and then subsequently sent to an iBGP speaker (CS1\Palo), it was retaining the next hop address of 1.1.1.9 \ 11.11.11.9 – the ISP interfaces where the route was originated, and passing that onto CS1. CS1 has no idea how to get to those networks! Here you need to enable Use Self on the LAN-PEERS Peer group. This is similar to the next-hop-self directive in a neighbor statement on Cisco IOS.

Here is the Import policy for default route learned from ISP1-1 – setting the Local Pref to 200

Similarly, we will set the Local Pref for ISP1-2 to 150

Here, on the Local BGP RIB on the Palo- you can see the imported route from ISP1 – with new local pref of 200

And the Local RIB out – only the default route from ISP1 is exported at the Palo to CS1 – now with the correct next hop and 200 for local pref

Palo routing table

And, here’s the default route on CS1’s BGP table -

Now let’s test our design and fail the primary ISP1 link

Our peering is down for ISP-1!

And the Palo has now installed the default route pointing to ISP2

BGP Table

And finally, the Exported routes – RIB Out- to CS1 – w local Pref of 150

As a side note, make sure your destination interfaces are specified in your NAT/PAT rules, or else nothing past the top most rule will evaluated or used ! Since the traffic is matching via the same source and destination zones for both rules.

Hope this basic Palo Alto BGP config walk-through was helpful --- thanks for reading my blog !