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

Multipath Rules vs Static Routing (Policy Routes) ?

Dear Experts,

We have 3x Internet access lines using Uplink Balancing.

We are using services for online file storage accessed by WebDAV (HTTPS) mostly.

I want do force all the traffic on HTTPS to destination i.e. "PROVIDER.com" to go over our dedicated line (same upload and download), let's call it "line1".

What is the best strategy in performance regarding the Astaro overload? And what is the difference in between?:

a) using Interfaces&Routing > Static Routing > Policy Rules (Any>Any>HTTPS>provider.com>interface "line1")

or

b) using Interfaces&Routing > Interfaces > Multipath Rules (Any>HTTPS>provider.com>line1)

Thank you in advance!
Uwe


This thread was automatically locked due to age.
Parents
  • Hi Bob, RED server hosts an inbound connection - RED client makes an outbound connection (unless I'm completely misunderstanding things).

    At the datacenter we have a single ISP feed, and the datacenter UTM acts as server.  No need for dyndns or the like since we just have the one connection there of course.  On the client side, the offices with two ISPs have a UTM acting as client, so it automatically fails the RED initiation over to the secondary ISP if the primary fails.  The only issue was how to ensure that - when both ISPs are up and the secondary line has the default route - the RED connection was forced to go out over the primary low-latency line.

    Since the UTM doesn't follow standard routing practices, the availability group is a way to simulate the same concept and ensure that invalid routes are properly dropped from the table (in effect) once one of the ISPs goes down.  I still can't understand why (and support was stumped as well) UTM even has an option to specify the metric in static routes since they never invalidate themselves - what good is it?  That KB I posted appears to be the only way to really set up proper failover routing (other than multipath, which is limited only to client traffic and not to the UTM's own routing table for its own traffic including RED initiation).

    From everything I've seen and read over the last 6 months it doesn't appear that UTM has any other facility to achieve this - although I readily admit that it could have easily been overlooked while trying to manage a nationwide UTM rollout that happened to coincide right with the disastrous slew of bugs that has been 9.3!

    At this point, we have 3 rather basic requirements at the client offices:
    1) handle two ISPs
    2) provide some way to designate one ISP as the default route (most systems you'd simply set up a pair of default routes with one having a lower metric than the other - but in the UTM world it appears that this is done by using uplink balancing and setting the weights to 100 and 0 respectively - seems to be working)
    3) provide some way to ensure that RED initiation and Lync traffic flow over the non-default ISP (again normally done via static routing and/or PBR but in the UTM world you have the added wrinkle of establishing availability groups per the KB - multipath would be an option if it affected RED targeting but it doesn't).

    If you can find me a way to control the interface that RED client initiation happens over using multipath I'd be open to switching, but at this point I think the availability group option is our only choice...

    Thanks again for all the help you provide on these forums by the way!
    Wes
Reply
  • Hi Bob, RED server hosts an inbound connection - RED client makes an outbound connection (unless I'm completely misunderstanding things).

    At the datacenter we have a single ISP feed, and the datacenter UTM acts as server.  No need for dyndns or the like since we just have the one connection there of course.  On the client side, the offices with two ISPs have a UTM acting as client, so it automatically fails the RED initiation over to the secondary ISP if the primary fails.  The only issue was how to ensure that - when both ISPs are up and the secondary line has the default route - the RED connection was forced to go out over the primary low-latency line.

    Since the UTM doesn't follow standard routing practices, the availability group is a way to simulate the same concept and ensure that invalid routes are properly dropped from the table (in effect) once one of the ISPs goes down.  I still can't understand why (and support was stumped as well) UTM even has an option to specify the metric in static routes since they never invalidate themselves - what good is it?  That KB I posted appears to be the only way to really set up proper failover routing (other than multipath, which is limited only to client traffic and not to the UTM's own routing table for its own traffic including RED initiation).

    From everything I've seen and read over the last 6 months it doesn't appear that UTM has any other facility to achieve this - although I readily admit that it could have easily been overlooked while trying to manage a nationwide UTM rollout that happened to coincide right with the disastrous slew of bugs that has been 9.3!

    At this point, we have 3 rather basic requirements at the client offices:
    1) handle two ISPs
    2) provide some way to designate one ISP as the default route (most systems you'd simply set up a pair of default routes with one having a lower metric than the other - but in the UTM world it appears that this is done by using uplink balancing and setting the weights to 100 and 0 respectively - seems to be working)
    3) provide some way to ensure that RED initiation and Lync traffic flow over the non-default ISP (again normally done via static routing and/or PBR but in the UTM world you have the added wrinkle of establishing availability groups per the KB - multipath would be an option if it affected RED targeting but it doesn't).

    If you can find me a way to control the interface that RED client initiation happens over using multipath I'd be open to switching, but at this point I think the availability group option is our only choice...

    Thanks again for all the help you provide on these forums by the way!
    Wes
Children
No Data