cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
914
Views
0
Helpful
3
Replies

Multicast over GRE problem.....looking for input

mmertens
Level 1
Level 1

Last night, I converted a remote site which had multicast, onto MPLS. Therefore, I am now attempting multicast over GRE. Site A is working, and has multicast coming in from one remote site via G0/0 (remote vif 10.100.20.1) , and is working. Site A has a new GRE tunnel built to Site B, which was moved onto MPLS last night, and is not working. Site B's mcsat vif address is 10.100.30.1. Site A's vif is 10.100.10.1.

Site A's "sho ip mroute" looks good. Site B, however, does not show an incoming interface of tunnel6 for vifs 10.100.10.2 or 10.100.20.2. Any idea why that is?

FYI: The VIFs are for a hoot appplication that terminates on fxs voice ports on the same router as the tunnel interface.

THANKS for  any input!

Mike.

SITE A

!
interface Tunnel6
ip address 192.168.46.1 255.255.255.252
ip pim sparse-dense-mode
tunnel source Loopback1
tunnel destination 192.168.36.1
!
interface Loopback1
ip address 192.168.31.1 255.255.255.255
!
interface Vif1
ip address 10.100.10.1 255.255.255.0
ip pim sparse-dense-mode
!

VGW2#sho ip mroute
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
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode


(*, 237.111.0.0), 21w6d/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel6, Forward/Sparse-Dense, 00:15:12/00:00:00
    GigabitEthernet0/1, Forward/Sparse-Dense, 1w0d/00:00:00
    Vif1, Forward/Sparse-Dense, 18w6d/00:00:00

(10.100.10.2, 237.111.0.0), 1w0d/00:02:58, flags: T
  Incoming interface: Vif1, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel6, Forward/Sparse-Dense, 00:15:13/00:00:00
    GigabitEthernet0/1, Forward/Sparse-Dense, 1w0d/00:00:00

(10.100.20.2, 237.111.0.0), 1w0d/00:02:58, flags: T
  Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.101.1
  Outgoing interface list:
    Tunnel6, Forward/Sparse-Dense, 00:15:13/00:00:00
    Vif1, Forward/Sparse-Dense, 1w0d/00:00:00

(10.100.30.2, 237.111.0.0), 00:02:44/00:00:15, flags:
  Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.101.1
  Outgoing interface list:
    Vif1, Forward/Sparse-Dense, 00:02:44/00:00:00
    Tunnel6, Forward/Sparse-Dense, 00:02:44/00:00:00

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


SITE B

!
!
interface Tunnel6
ip address 192.168.46.2 255.255.255.252
ip pim sparse-dense-mode
tunnel source Loopback6
tunnel destination 192.168.31.1
!
interface Loopback6
ip address 192.168.36.1 255.255.255.255
!
interface Vif1
ip address 10.100.30.1 255.255.255.0
ip pim sparse-dense-mode
!

R1#sho ip mroute
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
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode


(*, 237.111.0.0), 00:05:56/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel6, Forward/Sparse-Dense, 00:05:56/00:00:00
    Vif1, Forward/Sparse-Dense, 00:05:56/00:00:00


(10.100.10.2, 237.111.0.0), 00:02:56/00:00:04, flags:
  Incoming interface: Null, RPF nbr 198.18.46.97
  Outgoing interface list:
    Vif1, Forward/Sparse-Dense, 00:02:56/00:00:00
    Tunnel6, Forward/Sparse-Dense, 00:02:56/00:00:00

(10.100.20.2, 237.111.0.0), 00:02:56/00:00:04, flags:
  Incoming interface: Null, RPF nbr 198.18.46.97
  Outgoing interface list:
    Vif1, Forward/Sparse-Dense, 00:02:56/00:00:00
    Tunnel6, Forward/Sparse-Dense, 00:02:56/00:00:00

(10.100.30.2, 237.111.0.0), 00:05:58/00:02:51, flags: T
  Incoming interface: Vif1, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel6, Forward/Sparse-Dense, 00:05:58/00:00:00

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

I have a feeling that your problem may be caused by the failing Reverse Path Forwarding check on the Site B. The site B is currently receiving the multicast stream via the GRE tunnel. However, when it performs the RPF check to see whether the stream came from the interface that leads back to the source of the multicast stream, it does not discover the Tunnel interface but rather the physical interface that connects the site B to the MPLS VPN cloud (just have a look on the routing table on R1 on the site B - most probably, the route back to the source of the stream is not via the Tunnel but via some other interface).

In order to make this RPF check work, you have to create a static multicast routing table entry that points towards the sources via the Tunnel interface on the Site B, as follows:

ip mroute 10.100.0.0 255.255.0.0 Tunnel6

Give it a try and please let us know if it worked.

Best regards,

Peter

View solution in original post

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

I have a feeling that your problem may be caused by the failing Reverse Path Forwarding check on the Site B. The site B is currently receiving the multicast stream via the GRE tunnel. However, when it performs the RPF check to see whether the stream came from the interface that leads back to the source of the multicast stream, it does not discover the Tunnel interface but rather the physical interface that connects the site B to the MPLS VPN cloud (just have a look on the routing table on R1 on the site B - most probably, the route back to the source of the stream is not via the Tunnel but via some other interface).

In order to make this RPF check work, you have to create a static multicast routing table entry that points towards the sources via the Tunnel interface on the Site B, as follows:

ip mroute 10.100.0.0 255.255.0.0 Tunnel6

Give it a try and please let us know if it worked.

Best regards,

Peter

That did it!!!!!!!! Thanks Peter!!!

Hi,

You are welcome. Thank you for your generous rating!

Best regards,

Peter

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco