CCIE RS Lab – Week 4

Hours studying – 27.5

I continued working on foundations 3. This shed light on how much I need to practice more IPv6. The redistribution was nasty, there are a bunch of loops created when doing this. I used tags for the redistribution, there were no restrictions on what tech could or could not be used.

I used debug ip routing to find out if these was any loops, also check routing table and used traceroute to verify conenctivty

I did run into an issue where a route on R7 should have been learned via EIGRP from it’s directly connected neighbor, but was being learned from R6 via OSPFv3. After tracking the problem down to R6 and seeing how the route was being learned I added an deny statement on one of my route maps which restored connectvity on R7 and for the rest of the network to learn routes properly via R7’s EIGRP neighbors.

I was looking for a way to listen to videos and have them autoplay the next video. I found a way to listen to videos in the background which has helped greatly while commuting. The app on the iPhone is called PlayerXtreme, it is able to see existing videos on the phone and play them while giving additional options for play next video and increase the playback speed.

Being able to listen to the videos has increased the amount of time I’ve been able to spend “studying”. I count listening as study time as I’ll absorb some knowledge.

I have also started reading through Narbiks book, Bridging the Gap between CCNP and CCIE. So far it has been helpful and steps through the technology is a very step by step way.

I started Foundations 2 and did not run into many things I didn’t remember. I have been taking my time on this one and will be continuing it Week 5.

I was able to spend 7.5 hours on Troubleshooting Lab 1 with 2 study partners. This was the most helpful study session I’ve had in a long time. I’ll do a youtube video soon around the need for a study partner(s). We were able to discuss strategy and teach each other things we may have forgotten. This lab exposed a lot of weaknesses that I need to brush up on: OSPF LFA, BGP Table Map, Multicast MSDP, EEM tricks, BGP additional paths.

CCIE RS Lab Studying – week 1

This marks the first week of getting back into studying for the lab. I started this by getting my server running and software update. I’ve made a simple schedule, which I am already modifying and reached out to a mentor to help bounce ideas off of. On top of that I’ve got the videos loaded on my phone and iPad and added some more books to reach through safari.

For those interested. I using INE that I purchased back in the day and will continue using their material. I am also looking into Cisco360 based off feedback I’ve heard from others.

I didn’t make as much progress as I was hoping, but I’ve made a start.

So far I’ve tackled some of the L2 things just to get used to typing quickly and also going through the verifications. I’m also diving into OSPF and playing with the different network types and reading through the database.

CCIE RS – Tunneling – MPLS

Implement and Troubleshoot MPLS Operations

Multi-Protocol Label Switching

Requires CEF to be enabled on all devices running MPLS

  • Mpls ip
  • Mpls label-distribution [ldp, tdp, both]

Packet forwarding based on labels to make forwarding decisions

  • Label is 4 bytes, fixed length
    • Label – 20bits
    • Exp – 3 bits, COS
    • S – Bottom Stack, 1 bit
    • TTL – 8 bits
  • Locally significant ID
  • Forwarding Equivalence Class (FEC)
    • Group of IP packets which are forwarded in the same manner
  • Label is imposed between layer 2 (data link) header and layer 3 (network) header

Tag Distribution Protocol (TDP)

  • Cisco proprietary

Label Stack, LSR, LSP

LSR – Label Switch Router

  • Any router or switch that implements label distribution
  • Forward packets based on labels
  • Edge-LSR
    • Performs label imposition (push)
      • Prepending a label or stack of labels to a packet in the ingress point of the MPLS domain
    • Performs label disposition (pop)
      • Removing last label from a packet at the egress point before sending to neighbor outside the MPLS domain
  • Maintains a LIB table (Label Information Base)
    • Holds label mappings assigned by the LSR and mappings of these labels to labels received by neighbors
  • LFIB – Label Forwarding Information Base
    • MPLS forwarding tabel
    • Built from the LIB

LSP – Label Switched Path

  • Packets entering and exiting an MPLS network
  • Describes the set of LSR’s a labeled packet must traverse to reach the egress-LSR for a particular FEC
  • Unidirectional
  • Connection oriented scheme
    • Setup prior to any traffic flow
    • Based on topology information

FEC – Forwarding Equivalence Class

  • Grouping IP packets that are forwarded in the same manner over the same path with the same forwarding treatment
  • Might correspond to a destination IP subnet
  • After LIB is built – Labels get assigned to every FEC known by the router

Penultimate Hop Popping (PHP)

Label Stack

  • Inserted between L2 header and L3 contents of L2 frame
  • Shim header
  • 20 bits label
  • 3 bit COS / Experimental bit
  • 8 bit TTL
  • 1 bit bottom-of-stack
    • Combines 2 or more label headers attached to a single packet
  • Frame mode MPLS Actions
    • Pop – Remote top label
    • Swap – Replace top label with another value
    • Push – Replace top label with a set of labels
    • Aggregate – Remove top label and does L3 lookup of underlying IP packet
    • Untag – Remote top label and forward the underlying IP packet to next hop



Label Distribution Protocol

IETF Standard

Enables LSR to inform other LSR’s about label bindings that have been made.

Dynamically assign labels on a hop by hop basis

MPLS Ping, MPLS Traceroute


Implement and Troubleshoot Basic MPLS L3VPN


CE – Customer Equipment

  • Located on customer site
  • Exchanges routes with PE device

PE – Provider Edge

  • Exchanged routes with CE and other PE devices
  • Connect to both CE and P devices
  • Is part of the MPLS domain
  • Exchanges labels

P – Provider

  • Inside the MPLS cloud
  • Exchanges labels with P and PE devices
  • Does not need to know about CE routes


Extranet (route leaking)

Routes can be leaked between different VRF’s (customers) by using different route target import and exports.

Service providers can utilize this to help provide Internet or some other shared service connectivity from within their MPLS cloud

ip vrf VRF
rd 10:10
route-target export 100:100
route-target import 200:200
router-target import 100:100

CCIE RS – L3 Tech – EIGRP for IPv4 and IPv6

EIGRP for IPv4 and IPv6


  • Utilizes 50% of the bandwidth
  • DUAL algorithm for shortest path the destination
  • Distance vector protocol
  • Protocol 88
  • Builds a topology table for each of its neighbor advertisements
    • Converges looking for a loop-free router in the topology table
    • Doesn’t know other route and queries its neighbors


Neighbor discovery and maintenance

  • Only sends updates about paths that have changed when the paths change
  • Hellos sent every 5 seconds on high bandwidth links and 60 seconds on low bandwidth multipoint links
    • Hold time is 3x the hello by default
      • 15 seconds and 180 seconds
    • Commands – Per Interface
      • ip hello-interval eigrp
      • Ip hold-time eigrp
  • Neighbors are not built over secondary addresses


  • Bandwidth and delay are the default metrics used to determine the value to the destination
  • K1=1, K2=0, K3=1, K4=0, K5=0
  • Metric = bandwidth + delay


Describe Packet Types

Packet types (hello, query, update, and such)


  • Used by neighbor discovery and recovery
  • Multicast
  • Unreliable delivery


  • ACKs
  • Hello packet with no data
  • Always sent unicast
  • Unreliable delivery
  • If not received after 16 transmissions the neighbor is considered dead
  • RTO – Retransmission Timeout
  • RTO is calculated from the SRTT – Smooth Round Trip Time


  • Convey route information
  • Sent only when necessary
  • Contain only necessary information
  • When requested by single router, sent unicast
  • When requested by multiple routers, send multicast
  • Always reliable delivery

Queries and Replies

  • Used by DUAL
  • Queries can be multicast or unicast
  • Replies are unicast
  • Use reliable delivery

Route types (internal, external)


  • Routes originated within the AS
  • AD of 90


  • Routes that are summarized in the router
  • AD of 5


  • Routers that are redistributed into EIGRP
  • AD of 170


Implement and troubleshoot neighbor relationship

Neighbor table

Multicast, unicast EIGRP peering


  • Default neighbor discovery
  • — 0100:5e00:000a


  • Use neighbor command

OTP point‐to‐point peering

Point-to-Point Peering: Point-to-point offers the simplest form of configuration within OTP, and allows OTP to form a peer with a targeted router. This option is controlled by the additional “remote” keyword on the neighbor statement. Once the configuration has been entered, EIGRP will begin sending Hello messages to the address specified. When a Hello message is likewise received from the proper address, routes will then be exchanged.

OTP route‐reflector peering

Route Reflector Peering: If the network has many sites, then OTP offers Route Reflectors (RRs) to form a half-mesh topology and ensure connectivity among all sites in the network. A Route Reflector is an EIGRP peer that receives route updates from remote sites and “reflects” the routes to other sites. Route Reflectors are configured using the keyword “unicast-listen”. This option enables the Route Reflectors to listen for unicast Hello messages from other sites, and upon receiving the first Hello message, automatically forms a peering relationship. OTP supports the use of dual or multiple Route Reflectors for redundancy.

OTP multiple service providers scenario

Site Redundancy: The add path support feature enables hubs to advertise multiple best paths to connected sites. A typical OTP deployment would consists of dual hubs (for hub redundancy) connected to more than one service provider (for service-provider redundancy) and provides up to four additional paths to connected sites. This option is configured using the “add-paths” configuration under EIGRP. If, for example there are two spokes (spoke-1 and spoke-2) at a site, and add-path is configured on the hub, both spoke-1 and spoke-2 will be advertised to other sites, thereby allowing for both redundancy (in the event of lost of connectivity to one of the spokes) and load balancing traffic to spoke-1 and spoke-2

Implement and troubleshoot loop free path selection

Feasible Distance

  • Best metric along a path to a destination
  • Includes metric to the neighbor advertising the path
  • Lowest calcaulated metric to each destination

Reported Distance

  • Total metric along a path to a destination network as advertised by an upstream neighbor

Feasible Successor

  • Path whose reported distance is less than the feasible distance (current best path)
  • Reduces number of diffusing computations that need to be run

Feasibility Condition

  • Condition that is met if a neighbors advertised distance to a destination is lower tha the routers FD to that same destination
  • If met, a neighbors advertised distance to a destination is lower than the routers FD to the same desintation
    • neighbors advertised distance to a destination meets the FC that neighbor becomes the feasible successor for that destination


  • Router that is one hop closer to a destination
  • Route that is installed into the routing table from the topology table

Classic Metric

  • Supports 32bit metric calculation
  • EIGRP composite cost metric = 256*((K1*Scaled Bw) + (K2*Scaled Bw)/(256 – Load) + (K3*Scaled Delay)*(K5/(Reliability + K4)))
  • Bandwidth and Delay are used by default (K1 and K3)
  • Not scaled for the higher bandwidths in the field today
  • Lowest configurable delay – 10 microseconds

Wide Metric

  • Supports 64bit metric calculations
  • Allows for bandwidths up top 4.2 terabits
  • Cost metric formula was modified
    • Metric = [(K1*Minimum Throughput + {K2*Minimum Throughput} / 256-Load) + (K3*Total Latency) + (K6*Extended Attributes)]* [K5/(K4 + Reliability)]
  • Introduction of a K6 value
  • By default this calculation is used – Composite Cost Metric = (K1*Minimum Throughput) + (K3*Total Latency)

Implement and Troubleshoot Operations

General Operations

  • Protocol-Dependent Modules

    • Has modules for IP, IPX and AppleTalk for specific routing tasks
    • Uses information to pass to DUAL
  • Reliable Transport Protocol (RTP)

    • Manages delivery and reception of EIGRP packets
    • Delivery is guaranteed and packets will arrive in order
    • Cisco propreitary algorithm – Reliable Multicast
    • Sends packets on protocol 88
    • Packet Types
      • Hello – used for neighbor discovery and recovery. Multicast and use unreliable delivery (no ack required)
      • Ack – Hello packets with no data. Unicast and use unreliable delivery
        • If not recieved after 16 unicast retransmits, the neighbor is declared dead
        • Retransmission Timeout (RTO) – Time between unicast messages
          • Calculated from Smooth Round trip Time (SRTT). Average elapsed time (ms) between transmission of a packet to neighbor and receipt of acknowledgement
      • Updates – Convey route information, transmitted only when necessary. Always reliable delivery
      • Queries and Replies – Used by DUAL finite state machine to manage diffusing computation. Queries can be multicast or unicast. Replies are always unicast. Both use reliable delivery
      • RequestsNot in use. Packets intended for use in route servers
  • Neighbor Discovery / Recovery

    • Hellos are multicasted every 5 seconds
      • Slower links – unicast every 60 seconds
      • ip hello-interval eigrp
    • Packet includes hold time – max time to wait between hellos.
      • If holddown timer expires the neighbor is delcared unreachable and DUAL informs neighbors
      • Default hold time – 3 times the hello, 15 seconds
        • 180 on slow links
      • ip hold-time eigrp
    • Information from each neighbor is stored in the neighbor table
  • Diffusing Update Algorithm

    • DUAL – replaced Bellmand-Ford algorithm
    • Operations
      • Node detects within finite time the existance of a few neighbors or loss of connectivity with a neighbor
      • All messages transmitted over an operational link are recieved correctly and in proper sequence within finite time
      • All messages, changes in link cost, link failures and new neighbor noticiations are porcessed one at a time within finite time and in order they were detected
      • EIGRP used neighbor discovery for these operations
    • Adjacency – Logical associatation between 2 neighbors over which route information is exchanged.
      • Update contains all routes known by the sending router and the metrics for the routes
      • Each router will calculate a distance based on the distances advertised by the neighbor and the cost of the link to that neighbor
    • Feasible Distance – Lowest calculated metric to each destination
    • Feasibility Condition – If met, a neighbors advertised distance to a destination is lower than the routers FD to the same desintation
      • neighbors advertised distance to a destination meets the FC that neighbor becomes the feasible successor for that destination
    • Concept of FS and FC are central to loop avoidance. FS is always downstream
      • Router would never choose a path that will lead back to itself, that path out have a distance larger than the FD
    • Every destination for 1 or more FS’s will be recorded in a topology table
      • Destinations FD
      • All Feasible successors
      • Each FS advertised distance to a destination
      • Locally calculated distance to destination
      • Interface connected to the network where FS is found
    • Lowest metric is choosen, that route becomes the successor, next-hop router
  • DUAL Finite State Machine

    • Routes should be in a passive state – diffusing computations are not being performed
    • Router will reaccess the list of FS if an input event occurs
      • Change in cost for directly connected link
      • Change is state (up/down) for directly connected link
      • Reception of an update packet
      • Reception of a query packet
      • Reception of a reply packet
    • Local recomputation is performed first
      • If FS with the lowest distance is different from existing sucesssor the FS will become successor
      • If new distance is lower than the FD, the FD will be updated
      • If the new distance is different from existing, update will be sent to all neighbors

Topology Table

  • Topology table is used for which routes get installed into the routing table
  • Shared between neighbors
  • Table includes
    • Lowest bandwidth on the path to destinationupdate
    • total delay
    • path reliability
    • path loading
    • minimum path maximum transmission unit (MTU)
    • feasible distance
    • reported distance
    • route source (external routes are marked)
  • Show ip eigrp topology

Update Query

  • Used to get updated information from a neighboring router
  • debug eigrp packet update query reply

Active, Passive

  • Passive
    • Stable route in EIGRP, no diffusing computation being run
  • Active
    • If no feasible successor can be found in topology table, route changes to active while router runs diffusing computation
    • Route cannot be changed back to passive until:
      • Change the routes successor
      • Change the distance it advertising for the route
      • Change the routes FD
      • Begin another diffusing computation for the route
    • Active timer – 3 minutes
      • If no replies after active timer exprires the route is declared Stuck In Active
      • timers active-time

Stuck in Active (SIA)

  • When a query takes to long to be answered
  • Router that issued the query clears its connection with the router, restarting the neighbor session
  • Avoid with using summary and stub

Graceful Shutdown


Implement and Troubleshoot EIGRP Stub


Stub routing helps improve the stability of the EIGRP network. It can also help reduce resource utilization and simplifies stub device configuration.

Commonly used in hub and spoke networks at the spoke end

Any neighbor that recieved a packet informing it of the stub status will not query the stub router for any routes. This helps reduce the query domain and help prevent routes from going SIA.

Stubs will only advertise specified routes. Stub devices respond to all queries for summaries, connected routers, redistributed static routes, external routes and internal routes with inaccessible.

router eigrp [as]
network [ip] [wildcard]
eigrp stub [receive-only | leak-map | connected | static | summary | redistributed]
router eigrp [name]
address-family ipv4 [as]
 network [ip] [wildcard] 
 eigrp stub [options]
address-family ipv6 [as]
 network [ip] [wildcard]
 eigrp stub [options]


Leak-maps allow the ability to advertise a more specific route that would have been suppressed by summarization.

Implement and Troubleshoot Load-Balancing


EIGRP will load balance 4 equal cost paths into the routing table by default, which are then load balanced.

Using max-paths allows for up to 6 routes to be load balanced


EIGRP allows for unequal cost load balancing using the variance command. Variance is a multiplier


By default all interfaces are configured with next-hop-self for EIGRP. This default may interfere with the add-path feature. Used with DMVPN networks (hub). Add Path allows for the hub to advetise up to 4 additional best paths connected to spokes

Implement EIGRP (multi-address) named Mode

Named mode allows for everything about EIGRP to be configured under a single place inside EIGRP configuration mode.

With this named mode, only a single instance of EIGRP needs to be created. It can be used for all address family types. It also supports multiple VRFs limited only by available system resources. One thing to be aware of in regards to the named mode is that configuration of the address-family does not enable IPv4 routing as a traditional configuration of IPv4 EIGRP.

Covert config: eigrp upgrade-cli [eigrp name]

Types of families

5 types of families, IPv4 unicast, IPv4 multicast, IPv4 VRF, IPv6 unicast, IPv6 VRF

R1(config-router)#address-family ipv4 ?
 autonomous-system Specify Address-Family Autonomous System Number
 multicast Address Family Multicast
 unicast Address Family Unicast
 vrf Specify a specific virtual routing/forwarding instance

R1(config-router)#address-family ipv6 ?
 autonomous-system Specify Address-Family Autonomous System Number
 unicast Address Family Unicast
 vrf Specify a specific virtual routing/forwarding instance

IPv4 address-family

This address family can be unicast, multicast and set for global routing table or for a VRF.

This is for all EIGRP IPv4 routing

IPv6 address-family

This address family can be unicast and set for global routing table or for a VRF.

This is for all EIGRP IPv6 routing

Implement, troubleshoot and optmized EIGRP convergence and Scalability

Describe fast convergence requirements

Requires a feasible successor for a backup path to be added if the successor path fails. Summarization and stubs can also help by reducing the query boundary.

Control query boundary

Can be controlled using stub routers or summarization

IP FRR / Fast Reroute (single hop)

Fast Reroute (FRR) is the mechanism that enables traffic that traverses a failed link to be rerouted around the failure. In EIGRP networks, precomputed backup routes or repair paths are known as feasible successors or loop-free alternates (LFAs)

IPv6 is not supported yet

router eigrp [name]
address-family ipv4 unicast [as]
 topology base
 fast-reroute per-prefix [all | route-map]

Summary leak-map

Allows for more specific routes to be advertised that normally would be suppressed by the summary route

Summary metric

By default, summary routes use the lowest metric amoung the existing routes. If this metric changes, the summary route will also be updated.

The summary metric can be manually configured under the EIGRP process

R2(config)#router eigrp 1
R2(config-router)#summary-metric 10000 200 255 0 1500


CCIE RS – Routing Concepts – Implement, optimize and troubleshoot policy‐based routing

Implement, Optimize and Troubleshoot Policy-Based Routing

Policy based routing is being able to manipulate the path of traffic from what is being directed from the RIB.

Typically this is implemented using route maps and match a source of traffic and changing the destination path.

All packets received on an interface with PBR enabled are passed through enhanced packet filters known as route maps. The route maps used by PBR dictate the policy, determining to where the packets are forwarded.

  • Route maps are composed of statements. The route map statements can be marked as permit or deny, and they are interpreted in the following ways
  • If the packets do not match any route map statements, then all the set clauses are applied.
  • If a statement is marked as deny, the packets meeting the match criteria are sent back through the normal forwarding channels and destination-based routing is performed.
  • If the statement is marked as permit and the packets do not match any route map statements, the packets are sent back through the normal forwarding channels and destination-based routing is performed.

For traffic originated outside of the router

interface GigabitEthernet0/1
 ip policy route-map PBR

route-map PBR permit 10
 match ip address prefix-list LOOPBACK
 set ip next-hop

For traffic originated from the router

ip local policy route-map LOCAL_PBR

Identify and troubleshoot sub-optimal routing

Sub-optimal routing can occur when using PBR as it may be asymetric due to not capturing traffic in both directions. Asymetric routing is when traffic goes out one interface and is recieved back on a different interface. This may not cause a problem in normal cases, but if a firewall which requires state information, this will cause traffic to be dropped.

You can identify this by checking the routing table, cef table and using traceroute to follow the traffic path.

CCIE RS – Routing Concepts – Implement, Optimize and Troubleshoot Manual and Auto Summarization with any Routing Protocol

Implement, Optimize and Troubleshoot Manual and Auto Summarization with any Routing Protocol

Auto Summarization is when a a prefix is automatically summarized at a network boundary to it’s classful prefix. Example, a router changes the prefix to


By default RIP will automatically summarize subnet routes into network level routes

router rip
version 2
[no] auto-summary
network x.x.x.x

Manual summarization can be done at an interface level. The summary entry will be entered into the RIP database

R1(config-if)#ip summary-address rip
R1#sh int lo0
Loopback0 is up, line protocol is up 
 Hardware is Loopback
 Internet address is

R3#sh ip route is variably subnetted, 2 subnets, 2 masks
R [120/2] via, 00:00:05, GigabitEthernet0/1
R [120/2] via, 00:00:12, GigabitEthernet0/1 is subnetted, 1 subnets
R [120/1] via, 00:00:12, GigabitEthernet0/1 is subnetted, 1 subnets
C is directly connected, Loopback0 is variably subnetted, 3 subnets, 2 masks
R [120/1] via, 00:00:12, GigabitEthernet0/1
C is directly connected, GigabitEthernet0/1
L is directly connected, GigabitEthernet0/1


Auto summary is enabled in EIGRP by default.

Summary routers are given an administrative distance of 5

Manual summarization can be performed at any point in the network

R1(config-if)#ip summary-address eigrp 1 

R3(config-router)#do sh ip route

D* [90/3328] via, 00:00:08, GigabitEthernet0/1


OSPF does not have an auto summaization feature and can only perform summarization at specific points in the network. OSPF requires at an area has a the same database on each router in that area which means summarization can only be done at area borders.

There are 2 types of summarization

Area range – ABR, summarize internal routes as they get passed to another area as a type 3 interarea LSA

Summary address – ASBR, summarize external routes before injecting them into the OSPF domain at type 5 external LSA’s


BGP has multiple different ways to summarize routes

network w/ static route


R1(config-router)#do sh run | s bgp
router bgp 1
 bgp log-neighbor-changes
 network mask
 neighbor remote-as 2

R2(config-router)#do sh ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 a - application route
 + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set is variably subnetted, 2 subnets, 2 masks
B [20/0] via, 00:00:03
B [20/0] via, 00:00:03