08-02-2024 03:17 PM - edited 08-04-2024 09:32 AM
I have some questions about multicasting that I haven't been able to find answers for. We have a full functional multicast setup using PIM sparse-mode with ASM and a static RP, and MSDP peering.
Everything is working well, but I just need clarification on a few commands to understand if they are necessary and their use.
1. Is it necessary to enable multicast routing on the main routing table if I am only using multicast on specific VRFs?
2. Does the "show ip mroute" command display output only when the router is connected to a multicast source or receiver? I.e, if there is no multicast traffic passing through the router, will the output of this command be almost empty?
3. What is the purpose of the commands in bold font, and are they needed for ASM?
vrf definition Multicast_VRF
address-family ipv4
mdt default 235.5.0.0 => is this needed for ASM? and why?
mdt data 235.5.1.0 0.0.0.255 threshold 100 => is this needed for ASM? and why?
4. If MDT is needed, what commands can be used to display which MDT is/are being used?
5. How many PIM neighbors can an ASR-1001x router have?
6. Is the "ip pim ssm default" command required for an ASM setup, and what does it do?
7. Is there an equivalent command in multicast for the unicast command "maximum routes 10000 80 reinstall 90"?
Thank you!
Solved! Go to Solution.
08-04-2024 10:33 AM - edited 08-04-2024 10:36 AM
Hi @Ab26 ,
1. mVPN has two multicast domains. The customer domain and the core domain. When customer multicast traffic is received in the core, it is encapsulated in a multicast GRE tunnel and delivered to some or all the participating PEs depending of whether the data or default MDT is used for a specific multicast stream. So the answer to your question is yes, multicast is required to be configured in the core as well (either ASM or SSM).
2. In the core the default MDT will be signaled by default, so yes the "show ip mroute" for the core domain will contain information pertaining to the default MDT even if there are no active flows in the customer multicast domain.
3. The first command determines the multicast address for the default MDT and the second one determines the data MDT multicast address range. And yes, they are needed either you configure ASM or SSM.
4. "show ip mroute <vrf name>" will give you the inbound and outbound interface. The outbound interface will be the tunnel interface for the default or data MDT.
5. There is most certainly a limit, but no hard limit that I know of.
6. This command is not needed for ASM, only for SSM.
Regards,
08-02-2024 05:29 PM - edited 08-02-2024 05:39 PM
Hi @Ab26 ,
You need to deploy multicast in the VRF for the customer and also for the global routing table in the core.
> When I issue the "show ip mroute" command, I don’t see any of these mdt. I only see the multicast group > configured by our team, which is 239.10.10.X.
Have you configured the BGP address family ipv4 mdt?
> Is there a limit on the number of PIM neighbors a Cisco router can have?
There is certainly a limit, but no hard limit that I know of.
> When can I expect to see output from the "show ip mroute" command on routers with multicast sources or > receivers? Will there be output if no multicast sources or receivers are connected to the router?
In the default multicast routing table, you should at least see the multicast address for the default MDT.
In the VRF multicast routing table, you should only see the multicast addresses if there are senders and/or receivers.
Regards,
08-03-2024 02:59 AM
Thanks @Harold Ritter for your reply!
Our set up is like this:
MSDP Route-reflectors => Core => distrubtion routers => Access routers
Core is in the MPLS cloud with no VRFs and no multicast routing, only PIM in all MPLS interfaces (global routing table)
=> so PIM tunnels are created between distrubtion routers
MSDP Route-reflectors have BGP with MDT with the the distrubtion routers
MSDP Route-reflectors and distrubtion routers are MSDP peers
MSDP Route-reflectors and distrubtion routers are in MPLS cloud
MSDP Route-reflectors, distrubtion routers and Access routers have multicast routing enabled for the VRF
There is certainly a limit, but no hard limit that I know of. =>
Is there a way to know that for sure? I looked at Cisco device specification (Data sheets) but nothing mentioned there about any limit for multicast for ASR1001.
I found some info for ASR920
A maximum of 20 multicast VRFs are supported.
A maximum of 255 OIFs are supported.
And for Nexus 9000
Maximum number of PIM Neighbors 1,000
Maximum number of PIM Neighbors per VRF 64
Maximum number of L3Out physical interfaces with PIM enabled 32
In the default multicast routing table, you should at least see the multicast address for the default MDT.
=> no unfortunately, I see groups with 239.10.10.X. but not with MDT
08-03-2024 04:34 AM
Hello
You mention Route Reflectors/ASM which suggest this is an iMBGP Mcast pim spare-mode design
Can you elaborate on your topology, maybe share a diagram showing the Mcast source/receivers and Rp's?,
As for MSDP, you do not mention how the peering is being applied, are you using the same peer addressing as the iMBGP or different.
Do you actually obtain an established MSDP peering and if so do you see successful sa-ache entries?
08-03-2024 07:44 AM
Thanks Paul!
It's correct as you wrote. Unfortunately I don't have a diagram on hand at the moment. But, we are using PIM sparse-mode, with Any Source Multicast (ASM) and static RP. The same IP address of RP is configured on multiple distribution router. Each distribution is considered a Multicast domain. Each domain can have Multicast sources and receivers. Multicast is allowed between the domains that's why we are using MSDP. The MSDP peering is fully functional with SA running between the peers (interdomains).
My confusion is only about the need of MDT and its use on ASM. I think MDT is only used in SSM, but not sure
Second, question was in some places the output is almost empty when I run the (show IP mroute). Does a multicast source or receiver need to be connected to a router for this show command to display output?
Lastly, about the limitation for router ASR-1001x
08-03-2024 11:57 AM
Hi @Ab26 ,
Which mVPN profile are you deploying?
You should have multicast routing configured in the core as well. This would include configuring an RP if you are configuring ASM. RP would obviously not be required if you configure SSM for the default and data MDT.
Regards,
08-04-2024 05:26 AM - edited 08-04-2024 05:41 AM
Thanks @Harold Ritter for your reply!
We are using Profile 0 Default MDT - GRE - PIM C-mcast Signaling. As for the core, i meant the MPLS cloud. We don't configure VRFs nor multicast routing. We have only PIM enabled on all involved interfaces.
We are using ASM and static RP.
Do I understand from your sentence "SSM for the default and data MDT" is that default and data MDT are only used for SSM?
If so, does this mean that in our case, where we are using ASM, there is no need for the default and data MDT?
So under the vrf definition we can remove mdt default and data
vrf definition Multicast_VRF
address-family ipv4
mdt default 235.5.0.0 => has no effect?
mdt data 235.5.1.0 0.0.0.255 threshold 100 => has no effect?
I'm confused between MDT and multicast group
08-04-2024 07:33 AM - edited 08-04-2024 07:37 AM
Hi @Ab26 ,
> We don't configure VRFs nor multicast routing.
Do you mean that you do not have multicast routing for the global routing table? You need to have multicast routing on the core routers as well. You also need to configure the RP for the core routers.
> Do I understand from your sentence "SSM for the default and data MDT" is that default and data MDT are only used for > SSM?
Sorry for the confusion. I see that you are using ASM for default and data MDT. I was only suggesting that SSM could be used as well.
> So under the vrf definition we can remove mdt default and data
No, this is required.
Regards,
08-04-2024 09:41 AM
Thanks @Harold Ritter !
Think of the core just as tunnel nothing more in our network. We don't configure VRFs in the core devices, no BGP, no multicast, just PIM and IGP routing like OSPF.
I have updated the initial post. I'd appreciated if you can answer any of the questions i wrote their. And I'm happy to explain out set up with configuration if that would be beneficial for anyone who looking to set a PIM-SM with ASM, static RP and MSDP peering !
08-04-2024 04:38 AM - edited 08-04-2024 04:44 AM
Hello
Assumption is you are not an ISP so do not have any control of the MPLS cloud however PIM is activated within the MPLS cloud for you as the customer?
Now pim needs to be enabled throughout the network path between Mcast source/receivers in & out of the mpls cloud basically
As you mention MSDP then this seems to suggest your using PIM-SM with either static /dynamic RP registration, so can you confirm what mode of pim is being used? (SM/SSM/BIDIR).
With this in mind, the basic step Mcast establishment thereafter should entail from the first hop rtr (FHR) you see a creation of an automatic pim logical tunnel created upon a successful RP mapping to its designated RP, This is used to send encapsulation Mcast traffic towards the RP., if this reached the RP you'd see in the Mrib a Mcast Source/Group (S,G) state example = (10.1.1.1,235.5.1.1)
From the receiver perspective, the last hop router (LHR) that has attached Mcast receivers, it will receive igmp membership requests from hosts stating they it wish to receive Mcast for a particular group, in turn the LHR sends a pim join upstream towards it own designated RP for any source,group (*,G) example = (*,235.5.1.1.) you should see this on all the pim enabled rtrs upstream towards the RP
At this point the RP should have enough information (10.1.1.1,235.5.1.1) & (*,235.5.1.1.) to begin sending Mcast downstream towards the Mcast receivers.
....However if you have multiple RPs in the network with the FHR/LHR using different RPs then this is possibly where there is missing Mcast source/group state information that needs to be "shared" between those Rps for Mcast traffic to be successfully transmitted
This "sharing" or replication of the Mcast state information can indeed can be accomplished using MSDP. but for this to work successfully you need to create the MSDP peering which could be either internal/external to your routing domain.
TBH I have never performed MSDP in mVPN environment and looking at cisco cco documentation it recommends SSM to be used which would negate using MSDP altogether as stated by @Harold Ritter
08-04-2024 05:36 AM - edited 08-04-2024 05:38 AM
Thanks @paul driver !
Well, we are an ISP
I don't have a problem with the MSDP set up. My question was about the need or use of MDT default and data which are configured under VRF definition.
In this set up we are using PIM sparse-mode with ASM and static RP. The MSDP allows inter-domain RP communication.
08-04-2024 10:33 AM - edited 08-04-2024 10:36 AM
Hi @Ab26 ,
1. mVPN has two multicast domains. The customer domain and the core domain. When customer multicast traffic is received in the core, it is encapsulated in a multicast GRE tunnel and delivered to some or all the participating PEs depending of whether the data or default MDT is used for a specific multicast stream. So the answer to your question is yes, multicast is required to be configured in the core as well (either ASM or SSM).
2. In the core the default MDT will be signaled by default, so yes the "show ip mroute" for the core domain will contain information pertaining to the default MDT even if there are no active flows in the customer multicast domain.
3. The first command determines the multicast address for the default MDT and the second one determines the data MDT multicast address range. And yes, they are needed either you configure ASM or SSM.
4. "show ip mroute <vrf name>" will give you the inbound and outbound interface. The outbound interface will be the tunnel interface for the default or data MDT.
5. There is most certainly a limit, but no hard limit that I know of.
6. This command is not needed for ASM, only for SSM.
Regards,
08-04-2024 11:06 AM
Thanks a lot @Harold Ritter for your detailed answer !
I think I have misused the terminologies. Instead of multicast core I wrote distribution layer (according to our overall infrastructure design).
08-04-2024 11:40 AM
You are very welcome @Ab26 and thanks for the feedback
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide