Forum Discussion

clazba's avatar
Icon for Nimbostratus rankNimbostratus
Mar 16, 2012

How to disable OAM when an existing APM policy is assigned to the same VIP

Hi Guys,



We have successfully deployed APM with OAM Support on V11.1 (via the tick box) on VIP with an existing APM Policy already assigned.




I have written an irule that disables the APM policy via ACCESS::disable based on source IP but there is a business requirement to disable OAM as well based on source IP.




Unfortunately we are forced to have OAM Support and a standard APM policy on the same VIP due to stringent architectural requirements so my suggestion to have two separate VIPs and issue a 302 redirect to the OAM VIP based on DGL lookups wasn't welcomed.




As far as I can tell there is no way to tell ACCESS::disable which policy to turn off?Any ideas if this is at all possible or in roadmap?


















2 Replies

  • Hi Claud,



    What about calling two different internal virtual servers? Else I don't have any bright ideas on this one if you can't use a separate virtual server. If no one else has a suggestion here, I'd try opening a case with Support. You can at least log an RFE.



  • clazba's avatar
    Icon for Nimbostratus rankNimbostratus
    Hi Aaron,



    I agree that having a separate OAM VIP (whether is called internally via an irule or redirected to via 302) seems the most logical way to go and one that would allow the customer to gradually migrate services from the current APM policy to OAM which is the customer ultimately wants to be! The issue with that would be duplication of administrative points where the logic would have to be implemented:


    A list of URLs/URIs to make decisions based on would have to have maintained on OAM as well as APM -- true this could be mitigated by using a sideband connection to query the OAM api from the BIGIP but from what I gather the limitation seems to be political more than architectural. The customer rolled out the design with two policies applied to the same virtual and steering away from that would take time and cost more in governance (even if it would actually simplify the task from a technical standpoint).



    Anyway I have made my reccomendations based on the above and raised an RFE as sugegsted, ball - as they say - is now firmly in their court :)



    Thanks for your help in confirming this.