Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

multicast issue - strange

hi guys,

i am facing very strange issue with multicasting.

All the router's interfaces are configured in "ip pim spare mode: . Now i have enable auto-rp feature (not BSR),

Without configuring "ip pim auto rp listener " , i am able to ping from source to receiver .i... ..how it is possible ??

Am i doing something wrong ??

Please help

Everyone's tags (3)
14 REPLIES

multicast issue - strange

Can you post:

sh ip mroute

From the RP and the receiver?

HTH, John *** Please rate all useful posts ***
New Member

multicast issue - strange

Here is the output from RP nd receiver :-

RP :-

#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.10.10.10), 00:01:53/00:02:35, RP 150.1.5.5, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:01:53/00:02:35

(155.1.0.1, 224.10.10.10), 00:01:51/00:01:10, flags: T
  Incoming interface: Serial4/0.100, RPF nbr 155.1.0.1
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:01:51/00:02:35

(*, 224.0.1.39), 00:21:24/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:21:24/00:02:41
    Serial4/1, Forward/Sparse, 00:21:24/00:02:55
    Serial4/0.100, 224.0.1.39, Forward/Sparse, 00:21:24/00:02:46

(150.1.5.5, 224.0.1.39), 00:21:12/00:02:50, flags: LT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial4/0.100, 224.0.1.39, Forward/Sparse, 00:21:12/00:02:46
    Serial4/1, Forward/Sparse, 00:21:12/00:02:55

(*, 224.0.1.40), 00:23:54/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:21:25/00:02:42
    Serial4/0.100, 224.0.1.40, Forward/Sparse, 00:23:54/00:02:48

(150.1.5.5, 224.0.1.40), 00:21:12/00:02:39, flags: LT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial4/0.100, 224.0.1.40, Forward/Sparse, 00:21:12/00:02:48

Receiver :-

#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.10.10.10), 00:04:21/stopped, RP 150.1.5.5, flags: SJPL
  Incoming interface: Vlan58, RPF nbr 155.1.58.5
  Outgoing interface list: Null

(155.1.0.1, 224.10.10.10), 00:00:07/00:02:56, flags: PLT
  Incoming interface: Vlan58, RPF nbr 155.1.58.5
  Outgoing interface list: Null

(*, 224.0.1.39), 00:16:38/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan58, Forward/Sparse, 00:16:20/00:02:12

(150.1.5.5, 224.0.1.39), 00:16:40/00:02:25, flags: PTX
  Incoming interface: Vlan58, RPF nbr 155.1.58.5
  Outgoing interface list: Null

(*, 224.0.1.40), 00:24:17/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan58, Forward/Sparse, 00:24:18/00:02:12

(150.1.5.5, 224.0.1.40), 00:16:45/00:02:14, flags: PLTX
  Incoming interface: Vlan58, RPF nbr 155.1.58.5
  Outgoing interface list: Null

multicast issue - strange

I labbed this up and I'm seeing the same thing that you are. When using auto-rp, the announce messages are sent to 224.0.1.39. The mapping agent listens on this group address and then floods the mapping messages to 224.0.1.40. All PIM routers are members of this group automatically.

In your mrouting table, you can see that

(*, 224.0.1.40), 00:24:17/stopped, RP 0.0.0.0, flags: DCL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    Vlan58, Forward/Sparse, 00:24:18/00:02:12

is in Dense Mode. The (*, 224.0.1.39) is also in dense mode. Interestingly enough, my RP has 224.0.1.39 and 224.0.1.40 as sparse mode whereas yours is in dense.

My first thought is that autorp listener isn't used any longer because the 224.0.1.39 and .40 is already listening in dense mode. I'm not using autorp listener on any of my routers and all of my interfaces are in sparse mode. I've yet to find documentation on if the behavior has changed between IOS versions though, but I have ran across a few comments that it seems as though it has.

I could see needing autorp listener if all of the SM interfaces were listed in Sparse mode for the .39 and .40 groups, but in this case they're not.

HTH,

John

HTH, John *** Please rate all useful posts ***
New Member

multicast issue - strange

Hey john,,

Good to see that my observation is correct.

But I hav't seen any cisco doc which says that autolistener is enabled by default or we do not need it any more..

Even if u have seen workbooks for CCIE lab preparation ,,, they also insists on configure "ip autorp listner"" to  make auto RP work with spare mode...

And i m using "-ADVIPSERVICESK9-M - 12.4 T vesion"" . Its not 15 which is newer one.

Most of the people use 12.4 T only... and in CCIE lab too cisco is using 12.4T ... then how it is possible.....strange?/:(

multicast issue - strange

I agree. Maybe someone else can verify or possibly suggest a topology to test this with. I've tested different ways and can't get a good scenario in which I need to enable the listener:

R1 (RP) -- R2 (non-rp) --- R3 (MA)

R1 (RP & MA) - R2 (nRP) -- R3 (nRP)

R1 (nRP) -- R2 (RP & MA) -- R3 (nRP)

In all scenarios, I get the RP mapping on the non-RPs without listener enabled. I could do this in a larger scale, but I would think the situation would come in the first scenario where I break the RP and MA roles between 2 routers. I'm going to do some research to see if I can find where this behavior has changed.

John

HTH, John *** Please rate all useful posts ***

multicast issue - strange

Okay...I got it to work...or fail...whichever way you want to look at it

I set up a router with version 12.3(23) because I've been seeing that 12.4T versions do not need this because it forwards the group by default. Even Cisco documentation doesn't mention this, but I've been able to prove it at least that 12.4x DOES work without the autorp listener and this earlier version does NOT.

The routers are set up like:

R1 (RP) ----- R2 (nonRP) ---- R3 (MA)

All are in SM, and here's the routing table: (Bolded are the important parts)

(*, 224.0.1.39), 00:04:19/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    FastEthernet0/0, Forward/Dense, 00:04:19/00:00:00

(1.1.1.1, 224.0.1.39), 00:01:06/00:01:53, flags: PTX

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1

  Outgoing interface list: Null

(*, 224.0.1.40), 00:04:59/stopped, RP 0.0.0.0, flags: DCL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    FastEthernet0/0, Forward/Dense, 00:04:59/00:00:00

(1.1.1.1, 224.0.1.40), 00:04:09/00:02:49, flags: PLTX

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1

  Outgoing interface list: Null

(192.168.23.3, 224.0.1.40), 00:04:16/00:00:55, flags: LT

  Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0

  Outgoing interface list:

    FastEthernet0/0, Forward/Dense, 00:04:16/00:00:00

Above is from R2. Notice that R1 (1.1.1.1) RP doesn't have an interface in the OIL. I enabled autorp listener and here's what it shows:

(*, 224.0.1.39), 00:00:40/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    FastEthernet0/1, Forward/Sparse, 00:00:40/00:00:00

    FastEthernet0/0, Forward/Dense, 00:00:40/00:00:00

(1.1.1.1, 224.0.1.39), 00:00:26/00:02:35, flags: T

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1

  Outgoing interface list:

    FastEthernet0/1, Forward/Sparse, 00:00:26/00:00:00

(*, 224.0.1.40), 00:01:05/stopped, RP 0.0.0.0, flags: DCL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    FastEthernet0/1, Forward/Sparse, 00:01:05/00:00:00

    FastEthernet0/0, Forward/Dense, 00:01:05/00:00:00

(1.1.1.1, 224.0.1.40), 00:00:31/00:02:35, flags: LT

  Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1

  Outgoing interface list:

    FastEthernet0/1, Forward/Sparse, 00:00:32/00:00:00

Now it forwards the 224.0.1.39 group information to R3 which is out fa0/1. When I had R1 configured as the mapping agent and the RP, both routers did see it as the mapping agent. The reason this happens is because all PIM routers are members of 224.0.1.40, so with R2 being directly connected to R1, R1 could send (because it was the MA as well) out to R2 which then floods it to 224.0.1.40 which R3 is a member of.

HTH,

John

Please rate all useful posts....

HTH, John *** Please rate all useful posts ***
New Member

multicast issue - strange

Nice to see john that ...our assumption is correct for 12.3 versions...... But my mind can't accept how its working with..

12.4 ....

Anyways thks for ur observation nd testing.... may be we should wait for someone else and share thier observation...

Re: multicast issue - strange

Guys I would like to know if you got it to work with 4-5 routers in a row.

E.g. R1 (Lo0 as RP&MA, receiver) -------R2-----------R3----------R4-----------R5 (Source)

i.e

In the above topology I got the the rp mapping till R2 but R3.R4.&R5 were not aware of RP although they were listening on 239.0.1.40.

Once I enabled "ip pim auto-rp listener" on R2,R3,R4,&R5 the RP information got propogated. R5 is not required to have "ip pim auto-rp listener"

1] The reason which I suspect behind this is even though routers are listening to 239.0.1.40 they are not propogating the RP information, they are just listening to it.

2] When ip pim auto-rp listener is enabled they not only listen but also now propogate the RP information "debug ip pim auto-rp" , "debug ip pim " etc.

3] If you just have 3 routers namely R1, R2 & R3 then "auto-rp listener" is not required considering R1 is RP and MA, R2 learns the information directly from RP, R3 is source (stub), so in that case it works.

Please let me know if you guys agree with what I think.

Thanks,

Nandan Mathure

New Member

Re: multicast issue - strange

Hi nandan,

good points and tests

You may be correct with  the assumptions u r drawing with ur test results ..

But have u tried keeping MA & RP on different router and then check .... because in my solution they are diffrent...

Re: multicast issue - strange

Thanks Shekhar Ok I will first consider just 4 topology to prove my point with different combinations of RP and MA.

A] 4 Routers , R1 is RP and R3 is a MA

1] R1 's Lo0 is RP configured using "ip pim send-rp-announce"

2] R2 and R4 are non-rp, non-ma

3] R3 's lo0 is MA configured using "ip pim send-rp-discovery"

4] Checked "show ip pim rp mapping" on all the four routers with no required output.

5] "debug ip pim auto-rp" enabled on all routers and enabled "ip pim auto-rp listener" on R2 only and things started moving.

6] RP infomation propaged on all 4 routers.

B] 5 Router Topology --> R1 = RP & R2 = MA

1] R1 is a RP

2] R2 is a MA

3] R3 learns rp information from R2 but doesnt propogate it to R4 and inturn R5 has no clue.

4] When "ip pim auto-rp listener" is enabled on R3 , R3 forwards RP information to R4, thus R5 as a source can use this information to send traffic or R5 also needs auto-rp listener to further propogate the RP information if we connect more routers.

C] 4 Routers R1 = MA & R2 = RP

1] R1 = MA

2] R2 = RP

3] No RP information observed on R3 & R4

4] 'ip pim auto-rp listener" enabled on R2, R3 and which helped R3 and R4 to have the RP information.

Hope this makes the reason clear to have "ip pim auto-rp listener" command when PIM sparse mode is configured as opposed to PIM sparse-dense mode.

Please rate the usefull posts

Thanks,

Nandan Mathure

New Member

Re: multicast issue - strange

Great Nandan,

You really resolved this mystery.....

So its clear now that my toplogy and test results shared by John , listner command is not required since ther are few routers.....,

So the assumption we can draw here is that , it realy depneds on the toplogy , no. of routers , selection of RP & MP to decided wheather we need listner command or not ...But it is best practice to enable it on all the routers to avoid any issue later.

i have on more doubt ,  r u shore that u have configured loopback of RA & MA in spare mode.??

What I think is that, the source interface of RA & MA should be configured in dense both ,, because 224.0.1.39 &  224.0.1.40 works in dense ,mode only  . So RA & MA communicate in dense and all other is spare when listener command is use.

Correct me if i am wrong.

Re: multicast issue - strange

I relabbed this up with 5 routers spread out and using 12.4T. It does still require the autorp listener. You don't need autorp listener configured if you're using sparse-dense mode.

HTH, John *** Please rate all useful posts ***

multicast issue - strange

If we configure sparse-dense mode then RP information is forwrded out all interfaces using dense mode. In my examples all interfaces including loopbacks were sparse mode only.If we have sparse-dense mode then auto-rp listener is not requied.

Thanks,

Nandan Mathure

multicast issue - strange

Hi Shekhar,

Please rate the useful posts by contributors and mark the question as answered if the no further queries.

Thanks,

Nandan Mathure

1547
Views
0
Helpful
14
Replies
CreatePlease to create content