Posts from ‘CCIE Security’
A policy-map, by any other name…
Time is a valuable resource in the lab. In a lab task, if asked to configure a policy-map named “BOB”, it doesn’t get the same point value if we happen to accidentally name it “bob”, especially if they are looking to see if you configured what they asked for.
The challenge is, that when reviewing a lab task, and we discover that we need to change a name, it could be a hassle, as we need to remove the policy-map, recreate the policy map, and then put it in place again.
So if you are down to the last minute, here is a time saving solution, that can assist with that process.
IOS allows us to rename a policy-map, and the IOS will swap out the name in other areas of the configuration that reference that policy map. Continue Reading
“Why doesn’t this PING work!?!”
Here is a simple 3 router configuration, well at least it is simple on 2 of the 3 routers. R1 and R3 are configured quite traditionally, but R2 is a bit more involved.
Here is the diagram.
Here are the details.
R2 is using a VRF which includes both LAN interfaces. R2 is also acting as a Zone Based Firewall in transparent mode, allowing all ICMP traffic in both directions, as well as SSH from the inside to the outside networks. R2 has a bridged virtual interface in the 10.123.0.0/24 network. All are running OSPF, but pings issued from R2 to the loopbacks of R1 and R3 are failing.
Can you identify why? Continue Reading
Tags: ccie, troubleshooting
Join us Friday, June 25th at 11AM Pacific / 2PM Eastern for another installment in the Open Lecture Series.
The topic that will be covered is Privilege Levels and Role Based CLI.
We look forward to seeing you there. Seats are limited.
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 http://2.2.2.2:80 serial-number ip-address 10.0.0.1 subject-name cn=R1,ou=ccsp,o=ine,st=NV,c=US revocation-check none Continue Reading
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.
Often times, what seem like complex network troubleshooting scenarios are caused by overlooking simple fundamental components of the technology. Join me on Tuesday, June 8th as we discuss developing the Tier 1 knowledge that you need to know for the CCIE Security LAB, as well as strategy that may be used to continually build your base of knowledge as you prepare for your CCIE certification.
This v-Seminar is open to the public, and will be held online at
| U.S.A. – Pacific) | Tuesday, June 8, 2010 at 11:00:00 AM | UTC-7 hours PDT |
| UTC | Tuesday, June 8, 2010 at 18:00:00 |
To sign up for v-Seminars, click here, and select the link for Free v-Seminars.
To join the meeting listed above, click here now.
See you soon!
Keith
Summer is here and it’s time to get certified! Join us during the Summer of Success by attending one of our bootcamps and save up-to $1000. Get $500 off any one week on-site bootcamp or $1000 off any two week on-site bootcamp when you purchase during this limited offer. This special promotion applies to CCIE Routing & Switching, CCIE Voice, CCIE Service Provider or CCIE Security.
To take advantage of this special promotion, use discount code 1WEEKBOOTCAMP or 2WEEKBOOTCAMP when you check out at http://www.ine.com.
Tags: ccie, promotions
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: Continue Reading
It isn’t my fault, they configured it that way before I got here! That was the entry level technician’s story Monday morning, and he was sticking to it.
Here is the rest of the story. Over the weekend, some testing had been done regarding a proposed BGP configuration. The objective was simple, R1 and R3 needed to ping each others loobacks at 1.1.1.1 and 3.3.3.3 respectively, with those 2 networks, being carried by BGP. R2 is performing NAT. The topology diagram looks like this:
The ping between loopbacks didn’t work, but R1 and R3 had these console messages:
R1# %TCP-6-BADAUTH: No MD5 digest from 10.0.0.3(179) to 10.0.0.1(28556) (RST) Continue Reading
As you know, purchasers of the new INE 5-day QoS bootcamp receive the class in four different modalities. There is the interactive self-paced version, the live class, the recorded live class, and an audio bootcamp.
If you would like to check out a sample lesson of the audio bootcamp, tune into W-INE Internet radio, or visit the course’s Samples page. The lesson is also going to appear on our iTunes podcast channel by Saturday, May 22, 2010. Just search the iTunes store for INE.
Enjoy, and I look forward to “seeing you” in class soon.
The two engineers, as they grabbed a quick lunch, looked over the following diagram.
The 13.0.0.0/24 network is GRE. The routing in place, uses the tunnel interfaces to reach the remote networks of 1.1.1.0 and 3.3.3.0. 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 3.3.3.0/24 network sent a packet to a device on the 1.1.1.0/24 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
Continue Reading
Loading ...
