cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2044
Views
0
Helpful
9
Replies

GRE over IPSEC - Unstable

saquib.tandel
Level 1
Level 1

Hi All,

Can Someone input for tunnel flapping/unstable issue. I have attached the diagram.

GRE Tunnel is running over IPSEC, Tunnels are not stable between HQ and AB1 , HQ and AC1.

If I got only one tunnep up at a time then tunnel is stable but no redundancy or loadsharing.

Our idea was

() To send all traffic initiated from HQ to AC1 via tunnel 33, if Tunnel 33 is down then send traffic via Tunnel 20 and Tunnel 22

() To send all traffic initiated from HQ to AB1 via Tunnel 20 and Tunnel 22 if both tunnels are down then send via Tunnel 33

All routers are configured under the same area 0 ; internet bandwidth are unequal so EIGRP is configured on Tunnels

HQ_VPN_R1 : Internet Bandwidth 6MB - ISP1

HQ_VPN_R2 : Internet Bandwidth 1MB - ISP2

AB1 : Internet Bandwidth 2MB - ISP3 

AB1 : Internet Bandwidth 1MB - ISP2

AC1 : Internet Bandwidth 1MB - ISP3

I feel multiple link to same destination is causing the unstability of Tunnel, not sure how to tweak the configuration on OSPF, Eigrp

Please input.

Thanks

Saquib

1 Accepted Solution

Accepted Solutions

Hello Saquib,

I needed some time to prepare an answer.

Your initial requirements were:

>>>() To send all traffic initiated from HQ to AC1 via tunnel 33, if Tunnel 33 is down then send traffic via Tunnel 20 and Tunnel 22

>>>() To send all traffic initiated from HQ to AB1 via Tunnel 20 and Tunnel 22 if both tunnels are down then send via Tunnel 33

Examining the topology diagram we see:

tunnels 20 and 22 connect HQ VPN routers to AB1 VPN router

tunnel 33 connects HQ router HQ_VPN_R1 ro AC1 VPN router

An important element to be considered is the OSPF link between BB_AC1 and BB_AB1 routers that interconnect the two remote sites making internal routes of site AC known in OSPF on site AB and viceversa.

This means that on all GRE tunnels all the IP subnets of site AC and of site AB are advertised.


To implement the desired hierarchy of routing different metrics have to be associated to different subset of routes on the different tunnels.

More specifically, IP subnets and aggregate routes within AC1 address space 172.31.120.0/21 have to be seen with the best metric via tunnel 33.
The same routes have to be received on tunnel 20 or tunnel 22 but with an higher metric (equal on both tunnel 20 and tunnel 22 to perform load sharing when tu33 is down).

The same reasoning reversed applies to the ip address space of AB site 172.31.65.0/21 again IP subnets and aggregate routes within 172.31.65.0/21 have to be advertised with a lower equal metric on AB1 router out of tunnel 20 and tunnel 22.
AC1 router for the same routes within 172.31.65.0/21 has to advertise an higher metric.

Looking at the current configuration as you have reported in penultimate post:

within router eigrp process you would need to set a seed metric to see OSPF routes injected in EIGRP domain.

There are two ways to create a differentiation of EIGRP metrics advertised over the GRE tunnels:

a) use of a route-map to be invoked as additional option in router eigrp process

b) use of offset-lists that add delay selectively to some IP prefixes.

I give below an example of method a)

AC1 router:

ip prefix-list AC1routes seq 5 permit 172.31.120.0/21 le 32

route-map OSPFtoEIGRP_AC1 permit 10
match ip address prefix  AC1routes
set metric 10000 1000 255 1 1500
route-map OSPFtoEIGRP_AC1 permit 20
set metric 1000 20000 255 1 1500

the route-map sets a lower seed metric for local routes and an higher seed metric for routes that are actually of site AB1.

router eigrp 2
redistribute ospf 5 route-map OSPFtoEIGRP_AC1

A similar approach can be used on AB1 router

ip prefix-list AB1routes seq 5 permit 172.31.65.0/21 le 32

route-map OSPFtoEIGRP_AB1 permit 10
match ip address prefix  AB1routes
set metric 10000 1000 255 1 1500
route-map OSPFtoEIGRP_AC1 permit 20
set metric 1000 20000 255 1 1500

the route-map sets a lower seed metric for local routes and an higher seed metric for routes that are actually of site AB1.

router eigrp 2
redistribute ospf 5 route-map OSPFtoEIGRP_AB1

This should give you the desired routing behaviour

set metric for EIGRP uses 5 parameters

BW delay reliability load MTU

EIGRP metric is proportional to delay and inversely proportional to lowest BW on path.

Hope to help
Giuseppe

Rate useful posts to help Haiti

View solution in original post

9 Replies 9

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Saquib,

when dealing with multiple tunnels you need to avoid route recursion :

tunnel source and destinations must be not advertised on the routing protocol used over the tunnel

This is the usual reason for tunnel flaps

check if you are advertising over tunnel Y the endpoint of tunnel X and viceversa

if you use EIGRP you can take advantage of distribute-list in EIGRP process to control what you send out on each tunnel

Hope to help

Giuseppe

Rate useful posts to help Haiti

Hi Giuslar,

Thank you for replying the post.

I have posted the configuration for all sites, can you help to identify the missing configuration.

Our goal is

() To send all traffic initiated from HQ to AC1 via tunnel 33, if Tunnel 33 is down then send traffic via Tunnel 20 and Tunnel 22

() To send all traffic initiated from HQ to AB1 via Tunnel 20 and Tunnel 22 if both tunnels are down then send via Tunnel 33

Hello Saquib,

I have given a look at your configuration. Some notes follow:

#  AB1_VPN_RTR:
! there is a mismatch between ACLs and crypto maps, the source of
! should be that of the outgoing interface not that of the other outgoing interface

2) the configuration of the following tunnel GRE on device ##HQ_VPN_RTR_2  ### is wrong:
   the destination address must be an external address and cannot be the ip address used on the tunnel itself

interface Tunnel20
  ip address 172.16.1.9 255.255.255.252
  tunnel source GigabitEthernet0/1
tunnel destination 172.16.1.10

the same applies to the following tunnels

interface Tunnel22
  ip address 172.16.1.1 255.255.255.252
  tunnel source GigabitEthernet0/1
tunnel destination 172.16.1.2

interface Tunnel33
  ip address 172.16.1.5 255.255.255.252
  tunnel source GigabitEthernet0/1
tunnel destination 172.16.1.6

destination has to be in sync with IPsec peer external ip address as described in the ACLs

for example:

ip access-list extended ACL-GRE-R1
permit gre host 22.22.22.1 host 10.200.100.50

===> tunnel destination 10.200.100.50 and not the internal address

This error has been done everywhere

3) you are redistributing OSPF and EIGRP mutually you may need to take care of this using route tags and route maps

Fix your configuration accordingly

Later, your requirements can be examined when all tunnels will be up and stable.

Hope to help

Giuseppe

Hello Giuslar,

Thank you for your reply. I amended the configuration and all the tunnels are up, but still I see sometimes tunnel up/down.

I think this could be due to multiple routes to same destination. Can you help how to tune config with route-map/route-tag to avoid traffic flow concern.

I attached the updated configuration.

SAQUIB

Hi Guislar

All links are stable now, but at times traffic initiated from HQ to AC1 goes via AB1 even when the tunnel for AC1 is up.

Is route-tag needed to tune this issue.

thanks

Saquib

Hello Saquib,

I needed some time to prepare an answer.

Your initial requirements were:

>>>() To send all traffic initiated from HQ to AC1 via tunnel 33, if Tunnel 33 is down then send traffic via Tunnel 20 and Tunnel 22

>>>() To send all traffic initiated from HQ to AB1 via Tunnel 20 and Tunnel 22 if both tunnels are down then send via Tunnel 33

Examining the topology diagram we see:

tunnels 20 and 22 connect HQ VPN routers to AB1 VPN router

tunnel 33 connects HQ router HQ_VPN_R1 ro AC1 VPN router

An important element to be considered is the OSPF link between BB_AC1 and BB_AB1 routers that interconnect the two remote sites making internal routes of site AC known in OSPF on site AB and viceversa.

This means that on all GRE tunnels all the IP subnets of site AC and of site AB are advertised.


To implement the desired hierarchy of routing different metrics have to be associated to different subset of routes on the different tunnels.

More specifically, IP subnets and aggregate routes within AC1 address space 172.31.120.0/21 have to be seen with the best metric via tunnel 33.
The same routes have to be received on tunnel 20 or tunnel 22 but with an higher metric (equal on both tunnel 20 and tunnel 22 to perform load sharing when tu33 is down).

The same reasoning reversed applies to the ip address space of AB site 172.31.65.0/21 again IP subnets and aggregate routes within 172.31.65.0/21 have to be advertised with a lower equal metric on AB1 router out of tunnel 20 and tunnel 22.
AC1 router for the same routes within 172.31.65.0/21 has to advertise an higher metric.

Looking at the current configuration as you have reported in penultimate post:

within router eigrp process you would need to set a seed metric to see OSPF routes injected in EIGRP domain.

There are two ways to create a differentiation of EIGRP metrics advertised over the GRE tunnels:

a) use of a route-map to be invoked as additional option in router eigrp process

b) use of offset-lists that add delay selectively to some IP prefixes.

I give below an example of method a)

AC1 router:

ip prefix-list AC1routes seq 5 permit 172.31.120.0/21 le 32

route-map OSPFtoEIGRP_AC1 permit 10
match ip address prefix  AC1routes
set metric 10000 1000 255 1 1500
route-map OSPFtoEIGRP_AC1 permit 20
set metric 1000 20000 255 1 1500

the route-map sets a lower seed metric for local routes and an higher seed metric for routes that are actually of site AB1.

router eigrp 2
redistribute ospf 5 route-map OSPFtoEIGRP_AC1

A similar approach can be used on AB1 router

ip prefix-list AB1routes seq 5 permit 172.31.65.0/21 le 32

route-map OSPFtoEIGRP_AB1 permit 10
match ip address prefix  AB1routes
set metric 10000 1000 255 1 1500
route-map OSPFtoEIGRP_AC1 permit 20
set metric 1000 20000 255 1 1500

the route-map sets a lower seed metric for local routes and an higher seed metric for routes that are actually of site AB1.

router eigrp 2
redistribute ospf 5 route-map OSPFtoEIGRP_AB1

This should give you the desired routing behaviour

set metric for EIGRP uses 5 parameters

BW delay reliability load MTU

EIGRP metric is proportional to delay and inversely proportional to lowest BW on path.

Hope to help
Giuseppe

Rate useful posts to help Haiti

Many Many Thanks Guislar, your input will help alot.

I would apply and update you soon.

Question :  To avoid recursive routing do I need to add a static route to destination public IP on each VPN Router for each Tunnel. ( example below )

On  Router (AB1_VPN_RTR)

Ip route 10.200.100.50 255.255.255.255 22.22.22.3 

Hello Saquib,

if you are not sending a default route in EIGRP it should not be a problem.

However, it doesn't hurt to add these /32 static routes

Hope to help

Giuseppe

Great Help.

Many Thanks.

Review Cisco Networking products for a $25 gift card