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

(S,G) and (*,G) OILs

Hi,

I want someone to clarify this behavior to me.

There is a general rule (as per the author's Developing IP Multicast Networks book) says "When a new (S,G) entry is created, its OIL is initially populated with a copy of OIL from its parent (*,G) entry for the group".

I think this rule applies more in dense mode. However, in sparse mode, this rule applies only IF a router has legs to both RPT and SPT (or diverge). Other PIM-SM routers will have different OILs in their (*,G) and (S,G) OILs.

Correct me if i am wrong.

Regards,

AM

7 REPLIES
Cisco Employee

(S,G) and (*,G) OILs

Hello,

I have a feeling that the author of this book  described Cisco's implementation of multicast routing in particular. It  is true that Cisco routers always keep the (*,G) entries in their mroute  table, even with PIM-DM which theoretically should not at all need  these entries.

I think this rule applies more in dense mode. However, in sparse mode,  this rule applies only IF a router has legs to both RPT and SPT (or  diverge).

Well,  I would say quite the converse: that this rule applies primarily in  sparse mode. Note that in dense mode, you can hardly have the (*,G)  entries before the first multicast packet arrives, because

  • except routers having directly connected receivers via IGMP, other routers do not even know what the multicast group is
  • even if the routers knew what the group is, they have no clue who  the sender might be and thus the OIL is impossible to construct (an  interface might be in OIL for one sender and a RPF interface for the  other)
  • when routers in dense mode receive the first packet, they can  immediately construct a (S,G) routing table entry because they have all  information both about the sender and the group from the multicast  packet

It would be more logical, thus, that this rule applied to sparse mode. I would not personally worry about the 'IF' condition you  have specified. Note a particular fact: in PIM-SM, when a particular router switches over from shared tree to source tree, only the RPF interface changes, however, the OIL should remain the same (for the last router before the final receiver that starts the switchover to the shortest tree), or is even extended by an interface that received the PIM Join message with WC and RPT bits cleared (the (S,G) Join). Therefore, copying the OIL from (*,G) to (S,G) is a logical thing to do.

Best regards,

Peter

New Member

Re: (S,G) and (*,G) OILs

Hi Peter,

Thx for your kind reply as usual.

It  is true that Cisco routers always keep the (*,G) entries in their mroute  table, even with PIM-DM which theoretically should not at all need  these entries.

Well, i am not concerned if the PIM-DM need the (*,G) entry or not. I completely understand that PIM-DM doesn't use this entry at all for multicast forwarding. The reason i said that the rule applies more for PIM-DM because the entry is just a decoration and used only to list all the directly connected neighbors or group members in its OIL and the (S,G) entry inherits its OIL from it. At this point, it is obvious that the rule is applied more here.

Note that in dense mode, you can hardly have the (*,G)  entries before the first multicast packet arrives, because

  • except routers having directly connected receivers via IGMP, other routers do not even know what the multicast group is
  • even if the routers knew what the group is, they have no clue who  the sender might be and thus the OIL is impossible to construct (an  interface might be in OIL for one sender and a RPF interface for the  other)
  • when routers in dense mode receive the first packet, they can  immediately construct a (S,G) routing table entry because they have all  information both about the sender and the group from the multicast  packet

Actually, you don't need to have any entries created (even the (S,G) also) before any multicast packets arrive as it doesn't make sense and is against the dense mode nature. The dense mode (*,G) entry is created automatically when the (S,G) entry is created (of course, in response to a received multicast packets) because there is another general rule says "Whenever a (S,G) entry is created and its corresponding (*,G) entry doesn't exist, the second is created automatically". 

It would be more logical, thus, that this rule applied to sparse mode. I would not personally worry about the 'IF' condition you  have specified. Note a particular fact: in PIM-SM, when a particular router switches over from shared tree to source tree, only the RPF interface changes, however, the OIL should remain the same (for the last router before the final receiver that starts the switchover to the shortest tree), or is even extended by an interface that received the PIM Join message with WC and RPT bits cleared (the (S,G) Join). Therefore, copying the OIL from (*,G) to (S,G) is a logical thing to do.

Ahhhh .. now i see a good answer to my question.

This means i was correct when i said a router has 2 legs one for RPT and one for SPT (Point of Diverge) applies the rule of copying the (*,G)'s OIL to (S,G)'s OIL because as you said the OIL should remain the same. Good!! thank you for that.

About my "IF" condition.

Even though it is confusing to use a conditional "IF" early in my question, you should worry about it very much because it is actually the heart of my question but you didn't notice that.

Let me explain.

Because my question is regarding this rule, i tried to construct my own rule about on "WHICH" router(s) to apply this rule in both modes, such as the following:

1- In dense mode, rule applied to all routers. (since (*,G) used only to populate its child (S,G))

2- In sparse mode, rule is applied only on a router IF it has one leg for RPT and one leg for SPT. (i am not sure if this rule is applied to the rest of the PIM-SM routers)

Please let me know if i clarified my question to you. If it's not clear yet, then i will post a practical scenario in my next reply.

Regards,

AM

Cisco Employee

Re: (S,G) and (*,G) OILs

Hello,

You are a fine debater

The reason i said that the rule applies more for PIM-DM because the  entry is just a decoration and used only to list all the directly  connected neighbors or group members in its OIL and the (S,G) entry  inherits its OIL from it.

I apologize but I do not see the logic of this statement. How can in DM the "decoration" entry (*,G) be used to populate the child's (S,G) OIL list if it does not exist at all before the first multicast packet arrives, and after the first multicast packet arrives, the (S,G) OIL list is immediately and easily constructed as the set of interfaces except the RPF interface that

  • either have receivers registered via IGMP
  • or connect to other PIM-DM neighbors

without ever needing to refer or create the (*,G) entry?

Actually, you don't need to have any entries created (even the (S,G)  also) before any multicast packets arrive as it doesn't make sense and  is against the dense mode nature.

I have never indicated anything different. I merely pointed out that (*,G) are both impossible to construct before first multicast packets arrive, and useless after the first multicast packet arrives and (S,G) is constructed.

Regarding my extensive comments about the (*,G) and dense mode: I wrote them because you mentioned the dense mode and (*,G) in the same place, and we both agree that the dense mode has no use for these mroute entries, so I felt that mentioning those two things together is misplaced. Now, the book you're reading may say things like "Whenever a (S,G) entry is created and its corresponding (*,G) entry doesn't exist, the second is created automatically" - but from a principial point of view, this is an irrelevant information: as already mentioned, the principial dense mode has no use whatsoever for (*,G) entries, not for populating OIL lists nor for anything else. If Cisco routers do that, fine, but that's implementation-specific behavior that should not be considered representative of the elementary principles. And as you know, I always focus on principial views, not on implementation-specific behavior.

I apologize but I am afraid I still do not entirely get the point of your question regarding the IF branch Perhaps the practical example would help me understand better - I apologize again, and thank you!

Best regards,

Peter

New Member

Re: (S,G) and (*,G) OILs

I wish i am a debater in a good way though. ... Sorry for being not clear.

I will post the scenario tomorrow because i am currently busy re-locating my furniture to my new house.

Thank you so much man

Regards,

AM

New Member

Re: (S,G) and (*,G) OILs

Hi Peter,

You know what! This rule isn't true in sparse mode. I  just performed a couple of tests and noticed this rule isn't applied in  many situations in sparse mode. However, it is applied in dense mode  correctly. Therefore, the author should call it a dense rule not a  general rule. General rule means it applied in both modes.

So, i won't bother discussing a practical scenario. Everything is obvious now.

If you have this book and have time, please open page 196 and read General Rule 3.

Thanks for your time and your kind detailed explanation.

Regards,

AM

Cisco Employee

Re: (S,G) and (*,G) OILs

Hello,

You are welcome... but... now I am totally stumped! You are telling me that your observations are absolutely contrary to what I stated here.

I have snatched a copy of that book and will try to give it a read in a few days. Please be prepared that I may come with a florid apology and withdrawal of what I wrote here if I am proven wrong, which happens every so often.

For now - treat my comments as describing only the principles but not the implementation. Implementation may differ wildly, and it seems this is going to be the case... but I will be able to tell more only after going through that book.

I apologize in advance if I spread misinformation up to this point.

Best regards,

Peter

New Member

Re: (S,G) and (*,G) OILs

Peter,

No, i don't have any opposite or contrary observations with what you stated because after all i am still learning this stuff and you have experience more than me indeed, so it's impossible to argue with a specialist. About the debating thing, i didn't mean to be a fatal debater in order to prove you're wrong by any means (unfortunately few people think like that). Instead, i normally use words which are their main purpose is to understand a certain logic. These words sometimes takes the form of debating but i really didn't feel that i was debating. I absolutely have nothing against you. On the other hand, i respect you very much for the following reasons:

1- Providing a detailed explanation with examples.

2- Patiency.

3- Responding fast.

4- Always use smiley emoticons which describes how friendly you are.

Sadly, some experts here just throw an answer in 4 or 5 words maximum without a detailed explanation which i find it somehow an ignorance to my question or thread in the first place and sometimes i find it offensive. ... No hard feelings! but it's true.

Please don't forget to take a look at this rule in the page i mentioned. At this point, however, i am not going to accept an answer as a permanent solution to my question until new ideas show up.

Thank you again man.

Regards,

AM

492
Views
0
Helpful
7
Replies
CreatePlease to create content