Kevin Dorrell, CCIE #20765

27 Feb 2008

NMC Lab 09.18 – Multicast

Filed under: IP Multicast — dorreke @ 14:10

I set off with good intentions yesterday evening.  Having got full reachability in 2 hours and 20 minutes, I thought I would just knock off the BGP, the IPv6, and the multicast all in one evening.  It wasn’t to be.  I got stuck on the BGP (which I shall write about some other time) and I got stuck on the multicast (which I shall write about now because it is more interesting), and I didn’t even attempt the IPv6.

If anyone reads this posting, it will probably make much more sense if you have the NMC scenario in front of you.  So go out and buy it!  It is not my intention to substitute or plagiarise the excellent labs that NMC produce, but more to use them as a starting point for my learning experience.

As I could tell from the wording of the requirements, the main problem was how to get R7 FRS to respond to the multicast ping.  I knew what the problem was: the FRS has an RPF to the source that points to R4 on VLAN 40, but the multicast stream is coming from R3.  That, and the fact that the FRS does not seem to see the RP.  The FRS is logging something about an “invalid join for 229.17.17.17 from R4”.  (Note to self: Examine this message as see where it comes from, and why FRS thinks it is invalid.)

As usual, I almost got the solution, but not quite.  The first thing I did was to put a static mroute in R4 towards the RP (172.16.106.1) via the FR interface.  That was correct!  The RP turned up in the FRS immediately.  But still no multicast stream.

It was here I made my biggest mistake.  As usual, I did not read the scenario carefully enough.  It says “9.18.5. Do not introduce static mroutes on FRS or create any new interfaces on FRS or R4.  Only configure static mroutes on 1 router in this scenario.”  Instead, I read, “Only configure 1 static mroute in this scenario.”  Which is why I spent the rest of the evening learning the hard way.

The various things I tried were:

  1. Putting ip pim nbma-mode on the FR interfaces … on R1 and R4!  So near and yet so far!
  2. Changing the dr-priority of the three routers concerned: R3, R4 and FRS.
  3. ip mroute 172.16.0.0 255.255.0.0 172.16.10.1 on R4!  So near and yet so far!

By now, I have looked in the Answer Key and groaned.

The best way to look at this is as a starting point for a learning exercise.  These are things to be investigated:

  1. Start with initial conditions of PIM configured on all the routers and the RP sending out its stuff.  Then look at that logging message on FRS and work out where it comes from and why.  I suspect I shall be breaking out my laptop with Ethereal.
  2. In this condition, are the mpackets appearing on VLAN40 at all.  If so, then the FRS is not forwarding them to Lo107 because of the lack of RP.  So, if I join the R7-E0 into the group, would the FRS respond?
  3. Find out about dr-priority, what it means, why it exists, and work out whether it has any effect at all in this scenario at all.
  4. Configure the solution proposed in the Answer Key and the SHOWiT and examine it carefully.  In particular, look at the show ip mroute in R3 to see the nbma-mode in action.
  5. Now, just to be perverse, see if I can do it without any static mroutes at all.  It should be possible like this:
    1. Go to R4 OSPF and lower the AD of 172.16.106.1 to something under 90.  This of course will mean that R4 will start injecting that prefix into the EIGRP.  But that is OK.  We actually want the FRS to use R4 for this prefix, and R3 will ignore it because it has a better internal.
    2. Now, for the RPF on the source, 172.16.11.0/24.  I reckon that should already be on the FR interface, so no change required there.
    3. But R4 is not receiving any multicasts now.  Why not?  Because R3 and R2 are not forwarding them because of their split-horizon thing.  So we need ip pim nbma-mode.  On R2 or R3?  Probably one or the other, but not both.  What will happen if we do put it on both?  Will R4 get two copies of each mpacket?
    4. Alternatively, we could get R3 to prefer the EIGRP route to 172.16.11.0/24.  In that case, R3 should start receiving the stream from VLAN 40, and forwarding it on the FR.  As long as R4 is expecting it from the FR, that should work.

There are so many possible solutions, how come I didn’t hit on any of them?

I guess I’ll have to record Torchwood and watch it some other day.

Advertisements

3 Comments »

  1. I am glad that I am not the only one who misreads the questions… Catches me

    Comment by Doug — 28 Feb 2008 @ 12:44

  2. Doug, thanks for those docs. They are mainly concerned with dense-mode, so I shall keep them in my “possible solutions list”. For now, this is a sparse-mode scenario, and all it really needs is a clear head.

    The two aspects I need to read about are “What does the PIM DR do and how does that affect the topology?” and “If a router A is on an Ethernet segment and has an RPF to router B, and then it receives a packet from router C instead, how does it know to reject it?” I suspect the two questions are related.

    I wish Beau Williamson would update his book. Meanwhile, I am going to re-read the multicast chapter of Wendell Odom’s excellent CCIE Cert Guide. You never know, I might read the official conf guide as well.

    Cheers,
    Kevin

    Comment by dorreke — 28 Feb 2008 @ 15:31


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: