Hi All,
I have a 7100 that fails over to a MPLS circuit when the primary internet connection goes down. On the far end of the 7100 I have a 6355 witch NATs the web traffic from the 7100 out its primary web connection. Where the problem lies is failing back to the primary web connection on the 7100.
If the 7100 fails over to the MPLS circuit all devices on the network can reach the web without issues, however the ping probe still fails when the primary connection comes back on line. If I clear the IP Policy session this in-turn fixes the issues with the ping probe and brings the primary connection back online. The route-map applied global to the configuration has hits on the access-list, however I haven’t been able to pull a policy-session yet in a failed state to see if the ping probes traffic is truly being routed out the primary connection. I do not have Fast-Nat-Failover enabled because it not Nating between public interfaces.
!
ip local policy route-map Default_Route
!
probe Default_Route icmp-echo
destination X.X.183.237
source-address X.X.163.17
period 10
timeout 5000
tolerance consecutive fail 10 pass 1
no shutdown
!
track Default_Route_Failover
snmp trap state-change
test if probe Default_Route
no shutdown
test if not probe MPLS_Route
no shutdown
!
route-map Default_Route permit 10
match ip address Default_Route
set ip next-hop X.X.163.18
!
ip access-list extended Default_Route
permit icmp host X.X.163.17 host X.X.183.237
!
Extended IP access list Default_Route
permit icmp host X.X.163.17 host X.X.183.237 (156 matches)
Message was edited by: matt - removed sensitive informaiton
nathanscott,
Thank you for posting this question. In failover scenarios where the firewall is involved there are particular commands that need to be configured to kill the active sessions going through the backup connection once the primary has been restored:
ip firewall fast-nat-failover
ip firewall fast-allow-failover
When a route table change occurs these commands will attempt to send a TCP RST to both ends for applicable sessions so they will be restored over the primary connection. You mentioned this particular traffic is not being NAT'd, so if that is the case and the traffic is allowed via an allow policy-class rule instead you will need the ip firewall fast-allow-failover command. Let me know if that does not resolve the issue.
Thanks,
Matt
Sorry this is the correct Track:
!
track Default_Route_Failover
snmp trap state-change
test if probe Default_Route
no shutdown
!
Here is the policy-session info in normal state.
Policy class "self":
icmp (60) -> Public
X.X.163.17 65 X.X.183.237 65
Message was edited by: matt - removed sensitive information
nathanscott,
Thank you for posting this question. In failover scenarios where the firewall is involved there are particular commands that need to be configured to kill the active sessions going through the backup connection once the primary has been restored:
ip firewall fast-nat-failover
ip firewall fast-allow-failover
When a route table change occurs these commands will attempt to send a TCP RST to both ends for applicable sessions so they will be restored over the primary connection. You mentioned this particular traffic is not being NAT'd, so if that is the case and the traffic is allowed via an allow policy-class rule instead you will need the ip firewall fast-allow-failover command. Let me know if that does not resolve the issue.
Thanks,
Matt
Try updating your route-map to the following:
route-map Default_Route permit 10
match ip address Default_Route
set ip next-hop X.X.163.18
set interface null 0
This will ensure that the traffic only goes to X.X.163.18 and if that is not available it will drop the packet. This will keep it from trying to send that traffic across the MPLS circuit at all. When the Primary link comes back up, it should instantly start responding again.
Thanks,
Brad
nathanscott,
Were you ever able to resolve this issue? If so please come back to this post to update it and select a correct answer so other members can benefit from the solution.
Thanks,
Matt
Yes, thank you all for the help on this one.
--Nate