Multicast over VRF

Unanswered Question
Apr 27th, 2009

I had a subinterface that was working fine with multicast as of yesterday. I moved over the configuration to another subinterface, and stopped receiving multicast traffic from the LAN. The router is a 7506. Here is the relevant configuration:

interface FastEthernet4/1/0.113

description Private Subnet

bandwidth 100000

encapsulation dot1Q 113

ip vrf forwarding XXX

ip address 192.168.253.1 255.255.255.0

no ip redirects

no ip unreachables

no ip directed-broadcast

ip pim sparse-dense-mode

ip igmp static-group 239.195.0.0

end

if you do a sh ip mroute vrf XXXX 239.195.0.0- you see traffic going TO that lan- but not seeing traffic coming from it.

Later in the configuration we have bidirectional PIM enabled...

ip pim bidir-enable

ip pim vrf XXXXX rp-address 192.168.36.1

Like I said- all I changed was the subinterface. Any ideas?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Anonymous (not verified) Mon, 04/27/2009 - 17:16

devang_etcom Mon, 04/27/2009 - 17:34

Can you look for DATA MDT (mdt data) or Defualut MDT(mdt default) under your VRF configuration?

as well as check for following stuff:

ip multicast-routing vrf XXX

thanks,

Devang Patel

Laurent Aubert Mon, 04/27/2009 - 18:05

Hi,

Can you post also the sh ip mroute vrf XXX ?

If there is a source transmitting, you should have a (S,G) entry in the vrf mrib

Thanks

Laurent.

gregwoodson Tue, 04/28/2009 - 08:13

Core-1#sh ip mroute vrf XXXXXX 239.195.0.0

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,

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.195.0.0), 8w3d/00:03:24, RP 192.168.36.1, flags: SJC

Incoming interface: Multilink12, RPF nbr 192.168.252.14

Outgoing interface list:

FastEthernet4/1/0.113, Forward/Sparse-Dense, 19:26:22/00:01:15

Tunnel1, Forward/Sparse-Dense, 8w3d/00:03:24

(10.0.50.254, 239.195.0.0), 4d17h/00:03:29, flags: T

Incoming interface: Tunnel1, RPF nbr 10.255.0.8

Outgoing interface list:

FastEthernet4/1/0.113, Forward/Sparse-Dense, 19:26:22/00:01:15

Multilink12, Forward/Sparse-Dense, 4d17h/00:03:03

(10.0.36.55, 239.195.0.0), 2w0d/00:03:25, flags: T

Incoming interface: Multilink12, RPF nbr 192.168.252.14

Outgoing interface list:

FastEthernet4/1/0.113, Forward/Sparse-Dense, 19:26:22/00:01:15

Tunnel1, Forward/Sparse-Dense, 2w0d/00:03:24

(10.0.36.149, 239.195.0.0), 2w0d/00:03:25, flags: T

Incoming interface: Multilink12, RPF nbr 192.168.252.14

Outgoing interface list:

FastEthernet4/1/0.113, Forward/Sparse-Dense, 19:26:22/00:01:15

Tunnel1, Forward/Sparse-Dense, 2w0d/00:03:24

(10.0.36.254, 239.195.0.0), 6w5d/00:03:25, flags: T

Incoming interface: Multilink12, RPF nbr 192.168.252.14

Outgoing interface list:

FastEthernet4/1/0.113, Forward/Sparse-Dense, 19:26:22/00:01:15

Tunnel1, Forward/Sparse-Dense, 6w5d/00:03:24

We see traffic going toward Fa4/1/0.113, but not coming from it.

Giuseppe Larosa Tue, 04/28/2009 - 08:22

Hello Greg,

out fas4/1/0.113 there is a multicast source or receivers ?

if only receivers what you see is correct and this is a leaf.

Actually the ip pim static-group causes the interface to be in the OILIst for the group.

Hope to help

Giuseppe

gregwoodson Tue, 04/28/2009 - 08:24

It is both senders and receivers. This was working before- I just had to move to a new fast ethernet interface. We went from fa0/1/0.113 to fa4/1/0.113. The configuration is exactly the same.

Giuseppe Larosa Tue, 04/28/2009 - 10:34

Hello Greg,

just to be sure I suggest a basic check:

can you ping in VRF the supposed sources and receivers from f4/1/0.113 ?

Have you connected it to another L2 switch ? I guess it can be another switch port the one where f4/1/0 is connected.

Hope to help

Giuseppe

gregwoodson Wed, 04/29/2009 - 07:22

This is an entire production LAN on that port. Multicast traffic is the only thing not passing. I can ping these boxes with a regular ping, but not with a multicast ping.

gregwoodson Wed, 04/29/2009 - 07:23

This is a layer 2 switch connected to our 7507 router. All we moved was the subinterface- which worked before the move.

Giuseppe Larosa Wed, 04/29/2009 - 07:48

Hello Greg,

as I said it was a basic check to be sure everything is well in the unicast side.

I think it needs to trigger some recalculations.

I would try

clear ip route vrf XX *

Hope to help

Giuseppe

gregwoodson Wed, 04/29/2009 - 07:49

I'll have to try that after hours tonite. I will get back on in the morning with results. It just seems odd that multicast from the LAN itself is the only thing not working.

Laurent Aubert Wed, 04/29/2009 - 13:39

Hi,

There is no magic so you should starts from your source and:

-check the switch is well receiving the multicast traffic on the port where the source is connected to.

-check the switch is well forwarding this traffic to the port where the router is connected. If there are local receivers as well on the same VLAN, are they receiving this traffic ? Be aware IGMP snooping may be running

If the traffic is well transmitted, you could try a shut/no shut of the router interface...and do a sh ip rpf to be sure the router is expecting this traffic from this interface.

HTH

Laurent.

Actions

This Discussion