CCIE journey update part 6

June 7, 2019, was the date I chose for my second attempt at the CCIE lab.

My first attempt at the lab was April 12, 2019. It took me about a week to decide on when my next attempt was going to be. I reflected on my first attempt and came out learning several vital things.

1. I did a poor job confirming what pre-configurations there may have been in the configuration section.

For example, there could have been BGP configurations already preconfigured in my topology. I should have checked, reviewed what was there, and worked off of what was there

2. I linearly configured the topology.

My tracking strategy was vital, though I set a trap for myself. When working through the configuration section, each task I configured one after the other. What I mean by this is, if I started and complete section 1.0, my next part was 2.0. Configuring my topology in this manner set me up for failer. I needed a more strategic way to configure.

3. I worried too much.

Each completion of a section I worried that it was wrong. Even if I knew it was a surefire answer, I still worried I got it wrong. It’s like sitting for a math test where you are allowed to use your calculator, and you perform 3×3 on the calculator to triple-check that your brain knew how to multiply.

I purposely committed to a follow-up testing date that allowed me to maintain momentum but still able to work on my shortfalls.

At this point, I knew what I needed to do and got tactical about it. I put another 100 + hours into my studies before sitting on June 7. I got faster at configuring my full-scale labs by grouping configuration together. An example of this is if my lab called for a mpBGP core with OSPF as the IGP. I set up both protocols before moving to another task. That sounds simple, but it took practice to read ahead and recognize that there was a requirement for both. I started to do this “grouping” for everything I was asked to configure.

My studies stopped two days before taking off for my second trip to Richardson, Texas. I took down my business card from the cork wall at the gym and was bringing my good luck charm, my wife.

Test day

I was a lot less nervous this time around. My wife dropped me off at Cisco building 5, and it was game on.

I checked in with the receptionist and chose my lunch, knowing that I wasn’t planning on eating it. I was the first to enter the testing room, where I got assigned the lab station one to the left of where I sat on my first attempt. I waited anxiously for the other candidates to take their seats at their assigned lab stations.

It’s go time! I executed the same strategy for Tshoot as it had worked for me the first time around. After two hours, I tallied up my points and was undetermined if I had enough to move on. I had one ticket that could have gone both ways based on the restrictions outlined in the scenario and what my results were. I ultimately decided to move on because I didn’t have any more to give that section and didn’t want to eat up valuable time in the configuration section.

The Diag section was a bit more complicated than my first attempt. I ended with five minutes to spare and took my chance to use the bathroom.

I hit “phase 3,” the configuration section. I reviewed the entire test. This time around, I decided not to draw an L2 diagram. Instead, I relied solely on CDP, the topologies provided, and I double-checked my work before moving on from the L1/L2 section.

Lunch came quick, and I had completed L1/L2 connectivity, achieved same subnet reachability, I had started on some L3 in the core of my network and picked away at some low hanging fruit. I was feeling good. I saved my configurations before getting up and had left for lunch with knowing what I wanted to come back to next.

I took a couple of sips of my soft drink (Sprite) and waited for the others to finish their lunch. I would recommend getting something with some sugar in it at your lunch as this helped get me through the afternoon.

I came back to configuring my topology, where I faced some real challenges. I took them in stride and broke them down fairly quickly.

It was around 3 PM that I finished my last configuration task. I used the remainder of my time reviewing everything line-by-line. I found around ten points that I would have missed if I hadn’t had the time to review. I saved the running configuration on each device and left their terminal screens at the default prompt.

I left the testing center, knowing that I had a chance at passing. I shared my day with my wife over dinner and expected that I would know my results by the next morning. Saturday morning came and went, and I had no results. I woke Sunday to no results. Sunday night into Monday morning, I lied awake with anticipation of my test results.

Monday at 2:32 AM, I receive my email. I logged in to see that I had passed! I was awarded a CCIE #62183. I woke up my wife to share with her the news. She was more excited than I was!

There are a couple of things I wish I had done differently after reflecting on it.

  1. The EVE-NG platform looks to be more robust than GNS3. I wish I had invested some time to understand the platform.
  2. I shouldn’t have put so much emphasis on passing my first attempt.
  3. I started to read the book Getting Things Done by David Allen. I read the first 50 pages which helped but I wish I had finished during my studies.

What’s next?

I will focus on my family and work for some time. I will be getting into cloud networking and computing. Also, I might consider going back to school to round out my education.

Thank you everyone for your support!


CCIE journey update part 5

My business card hung from the cork wall posted at the exit of the gym. I hated the fact that my business card didn’t have a CCIE on it. Each day, I would exit from the iron palace, and reminded of it. It was a motivating factor for me. I took it down the morning of April 10th, two days before my exam.

I left for Richardson Texas April 10th. I remember sitting on the plane, amazed that I was about to head halfway across the country to take a test. All the time that I had spent behind a keyboard, sacrificing time with my wife, family, and friends. Not to mention the sleepless nights. It had all come down to this moment.

I felt ready. I had done everything in my power to give myself the best possible chance at passing on my first attempt. I knew that the probability of me passing on my first attempt was a mere 5%, but I was ready to defy the odds.

I felt energized and well rested the morning of my test day, April 12th. I had a light breakfast and took the hotel shuttle over to Cisco building number 5.

I was way too early to be there. I took a walk around the building where I stayed waiting for the doors to open.

I entered building 5, where the receptionist greeted me. I checked in and selected my option for lunch. Eight other candidates sat just to the right of the receptionist in a waiting area. I joined the other candidates. No one was talking. Not more than five minutes later, the proctor came around the corner, brought us back to the testing room, and assigned us our lab stations.

We placed our personal belongings in the back of the room. I sat back down at my station and waited for my queue to start. The proctor reminded us of the rules, wrote down the start time and the time we would be breaking for lunch on the whiteboard.

8:23 am – I started Tshoot.

I immediately felt frantic, stunned, and overwhelmed after hitting begin.

I took my pen and paper and began to execute my tracking strategy on it. At the top of my paper read:

Task Points Lvl Time Verified Comments

I then started to read through all of the Tshoot scenarios and began filling in the columns of my paper. My “Lvl” column was my confidence level on a scale of 1 – 3 that I used to rank my self on the scenario. Any “3s” in this column I took care of first. Followed by 2s and then 1s.

For Example:

Task    Points    Lvl      Time   Verified   Comments
1.                    2       3       8:33-               MPLS
2.                    4       3                             DMVPN
3.                    2       2                             IPV6

I was out of sorts while going through the scenarios, but I was meticulous about keeping each question to around 10-11 minutes. I did get to attempt each one. I felt confident in what I had for points at the end of two hours. I decided to move on to the Diag section and did not want to borrow any more time from the configuration section.

10:23 – 10:53 am – DIAG

I didn’t know what to expect in the diagnostic section. I decided that I would read the scenario and the supporting documentation. I then read through the multiple choice options that I had to choose. I was hoping that this would help me focus on what I should be looking for in the supporting documentation.

I finished DIAG with five minutes to spare. I couldn’t continue until those 5 minutes expired so I opened the doc CD and navigated to the relevant information that I thought may be useful to me during the Configuration section and took a bio break.

10:53 am – 12:00 pm – Config

I flipped my scrap piece of paper over and began to write down my tracking strategy. I then reviewed the topologies, read the entire lab, and drew my L2 diagram. I was only able to configure some of my L2 before needing to break for lunch at noon.

Task   Points  Time  Configured   Verified   Comments

12:00 pm – Lunch

It sucked that we had to get up to break for lunch. I felt like I had momentum behind me. We all sat together in a room with the proctor present. Again, we weren’t a friendly group. No one said anything. I took the chance to introduce my self to another gentleman to see if I could enlist some small talk, but that died before it started. I sat there without an appetite thinking to myself: “Ok, execute on phase 3”. I felt good about Tshoot and Diag but didn’t know if I had passed them.

It didn’t take long for lunch to be over. I could feel everyone wanting to get back into the lab.

12:16 – 2:30 – Resume Config

I resumed my L2 config and completed it. I verified that I had same subnet reachability for all of my devices. A great feeling!

I moved on to L3 and other one off tasks. I was feeling awesome!

2:30 – 4:36 – The “oh shit” moment

My feeling of “awesome” didn’t last long. Addmittantly, that was the last time I felt “awesome” for the entire day. I hit a scenario that was ambiguous and indirect. I sat there bracking down the question and the tasks associated to it and began configuring based on what I thought was being asked.

Ok, time check. .. .. 3:30 pm

Wait! I just sunk an hour into one scenario? I told my self I wouldn’t do that. I did the exact opposite of what I had practiced. It was at this moment where I panicked.

I started reading through the scenarios for “easy” points while also going back and verifying the work that I had already configured. I could feel myself completely losing hope and was spiraling out of control.

4:36 – END

I walked out of the test with my head down. I knew I had failed. I left way to many points on the table to not have failed. I made my way back to the hotel, where I called my wife. I told her that there was no way I had passed, and I was emotional about it. I was disappointed in myself, and I felt like I let her down.

I wanted so badly to feel different. I dedicated so much time and effort to this that I wanted to pass on my first attempt.

Final Result

I received my results early the next morning and waited until I arrived home to open them with my wife. Not to my surprise, the results read.

Tshoot – PASS
Config – FAIL

My results were hard for me to stomach. I allowed myself to sulk for the weekend.

Monday morning came, and I hit the gym hard. I brought with me my business card and stuck it back on that same cork wall that I took it down from five days earlier.


CCIE journey update part 3

I’m sitting to write this after several hours of lab time..

Around a month ago, I started INEs foundational labs. First one I did great, took me about 3.5 hours from start to finish.

The following week I started Foundation Lab 2. That took me about 25 hours to complete. I got stuck on a redistribution issue and wouldn’t allow myself to move on from it until I understood what was going on and how to properly diagnose and fix it.

The week after that I started Foundation lab 3. Foundation lab 3 took me 22 hours. I did both Foundation Lab2/3 over a course of a couple of day and performed code review afterwards. Redistribution was an issue in Foundation Lab 3 but wasn’t nearly as much of an issue for me as in Lab 2.

I still wasn’t happy with how much stumbling I did in both labs but I decided to try Troubleshooting Lab 1. I got my chin checked so hard! I got to ticket 5 and gave up. It was odd, I understood what the questions were asking but I sat almost paralyzed in thoughts… I spiraled for a bit in my own sauce for a week trying to figure out what I need to be doing to get to being, Troubleshooting Lab ready. I decided to go back to the Advanced Technology labs and get terminal time. This is what I am doing day in and day out. I’m trying to randomize things though. For instance ill spend an hour in multicast, jump to OSPF, go to IOS security for an hour. Then I’ll come back the next day and jump back into multicast from where I left off last, hit BGP, etc… Just trying to get my recall and enforcement up.

I met a fellow Cisconian going through the grind as well. It felt great being able to relate with someone. We shared our struggles and strategies and I’m hoping to link up with them soon to do labs and maintain our ambition.

Its an unreal, humbling and emotional experience going through this journey. I’ve never had to endure something so mentally challenging in my life. LET’S GET BUSY!!


“Start by doing what’s necessary, then do what’s possible, and suddenly you are doing something impossible” – Saint Francis of Assisi


CCIE journey update part 2

Wow. . . .

What. A. Day!

Just coming from my first attempt at the CCIE written. I passed! Unreal feeling!!

I’m not going to sit here and say that it was easy. It wasn’t, it was definitely challenging. I didn’t have the answers to what seemed like many of the questions.

It was such a odd feeling, I had an understanding of everything that was asked on the test, yet I didn’t have a surefire answer. It left me nervous for most of the test.

I had written down some reminders for myself on my white board before starting my test..

  • Trust your gut!
  • Read the question and answer thoroughly!
  • Take your time!
  • Process of elimination!
  • BGP well-known/optional/transitive attributes (for some reason I had this in my head and wanted to get rid of it so I wrote them down)

Now the above points, they may be obvious, but I needed a reminder. I wrote them down which oddly calmed me.


I was zoned in baby!

Clock check ..64 minutes left..Okay, i’m making good time.

Q70..Submit..Q90..Sumbit..Oh, man hearts racing again, finish line is near!

“Are you sure you want to end your exam?”..ya I guess



I’m not even going to lie, I did shed a tear. What a relief!

I walked out of the testing center yelling “LET’S GO!!!” “LET’S GO BABY!” “WOO!!”

I’ve put in a lot of work and the payoff seems so great. Yeah this is only the written and doesn’t actually mean anything but it most certainly does. It means that I’m following a process. The process is key to success. Forget about the overall goal. Put in the work, day in and day out. There is no choice, there are no excuses.

I will take a bit to enjoy this win, but not long!





Multicast BSR

Hello fellow networking savants. Hope you are all well, working towards your goals and certifications. For myself, I’ve been busy. A hungry busy if you will. Hungry for the next best thing.

Today I will be discussing Bootstrap router. Multicast is a weak spot for me so I thought it would be good to write about it.

Let’s get into it.

BSR is a standards based solution that shares RP information, it performs the same function as Auto-RP (Cisco proprietary) and uses the same concept of cRP or candidate RP.

There are two roles in BSR:

Candidate BSR – Similar function to the Mapping Agent (MA) in Auto-RP, shares information that it receives from all candidate RPs.

Candidate RP – The routers advertising themselves as a potential Rendezvous Point (RP).

Where BSR differs from Auto-RP is how it shares its information with other multicast routers in the network.

There can only be one active BSR in a multicast network and it’s election is based on highest priority, and if the priorities are the same among multiple BSRs the router with the highest IP address will be elected at the BSR.

BSR messages are sent to all routers on a hop-by-hop basis, sending its messages to the multicast address with a TTL of 1. When a multicast router receives this message it resends this message out all PIM enabled interfaces.

All multicast routers will eventually know about the source address of the BSR through these messages. The messages also include group range-to-RP set mapping. (more on this later)

Candidate RPs will know the address of the BSR and will register its self via a unicast packet to the BSR.

Once the BSR receives the registration messages from the cRPs, it will include all cRPs in its BSR messages and share them to all multicast routers. This differs from Auto-RP, Auto-RP picks only the best RP for every group.

Let me show you what some of this theory looks like on the command line.


Enable multicast routing on all routers and enable PIM sparse mode on all Ethernet segments for R4,R5,R8,R10


R8 has formed PIM neighbors with R5 and R10. All routers have their appropriate neighbors.


I’ll make R8 and R10 candidate RPs


I’ll make R5 the BSR, but before I do that I am going to turn on debug ip pim bsr for R5,R8 and R10.

From R5s debug output, you can see that it received both R8s and R10s RP registration.


From R4s perspective, it knows about the BSR at R5 and the two RPs at R8 and R10.


Notice that R4 is seeing both R8 and R10 as possible RPs for the group. This is known as the group range-to-RP set mapping. This was included in the BSR messages that R5 generates.

We’ll have to check the rp-hash for the group to know who is the RP.


R10 is the RP for How was this determined?

  1. If the RPs advertise for the same group (in our case) prefer the one with the lower priority. Default it 0.
  2. Look for the highest hash value if priorities are the same.
  3. Highest IP address will be preferred if priority and hash values are the same.

R10 won the election based on having the higher IP in this case.

The hash value is an interesting feature that allows us to load balance our groups between RPs.

The hash value is based on a 32-bit value. By default this hash value is 0. So this means the hash value will be calculated on the IP address of the RP.

Lets change the hash mask length to be 31 on R5 the BSR.


Lets view R4 to see what this has changed.


R4 now see R10 as the RP for the group and R8 as the RP for the group. Changing the hash mask value has allowed us to load balance our groups.

We can also confirm this from a data plane perspective. I’ll join R4 to two different groups.


I joined R4 to group and, notice the RPs for both (*,G) groups.


Summarizing Discontiguous Networks

There are a series of posts by INE, I believe the author is Brian McGahan (A very smart guy to say the least), that explains how to optimally create an ACL with discontiguous networks.

You can find the series of posts here

Binary Math Part1
Binary Math Part1 – Answers
Binary Math Part2
Binary Math Part2 – Answers

I apologies if I’ve given the credit to the wrong INE instructor, you guys are great!

I attempted to summarize the process that is so wonderfully explained in great detail in the above posts. The scenario is below. Just after the scenario is the summary. The answer to the scenario is left out.

Create an ACL to use as an access-class on the VTY ports.  Use as few lines as possible.  You must use two “deny” statements in your ACL.

The following hosts should be allowed to telnet into your router:

Summarizing discontiguous networks