Running a BGP Free Core - Quick and dirty

So it's the end of the year, and I wanted to do a quick video/post to round of the blog for 2015. A concept that's relatively new to me (sadly) is running a BGP free core, and it's relatively easy to set up. That being said... I know it's kind of a lazy post. Hopefully one that will spark some interesting conversation and inspire new posts in 2016!!

That being said, let's talk about the the concept, and the problem it's trying to address. BGP tables for IPv4 are $@#%@ massive. Over 500,000 prefixes which, obviously, is a lot. Traditional networking would call for every device in your core to have these routes (or summaries of them) in order to ensure reachability. However, what if I told you there was a way to only have edge routers store these massive BGP tables and to keep the core running light and efficient?!

Of course you want to know. MPLS. *Mic drop*. With MPLS the core doesn't have to know anything about the outside world, all it needs is labels for reaching edge routers. But why?! So I have a working environment pictured here:

Ok, to keep things simple I shutdown P3 and P4. Let's see what happens when R1 tries to send traffic to R2's loopback 0 interface.

R1#show ip cef 172.16.2.2
172.16.2.2/32
  nexthop 172.17.111.11 GigabitEthernet0/1
R1#show ip route 172.16.2.2
Routing entry for 172.16.2.2/32
  Known via "bgp 1", distance 20, metric 0
  Tag 1122, type external
  Last update from 172.17.111.11 20:55:28 ago
  Routing Descriptor Blocks:
  * 172.17.111.11, from 172.17.111.11, 20:55:28 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 1122
      MPLS label: none 

Alright, nothing fancy yet, we see a next of of 172.17.111.11 (PE1's Gi0/3). Moving right along, let's go over to PE1 and see what's happening.

PE1#show ip cef 172.16.2.2
172.16.2.2/32
  nexthop 10.1.11.1 GigabitEthernet0/1 label 26
PE1#show ip route 172.16.2.2
Routing entry for 172.16.2.2/32
  Known via "bgp 1122", distance 200, metric 0
  Tag 2, type internal
  Last update from 10.22.22.22 20:53:59 ago
  Routing Descriptor Blocks:
  * 10.22.22.22, from 10.22.22.22, 20:53:59 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 2
      MPLS label: none

Now things are getting a bit more interesting, checkout out our 'show ip cef' output. Label 26... put a pin in that, we're coming right back to it. Ok, so we have a next hop of 10.22.22.22 (loopback 0 of PE2), but cef shows that we're forwarding this traffic out Gi0/1 towards P1. Let's go to P1 and issue the same commands (show ip cef and show ip route for 172,16.2.2).

P1#show ip cef 172.16.2.2
0.0.0.0/0
  no route
P1#show ip route 172.16.2.2
% Network not in table

You're reading that right, no route. I can smell your fear from my monitor. Don't panic, allow me to explain. Go back to the output from PE1. remember that label 26? Let's follow the label brick road, and see where that takes us.

PE1#show mpls forwarding-table | i 26
28         26         10.22.22.22/32   0             Gi0/1      10.1.11.1
P1#show mpls forwarding-table | i 26
26         26         10.22.22.22/32   9772          Gi0/1      10.0.12.2
P2#show mpls forwarding-table | i 26
26         Pop Label  10.22.22.22/32   73            Gi0/4      10.2.22.22 

Alright, so PE1 has an LSP (label switched path) to reach the loopback of PE2. For brevity, just take my word that the reverse is true. On the second to the last label hop, per MPLS standard, P2 performs a pop operation and forwards the traffic on to PE2. Alright, to put a bow on this thing let's tie together the final peices of the pie, by answering a question I feel like some of you must be asking yourselves. Why does it matter whether or not PEs have an LSP between their loopbacks? For that matter, how is it remotely related to R1 and R2 communication? To answer that, first let's look at the show bgp ipv4 unicast output and a show run | sec router bgp on PE1.

PE1#show bgp ipv4 unicast | beg Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.1.1/32    172.17.111.111           0             0 1 i
 *>i 172.16.2.2/32    10.22.22.22              0    100      0 2 i
PE1#show run | sec router bgp        
router bgp 1122
 bgp log-neighbor-changes
 neighbor 10.22.22.22 remote-as 1122
 neighbor 10.22.22.22 update-source Loopback0
 neighbor 10.22.22.22 next-hop-self
 neighbor 172.17.111.111 remote-as 1

Very similar output can be observed on PE2. The magic that's happening here is PE1 knows to reach 172.16.2.2 via 10.22.22.22 (loopback0 on PE2). PE1 also knows that it has an outgoing label of 26 to reach 10.22.22.22. So instead of just forwarding traffic to 172.16.2.2, or requiring a label specifically for that prefix, it just encapsulates the traffic MPLS with a label for PE2's loopback 0 interface. Effectively tunneling this communication through the core network to PE2. So in short... magic. Finally, as promise, so wireshark output from R1 pinging R2.

So what you'll see in the following screenshots is

1. R1 forwards traffic PE1, stock standard IP.
2. PE1 forwards traffic to P1 using label 26 (to reach PE2).
3. P1 forwards traffic to P2 also using label 26 (just a coincidence they share the same label for 10.22.22.22)
4. P2 does a pop operation and forwards the original IP packet from R1 to PE2 with no label. Then obviously PE2 forwards the ICMP packet to R2.


Link from R1<>PE1

Link from PE1<>P1

Link from P1<>P2

Finally, P2<>PE2

Well, that's it for this one guys and gals. Happy New Year, and I'll see you in 2016!!

Video here

CCIE SPv4 Lab: Running it on my laptop (w/only 16GB of RAM)

BIG shot out to VMWare ESXi, because that finally did the trick. Currently, I'm visiting family for the holidays but I still want to be able to study when I can. I know that's super nerdy, but if you're reading this... you're not much better than me. So stop judging. I've recently purchased a server off eBay (nice Dell R610 with 32GB of DDR3 for ~300 bucks), but it's not yet arrived so I've been trying to get something workable in place for the interim. At home my workstation has 32GB of RAM, and is fairly capable of running these SP labs. However, I'm getting both off point and a little ahead of myself. Let me first tell you about my lab topology, from INE's SPv4 material.

 - (10) CSR1000v. The CSR1kv has certainly come a long way in terms of requirements, but it's still a hefty beast. You can technically get by on (1) vCPU and 2.5GB of RAM, but I like to run mine with 3GB of RAM. So right off the bat, I'm at a potential 30GB of RAM needed.

- (4) IOS-XRv. IOS-XRv runs perfectly well with only 2GB of RAM, so we're up to a potential 38GB of RAM needed.

So, obviously these VMs will rarely (if ever) use that much memory. That doesn't matter with VIRL though, because it will still prevent you from firing up that environment without 38GB of available memory. First attempt at resolving this, lie to VIRL. I went into my VMWare Workstation settings and told it "Allow most virtual machine memory t be swapped"

However, for this to really work I'd need to limit overall memory usage of all my VMs to ~8-10GB and swap the rest. Workstation doesn't like that, anything over 3/4 being swapped and Workstation will not let you boot the VM. Which wouldn't be a huge issue, except for the added overhead of VIRL itself, requiring anywhere from 2.5 - 5GB of RAM to run. Also keep in mind, I know that swapping that much will just murder performance, but I'm not after performance. I'm after boot 14 routers that move JUST fast enough that I can lab with them until I get home. So I hit a wall there. I tried my GNS3 Server approach (as covered in earlier posts)... but GNS3 can have odd issues with environments that get powered off and on several times. I even ran into issues with shutting down the server with GNS3 still open... then the server would just be perpetually hosed upon next boot. This just felt like WAY too much effort lol.


"Okay, we get it. How did you actually get it working?!"

I had this half baked idea, that I honestly felt wouldn't work. "What if I nest ESXi inside workstation? Give my ESXi VM a small amount of memory, then just try to boot everything?" I know ESXi is way better about swap when it runs out of RAM (hence why I bought  server explicitly for my SP lab), but I didn't think this would work well enough to actually use. I was wrong. I gave ESXi 8GB of RAM, loaded up (10) CSR1KVs and (4) IOS-XRvs and booted everything up. My laptop's CPU spiked really hard, and remained at ~89% for 5-10 minutes. After that though, it seemed to settle down well enough, and... everything booted. More than that, I copied base configs in for all devices and everything was talking!! Response times between devices is fairly high, but no more than dynamips routers really (averaging 30-60msec). That's totally ok though, and the console response is almost perfect after everything is booted. Nearly no lag... enter screen shots!!!

As you can see, all nodes booted and ESXi is just amazing at memory management apparently. On my host side, here's what task manager looks like:

I mean, it's definitely loaded (and when my work VM is running too, mem is at 96% utilized), but my laptop isn't melting!! As a follow up to this post, I might record a video showing off my VMWare config, the full on home lab I'm planning on using vSphere so I can have easier packet captures with a jump host. That's all for now though! Thanks for reading, and comment if you have questions or suggestions.

The way forward

Blog.. TRANSFORMATION TIME!! Thanks to my long-time, and very good friend Steve Occhiogrosso (found here at ccie-or-null.net) I think I finally have a way forward. Since I passed my lab, you know WAY back in April, I've been feeling a bit empty. Just dying to be working on something new and different. For a while I toyed around with the idea of going the Data Center route (since I work in cloud services), but to be perfectly honest I just didn't feel the fire when I was going through the material. Nothing jumped out and pulled me in, and you really need that when you're considering an IE.

Enter Steve. In a brief chat, I was explaining how DC didn't seem like the path for me. Between a huge influx of interest in DC resulting in next to no available rack time... I wasn't feeling it. Then Steve very casually mentioned "What about Service Provider?"

...

Of course SP makes sense for me! MPLS is one of my absolute most favorite topics, so right off the bat I was really excited. So I cracked open INE's CCIE SPv4 material (all access pass, true nerd) and skimmed over it, all the while getting more and more enthused. Even better, they just revamped the exam mirroring the style of R/S v5 so you can virtualize everything. So, SP is my next mountain to climb, buckle up for SP related posts.

Let's talk about ACI - Cisco's SDN vision.

So everyone keeps saying "SDN is the future!! Network Engineers beware!!", and it's been a few years but generally my reply to that remains the same. "Meh." I'll save my general SDN opinions for another post. This post is about Cisco ACI, and all the fantastic fail that it is. In fairness, I'll start with things I like about ACI first... then I'll drag my soapbox out.

The Good!

(1) VXLAN... oh how I love thee. ACI brings you vxlan right out of the box, links between spines/leaves are IS-IS, and there are literally NO L2 links between fabric nodes. This is pretty awesome, admittedly not remotely unique to ACI, but very cool that this is the default behavior. (2) Bash shell on your network devices. The latter is pretty cool, but I'll go over the downsides soon. It was unsettling to log into a very NX-OS looking shell, but have full use of my favorite Linux commands. I want you (yes you, all 5 of the people that will read this) to know, when I started writing this blog, my intention was to make this section longer. I swear.


So, that all sounds kind of cool right? ACI must not be so bad after all!! Nope.

The Bad, and the Ugly.

I'm going to try my best to keep this section short, but I get the strong feeling I'm only going to become enraged as I type along. Any Windows users out there? It's ok, this is a safe place, I'm typing this post from the comfort of my Windows 10 workstation. Remember when Microsoft decided to take the start button away? That's how MOST of ACI feels. It feels like Cisco took my [slew of obscenities] start button away. Before ranting about what an awful mess it is to try to use REST to configure anything, let's talk about the things you just don't have currently in ACI. I'll start with the biggest one, traceroute. You heard me. You. Can not. Traceroute. 

[Stopping to allow that to sink in]

That's right, no traceroute. Sure the command is there, but it does nothing. Cisco documentation will refer you to "itraceroute", however that traceroute only shows the path within the fabric... making it useless really. I also hate that when converting a 9500 chassis to ACI, if you migrate one SUP to ACI mode... the change isn't replicated to the standby, which can lead to this just... weird flapping scenario until you figure out what happened. I know, because it [slew of obscenities] happened to me. Even better, if Cisco didn't ship your SUPs with the latest SSL certificates, your fabric will not come up. At all, OH, and you have to contact TAC to get it resolved. Again, I know... because it happened to me.

Automation, pretty much the only reason anyone thinks "Yeah, we should implement an SDN solution." Was just... painfully slow. I've used python scripts to push mass changes to non-SDN architecture at other jobs, and that was faster than trying to push changes to ACI. It was just slow. Speaking of slow, the APIC GUI is, as GUIs are, slow. Shutting/no shutting a single interface can take 2 minutes. Log into the APIC, wait. Go to Fabric, wait. Expand inventory, wait. You get it, it's a WebUI... it's freaking slow.

Which brings me to REST, because surely you're reading this thinking "C'mon there has to be a faster way to make those sort of one off changes?!" Yes, there is. REST, sort of your replacement to the ultra fast CLI that we all loved. With REST, there are a number of different ways to POST changes, I decided to use a REST plugin for Firefox. Finding documentation on using REST with ACI, turns out to be a nightmare. After digging through documentation for a period of time, I finally found out how to actually get my auth token so the APIC would allow me to POST said changes. Then I found a doc on shutting/no shutting ports via REST, which turned out to be wrong. Cisco's documentation on using REST with there own product, was wrong. Of course I didn't find this out immediately, because REST is just using HTTP so you don't get handy CLI-like errors telling you specifically where the syntax is invalid... you get HTTP error codes lol. Which is just, awful. So I found some useful information on Cisco support forms that showed the correct formatting of a REST call for that purpose, modified the information to fit my environment AAAANNNNNNDDDD.. new and different HTTP failure code. I tried at this for another 15 minutes or so, before throwing in the towel and just using the slow GUI to make my changes. One port at a time, I finally resolved the given issue I was after. Naturally the next day I had to sit through a sales call with ACI guys talking about how ACI was the best thing since sliced bread, all the while the environment is proving the be least stable we have, and took the most amount of time to deploy.

Honorable mentions for things I also hate about ACI!

- Default behavior doesn't allow for GARP tracking, or ARP flooding. VRRP fail overs were a nightmare. (Can be resolved, just annoying in the heat of tshoot).

- VLANs are localized to the switch, which is fine... but ACI also maps them seemingly arbitrarily to other VLANs. So if you're looking for where VLAN 10 is, you need to see what THAT particular switch mapped VLAN 10 to, and then you can see what ports are in the mapped VLAN. Which will change switch to switch.

- ACI NX-OS is just NX-OSish to make you feel at home until you need to actually use a show command. No tab complete, no context sensitive ANYTHING and if you want the old NX-OS back you can go into vshell, but the commands will often return empty or incomplete information.

- You can not the see "running config" of anything. Which just gets SO old. Sometimes you just want to look at how BGP is configured, or how an interface is configured. Can't do that, so your stuck with using a variety of other show commands to eventually get the information you were after in the first place.

- Contracts. Do a little reading on your own about endpoint groups (EPGs) and contracts. Implementation is sloppy, and doesn't make much sense. Having a white-list only LAN sounds cool, but even Cisco just ends up recommending that you permit any any inside a given group.


That's all I have for now, this post is already too long so I might just do a part 2 later. 

VPLS BGP Signaling (this is really cool)

So, a while back (~ a year ago now) I did a YouTube video/blog post about having a sort of hacked VPLS environment in GNS3. Why?! Because it's awesome to have a multi-point l2vpn running over MPLS, that's why. 

Today, I bring you a post/video that's far from a hack. Full on VPLS using my best friend the CSR1000v, and using BGP for signaling.

CSR1000v and GNS3, best thing?

Really quick post today about integrating the CSR1000v into GNS3. First up! Why would you want to do this?

1.  Latest greatest IOS
2.  Feature packed (supports VXLAN, OTV, MPLS, VPLS, and a ton more)
3. What do you want from me? Those first two should be enough.

Video at the bottom for those too impatient to read (like me). First thing you're going to need, a fresh ISO of the CSR1000v, available from cisco.com. I'm using "csr1000v-universalk9.03.14.01.S.155-1.S1-std.iso", but depending when you read this your mileage my vary. After you have that, I think it goes without saying that you'll need GNS3 installed, and VirtualBox.

VirtualBox
In virtualbox, create a new VM. Set the OS type to Linux and version to Other Linux (64-bit). Give it at least 2.5 GB of ram (2560 MB), but if you can spare it 4GB is better. All default values after that are totally fine, you won't need more than the standard 8GB hard drive.

Now open the settings for your new CSR virtual machine, on Serial Ports check port one's "Enable Serial Port". You leave it disconnected, GNS3 will handle the host pipe end (if that doesn't make sense to you, then just know that GNS3 will do some magic and you'll have a working console port).

Next up, go to storage and set the CD drive to point to the ISO you downloaded from Cisco (or from the wild wild internet). When all is said and done your VM should have settings similar to this

Alright, now we can boot it up. You'll see a dialog box asking if you want to (a) auto detect console type (b) use vga or (c) use serial. For now, auto detect is just fine. This process can take a few minutes, IOS-XE will do a nice and neat auto installation and reboot. After a reboot you'll come to a familiar IOS prompt. Last thing we want to do, go into global configuration and set the console port to be serial only "platform console serial". After that, exit global config, wr mem and shut the vm down.

GNS3

Open up GNS3, go to File-->Preferences->VirtualBox VM templates. From here you're going to click "new". From drop down VM list, select your CSR1KV and check the box "Use as a linked back (experimental)". That last step is a huge, what it means is you can dynamically create CSRs without being limited to how many are available in VirtualBox. I.e., you create (1) CSR1KV in VBOX... and that's it. GNS3 will handle dynamically cloning routers for you, giving you a very dynamips-like experience. 

Now click "Finish". 

From here, I like to first right click on my newly added CSR1KV and select "change symbol". Then I select a nice router icon and set the category to "Routers". This will make it so your CSR1KV shows up with all your dynamips routers instead of as a vbox guest.

Finally add some additional network adapters to your new VM by clicking on "edit" and going to "Network". I run mine with 5 nics each. That's it! You're all set, final note is linked base guests can only be run in saved projects. That means you have to create a new project (can't just use a temporary work space) to add your VMs. No big deal really, but if you forget GNS3 will give you a friendly little error/reminder.

See my video on this process below for those of you who don't like reading!

GNS3 All the Things!!

Coming soon, I'm going to do a short video series about getting all your favorite VIRL appliances (vNX-OS, ASAv, IOS-XR, vIOS, and vIOS-L2) running in GNS3. So you can enjoy all the power of a modern virtual lab, without the overhead from OpenStack (what VIRL runs on).

VXLAN and GNS3!!!

This isn't going to be a super long blog post, but I just wanted to quickly add my recent videos :-).



Install CSR1000v into Virtualbox, and integrating with GNS3

And VXLAN in GNS3

Passing the CCIE (R/S) - A non-technical post

This is going to be me rambling. Fair warning.

I wanted to write down my experience with CCIE lab, now that I'm finally done. Not what technologies I saw, or who's workbooks helped the most (though I'm happy to answer those questions, so long as they don't violate NDA). This post is about the mental side of the CCIE, and I'll probably write a little bit about life ~two weeks after passing and getting my number.

A brief back story.

So I started my CCIE journey, unofficially sometime in 2011 (summer I think?). I passed my written on December 14th 2011 (version 4), and had my first attempt at the lab October 2012. My first attempt was such a rush, it was so great to be there in RTP... in the lab, I almost didn't care that I failed. I did pass troubleshooting, so I had that on my side, but the configuration section was brutal. I made some additional attempts in 2013, and was never met with success. I even went to a 5-day lab focused boot camp before one attempt. Still, no love. I remember riding home on the train (yes, the train) after failing the v4 lab, for what would be my last attempt at v4 thinking "Maybe I'm just not meant to pass this thing." I credit my wife with telling me that I needed to try one more time before she'd support me giving it.

2014 - too much happening

Towards the end of 2013 my wife and I decided to full-fill our dream of leaving Florida, and moving to North Carolina. With changing jobs (a couple times) and a second move to be closer to RTP, 2014 came and went. Very little studying and no attempts.

2015 - Let's make this happen.

In January I took a v5 mock lab and scored 95% overall. This got me excited about the technologies, and got me off my butt and back into labbing. I spent the next couple months dedicating ~10hrs a week to studying. Sometimes a little more, sometimes  a little less. Keep in mind, back in my previous attempts I dedicated 15-25hrs a week to studying. So I had a solid foundation, and felt that I needed to really work on strategy and lab changes.

I ran a number of mock labs, and made my way through workbooks fine tuning my own personal strategy. This turned out to be a BIG change for me, instead of approaching the lab the way others had told me to with a cookie cutter approach, I decided to read through each lab and develop a custom strategy for each. This resulted in, generally, very good scores and faster times. When I was about two weeks away from my lab, I decided that I would run (1) more graded mock lab and no matter the results I wouldn't run any more. Just focus on workbooks. Reason being is while I wanted to make sure I was on top of my game, I also didn't want to be burned out.

One week before the lab

So at this point, I've run my last graded mock lab, and luckily for me I scored a nice 85%. Not amazing, but hey it's passing. At this point I'm doing very little lab work, maybe spending an hour here and there working my way through a given workbook lab. Then 2 days before the lab, cutoff time. I had decided not to do anything, but maybe watch some video lectures at this point. Again, my thinking was "I want to be sharp, but I don't want to be completely burned out."

Night before the lab

I went to the store, picked up some things:

- Red bull (4 pack of 8oz cans - sugar free, don't want the sugar crash)
- Water, staying hydrated helps you stay alert and jitter free
- Trail mix, don't trust the lab food. The cake is a lie.

You should know that, yes they do feed you... but you shouldn't eat very heavy at the lab. Reason being, and this is a theory, they're counting on you going after the cookies and cake, eating a heavy lunch...ANNNDDDD crashing 2hrs before the lab ends. So I aim to eat a little protein, some fruit and salad. Anyway, back to the night before. For weeks I had been so cool, so confident. Then all the stress of passing the lab hit me like a ton of bricks, I slept absolutely terrible.

Lab Day. April 1, 2015 (April Fools Day)

I'm up at 5:30 am to get dressed, have breakfast, and make the drive to RTP to arrive at 6:45-ish. First things first, I slam some orange juice, vitamins, and drink a protein shake with some fiber added in. I should note at this point, I'm not a super fit person, but lab day is like running a freaking marathon, failure to treat it as such will leave you disappointed. So no caffeine yet, which is hard because I normally drink coffee before doing literally anything else. However, experience tells me I don't want to be jittering in my seat at the lab. So Red bull is on standby at this point. With some minor traffic on I-40, I still make it to building 3 around 6:50. This turned out to be completely fine as the proctor didn't arrive until 7:25 on this particular day.

Now you have to go through some pre-lab rules with the proctor. He (or she) is going to tell you some basic do's and don'ts. For example, no electronic devices in the lab, and only one person out of the lab to the restroom at a time, etc etc. This takes about 10 minutes or so. If you're in RTP, the proctor (Dave), will crack a few jokes to try and ease everyone's tension. Welcome the laugh, you'll need it you nervous wreck you!

Troubleshooting Section (120 minutes + up to 30 minutes borrowed from Configuration)

Crack open a Red bull, and go time!! I used one sheet of paper as a TPS so I could track what tickets I had completed, and how many points each task was worth. This was the most difficult troubleshooting section I ever had. I kept going through phases like
"I got this ticket"
"wait... no I don't"
"Oh God, I'm going to fail the lab again!!"
"Ok calm down, focus, try the next one and circle back to this one later."

Plan here was fairly cookie cutter, contrary to previous statements. Spend roughly 6-8 minutes on each ticket, if I couldn't figure it out I'd make a couple notes on my TPS about it and move on. When I reach the last ticket, circle back to beginning, rinse and repeat until all tasks were completed (or I had enough points to pass). I did have to borrow 15 minutes from configuration, but it was well worth it.

Diagnostic Section (fixed 30 minutes)

Guys and Gals... this section is weird. If any of you did the CCNP TSHOOT exam, it will feel sort of familiar. You'll be given a few scenarios, call it 2-4 different ones, where they outline a problem description (usually from the point of view of another network person). You'll also be given any relevant syslog, running configurations, network diagrams, and the original help desk ticket. With the help desk ticket they're giving you the problem from an end user's perspective.

With all that information at your disposal, you'll get some multiple choice questions. Before you have a sigh of relief about it being multiple choice, these are normally 2-part questions. I.e. for one question you have to select which device is causing the issue and which commands should be run to further diagnose the problem.


Configuration Section ( 5hrs 30 minutes + leftover time from troubleshooting)

So my configuration section was actually 5 hrs and 15 minutes, since I had to borrow time in TShoot. Now, here's a truth that all candidates need to accept about the configuration section (and really the lab as a whole). You are not going to get every point. If you hope to pass, you'll learn to pick your battles and make smart sacrifices. If you see a 4 point task that you're unsure about... but has the potential to break other tasks if configured wrong, well that's one you should eat the points on. I did that with (1) task in particular. I was 80% positive I could figure it out, but after spending 10 minutes on it and making no progress I realized "I'm wasting time, and furthermore if I misconfigure this I could break certain parts of my routing and cost myself 12 points... all for only a potential 4 points? Nope, pass."

It was such an insane day. I always thought that when I finally passed the lab, I would know it all day long. That is, during the lab I thought I'd never doubt myself and I'd finish 2 hours early. That's not what happened. I was panicking almost the entire day. I would force myself to stop and breath. Get up to go to the restroom. Just for a few minutes to calm down, and refocus. I honestly didn't think I had a chance until the last hour or so. Then I caught myself thinking "I might pass this thing today." I used every single minute, up until the last 5 minutes on the clock. However, I walked out the front door knowing I passed. I'd never felt so confident, and I'm so happy it was just.



About two weeks later

So I passed the lab!! CCIE 47884!! I was showered with rose petals, and I was given a 20k dollar raise! Oh and a new Macbook Pro retina!!!

Ha. Nope. Honestly, aside from me running around my house at 6 am the next morning when I finally got my results, it was pretty anti-climatic. A few congratulations at work, and recognition from colleagues. Which I'm totally OK with. This has been such an awesome experience and I wouldn't trade it for the world. My advice to other hopefuls out there? Don't quit. Getting your number is hard, and its meant to be hard. But never give up.



Sincerely,

Jon Major, CCIE# 47884 (yes, that number goes on everything I sign)

CCIE# 47884

Can't. Stop. Shaking. I just got my results in and after nearly four long years, I'm a CCIE. More to come later. I do want to write up my general feelings on the exam, and what v5 candidates should expect.

OSPFv3 for IPv4 (hooray address families!)

OSPFv3 is a pretty slick upgrade to OSPFv2. Most of us know as much, but in an IPv4 world we're all just stuck... waiting. Well with recent updates to IOS (I noticed it available in 15.3 - which can run on a 7200 in GNS3 for all you labbers at home) OSPFv3 now supports multiple address families. So much like with EIGRP named mode, we're seeing Cisco migrating routing protocols to follow the format of MP-BGP. The catch 22 with IPv4 routing with OSPFv3 you do have to have IPv6 unicast-routing enabled, AND all participating interfaces have to have IPv6 link-local addressing. The reason being, as we'll see in Wireshark, is that even though we're relaying information about IPv4 prefixes all communication with OSPFv3 is still done in IPv6. So let's get into the configuration, and we'll double back on packet level details.

Topology:

SP-METRO
!
conf t
!
ipv6 unicast-routing
!
router ospfv3 1
address-family ipv4 <-- support for VRF here!
!
!
interface Ethernet0/0
no switchport
ip address 200.1.1.1 255.255.255.252
ipv6 enable
ospfv3 1 ipv4 area 0.0.0.0
!
!
interface Ethernet0/1
no switchport
ip address 200.1.2.1 255.255.255.252
ipv6 enable
ospfv3 1 ipv4 area 0.0.0.0
!
!
interface Ethernet0/2
no switchport
ip address 200.1.3.1 255.255.255.252
ipv6 enable
ospfv3 1 ipv4 area 0.0.0.0

R1
!
ipv6 unicast-routing
!
router ospfv3 1
 address-family ipv4 unicast
!
!
interface Ethernet0/1
 ip address 200.1.1.2 255.255.255.252
 ipv6 enable
 ospfv3 1 ipv4 area 0.0.0.0
!
!
interface Loopback0
 description LAN NETWORK
 ip address 192.168.1.1 255.255.255.0
 ipv6 enable
 ospfv3 1 ipv4 area 0.0.0.0

Also we have very similar configurations on R2 and R3. After a few seconds you should see a nice console prompt "%OSPFv3-5-ADJCHG: Process 1, IPv4, ..." letting us know that we have an OSPFv3 peer within the IPv4 address family. Important take way from this is that if you do enable IPv6 address families, while it will run with the same routing process it does require a second neighbor adjacency. Another important note on that is if you're running both IPv4 and IPv6 address families, you'll have separate OSPF data bases for each addr family.

So show commands! Let's see what we get, then we'll take a look some wireshark info.

R1#show ip ospf neighbor
R1##CRAP
R1#show ip route ospf
R1##Double Crap!!

Wait?! What the hell's going on here?! I can feel the tension building at home, put your pitch fork down. I didn't lie to you. 'show ip ospf' explicitly refers to OSPFv2... and we don't have any v2 neighbors. Same with 'show ip route ospf', we don't have any v2 routes. Let's try this again.

R1#show ospfv3 neighbor
          OSPFv3 1 address-family ipv4 (router-id 192.168.1.1)
Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
200.1.3.1         1   FULL/DR         00:00:39    17              Ethernet0/1
R1#show ip route ospfv3 | b ^Gateway
Gateway of last resort is not set
      200.1.2.0/30 is subnetted, 1 subnets
O        200.1.2.0 [110/20] via 200.1.1.1, 00:55:43, Ethernet0/1
      200.1.3.0/30 is subnetted, 1 subnets
O        200.1.3.0 [110/20] via 200.1.1.1, 00:55:43, Ethernet0/1

Like a promised, here's a quick wireshark off R1's Eth 0/1 interface, again important take away is that even though we're exchanging IPv4 prefixes, v3 send it's hellos and LS information with IPv6 addresses. If you go back to the configuration above, that's why "ipv6 enable" has to be enabled. Alternatively, you can also just assign IPv6 link local addresses manually... if you just like killing time.

Pop Quiz hot shot! FF02::5 is obviously an OSPF multicast address, but which one? Also what do you think the other OSPFv3 multicast address is? Answer here(select text after): FF02::5 is the ospfv3 all ospf routers group, like 224.0.0.5. FF02::6 is the ospfv3 DR group, again like 224.0.0.6.

The benefits of deploying OSPFv3 for your IPv4 networks are pretty sweet. The most obvious benefit, it lines you up perfectly for when you actually deploy IPv6 internally (in 1000 years). The next one, that I really like, you can start leveraging v3's security. That's right... IPsec. Lets take a look at that configuration real quick.

Now like ospfv2, authentication can be enabled per-link or globally for an entire area. I'll the area-wide method here, and cover the per-link in a future post/video (it's not vastly different).

SP-METRO
!
router ospfv3 1
 area 0.0.0.0 authentication ipsec spi 912 sha1 0123456789012345678901234567890123456789
 !
 address-family ipv4 unicast
!

 Notice on the area wide configuration you enable IPsec outside of any address-family. Again, making transitioning to IPv6 that much easier, you don't have to reconfigure security. So let's break this down. I think 'area 0.0.0.0 authentication' is pretty straight forward, so is the 'ipsec' portion of the command. Unless you didn't know OSPFv3 secured its routing with IPsec... then that might have been a surprise. The next part "spi" or Security Parameter Index, is a fairly arbitrary number between 256 and 4294967295. When enabling ospfv3 authentication per-interface the SPI has to be unique for each interface on the local router, and spi's have to match between neighbors. Area-wide, a single spi is just fine - since that's the only option for area wide authentication lol. After we specify an spi value we can choose to either use an md5 or sha1 hash. For SHA1 the hash value has to be 40 characters long, so for demonstration purposes I copied '0123456789' into notepad, copied and pasted three times. In the real world, obviously, you'll want something a bit more secure.


So there you have it! I'll have a video coming soon going into a bit more detail, but it's been a while since I posted anything and I thought this would be a good topic to start covering.