Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 2547 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Uplink Balancing / Multipath: No Fallback

Xavier2
Hi

ASG220, UTM9 (9.106-17) with two WAN-Interfaces
Uplink Balancing:
Interface1: Weight 100 
Interface2: Weight 0
Persistence Timeout: 1min (smallest possible)

Multipath Rule:
All Services from Internal LAN to Internet IPv4 balanced to just Interface2
with persistence by connection.

In normal operation (both interfaces up) all traffic goes through Interface2. Ok.
With Interface2 disabled all traffic goes through Interface1. Fine too. ;-)

But after Interface2 comes up again some traffic doesn't move back to Interface2, i.e. pings continously sent don't move back.
Why that? There's no connection with ICMP that could be persistent!?

Even worse, traffic from UTM's VoIP-Gateway doesn't move back too.

Best regards
Xavier


This thread was automatically locked due to age.
  • 0
    You shouldn't need the weighting, but didn't you write that backwards?

    However, it sounds like you would have been better off putting Interface1 into 'Standby interfaces' instead of using weighting or a multipath rule - have you tried that?

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi Balfson.

    However, it sounds like you would have been better off putting Interface1 into 'Standby interfaces' instead of using weighting or a multipath rule - have you tried that?


    Yes, I tried that and it works but there's traffic from another internal LANs that shall go other Interface1. So standby is no solution.


    Xavier
  • 0
    Since you're using persistence by connection, have you tried changing the weighting so that both WAN connections are weighted the same?  You might find a five-minute setting for the Persistence-Timeout to be more-robust.

    Cheers - Bob
  • 0 in reply to BAlfson
    Since you're using persistence by connection, have you tried changing the weighting so that both WAN connections are weighted the same?  You might find a five-minute setting for the Persistence-Timeout to be more-robust.

    Cheers - Bob


    Not by now, but why should this succeed?
    Let me explain it with some other words.
    Almost all traffic should flow over Interface1 except for some traffic bound explicitly to Interface2. 
    In case of a failure of Interface2 all traffic should go through Interface1.
    But after coming Interface2 up again the traffic bound to Interface2 should flow through Interface2 as soon as possible.
    But this don't happen. Even constantly sent pings remain on Interface1.

    Xavier
  • 0
    Almost all traffic should flow over Interface1 except for some traffic bound explicitly to Interface2.

    I maintain the recommendations in Post #4.  After the rule binding specific traffic to Interface2, bind Any->Any->Any traffic to Interface1.

    Cheers - Bob
  • 0
    Hi Bob,

    adding a Any->Any->Any traffic to Interface1 as last rule was a succes concerning SIP UDP datagramms. They fall back to Interface2 almost immediately after its up again.

    So thanks for your advice.

    But unfortunately ICMP Pings don't fall back. 
    I just discovered that it even takes quite a long time before they fall over to Interface1 when Interface2 is shut down. The UTM answers with 'Host Unreachable' for almost half an hour before UTM uses Interface1 and the pings go through again (Interface1).

    SIP UPD immediately fall over and back although they're sent with almost same frequency.

    During all experiments persistence by connection was set to 1min.

    Xavier
  • 0
    The UTM does have mysterious behavior when it comes to ping and traceroute, and I suspect that it's not intended behavior.  Since you have a paid license, please have your reseller submit a Support request to Sophos so that they can attempt to find the bug.

    Cheers - Bob