OSPF Totally Stubby Area basically filters out an information of a OSPF database purely based on the LSA types. An ABR in a Totally Stubby Area prevents LSA type 3, Type4 and Type 5 to be flooded in to a Totally Stub Area. It replaces all these types of LSA with a default route. Basically the Totally Stubby Area carries out the concept of Stub area in addition to removing type 3 LSA.
From the above scenario the ABR R2 will simply strips of Type 5, Type3 and Type 4 LSA and just forward a default route to R3. In order to configure a Totally Stubby Area one need to use Cisco IOS command ” area x stub no-summary” on the ABR Router and Cisco IOS Command ” area x stub” under OSPF process in Totally Stubby routers, where X happens to be the Area number . Now you might be wondering why the IOS commands are different in an ABR and other routers which are part of Totally Stubby Area, well the IOS command no-summary tells the ABR not to inject TYPE 3 LSA which represent the Inter-Area routes. I upcoming post lets see how to configure Totally Stubby Area.
In my previous post we studied the topology and saw how Type 5 LSA routes are installed in non 0 Area. Now lets configure Area 5 as a stub area.
Its very easy to configure a stub area , by enabling the Cisco IOS Command ” area X stub ” in OSPF process one can enable Stub area ,X is the area number.
In our case we need to configure Area 5 as a stub area by using the below Cisco IOS command in Routers R2 and R3
router ospf 1
area 5 stub
Now lets examine how R4 loopback interface networks are installed in R3 router
We can see there are no specific routes for R4 loopback interfaces, networks 10.0.1.0 , 10.0.2.0, 10.0.3.0 and 10.0.4.0 are replaced by a default route.
We cannot see a specific route for the R4 Loopback interface 1 , its not in the routing table, however when we examine the CEF table we can discover the nexthop for the network 10.0.1.0 is 192.168.23.3 which happens to be the R2 interface connecting to R3 and also there is a reachability.
By configuring a Stub Area one can install all the external routes ( type 5 LSAs) using a default route, the greatest advantage one could see is the size of routing table and OSPF database is reduced to a smaller size
In this series of posts lets configure OSPF Stub Area, but before proceeding further lets summarize the below topology
- Two OSPF Areas, Area 0 and Area 5
- R1, R2 and R4 are part of Area 0 and OSPF is configured on the directly connected links on each router ( R1 – R2 link , R1-R4 link)
- R4 has four loop back interfaces loopback 1 (10.0.1.1) , loopback 2 (10.0.2.2) ,loopback 3 (10.0.3.3) and loopback 4 (10.0.4.4) ,these loopback interfaces networks are redistributed into OSPF
- R2-R3 are part of Area 5, R2 happens to be a ABR
- OSPF Area 5 is configured on the interfaces connected between R2-R3.
Currently Area 5 is a normal area and its not been configured as a stub area, currently R2 installs the R4 loopback interface networks as Type 5 LSA and forward the same to Area 5
We can see from the below snap shot R2 received R4 loopback networks as Type 5 LSAs and the routes are installed as Type 2 External OSPF routes
R3 does installs the R4 loopback networks as Type 2 External OSPF routes and they are received as Type 5 LSAs
In the next post lets see what will happen when we configure Area 5 as a Stub Area.
We all know OSPF as routing protocol is one of most widely used IGP protocol, OSPF happens to be the most scalable IGP protocol. OSPF also happens to be one of complex protocols as it deals with various concepts and terminologies. Once such topic where people get confused is OSPF Area types.
I will try to simplify them and present them in an easy language, I am not going to reinvent the wheel , as one can find plenty of resources for OSPF.
What is a OSPF Stub Area ?
OSPF Stub Area basically filters out an information of a OSPF database purely based on the LSA types, Basically an ABR in a Stub Area prevents LSA type 5 to be flooded in to a Stub Area , it removes Type 5 LSA and replaces them with a default route which is a Type 3 LSA. To simplify ABR creates a default route using LSA 3 , listing a 0.0.0.0 with a subnet mask 0.0.0.0 and flood the same into stub area. By using Stub Area feature one can reduce the CPU utilization of a Router .
From the above scenario we can see Type 3 LSA is exchanged between Area 0 and 5 , however when a Type 5 LSA reaches R2 which is an ABR , it will strip External LSAs (Type 5 LSAs) and replace them with default route towards the Router R3.
OSPF Stub Area is configured in Cisco Routers using an IOS command
router ospf 1
area 5 stub
In the upcoming post lets see how to configure OSPF stub area in Cisco Routers, we will build a sample topology using Cisco VIRL.
If you are planning to do a hitless upgrade of a failover pair of ASA 5500 X Series firewall from 8.4(6) trail to 9.2(4) trail, you need to be little cautious. As you cannot do a direct upgrade, you need to rely on a interim release.
Most people tend to try 9.1(2) as an interim upgrade, when you first upgrade your secondary firewall to the 9.1(2) version you will notice lots of logs are generated with an error “Number of interfaces…not consistent”. These logs are generated especially when you are trying re-enable the failover on the standby ASA firewall.
This version of IOS is hit by a bug CSCug88962 which results in failure of synchronisation between ASAs. Also when you verify the MD5 hash it never matches with hash value mentioned in Cisco Website. This version never allows you to have a zero down time upgrade of Cisco ASA 5580 X Series firewalls, the only work around for those who end up in these kind of situation is to downgrade the ASA firewall the previous version of IOS, which was working fine. And then they can plan the upgrade of ASA 5500 X Series firewall by using the interim version 8.4(7) which is bug free and then to 9.2(4).
In this post we will continue the configuration of log forwarding in Palo Alto Networks Firewall, in previous post we saw how to add a Syslog Server Profile
Step 4 – Provide any valid name for the Log Forwarding profile and select the Syslog Server configured in Step 2
You could see Palo Alto Network Firewalls logging profile has many options , one has the flexibility to forward the logs to all the options available. The good thing I see you can even email the critical Threats or WildFire actions by email. In this post we will stick to configuring Syslog.
Step 5 – Select the log field you want to forward to your Syslog Server, it always better to chose the Severity based on your organizational needs as shown below
Your final log forwarding Profile should look like this
Step 6 – Applying the log forwarding action
In Palo Alto Firewalls one can apply Log Forwarding action to either Security Policy Rule or Zone , both are independent logs.
By following the above mentioned steps one can enable log forwarding in Palo Alto Networks Firewall.
We all know the importance of having historical logs for any references or forensic analysis. I have personally benefitted from historical records for various reasons and it happens to be a good practice to forward all the logs of your firewall to a logging server. The logging server could be as simple as Syslog Server, Palo Alto Panorama or any SIEM solution like ARC Sight or QRadar etc., Also we all know firewalls cannot hold the logs for long time, once the log buffer is full the firewall losses the old logs. However I have noticed, compared to their competitors Palo Alto Networks Firewalls does posses good amount logging space.
In this post lets see how we can configure Palo Alto Networks Firewalls to forwards all the logs it generates to a logging server.
Step 1 – Add the Syslog Server
Device > Server Setting > Syslog > Add
Step 2 – Configure the Syslog Server Profile
- Name : Provide a valid Name
- Click Add Button
- Provide a valid name for Syslog Server
- Assign the IP Address as shown below
- By default Syslog server listen on UDP port 514, if you are using custom port you can modify it
If you need to add multiple Syslog Servers then follow the Steps from step b to step e
Step 3 – Create a Log Forwarding Profile
Objects > Log Forwarding > Add
In this step we are going to create a log forwarding profile which can be applied to Security rules to forward the logs
When it comes to live troubleshooting or to ensure certain traffic is either blocked or allowed one relies heavily on logs, Palo Alto Network Firewalls does provides very good logging options and fields. Its quite easy to read them and understands them. By default when some one creates any security policy Palo Alto Networks Firewall logs the details at the end of the session. So one does not need to enable logging, if he/she wants to monitor session since it started then they have enable the it.
One can enable logging, directly from the security policy he/she creates as shown below
Restoring the Cisco ASA Firewall to default settings is quite easier , there are two ways to do this. In this post lets see how we can do this using the Cisco IOS Command
Connect the console cable to the console port of an ASA Firewall and to the serial port of your laptop or desktop
Connect to the Cisco ASA Firewall using your favorite terminal client ( I am using Secure CRT ) with following serial setting
After login to Cisco ASA Firewall through the console port enter to enable mode
Enter to Config mode and enter the following Cisco IOS command and press enter
You could see the Cisco ASA Firewall is configured to factory default setting, reload the Cisco ASA Firewall with an IOS command
reload save-config noconfirm
By following the above steps one can reset the Cisco ASA Firewall to factory default settings , now you are free to access the firewall using either a console port or ASDM using the default IP address of 192.168.1.1, provided that you are connected to Cisco ASA firewall on an ethernet or management port, this depends on the model please do check the data sheet of your firewall, in my case its a Cisco 5540 Firewall and the IP address is assigned to management interface and the DHCP pool is also configured.
The moment I connect my laptop to the management port of the Cisco ASA Firewall I will got an IP address from the DHCP server of ASA Firewall as shown below
I could login to Cisco ASA Firewall using my browser and I can manage the Cisco ASA Firewall by downloading the ASDM as shown below
When comes to Palo Alto Networks Firewalls, they work on the concept of zones not the security levels. They are no different when compared to other leading Firewall vendors. While designing the Network one must focus on number of zones the business is looking for and what kind of scalability the business is looking for? As Palo Alto Network Firewalls security zones are platform dependent and there is a limit as well.
Coming back to security policy , its always applied to a zone not to an interface so one can decide what kind of zones need to be created again this completely relies on the Organisational needs.
By default Palo Alto Firewall with a PAN-OS of 6.1 or above offers there security Policy rules type
- Universal (default)
Intrazone Rules are basically used to allow the traffic within same zones , for example you have two zones name DMZ1 and DMZ2 , using an Intrazone rule traffic from DMZ1 is forwarded to DMZ1 not to DMZ2.
Intrazone rules mathes only the traffic within the specified source zone not between them , one cannot specify the destination zone for Intrazone rules.