BGP Ticket(s) - Multiple faults

Buckle up, it's BGP time. This ticket, or tickets features multiple fault points. I went a little overboard to be completely honest. So here we go! When all tickets are resolved, both R6 and R7 should have full readability to R1. You are not allowed to modify the configuration on R1.

*Note, recommended that you fix tickets in order.

GNS3 Files

Ticket #1

AS 5432 has a new customer, the data activation team has completed work but BGP isn't peering between R4 (AS 5432) and R6 (AS 6).

 - Do not remove any security features.
 - You have permission to access the CE device, R6, however you are only allowed to modify routing configurations that are directly related to R4/R6 peering. No global changes may be made.


Ticket #2

R3 is not able to peer to R1, a network admin has observed an odd BGP peer state on R3. R1 an edge router from an upstream ISP and is not accessible in this lab. Ensure that R3 is able to peer with R1.

 - NO static routes may be added to R1
 - Peering must be between Loopback interfaces
 - eBGP multihop may not be altered.


Ticket #3

R7 can not ping R1. You remember reading an email from the upstream ISP about security changes with regard to AS Path. However, that's all you can recall.

- Resolve this ticket without using any summarization or NAT.


Diagrams:

Solution(s):

Working on a Fun BGP Lab

I'm not dead and gone! I've just been extremely busy with work and studying. Things might calm down next week, and for the few that actually check this blog I have a fun BGP ticket coming. It's about 75% done now, I want to toss a couple curve balls in there though. Should be a good example of a (3) point ticket with two faults.

Fun with MPLS - Part 2/'however many of these I feel like doing'

It's been a peaceful couple weeks at iHatethisjob INC., perhaps too peaceful... Come to think of it you haven't had ANY calls. Seeing as you're Xbox is broken, and you're all caught up on Downton Abbey (don't lie to yourself), you decide to investigate. First things first you try to ping the PBX over in Carmel from Delaware, to your horror pings are timing out. After logging into the Delaware MPLS router you see that Carmel's subnet shows as an Inter-Area route, this is not the way you left it.  After some troubleshooting you see that no traffic is reachable over the MPLS backbone, and people from the Carmel office have discovered cells phones. Peace and quiet gone you call up the SP to get to the bottom of this, before getting your first sentence out the solutions engineer confesses that one of the Security techs made some configuration changes and now nothing works. 

Your mission, fix the provider network (again) and restore connectivity between both sites. Insure that remote prefixes from both sites show as OSPF Intra-area routes. Also, don't be cheap, follow these restrictions:

- You may not add any new interfaces.
- You may not change any routing protocol boundaries.
- No static routing is allowed.
- You may not enable any additional routing protocols.
- When possible, avoid disabling features. 

**HINT**  THERE ARE TWO FAULTS

GNS3 Files

DIAGRAMS/Example:

Solution:

No Dice

Well, it kills me to report that I've failed my third attempt. I knew at 9:30am my day was shot, I had not been able to complete either of the three pointers on the troubleshooting section of the lab. It's hard to explain how that felt... it was the first time I'd failed TSHOOT. Missing BGP and MPLS tickets, two subjects I considered myself very much expert in. Though I would not pass, I decided to stick it out and tackle the Configuration section... which I ultimately failed as well.

Suffice to say, it was not a good day for my ego, but that's part of it. A co-worker of mine put it best, 'the only attempt that matters is the one you pass'. Very true, but it didn't make it any easier to drive home knowing so many people had counted on me to pass. Knowing my boss's boss was expecting me to come back with a number. It's difficult, but I'm not done. I'll learn from my mistakes and come back in August for another round. In the mean time, I'll have another MPLS ticket out this week =].

Off to Raleigh, for my third (and hopefully final attempt)

No trouble ticket today, just nervous as hell and wanting to vent to the glorious internet. My lab @RTP is scheduled for the 8th, the Monday following this long weekend. I feel pretty good, but there's always the unknown... which is killing me. The amount of time and stress that comes with pursuing the CCIE is more than I think anyone can prepare you for. When I started prepping almost two years ago, I knew that having my IE was part the dream I had for myself. I wanted to be among the top tier Engineers in the world, and I knew that going after my number was the best way to get there.

Not because having your CCIE makes you the best, but because the work you have to put into preparing, the road you travel does. Over the past two years I've taken my skill set to a level I thought wasn't possible, hell the difference between my last attempt in February and now is noticeable to me. I know this is what I want to do, and I know that no matter how many times I fail... I'll come back for more. That's what really makes an IE an IE, being able to not only dedicate yourself to being the Engineer you can be but also being able to recover after defeat. To press on.

When you're preparing for the lab there's a lot of "opponents". You face off against your won ignorance in the beginning, once your knowledge starts catching up to where you need it you start facing more personal demons. I know I sound over dramatic, but for me I found that I had (hopefully that remains past tense) terrible time management and accuracy.  The combination of the two lead to endless embarrassing mistakes, because there's no such thing as partial credit on the IE. I spent these past few months leading up to my third attempt trying to isolate and exterminate these problems. Working on not only being fast, but working smart validation methods that help me check each section before moving on. That's something else that comes with a lot of prep time. GRADE YOUR OWN LABS! At least a few of them, because when you're running validation commands from your work book, you're not just seeing how well you did on that given lab... you're also gaining insight on how these beasts are graded. This is to your advantage, because you too should run the same validations.

So finally, I'm not an author lol. This post is terribly structured and likely full of grammatical errors. All I want to impart on my fellow geeks is that this path isn't for everyone, but if it's for you embrace it. You can spend a lot of time kicking yourself and feeling down when mock labs return poor scores, or when you fail the real lab. However I'd recommend that you don't. Advice I hope I don't have to follow July 8th, but true none the less. This lab is tough, likely one of the most difficult things you'll have to overcome in your career. Failure is part of it, but failing a lab attempt is failing at getting your number. It's nothing more than a mile stone in the long road to the top of the hill, and getting your digits. To all those after their number, best of luck, and with a bit of luck I'll have happy news the evening of the 8th!