05-20-2013 11:32 AM - edited 03-04-2019 07:57 PM
Welcome 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.
Solved! Go to Solution.
05-26-2013 04:57 PM
Hi Giuseppe
I will check this and come back to you
Thanks
Raju
05-28-2013 09:16 AM
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
05-28-2013 09:24 AM
Hi
Also for transport, Juniper supports RSVP TE. But ASR1k does not support this but supports mLDP
Thanks
Raju
05-29-2013 08:41 PM
Hi Giuseppe
BGP AD and BGP c-Mc sig are not offcially supported on 7600
Thanks
Raju
05-29-2013 07:35 AM
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
05-30-2013 09:28 AM
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
05-30-2013 11:46 AM
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
05-31-2013 01:54 AM
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
05-29-2013 01:07 PM
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.
05-30-2013 08:36 AM
Hi
I don't think you can acheive this without configuring MDT which is not possible in pure VRF-lite
Thanks
Raju
05-30-2013 11:26 AM
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
05-31-2013 02:53 AM
New generation MVPN eveolved to meed the following requirements
Simplicity, managability, scalability,....
Label Switched Multicast has following advantages over traditional GRE based MVPN
. 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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: