This discussion is locked

Ask the Expert: Understanding, Configuring and Troubleshooting IP Multicast and MVPN

Endorsed Question
May 20th, 2013

Understanding, Configuring, and Troubleshooting IP Multicast and Multicast VPN with Pulikkal Sekharan RajuWelcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about IP Multicast and Multicast VPN with Cisco expert Pulikkal Sekharan Raju. With Multicast VPN Cisco provides a practical solution to solve the challenge of manual configuration. MVPN architecture introduces an additional set of protocols and procedures that help enable a service provider to support multicast traffic in a VPN.  

Pulikkal Sekharan Raju is a customer support engineer in the High Touch Technical Support group for Cisco. He has over 13 years of experience in electronics and communications. His technical expertise is Border Gateway Protocol, Open Shortest Path First protocol, MPLS, Multicast, Multicast Virtual Private Network Layer 3 Virtual Private Network (MVPN L3VPN), and Layer 2 Virtual Private Network (L2VPN). He has also served as a network engineer for CMC Ltd and a team lead for Remote Management Services. He holds a bachelor of technology degree in electronics and communications from M G University and holds CCIE certification (#25000).

Remember to use the rating system to let Pulikkal know if you have received an adequate response.  Pulikkal might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the WAN, Routing and Switching community sub-community in Network Infrastructure shortly after the event.

This event lasts through Friday May 31, 2013.

Visit this forum often to view responses to your questions and the questions of other community members.

I have this problem too.
0 votes
Endorsed by Giuseppe Larosa
rajs2 about 10 months 3 weeks ago

Hi Giuseppe

I can see that BGP Auto-discovery and BGP C-multicast Routing support added on 15.2(2)S

http://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_mvpn/configuration/15-s/imc_vpn_bgp_croute.html

These features should be availble on ASR1K

7600 Hardware  I am still checking if this is supported on it. Will update you back

Thanks

Raju

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (4 ratings)
Bilal Nawaz Mon, 05/20/2013 - 11:45

Hello Pulikkal,

Thank you for taking to the CSC for multicast etc...

I need some help please,

So at the moment  things look like this in terms of multicast. There is an MSDP peering with the  SQP ASR's forming a redundant RP. Its in a sparse mode environment. The plan is  to implement a solution whereby each site can have its own RP (MSDP peering)  with anycast. And then I want to lock down which set of RP's can be the RP for  particular groups. (easy - ip pim rp-address x.x.x.x 1) 1 being the access list  permitting the group address.

Having said this,  we also require that any multicast traffic generated in ET or any other sites,  if users, lets say... XX, YY and I was to be interested in the multicast traffic from another  site like SQP, we want to ensure that only one stream is sent across the WAN  and then split locally at the site. OSPF is the routing protocol here with point-to-point links. How should I be implementing this?

Thank you.

Please rate useful posts & remember to mark any solved questions as answered. Thank you

rajs2 Tue, 05/21/2013 - 07:35

Hi Bilal

Thank you for yout query

1. Is your requirement to have both anycast RPs in each site to have external MSDP peering with the 2 anycast RPs in  SQP. Also you don't want to run BGP between them and want to use OSPF as the protocol between them?

2. Can you clarify the below statement

"we want to ensure that only one stream is sent across the WAN  and then split locally at the site"

Does that mean that you don't want to receive the mutlicast packet on both RPs in the same site?

3. What is the code you are running on the ASRs which is used as RP?

Thanks

Raju

Bilal Nawaz Tue, 05/21/2013 - 11:43

Hello Raju

Thank you for your reply.

1) This is not a requirement, although I don't know if this is actually needed or not? I have only created MSDP peering for Anycast between the SQP ASR's only for redundancy. OSPF is already the routing protocol, BGP is not used unfortunately. But the Plan is to create MSDP peering's for anycast

SQPASR01 -- SQPASR02 (Anycast RP for x.x.x.x)

ETASR01 -- ETASR02 (Anycast RP for y.y.y.y)

IHASR01 -- IHASR02 (Anycast RP for z.z.z.z)

2) We want to make sure that when multicast source traffic is generated (lets say in SQP IPTV is streaming Channel 1 (x.x.x.x) ) - If myself and other users within another building (lets say ET or IH) were to be interested in this Channel 1 traffic, how can I ensure that only one single multicast stream is sent across the WAN link (or two of the links - because of the secondary WAN link and equal paths in OSPF) instead of unicast for each and every user - I don't want to be saturating a 1GB WAN link. Is this the way it would work already with PIM-SM?

The RP's for each multicast stream should be local to the site from which its generated (makes sense to do that right?)

This should be the same for any source at any other site.

3)

SQP ASRs:

asr1000rp1-adventerprisek9.03.06.00.S.152-2.S.bin

IH ASRs:

asr1001-universalk9.03.06.00.S.152-2.S.bin

ET ASRs:

asr1001-universalk9.03.07.00b.S.152-4.S0b.bin

What kind of configuration and design will be required for this?

Thank you

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

rajs2 Wed, 05/22/2013 - 21:26

Hi Bilal

This should be ok. I will  test this and provide you a detailed reply. Expect bit of delay

Thank you

Raju

Bilal Nawaz Wed, 05/29/2013 - 01:57

Thanks Raju - really appreciate it, look forward to your response.

By the way, this topic is on multicast, why does it say about CUCM??

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

rajs2 Wed, 05/29/2013 - 02:49

Hi Bilal

Me to noticed the same that it is showing as CUCM. I have contacted the cocnerned team regarding  this and waiting for them to correct it

Thanks

Raju

Bilal Nawaz Thu, 05/30/2013 - 03:57

Hello Raju, this event closes tomorrow unfortunately, and im really keen on your response to my questions. Is there a means for you to post the suggestion and answers after the event?

Thank you

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

rajs2 Thu, 05/30/2013 - 06:01

Hi Bilal

I will be answering to your query even if the event closes

Thanks

Raju

Marwan ALshawi Thu, 05/30/2013 - 11:40

Generaly speaking

MSDP will help you share Mcast sources between differnt Multicast domains, which is in your case,

once the receiver find the source/sender via the MSDP/RP then your Mcast Tree and RPF things will into the picture like normal end to end Mcast network

Hope this help

Bilal Nawaz Fri, 05/31/2013 - 08:16

Hello Marwan, thank you for taking time to reply to my query, does this mean all I have to do is create MSDP peerings with each and every connected ASR? and the multicast tree will just be like normal, with single stream going over the WAN for multiple receivers?

How can i test this all out?

I will generate multicast traffic by pinging the multicast group address e.g. 239.1.1.1 and will set a IGMP join on several devices, which commands/verification can I do to check if theyre all using this single stream. i have OSPF enabled only and will have two routes that are equal, how would mcast traffic react to this, what affect will the setup have?

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

brooks_simon@ho... Tue, 05/21/2013 - 23:37

Hi bilal

Im no expert but msdp peering across wan between rps should not saturate link. This is how pim-sm works. If no subscribers on remote site then no traffic! just a source active in the msdp table of the remote router so it knows how to get to the remote rp of the source.

You are correct that rp for source should be local to site and msdp for redundancy is good. However adding acl for specific groups kind of eradicates the need for redundancy. Why have redundancy if you only allowing (*, g) for certain groups on each rp?

Design sounds good otherwise.


Sent from Cisco Technical Support Android App

Bilal Nawaz Wed, 05/22/2013 - 11:32

Hello, thanks for your input - much appreciated! So are we saying that I should create MSDP peerings across the WAN? If we have the source as active in an 'msdp table' am i correct in saying that this will be only using one stream across the links?

Adding ACL's was just for control purposes on which RP's can be the RP for certain groups. Not so much for redundancy.

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

Giuseppe Larosa Sun, 05/26/2013 - 03:04

Hello Pulikkal,

it is nice that you are the expert for an event!

I would like to ask questions about feature road maps in Multicast VPN.

In the past I have configured successfully multicast VPN Draft Rosen where customer multicast traffic is encapsulated in a mGRE tunnel using Service Provider multicast addresses (MDT and data).

Later I have worked on NG Multicast VPN with Juniper implementation using MP BGP special address families and RSVP TE p-2.mp LSPs in the forwarding plane.

What is the state of Cisco implementation for NG MVPN?  I have seen  a solution using P2MP LDP LSPs but in a context of L2VPN /VPLS (OSI L2) that cannot interoperate with Juniper implementation that is still a L3 VPN

I see support of NG MVPN in ASR 9K

http://www.cisco.com/en/US/partner/docs/routers/asr9000/software/asr9k_r4.3/general/release/notes/reln_430a9k.html#concept_6E729038F2174697B94AA2F2DE3CA583

http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/general/release/notes/reln_430a9k.html#concept_6E729038F2174697B94AA2F2DE3CA583

Is there a roadmap to support this also on ASR 1000 platform  and/or C7600?

Thanks for your attention

Best Regards

Giuseppe

rajs2 Sun, 05/26/2013 - 16:57

Hi Giuseppe

I will check this and come back to you

Thanks

Raju

rajs2 Tue, 05/28/2013 - 09:24

Hi

Also for transport, Juniper supports RSVP TE. But ASR1k does not support this but supports mLDP

Thanks

Raju

rajs2 Wed, 05/29/2013 - 20:41

Hi Giuseppe

BGP AD and BGP c-Mc sig are not offcially supported on 7600

Thanks

Raju

jeleinweber Wed, 05/29/2013 - 07:35

I'm struggling with multicast support on ASA 5520 firewalls.   Recently I upgraded some running a rather archaic 8.2(2) firmware to 9.0(2), in preparation for deployment of some new 5525-x's we bought.  In the old configuration I had

multicast-routing

interface Gi0/1

...

igmp forward interface outside

and an access-lists on the outside interface which allowed inbound UDP traffic with the relevant multicast destinations, particularly 239.0.0.0/24.

When I upgraded to 9.0(2), I threw in "no pim", and it broke.  However, allowing pim still is broken, as I'm winning the DR election with my upstream router (run by the UW-Madison), when I need to be losing.   The real PIM is taking place between the campus router and the campus RP; all I want to do is stub forwarding of IGMP v2 join messages from one LAN vlan through my firewall to the upstream router.

What does a working multicast configuration look like on ASA 9.0?  I have hideous memories of months of TAC cases back in the 7.0 days; in 8.2 it was comparatively easy.

-- Jim Leinweber, Wisconsin State Lab of Hygiene

rajs2 Thu, 05/30/2013 - 09:28

Hi

Do you have any PIM RP-addres configuration on the ASA?

can you send me the following outputs from ASA

1. Show igmp groups

2. Show ip mroute

Thanks

Raju

jeleinweber Thu, 05/30/2013 - 11:46

ASA 5520, firmware 9.0(2).  I have gone back to "no pim" on the outside interface; pim variations I have tried on the outside interface only:

   1) no pim

   2) pim, default pim values

   3) pim, dr-priority 0

I haven't tried seting a pim RP address; the upstream router knows that.  Multicast joins work from the transit network upstream of the firewall.

No "igmp access-group" or "pim neighbor-filter" restrictions are applied on any interfaces; it's all defaults.

The client interface on the inside  ("hm-lan") has:

   no pim

   igmp forward interface outside

The outside interface currently has:

  no pim

There are no explicity "mroute" statements in the configuration; supposedly multicast traffic should follow the unicast default route.

f-slh-hm# show igmp groups

-------------------------------

IGMP Connected Group Membership

Group Address    Interface            Uptime    Expires   Last Reporter

224.0.1.24       hm-lan               6d06h     00:03:43  144.92.84.29

226.178.217.5    hm-lan               1w1d      00:03:41  144.92.84.223

230.0.0.1        hm-lan               2d01h     00:03:39  144.92.85.6

239.192.83.80    hm-lan               05:49:34  00:03:41  144.92.85.36

239.255.255.250  hm-lan               6d02h     00:03:37  144.92.84.233

239.255.255.253  hm-lan               05:35:11  00:03:39  144.92.84.208

239.255.255.254  hm-lan               6d03h     00:03:37  144.92.84.29

f-slh-hm# show mroute

--------------------------------

Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,

       C - Connected, L - Local, I - Received Source Specific Host Report,

       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,

       J - Join SPT

Timers: Uptime/Expires

Interface state: Interface, State

(*, 224.0.1.24), 6d06h/never, RP 0.0.0.0, flags: DPC

  Incoming interface: Null

  RPF nbr: 0.0.0.0

  Immediate Outgoing interface list:

    hm-lan, Null, 6d06h/never

(*, 226.178.217.5), 1w1d/never, RP 0.0.0.0, flags: DPC

  Incoming interface: Null

  RPF nbr: 0.0.0.0

  Immediate Outgoing interface list:

    hm-lan, Null, 1w1d/never

(*, 230.0.0.1), 2d01h/never, RP 0.0.0.0, flags: DPC

  Incoming interface: Null

  RPF nbr: 0.0.0.0

  Immediate Outgoing interface list:

    hm-lan, Null, 2d01h/never

(*, 239.192.83.80), 05:49:54/never, RP 0.0.0.0, flags: DPC

  Incoming interface: Null

  RPF nbr: 0.0.0.0

  Immediate Outgoing interface list:

    hm-lan, Null, 05:49:54/never

(*, 239.255.255.250), 6d02h/never, RP 0.0.0.0, flags: DPC

  Incoming interface: Null

  RPF nbr: 0.0.0.0

  Immediate Outgoing interface list:

    hm-lan, Null, 6d02h/never

(*, 239.255.255.253), 05:35:31/never, RP 0.0.0.0, flags: DPC

  Incoming interface: Null

  RPF nbr: 0.0.0.0

  Immediate Outgoing interface list:

    hm-lan, Null, 05:35:31/never

(*, 239.255.255.254), 6d03h/never, RP 0.0.0.0, flags: DPC

  Incoming interface: Null

  RPF nbr: 0.0.0.0

  Immediate Outgoing interface list:

    hm-lan, Null, 6d03h/never

-- Jim Leinweber, WI State Lab of Hygiene

rajs2 Fri, 05/31/2013 - 01:54

Hi

I can see that the IGMP joins are reaching the ASA from your hm-lan interface

I am not an expert on ASA. but I think there is a way you can check if the IGMP packets are going out of the outside interface

have you cheked to see if multicast packets are leaving out of the outside interface

Thanks

Raju

ldesmasures Wed, 05/29/2013 - 13:07

Hello Pulikkal,

We're using VRF-lite on catalyst 6500 with SUP2T  IOS 15.1(1)SY1 on a campus network.

We also import/export unicast prefixes using route-target and BGP for IPv4 and IPv6.

The other information is that we're using only one 6500 core switch (no external peering).

We want to use multicast (for video streaming) on our architecture using PIM and also export multicast prefixes from one VRF to another.

Is it possible ?

I saw the functionnality "Multicast VPN Extranet Support" but it seems that it's working only on MPLS (so no VRF-Lite).

Thanks.

rajs2 Thu, 05/30/2013 - 08:36

Hi

I don't think you can acheive this without configuring MDT which is not  possible in pure VRF-lite

Thanks

Raju

Marwan ALshawi Thu, 05/30/2013 - 11:26

Dear

just interested to know from Design point of view which solution is recommend in which case or scenario and advantages/disadvantages of each in high level

mVPN + MPLS-TE bp2mp TE

mVPN + mLDP  p2mp,mp2mp ldp

mVPN + MDT

Thanks

rajs2 Fri, 05/31/2013 - 02:53

New generation MVPN eveolved to meed the following requirements

Simplicity, managability, scalability,....

Label Switched Multicast  has following advantages over traditional GRE based MVPN

  • Enables the use of a single MPLS forwarding plane for both unicast and multicast traffic.
  • Enables existing MPLS protection (for example, MPLS Traffic  Engineering/Resource Reservation Protocol (TE/RSVP link protection) and  MPLS Operations Administration and Maintenance (OAM) mechanisms to be  used for multicast traffic.
  • Reduces operational complexity due to the elimination of the need for PIM in the MPLS core network.

. Both Mldp and P2P TE support a unified forwarding plane for unicast and multicast. They are hop-by-hop protocols. MLDP is receiver driven while P2MP is headend driven. MLDP is a suitable for generic MVPN, secondary video and consumer video distribution where the trees are dynamic and number of participants are larger. P2MP is suitable for primary and studio-to-studio distribution where the trees are static and the number of participants is smaller.

Here is a white paper for this

http://www.cisco.com/en/US/prod/iosswrel/ps6537/ps6552/ps11505/whitepaper_c11-598929_v1.pdf

Thanks

Raju

Actions

Login or Register to take actions

This Discussion

Posted May 20, 2013 at 11:32 AM
Stats:
Replies:26 Avg. Rating:5
Views:4413 Votes:0
Shares:0
Categories: Routers
+

Related Content

Discussions Leaderboard