The newest updates to the Routing & Switching Volume II labs are being released in electronic format starting this week. The updates will automatically show up in your members site account as the labs are released.

This Friday the CCIE R&S Lab Meet-Up series kicks off with the new CCIE R&S Lab Workbook Volume 2 Version 5 Lab 1. The new lab will be posted on the members site on Thursday, and the lab meet-up starts at 9am Pacific time. The session should lab about 4 hours, depending on how many questions people have. Essentially I will be configuring and explaining the lab live on the command line, and going through the logic of the solutions in detail.

It’s not too late to sign-up for the series, so contact our sales department if you have any questions. I hope to see you there!

It looks like IE will be releasing the new labs one lab at a time with a Lab Meet-Up scheduled for each lab to discuss the lab/solutions.

Graded Labs (an Internetwork Expert partner) recently announced a new feature: Workbook Scaffolding. So what exactly is workbook scaffolding?

Starting with the labs in Internetwork Expert’s Routing and Switching Workbook Volume 2, you will be able to one-click load the starting configurations for any task in the workbook. The purpose of this scaffolding is to increase your productivity by giving you the option to by-pass content that you have already mastered.

You now have the ability to load the configuration for any task in the IE Volume II workbook labs. This is pretty handy. Say that you really want to work on mastering BGP. Usually you would need to complete switching, IGP, and Frame Relay before you could start to do the BGP tasks. With workbook scaffolding you can simply load a lab to start at the BGP section.

Graded Labs - Lab Scaffolding

This is also great for lab continuity if you use a home rack as well as rack rentals. I have a rack at work which I use on the weekends. During the week I rent rack time from IE. In the past if I did not complete a lab, I would either need to alter the configurations to work with IE’s interfaces or just wait until the next weekend to complete the lab. After a week the details of the lab are much more fuzzy. Now I can stop at any point in a lab and start again at the same task on an IE rack.

One other use for this feature is when you just can’t get your output to match the output in the solution guide. You may have misconfigured something earlier in the lab and it’s now messing you up to the point of frustration. While troubleshooting is an important skill, there are times when you just need to move on with your lab. You can load the task on a rented rack and continue on with the lab or even save out the working configurations and compare them with your configuration to see where you went off the tracks.

I haven’t tried out this feature yet, but I am pretty excited and think that it’s another great tool for CCIE candidates.

Users in VLAN 26 have their default-gateway set to their own IP address instead of r6’s address. Configure r2 and r6 to support them.

WTF? No clue.

The answer: turn off proxy-arp on those segments.

UPDATE:

It turns out that I read the question wrong. The requirement is:

“Configure r2 and r6 not [sic] support these users.”

It make sense to disable proxy-arp so as NOT to support these users. The users are set up to ARP for everything. Proxy-ARP is enabled by default so r2 and r6 will respond to ARPs with their own MAC address if they have a route for the address that the users ARP for. By disabling proxy-arp, the routers will not respond to those ARP requests.

9.2 Web Caching

Configure WCCP for users in VLAN 4. The web servers are out the Frame link.

“Configure r4 to support this setup, but don not attempt to cache HTTP traffic between VLANs 4 and 45.”

r4(config)#ip wccp web-cache ?group-address Set the multicast group
group-list Set the access-list used to permit group membership
password Authentication password (key)
redirect-list Set the access-list used to permit redirection
<cr>

The three options that stand out as possibly being useful for the last requirement are the outbound-acl-check, the group-list, and the redirect-list.

I peeked the solution guide.

Huh?

IE just enabled WCCP globally and then set s0/0 to redirect out??? Does that last requirement mean ALL HTTP request on VLANs 4 and 45 or just the traffic between those two VLANs (as I understood it)?

I get it now. There are only two egress point for traffic from VLAN 4 or 45. They can either egress the other VLAN or out the Frame link. So IE’s solution makes sense.

9.3 IP SLA

This is a basic IP SLA task in which you must set up IP SLA on r6 to ping 115.0.0.1 every 30 seconds with 1250 byte packets and a timeout of 25ms.

Drop all source-routed packets
Disable proxy-arp and CDP support on the connections to BB2 and BB3
Drop all HTTP an telnet sessions destined for 174.x.0.0/16 and 150.x.0.0/16 from BB2 or BB3
Drop all inbound echo requests coming from BB2 or BB3

In the real lab I would just eat the 3 points rather than mess with connections to the backbone routers. But this task is pretty easy so I gave it a shot.

Easy BGP peering task. Only “twist” is that you’ll be configuring confederations.

SubAS 65145 has a full mesh. 65267 does not. You’ll need make r6 a route-reflector.

You’ll also need to remember to set ‘next-hop-self’ between inter-confederation peers where needed (unlike true EBGP peerings, inter-confederation peers do not automatically set ‘next-hop-self’). Or not…this will be addressed in later tasks. :-)

For some reason IE peered between the loopbacks on the routers in SubAS 65145.

4.2 BGP Summarization

Advertise a summary of 174.x.0.0/16 to the backbone routers.

“Do not allow any other devices in your BGP network to see this prefix.”
“Use one static router on r5 and r6 to accomplish this.”

So we’ll need to create a static route to Null0 on r5 and r6 and redistribute it into BGP…while filtering it for the rest of the BGP routers.

First, create the static route:

r5(config)#ip route 174.1.0.0 255.255.0.0 null0

Next, match that route in a prefix-list and create route-maps to filter it for our network:

“Configure the network in such a way that all devices throughout your network have reachablility to the BGP prefixes learned from AS54.”

Ugh. That “all devices” bit had me worried that I would need to redistribute BGP into IGP. But the only devices not running BGP are sw3 and sw4 and they are in an OSPF stub area so they will just send traffic for unknown destinations to r3. So we should be cool.

“Do not advertise the Frame Relay link to BB1 or the Ethernet link to BB3 into IGP or BGP to accomplish this.”

Not a problem I just use ‘next-hop-self’

“Do not use the next-hop-self command to accomplish this.”

Oh poop. I’m stumped. Should I summarize the routes? Create a default route?

Nope. IE was being a bit tricky. I need to use next-hop modification BUT I cannot use the command ‘next-hop-self’. Instead I can set the next-hop in a route-map with ‘set ip next-hop peer-address':

We can use the route-maps that we created for the last task and just add the line:

Basic EIGRP task. The only confusing bit is that the task asks you to advertise the lo0 interface of all of the EIGRP devices into EIGRP. r3 is already advertising its lo0 interface into OSPF. They must have meant all of the EIGRP devices except r3 (the solution guide bears this out).

Redistribute between RIP and EIGRP on r5 and then between OSPF and EIGRP where needed.

Remember that OSPF area 38 is a stub area so it’s not going to let in any external routes. That means our OSPF<->EIGRP redistribution needs to happen on r3.

I ran into one issue. I had a route to 174.1.31.0/24 on r1 (connected) as well as r2-3(OSPF). But r4 and r5 did not have the route.

The problem is that r3 gets that route via OSPF and then advertises it to r1. R1 does not install the route from r3 because it has that network as connected. The route does not get passed on to the EIGRP routers behind r1.

I need to either redistribute that connected interface into EIGRP on r1 or find some way to have r1 prefer the route to r3 over the connected route.

Thus begins the monster BGP section. 20 points! Plus we get to deal with a network in which there is not end-to-end IGP reachability. WHEE!!!

I drew out my BGPpeering diagram and spotted four possible route-reflectors. I needn’t have bothered as the next task explicitly pointed them out. :-) The only twist is that these route-reflectors should not treat each other as clients.

All of these first three tasks were very basic, so I just did them all together.

Because of the broken IGP you’ll need to configure “next-hop-self” for all of the iBGP peerings behind routers with EBGP peerings.

The IE solution for r2 shows a ‘next-hop-self’ statement for the EBGP peering from r2 to BB2. They do the same thing for the EBGP peering between r6 and BB1 as well as the EBGP peering between sw2 and BB3. This seems redundant to me. Watch the network masks (/25) when advertising in VLANs 3 and 33. That task also asks you to use r2, but that’s a typo as it should be r3. VLAN 45 is a /29 so watch that one as well.

5.4 BGP Bestpath Selection

Configure AS 200 to affect traffic inbound from AS 100 so that traffic to VLAN 3 goes one route and traffic to VLAN 33 goes another. If either link fails, use the other as a backup. Make sure that a third link is not used at all.

Well we’re tasked with affecting inbound traffic by configuring AS 200. We have two primary options to do this: AS-Path or MED. Since we are affecting all traffic and AS 200 is the destination AS, MED is the easier method to use. We will need to change the MED on two of the three AS border routers and then either crank up the MED to an impossibly high value or just filter the routes (my preference) on the third.

Configure AS 200 to only route traffic destined for AS 254 (BB2) over the Frame Relay link between r2 and r4. Do not allow traffic destined for AS 254 from AS 100 to route out any other connections even if the Frame Relay link between r2 and r4 is down.

This means that we need to filter all routes to destinations that have AS 254 in the AS-Path from using r1 and sw1 to enter AS 100.

Since we’re tasked with doing this in AS 100 AND we only want the traffic to AS 254 to use one link regardless of the state of that link, we just need to filter any advertisements with AS 254 in the path outbound on r1 and sw1.

First we need an AS-Path statement matching traffic with AS 254 in the path. We need to match any AS-Path that contains an instance of ‘254’:

Rack16R1(config)#ip as-path access-list 55 permit _254_

Now we need to filter any prefixes that match that AS-Path in a route-map. We already have an outbound route-map set up for r4:

And of course after all of that….IE uses a different AS-Path statement:

ip as-path access-list 1 permit ^254$

I’m a little confused on this. This matches any paths where AS 254 is the first AS in the path. Both solutions provide the same results, but mine does not assume that there will always be only one exit path to AS 254. I say tomato, IE says tomato.

5.6 BGP Default Routing

Just read the last few lines of this task as the rest may confuse you (as it did me). You need to configure As 100 do advertise a default route into AS 200 but “send AS 200 a full view along with a default out each BGP connection.”

We might as well address our last requirement at this point. We need to affect outbound traffic from AS 200 to prefer this default route. We have a choice of Weight or Local Preference to do this. Since we are limited to configuring sw1 and we need to affect all of AS 200 only we need to use local_pref. We just need to set the local-preference for this default route to a high value (higher than the default of 100 at least):

I guess that I read the requirements wrong as I thought that we needed to include traffic destined for AS 100 AND AS 100 plus one more AS.

DOH!!! Those of you with a keen eye will see where I fucked up. I pasted in the IE regular expression. If you look at my command you’ll notice that the question mark is missing. You need to use ‘control+v’ to insert a question mark. Here’s what the output should look like:

“This link should still be able to be used to send traffic out to AS 100 if there are no longer matches throughout the BGP domain, but should only be preferred as a default exit point if sw1’s connection to AS 100 is down.”

All this is saying is that we should leave the default route to AS 100 alone (we already configured the AS 200 to prefer the default route to sw2).

5.9 BGP Bestpath Selection

At this point I was sick to death of BGP. Only two more tasks to go:

I had a hell of a time deciphering this mess. I think that we just need to make sure that the default route that r1 is learning from r4 is only used if the link between sw1 and sw2 as well as the link between r2 and r4 are down. This seems like it should be as simple as setting the local-preference on the default to be less than those two links. sw1-sw2 has a local-preference of 666666 and r2-r4 has the default of 100, so we just need to configure the default on r1 to a value less than 100.

I doesn’t get any easier than this. You’re asked to configure dense mode on specific interfaces.

6.2 Multicast Distribution

Users in VLAN 22 want access to a video feed on 225.25.25.25 (using UDP port 31337) from VLAN 17. For some reason (most likely because PIM is not configured on r3’s s1/3 :-) ) r3 is not passing this traffic to r2. Configure the network so that the users can receive traffic from this group.

“Do not enable PIM on any additional interfaces to accomplish this.”

Fuck. There goes the easy solution.

This has me stumped. The multicast path from VLAN 17 to VLAN 12 is broken at r3. Is there a way to change this traffic to unicast or broadcast traffic? Yup. :-)

There are a lot of verification commands in the solution guide, but nothing as far a breakdown.

6.3 Static RP

Well you didn’t think that we were going to get away with just running dense-mode on three devices did you? This task has you set up a pim-spare multicast network in the OSPF half of the network.

The weird bit is that we have to create loopback 1 on r4 and r5 and then give them the same address and advertise them into OSPF.

Then we need to configure r6 to use r4’s loopback 1 as the RP and sw2 to use r5’s loopback 1 as the RP. If either should fail, then they should switch over to the other loopback 1 as the RP. Remember, these loopbacks have the same /32 address.

Ummm…r3 has TWO Ethernet interfaces? Which one do they mean? It turns out that they only mean e0/0 (VLAN3).

7.2 IPv6 over Frame Relay

This is a basic IPv6 Frame Relay hub-and-spoke task. They even go so far as to tell you what to use for the link-local addresses. I always read ahead in the IPv6 section to see if we will be running an IPv6 IGP over the Frame Relay network. In this case task 7.4 will require exactly that. SO….if there are no requirements against it, I hardset the link-local addresses to Fe80::Y (where Y is the router number) AND I go ahead and create frame maps for the link-local addresses. It’s not required in this task, but we might as well do it now.

Since we don’t have any routes greater than /64 coming from BB2, there is really no good way to validate this. BUT make sure that the this doesn’t break your IPv6 routing by making sure that the RIPng routes from BB2 are getting to r3:

If you did not create frame maps for the link-local addresses then you will need to do this now (IPv6 IGPs use the link-local address for next-hop processing).

We need to get our neighbor adjacencies up, but we’re not allowed to change the default OSPF type. This means we need neighbor statements on the hub (and priority 0 statements on the spokes). The only deviation form the OSPFv2 process is that this is done under the interface:

The redistribution is pretty straight-forward except I couldn’t decide if I needed “include-connected” as well. I voted “no” – which ended up being a mistake. I need to review IPv6 redistribution to find out why.