OSPF Area Types and LSAs

 

In this post I wanted to go over the various OSPF area types and LSAs associated with each type, and then a configuration example for each, working with the above topology as in previous posts.

There is simply TONs of quality information and lessons out there on OSPF area types, LSAs etc, so I won’t re-invent the wheel here, just create (another) hopefully useful reference. 😊

Use this illustration below as a guide

Normal Area

Let’s first take a normal area – Area 3 – R8 – and run an ip ospf database command

You can see we have LSA types 1 – 5 – we expect the LSA types 4 and 5 since we have external AS routes being redistributed into our topology at the other side of the network.

Let’s look at the routing table on R8 also

Looks like this area is a good candidate to be a stub area – all the routes go through R7, so we can definitely make this more efficient.

Stub Area

To configure our Area 3 as a Stub area, we need to run this command on all routers in the area. So that’s R7 (the ABR), R8, and R9.

router ospf 1

area 3 stub

Let’s look at the OSPF database and routing table now on R8 now

We’ve replaced the external routes (E2 and E1) with a default route (via Type 3 LSA) and eliminated type 4 and 5 LSAs

But we still have all these inter-area routes that could use optimizing

Totally Stubby Area

Next, we’ll take this a step further and make Area 3 a Totally Stubby Area

Issue this command on ABR of the area – in this case, R7

router ospf 1

area 3 stub no-summary

R8’s route table and ospf database

We cut down the Type 3 Summary LSA’s down to a single LSA, and a single default route that represents all networks beyond the ABR…external and inter-area. Quite cool!

You can also run a show ip ospf command – and confirm that Area 3 is indeed a total stub area as shown below

Next, we’ll go over to the other side of the network and optimize those external AS routing

Here’s what we have so far

Not So Stubby Area (NSSA)

To make Area 2 a NSSA, we need to run this command on R3 (the ABR), R4, and the 2 ASBRs (R10 and R5)

router ospf 1

area 2 nssa

As show on R4’s routing table, the routes themselves don’t change, their designations do -the E2s become N2s, and E1s become N1s.

What does also change is type 5 LSAs are gone, replaced with Type 7 – as shown on R4

There is NO default rote injected in a NSSA – you need to manually inject the route from the ABR if you want to- the reason for this is that your ASBR may be injecting default routes into the area, for reaching the external networks, and you would not want multiple default routes. And in our case here, we have 2 external networks in Area 2

Let’s inject a default route into the nssa with tis command – appending default-information-originate

area 2 nssa default-information-originate

On R4, nothing magical happens – only difference is there is now a default route added (as a N2 route) with R3 as the next hop. Every other route has a longer prefix so the default route in this case does nothing to minimize the routing table, so this route is useless. Since the area contains ASBRs, advertising externally redistributed routes from 2 ASs, those routes remain.

Total Not So Stubby Area

Now we can try to reduce the type 3 LSAs (responsible of inter-area summary routes) here, and get a default route towards R3 for the destinations on the opposite side of the network. Also, I will remove the default-information-originate option

area 2 nssa no-summary default-information-originate

Here’s R4’s routing table now. The external routes remain for the 2 advertising ASBR routers, and now we have a single inter-area default route towards R3 for destinations beyond, and a smaller routing table ! This is as optimized as you can get with this topology.

Again, the no-summary option reduces the type 3 LSAs (to 1), and a default route towards the ABR is injected automatically for inter-area routes, without the need to specify default-information-originate, which was not helpful here anyway as it only represents external routes.

Thanks for reading this post- hope it serves as a useful reference!

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 !