Subject: RE: Encapsulation of packets from non-directly connected hosts in PIM -SM

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 17 May 2001 19:44:13 -0400

> All,
> I was trying to better understand the motivation behind only 
> allowing encapsulation of packets from directly connected 
> hosts. Are there reasons other than security concerns for 
> making this restriction? The new revised draft seem to state 
> this in section 4.3.1. Is this the correct interpretation, or 
> am I mis-reading the draft? 
> 
> I guess my point is that if there is a non-PIM capable router 
> directly connected to the sender, and if the packets are 
> being sent into a PIM domain, does it (the first router 
> running PIM in the path of the multicast flow) now not have 
> to encapsulate the packets? Specifying that register state 
> must only be maintained for directly connected hosts makes it 
> seem like restricting such a design. 

  I havent read the new revised draft yet, but if thats the 
  case then that seems to be a problem for PIM border routers
  (if RP is not the border router itself). PIM border router
  should register encapsulate the data and send it to RP. 
  Recipients in the PIM domain wont be able to receive the 
  data otherwise.

  - Ravi Shekhar.

---

From: Marian Stagarescu <[email-masked]>
Date: Thu, 17 May 2001 21:22:26 -0400 (EDT)

i have the following "flooding" problem.
i hope someone may help me configure it properly
to prevent it.

configuration:

Mrouted---PimSM (cisco)--- MulticastSource.

In this scenario, the next-hop (nexthop to the MRD) PIM router forwards all
mcast traffic present on its McastSource interface to the MRD. 

When a MRD comes up it sends a DVMRP Probe to determine where its
neighbors are located. When PIM receives this Probe it turns on "PIM-DVMRP
Interoperability". This cause the PIM router to forward all mcast traffic it
sees to the MRD.

how can I stop this ?
preferably via mrouted.conf since I don't have access
to PIM-SM router config.

thanks,
marian

---

From: Beau Williamson <[email-masked]>
Date: Fri, 18 May 2001 09:18:01 -0500

>preferably via mrouted.conf since I don't have access

The only way I'm aware of (without changing the Cisco config) is to disable the interface in the Mrouted.conf file thereby turning of DVMRP on that interface.  (That's the only way to stop it from sending out DVMRP Probes.)  Of course that stops multicast to/from that interface so that's probably not what you want.

You really need to configure a dvmrp accept-filter on the cisco router to stop it from seeing/paying attention to the DVMRP router.  (See below.)

    [no] ip dvmrp accept-filter <access-list> [neighbor-list <nbr-acl>]
                                [<distance>]
        Configures an acceptance filter for incoming DVMRP Reports. Any 
        destinations that match <access-list> received in DVMRP reports 
        from neighbors in the <nbr-acl> are stored in the DVMRP routing table 
        with <distance>. The distance is used to compare with the same 
        destination in the unicast routing table. The lower distance route 
        (either from the unicast routing table or DVMRP routing table) will 
        take precedence when computing the RPF interface for a source of a 
        multicast packet. When no filters are configured on an interface, all 
        destinations are accepted with distance configured from the "ip 
        dvmrp distance" global command. An <access-list> value of 0,
        accepts all destinations. <access-list> can be a simple or extended
        access-list. If extended access-lists are used, you have both address
        and netmask granularity. An <nbr-acl> value of 0 means accept from 
        all neighbors on interface. [10.2]

Beau Williamson

---

From: Marian Stagarescu <[email-masked]>
Date: Fri, 18 May 2001 15:43:59 -0400 (EDT)

I did more verification on this and still appears to be an
interoperability problem:

  mrouted(mrouted-3.9beta3+IOS12) ----- cisco(2514, IOS 12.05T) ----multicast-source

  I see the mrouted sending Prune msgs but the traffic continues to flow
  from cisco to mrouted.

  (I'll follow up with a dump of the mrouted prune msgs., believe me, they
   are going on the wire).

  I found the follwing will work:

  I set mrouted to deny 0/0 on the interface facing the router.
  This stops the flooding.

  Moreover my inclusive scenario is as follows:

  my_multicast_src --- mrouted ---- cisco ---- end_users_for_my_source
                                      |
                                      + other_multicast_src

  What I want:
  0) my_multucast_src sends traffic but mrouted stops it (no listener for
     it yet)
  1) end_users_for_my_source send IGMP for my_multicast_src(group)
  2) igmp request is passed to mrouted from cisco
  3) traffic flows from (my_multicast_src) to (end_users_for_my_source)

  AT THE SAME TIME:

  I do not want to get at (mrouted) the traffic from (other_multicast_src)
  my Mrouted (mrouted-3.9beta3+IOS12) sends PRUNE msgs for these groups.

  If I do not put deny as explained above cisco will pass to mrouted this
  unwanted traffic.

  deny seems to work since 

  -affects only the input on interface facing cisco.
  -does not apply to the other interface facing (my_multicast_src)
  -when traffic is forwarded from (my_multicast_src) to the interface
   facing (cisco) is going to be an output for this interface so
  "deny" should not filter it.

But I would be extremely interested to figure out why the Prunes are not
processed by Cisco.

thanks a lot.
marian stagarescu