Stop alive requests in a dead realm

[Santiago Balaguer García]

Hi,

 

I am using freeradius 2.1.3 for my AAA servers. I have a little problem when a third-patner RADIUS is dead. My problem is my freeradius send the following status packect every 

2-5 seconds.

 

Sending Access-Request of id 77 to 200.160.126.23 port 1812
        User-Name := ""
        User-Password := ""
        Service-Type := Authenticate-Only
        Message-Authenticator := 0x00000000000000000000000000000000
        NAS-Identifier := "Status Check. Are you alive?"
Waking up in 1.0 seconds.
Cleaning up request 3 ID 151 with timestamp +723
Waking up in 2.9 seconds.


I want to avoid this test because my partner tell me that I send too many trafic ('operator' is the realm name).

 

proxy.conf file

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

proxy server {
        default_fallback = yes
}

home_server localhost {
        type = auth
        ipaddr = 127.0.0.1
        port = 1812
        secret = testing123
        require_message_authenticator = no
        response_window = 20
        zombie_period = 40
        revive_interval = 120
        status_check = none
        check_interval = 30
        num_answers_to_alive = 3
}

home_server virtual.example.com {
            virtual_server = virtual.example.com
}

home_server_pool my_auth_failover {
        type = fail-over
        home_server = localhost
}


realm example.com {
        auth_pool = my_auth_failover
}

realm LOCAL {
        type            = radius
        authhost        = LOCAL
        accthost        = LOCAL
}
realm operator {
        type            = radius
        authhost        = 200.160.126.23 :1812
        accthost        = 200.160.126.23 :1813
        secret          = my_secret
        strip
}


_________________________________________________________________
¿Quieres ver los mejores videos de MSN? Enciende Messenger TV
http://messengertv.msn.com/mkt/es-es/default.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20090603/b4956df8/attachment.html>