Cisco

CCIE Security Lab 1, Steve 1 – I passed!

~ Steven McNutt ~ 5 Comments

Greetings Programs!

I sat my second attempt at the CCIE security lab on Monday, March 5th, 2018. This time I got the pass. It was not without a bit of drama.

pass

TL;DR: It’s a very tough exam, harder than you think, harder than you remember. Fight with everything you have until the proctor tells you to stop.

The longer version.

Had the usual anxiety thing in the days leading up to lab day. Did what I could to minimize it. Got ok sleep the night before. On Lab day I wasn’t nearly as nervous as I was in January.

Tshoot.  I came out swinging and quickly solved most of the tickets. Then I had an issue with ISE that left me dead in the water for half an hour. left one ticket unsolved.

Diag was like last time, pretty easy, chance to take a breather and get ready for the main event.

Config started out well, was flying through the first few tasks. Had some annoying issues related to code and platform differences between my personal lab and the actual exam, don’t recall that happening the last attempt.

Then the trouble began.

ISE was acting up, so I attempted to restart it. Application shut down dirty with database errors and would not start. While all this was going on I was trying to work on other stuff and keep moving. Eventually the proctor got ISE running somehow, but the database corruption was an issue and ISE wasn’t adding endpoints to the database, which made several tasks impossible to complete. The lowest point was when he was sending people home, and I knew I didn’t have the points. When he said I could continue I put my head down and kept grinding.

I was just about out on my feet but I kept battling. When I was told I’d have to stop, I looked at my scorecard to add the points, and all the tasks that could be completed were.  Scorecard said I had the points with a small cushion. Would the tasks verify though?

To my amazement I got the email about 3 hours later with the good news.

Much respect to the proctor who probably stayed at work late in order to let me make up the time lost by the ISE debacle. Those folks have a very tough job putting up with us.

Final thought: The CCIE lab is **always** so much harder than you remember it. You can’t simulate what it’s really like. Even after just 7 weeks gap I was going “what the hell!?!”.

Now I get to make things up to my wife and try to lose the 10 lbs of body fat I put on in the final push.

Warmest regards,

-s

SEC-3.3.1 FlexVPN challenge/Exploration lab

~ Steven McNutt ~ Leave a comment

Greetings programs!

This is a lab topology I put together in EVE-NG to help me sharpen up my knowledge and skills with IKev2/FlexVPN. The baseline configuration uses pre-shared keys and there’s quite a bit of preconfigure.

 

Screenshot of topology

Here’s a screenshot of the topology.  I’ll give a big shout out to whomever can explain why tunnel 100 between r1 and r2 exists.  🙂

Description

There’s two initial versions in the repo.

  • There’s the actual challenge lab where I removed some bits of config here and there to make it more fun.
  • There’s a partially completed version using pre-share keys.  flex mesh works, the ASA part works, flex client works.  No config on R7.  You could use this as a starting point to work on the tasks in the lab.

Links

 

Challenge lab proper

Challenge lab with working basic config

Fire it up and let me know what you think!  If you get everything working, feel free to do a pull, inject some faults and create some troubleshooting labs.   Here’s the link to the github repo:

Repo for EVE-NG Exports
https://github.com/srmcnutt/CCIE.6495.EVE
0 forks.
2 stars.
0 open issues.

Recent commits:

Happy labbing!

-s

IKEv1/v2/IOS/ASA Cheatsheet

~ Steven McNutt ~ 6 Comments

Greetings fellow networkers.

This is a cheat sheet to cross reference the differences between the two versions of IKE as implemented on Cisco IOS and ASA.

I used Crypto Maps with pre-shared authentication as the reference example because  Virtual Tunnel Interfaces are fairly new on the ASA and I wanted a broadly applicable baseline.  To apply these to tunnel interfaces is a simple matter of replacing the crypto map with an IPSEC profile and calling that under your tunnel interface.

IKEv2 is not cast in the best light here based on the additional configuration in the example, but understand it has an enormous amount of flexibility and maintains a consistent configuration syntax and workflow for all of the VPN permutations compared to IKEv1, where things were bolted on over time.  Additionally, you need IKEv2 to utilize next generation crypto suites.  There’s really no reason to use IKEv1 in new deployments.

Best wishes,

-s

IPv4 redistribute connected gotcha

~ Steven McNutt ~ Leave a comment

In Cisco IOS, when you are redistributing between routing protocols, redistribution is not transitive, with connected networks of the source protocol being excepted.  However, if you explicitly redistribute connected, then the exception is removed and all connected networks must be explicitly redistributed.  It can be a bit confusing, hence the reason to break it down and write about it.

Let’s set up an example and observe the behavior.

We’ll make R1 a border router between RIP and OSPF.  R2 will be an OSPF router.

topo.jpg

red1.jpg

R2’s routing table:  r2.png

Now, let’s redistribute R1’s loopback into OSPF and see what happens:

red2.jpg

connected.png

The loopback is advertised, but the 11.11.11.0/24 network has been withdrawn.

Let’s redistribute our loopback into RIP instead

red3.jpg

Now we got nothin’:

red.connected.png

To break it down, there’s two things happening here:

  1. Redistribution is not transitive.
    1. i.e. protocol 1->protocol 2->protocol 3
      1. Protocol 3 will not get protocol 1’s routes
        1. connected counts as a protocol*
  2. The above rule is bent for connected when not explicitly redistributed
    1. The moment we redistribute connected into the protocol the transitive property is instated for connected routes.  This includes links the are covered by the source protocol.  I.e. the interface running RIP is considered to belong to connected before it belongs to RIP

Any time you’re asked  to redistribute connected into a border router, be mindful to pick up any additional interfaces that need to be seen by the destination routing protocol in your route map.

red4.png

red5.png