Cisco vs Palo Alto Networks: The Hidden Battle


In my conversations with firewall users I often hear references to the “battle of the titans” between Check Point and Palo Alto Networks. Both are leaders in the Gartner Magic Quadrant, their security technologies are often compared and the marketing slander has been seen often in all the different mediums.

As everyone is aware, PANW’s aggressive growth outpaces the growth of the firewall market. This means that a large portion of the growth is coming from the displacement of their competitors. A point PANW’s CEO, Mark McLaughlin, made recently.

However, very little attention has been given to this:


The sum of the percentages is greater than 100% as some customers migrated from multiple vendors to PANW.

Continue reading

Configuration Management Tool Comparison: Multi-Vendor Deep Configuration Analysis: Cisco-Focused

NetMRI was originally developed and sold by Netcordia, founded in 2000 by the world’s first Cisco Certified Internetwork Expert (CCIE). It was created to help Cisco admins solve configuration issues in their network equipment by defining certain checks and ensuring that all switching and routing devices conform to the desired configuration.

In-depth configuration analysis for Cisco with NetMRI

NetMRI is a fantastic configuration management tool for Cisco admins – it’s got incredible visibility into Cisco configurations and the ability to dissect and analyze some of the most complicated setups of Cisco routers and switches. However, it falls quite short for other network devices, especially the non-Cisco ones and those for layers 4 and up. This includes Check Point, Fortinet, Juniper and Palo Alto Networks firewalls as well as F5 load balancers. For these, NetMRI supports pulling the configurations (see DSB list) but comes with no built-in configuration checks. As a user, you are required to teach NetMRI how to understand the configuration of these devices and what to look for. Quite a tedious task.

For example, consider the release notes for NetMRI 6.9.1 (released in 2014). The new features focus solely on switching and routing equipment. The same is true for other recent releases of NetMRI, such as 6.8.1. This is caused by Infoblox’s focus on DDI – (DNS, DHCP and IP Address Management) which are the company’s core business. DDI is tightly integrated with switching and routing, hence the focus on those devices by NetMRI as shown in a demo video of NetMRI.

Therefore, users who run a Cisco shop should consider investing in NetMRI and using that as their go-to tool for analyzing the configuration of their routers and switches. Even those running a mixed environment with a heavy investment in Cisco routing and switching gear, should consider using NetMRI to automate their IP address management and routing.

Users who require deep-visibility into their Cisco AND non-Cisco devices, specifically identifying common misconfigurations as well as pointing out which devices are not compliant with the organization’s gold configuration, should take a look at indeni. With indeni you will be able to identify known configuration issues in your Check Point, F5, Fortinet, Juniper and Palo Alto Networks gear, as well as your Cisco equipment.

VPN peer not responding or unreachable

This is a real life sample alert from indeni


Some of the device’s VPN peers are not responding to VPN traffic.

Affected VPN Peers

VPN peer is currently not responding

Manual Remediation Steps:

The VPN peer is not responding to VPN traffic. Please check network connectivity and contact the administrator of the VPN peer to ensure VPN is still enabled.

Note that many VPN peers do not respond to ICMP pings and will only respond to VPN traffic (such as UDP port 500, IP protocol 50, etc.). To test that the VPN peer responds to VPN traffic, use Nmap’s ike-version script.

How does this alert work?

indeni uses device-specific commands and logs to determine if the VPN peer is not responding.

NTP Servers Configured but not Operational: Check Point Configuration Alert Guide

This is a real life sample alert from the leader in Proactive Network Management: indeni


While NTP is configured on this device it does not seem to be operating correctly for all of the configured servers.

indeni will re-check this alert every 1 minute. If indeni determines the issue has been resolved, it will automatically be flagged as such.

Problematic NTP Servers:
Executed command “ntpdate” with the response:
27 Aug 12:36:30 ntpdate[29924]: no server suitable for synchronization found

Manual Remediation Steps:

Review the NTP configuration, firewall rules, routing tables and other elements of the network to determine the cause.

How does this alert work?

indeni uses different commands for different devices to determine if NTP is working. Examples:

  • On many Linux-based OS’s, indeni will use ntpdate for each configured NTP server (essentially forcing an NTP update and reviewing the results).
  • On Cisco devices and Juniper JunOS devices, “show ntp associations”.
  • On Check Point IPSO devices and Juniper ScreenOS devices, ntpq or ntpdate depending on version.
  • On Fortinet Fortigates, “diag sys ntp status”.

A NIC failed recently or port down

This is a real life sample alert from indeni


Some network interfaces or ports have gone from “working” to “not working”, some network traffic may be lost.

indeni will re-check this alert every 1 minute. If indeni determines the issue has been resolved, it will automatically be flagged as such.

Affected Network Interfaces or Ports:

GigabitEthernet0/2 (MAC Address: 00:0f:34:fe:00:1a, IP Address:, Description: Our Connection to ACME)

Manual Remediation Steps:

For GigabitEthernet0/2(Our Connection to ACME): The following log lines may assist with troubleshooting this issue:

  • Nov 12 18:30:24.704 GMT: %TRACKING-5-STATE: 2 interface Gi0/2 line-protocol Up->Down
  • Nov 12 18:30:26.588 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to down
  • Nov 12 18:30:26.588 GMT: %ENTITY_ALARM-6-INFO: ASSERT CRITICAL Gi0/2 Physical Port Link Down
  • Nov 12 18:30:27.588 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to down

How does this alert work?

indeni uses different commands for different devices to determine if the NICs are working correctly and the ports are up. Examples:

  • On many Linux-based OS’s, indeni will use ifconfig.
  • On Cisco devices indeni will use “show interface” and related commands.

In the specific case of switches, indeni will attempt to determine if it is monitoring an access switch and will avoid alerting about ports that tend to go up and down a lot. Trunk ports, for example, will still be monitored.


Cisco VRF Lite Configuration

VRF (Virtual Routing Forwarding) is a tool that enables service providers to support customers with VPNs that have overlapping IP addresses. Usually this tool is part of bigger MPLS and MP-BGP setups and configured on a PE (provider’s edge) router facing a CE (costumer’s edge). VRF can also be used as a sort of VLAN to separate overlapping IPs on a router with no MPLS configured.

In this blog post I will demonstrate how to configure VRF lite in order to separate networks with overlapping IPs.

In the following topology there are three identical networks with the same IP address. Without the use of VRF lite, those networks cannot function. We will use VRF lite to separate those networks.

VRF Lite configuration VRF Lite configuration

These are the steps for VRF lite configuration:

  • Create and name VRFs.

ip vrf VRF1 ip vrf VRF2 ip vrf VRF3

  • Attached VRFs to desired interfaces.

interface FastEthernet0/0 ip vrf forwarding VRF1 ip address no shut !

interface FastEthernet1/0 ip vrf forwarding VRF2 ip address no shut !

interface FastEthernet2/0 ip vrf forwarding VRF3 ip address no shut !

  • Apply routing to specific VRF.

router ospf 1 vrf VRF1 log-adjacency-changes network area 0 !

router ospf 2 vrf VRF2 log-adjacency-changes network area 0 !

router ospf 3 vrf VRF1 log-adjacency-changes network area 0 !

And you’re done! Now you can use a single router to separate networks with overlapping IPs.

How to Configure HSRP VIP Problems Using Next Hop Redundancy Protocol Alert

For those of you who don’t know what HSRP is, here is a quick explanation (for those who do, just skip to the 2nd paragraph). HSRP is ‘Hot Standby Router Protocol’. It is a Cisco-proprietary redundancy protocol for establishing a fault-tolerant default gateway–basically, redundancy for routers.

It is crucial for all devices communicating with routers in an HSRP setup to use the HSRP’s Virtual IP (or VIP) and to make sure there is no access enabled to the physical IP of those routers/interfaces.

The problem is that when the router goes down, the physical IP goes down with it and all those devices that are configured to use this physical IP (and not the VIP) will not be able to switch over to other routers in the HSRP setup. In most cases, this happens because before you enabled HSRP, all your network devices used the physical IP of this router’s NIC. Since we’re all human, we may forget to change some of those devices to use the Virtual IP.

I wrote a signature (indeni’s Dynamic Knowledge checks: See all checks here) to check for this specific setup. indeni will automatically verify that all indeni-monitored devices are using Virtual IP. In order to do this, I used the following commands:

  • “show standby” – to get the Virtual IP
  • “show ip interface brief” – to get the IP of the NIC

Once we have collected all the relevant information, we go over all the devices and check whether they are using a physical IP instead of a Virtual IP. If indeni finds any physical IPs, then indeni alerts that “HSRP Virtual IP Is Not Used as Next Hop on Some Devices”, with detailed information of our findings, for example:

indeni found that has a route “ nexthop”; however, you have HSRP configured with the Virtual IP address