04-08-2010 03:59 AM - edited 03-04-2019 08:04 AM
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
Solved! Go to Solution.
04-11-2010 04:43 AM
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
04-08-2010 05:05 AM
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
04-08-2010 03:38 PM
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
04-09-2010 01:14 AM
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
04-09-2010 03:56 AM
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
04-09-2010 10:29 PM
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
04-11-2010 04:43 AM
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
04-11-2010 06:45 AM
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
04-12-2010 09:11 AM
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
04-13-2010 12:53 AM
Great Help.
Many Thanks.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: