Guest User!

You are not Sophos Staff.

[CONFIRMED] [7.385] Multipath rules issue

Hi,

we have try the new features "MULTIPATH RULES & UPLINK BALANCING....." on a ASG appliance 220 with OS v 7.380 for testing.

We are using two different adsl lines, first bound on eth1 and second on eth2. (eth0 is for internal network)

The configuration we used in our case is as follows :

A) Uplink Balancing : 

Type: Multipath
Interfaces: eth1 (first)
                eth2 (second)
Automatic monitoring: ON

--------------------------------------------------------------

B) Multipath rules :

1- Internal Network --> Any --> Any --> ADSL1 (eth1, itf.persistence by interface) 

2- Internal Network --> Http --> Any --> ADSL2 (eth2, itf.persistence by interface)

--------------------------------------------------------------

First only rule 1 is active and we see that correctly traffic comes through ADSL1 interface.

After that we have activated the second rule and also correctly we see that now traffic went out via ADSL2 interface.

Then we deactivated second rule.
Now we aspect that traffic go out through ADSL1 again but strangely it still leave via ADSL2!!
We disabled both rules but it persists to go out through ADSL2!

Can some one help us?

many thanx
  • Seems the interface is marked as unusable, means there is an connectivity error.
    Whats in the service_monitor log?

    Can you post the output of the command "/var/mdw/scripts/service_monitor status"
  • Hi,

    this is the output

    BETA:/root # /var/mdw/scripts/service_monitor status
    Checking for service ASG Load Balancing Service Monitor               running
    ALIVE:
    [multipath 0] TRACEROUTE 192.168.2.29 since Wed Jan 21 09:03:45 2009

    DEAD:
  • Ok this has allowed me to understand the reason for the problem ...
    In Uplink balancing page, I have set "Automatic monitoring". In this way ASG is able to autoconfigure a host to ping on the Internet for ADSL1 but it isn't able for ADSL2.
    So in dashboard I see link "ERROR" for ADSL2.

    If this can help, this is the result of a traceroute from both ADSL lines :

    ADSL1 :
    traceroute to 192.58.128.30 (192.58.128.30), 30 hops max, 40 byte packets
     1  10.4.17.49 (10.4.17.49)  0.322 ms   1.060 ms   0.610 ms
     2  10.4.16.1 (10.4.16.1)  0.525 ms   1.591 ms   0.506 ms
     3  192.168.2.17 (192.168.2.17)  1.105 ms   0.550 ms   1.204 ms
     4  192.168.0.105 (192.168.0.105)  1.164 ms   2.204 ms   1.752 ms
     5  192.168.255.232 (192.168.255.232)  1.664 ms   2.604 ms   2.015 ms
     6  x.y.z.w (A.B.C.D)  34.335 ms   32.906 ms   33.198 ms
     7  r.s.t.u (E.F.G.H)  43.636 ms   48.162 ms   45.743 ms
     ...........


    ADSL2 :
    traceroute to 192.58.128.30 (192.58.128.30), 30 hops max, 40 byte packets
     1  192.168.1.254 (192.168.1.254)  41.614 ms   40.970 ms   36.432 ms
     2  * * *
     3  f.g.h.i (A.B.C.D)  42.351 ms   42.235 ms   41.788 ms
     4  l.m.n.o (E.F.G.H)  48.313 ms   47.073 ms   49.436 ms
     ..................


    For ADSL2 the 2nd HOP is not "unreacheable"..... Can this cause the problem? [H]

    -thx-
  • Mhm thats strange. No this should not be a problem,
    service_monitor uses the third pingable hop.

    Whats in /etc/service_monitor.conf ?

    Can you restart the service montor with "/var/mdw/scripts/service_monitor restart",
    wait some minutes and mail me the log file /var/log/service_monitor.log afterwards
    to uweber@astaro.com ?
  • ok

    for now this is the /etc/service_monitor.conf 

    [config]
      branding=yes
      tcp_timeout=5
      udp_timeout=5
      icmp_timeout=5


    [multipath 0]
      #REF_PuPwOVFGAZ
      service auto://traceroute:
      interval 15
      bind 10.4.17.54

      action confd_link REF_PuPwOVFGAZ
      action proc multipath 0


    [multipath 1]
      #REF_iqCxsdOuty
      service auto://traceroute:
      interval 15
      bind 192.168.1.66

      action confd_link REF_iqCxsdOuty
      action proc multipath 1


    As soon you will receive also the service_monitor.log on your mail address uweber@astaro.com

    thx
  • Problem occured due activated IPS on ADSL Modem.

    Changed code of traceroute to send RFC conform ping packets.
    Will be fixed in final 7.400 version.

    Thanks for finding this bug!