Forum Discussion

Adrian_1807's avatar
Adrian_1807
Icon for Nimbostratus rankNimbostratus
Dec 14, 2010

error assigning diferent pools on an iRule

Hi.

 

 

We have faced a problem with an iRule.

 

 

This is the iRule:

 

 

Dec 10 13:42:10 tmm tmm[1729]: Rule regla_wap_mms_v1_pt_chatv4_data : Contenido ÂÀ À@Ohttp://213.229.187.118/chat/v4-c/chat.w.wml?sid=b5b2384d1&a=rl&c=62919849366003µhttp://motorola.handango.com/phoneconfig/E1000/Profile/E1000_WITH_BEARER.rdfÀ Dec 10 13:42:10 tmm tmm[1729]: 01220001:3: TCL error: regla_wap_mms_v1_pt_chatv4_data - Address in use (line 1) invoked from within "pool pool_WAP"

 

 

 

And the iRule:

 

 

when CLIENT_ACCEPTED {

 

set cliente [IP::client_addr]

 

if {[matchclass $cliente equals $::dg_wap]} {

 

pool POOL_WAP_v1_PT

 

}

 

if {[matchclass $cliente equals $::dg_mms]} {

 

pool POOL_MMS_v1_PT

 

}

 

}

 

when CLIENT_DATA {

 

set contenido [UDP::payload 500]

 

if {$contenido contains "213.229.187.118"} {

 

log local0. "Contenido $contenido"

 

pool pool_WAP

 

log local0. "Chat"

 

}

 

}

 

 

The traffic start being balanced to a pool regarding client IP, but for a specific kind of traffic, it must be balanced to a diferent pool.

 

 

The first part of the irule seems to work fine, but when second part (CLIENT_DATA), has to be applied, it crashes, and the error above is shown. Do you know what that error means???

 

 

I understand there is a problem when assigning to the pool pool_WAP. At that point, one connection has been established to one of the pools of ther CLIENT_ACCEPTED part, and it seems to crash when trying to assign same connection to another pool.

 

 

But, the thing is I am not very sure of that behaviour. I have done several tests with other protocols, assigning diferent pools to the connection in the same iRule, i have never seen that error, so i am not very sure of what it meant.

 

 

Have you ever seen that error???

 

 

Do you know what can be happening??

 

 

 

Thank you very much in advance.

 

 

BR

 

 

 

1 Reply

  • Hi Adrian,

     

     

    I think this is a cosmetic issue only as described in an unpublished CR, CR69801. I expect the connections will work regardless of the TCL error. You should be able to eliminate the error using a few different steps:

     

     

    - move the code from CLIENT_DATA to CLIENT_ACCEPTED. The UDP payload should already be available in CLIENT_ACCEPTED.

     

    - create a custom UDP profile with idle timeout set to immediate

     

     

    Aaron