Multiple GRE Tunnels

[Robert Craig]

I am trying to setup two different GRE multipoint tunnels. Tu0 is a regular GRE Multipoint with no IPSEC profile. Works like a charm. Now, I created another tunnel, Tu1 with the same configuration, except I changed the subnet of Tu1 to something different, changed the network-id, and also added an IPSEC profile (tunnel protection). As soon as I turn on Tu1, it kills all of the traffic terminating on Tu0 and I see errors about 'received unencrypted packet' and stuff. It's almost like the traffic starts heading towards Tu1 when it's on. Any ideas? Config is below if it helps. Thanks for any help.

interface Tunnel0

bandwidth 100000

bandwidth inherit

ip address 10.1.1.1 255.255.255.0

no ip redirects

ip mtu 1500

ip nhrp map multicast dynamic

ip nhrp network-id 1011

ip nhrp holdtime 600

ip nhrp registration timeout 30

ip tcp adjust-mss 1400

load-interval 30

qos pre-classify

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel bandwidth transmit 100000

tunnel bandwidth receive 100000

interface Tunnel1

bandwidth 100000

bandwidth inherit

ip address 10.1.2.1 255.255.255.0

no ip redirects

ip mtu 1500

ip nhrp map multicast dynamic

ip nhrp network-id 1012

ip nhrp holdtime 600

ip nhrp registration timeout 30

ip tcp adjust-mss 1400

load-interval 30

shutdown

qos pre-classify

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel bandwidth transmit 100000

tunnel bandwidth receive 100000

tunnel protection ipsec profile DMVPN

[malshbou]

Hi Robert,

This seems like a demultiplexing issue for GRE. Try using different tunnel keys for the two tunnel interfaces and match them at the VPN peer router:

Router(config-if)# tunnel key  <0-4294967295>

Hope this helps.

----
Mashal Shboul

[Robert Craig]

OK, I'll give that a shot. A buddy of mine said I would have to use VRF-Lite to separate the tunnels. I couldn't get my head wrapped around how to do that because there is only one physical interface at the colo that I am plugged into and one IP they give me. It's not even a sub interface. So, to me, vrf isn't really possible because there is only one way in and out. Ideas?

Robert

[Marius Gunnerud]

I think it could be because of the source interface you are using for both tunnels.  I would suggest trying to set up the tunnels using loopbacks as the source interface or perhaps subinterfaces if that is an option and see how that goes.

[Robert Craig]

OK, so I'm having a hard time understanding this concept. If I source the tunnel from a loopback, that would drop everything. Am I right that if a loopback isn't routable across the WAN (ie, 10.0.0.1), the tunnel will never come up?

Robert

[malshbou]

Hi Robert,

Yes, you need to source the tunnel from an IP that is routable in the Internet. The tunnel source will be the source IP address in the outer ip header for the tunneled packet.

--
Mashal Shboul

[Robert Craig]

OK, thats what I thought. Can I use a public address on a loopback and it still be accessible?

[malshbou]

Yes, you can.

--
Mashal Shboul

[Robert Craig]

OK, so I'm still without two public IP's, but I found a VRF guide that suggested throwing tunnel 2 into a VRF. Well, that worked. I now have tunnel 1 up with the regular, global vrf. Tunnel 2 is using vrf CustomerA. Both endpoints are up, but trying to get my head wrapped around routing between the tunnel. If I try to ping spoke of tu2 from spoke of tu1, it just fails. Reverse the flow, I get a U. Any ideas. Below is the relevant config on the hub.

ip vrf CustomerA

rd 65000:1

interface Tunnel0

bandwidth 100000

bandwidth inherit

ip address 10.1.1.1 255.255.255.0

no ip redirects

ip mtu 1500

ip nhrp map multicast dynamic

ip nhrp network-id 1011

ip nhrp holdtime 30

ip nhrp registration timeout 30

ip tcp adjust-mss 1400

load-interval 30

qos pre-classify

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel bandwidth transmit 100000

tunnel bandwidth receive 100000

interface Tunnel1

bandwidth 100000

bandwidth inherit

ip vrf forwarding CustomerA

ip address 10.1.2.1 255.255.255.0

no ip redirects

ip mtu 1500

ip nhrp map multicast dynamic

ip nhrp network-id 1012

ip nhrp holdtime 600

ip nhrp registration timeout 30

ip tcp adjust-mss 1400

load-interval 30

qos pre-classify

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 50

tunnel protection ipsec profile DMVPN1

tunnel bandwidth transmit 100000

tunnel bandwidth receive 100000

!

interface FastEthernet0/0

ip address 208.110.X.X 255.255.X.X

duplex auto

speed auto

IP Address of spoke from tu1 is 10.1.1.7. Tu2 spoke is 10.1.2.7.

[Marius Gunnerud]

You are missing the route-target [import | export | both] command in the VRF.

you would also need to add routing for the VRF.  The following is just an example of how it would be configured:

ip route vrf CustomerA 0.0.0.0 0.0.0.0 10.10.10.1

You also need a device outside of the VRF that will do the routing from the VRF to the other VRF or global routing domain.

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml

[Robert Craig]

Yeah, every example I've looked at and tried to understand shows multiple VRF's and at least two physical interfaces for the traffic. For the current situation, I am stuck with one physical interface (public IP) and only one public IP. Is what I need to accomplish even possible? For the vrf route you mentioned, what is the "10.10.10.1"? Is that a loopback that I can configure that is a part of the vrf or would it be considered a loopback thats in the global vrf?

[Marius Gunnerud]

As with any static route configuration the last IP in the config is the next hop. I used 10.10.10.1 just as an example.

so a better example might be:

ip route vrf

You can use subinterfaces.  Just create the subinterfaces and then add the command ip vrf forwarding

If you need to route between the VRFs you would need another device that is not participating in the VRF network to do that routing.

Have a look at this link. hope it can shed som light on your issue (if you haven't already seen it)

http://packet.life.net/blog/2009/apr/30/intro-vrf-lite

[Robert Craig]

Actually I figured it out. I added a default route for the VRF. It's destination is another router/device in the same public network.

ip route vrf CustomerA 0.0.0.0 0.0.0.0 208.110.X.X global

I don't have control over the default gateway, but I can use a Linux server that has routes to the 10.1.2.0 network

Also added a route for the VRF network from the global VRF routing table

ip route 10.1.2.0 255.255.255.0 tu1

I also added the route-target import/export entries

ip vrf CustomerA

route-target import 65000:1

route-target export 65000:1

I've had the route-target statements before, but never had the the static routes entering and leaving the VRF(s). Some of the guides I've seen suggested using BGP, but static routes seem much simpler in this scenario. Comments/suggestions for the future?

[Marius Gunnerud]

It depends on your network design and requirements.  For example: The one client I am now designing and setting up a network for use both BGP and Static routes.  BGP for routing within the VRF and Static to route between the VRF (everything between VRFs gets sent through the firewall.)

Ofcourse BGP is a bit easier as it is dynamic so if you have a lot of routes then this might be the way to go.  Static routes are good as they can not be manipulated in ways that the dynamic routing protocols can...but having said that, you can use MD5 authentication with BGP and other routing protocols.

Please rate any helpful posts.

[Robert Craig]

Yeah, that makes sense. The more networks, the more static statements. To jump ahead here, is there technically any limit on how many different tunnels with independent VRF's I can have or is it all dependent on the hardware?