Two GRE Tunnels on one router

Unanswered Question
Oct 17th, 2008

I have an existing router in Fairbanks, AK already running a GRE Tunnel (aka: Tunnel1) on Circuit A;interface FastEthernet0/1.

I can not get Tunnel2 working on Circuit B;interface Serial0/3/0.

Is it possible to configure two GRE Tunnels on the same router that both go back to the same router?

Please see attached shorted and edited versions of the configs.

I was tasked to test VOIP on seperate circuits only. I can not boundle these together per the project requirenments.

[this is over internet cloud]

Please see next message for the correct Fairbanks config

Thanks, Joe

Ip key

Seattle External interface: 65.1.1.1

Fairbanks int for Tunnel1: 209.165.1.18

Tunnel1 Fairbanks: 192.168.51.2

Tunnel1 Seattle: 192.168.51.1

Fairbanks int for Tunnel2: 209.165.2.194

Tunnel2 Fairbanks: 192.168.115.2

Tunnel2 Seattle: 192.168.115.1

Multilink int: 65.1.24.66

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Fri, 10/17/2008 - 10:31

Hello Joseph,

I don't know if you made later changes but the interface ser0/3/0 is shutdown so it cannot be used as source for the second GRE tunnel:

interface Serial0/3/0

description GCI HC.103333, INETFBKDIST-1 intS1-1-0 25:1

ip address 209.165.2.194 255.255.255.252

ip access-group 115 in

ip virtual-reassembly

no ip route-cache cef

no ip route-cache

no ip mroute-cache

shutdown

no fair-queue

service-module t1 timeslots 1-12

!

the interface must be up/up in order to be able to receive GRE packets.

In general you can have as many GRE tunnels as the number of interfaces supported on the platform so this is not an issue

Hope to help

Giuseppe

Giuseppe Larosa Fri, 10/17/2008 - 10:35

Hello Joseph,

ok the test to do is the following

use an extended ping with source= 209.165.2.194 and destination the tunnel destination if this doesn't succeed the remote site does not know I to route to your source ip address

remove ACLs if thet can block this traffic

Hope to help

Giuseppe

jsocolosski Fri, 10/17/2008 - 11:48

That is a good idea.

I have relaxed the crypto and ACLs on the tunnel so it is basically just a GRE at this point and I still can't ping any tunnel interface ip from either opposite side.

When the circuit was first gone live the Fairbanks telco tech could not ping my Fairbanks' 209.165.2.194 internal address from his 209.165.2.193 address, even though my 'show int Serial0/3/0' has up up and packets going thru.

I am calling the telco now to troubleshoot that but How do I force traffic out one interface and not another? I can not shutdown the Tunnel1 since it is business hours.

Thanks for your help, Joe

Giuseppe Larosa Fri, 10/17/2008 - 22:34

Hello Joseph,

for doing the tests and may be in the future if you need to route based on additional criteria like protocol type and / or source you can use PBR (policy based routing)

For example:

access-list 111 permit icmp host 209.165.2.194 host destination-GRE

route-map icmp_pbr permit 10

match ip address 111

set interface ser0/3/0

route-map icmp_pbr permit 20

! empty block for safety

then:

ip local-policy route-map icmp_pbr

now your tests should go out se0/3/0

or even simpler

ip route destination_GRE_2 255.255.255.255 s0/3/0

so you can send the traffic out the right interface and this is the better solution

Hope to help

Giuseppe

jsocolosski Fri, 10/17/2008 - 11:51

Also, I receive this when I try to enable cryto for Tunnel2

FBK_2801(config)#crypto isakmp key bullride address 65.1.1.1

A pre-shared key for address mask 65.1.1.1 255.255.255.255 already exists!

So is it possible to have another cryto Tunnel?

Giuseppe Larosa Sat, 10/18/2008 - 09:32

Hello Joseph,

you need to use a different endpoint ip address for the IPSec.

crypto isakmp key ohms address 65.1.1.1

crypto isakmp key bullride address 65.1.1.1

the limit is not on the GRE tunnel but on IPSec: the ISAKMP tries to match an endpoint to a specific key so it doesn't allow to have two keys for the same IP address.

I didn't realize the remote ip address was the same for both.

If you cannot get a second IP address to use on remote end you can try to use QoS on the crypto to provide a better treatment to VoIP traffic.

It is different then having two different IPSec tunnels but it is used.

Hope to help

Giuseppe

jsocolosski Mon, 10/20/2008 - 06:49

Giuseppe,

Thanks for your help. Some followups...

Will creating another virtual interface with a new IP on the remote end work?

====

interface GigabitEthernet0/0

description Internet Interface

ip address 65.1.1.1 255.255.255.0

no ip redirects

no ip unreachables

duplex full

speed 100

media-type rj45

!

interface GigabitEthernet0/0.100

description Fairbanks VOIP Interface

ip address 65.1.1.100 255.255.255.0

no ip redirects

no ip unreachables

duplex full

speed 100

media-type rj45

!

====

Then use route-map on FBK_2801

FBK_2801(config)#route-map DATAINT permit 10

FBK_2801(config-route-map)#match ip address 109

FBK_2801(config-route-map)#set ip next-hop 209.165.1.18

FBK_2801(config)#route-map VOIPINT permit 20

FBK_2801(config-route-map)#match ip address 115

FBK_2801(config-route-map)#set ip next-hop 209.165.2.194

What do you think?

Giuseppe Larosa Mon, 10/20/2008 - 10:26

Hello Joseph,

overlapping ip addresses are not allowed on Lan interfaces and subinterfaces.

The only trick I can think of is:

define an HSRP group on remote and use the HSRP VIP 65.1.1.x as an endpoint for the second IPsec tunnel

then you need to define traffic to be encrypted and you could try to use PBR to influence out what interface/ipsec tunnel traffic is sent:

but we should note that both IPsec tunnels arrive on the same interface.

Hope to help

Giuseppe

Actions

This Discussion