GRE Tunnel help

[rcoote5902_2]

Hello,

We are in the process of trialing Singlewire's Informacast software.  I've been able to get multicast routing set up properly on the LAN where the server resides, however getting it across our WAN to a remote site is another story.

Our provider (Alberta Supernet) is an MPLS network and so do not route multicast traffic.  In speaking with them they will do it, at a cost, and we would have to set up a dedicated vpn to do so.  They (and I) would prefer the alternative, which is a GRE tunnel.

That being said, I've tried my best to follow this document, but just don't seem to be able to get this working.  It is a bit above my head I think.

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

I've attached a network diagram with a basic picture of how our sites are routed.  Everything from our routers to the supernet edge routers is done via static routes.  I think that might be where my issue is...the example config uses OSPF.  I assume that's just for the tunnel but I'm not 1005 sure.

Also I likely have to add a static route to the Supernet config but I'm unclear on what I'd be adding...the network for the loopback or the tunnel?

Relevant configs attached.  If anyone can assist that would be great.

Rob

[Richard Burts]

Rob

There are probably several parts to the problem in getting your GRE tunnel to work. I will start with the first and most significant problem which the use of 2.2.2.2 and 4.4.4.4 as the tunnel source and destination. One important requirement for GRE tunnels is that there must be IP connectivity between the source and the destination before the GRE tunnel comes up. So - can router A ping 4.4.4.4 using 2.2.2.2 as a source?

I know that there are examples where the GRE tunnel is configured using loopback interface addresses as source and destination. And there are situations where this is appropriate. I would suggest that it is not optimum in your situation. I would suggest that you try using the router interface which faces toward the MPLS as the source and destination addresses. I can not be sure from what you have posted but I am guessing that you can ping from one outbound interface to the other outbound interface. If so that would be the first step in getting GRE to work.

HTH

Rick

[rcoote5902_2]

Rick,

The 4.4.4.4 and 2.2.2.2 addresses are definitely not pingable.  I took the config example a bit too literally.

But yes, the outside interfaces for both routers can ping each other.  I will use those as the source and destination interfaces for the tunnel as a start and see where I can get with this.

Thanks for your help,

Rob

[Richard Burts · Accepted solution]

Rob

I sympathesize. It can be difficult when you look at examples to know which parts should change (or are not necessary to the essential function and might be ignored) and which parts are essential. In this case having source and destination addresses be reachable is an essential requirement.

The rest of the tunnel config looks ok from here and if the source and destination addresses have IP connectivity I believe that the tunnel should come up.

I am not sure if you intend to do any routing over the GRE tunnel. If so, then one thing to watch for is to be sure that you do not advertise the source or destination address as being reachable through the tunnel. That causes a problem with recursive routing and will take the tunnel down.

HTH

Rick

[rcoote5902_2]

Rick,

I've changed the source and destination addresses and it looks like the tunnel has come up however  am not seeing multicast traffic making it over this tunnel yet.

With respect to routing, which networks should I be advertising using OSPF, and which mroutes should be present.  Do the mroutes need to be on both sides of the tunnel?

Rob

[rcoote5902_2]

Ok we're moving along now.  I had the wrong mask on one of my mroutes.  Adjusted that and multicast is going across now.

Now I just have to my other 11 sites....

[Richard Burts]

Rob

The easy way to check whether the tunnel is working is for one router to traceroute the tunnel address of the other router. If you get a response and the response is one hop away then you know that the tunnel is working.

Just to check - both ends of the tunnel are configured with ip pim and multicast routes are present in the router on one end of the tunnel.

Assuming that the above is true then my guess is that the issue is with the reverse path check that multicast routing does. If a multicast route is advertised over the tunnel then the source of the multicast must be reachable via the tunnel. The practical effect of this is that every subnet which is potentially a source for multicast must be advertised over the tunnel. If you are going to run OSPF over the tunnel, and if OSPF is the protocol that you are already using on the routers then be careful that the OSPF over the tunnel does not advertise the tunnel source and destination addresses over the tunnel.

There are several ways to work around the issue of advertising the tunnel source and destination over the tunnel:

- you might configure a static route (advertise a /32 host specific route) on the router for the tunnel source/destination address of the other router. The local static is more attractive than the advertised subnet and it avoids the recursive routing issue.

- you might run 2 OSPF processes. One OSPF process (perhaps ospf 1) is the process that runs generally on all interfaces of the router and another OSPF process (perhaps ospf 2) runs only over the tunnel. You redistribute ospf 1 into ospf 2 so that the routes are advertised over the tunnel. And in the redistribution you are careful to filter out the tunnel source and destination subnets.

- you might run OSPF as the general routing protocol on the routers and run some other protocol over the tunnel (perhaps EIGRP) and you redistribute OSPF into the other protocol (again being careful to filter out the source and destination subnets in the redistribution.

HTH

Rick

[rcoote5902_2]

Thanks for your help Rick!