CCIE RS Lab – Week 3

12 hours of study time this week. A little light on the amount of time I’d like to spend studying, but not a set back.

This week was focused on a few different things, I practiced the different varients of configutring NAT.

I spent a lot of time on INE Foundations lab 3 –

The first time through I did not have an easy way to config the L2 part in virl, not all the commands were accepted. To practice, I wrote all the commands out into notepad, Today (Sunday) I scheduled rack time to test my config

I did run into an issue with virtual links not forming, could not find anything wrong. Had study friends help look as well, could not resolve. We were not able to recreate in different equipment – after watching Nick Russo’s Troubleshooting OSPF Live presentation he went over this exact scenario and I can clearly see what happened. Please check out his video, it’s very good

Troubleshooting OSPF – BRKRST-3310

Systems management – I need to practice this a lot more as there are so many options. This section will be included every day after working on some of the core content. This week I covered:  Logging, archive, logging with ACL

CCIE RS Lab – Week 2

Day late on this post, was going to try and keep these to Sunday as a brief highlight of what I studied for the week.

First, I created a time tracker, this is something I wish I did the first time around. I want to start getting data around how much did I study and also what subjects did I study. This way I can see what I need to come back to in the future for refreshers.

I’ve been doing pointed labs through INE and worked on MPLS, BGP, IPSEC, DMVPN and filled in some time with system management.

BGP was more to play with some filters and get used to the show commands and how they change when multi address families are used.

MPLS was a refresher on the command structure and checking the verifications. This was some lighter work for the basics of the P routers. I’ll be revisiting this to work on the CE-PE type routing and playing more with imports/exports within the VRF’s. I made a video for the config operations as it’s easy to setup but there are a lot of external config that relies on the underlaying config.

IPSEC was an eye opener on how much I forgot. I used to build these tunnels all the time in a past life. Once I remembered the order of configuration operations it came back to me fairly quickly. What I need to practice more of here is interupting the debug information.

DMVPN required me to go back into the documentation and find the config guide. I used this as practice to navigate the documentation, which I need to get better at doing. This was fun to play with how routing is handled and getting the difference for phase 1 2 and 3 back into my brain. I’ll most likely record a youtube video for this once my mic and tripod show up.

As fillers when I was to tired for a couple hours of labs or I had a spare 30 minutes I worked on some system management things like exec alias. I figure these are easy points on the actual lab and I need to intertwine these into my labbing sessions.


CCIE RS Lab – MPLS Configuration Config Order


  1. Configure IGP routing between routers
  2. Configure MPLS on PE and P routers
  3. Create VRF instances
  4. Assign RD and RT
  5. Apply VRF to interface(s)
  6. Re-apply IP address back to the interface
  7. Configure BGP peering between PE and P routers
    1. Disable the default of using ipv4 unicast address family
  8. Create vpnv4 address family
    1. Use iBGP rules for full mesh or RR
    2. Activate the neighbor
  9. On PE routers, create an additional address family for the VRF
  10. Redistribute the routes for the VRF into BGP
  11. Test connectivity

Note the changes in bgp show commands


I’m still getting used to making videos. Hard to tell where to look when holding the phone

CCIE RS Lab – Proxy ARP

Proxy ARP is one of those things that may make you think a route is working but will have a problem when you double check after it’s disabled. If you create a static route using an interface instead of an address, the router has to ARP out that interface for the neighboring address. If proxy arp is enabled on the recieving router is can “pretend” to know how to get to the destination.

How can this hurt you? If you test connectivity before disabling proxy arp you’ll have an entry in the arp table for the destination. After you disable proxy arp on the neighboring router, your originating router will still have that arp entry and you may think you still have connectivity until that arp entry times out (after 5 minutes).

How do you fix this? Static ARP entry on the router using a static route pointing out an interface for the destination you are trying to reach


Originating router:
ip route gi0/1.5 
arp 5555.5555.5555 arpa

Neighboring Router
int gi0/1
mac-address 5555.5555.5555

int gi0/1.5
no ip proxy-arp

int lo5
ip add

For good practice in the lab, statically configure the mac address on the interfaces just incase the router reloads since most of the time it’s in a virtualized environment now