CCIE Training

I enjoyed Petr’s article regarding explicit next hop.  It reminded me of a scenario where a redistributed route, going into OSPF conditionally worked, depending on which reachable next hop was used.

Here is the topology for the scenario:

Here is the relevant (and working ) information for R1.

When we replace the static route, with a new reachable next hop, we loose the ability to ping 100.100.100.3

When we change the next hop for the static route, (which is being redistributed into OSPF), the route to 100.100.100.0/24 no longer works, even though we have verified ability to ping the new next hop.

Can you solve this puzzle?  Please post your ideas!

For more troubleshooting scenarios, please see our CCIE Route-Switch workbooks, volume 2, for more than 100 challenging troubleshooting scenarios.

We will post the results right here, in a few days, after you have had a chance to post your comments and ideas.

Best wishes,

Keith

Are you a CCNP or CCIE student looking to challenge your perfect knowledge of Catalyst switchport commands?

Take the latest SWITCH Command Recall exam by clicking the link below. Good luck – and let us know how you scored in the comments area of this post.

Remember to read, AND TYPE, very carefully! I failed my first attempt due to just plain sloppiness.

SWITCH Command Recall Exam – L2/L3 Ports

One of the frequent questions I hear regarding L3VPNs, is regarding the bottom VPN label.  In this article, we will focus on the control plane that provides both the VPN and transit labels, and then look at the data plane that results because of those labels.

In the topology, there are 2 customer sites (bottom right, and bottom left).  The BGP, VRFs, Redistribution, etc are all configured to allow us to focus on the control and data plane.   Lets begin by verifying that R1 is sourcing the network, 1.1.1.1/32.

A debug verifies that R1 is sending the updates for 1.1.1.1 to R2.

R2 has learned the route from R1, has assigned a VPN label for it, and has exported it from the VRF into BGP.  This lucky route was assigned the local label of 16 by R2.

We can also look at the MPLS forwarding table on R2 to see the same tag information.

This prefix, as a VPNV4 route, is sent as an update to the iBGP peer R4.   We can force an update with refresh.

The update can be seen on the wire between R2 and R3, (on its way to R4) using a protocol analyzer.  You may also notice that R2 uses outgoing label 19 for forwarding this update to 4.4.4.4   The label can be seen in the MPLS forwarding output above.

The VPN label being advertised in the update is Label 16, which is R2’s local label for the 1.1.1.1 network.

On R4, which will be the ingress PE for transit traffic destined for 1.1.1.1, we can see that the VPN label of 16 is associated with destination network of 1.1.1.1  The next hop of 2.2.2.2 to reach the 1.1.1.1 network, is due to R2 assigning next-hop-self for updates it sends to R4.

We can also see the outgoing MPLS label that R4 will use to reach the next hop of 2.2.2.2.  The label of 18 below, was advertised by R3, as the label to use to reach 2.2.2.2

We can also verify that the route (1.1.1.1) has been imported by R4 into the customer vrf.

So when a transit packet is sent from R5 to 1.1.1.1, R4 should impose 2 labels.   The bottom label will be 16 (the VPN label) for the 1.1.1.1 network (R2 told us about that via the iBGP update), and the top label should be 18 (advertised via LDP from R3), to reach the next hop of 2.2.2.2

On R4 a quick check of the CEF table for the vrf can verify both labels.

A simple trace from R5, to the destination network of 1.1.1.1 should prove all the labels in the path.

The top label of 18 is used to reach the next hop of 2.2.2.2, and the bottom label of 16, which is meaningful to R2, because he sourced it, will be used by R2 in forwarding the transit traffic destined to 1.1.1.1 to the next hop, which is R1.

R3 will pop the transit label off, due to R2 advertising implicit-null for the network 2.2.2.2 (itself).

For more information and step by step training on MPLS, take a look at our newest MPLS self paced course!

If you like, an 8 minute video, that reviews the same steps, may be viewed here.

Thanks for reading!

Keith Barker

In this blog post we’re going to discuss the fundamental logic of how MPLS tunnels allow applications such as L2VPN & L3VPN to work, and how MPLS tunnels enable Service Providers to run what is known as the “BGP Free Core”. In a nutshell, MPLS tunnels allow traffic to transit over devices that have no knowledge of the traffic’s final destination, similar to how GRE tunnels and site-to-site IPsec VPN tunnels work. To accomplish this, MPLS tunnels use a combination of IGP learned information, BGP learned information, and MPLS labels.

In normal IP transit networks, each device in the topology makes a routing decision on a hop-by-hop basis by comparing the destination IP address of the packet to the routing or forwarding table. In MPLS networks, devices make their decision based on the MPLS label contained in the packet that is received. In this manner, MPLS enabled Label Switch Routers (LSRs for short) do not necessarily need IP routing information about all destinations, as long as they know how to forward traffic based on an MPLS label. To demonstrate how this process works, we’ll examine the above topology in two sample cases, first with normal IP packet forwarding, and secondly with IP packet forwarding plus MPLS.

In this topology R4, R5, and R6 represent the Service Provider network, while SW1 and SW2 represent customers that are using the Service Provider for transit. In each example case, the goal of our scenario will be to provide IP packet transport between the 10.1.7.0/24 network attached to SW1, and the 10.1.8.0/24 network attached to SW2.

Case 1: Normal IP Forwarding

In case 1, the devices in the topology are configured as follows. AS 100, which consists of R4, R5, and R6, runs OSPF as an IGP on all internal interfaces, along with a full mesh of iBGP. AS 7, which consists of SW1, and AS 8, which consists of SW2, peer EBGP with AS 100 via R4 and R6 respectively, and advertise the prefixes 10.1.7.0/24 & 10.1.8.0/24 respectively into BGP. The relevant device configurations are as follows. Note that these configs assume that layer 2 connectivity has already been established between the devices.

R4#
interface Loopback0
 ip address 10.1.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 10.1.47.4 255.255.255.0
!
interface FastEthernet0/1
 ip address 10.1.45.4 255.255.255.0
 ip ospf 1 area 0
!
router bgp 100
 neighbor 10.1.6.6 remote-as 100
 neighbor 10.1.6.6 update-source Loopback0
 neighbor 10.1.6.6 next-hop-self
 neighbor 10.1.45.5 remote-as 100
 neighbor 10.1.45.5 next-hop-self
 neighbor 10.1.47.7 remote-as 7

R5#
interface FastEthernet0/0
 ip address 10.1.45.5 255.255.255.0
 ip ospf 1 area 0
!
interface FastEthernet0/1
 ip address 10.1.56.5 255.255.255.0
 ip ospf 1 area 0
!
router bgp 100
 neighbor 10.1.45.4 remote-as 100
 neighbor 10.1.56.6 remote-as 100

R6#
interface Loopback0
 ip address 10.1.6.6 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 10.1.56.6 255.255.255.0
 ip ospf 1 area 0
!
interface FastEthernet0/1
 ip address 10.1.68.6 255.255.255.0
!
router bgp 100
 neighbor 10.1.4.4 remote-as 100
 neighbor 10.1.4.4 update-source Loopback0
 neighbor 10.1.4.4 next-hop-self
 neighbor 10.1.56.5 remote-as 100
 neighbor 10.1.56.5 next-hop-self
 neighbor 10.1.68.8 remote-as 8

SW1#
interface Loopback0
 ip address 10.1.7.7 255.255.255.0
!
interface Vlan47
 ip address 10.1.47.7 255.255.255.0
!
router bgp 7
 network 10.1.7.0 mask 255.255.255.0
 neighbor 10.1.47.4 remote-as 100

SW2#
interface Loopback0
 ip address 10.1.8.8 255.255.255.0
!
interface Vlan68
 ip address 10.1.68.8 255.255.255.0
!
router bgp 8
 network 10.1.8.0 mask 255.255.255.0
 neighbor 10.1.68.6 remote-as 100

Next, let’s examine the hop-by-hop packet flow as traffic moves between the 10.1.7.0/24 and 10.1.8.0/24 networks, starting at SW1 towards SW2, and then back in the reverse direction. Note that verification should be done in both directions, as packet flow from the source to destination is independent of packet flow from the destination back to the source.

SW1#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "bgp 7", distance 20, metric 0
  Tag 100, type external
  Last update from 10.1.47.4 00:21:13 ago
  Routing Descriptor Blocks:
  * 10.1.47.4, from 10.1.47.4, 00:21:13 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 100

On SW1, the prefix 10.1.8.0 is learned via BGP from R4, with a next-hop of 10.1.47.4. Next, SW1 performs a second recursive lookup on the next-hop to see which interface must be used for packet forwarding.

SW1#show ip route 10.1.47.4
Routing entry for 10.1.47.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Vlan47
      Route metric is 0, traffic share count is 1

The result of this lookup is that SW1 should use interface Vlan47, which connects towards R4. Assuming that underlying IP address to MAC address resolution is successful, packets going to 10.1.8.0 should be properly routed towards R4. Next, the lookup process continues on R4.

R4#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "bgp 100", distance 200, metric 0
  Tag 8, type internal
  Last update from 10.1.6.6 00:25:19 ago
  Routing Descriptor Blocks:
  * 10.1.6.6, from 10.1.6.6, 00:25:19 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 8

R4 is learning the prefix 10.1.8.0 via iBGP from R6, with a next-hop value of 10.1.6.6, R6’s Loopback0 interface. R4 must now perform an additional recursive lookup to figure out what interface 10.1.6.6 is reachable out.

R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 10.1.45.5 on FastEthernet0/1, 00:25:26 ago
  Routing Descriptor Blocks:
  * 10.1.45.5, from 10.1.6.6, 00:25:26 ago, via FastEthernet0/1
      Route metric is 3, traffic share count is 1

R4 knows 10.1.6.6 via OSPF from R5, which uses interface FastEthernet0/1. Assuming layer 2 connectivity is working properly, packets towards 10.1.8.0 are now routed to R5, and the lookup process continues.

R5#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "bgp 100", distance 200, metric 0
  Tag 8, type internal
  Last update from 10.1.56.6 00:24:36 ago
  Routing Descriptor Blocks:
  * 10.1.56.6, from 10.1.56.6, 00:24:36 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 8

R5 is learning the prefix 10.1.8.0 via iBGP from R6, with a next-hop of 10.1.56.6. A recursive lookup on the next-hop, as seen below, indicates that R5 should use interface FastEthernet0/1 to forward packets towards 10.1.8.0.

R5#show ip route 10.1.56.6
Routing entry for 10.1.56.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/1
      Route metric is 0, traffic share count is 1

The lookup process now continues on R6, as seen below.

R6#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "bgp 100", distance 20, metric 0
  Tag 8, type external
  Last update from 10.1.68.8 00:28:58 ago
  Routing Descriptor Blocks:
  * 10.1.68.8, from 10.1.68.8, 00:28:58 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 8

R6 is learning the prefix 10.1.8.0 via EBGP from SW2, with a next-hop of 10.1.68.8.

R6#show ip route 10.1.68.8
Routing entry for 10.1.68.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/1
      Route metric is 0, traffic share count is 1

A recursive lookup on 10.1.68.8 from R6 dictates that interface FastEthernet0/1 should be used to forward traffic on to SW2.

SW2#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Advertised by bgp 8
  Routing Descriptor Blocks:
  * directly connected, via Loopback0
      Route metric is 0, traffic share count is 1

SW2’s lookup for 10.1.8.0 indicates that the destination is directly connected, and packets are routed to the final destination. For return traffic back to 10.1.7.0, a lookup occurs in the reverse direction similar to what we saw above, starting as SW2, and moving to R6, R5, R4, and then finally SW1.

This example shows how the hop-by-hop routing paradigm works in IPv4 networks. While this type of design works, one of the limitations of IPv4 forwarding is that all devices in the transit path must have routing information for all destinations they are forwarding packets towards. If AS 100 was used for Internet transit in this example, each router in the transit path would need 300,000+ routes in their routing tables in order to provide transit to all Internet destinations. This is just one of the many applications for which MPLS can be helpful. By introducing MPLS into this design, the need for large routing tables can be avoided in the core of the Service Provider network.

Case 2: MPLS Forwarding

By enabling MPLS in the Service Provider network of AS 100, BGP can be disabled in the core, lightening the load on devices that are possibly already taxed for resources. The configuration for MPLS in this scenario is very simple, but the understanding of what happens behind the scenes can be intimidating when learning the technology for the first time. To help with this learning curve, we’ll look at the step by step process that occurs when an MPLS tunnel is functional in AS 100.

The configuration changes necessary to implement MPLS in AS 100 are as follows:

R4#
mpls label protocol ldp
!
interface FastEthernet0/1
 mpls ip
!
router bgp 100
 no neighbor 10.1.45.5 remote-as 100

R5#
mpls label protocol ldp
!
interface FastEthernet0/0
 mpls ip
!
interface FastEthernet0/1
 mpls ip
!
no router bgp 100

R6#
mpls label protocol ldp
!
interface FastEthernet0/0
 mpls ip
!
router bgp 100
 no neighbor 10.1.56.5 remote-as 100

Once MPLS is enabled inside AS 100, BGP can be disabled on R5, and the additional BGP peering statements removed on R4 and R6. The end result of this change is surprising for some, as seen below.

R5#show ip route 10.1.7.0
% Subnet not in table
R5#show ip route 10.1.8.0
% Subnet not in table

SW1#ping 10.1.8.8 source 10.1.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.1.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

Although R5 no longer has a route to the prefixes 10.1.7.0/24 or 10.1.8.0/24, it can still provide transit for traffic between them. How is this possible you may ask? The key is that an MPLS tunnel has now been formed between the ingress and egress routers of the Service Provider network, which are R4 and R6 in this case.  To see the operation of the MPLS tunnel, we’ll follow the same lookup process as before, but now R4, R5, and R6 will add an additional MPLS label lookup.

Below SW1 looks up the route for 10.1.8.0/24, and finds that it recurses to R4’s next-hop value reachable via the Vlan47 interface.

SW1#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
 Known via "bgp 7", distance 20, metric 0
 Tag 100, type external
 Last update from 10.1.47.4 01:02:56 ago
 Routing Descriptor Blocks:
 * 10.1.47.4, from 10.1.47.4, 01:02:56 ago
 Route metric is 0, traffic share count is 1
 AS Hops 2
 Route tag 100

SW1#show ip route 10.1.47.4
Routing entry for 10.1.47.0/24
 Known via "connected", distance 0, metric 0 (connected, via interface)
 Routing Descriptor Blocks:
 * directly connected, via Vlan47
 Route metric is 0, traffic share count is 1

Next, R4 receives packets for this destination and performs its own lookup.

R4#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
 Known via "bgp 100", distance 200, metric 0
 Tag 8, type internal
 Last update from 10.1.6.6 01:05:15 ago
 Routing Descriptor Blocks:
 * 10.1.6.6, from 10.1.6.6, 01:05:15 ago
 Route metric is 0, traffic share count is 1
 AS Hops 1
 Route tag 8

Like before, R4 finds the route via BGP from R6, with a next-hop of 10.1.6.6.  R4 must now perform a recursive lookup on 10.1.6.6 to find the outgoing interface to reach R6.

R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
 Known via "ospf 1", distance 110, metric 3, type intra area
 Last update from 10.1.45.5 on FastEthernet0/1, 01:06:22 ago
 Routing Descriptor Blocks:
 * 10.1.45.5, from 10.1.6.6, 01:06:22 ago, via FastEthernet0/1
 Route metric is 3, traffic share count is 1

R4’s recursive lookup finds the outgoing interface FastEthernet0/1 with a next-hop of 10.1.45.5.  In normal IP forwarding, the packet would now be sent to the interface driver for layer 2 encapsulation.  However in this case, R4 first checks to see if the interface FastEthernet0/1 is MPLS enabled, as seen below.

R4#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/1        Yes (ldp)     No       No  No     Yes

Since interface FastEthernet0/1 is running MPLS via Label Distribution Protocol (LDP), R4 now consults the MPLS Label Forwarding Information Base (LFIB) to see if there is an MPLS label assigned to the next-hop we’re trying to reach, 10.1.6.6.

R4#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     10.1.56.0/24      0             Fa0/1      10.1.45.5
17     17            10.1.6.6/32       0             Fa0/1      10.1.45.5
18     18            10.1.68.0/24      0             Fa0/1      10.1.45.5

R4 finds an entry for 10.1.6.6/32 in the LFIB, and uses the outgoing label value of 17.  This means that for traffic going to 10.1.8.0/24, the label 17 will be added to the packet header.  In reality this lookup process occurs as one step, which is the lookup in the CEF table.  The below output of the CEF table for the final destination on R4 shows that label 17 will be used, because it is inherited from the next-hop of 10.1.6.6.

R4#show ip cef 10.1.8.0 detail
10.1.8.0/24, epoch 0
 recursive via 10.1.6.6
 nexthop 10.1.45.5 FastEthernet0/1 label 17

Now that the MPLS label lookup is successful, the packet is label switched to R5, which leads us to the key step in this example.  When R5 receives the packet, it sees that it has an MPLS label in the header.  This means that R5 performs a lookup in the MPLS LFIB first, and not in the regular IP routing table.  Specifically R5 sees the label number 17 coming in, which has a match in the LFIB as seen below.

R5#show mpls forwarding-table

Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop

Label  Label or VC   or Tunnel Id      Switched      interface

16     Pop Label     10.1.4.4/32       15447         Fa0/0      10.1.45.4

17     Pop Label     10.1.6.6/32       15393         Fa0/1      10.1.56.6

18     Pop Label     10.1.68.0/24      0             Fa0/1      10.1.56.6

The local label 17 is associated with the destination 10.1.6.6/32.  Although our packets are going to the final destination 10.1.8.0/24, knowing how to get towards the next-hop 10.1.6.6/32 is sufficient for R5, because we know that R6 actually does have the route for the final destination.  Specifically R5’s operation at this point is to remove the label 17 from the packet, and continue to forward the packet towards R6 without an additional label.  This operation is known as the “pop” operation, or label disposition.  This occurs because R5 sees the outgoing label as “no label”, which causes it to remove any MPLS labels from the packet, and continue forwarding it.

On the return trip for packets from 10.1.8.0/24 back to 10.1.7.0/24, R6 adds the label 16 and forwards the packet to R5, then R5 removes the label 16 and forwards the packet to R4.  This can be inferred from the LFIB and CEF table verifications below.

R6#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     16            10.1.4.4/32       0             Fa0/0      10.1.56.5
17     Pop Label     10.1.45.0/24      0             Fa0/0      10.1.56.5   

R6#show ip cef 10.1.7.0 detail
10.1.7.0/24, epoch 0
  recursive via 10.1.4.4
    nexthop 10.1.56.5 FastEthernet0/0 label 16

R5#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     No Label      10.1.4.4/32       17606         Fa0/0      10.1.45.4
17     No Label      10.1.6.6/32       17552         Fa0/1      10.1.56.6
18     Pop Label     10.1.68.0/24      0             Fa0/1      10.1.56.6

To see this operation in action, we can send traffic from 10.1.7.0/24 to 10.1.8.0/24, and look at the debug mpls packet output on R5.

R5#debug mpls packet
Packet debugging is on

SW1#ping 10.1.8.8 source 10.1.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.1.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

R5#
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data

The beauty of this MPLS design is that for any new routes AS 7 or AS 8 advertise into the network, AS 100 does not need to allocate new MPLS labels in the core.  As long as MPLS transport is established between the BGP peering address of the Provider Edge routers (R4 and R6 in this case), traffic for any destinations can transit over the Service Provider’s network without the core needing any further forwarding information.

R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.1.45.5 on FastEthernet0/1, 01:06:22 ago
Routing Descriptor Blocks:
* 10.1.45.5, from 10.1.6.6, 01:06:22 ago, via FastEthernet0/1
Route metric is 3, traffic share count is 1

R4#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/1        Yes (ldp)     No       No  No     Yes
R4#show mpls forw
R4#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     10.1.56.0/24      0             Fa0/1      10.1.45.5
17     17            10.1.6.6/32       0             Fa0/1      10.1.45.5
18     18            10.1.68.0/24      0             Fa0/1      10.1.45.5
R4#show ip cef 10.1.8.0 detail
10.1.8.0/24, epoch 0
recursive via 10.1.6.6
nexthop 10.1.45.5 FastEthernet0/1 label 17

We recently created a new self-paced MPLS course, which walks the learner step by step from concept to implementation for MPLS and L3 VPNs.  Click here for more information.

We wanted to provide our students with advance notification of some upcoming online classes here at INE. While we hope to see many students in the actual live events, on-demand versions will indeed be made available the week following the live, online version.

Join the INE Experts Online in September and October

September 13 – 17th, 2010     CCNA Wireless 5-Day Bootcamp

September 15 – 17th, 2010     Security for CCIE R&S Candidates 3-Day Bootcamp

September 29 – Oct 1, 2010    IPv4/IPv6 Multicast 3-Day Bootcamp

October 4 – 9th, 2010              Online 6-Day CCIE R&S Bootcamp with K. Barker and A. Sequeira

Time is a valuable resource in the lab.   In a lab task, if asked to configure a policy-map named “BOB”, it doesn’t get the same point value if we happen to accidentally name it “bob”, especially  if they are looking to see if you configured what they asked for.

The challenge is, that when reviewing a lab task, and we discover that we need to change a name, it could be a hassle, as we need to remove the policy-map, recreate the policy map, and then put it in place again.

So if you are down to the last minute, here is a time saving solution, that can assist with that process.

IOS allows us to rename a policy-map, and the IOS will swap out the name in other areas of the configuration that reference that policy map.

Here is an example, of a policy map from Volume 2, lab 5.

Rack1R5#show run policy-map
Building configuration...

Current configuration : 352 bytes
!
policy-map TRANSIT_RATE_LIMIT
class FRAGMENTS
   police rate 1000000 pps burst 200000 packets
policy-map type port-filter HOST_PORT_FILTER
class CLOSED_PORTS
   drop
policy-map CEF_EXCEPTION_RATE_LIMIT
class class-default
   police rate 100 pps burst 20 packets
policy-map HOST_RATE_LIMIT
class ICMP
   police rate 10 pps burst 5 packets
!
end

Rack1R5#show run | begin control
control-plane host
service-policy input HOST_RATE_LIMIT
service-policy type port-filter input HOST_PORT_FILTER
!
control-plane transit
service-policy input TRANSIT_RATE_LIMIT
!
control-plane cef-exception
service-policy input CEF_EXCEPTION_RATE_LIMIT

Let’s say that after reviewing our configuration, we discovered that the policy-map for the cef-exception sub interface of the control plane should have been named “NEW-NAME-CEF”.

To change it everywhere in the configuration, instead of creating it new, and replacing it, we could simply do this:

Rack1R5(config)#policy-map CEF_EXCEPTION_RATE_LIMIT
Rack1R5(config-pmap)#rename NEW-NAME-CEF

Now, when we look at the configuration, we can see that not only the name has changed for the policy-map, but it also updated our control-plane configuration to reflect the new name there as well:

Rack1R5#show run policy-map
Building configuration...

Current configuration : 340 bytes
!
policy-map TRANSIT_RATE_LIMIT
class FRAGMENTS
   police rate 1000000 pps burst 200000 packets
policy-map type port-filter HOST_PORT_FILTER
class CLOSED_PORTS
   drop
policy-map NEW-NAME-CEF
class class-default
   police rate 100 pps burst 20 packets
policy-map HOST_RATE_LIMIT
class ICMP
   police rate 10 pps burst 5 packets
!
end

Rack1R5#show run | begin control
control-plane host
service-policy input HOST_RATE_LIMIT
service-policy type port-filter input HOST_PORT_FILTER
!
control-plane transit
service-policy input TRANSIT_RATE_LIMIT
!
control-plane cef-exception
service-policy input NEW-NAME-CEF
!
!

Best wishes on your studies, and may your policy-maps be named correctly the first time around.

Keith

As you know, the foundation products for self-paced CCIE R&S studies are the IEWB-RS VOL1 and VOL2 workbooks. Together, these two sum up to 4000 pages of hands-on practice content. VOL1 consists of over 600 technology-focused scenarios, while VOL2 consists of 20 full-scale scenarios that now started featuring independent troubleshooting sections and detailed breakdowns, linking you to VOL1 scenarios relevant to a particular task. With this amount of training content, it is not a secret that the major issue people are having while preparing to CCIE lab is lack of study time. Typically, available time slots are random, fragmented and limited to four hours maximum per day. Students may obtain larger time-slots on weekends. Such limitation in contiguous time slots results in people biasing their study habits toward the exclusive use of VOL1, while neglecting VOL2 and practicing only a few out of all 20 scenarios.This results in the following major problems:

• Working mainly through VOL1 in linear fashion, people tend to forget the information they learned earlier during the study process. Based on the logical grouping of VOL1 topics, these are typically L2/L3 and IGP/BGP technologies.
• Missing time to practice VOL2 (full-scale 8 hour scenarios), students find themselves in a situation where they know how to configure and troubleshoot technologies individually, but cannot deal with the complexity of mixed, multi-technology full-scale scenarios.

In this publication we are suggesting an alternative approach for working with VOL1 and VOL2 products, which aims at faster learning and better memorization. The step by step process is outlined below in two different variations, called “Gentle Start” and “Kick Start”. In this publication, the terms “core” and “non-core” technologies are used extensively. The CCIE R&S “core” topics encompass Layer 2 Technologies (e.g. Ethernet, Frame-Relay, PPP), Layer 3 Technologies (IP/IPv6/IGP/BGP), MPLS VPN (MPLS/LDP/MP-BGP) whilte “non-Core” topics are Multicast, QoS, Security and Network Services. The main differentiator is that “core” technologies provide connectivity services, while non-core technologies provide additional functionality on top of the working network.

Gentle Start

This variation offers clearly structured approach to learning and features “smooth” introduction. The unavoidable drawback is larger amount of study time required by this approach, which is approximately 6-7 months. You may choose this option if you have enough time before the lab exam and look toward more “predictable” performance. Make sure you estimate your time availability reasonably, and schedule your lab say a month after you project your training to be completed.

Step 1

Ensure you have enough preliminary knowledge to try a VOL2 scenario. You need to pass the CCIE written exam and fully understand topics covered in the test. As for hands-on component, take a look at Appendix A for the “minimal” set of VOL1 scenarios that you may need to practice to boost your core technologies configuration skills. You may want to use the Advanced Technologies Class-on-Demand to fill up missing knowledge gaps as well.

Step 2

Select a day when you can allocate enough time to complete VOL2 Lab 1 sections “L2, L3, IPv6 and MPLS VPN” (the core sections). Do not spend time on Security, QoS and Network Services sections at this moment. Focusing on topics in this manner should take you about 4-5 hours to finish the “truncated” full-scale lab. Try completing as much core tasks as possible, but don’t get stuck in the areas you are unfamiliar with. For scenarios you completely have no idea how to deal with, manually copy the solution from the solution guide into notepad and paste it into the respective devices. This approach, while looking cumbersome at first sight, has unique benefit of building up your visual and kinetic memory. However, keep in mind that your primary focuse is compiling a list of the individual technologies you need to practice.

Now some really good news – VOL2 labs are starting to have references to VOL1 sections you need to practice to master a particular section of VOL2 lab. This is exactly the list of VOL1 labs that you need to compile for yourself. Also, don’t feel frustrated if you cannot understand the breakdowns in VOL2 at this moment. The VOL2 breakdowns are supposed to be a condensed explanation of the solution and not the detailed technology breakdowns in the newer versions of the product. You will cycle back to VOL2 breakdowns once you’re done with individual technology topics extracted from the selected full scale lab.

Step 3

Practice VOL1 scenarios from the list you made at Step 2. You may also use Advanced Technologies Class-on-Demand as a helper in understanding complicated topics, but make sure you spend time practicing on your own. It is important to note that this process will take you across multiple sections of VOL1 (e.g. L2, L3, IPv6), so you’ll be learning multiple different technologies separated by short time spans. While this could look complicated at first, such process has benefit of keeping your memory up to date with every core technology domain in VOL1. Compare this to the typical “linear” approach of working through VOL1. If you do not have enough time to do every scenario live on a rack, make sure at least that you understand all the breakdowns and retype the solutions to build visual/kinetic memory. You will most likely practice the technology live in the remaining VOL2 scenarios. When you’re done with individual technologies, go back to the full-scale lab you practiced and read the solutions over again – this time making sure you understand the breakdowns.

Step 4

Repeat Steps 2-3 for VOL2 Labs 2-10. Aim at completing this in about 1.5-2 months. This will build solid foundation in core technologies and give better feeling of the lab exam, without stressing you too much with details of non-core topics. Simply practicing the core technologies and mixing full-scale scenarios with individual topics has great overall educational effect.

Step 5

Cycle through labs 1-10 once again, but this time do them in their entirety. Complete as much troubleshooting tickets as you can and identify the non-core topics that are unfamiliar to you and to practice them after the full-scale lab. However, this time do not spend too much time on hands-on for selected VOL1 scenarios. Rather, use them mainly as reading reference and source of configuration samples. Copy the code samples by hand, simply to better memorize the commands, but don’t try completing them all, as this might be too much of the burden at the moment.

At this step, aim primarily at developing configuration speed in “core” topics and building up troubleshooting skills. It is worth mentioning again, that since you practice a mix of technologies at once, the forgetting curve effect will not be so noticeable as it would be in case of linear study approach. Depending on time available to you, this whole study cycle should take approximately 2-3 months.

Step 6

Continue with Labs 11-20 and complete as much of these as you can, in the same manner you worked through Step 2: identify topics you are weak at and practice them afterwards using VOL1 + ATC as your main reference. Notice that this time you will have to allocate full 8 hour time-slots for every VOL2 lab and focus on completing all core scenarios and as much non-core topics as you can. This is no longer plain core-technology practice, but rather full-scale lab exercise. You should aim to be at the 6 months mark after completing this step.

Step 7

Still have some time left? You should have already spent about 5-6 months on hands-on practice at this moment and built solid foundation for passing the lab exam. Take a look at the list of all VOL1 topics and skim over the technologies you think you are weak at. It would be great time to take a few graded mock labs (e.g. ML1-4) and see how you do there. If your scores are rather disappointing, you have about a month to correct the situation. If you are getting good scores in at least 3 labs, then practicing some scenarios from VOL3 or VOL4 is a perfect time filler before your lab exam, especially if you combine them with a handful of VOL2 labs. Just keep in mind that your last month should be dedicated to practicing as much full-scale labs as possible, developing speed and accuracy.

Kick-start

This is an option for people who has less time to prepare and can tolerate some “roughness” in the beginning. The main challenge of this approach is high level of stress and frustration associated with diving into technology topics with little prior experience/knowledge. Estimated time to complete this plan is about 4 months, as compared to 6-7 months of “gentle” start. Unlike more structured “gentle” start, however, obtaining predictable performance might be harder with “kick-start”. We would suggest you not to book a lab exam until you spent at least a month familiarizing yourself with this approach.

Step 1

Ensure you have knowledge of routing and switching technologies at least at the level of CCIE Written test blueprint. It is important that you pass the written test prior to starting the hands-on and do understand the theoretical basics mentioned there. Practicing the VOL1 lab list from Appendix A is advisable, but not highly necessary, unless you really lack configuration skills.

Step 2

Dive into VOL2 Lab 1 and try completing it entirely. However, depending on your posture, you may not be able to configure most of the topics. Don’t feel frustrated, it’s just a rough start. If you don’t understand the solution, simply type the it from the solution guide into notepad and paste it into devices. Run the verification commands to see if the solution works. For troubleshooting sections of VOL2, try spotting the issues, and if you can’t , simply try memorizing the symptoms and mapping them to the problem. Sounds more like cramming, but this is what you get in the beginning.

As you done with the lab, build the list of VOL1 topics you need to deal with as per the results of this lab. Most likely the number of topics would be close to the number of tasks in the full-scale lab.

Step 3

Proceed to completing the VOL1 labs you made based on the full-scale lab at Step 1. However, unlike with gentle start, don’t aim at completing them all live on the racks. Rather, practice just the technologies you find most confusing and complicated. For other VOL1 scenarios, simply read over the breakdowns and “copy” the solutions to notepad to build the visual/kinetic memory. This is by far not the perfect approach, but it will save you a lot of time you would need to spend otherwise working on foundations. Your main goal at this stage is getting to understand the technologies you’ve been dealing with in the full-scale scenario you just have completed.

Step 4:

Repeat Steps 2-3 for Labs 1-10. This should take you about 2-3 months, and in the end you would have approximately 60-70% of the knowledge you need to pass the CCIE exam. You may not be completely solid at core topics yet, but you would surely do much better compared to the time you were just starting Lab 1.

Step 5:

Complete the remaining ten VOL2 labs. Use the same mode, spotting the topics you need to practice more, but aim at completing every lab as fast as you can. You should be done with these tens labs in another 2 months. After that, take at least one graded mock lab, approximately 3 weeks before your lab date and see if you have any weak spots. If you do, cycle back to the complete list of all VOL1 labs and see if there is anything you’re missing. Practice them, and complete VOL2 Labs 1-5. This should give you a good refresher in core skills.

It is highly advisable to have some extra time for completing at least some of VOL3 and VOL4 scenarios. Those are “advanced” focused workbooks aiming at refining your core configuration and troubleshooting skills.

Summary

We suggest a training approach that is different from the classic “linear” model, where students complete ATC and VOL1 prior to starting VOL2 full-scale scenarios, focusing mainly on the first two products. The proposed approach has two main features:

• Interleaving full-scale (VOL2) and technology-focused (VOL1) scenarios, which results in faster content memorization and better retention.
• Instense use of “blind” typing for router configuration command memorizing, where student types configuration in the notepad prior to pasting it to the routers. This greatly helps building speed an accuracy in Cisco IOS device configuration.

The two workbooks (VOL1 and VOL2) form the core of this training approach, with other products (e.g. ATC, VOL3 and VOL4) being additional tools used either to build foundation or refine skills obtained with the core products.

Appendix A

List of “bootstrap” scenarios from VOL1:

Bridging & Switching: 1.1-1.15
Frame-Relay: 2.1-2.10
IP Routing: 3.1-3.11
RIP: 4.1-4.6
EIGRP: 5.1-5.8
OSPF: 6.1-6.11, 6.21-6.31
BGP: 7.1-7.9, 7.16-7.26
IPv6: 9.1-9.5, 9.12-9.14, 9.17-9.20, 9.29-9.31
MPLS VPN: 14.1-14.7

That is approximately 1/6 of the full VOL1. If you find every topic listed here familiar to you, you may start directly with VOL2 scenarios and skip the preliminary preparations.

INE wants to thank IEOC member Ray Aragon (NET_OG) for his awesome contributions to our Cisco forums. Thanks so much Ray and enjoy 100 complimentary GradedLabs Rack Rental Tokens.

Ray's IEOC Avatar!

I am sure many of you would love to know more about Ray – here it is:

Ray Aragon is an SE in the Networking World and after 10 Plus years working with State/Local government and Major Carriers around the world he decided to get his CCIE using INE products as his primary study aide. Here were some facts Ray shared with me:

• I think I try to be helpful to others, and identify “pitfalls” and my “ahhh-haa” moments

• I like it when I run into a stumbling block and there is already a good discussion on IEOC

• Much thanks to Routing and Switching (networking)…

◦ I lived in London for two years

◦ I lived in Stockholm for two years

◦ I met my wife in Chile

◦ I have travelled to over 25 countries from Egypt to Indonesia

◦ I have over 1 Million Airplane miles flown

• I have an immense respect for anyone that has put in the time to become a CCIE in any track; it demonstrates a commitment that only after my pursuit I can appreciate.

• My Top 10 favorite cities: Madrid/Rome/London/Santiago, Chile/Rio de Janeiro/Santa Barbara/Miami/Lima/Cancun/Mexico City D.F

Can you solve this puzzle?

R2, R3 and R4 create the service provider network, with MPLS on all three routers, and iBGP at the PE routers.  R1 and R5 are the CE routers.

R2, prefers the BGP next hop of 4.4.4.4 for network 5.5.5.5 (R5 loopback). R4, at 4.4.4.4 is an iBGP neighbor.

R2#show ip route vrf v | inc 5.5.5.0
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:06:47

Is R2 preferring an iBGP learned route, which has an AD of 200, over a EIGRP route, which would have an AD of 90?

Can you identify why the routing for 5.5.5.0 on the VRF of R2 is using BGP instead of EIGRP?

Below are the relevant portions of the configuration, which also can serve as a great review of how to configure MPLS VPNs.
R1, CE router:

R1#show run
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.12.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 ip address 10.1.215.1 255.255.255.0
!

router eigrp 1
 network 0.0.0.0
 no auto-summary

R2, PE Router:

R2#show run
!
ip vrf v
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip vrf forwarding v
 ip address 10.1.12.2 255.255.255.0
!
interface FastEthernet0/1
 ip address 10.1.23.2 255.255.255.0
 ip ospf 1 area 0
 mpls ip
!
router eigrp 1
 no auto-summary
 !
 address-family ipv4 vrf v
  redistribute bgp 234 metric 1 10000 1 1 1
  network 10.1.12.2 0.0.0.0
  auto-summary
  autonomous-system 1
 exit-address-family
!
router ospf 1
 log-adjacency-changes
!
router bgp 234
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 4.4.4.4 remote-as 234
 neighbor 4.4.4.4 update-source Loopback0
 !
 address-family vpnv4
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf v
  redistribute eigrp 1
  no synchronization
 exit-address-family
!
ip forward-protocol nd
!

R3, P router:

R3#show run

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.34.3 255.255.255.0
 mpls ip
!
interface FastEthernet0/1
 ip address 10.1.23.3 255.255.255.0
 mpls ip
!
router ospf 1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!

R4: PE Router

R4#show run
!
ip vrf v
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 10.1.34.4 255.255.255.0
 ip ospf 1 area 0
 mpls ip
!
interface FastEthernet0/1
 ip vrf forwarding v
 ip address 10.1.45.4 255.255.255.0
!
router eigrp 1
 no auto-summary
 !
 address-family ipv4 vrf v
  redistribute bgp 234 metric 1 1 1 1 1
  network 10.1.45.4 0.0.0.0
  auto-summary
  autonomous-system 1
 exit-address-family
!
router ospf 1
 log-adjacency-changes
!
router bgp 234
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 234
 neighbor 2.2.2.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf v
  redistribute eigrp 1
  no synchronization
 exit-address-family

R5: CE Router

R5#show run
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.0
!
interface Serial0/0
 ip address 10.1.215.5 255.255.255.0
 clock rate 64000
!
interface FastEthernet0/1
 ip address 10.1.45.5 255.255.255.0
!
router eigrp 1
 network 0.0.0.0
 no auto-summary
!

Now for a couple show commands on R1:

R1#show ip route eigrp
     5.0.0.0/24 is subnetted, 1 subnets
D       5.5.5.0 [90/435200] via 10.1.12.2, 00:19:08, FastEthernet0/0
     10.0.0.0/24 is subnetted, 3 subnets
D       10.1.45.0 [90/307200] via 10.1.12.2, 00:19:08, FastEthernet0/0
R1#

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.1.215.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 1.1.1.0/24, 1 successors, FD is 128256
        via Connected, Loopback0
P 5.5.5.0/24, 1 successors, FD is 435200
        via 10.1.12.2 (435200/409600), FastEthernet0/0
        via 10.1.215.5 (2297856/128256), Serial0/0
P 10.1.12.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 10.1.45.0/24, 1 successors, FD is 307200
        via 10.1.12.2 (307200/281600), FastEthernet0/0
        via 10.1.215.5 (2195456/281600), Serial0/0
P 10.1.215.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0
R1#

And some on R2, the PE router:

R2#show ip route vrf v

Routing Table: v
Codes: 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

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
D       1.1.1.0 [90/409600] via 10.1.12.1, 00:31:48, FastEthernet0/0
     5.0.0.0/24 is subnetted, 1 subnets
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:02:34
     10.0.0.0/24 is subnetted, 3 subnets
C       10.1.12.0 is directly connected, FastEthernet0/0
B       10.1.45.0 [200/0] via 4.4.4.4, 00:31:48
D       10.1.215.0 [90/2195456] via 10.1.12.1, 00:31:21, FastEthernet0/0

R2#show ip eigrp vrf v topology
IP-EIGRP Topology Table for AS(1)/ID(10.1.12.2) Routing Table: v

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 1.1.1.0/24, 1 successors, FD is 409600
        via 10.1.12.1 (409600/128256), FastEthernet0/0
P 5.5.5.0/24, 1 successors, FD is 409600
        via VPNv4 Sourced (409600/0)
P 10.1.12.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 10.1.45.0/24, 1 successors, FD is 281600
        via VPNv4 Sourced (281600/0)
P 10.1.215.0/24, 1 successors, FD is 2195456
        via 10.1.12.1 (2195456/2169856), FastEthernet0/0
R2#

Take a minute to post your thoughts, and as always, happy studies.

Keith

It has been a few days, and we have received lots of great ideas.   Thank you.

When R4 receives the routes in VRF v, the EIGRP metrics are copied into extended BGP attributes, and include the information for metric, AS, route-type and more.  The iBGP updates from R4 to R2 contain all those attributes.   When R2 receives the updates, if the route type is internal (from EIGRP attributes) and the source EIGRP AS matches the local EIGRP AS we are importing to, it will then be up to the  metric to determine the best path.

If we decreased the bandwidth statement on R4 Fa0/1, or used an offset list (2,000,000 more should do the trick) on R5 out Fa0/1 (towards R4), the increase in metric would cause R2 to prefer the path through R1 for 5.5.5.0/24 instead of using the MPLS backbone.

BGP updates that contain the cost community attribute will use the EIGRP AD instead of the iBGP AD of 200 to compare routes on metric alone. In that light, another option, would be to tell R2 to ignore cost-community, with the BGP router command:

bgp bestpath cost-community ignore

Let’s take a look at the results.

Here is the baseline for before any changes:

R2#show ip route vrf v | inc 5.5.5
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:02:29
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 8
Paths: (1 available, best #1, table v)
Flag: 0x820
  Not advertised to any peer
  Local
    4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)
      Origin incomplete, metric 409600, localpref 100, valid, internal, best
      Extended Community: RT:1:1 Cost:pre-bestpath:128:409600 0x8800:32768:0
        0x8801:1:153600 0x8802:65281:256000 0x8803:65281:1500
      mpls labels in/out nolabel/19
R2#

Now we will remove the default behavior

R2(config)#router bgp 234
R2(config-router)#bgp bestpath cost-community ignore

Cleared BGP sessions and routing tables, and waited a minute before the following show commands:

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:00:08, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 8
Paths: (2 available, best #2, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)
      Origin incomplete, metric 409600, localpref 100, valid, internal
      Extended Community: RT:1:1 Cost:pre-bestpath:128:409600 0x8800:32768:0
        0x8801:1:153600 0x8802:65281:256000 0x8803:65281:1500
      mpls labels in/out 20/19
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 20/nolabel
R2#

After setting it back to defaults, we could then try an offset list on R5 advertising to R4:

R5(config)#router eigrp 1
R5(config-router)#offset-list 0 out 2000000 fastEthernet 0/1

Cleared BGP sessions and routing tables, and waited a minute before the following show commands:

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:06:28, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 12
Paths: (1 available, best #1, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 31/nolabel
R2#

After resetting all that, implementing the following on R4, and then clearing BGP and routing, we issue the show commands again.

R4(config)#int fa 0/1
R4(config-if)#bandwidth 100

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:00:05, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 20
Paths: (1 available, best #1, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 23/nolabel
R2#

Thanks again to all who contributed. I encourage all RS candidates to lab this up, as well as practice MPLS with OSPF at the CEs.

Marcel posted a comment, reminding us of an excellent document written by Petr, on this topic and more. The original post from Petr which includes the link to free .PDF for this document may be found by clicking here. Thanks Marcel!

As a CCIE instructor, this type of question is one that I see (in IEOC) or hear (in class) often. To help directly address this question, I have maintained a document I call the Expanded Blueprint for many years now. I was quite flattered to see the CCIE team at Cisco publish their own version and name it the Expansion Blueprint.

I made sure to correlate their’s against my own and ensure that I did not miss anything. In fact, what I learned quickly was the fact that they had some very glaring omissions of topic areas that were on the original Lab Blueprint. I would hope they have since corrected that.

But what I want to discuss in this blog post is the fact that regardless of which blueprint document you are relying upon in your studies, Cisco does make it very clear that it is their Certification-given right to test anything they deem appropriate from the 12.4T IOS code (in the case of the routers in the exam). Hmmmm, wait a minute! So they can test anything that the routers or switches can do!?!?!? This will certainly go a long way in dashing the hopes of many feint of heart candidates.

Before you get excessively upset about this fact, just be sure to use some common sense. My Expanded Blueprint is certainly going to cover the overwhelming majority of exam topics. Moreover, I will go so far as to say, since you do not require to pass this exam (either section) with a perfect score, knowledge of the Expanded Blueprint topics is indeed enough to pass. Whew!

I believe that one of the reasons Cisco likes to make this disclaimer (they can test anything), is the fact that they often like to challenge students on new features of protocols or services. This is one of the reasons that I like students to incorporate the New Features section of the DOC-CD in their studies. For more information on using the DOC-CD, you might want to check out my free vSeminar on the topic.

Another perfectly valid reason for Cisco making this statement is the case where a proctor wants to compose a juicy new task and they simply do not want to have to worry about whether or not it is on the blueprint, their expansion version or otherwise. They believe, correctly, that if the feature is contained within the context sensitive help, and/or the documentation, then it is certainly reasonable that a CCIE-level candidate should be able to achieve the points. Buy again, note we are talking about minor router and switch capabilities here and not a dramatically vast topic area.

I would recommend the use of common sense when contemplating your scope of studies. Sure the official, original, condensed Cisco Lab Blueprint might say “Other Security Features”, but do you really think they are going to test R&S candidates on the GET VPN? No. This is the fun that CCIE Security candidates get to enjoy.

If you ever have questions regarding study scope, be sure to hit our forums, but I am thinking you can answer many of those questions for yourself now as well.

By the way, I would recommend you be very careful about listening to what just anyone has to say on subjects like this. For various reasons, candidates, CCIEs, and even some non-INE instructors I have come across, love to instill fear and doubt in others regarding the CCIE and its pursuit.