Peplink Balance with Cisco SLA route

Product Discussion Peplink Balance
1

A client has reported that our Peplink Balance 380/Cisco ASA implementation did not fail over during testing. The Peplink is in drop in mode for ISP1 and proper NAT rules are configured for ISP2. I have looked through the firewall config and found an SLA configuration on a static route:

sla monitor 1
type echo protocol ipIcmpEcho 1.1.1.222 interface Outside_ISP1
sla monitor schedule 1 life forever start-time now
track 1 rtr 1 reachability
route Outside_ISP1 0.0.0.0 0.0.0.0 1.1.1.1.222 128 track 1
route Outside_ISP2 0.0.0.0 0.0.0.0 2.2.2.222 254

The interface on the ASA for ISP1 is plugged directly into the Peplink. There is nothing plugged into the ASA on the ISP2 interface.

1.1.1.222 is the default gateway for ISP1, which is a public, globally pingable IP address.

As I understand it, the Peplink is performing arp proxy to the ASA for the IP 1.1.1.222. This way the firewall will always send the traffic to the Peplink, no matter which link is up.

So, the second default route should never be used. The default gateway for ISP1 will always appear up even if traffic is routed through the ISP2 link.

I did notice something strange when performing a traceroute to this IP from the Peplink’s web interface:

Traceroute via ISP1 link:

traceroute to 1.1.1.1.222 (1.1.1.222), 30 hops max, 60 byte packets
1 1.1.1.222 (1.1.1.222) 19.556 ms 19.381 ms 19.294 ms

This is expected because 1.1.1.222 is the default gateway on ISP1. It should only be one hop.

Traceroute via ISP2 link:

traceroute to 1.1.1.222 (1.1.1.222), 30 hops max, 60 byte packets
1 1.1.1.222 (1.1.1.222) 32.624 ms 32.411 ms 33.682 ms

This is unexpected behavior. In order to get to the default route of ISP1 via ISP2 there should be many hops involved. The only thing I can think of is that the Peplink is tracerouting to itself because of the arp proxy used to trick the ASA into sending all the traffic to the Peplink. If that were true, however, the response times would be much less. Is the Peplink performing the traceroute correctly but displaying the results wrong?

Also, When does Arp proxy kick in? Is it used, while in drop in mode while traffic is routed out the main wan link (ISP1)? Or does the Peplink start proxying ISP1 gateway when traffic is failed over to the secondary WAN link?

Is there a way to view the arp table on the Peplink?

Thank you,

Ben

2

I don’t think the SLA configuration is even needed on the ASA. When ISP1 is in drop-in mode, we are performing MAC address pass-through from the ASA to the ISP1 default gateway. This means that all traffic leaving the Balance 380 on ISP1 will appear as though it were coming directly from the ASA and not the Peplink.

The Balance 380 constantly monitors the state of all connections, and if it detects a failure on ISP1 then all traffic will be NAT’d and routed out ISP2 instead.

3

Right, it is not needed and there is more to this story. ISP1 is Comcast business coax which assigns the default gateway’s IP address to the CPE modem. Which means the SLA route was pinging a local device, making the SLA rule useless from the beginning. However, tracerouting to ISP1’s gateway via ISP2 on the Peplink, should have listed more hops. I was able to get the correct MAC address of the Peplink by turning on SSH access and issuing a ‘get system’ command.

Thanks for your time on this.

4

I think the Balance is just being smart and knows the path is much shorter going through ISP1. If ISP1 actually failed, you would see all the hops to try and get back to it from ISP2.

I attribute the difference in latency to the “thinking” time it takes before deciding to send it out ISP1 vs ISP2.