Tag Archives: Cisco

How to configure OSPF Totally Stubby Area in Cisco Routers- Series 1?

In this series of posts lets configure OSPF Totally Stubby Area, but before proceeding further let’s summarise the below topology

OSPF Totally Stubby Area
  1. Two OSPF Areas Area 0 and Area 5
  2. 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)
  3. R4 has four loop back interfaces  loopback 1 ( , loopback 2 ( ,loopback 3 ( and loopback 4 ( ,these loopback interfaces networks are redistributed into OSPF
  4. R2-R3 are part of Area 5, R2 happened to be a ABR
  5. 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 totally stubby area,  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, also we could see the interface connecting R1-R4 are also advertised as Type 3 LSA

R2 - R4 route
R2 - type 5

R3 sees R4 loopback interfaces network as Type 5 LSA and R1-R4 , R1-R2 links network ,  as Type 3 LSAs

R3 LSA table

In next post, let’s see by what impact Area 5 will have especially after configuring it as  OSPF Totally Stubby Area.

Introduction to Cisco port security and the reasons to implement

A growing challenge facing network administrators is determining how to control who can access the organization’s internal network—and who can’t. For example, can anyone walk into campus LAN , plug in a laptop, and access the network? You might argue that the wall jack has no connection to a switch, but couldn’t someone just pull the Ethernet cable from a working PC and connect to the network that way?

You might think this an unlikely scenario, but it does happen. For example a salesmen coming in to demo products, and they would just pull the Ethernet jack off a PC and connect it to their laptop, hoping to get Internet access.

I turned to switch port security to help solve the problem. Let’s look at how we can use Cisco’s Port Security feature to protect our organization.

Understand the basics
In its most basic form, the Port Security feature remembers the Ethernet MAC address connected to the switch port and allows only that MAC address to communicate on that port. If any other MAC address tries to communicate through the port, port security will disable the port. Most of the time, network administrators configure the switch to send a SNMP trap to their network monitoring solution that the port’s disabled for security reasons. When using port security, we can prevent devices from accessing the network, which increases security.

Benefits to port Securty
The key benefits of Port Security are:
•Network Availability – Reduce campus wide network outages caused by broadcast storms by blocking non standard hubs and switches.
•Network Reliability – Network port bandwidth can be guaranteed if limited to one MAC address. Bandwidth can’t be guaranteed if other network devices are sharing the network port.
•DHCP Availability – Reduce the risk of over subscription of DHCP IP Address per VLAN by limiting one MAC address per port.
•Network Security – Limiting one MAC address per switch port is an attack mitigation strategy. Stops CAM tables flooding attacks forcing the switch into repeater mode. Tools like macof can be used for this type of attack.
•Future Proofing – The implementation of port authentication at the edge of the network (802.1x) will also limit user to one MAC address per port.

Applying Cisco Security Features to Solve Common Problems

Sample Configuration for port security
Configuring the Port Security feature is relatively easy. In its simplest form, port security requires going to an already enabled switch port and entering the port-security Interface Mode command. Here’s an example:

Switch)# config t
Switch(config)# int fa0/18
Switch(config-if)# switchport port-security ?
aging Port-security aging commands
mac-address Secure mac address
maximum Max secure addresses
violation Security violation mode

Switch(config-if)# switchport port-security

By entering the most basic command to configure port security, we accepted the default settings of only allowing one MAC address, determining that MAC address from the first device that communicates on this switch port, and shutting down that switch port if another MAC address attempts to communicate via the port. But you don’t have to accept the defaults.

Know your options
As you can see in the example, there are a number of other port security commands that you can configure. Here are some of your options:
switchport port-security maximum {max # of MAC addresses allowed}: You can use this option to allow more than the default number of MAC addresses, which is one. For example, if you had a 12-port hub connected to this switch port, you would want to allow 12 MAC addresses—one for each device. The maximum number of secure MAC addresses per port is 132.
switchport port-security violation {shutdown | restrict | protect}: This command tells the switch what to do when the number of MAC addresses on the port has exceeded the maximum. The default is to shut down the port. However, you can also choose to alert the network administrator (i.e., restrict) or only allow traffic from the secure port and drop packets from other MAC addresses (i.e., protect).
switchport port-security mac-address {MAC address}: You can use this option to manually define the MAC address allowed for this port rather than letting the port dynamically determine the MAC address.

Of course, you can also configure port security on a range of ports. Here’s an example:
Switch)# config t
Switch(config)# int range fastEthernet 0/1 – 24
Switch(config-if)# switchport port-security
However, you need to be very careful with this option if you enter this command on an uplink port that goes to more than one device. As soon as the second device sends a packet, the entire port will shut down.

View the status of port security
Once you’ve configured port security and the Ethernet device on that port has sent traffic, the switch will record the MAC address and secure the port using that address. To find out the status of port security on the switch, you can use the show port-security address and show port-security interface commands. Below are examples for each command’s output:
Switch# show port-security address
Secure Mac Address Table
Vlan Mac Address Type Ports Remaining Age
—- ———– —- —– ————-
1 0004.00d5.285d SecureDynamic Fa0/18 –
Total Addresses in System (excluding one mac per port) : 0
Max Addresses limit in System (excluding one mac per port) : 1024

Switch# show port-security interface fa0/18
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 1
Total MAC Addresses : 1
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address : 0004.00d5.285d
Security Violation Count : 0


How to configure Cisco VIRL – VMMaestro to use SecureCRT as an external telnet and SSH Client?

Cisco VIRL comes with an internal SSH and Telnet client which is quite good and it opens all the SSH and telnet sessions within VMMaestro GUI, but if someone wants to use Secure CRT on  their MAC as an external client, one can easily configure the changes in VIRL VMMaestro,


Terminal>Cisco Terminal

Step 1

Change the title format to : %s

Step 2

Select : Use external terminal applications


Use the following fields show below

Telnet command:/Applications/SecureCRT.app/contents/MacOS/SecureCRT
Telnet arguments:/T /N %t /TELNET %h %p
SSH Command:/Applications/SecureCRT.app/contents/MacOS/SecureCRT
SSH arguments:/T /N %t /TELNET %h %p

By doing these minor changes you can use Secure CRT to SSH or Telnet VIRL Devices

telnet VIRL
VIRL telnet 1

What is the OSPF Stub Area?

We all know OSPF as routing protocol is one of the most widely used IGP protocol, OSPF happens to be the most scalable IGP protocol. OSPF also happens to be one of the complex protocols as it deals with various concepts and terminologies. One such a 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 information of an OSPF database purely based on the LSA types, Basically, an ABR  in a Stub Area prevents LSA type 5 to be flooded into 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 with a subnet mask and flood the same into the stub area. By using Stub Area feature one can reduce the CPU utilization of a Router.

OSPF Stub Area

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 a 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, let’s see how to configure OSPF stub area in Cisco Routers, we will build a sample topology using Cisco VIRL.

Cisco ASA VPN troubleshooting  – Decaps but No encaps

Recently we observed a strange issue while building a site to site VPN tunnel between a Cisco ASA [9.1( 5) ] and Palo Alto Next Generation firewall.(PAN-OS 7.0.9) It was observed always phase 1 part of tunnel established successfully with peer however phase 2 failed to come up.

Always we were seeing issues with encapsulation, the packets sent were never encapsulated, however the packets received from remote peers were de capsulated, this means  the ASA was not encrypting the data. The below logs demonstrates the error,

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

#pkts decaps: 74, #pkts decrypt: 0, #pkts verify: 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#TFC rcvd: 0, #TFC sent: 0

#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0

#send errors: 0, #recv errors: 74

We did a through troubleshooting and we ensured the following ay both ends of the firewalls

  • Ensure both the firewalls have an appropriate route for the interesting traffic / proxy id
  • Ensured the ACL / Policies are matched
  • Ensured NAT configuration is done properly as were using source based NATTing at both the end.
  • Ensured proper debugging is done at both ends,
  • Involved vendors to see what the issue was

Upon through troubleshooting it was discovered the ASA was hitting a bug CSCuo58411

This bug basically creates duplicate entries in tunnel manger and one could see from the below logs

IPSEC(crypto_map_check)-3: Checking crypto map outside_map 10: matched.
Jul 24 08:20:49 [IKE COMMON DEBUG]Duplicate entry already in Tunnel Manager

IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=1, saddr=, sport=45638, daddr=, dport=45638

IPSEC(crypto_map_check)-3: Checking crypto map outside_map 10: matched.
Jul 24 08:20:50 [IKE COMMON DEBUG]Duplicate entry already in Tunnel Manager

The work around worked for us to fix this issue, was to upgrade the ASA from 9.1(5) to 9.5(3)6 . The other recommended work around to fix this issue is

Issue “debug menu ike-common 10” to remove the stale IKEv2 entries (this will delete all current IKEv2 connections)