04-21-2010 07:05 AM - edited 03-06-2019 10:43 AM
Hello guys,
I have private PPP link between two sites connected to two L3 switches as routed port. Traffic between these two LANs is sailing smoothly via the PPP link bidirectional. I have also implemented IPSec VPN tunnel between the same two sites via the internet as backup in case the private link failed. In this case, the tunnel is working great.
When the PPP link restored on the L3 switch the LAN traffic continue to pass through the tunnel.
How do I configure the firewall or the switch to drop the IPSec tunnel when the PPP link restore?
The trick here is my internet ASA5520 firewall at both sites doesn’t know this route because it is part of the LAN. Can sla monitor and tracking with ACL will work? If so, any advice
Site A:
PPP link address 10.10.10.1/30 on L3 switch
ASA 192.168.1.1 outside
192.168.2.1/24 inside
Site B:
PPP link address 10.10.10.2/30 on L3 switch
ASA 10.0.1.1/30
Inside 192.168.2.1/24
Thanks,
Eric
04-21-2010 08:16 AM
SLA monitor will resolve your issue, please check out the following example;
please rate the post if this is helpful
04-21-2010 12:17 PM
P, Thank you very much for your lead and already looked into that link. My situation is bit different because both links are not physically connected to my firewall. I have one link from the firewall to ISP and other from the LAN switch to other location’s LAN switch. Just link trunking link but instead it is point-to-point with L3 subnet.
Thx, Eric
04-21-2010 01:32 PM
Hey guys, I have tested various sla tracking solutions in my lab and finally got the best solution base on the design. I will advise later.
Thx,
E
04-22-2010 01:21 AM
Hi Eric,
you could try and configure SLA monitor on the lan switch so that it is tracking the remote LAN switch, if this fails then the SLA could then failover to the VPN link
04-22-2010 05:27 AM
What about when the PPP link restores and how it will force the firewall to drop the tunnel and route inside traffic to the ppp link? I am continue to test various scenarios
04-22-2010 06:52 AM
Hi Eric,
You can set up reliable static route to track the SLA and set up the same route with higher metric through the ASA.
Once the ppp link goes down the higher metric static route kicks in and once comes back the original route will be valid again.
If your L3 switch has routing protocol capability you can use that as well combined with static route.
Another option is if your p2p link is transparent ethernet you can use udld to detect the link failure so normal floating static route can work well.
I have a similar setup and udld works well.
Let me know if any of the options needs clarification.
Hope it helps, rate if does
Krisztian
04-22-2010 12:43 PM
Hi K,
Can you send me some example config please? I have tried almost any to no success. I will try your UDLD option
Thanks,
E
04-22-2010 08:03 PM
Hello Guys,
After testing various config I came accross my old references that I used to design MPLS private link. This tracking SLA policy config works great on L3 switch! Make sure the port that will be use on L3 switch is set to routed port instead of trunking betwn two locations. Use L3 subnet to create PPP link.
ip route 0.0.0.0 0.0.0.0 5.5.5.2 <
ip route 4.4.4.0 255.255.255.0 interface ethernet0/1 6.6.6.2 track 50 << to private PPP link
ip sla 1
icmp-echo 6.6.6.2
ip sla monitor schedule 1 life forever start-time now
num 3
freq 10
access-list 101 permit icmp any host 6.6.6.2 echo
route-map local permit 20
match ip address 101
set ip next-hop verify-availability 6.6.6.2 10 track 50
track 50 rtr 1 reachability
delay down 10 up 10
interface ethernet0/1
ip policy route-map local
Thank you all for your input and hope this help others. Please rate this
Thx,
Eric
04-23-2010 12:21 AM
Hi Eric,
I just don't see the relevance of the PBR configured especially on the interface facing to the p2p link.
I think if you want to use PBR then would be better to configure on the port facing to your LAN and select the path based on the availability of next hop.
If your p2p goes down the static route should disappear from the routing table and the default route would kick in.
First I was thinking that your goal is to detect a stucked route due to up/up condition of the interface, but that is anyway done by the sla and removes the static route if no response received from 6.6.6.2
May be I was overlooking something.
Can you explain?
Thanks,
Krisztian
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: