Re: Multicast VPN - Troubleshooting

donniedarko84 · ‎05-15-2010

Hi All,

I'm trying to fulfill a requirement for connecting two (2) CE routers over two seperate PE routers within the same vrf.

Multicast routing is working within the VRF on each PE, but I believe the problem is that multicast routes are not being shared between the PE's. I can confirm that the default MDT is being seen on each PE and that the Tunnel 0 is up.

Odd thing on the tunnel, which probably explains alot, is that I have output packets through the tunnel....but no input packets on the tunnel.

I've confirmed that I have the following....

- pim spare mode enable on the MP-BGP source loopback.

- pim spare on the MPLS links.

- pim spare-dense on the CE link.

- within the vrf I'm using a default mdt of 239.232.0.0

- ip pim ssm default

- ip pim bidir-enable

If anyone can point me in the right direction I'd appreciate the advice.

Laurent Aubert · ‎05-15-2010

Hi,

Do you have a RP configured in the SP multcats domain (for the MDT group) ? Could you share the mRIB (sh ip mroute) of the two PE's (GRT and VRF) and the P routers which may be in the middle in addition to the topology ?

Hardware and version would help as well.

Thanks

Laurent.

donniedarko84 · ‎05-15-2010

Hi Laurent,

No I do not have an RP configured.in the global multicast routing table. Not entirely sure if I needed one or not.

IOS is 12.2(33)SRC2

The mroute GRT is the same for both PE's....

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, E - Extranet,
       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,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.232.0.0), 11:55:18/stopped, RP 0.0.0.0, flags: SJCZ
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
MVRF TEST, Forward/Sparse, 11:53:33/00:00:26

(*, 224.0.1.40), 1d09h/00:02:43, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 1d09h/00:02:43

The mroute for the VRF just shows the route for 224.0.1.40.

Thanks for your reply! I appreciate the help.

Nagendra Kumar Nainar · ‎05-15-2010

Hi Donnie,

With PIM sparse mode configured o core, you need RPassigned to function properly. From mRIB output, I assume your PIM neighborship with other PE over tunnel intf wil not be established. Can you check the same in "show ip pim vrf neighbor" ?.

Can you try assigning RP (either manually or using Auto-RP/BSR) and see if it works fine?. You can configure any one PE as RP manually using "ip pim rp-address " on all multicast routers.

HTH,

Nagendra

donniedarko84 · ‎05-16-2010

Hi Naikumar,

Here is the output off one of the PE's...

PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
172.26.1.6        Vlan189                  1d19h/00:01:29    v2    1 / DR B S

So from the output...it is showing me that the CE router has negotiated PIM with the PE router local to it. From what you've indicated below, I should be seeing the other CE router, off the other PE...correct?

Before I add this command...Is their a best practice for the selection of an RP? and....using static/Auto-RP/BSR...which is preferred?

Thanks Naikumar for your response.

Vaibhava Varma · ‎05-16-2010

Hi Donnie

Few words on this:

Static RP- has configuration burden limitations in the case the RP Address changes as we will need to manually change it on all Mutlicast Domain ROuters.

Auro-RP - Dynamic Cisco Proprietary

BSR- Dynamic IETF Standard

When we are ruuning Multicast MPLS VPNs , we establish PE-PE PIM Neighbouship per VRF over the MDT Tunnel used for the VRF which is a dynamic always on tunnel.

On a per PE basis we will see only PIM Neighbourship with the attached CE and Remote PEs participating the particular VRF for Multicast over the MDT Tunnel. We will not see other CEs as PIM neighbour on a PE for that VRF. But what we will see is the RP Mapping propogating end to end on each PE under that VRF and on each CE if using Dynamic RP.

Regards

Vaibhava Varma

donniedarko84 · ‎05-16-2010

Hi Vaibhava,

Well it sounds like Auto-RP and BSR are the best choices. I'll have to do some research and get some better understanding of each before selecting the winner.

Thank you very much for the explanation. Do you think the issue is as simple as not having an RP configured for my GRT PIM?

mlund · ‎05-17-2010

Hi

I see You have configured "ip pim bidir-enable", but there are no rp configured. Sparse-mode is configured on the mpls-links, wich makes an eventual configured " ip pim send-rp-announce " on other router not working, becaues auto-rp needs "dense-mode" or better "sparse-dense" to work.

Also You have specified "ip pim ssm default", and at the same time using "239.232.0.0" as a group this will not work when ssm is active.

One choice here is

remove ip pim bidir and enable "ip igmp version 3" on the mpls-links. This way You are using ssm and doesn't need any rp configuration.

To have ssm working You also have to either, change the group to "232.x.y.z" to match the "ip pim ssm default", or change the command "ip pim ssm default" to "ip pim ssm range " and in the access-list specify 239.232.0.0.

/Mikael

donniedarko84 · ‎05-17-2010

Thanks mlund for the reply.

Is their a more preferred way to go about this?...

If I remove 'ip pim bidir-enable'....and tie PIM SSM into a range using an ACL...an enable IGMPv3 on the MPLS links that will, from what I understand, cancel the need for me to configure an RP.

Is this a best-practice?

donniedarko84 · ‎05-17-2010

Hmmm...I tried this and still seeing the same thing. Looks like the PEs aren't seeing the multicast routes off the other PE.

Laurent Aubert · ‎05-17-2010

Hi,

For each MDT group, each PE acts as a source and a receiver at the same time. If you use PIM-SM in your core, you need a RP (either learned statically or dynamically). In your case, there is two PE's so if the number of P in the middle is not too high, I would go with the static configuration just to make the solution works. Later you could work on a RP redundancy policy.

Now If you use PIM-SSM, you need a way for a PE to learn the different sources addresses (which are the other PEs) because there is no RP anymore. To achieve that, you use specific BGP updates via the MDT address-family.

http://www.cisco.com/en/US/partner/tech/tk828/tech_digest09186a00801a64a3.html

http://www.cisco.com/en/US/partner/docs/ios/ipmulti/configuration/guide/imc_cfg_mc_vpn_ps6922_TSD_Products_Configuration_Guide_Chapter.html#wp1055401

I suggest you to make it work with a static configured RP and then you could go deeper on the different options you have and choose the one which best fit your environment.

HTH

Laurent.