multicast across GRE tunnel

Unanswered Question
Dec 23rd, 2008

We are deploying a IPTV solution for one internal department into our core. In one side of our core we will have one TV encoder, and in the other hand of our core we will have TV decoders. Because our core doesn't support multicast routing at this momment, provisionally we will install two cisco routers, one of them on the LAN TV encoder side, and the other on the LAN TV decoders side, configuring a tunnel interface between them. By this way, multicast routing will be routed across tunnel interface, and unicast routing will be routed across lan routing.

Ok, we have configured them with pim dense mode, adding an ip mroute in decoders router side pointing to multicast source network and multicast routing works fine.

Now we want to try to configure this environment with pim sparse mode, and it doesn't work. Here you have simplified configuration from both routers in sparse mode:

ENCODER SIDE ROUTER

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

interface Tunnel1

ip address 10.211.251.74 255.255.255.252

ip accounting output-packets

ip pim sparse-dense-mode

load-interval 30

tunnel source FastEthernet0/0

tunnel destination 10.0.71.210

tunnel path-mtu-discovery

!

interface FastEthernet0/0

ip address 10.0.6.18 255.255.255.248

ip pim sparse-dense-mode

load-interval 30

duplex auto

speed auto

ip pim rp-address 10.0.6.18 99

ip mroute 10.0.70.0 255.255.254.0 Tunnel1

access-list 99 permit 239.8.1.2 0.0.0.1

DECODERS SIDE ROUTER

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

interface Tunnel1

ip address 10.211.251.73 255.255.255.252

ip pim sparse-dense-mode

load-interval 30

tunnel source FastEthernet0/0

tunnel destination 10.0.6.18

tunnel path-mtu-discovery

!

interface FastEthernet0/0

ip address 10.0.71.210 255.255.254.0

ip accounting output-packets

ip pim sparse-dense-mode

ip igmp join-group 239.8.1.2

load-interval 30

duplex auto

speed auto

ip pim rp-address 10.0.6.18 99

ip mroute 10.0.6.16 255.255.255.248 tunnel1

access-list 99 permit 239.8.1.2 0.0.0.1

At this momment TV encoder has only one tv channel transmiting into 239.8.1.2 multicast group.

Taking a view to show commands I post, we think the problem is not rpf failure. In "show ip mroute 239.8.1.2 count" command output from encoder side router, you can see continously drops due (OIF-null, etc.) But what is the problem? Anybody can help us?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 2.5 (2 ratings)
Loading.
passioncas Tue, 12/23/2008 - 03:50

hi

Can you please change the ACL statement.Please configure same ACL statement on both side Router as access-list 99 permit 239.8.1.1 0.0.0.1 and let me know whether it is happening or not.

jmfranco Tue, 12/23/2008 - 04:13

Hi.

Thanks for your answer, but I think I have configured the same ACL in both routers:

access-list 99 permit 239.8.1.2 0.0.0.1

There is one thing I don't understand, and I think it could be related with our issue. Taking a view to "sh ip pim neighbor" command in both routers, one of them are not seeing the other side as pim neighbor. However, it was occuring the same thing with DM, and it worked fine. Could be this useful?

Greetings.

ullasupendran Tue, 12/23/2008 - 07:27

HI franco

Can you change the following statements and try?

"ip mroute 10.0.70.0 255.255.254.0 Tunnel1

access-list 99 permit 239.8.1.2 0.0.0.1 "

Change these 2 like the following in both router

on decoder site router

ip mroute 239.8.1.2 255.255.255.255 Tunnel1

on both sites

access-list 99 permit 239.8.1.2 0.0.0.0

Let me know the results

Ullas

jmfranco Tue, 12/23/2008 - 07:55

Hi Ullas, thanks for your post.

About your suggestion, take in mind ip mroute command only accepts multicast source networks/hosts, not multicast addresses/ranges.

ENC_ROUTER(config)#ip mroute 239.8.1.2 255.255.255.255 tunnel 1

%Invalid source address

Thanks.

Giuseppe Larosa Tue, 12/23/2008 - 09:46

Hello Juan,

>>aking a view to "sh ip pim neighbor" command in both routers, one of them are not seeing the other side as pim neighbor. However, it was occuring the same thing with DM, and it worked fine.

In dense mode the idea is to sent traffic out until someone explictily asks for pruning.

With sparse mode it is opposite traffic is sent only if an explicit join is received and to be able to receive it the first requirement is a valid PIM neighborship.

You need to be able to establish a PIM neighborship over the GRE tunnel to be able to move multicast traffic over it

This is the meaning of the following lines taken from encoder router:

(10.0.6.19, 239.8.1.2), 00:49:03/00:02:58, flags: PT

Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0

Outgoing interface list: Null

oil null means the source router has no knowledge of someone interested in this traffic and it doesn't forward it this is seen in the sh ip mroute 239.8.1.2 count

Another important note:

if you want to use the GRE tunnel you need to disable pim on the physical interfaces:

int f0/0

no ip pim sparse-dense-mode

your issue is probably caused by this.

This is useful also for your tests because you want to emulate crossing a non multicast capable core.

Hope to help

Giuseppe

jmfranco Tue, 12/23/2008 - 23:44

Hi Giuseppe, thanks very much for your post.

ip pim sparse-dense-mode is needed in physical interfaces. Take in mind we are using the same physical interface in both routers for receiving/sending unencapsulated traffic from encoder/to decoders, and for establishing tunnel interface between routers as tunnel source and destination.

About pim neighbor relationship between routers, encoder router is knowing the other side as pim neighbor, but decoders router doesn't know the other side as pim neighbor. I have obtained debug ip pim hello in both routers.

ENC_ROUTER#debug ip pim hello

4w5d: PIM(0): Send periodic v2 Hello on FastEthernet0/0

4w5d: PIM(0): Received v2 hello on Tunnel1 from 10.211.251.73

4w5d: PIM(0): Send periodic v2 Hello on Tunnel1

4w5d: PIM(0): Send periodic v2 Hello on FastEthernet0/0

4w5d: PIM(0): Received v2 hello on Tunnel1 from 10.211.251.73

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

DEC_ROUTER#debug ip pim hello

1d22h: PIM(0): Send periodic v2 Hello on Tunnel1

1d22h: PIM(0): Send periodic v2 Hello on FastEthernet0/0

1d22h: PIM(0): Send periodic v2 Hello on Tunnel1

1d22h: PIM(0): Send periodic v2 Hello on FastEthernet0/0

Taking a view to these debugs, you can see DEC_ROUTER doesn't receive hellos across the tunnel interface and I don't understand why. Any idea?

Greetings.

Giuseppe Larosa Wed, 12/24/2008 - 05:27

Hello Juan,

my understanding is that if you want to use successfully the GRE tunnel for multicast, multicast has to be disabled on the physical interfaces in between.

>> Take in mind we are using the same physical interface in both routers for receiving/sending unencapsulated traffic from encoder/to decoders, and for establishing tunnel interface between routers as tunnel source and destination.

I still think your lab setup is not representative of what you want to test.

see the following example

http://www.cisco.com/en/US/tech/tk828/technologies_configuration_example09186a00801a5aa2.shtml

it says:

interface Serial8/0

ip address 192.168.23.1 255.255.255.252

!--- Note IP PIM sparse-dense mode is

!--- not configured on Serial interface.

this is the physical interface between routers the scenario is similar to yours.

You need to have a separate internal lan for senders and receivers as in this example.

If you miss an additional physical interface use two VLan subifs

int f0/0.10

! interlan lan with ip pim enabled

int f0/0.20

! backbone lan with pim disabled

and you connect the port a switch port in trunking mode.

Hope to help

Giuseppe

jmfranco Thu, 12/25/2008 - 23:43

Hi Giuseppe, thanks again for your post.

In this sample configuration, you have an incoming physical interface for multicast traffic, an outgoing tunnel interface for multicast traffic and an outgoing physical interface for "tunneled traffic". I'm agree with you, in this sample configuration, you need pim sparse-dende-mode in incoming physical interface and outgoing tunnel interface, and not in outgoing physical interface.

In my configuration, incoming physical interface for multicast traffic and outgoing physical interface for "tunneled traffic" is THE SAME. If this interface is used for incoming multicast traffic, ip pim sparse-dense-mode is needed.

Best Regards.

Giuseppe Larosa Fri, 12/26/2008 - 01:41

Hello Juan,

>> In my configuration, incoming physical interface for multicast traffic and outgoing physical interface for "tunneled traffic" is THE SAME.

I've understood this use a lan switch and VLan subinterfaces and then you will see that your setup will work.

Until you keep the current setup you are not testing the target scenario and pim neighborship on GRE tunnel will fail.

Hope to help

Giuseppe

Harold Ritter Wed, 12/24/2008 - 06:23

Juan,

This could be due to the tunneled traffic from the encoder to the decoder router being filtered by some access-list in the way. Can you try configuring "keepalive" on the tunnel interfaces to ensure the traffic can be received and sent end to end on the tunnel.

Regards

jmfranco Thu, 12/25/2008 - 23:22

Hi Harold, you are welcome to this discussion.

I promise you we haven't access list in the way from encoder-to-decoders routers.

About keepalives, here there is curious thing. You can do ping between tunnel ip adresses (from 10.211.251.73 to 10.211.251.74 and vice versa), and all seems to work fine. Well, I tried to enable keepalives in tunnel interfaces, and tunnel interfaces goes down. Tunnel interfaces remains down until I disable keepalives in tunnel interfaces. If there was any connectivity issue, ping between tunnel ip adresses will fail.

any suggestion? This issue is driving me crazy.

Greetings.

jmfranco Fri, 12/26/2008 - 02:42

Problem solved!!, but I hate problems without sense.

I had a default route in both routers. Testing I removed these default routes and I configured only specific routes to remote lan in both routers. Mysteriously both routers started to seeing themselves as pim neighbors (remember previously only one of involved routers was seeing the other side as pim neighbor) and multicast routing started to work fine.

Since this had no sense, I configured again default routes removing specific routes, and multicast routing continued working. ¿¿??

Ok, I restarted both routers and from previous dense-mode configuration, I configured rp-address in both routers, and multicast routing worked fine.

Any suggestion/comment?

Thanks.

Giuseppe Larosa Fri, 12/26/2008 - 03:08

Hello Juan,

from your first post:

>> Because our core doesn't support multicast routing

where in your lab setup is the unicast only core ?

there are only two routers with PIM enabled in between.

I think your setup is not representing the real network scenario you tried to push into a too simple network the support of multicast GRE tunnel but the core link between the two routers is also the link to sources or reicevers.

It is important to perform tests that are meaningful that represent the real world or bad surprises can happen in the deployment phase.

Then you did a lot of actions and you made your demo to "work" but how far is from the real network ?

Hope to help

Giuseppe

jmfranco Fri, 12/26/2008 - 04:09

Hi Giuseppe.

Lab? I think never I told it was lab. The only "lab" was to try it with sparse mode. Let me to explain.

I have put these two routers in our corporative production network, our real network, but we are evaluating the solution for IPTV (that is the reason we can turn off and on these routers without problems, in some months this will be different). Between these two routers there are a lot of L3 devices, and both DEC/ENC routers are reachable themselves by unicast routing. Because our core at this momment doesn't support multicast routing, we need to configure a tunnel interface between them.

Perhaps you will ask you, why you are testing in production environment and not in lab? Because the configuration, at first sight, is not complicated in dense-mode, and in dense-mode always has worked fine. The "lab" in this issue, as I told you, was trying to do it with sparse mode.

About bad surprises, all we are exposed to bad suprises with hardware boxes running a software. I bet you have been in troubles like this too.

Thank very much for your help

.

Thanks

Giuseppe Larosa Fri, 12/26/2008 - 07:22

Hello Juan,

this sounds better.

I had the wrong impression they were two routers in back to back by looking at the configurations you posted.

My previous post is out of context in this case: your tests are meaningful.

And yes bad surprises are always possible even after a careful lab testing.

About PIM: means protocol independent multicast that only means indipendency from a specific unicast routing protocol not from the whole ip routing table.

In your case a picture could have helped us to understand what you were doing: I guess you have used the internal lan for the GRE tunnels while I was thinking at interface to the core.

Best Regards

Giuseppe

Harold Ritter Fri, 12/26/2008 - 09:32

Juan,

Glad you got it working and that the keepalives helped you realized that there was a connectivity issue between the two tunnel end points.

Feliz año nuevo

Actions

This Discussion