MultiCast over VPN

[martinbuffleo]

I have two routers set up with a VPn between them.

10.9.1.0/25 --Router--- VPN 10.1.0.0/24---Router 10.200.1.6

I need my multicast to travel both ways. 239.255.5.1:8500.

I have no idea where to start. Please help.

Routers are 2811 with 16 switch modules.

[andrew.prince]

Martin,

IPSEC VPN does cannot encrypt/decrypt multicast traffic. If you need to have multicast traffic - you need to "tunnel" it.

The below URL will help you:-

http://www.cisco.com/en/US/docs/ios/12_4/ip_mcast/configuration/guide/himc_c.html

HTH.

[martinbuffleo]

So I'm gonna have to create a GRE tunnel inside my IPSEC tunnel?

[andrew.prince]

Pretty much - which is pretty simple!

My advice to you, is to use tunnel keepalives, as there are a couple of ways to fool a tunnel to be up - when it can't be ;o)

HTH.

[martinbuffleo]

I have configured my GRE tunmnels within my IPSEC tunnel. GRE = tunnel 1

My multicast devices are connected to the a 16 port switch module . All ports on VLAN 1

I then added the following to both routers;

interface vlan1

ip address

ip pim sparse-dense-mode

interface tunnel1

ip address

ip pim sparse-dense-mode

That didn't work so I added

ip pim send-rp-announce vlan1 scope 16

ip pim send-rp-discovery scope 16

didn't work on one, so added to both still didn't work.

Which didn't seam to work either.

This is my first time with multicast routing so I could be make obvoise mistakes.

[andrew.prince]

give the below a try:-

http://www.cisco.com/en/US/products/ps6651/products_ios_protocol_option_home.html

HTH.

[Richard Burts]

Martin

If the link that Andrew provided does not solve your problem then it would be helpful if you provide some additional information to help us understand the problem. Aside from the multicast issue are the VPNs working ok? Can you ping the GRE tunnel address of the peer router? What have you got in the access list that identifies traffic for IPSec VPN? In fact it would be helpful if you post configs of the routers.

HTH

Rick

[martinbuffleo]

Sorry for the delay in my reply manager just keeps adding to my work load.

The VPN tunnels are fine i can ping the vpn end points and I can ping my GRE tunnel ip address end to end.

Please find attached my configs.

[Richard Burts]

Martin

I have looked at the configs that you posted. While I do not understand everything that I see in them, and may miss an issue or two, I do have these comments and suggestions:

- I am a little unsure why you are configuring 2 tunnels. You do not need a separate tunnel for multicast. The multicast should work over the tunnel that is processed with IPSec. So my first suggestion is that unless there is some reason for separate tunnels that I do not know about, that you should consolidate and have a single tunnel between the routers.

- access-list 101 is used to identify traffic for IPSec. It is better not to configure this access list with permit any and is better to specify the specific tunnel source address.

- this is the access list from Central

access-list 101 permit gre any host 001.002.50.94

but 50.94 is the address of FastEthernet0/0 on that router. The access list destination should be 50.93.

- for tunnel 1 the source address and the destination address are the addresses of tunnel 0 on each router. This is at least unusual and may be a problem. If you do not take my suggestion to consolidate the tunnels I would suggest that these tunnels should have source and destination addresses that are not associated with tunnels.

- the crypto map is configured on both the physical interface and on the tunnel interface. I have not done much DMVPN but with regular IPSec tunnels with GRE the crypto map goes on the physical interface and not on the tunnel (actually in older code the crypto map was put on both the physical and the tunnel - but I do not think you are running code that is that old).

HTH

Rick

[martinbuffleo]

Thank you for taking the time to look at my configs.

The only reason I have tunnel 1 is because prevously on this post I was instructed that multicast routing would NOT work accross IPSEC and I would need to configure a GRE tunnel for the multicast to work.

For tunnel 1 I felt I needed to use tunnel 0 ip addresses as they are the only ones I know both ends. But if your saying that MRoute should work over tunnel 0 I have no problem removing tunnel 1 from my configs.

With regards to the access list 101 for central my understanding is that:

Source Any IP using GRE permited to Destiniation 001.002.50.94 (The Hub of the hub spoke setup)

At the moment tunnel 0 (DMVPN) comes up fine and I can ping both ends and access service across the tunnel. I'm sure my configs need an overhall but at present my main push is to get the multicast work within the next 2 weeks.

Would you suggest bining tunnel 1 (GRE) and adding the PIM commands to tunnel 0 (DMVP. Do you think this would work???

[Richard Burts]

Martin

I would expect that multicast would operate over tunnel 0. Give it a try and let us know.

As for the original advice that you needed a GRE tunnel, I do not want to put words into Andres's mouth, but your original post only mentioned configuring IPSec and did not mention configuring a tunnel. If he had not advised a GRE tunnel then I would have because I interpreted your original post to indicate that you had an IPSec VPN running without tunnels and native IPSec does not transmit multicast. Now that we know that there is a tunnel I do not see any need for an additional tunnel.

HTH

Rick

[martinbuffleo]

I have removed Tunnel 1 (GRE) and added:

ip pim sparse-dense-mode

To tunnel 0 on both routers.

Central#show ip mroute

(*, 239.255.5.1), 00:21:05/00:03:01, RP 10.200.1.1, flags: SJC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan1, Forward/Sparse-Dense, 00:02:08/00:01:48

Tunnel0, Forward/Sparse-Dense, 00:21:05/00:03:01

shadow09#show ip mroute

(*, 239.255.5.1), 00:37:41/00:02:47, RP 10.200.1.1, flags: SJC

Incoming interface: Tunnel0, RPF nbr 10.1.0.1

Outgoing interface list:

Vlan1, Forward/Sparse-Dense, 00:37:41/00:02:47

company-central#show ip igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter

239.255.5.1 Vlan1 00:10:02 00:02:11 10.9.1.5

224.0.1.39 Tunnel0 00:32:09 00:02:58 10.1.0.1

224.0.1.39 Vlan1 1w6d 00:02:10 10.200.1.1

224.0.1.40 Vlan1 1w6d 00:02:12 10.200.1.1

224.0.1.149 Vlan1 00:10:04 00:02:09 10.9.1.5

shadow_09#show ip igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter

239.255.5.1 Vlan1 00:45:11 00:02:17 10.9.1.2

239.255.5.3 Vlan1 00:28:35 00:02:17 10.9.1.2

224.0.1.39 Tunnel0 00:29:52 00:02:43 10.1.0.1

224.0.1.39 Vlan1 00:45:14 00:02:16 10.9.1.1

224.0.1.40 Vlan1 00:45:05 00:02:14 10.9.1.1

224.0.1.149 Vlan1 00:45:10 00:02:16 10.9.1.2

I have tried sending in both directions and yet nothing is recieved the other end.

[Richard Burts]

Martin

From what I am seeing it looks like central is initiating multicast route 239.255.55.1 (it does not show any incoming interface and does show outgoing interfaces). And it appears that shadow is learning the multicast route. So it looks like that part of sending multicast over the tunnel is working.

I would not expect sending from shadow to central to work, since shadow is learning the route not advertising the route. I would expect sending from central to work. Perhaps you can tell us what you are using to generate the multicast traffic on central? This might help us to understand why sending is not working.

HTH

Rick

[martinbuffleo]

It is just a multicast voice system.

At present one unit at each end with a Mic and speaker.

Bit like a two way intercom.