The first portion of INE's new CCIE Security Advanced Technologies Class for the 3.0 blueprint is now available in both streaming and download formats.  Subscribers to the All Access Pass already have access to this new course, and can upgrade to the download version for $159.  Non-subscribers can purchase the standalone download for $299, or subscribe to the AAP for just $159 per month.  Customers who have access to previous versions of the CCIE Security ATC will get access to the new streaming version at no extra charge.

The current release of the class contains the first 18 hours of videos.  New videos will be posted incrementally over the next few weeks, to bring the final runtime somewhere between 40 and 60 hours.  Specifically the following topics are covered in this first portion of the release:


Today's challenge is drawn from the exciting area of CCNA Security. Enjoy. As always, you can find the answer in the comments area a day or two after the date of this post.


Catalyst switch port security is so often recommended. This is because of a couple of important points:

  • There are many attacks that are simple to carry out at Layer 2
  • There tends to be a gross lack of security at Layer 2
  • Port Security can guard against so many different types of attacks such as MAC flooding, MAC spoofing, and rouge DHCP and APs, just to name a few

I find when it comes to port security, however, many students cannot seem to remember two main points:

  1. What in the world is Sticky Learning and how does it work?
  2. What is the difference between the different violation modes and how can I remember them?

Sticky Learning

Sticky learning is a convenient way to set static MAC address mappings for MAC addresses that you allow on your network. What you do is confirm that the correct devices are connected. You then turn on sticky learning and the port security feature itself, for example:

switchport port-security maximum 2
switchport port-security mac-address sticky
switchport port-security


In this series of blog posts, we will examine WLAN security mechanisms in an even greater detail than in our popular 5-Day CCNA Wireless course. We will begin with one that is now considered legacy due to major weaknesses that were quickly discovered in its implementation.

We Don't Need No Stinken' Wires!

This security mechanism receives the least coverage in the CCNA Wireless materials and exam, because, as we stated, it is indeed considered legacy. The official title for this technology is Preshared Key Authentication with Wired Equivalent Privacy. This name tells us a lot. We are not really truly authenticating someone using this approach, we are just ensuring that they possess a piece of information, the preshared key (password). Notice the Wired Equivalent Privacy portion of the name tells us that the creators of the technology were really trying to sell it to WLAN designers and implementers!


Join us Friday, June 25th at 11AM Pacific / 2PM Eastern for another installment in the Open Lecture Series.


A big shout out to all the students in the Raleigh Security CCIE bootcamp last week.   I had a blast!   Thank you for all your hard work, as well as the after hours discussions about the unknown, and why people feel they know it.  :)

I promised a few blog posts related to security over the next few weeks, and this one is regarding Certificate-based ACLs.

This blog may also serve as a review on how to configure the CA clients so that their certificates contain various fields and values, such as subject-name.

Let's use this diagram for the backdrop of our discussion:

R2 will be the NTP and CA server with R1 and R3 as IPSec VPN peers.  (Remember, with certificates we really do need time to be on "our side").  :)

R1's configuration for the trustpoint is as follows:

crypto pki trustpoint R2
enrollment url
subject-name cn=R1,ou=ccsp,o=ine,st=NV,c=US
revocation-check none

I just returned from an awesome Security bootcamp in Raleigh, and am looking forward to more there in the future. Core knowledge is still alive and well in the Security LAB exam, as well as troubleshooting, which is integrated as part of the configuration section.


In a recent post here on the INE blog, we received some follow-up questions similar to the following:

"Why do IPSec peers end up using tunnel mode, even though we had explicitly configured transport mode in the IPSec transform-set?"

It is an excellent question, and here is the answer.   In a site to site IPSec tunnel the "mode transport"  setting is only used when the traffic to be protected (traffic matching the Crypto ACLs) has the same IP addresses as the IPSec peers, and excludes all other IP addresses.   When Crypto ACLs include IP addresses beyond of the 2 peer endpoints the "mode transport" setting is ignored, and tunnel mode is negotiated (due to IP addresses, other than the 2 peers, being part of the crypto ACL).       There is also an option for the key word "require" after "mode transport" which will prevent the peers from negotiating tunnel mode, and if the IP addresses in the Crypto ACLs are outside of the peers's own IP addresses, IKE phase 2 will not successfully complete.

One notable exception to this, is GET VPN, where the KS policy of tunnel mode or transport mode will be used by the group members (whichever mode the KS has configured), regardless of the IP addresses used in the KS ACL for policy.

Below is a site to site example.  Let's use the following topology, with R1 and R3 being peers, and a Crypto ACL that says to encrypt all ICMP traffic, regardless of the IP addresses.   This Crypto ACL will cause our peers to ignore the mode transport option, and negotiate tunnel mode.

Below are the full configs, some debug output, and show commands to demonstrate that even with transport mode explicitly configured in the transform sets, if the crypto ACLs don't exclusively include the endpoints of the VPN tunnel, the two peers go ahead and negotiate tunnel mode instead of transport mode.  Note the Crypto ACL includes all ICMP from any source to any destination.

First, here is R1:


The two engineers, as they grabbed a quick lunch, looked over the following diagram.

The network is GRE.   The routing in place, uses the tunnel interfaces to reach the remote networks of and   The IPSec policy is to encrypt all GRE traffic between R1 and R3.  R1 and R3 are peering with each other using loopback 11 and loopback 33 respectively.

The technicians considered the traffic pattern if a host on the network sent a packet to a device on the network.

Then they reviewed the configurations (below), and discussed them. Based on what they saw, they just couldn’t agree completely with each other regarding the following questions?

1. How many IP headers would be in each packet.
2. What would the source and destination address be of each IP header.
3. What order the IP headers would be in (beginning with the outside header).
4. Would the IPSec be using transport or tunnel mode.
5. Would this be called IPSec over GRE, GRE over IPSec, or something else, (like "nightmare").

So they called for the expert, YOU, to assist in these questions.

Are you up to the challenge.   Answering even 1 of them will be appreciated, so take moment now, and GO FOR IT !

Post your ideas, and we will put all the people who post ideas into a virtual hat, and draw a winner to receive 100 rack tokens to our preferred lab gear provider, graded labs. Please have your posts in by


We are excited to announce that for the first time INE is traveling to Nigeria! In partnership with New Horizons, INE will be offering two classes in Lagos, Nigeria. We will be offering both our CCIE Routing & Switching Advanced Technologies Class and our CCIE Security Advanced Technologies Class. These classes will be held in New Horizons Training centers.

Subscribe to INE Blog Updates

New Blog Posts!