MPLS Multicast VPN connectivity issues

[ksolie]

I'm trying to get a Multicast VPN deployed across a MPLS backbone.

The CE router has a multicast group, multicast routing enabled and it's interfaces are in sparse-dense mode. The CE is using autorp, (the discovery and annoucement commands) configured for the RP Mapping

The PE router has a Multicast aware VPN for the CE router, The interface to the CE router is in sparse dense mode, and in the Multicast VPN. The PE router also has the MDT tree configured as well.

The Loopbacks are all enable on the MPLS backbone with sparse-dense-mode for BGP. All interface going from PE-P routers are in sparse mode.

I can get multicast traffic from the CE to the first PE. I have the RP mapped, and I can ping my multicast groups. So it looks like multicast traffic is going from CE to PE. However the PE router doesn't seem to pass it on to other PE or P routers. Again BGP loopbacks and all physical interfaces are in sparse mode on the backbone. I do have PIM adj across the backbone as well.

But I can't get multicast traffic across.

I've read about everything and I'm getting stumped.

Any advice on what I'm missing??? I think it is real close, but I just must be missing something.

Any Help is greatly appreciated!!

Thank you for your time,

Karl Solie

[Harold Ritter]

That should definitely do it. This is not a bug but rather the new approach to mVPN support for single AS or InterAS. It is just that before the MDT info was propagated using a VPNv4 prefix advertisement. Now it is propagated via new sub address family identifier as per the following draft:

http://tools.ietf.org/wg/idr/draft-nalawade-idr-mdt-safi-02.txt

Hope this helps,

[swaroop.potdar]

Harold thanks for that information, and also clarifying about the amendment.

But the concern is there wasnt any official declaration about the same, and also any idea's why there isnt backward compatibility using VPV4 MDT as well, as not all routers in a given network would be using the same IOS?

THanks,

Swaroop

[Harold Ritter · Accepted solution]

The backward compatibility between VPNv4 MDT (old mode) and IPv4 tunnel SAFI (new mode)has been implemented in 12.2(33)SRA1 and 12.0(30)S3.

You will see the following translation being performed on the box running backward compatible code for a peer that doesn't support the ipv4 tunnel SAFI:

r8#sh bgp vpnv4 unicast all nei 192.168.100.5

BGP neighbor is 192.168.100.5, remote AS 1, internal link

Member of peer-group internal for session parameters

BGP version 4, remote router ID 192.168.100.5

...

For address family: IPv4 MDT

Translates address family VPNv4 Unicast <+++ actual translation between old and new

Hope this helps,

[ksolie]

Thanks Guys,

It's up! It actually was the MPLS TE tunnels that were messing it up. I thought I had taken them down, but left one up. Upon looking at the MROUTE, with the Cisco TAC, we saw the next hops were not correct, and sure enough I forgot one of the tunnels.

After this was down the PIM neighbors came up and formed the tunnels from the Egress PE to the Ingress. And boom the multicast took off.

Sounds like I might want to be careful with the TE tunnels.

I'm pretty sure I go back to SSM now, that the tunnels are out of the way, and that should work as well.

Take's everyone for your help! I really do appreciate it.

-Karl Solie

Solie Research, LLC

CCSI, CCIE 4599

[swaroop.potdar]

Hey Karl,

It was a pleasure, and to know that I had read your book at a point in time, it felt good to work for some time together.

Be around, its nice to see people like on the forum.

Cheers!!,

Swaroop

[Harold Ritter]

You should be able to use both multicast and TE tunnels in your core.

- First, you need to remove "ip pim sparse-mode" from the TE tunnel configuration. TE tunnels are not currently multicast capable, so it doesn't make sense to configure PIM on them.

- Second, you need to add "mpls traffic-eng multicast-intact" under the isis configuration, to ensure the RPF won't fail because it sees the loopback0 of the opposite router reachable via the tunnel interface while the multicast traffic comes from the physical interface.

See the following URL for more information about this command:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124tcr/tmpls_r/mpl_m4ht.htm#wp1016632

Hope this helps,

[ksolie]

I'm trying to move it over to SSM today, and then I'll bring the tunnels back up

I did have the global command for the TE in the config, but I think othere issues prevented this from coming up.

Thanks again for your help,

(PS-Anyway to mark this post has solving my problem??)

[swaroop.potdar]

Also you may want to vaoid enabling PIM on the TE tunnel :-) just in case.

You should see the option to flag off the thread as solved. AS only you can see this, since you have originated the thread.

HTH-Cheers,

Swaroop