ISP redundancy - traceroute/ping question..

[D_TK]

Good day everyone.

I've brought in a 2nd DIA link and have configured ISP redundancy on my cluster in primary/backup mode (new circuit is backup).  The config looks fine, and SV monitor shows status OK for both.  I can connect from the outside directly to my new circuit's IPs so i know that routing is working fine.

From the gateway, if i try to ping or traceroute through the new interface, i get no response.  The interface for the new circuit is "eth4".  The syntax i'm using is:

ping -I eth4 9.9.9.9

tracert -i eth4 9.9.9.9

The logs show this traffic as going out the correct interface, sourced with the correct NAT.  If i try these commands without the interface specification, they go out the default route (primary ISP redundancy interface), and receive responses.  fw ctl zdebug drop does not show anything salient during the failed attempts.

Can someone please let me know what i'm missing here?  Version is R81.10 HF 55

Thanks.

[the_rock]

If you run ip r g x.x.x.x (replace with right IP), do you see it go out right interface?

[D_TK]

It shows the gateway's default route, which is currently the primary DIA circuit in the ISP redundancy group for that device..which seems normal.  How can i test the "backup" circuit routing without actually making it the "primary"?

[Vladimir]

try tcptraceroute with "-i" and "-s" sourcing from the address of 2nd ISP assigned to the gateway/cluster

You may run tcpdump on the same interface using original destination from the command above as your source filter.

[D_TK]

Thanks.

The command i used was: tcptraceroute -i eth4 -s (interface ip eth4) 9.9.9.9 and i had this running: tcpdump -i eth4 host 9.9.9.9

The IP that's redacted is the IP i used on the command - the interface IP for eth4

Not sure what's going on.

thanks

 

[Vladimir]

I do not recall the particulars of ISP redundancy configuration, but it stands to reason that if it is an active/standby setup, you only have a single default gateway and it'll be your primary ISPs next hop until it fails.

If the above is correct, you have to force the next hop for specific destination to be that of 2nd ISP's connected router's IP. In that case, perhaps following sequence will work for your test:

1. Can you ping adjacent IP address of the 2nd ISP router when sourcing from eth4 IP address?

2. If [1] is a "Yes", pick any, least likely to be used in production, public IP address and add a static route to it on your cluster member, using your 2nd ISPs IP as a gateway.

3. repeat the test.

[D_TK]

I was able to add some /32 routes through ISP 2 and they worked as planned.  I think your reasoning about how it works in active/standby mode is spot on.

thanks

[Vladimir]

Happy I was able to help.

Cheers,

Vladimir