I am completely off work for 2 whole weeks starting today! I’ve been struggling to finish up the IPexpert Volume 1 technology specific labs all week, so that by the time my 2 week break came up, I could start using it to dig into the full scale 8 hour Volume 2 labs.

I did pretty well on my struggle to finish up volume 1, although admittedly I did skip a lab on GRE tunnels, and I sort of rushed through IPv6.

My plan for the next few weeks is to get my ass out of bed by 9:00 AM, get my coffee, and get on my rack! I’ll be starting with Volume 2 lab 1. My lovely wife is not as fortunate as me, and has to go to work, which sucks for her, but that means I will have an entire quiet empty house and NO EXCUSES! I plan on really hitting it hard, and taking full advantage of this opportunity. My goal is to put in between 8 and 16 hours a day on my rack.

P.S. Anybody out there know if the 3550 supports IPv6 ??? I have been unsuccessful trying to find an IOS that will do it for this platform, yet my buddy tells me he has a friend that is doing IPv6 on a 3550. According to internetworkexpert’s difference between 3550/3560 that I stumbled across that is one of the differences

– Joe

So way back in June when I was studying the R/S exam cert guide 3rd edition for the written exam, I found what I thought was an incorrect answer. Feeling more motivated and inspired than usual that day, I actually wrote in to the email address in the book for errata and kind of forgot about it. This morning I received this email from Wendell Odom himself!

Hello Joe,

Wendell Odom here, co-author of the CCIE R/S Written Exam Cert Guide from Cisco Press. You had sent in a note about an error in the book way back in July. My apologies for the delay in responding; the delay was my fault. However, just in case you still care about a response, I wanted to give you my thoughts.

Here’s what you wrote:

I believe the answer to chapter 8, question 8 of the “Do I

know this already” quiz is incorrect.

In the answers appendix the author states “…Because it is passive, no

hellos are sent out fa0/0, meaning no neighbor relationships are formed,

and no routes are exchanged either in or out fa0/0”

However, the correct answer, listed as “C” states “R11 will advertise

subnets 10.1.1.0/24 and 10.1.2.0/24, as well as attempt to send hellos

and updates on the related interfaces”

Why would it attempt to send hellos and updates on 10.1.1.0/24 if it was

configured as a passive interface as shown in the configuration for the

question?

You are indeed 100% correct. The question is wrong. In short, R11 wil advert about 10.1.1.0/24, 10.1.2.0/24, and 10.1.3.0/24, and only send Hellos on the interfaces connected to subnets 2 and 3. So, the explanation text in the answer appendix is accurate, but the answer C text back in Chapter 8 is wrong.

Again, my apologies for the delay.

Regards,

Wendell Odom

Sure it’s really no big deal…I mean it is an obvious mistake, but I have to tell you…Wendell Odom contacting me at all, let alone Wendell Odom contacting me to say “you were right” felt pretty damn good! It was like GOD stepped down for a second and said “Hey good job!” haha

Internetwork Expert has the new Volume 2 labs 1 and 10 up right now.

Labs 1 and 10 of the new CCIE Routing & Switching Lab Workbook Volume 2 Version 5 (IEWB-RS) are now available on the members site. All users with an active subscription to version 4.1 should automatically see the R&S Lab Workbook Volume II Version 5.0 Beta link when you login. The lab meetup for lab 10 is scheduled for 9am Pacific time this Thursday.

Hope to see you there!

Link

Well I am up to IPexpert Volume 1 lab 17. Knowing full well that it would throw a beat down on me hardcore, I decided to re-read the chapters in the CCIE R/S exam cert guide involving mcast, and also watch through both the VOD lecture and configuration on the blended learning solution. As I was watching the configuration video, I was configuring things along with Scott on my own home lab. One small difference between my home lab and the one in the video is that I have a mix of ethernet/FastEthernet interfaces…this turned out to actually cause me to learn a LOT more over the last few days. So while going through the configurations I ran into an issue…and it was really bugging me. I wanted to understand exactly what was going on, and I could not explain it, so I started digging around (curiosity and the desire to know EXACTLY what is going on must be a common trait among us CCIE candidates haha).

I went hard until 2:30 AM and went to bed defeated and exhausted. I worked on the issue all day today….finally 15 minutes ago I put my finger on it. I wanted to write a blog to explain all the pain and suffering : )

Here is the topology for this fun excursion into multicast:

So R2 is our RP, which is statically assigned on all our other routers here. Behind R2 there is a multicast source pumping info to 228.1.1.1. R2 is our Frame-Relay hub, and the routers are all happily running OSPF without any issues. I’ve also added ip pim nmba-mode to R2s frame interface to avoid other issues.

So the first thing I do is make R5 join the multicast group 228.1.1.1 from it’s fa1/0 interface

conf t
int fa1/0
ip igmp join-group 228.1.1.1

R5#show ip mroute 228.1.1.1 | beg \(\*
(*, 228.1.1.1), 00:02:54/00:02:32, RP 200.0.0.2, flags: SL
Incoming interface: Serial2/0, RPF nbr 150.100.100.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:01:57/00:02:32

OK … so I see the multicast coming in from the frame cloud…good. And I see it exiting out E0/0 …hmmmmmm. This was really puzzling because I had put the igmp join command on Fa1/0 , so why was it adding e0/0 to the outgoing interfaces list?

R5#debug ip pim 228.1.1.1
PIM debugging is on

*Dec 10 21:49:27.737: PIM(0): Received v2 Join/Prune on Ethernet0/0 from 150.100.220.7, to us
*Dec 10 21:49:27.737: PIM(0): Join-list: (*, 228.1.1.1), RPT-bit set, WC-bit set, S-bit set
*Dec 10 21:49:27.737: PIM(0): Update Ethernet0/0/150.100.220.7 to (*, 228.1.1.1), Forward state, by PIM *G Join

So R5 is getting PIM joins from R7 on its E0/0 interface. That sure seemed strange, considering I have no real users or anything off or R7 ANYWHERE. When R5 receives that PIM join on its E0/0 interface from R7, it causes R5 to add e0/0 to the outgoing interface list for group 228.1.1.1. The question was why in the hell is R7 sending me PIM joins for this group?

Well according to the route/switch exam cert guide 3rd edition, when there is more than 1 router on an ethernet that receives an IGMP join, they need to battle it out to decide which router has the right to forward multicast onto the segment for that specific multicast group. How they decide that seems to be a bit confusing. The book says it is based on lowest AD of the route to the source address, followed by lowest route metric, followed by highest ip address. In this case, R5 has the better metric to the source of the multicast traffic (100.100.100.102), and R7 has the highest IP address. However I found that R7 seemed to win the ability to forward traffic. I even changed the ip address on R5 to a higher number and at that point R5 started forwarding.

R5#sh ip route 100.100.100.0
Routing entry for 100.100.100.0/24
Known via “ospf 1”, distance 110, metric 36, type intra area
Last update from 150.100.100.2 on Serial2/0, 00:30:08 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 200.0.0.1, 00:30:08 ago, via Serial2/0
Route metric is 36, traffic share count is 1

R7(config-if)#do sh ip route 100.100.100.0
Routing entry for 100.100.100.0/24
Known via “ospf 1”, distance 110, metric 37, type intra area
Last update from 150.100.220.5 on FastEthernet0/0, 00:30:18 ago
Routing Descriptor Blocks:
* 150.100.220.5, from 200.0.0.1, 00:30:18 ago, via FastEthernet0/0
Route metric is 37, traffic share count is 1

So lets think about this…. There is essentially a user off of R5’s Fa1/0 interface joining the group. What happens? R5,R6, and R7 all get an IGMP join request for (*,228.1.1.1). R7, having won the ability to forward traffic for that group sends a PIM join to the RP. HERE IS THE TRICK! When R7 sends that PIM join to the RP it send it out it’s RPF interface….on R7 that would be Fa0/0 because it’s route to the RP through the FastEthernet interface has a better metric than its route to the RP through its Ethernet interface ….the FastEthernet interface happens to be on the same segment as R5’s E0/0. THAT is why R5 keeps seeing PIM joins from R7 on its E0/0 interface…which causes R5 to add E0/0 to the outbound interface list for 228.1.1.1 !

To demonstrate this we can mess with the OSPF interface costs…lets see what things look like now, running as described first.

R5#show ip mroute 228.1.1.1 | beg \(\*
(*, 228.1.1.1), 00:40:38/00:03:10, RP 200.0.0.2, flags: SL
Incoming interface: Serial2/0, RPF nbr 150.100.100.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:39:42/00:03:10

R7#show ip mroute 228.1.1.1 | beg \(\*
(*, 228.1.1.1), 00:40:14/00:02:45, RP 200.0.0.2, flags: SC
Incoming interface: FastEthernet0/0, RPF nbr 150.100.220.5
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:40:14/00:02:45

R7#sh ip ospf int fa0/0 | i Cost
Process ID 1, Router ID 200.0.0.7, Network Type BROADCAST, Cost: 1
R7#sh ip ospf int e1/0 | i Cost
Process ID 1, Router ID 200.0.0.7, Network Type BROADCAST, Cost: 10

So we see the Ethernet interface has a cost of 10 and the FastEthernet has a cost of 1 as expected in OSPF. Let’s flip them and see what happens.

R7(config)#int fa0/0
R7(config-if)#ip ospf cost 10
R7(config-if)#int e1/0
R7(config-if)#ip ospf cost 1
R7(config-if)#do clear ip mroute *

This causes the Ethernet interface on R7 to actually have a better metric to the RP than the FastEthernet interface….therefore the Ethernet interface becomes the interface checked for RPF.

R5#show ip mroute 228.1.1.1 | beg \(\*
(*, 228.1.1.1), 00:45:49/00:02:03, RP 200.0.0.2, flags: SCL
Incoming interface: Serial2/0, RPF nbr 150.100.100.2
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:01:34/00:01:56

R7(config-if)#do show ip mroute 228.1.1.1 | beg \(\*
(*, 228.1.1.1), 00:01:50/00:02:08, RP 200.0.0.2, flags: SPC
Incoming interface: Ethernet1/0, RPF nbr 150.100.221.5
Outgoing interface list: Null

As we can see, now what happens is that the multicast receiver on R5’s Fa1/0 LAN sends an IGMP join for group 228.1.1.1 just like before. Just as before R5, R6, and R7 all receive it. R7 wins the right to forward multicast traffic for that LAN (so far as I understand it) because it has the highest IP address. Therefore, R7 sends a PIM join out it’s RPF interface, which is now e1/0. R5 sees that PIM join request on it’s Fa1/0 interface, and therefore adds it to the outbound interface list as it forwards it up to R2.

I am fairly confident I am giving an accurate description of what is going on here, but if anybody out there sees any mistakes let me know! I sure am curious about that whole thing regarding what router gets the right to forward traffic on a LAN when there is more than 1 router. Is it the lowest metric , or the highest IP address? My testing seems to indicate highest IP address. Oh yeah, this all of course is PIMv2.

It’s official, the CCIE wireless track is here. It looks like the writen exam will be available shortly, and the lab exam will be available in April.

In addition, it seems the voice track has been updated to a “3.0”. Check out the updated blueprint here:

Link

I sent a couple of emails over to sales a few weeks ago asking about when current end-to-end users would see any of the CCIE 2.0 material show up in their account and have not received any response. Last week Monday I talked to a sales rep and they said they were trying as fast as they could to get everyone’s current account updated. I was told they were going to do mine for me in a few minutes since I asked, but that still do not have any of the new material listed under my account.

Anyone out there with an end-to-end program get their updates yet? Just curious how they are looking.

Going to post a status update later tonight as well. It has been a long time I know…

***********Update*********

Stan over at IE got in touch with me to fix my access issues. It looks like I did get my access but it was just in the online classroom section, and was not showing under my members section. So my thanks goes out to Stan in helping out with that. Hopefully I can drive in and blog about these very soon.