I'm new to multicast. I'm working on a simple topology as follows and just use pim-dm on all interfaces. I statically joined the loopback interface on R6 to group 224.1.1.1. but routers are joined to "24.0.1.40" that are expected to seen on pim-sm networks and even I can see another entry as "(*,224.1.1.1) on routers. why these 2 groups are created whereas I used just pim-dm on all routers?



R5(config-if)#do sh ip mroute
(*, 224.1.1.1), 00:01:59/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:01:59/00:00:00

(8.8.8.7, 224.1.1.1), 00:00:26/00:02:33, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 5.5.5.8
Outgoing interface list: Null

(5.5.5.8, 224.1.1.1), 00:01:59/00:01:00, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 224.0.1.40), 00:24:13/00:02:20, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:24:13/00:00:00

_________________
ciscoworlds.com
timaz mohsenzadeh

It's just Cisco's way of doing things. They are ALWAYS there

_________________
www.mellowd.co.uk/ccie/

so isn't there any explanation for this behavior? we learn that (*.G) is for pim-sm. if anything else appears, there must be a explanation.

_________________
ciscoworlds.com
timaz mohsenzadeh

The explanation is that on a Cisco router it's always there with IPv4, regardless of what version of PIM you are running.

They always seem to listen for Auto-RP, regardless of whether you are running a pure in pure dense mode

_________________
www.mellowd.co.uk/ccie/

what about other (*.G) entries on pim-dm network? it seems that cisco uses pim-sm always, regardless our configs? .... I'm really confused!

_________________
ciscoworlds.com
timaz mohsenzadeh

No, it is using dense mode however as mellowd has said you will always see the entries for the Auto-RP.

You will have the (*,G) entries on the router that is requesting the feed however you shouldn't see it any further up the network.

_________________
---
David
CCIE R&S #38338, CCIP, CCNP

http://networkbroadcast.co.uk - My Blog
http://twitter.com/davidrothera

I started a ping test to 224.1.1.1 on R7 and then issued "sh ip mroute" command on R8. the abbreviated output is as follows:

(3.3.3.3, 224.1.1.1), 00:00:17/00:02:42, flags:
Incoming interface: FastEthernet0/1, RPF nbr 2.2.2.3
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:00:18/00:00:00
Serial0/0, Forward/Dense, 00:00:18/00:00:00

(2.2.2.3, 224.1.1.1), 00:00:18/00:02:54, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Prune/Dense, 00:00:18/00:02:45
Serial0/0, Forward/Dense, 00:00:18/00:00:00

with regard to the fact that R7 can reach to 224.1.1.1 through F0/0, so what's the meaning of "(2.2.2.3, 224.1.1.1)" and nbr 0.0.0.0 in the output above?

_________________
ciscoworlds.com
timaz mohsenzadeh

It's handy to put the interface names on the image you posted above

_________________
www.mellowd.co.uk/ccie/

now here are the names:

_________________
ciscoworlds.com
timaz mohsenzadeh

another issue:

I forced another ping test from R7 to 224.1.1.1 (that reside on loop 0 of R6) but determine the loop 0 of R7 (77.77.77.77/32) as ping source. relevant portion of "sh ip mroute" on R8 are as follows. I think the entries must be (77.77.77.77, 224.1.1.1). but 2.2.2.3 and 3.3.3.3 that are IP addresses of fast0/0 and fast0/1 of R7 are displayed as source! what is explanation for this output?

(3.3.3.3, 224.1.1.1), 00:00:11/00:02:48, flags:
Incoming interface: FastEthernet0/1, RPF nbr 2.2.2.3
Outgoing interface list:
Serial0/0, Forward/Dense, 00:00:13/00:00:00
FastEthernet0/0, Forward/Dense, 00:00:13/00:00:00

(2.2.2.3, 224.1.1.1), 00:00:13/00:02:54, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, Forward/Dense, 00:00:13/00:00:00
FastEthernet0/0, Prune/Dense, 00:00:13/00:02:48

_________________
ciscoworlds.com
timaz mohsenzadeh

Let me clear this up ...

1) First, dense mode sucks for tons of reasons -- don't use it. I absolutely hate vendors that use this. It really isn't hard to setup a proper PIM-SM/MSDP anycast RP topology. I understand you're learning multicast so I won't yell at you anymore

2) As it has been said, 224.0.0.40 is auto-rp (discovery). It wouldn't be very automatic if it wasn't enabled by default, so that's why it is always there. It will only go across dense mode/sparse-dense mode enabled interfaces. If you want to use auto-rp but don't want to use sparse-dense mode, use "ip pim autorp listener". This will forward auto-rp messages across sparse mode interfaces (to be more technical, it turns on dense mode only for 224.0.0.39 and .40 and forwards on all PIM interfaces)

3) You won't have an RPF neighbor if the source route for that (S,G) doesn't have a valid PIM neighbor on it. Also, if you are doing "sh ip mroute" on the router with the attached source (your ping), there wouldn't be an RPF neighbor since it is itself.

4) The (*,G) entry for PIM dense mode isn't actually used for any traffic forwarding like it is in sparse mode. It's more of an accounting thing. If you received any traffic for that group, all dense mode interfaces in the OIL would also receive a copy. If you look at the output from your first post, you'll see "stopped" on the (*,G) since it is never used for forwarding.

4b) Now you'll ask why the (S,G) OILs don't line up with the (*,G) OILs. That's because, like I said, the (*,G) is used for accounting. Notice in your first post you have "P" for pruned on your (S,G) routes. You can prune the (S,G) route, but then dense mode will flood that again to all OILs in the (*,G) unless you configure state-refresh. Since they don't match in your first post, that would normally mean the router on Fa0/0 sent a prune to R5. However, since R5 is a stub, it actually sent the prune to R8 since it has no (S,G) OILs for that group.

5) Not being able to source multicast pings from loopbacks is a known IOS limitation, that's all I'll say about it for now. Honestly, in production, I never needed to use this anyway, nor does anyone.

That should answer all your questions.

wow! man you did great with your detailed answer thanks a lot.

_________________
ciscoworlds.com
timaz mohsenzadeh