Forum Discussion

Chris_Phillips's avatar
Chris_Phillips
Icon for Nimbostratus rankNimbostratus
Oct 03, 2006

voyeuristic pool monitoring

Hi all,

 

 

Unless i'm very much mistaken there is no way at all within the LTM's to make them snat their monitor traffic. As such whilst we can happily use a snatpool or such on a virtual server and have it work great, if our monitor traffic needs to also come from that location, e.g. due to firewall or routing rules, then without snatting that traffic we are up a certain creek without a certain implement.

 

 

As such i'm trying to find alternative (and hopefully elegant) ways to monitor these remote sites. i'm only on 9.1.1 at the moment, but looking at the additional iRule commands in 9.2 i'm wondering how feasible it is to mark a pool up or down based on the responses we are getting back from the remote site. we have a critical need to monitor the pools, get can't reach them effectively outside of the application trafic itself. Initially i am looking at replicating TCP or basic HTTP monitoring of a pool (which are all HTTP servers as far as this is concerned.) for now i'm happy to assume a node is up if i get a response packet at all, but may want to go further.

 

 

is this the sort of thing that anyone is already doing with LB::down and other commands? does anyone have any examples to look at? do i really need 9.2+ to achieve this? i just really want to achieve a syslog entry / SNMP trap / red light from whatever voyeuristic tests i can do. as there is no alternative service available and each pool only has a single member i may as well keep throwing traffic at the "down" node just in case i'm wrong.

 

 

the lack of monitor snats or direct monitors that function like this appear to be a fairly sizeable drawback in LTM land... are there any plans for inclusion of these features or do F5 not belive they are justified requests?

 

 

Thanks as always

 

 

Chris
application delivery
dev
devops
iRules

4 Replies

Sort By
  • Chris_Phillips's avatar
    Chris_Phillips
    Icon for Nimbostratus rankNimbostratus
    Oct 04, 2006
    well the traffic is coming from a snat pool, but even if we were doing an automap then that would snat it to the floating ip not the self ip's. obviosuly if a monitor was coming from a single snat address on both an active and a passive box then monitoring is (presumably) impossible.

     

     

    my particular situation is that we have been allocated a large ip range within a third parties network. this range bears no relation to our own range, but is required to be used for their firewalling / routing. the address space therefore lives purely within a virtual space in the LTM's. we would then have to SNAT our requests on a perimeter firewall into the address space on the LTM's. this is possible sure, but not fun.

     

     

    in addition to this we naturally want to test the remote applications as far as possible, but that in itself is hard as the requests required are all based on session id's and unique identifiers. if we make a request for the same session id (i.e. with an http monitor) then the remote party starts complaining as their IIS logs fill with HTTP 500's and in their opinion appear to suggest that someone is trying a DOS on them (!!). if we could instead just watch the respsonses to live traffic then implicitly we are covered to the full depth of each nodes service.

     

     

    It does seem strange to monitor a node / pool based on tests that do not represent the live usage... but obviously that leads to much more complex grounds.

     

     

    Cheers

     

     

    Chris
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Oct 04, 2006
    Hi Chris -

     

     

    I'll just chime in to answer your question as to why we don't have the ability to SNAT monitor traffic:

     

     

    Monitor traffic is sourced from the non-floating self-IP for each unit in a redundant pair, since each unit will be performing its own independent health checks. (If a monitor instead used a floating address as a sourceIP, the standby box would never get a response, so all the nodes would be marked DOWN until after that unit became Active -- obviously not an ideal situation on failover for all nodes to be marked DOWN on the newly active unit.)

     

     

    SNATs, on the other hand, are typically configured to use floating self-IPs (or SNAT-defined shared address) to maintain consistency on failover, so you would need to have a firewall rule allowing all 3 addresses to access the nodes.

     

     

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Oct 04, 2006
    I was thinking of a standalone unit as far as the source IP's used for monitoring versus load balancing traffic...

     

     

    If the relatively static testing functionality of HTTP monitors isn't getting far enough into your application (for example you are only able to check the front end web server, but want to check if the app server or db are responding), you could consider using a script on your app server which performs a more complicated test and then have it update a page on your front end web server. You could then configure a monitor that checks for an up/down message in the page content.

     

     

    Aaron
  • Chris_Phillips's avatar
    Chris_Phillips
    Icon for Nimbostratus rankNimbostratus
    Oct 04, 2006
    well these services are not managed by us, they are a third party we communicate with so scripted monitors aren't possible. essentially if we see any traffic coming back from the server we can assume it's up but i was really after thoughts on how best to interpret live traffic if possible.

     

     

    thanks for the thoughts, has given me some food for thought certainly, it's not like there's a perfect solution all round for the sort of constraints imposed upon us.