iCall to disable VIP and self IP

Hi Piotr,

very good question. There is maybe a solution for disabling the VIP, but the combination VIP/Self IP is the challange I fear.

What bout the following:

• Create two new pools a: Pool "gateway" - containing the gateway and a specific monitor b: Pool " upstream" - containg the upstream devices and a specific monitor.

The health check will mark those pool as available until one are all combination will fail. As soon there will be a status change of a pool (member) or node (if monitoring is selected) a messages will be generated in /var/log/ltm i.e. "notice mcpd[xyz]: 123456:7: Pool /Common/xxxx member /Common/xxxx:80 monitor status up."

Rather using iCall you have the abillity to execute a tmsh command by modifying the "user_alert.conf" file. Example:

alert local_pool_http_x_y_Z_enabled "Pool /Common/xxxx member (.*?) monitor status down." { exec command="tmsh modify net interface x.y disable" }

Its may woth to test it and see if it s working. But make sure that the monitoring traffic is using the management route not a route via an interface which gets been disabled based on a VS down message.

Cheers and regards, Patrick

Hi,

Thanks a lot for this idea. Not sure how to make pool with more than member to go down when only one member is down - or I am missing something obvious here? So what do you mean by "The health check will mark those pool as available until one are all combination will fail"

So how this second pool with few devices can be used here?

Other issue is self IP - seems that there is no way to disable just self IP, only interface can be disabled - Am I right?

That is a bit to harsh method - interface can have many self IPs so being able to disable only specific self IP is the case - but if I am not wrong that is not possible?

Is iCall not better when used with periodic handler checking number of up members? So there is no dependence on log messages for both making VIP/interface down and bringing it back?

Piotr

Hi Piotr, i´ve done only little things with iCall and yes, there is no dependence on log messages.

With regards to your question: "seems that there is no way to disable just self IP". What about to shift the self ip´s into a "pseudo" VLAN in case gateway/upstream device is not responding?

Disabling the VIP can be achieved by issuing the following command: “modify ltm virtual-address x.x.x.x enabled no”

With regards to the pools: As far as I understood the gateway/upstream pools will be only configured to check a status of some services i.e. gateway reachable (yes/no) – upstream reachable (yes/no). If any of the monitor is replying with a “no” -> “down” some kind of action should follow. Action A = Disable VIP (no ping or ARP reply) -> “tmsh modify ltm virtual-address x.x.x.x enabled no” Action B = Disable external self IP and internal self IP (simultaneously) -> Shift self ip´s into a pseudo - non productive vlan –> “tmsh modify net self x.x.x.x vlan 123”

Would that make sense? Not sure if I understood it right :-)

Best regards, Patrick

Great idea about pseudo VLAN - should be the solution. Will test it.

Considering VIP it's easy (be aware that at least on 11.5.3HF2 running as VA on VMWare just disabling VIP do not make it really dead - I can still ping VIP and access VS provided content! Only ARP disable seems to work reliably - don't know if it's only a case on VA and works OK on physical BIG-IP).

Regarding test pool, seems that one pool should be OK. Member will be gateway node with monitor for it's IP and second, third... transparent monitors for devices behind DG. With Availability Requirement set to All pool should go down in case DG stops responding or any of upstream devices stops responding - Am I right here?

Piotr