Kevin Dorrell, CCIE #20765

17 Feb 2008

NMC Lab 7.17 Multicast

Filed under: IP Multicast — dorreke @ 19:14

So, to the multicast.  Accompanied by Gordon Giltrap’s excellent album “Fear of the Dark”.

Configured it all up according to the requirements, configuring static RP all over just to be quick-and-dirty.  (I shall play with BSR later.)  Pinged 227.7.7.7 from 172.16.31.1 on R1. Nothing.  Enabled debug ip mpacket on R3 and tried again.

Feb 17 16:27:38.106: IP(0): s=172.16.31.1 (FastEthernet0/0.10) d=227.7.7.7 id=2, ttl=254, 
 prot=1, len=114(100), RPF lookup failed for source or RP[OK]

So, an RPF failure. It is not expecting multicast packets form 172.16.31.1 to arrive on FastEthernet0/0.10.  So where is it expecting them to arrive?

R3#show ip route 172.16.31.1 
Routing entry for 172.16.31.0/24 
  Known via "connected", distance 0, metric 0 (connected, via interface) 
  Advertised by bgp 300 
  Routing Descriptor Blocks: 
  * directly connected, via FastEthernet0/0.10 
      Route metric is 0, traffic share count is 1

 Huh?  Scratches head.  RPF failure when the packet arrives on Fa0/0.10, but the route to the source is via Fa0/0.10.  What is going on?  Must be that strange secondary addressing that is upsetting it.  Tried reversing primary and secondary addresses on R3 – no change.  ???  Aagh, another misconf:

interface FastEthernet0/0.20 
 ip pim sparse-mode

No! VLAN 20 is not on Fa0/0.20, it’s on Fa0/1.  So R3 could not see the RP, even if it was configured statically. But what a cryptic error message!  It was the RP that was failing the RPF check, not the source.  Not only that, but I did it on R2 as well. Perhaps I would do well to keep a note of the interfaces I am using.  Or use the show ip int brief command more often.  Perhaps I should do an alias exec ship show ip interface brief | exclude unassigned on all routers.  That would be useful, and would help avoid such mistakes.

What it does illustrate is the advantage of distributing RP information dynamically, either with autoRP or with BSR.  You can see whether or not you are talking to the RP.  So, reconfigured everything to use BSR, and watched the RP turning up in each router in turn. Great!  Except R6.  What is the problem there?  Let us take the hint from the mistake we made before: let’s check the RPF back to the RP:

R6#show ip route 172.16.120.1 
Routing entry for 172.16.120.0/24 
  Known via "eigrp 30", distance 170, metric 40960 
  Tag 110, type external 
  Redistributing via eigrp 30 
  Last update from 172.16.46.4 on FastEthernet0/0.40, 01:21:12 ago 
  Routing Descriptor Blocks: 
  * 172.16.46.4, from 172.16.46.4, 01:21:12 ago, via FastEthernet0/0.40 
      Route metric is 40960, traffic share count is 1 
      Total delay is 600 microseconds, minimum bandwidth is 100000 Kbit 
      Reliability 255/255, minimum MTU 1500 bytes 
      Loading 1/255, Hops 1 
      Route tag 110

OK, it is not the way the multicast topology is drawn.  So, let’s try and fix it with a static mroute:

R6#conf t 
R6(config)#ip mroute 172.16.120.0 255.255.255.0 172.16.36.3 
R6(config)#^Z

Have we got the RP now?

 R6#show ip pim rp mapping 
PIM Group-to-RP Mappings Group(s) 227.7.7.7/32 
  RP 172.16.120.1 (?), v2 
    Info source: 172.16.120.1 (?), via bootstrap, priority 0, holdtime 194 
         Uptime: 00:01:13, expires: 00:02:55 
Group(s) 227.8.8.8/32 
  RP 172.16.120.1 (?), v2 
    Info source: 172.16.120.1 (?), via bootstrap, priority 0, holdtime 195 
         Uptime: 00:01:13, expires: 00:03:00

How are we doing at R1?

R1#ping 227.7.7.7 Type escape sequence to abort. 
Sending 1, 100-byte ICMP Echos to 227.7.7.7, timeout is 2 seconds: Reply to request 0 from 172.16.13.3, 5 ms 
Reply to request 0 from 172.16.234.4, 45 ms 
Reply to request 0 from 172.16.25.5, 29 ms 
Reply to request 0 from 172.16.36.6, 13 ms 
Reply to request 0 from 172.16.23.2, 9 ms 
R1#

OK, all but CAT2.  I had added a join-group on CAT2, but I don’t know whether that was required.  One sure way to find out is to look at the SHOWiT.  No, Lo120 doesn’t join the group.  Nevertheless, I wonder why I am not getting a ping off it.  It’s on the OIL for the group on CAT2.  Lets look at the RPF for the source 172.16.31.1:

CAT2#show ip route 172.16.31.1 
Routing entry for 172.16.31.0/24 
  Known via "ospf 7", distance 110, metric 20 
  Tag 120, type extern 2, forward metric 1 
  Last update from 172.16.23.2 on Vlan20, 01:41:14 ago 
  Routing Descriptor Blocks: 
  * 172.16.23.2, from 172.16.122.1, 01:41:14 ago, via Vlan20 
      Route metric is 20, traffic share count is 1

OK, it is expecting that source to come from 172.16.23.2, i.e. R2, but it is coming from R3.  How it knows it is coming from R3 instead of R2, I’m not really sure.  But let’s put in a static mroute and see if it works:

CAT2#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT2(config)#ip mroute 172.16.31.1 255.255.255.255 172.16.23.3 
CAT2(config)#^Z 
CAT2#

Try pinging from R1 again:

R1#ping 
Protocol [ip]: 
Target IP address: 227.7.7.7 
Repeat count [1]: 10 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y 
Interface [All]: FastEthernet0/0 
Time to live [255]: 
Source address: 
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort. 
Sending 10, 100-byte ICMP Echos to 227.7.7.7, timeout is 2 seconds: Reply to request 0 from 172.16.13.3, 8 ms 
Reply to request 0 from 172.16.234.4, 48 ms 
Reply to request 0 from 172.16.25.5, 28 ms 
Reply to request 0 from 172.16.36.6, 12 ms 
Reply to request 0 from 172.16.23.2, 12 ms 
Reply to request 1 from 172.16.13.3, 4 ms 
Reply to request 1 from 172.16.234.4, 64 ms 
Reply to request 1 from 172.16.234.4, 48 ms 
Reply to request 1 from 172.16.25.5, 32 ms 
Reply to request 1 from 172.16.25.5, 24 ms 
Reply to request 1 from 172.16.36.6, 12 ms 
Reply to request 1 from 172.16.23.2, 8 ms 
Reply to request 1 from 172.16.23.20, 8 ms 
Reply to request 1 from 172.16.23.2, 4 ms 
Reply to request 2 from 172.16.13.3, 4 ms 
Reply to request 2 from 172.16.234.4, 40 ms 
Reply to request 2 from 172.16.25.5, 24 ms 
Reply to request 2 from 172.16.36.6, 8 ms 
Reply to request 2 from 172.16.23.2, 8 ms 
Reply to request 2 from 172.16.23.20, 8 ms 
Reply to request 3 from 172.16.13.3, 4 ms 
Reply to request 3 from 172.16.234.4, 45 ms 
Reply to request 3 from 172.16.25.5, 24 ms 
Reply to request 3 from 172.16.36.6, 12 ms 
Reply to request 3 from 172.16.23.2, 8 ms 
Reply to request 3 from 172.16.23.20, 8 ms 
: 
:

Not first time, but OK once the shortest-path tree cuts in.  That was hard work!

Now, I wonder why the SHOWiT has configured bidir on R3 and R4?

At the end of the day, what are the lessons to be learned?

  1. Don’t configure the wrong interface!  Check show ip int brief regularly to make sure you configure the right one.  Do a show run int after each interface is configured.
  2. Check the PIM neighbor relationships one at a time as you build up the tree.
  3. Check the RPF back to the RP from every destination router.  This can be done by pinging the group from the RP interface of the RP router itself.  Any router that does not reply is likely either to have missed the join-group, or to have an RPF issue with the RP.
  4. Check for  FR multipoint interfaces.  If it is a sparse-mode secenario, put ip pim nbma-mode on the multipoint interface.  If it is dense-mode, build some tunnels so that there is a different logical interface to each neighbor.
  5. Ping from the source as specified in the scenario.  Several times.  One the PIM has settled down (after the second ping), check every router responds, and no router responds more than once.
Advertisements

Leave a Comment »

No comments yet.

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

Blog at WordPress.com.

%d bloggers like this: