MULTICAST OPERATION BETWEEN SPARSE & DENSE DOMAINS

[netops044]

Hi,

I have a location with a Cisco 1841 router consisting of two Fastethenet interfaces [Fa0/0 & Fa0/1]. Fa0/1 is used for LAN connecting machines and Fa0/0 for WAN . Multicast is enabled on the router.GRE tunnel is configured from this router to another domain that has multicast source servers. PIM-DENSE-MODE is configured on the LAN & GRE interfaces.

The other domain is completely running on PIM-SPARSE-MODE. The GRE tunnel coming from customer end to this domain is configured for PIM-SPARSE-MODE.Plz find my observations:

1) PIM neighborship over GRE tunnel is showing up.

2) The receivers are able to receive the multicast feed.

Now, is it possible for PIM neighborship to come up on when one is configured 'Sparse' and other as 'Dense'. Even then how is the multicast feed recevied from SPARSE to DENSE mode domain. Would sure appreciate if someone enlightens me on the minutae.

Also static RP is configured on the 1841. Why is the (*, G) entry with S flag generated if both my LAN & GRE interface are configured for dense-mode? Pasted below the 'show mroute' logs.

(*, 239.0.0.1), 01:27:57/stopped, RP 172.17.1.18, flags: SJC
  Incoming interface: Tunnel0, RPF nbr 172.17.210.101
  Outgoing interface list:
    Ethernet0, Forward/Dense, 01:27:57/00:00:00

(192.168.2.25, 239.0.0.1), 01:26:58/00:02:51, flags: JT
  Incoming interface: Tunnel0, RPF nbr 172.17.210.101
  Outgoing interface list:
    Ethernet0, Forward/Dense, 01:26:58/00:00:00

[Peter Paluch]

Hello,

If a link (including a point-to-point GRE tunnel) is configured with different PIM modes on each end, the PIM adjacency will come up but I doubt it will work appropriately without additional configuration. The PIM neighborship will be reported fine but I am not sure if the other messages (Join, Prune, Graft) will be processed accordingly. Because the logic of their usage is different in each PIM mode, I believe that without additional configuration, the multicast distribution will not work correctly.

The additional configuration can be done using ip igmp join-group and/or ip igmp static-group interface commands to force the interface to join a particular group via IGMP (the first command), or to simply become a valid egress interface (the second command). Are similar commands used in your configuration? Is it actually possible for you to post the configuration of the two routers interconnected over the GRE tunnel?

Regarding your question about the (*, G) entries: they are used as templates to instantiate source-based entries (S, G) at the moment a packet from a particular source S arrives, destined to the group G. They will always be present in the routing table but they will not be actually used to forward packets in PIM-DM mode.

Best regards,

Peter

[margalla]

Since you have an RP for 239.0.0.1 your router will still send a join across the GRE tunnel for that group so on the "SPARSE" side of the tunnel it looks just like any other sparse mode group and traffic will get forwarded down the tunnel.

If you adjust your RP mapping so 239.0.0.1 is not in it any more, then you should find you stop seeing the traffic and the "SPARSE" side of the tunnel doesn't see the group.

#
# 239.0.0.1 is in RP mapping.
#
router-4#
router-4#sh ip pim interface   

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
192.168.7.2      Ethernet1/1              v2/D   1      30     1      192.168.7.2
192.168.8.1      Ethernet0/0              v2/D   0      30     1      192.168.8.1
router-4#
router-4#sh ip pim rp mapping   
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 192.168.10.50 (router-3-lo10.mcast.mrg), v2v1
    Info source: 192.168.4.3 (hsrp-2.mcast.mrg), elected via Auto-RP
         Uptime: 00:00:42, expires: 00:02:28
router-4#
router-4#
router-4#sh ip mroute 239.0.0.1 
...

(*, 239.0.0.1), 00:13:49/00:02:10, RP 192.168.10.50, flags: SJC
  Incoming interface: Ethernet1/1, RPF nbr 192.168.7.1
  Outgoing interface list:
    Ethernet0/0, Forward/Dense, 00:13:49/00:00:00

router-4#
router-4#

# On the sparse mode side.

router-2#sh ip mroute 239.0.0.1
IP Multicast Routing Table
...

(*, 239.0.0.1), 00:01:43/00:02:46, RP 192.168.10.50, flags: S
  Incoming interface: Ethernet2/0, RPF nbr 192.168.6.1
  Outgoing interface list:
    Ethernet1/1, Forward/Sparse-Dense, 00:01:43/00:02:46

router-2#

#
# 239.0.0.1 is NOT in RP mapping.
#
router-4#
router-4#sh ip pim interface 

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
192.168.7.2      Ethernet1/1              v2/D   1      30     1      192.168.7.2
192.168.8.1      Ethernet0/0              v2/D   0      30     1      192.168.8.1
router-4#
router-4#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 192.168.10.50 (router-3-lo10.mcast.mrg), v2v1
    Info source: 192.168.4.3 (hsrp-2.mcast.mrg), elected via Auto-RP
         Uptime: 00:22:16, expires: 00:02:17
Group(s) (-)239.0.0.1/32
  RP 192.168.10.50 (router-3-lo10.mcast.mrg), v2v1
    Info source: 192.168.4.3 (hsrp-2.mcast.mrg), elected via Auto-RP
         Uptime: 00:07:36, expires: 00:02:16
router-4#
router-4#
router-4#sh ip mroute 239.0.0.1
IP Multicast Routing Table
...

(*, 239.0.0.1), 00:07:37/00:02:17, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/0, Forward/Dense, 00:07:37/00:00:00
    Ethernet1/1, Forward/Dense, 00:07:37/00:00:00

router-4#

# On the sparse mode side.

router-2#sh ip mroute 239.0.0.1
Group 239.0.0.1 not found
router-2#