Forum Discussion
MerryIT
Altostratus
AltostratusVirtual address from address list is down after assignment to VS
Hello,
I'm trying to use address list on a VS in order to have the VS answering to both internal private IP address and external public address.
First of all, the privilege for address list is not very handy, since you need to be Firewall Manager to be able to create one (and it doesn't work, I tested) but you absolutely need to be administrator to assign it to a VS (manager role is not enough). So in the end only administrator can handle and assign address lists.
Then, right after I assign the address list to the virtual server, the corresponding virtual addresses are changed from BLUE to RED, the monitor going from UNCHECKED to DOWN as witnessed in /var/ltm/log. The WebUI when I hover over the virtual address status tells "the virtual address has no virtual server".
And indeed I'm unable to reach any of the IP addresses, there is no ARP and no traffic received for the IP on the interface.
Am I missing something here ?
the doc seems pretty straightforward : 1- create the list 2- assign the list and done.
Here is an update after I opened a case.
- this is actually a known behavior, and it is documented here Route Domain ID specified in traffic matching criteria address list doesn't take effect on Virtual Server IP (f5.com)
- so after you assign your address list to the VS, its create a traffic-matching-criteria object that is by default attached to the default domain
- you can change the route domain from CLI
- then the virtual IP is finally UP, and answering ARP requests
In my case, I also have this other issue since I'm also using ASM policy on the VS: Security log profile cannot be assigned to a virtual servers using address list, traffic matching criteria, TMC (f5.com)
- it is NOT recommended to use address list on VS if you intend to use ASM on the VS as well
- there is a workaround to use it anyway, but only for experimental purpose
MerryITI've tried the following :
in partition A : create address list, and assign to VS in partition A as well => virtual addresses are down
in common partition : create address list, and assign to VS in partition common as well => virtual addresses are UP!
mix : create address list in common partition, and assign it to VS in partition A => virtual addresses are down
=> I do need to assign address lists to my partition A VS, I can't create them in /common, due to different route domains.
How to achieve that ?
Hi MerryIT ,
I have tested your scenario :
>> Create address list ( list of Virtual server IPs ).
>> Create Virtual server with this Address list as a destination IP.
>> and yes I found it created in virtual address ( this is expected ) and in unknown status.Till now this is your implementation , right ?
- let me know your current TMOS version
- send a sample of your logs- MerryIT
I'm using version 17.1.0.1.
I believe it is something with the partitions / route domains
I've changed the sensible info but here is the log : the warning is when I assign the address list.
Oct 3 15:02:10 lb-01 warning mcpd[6053]: 01071859:4: Warning generated : Traffic Matching Criteria's inline destination address has been set to any4 from any6 to match inline source address' address family.
Oct 3 15:06:04 lb-01 notice mcpd[6053]: 010719e7:5: Virtual Address /NOPROD/1.1.1.61 general status changed from BLUE to RED.
Oct 3 15:06:04 lb-01 notice mcpd[6053]: 010719e8:5: Virtual Address /NOPROD/1.1.1.61 monitor status changed from UNCHECKED to DOWN.
Oct 3 15:06:04 lb-01 notice mcpd[6053]: 010719e7:5: Virtual Address /NOPROD/2.2.2.61 general status changed from BLUE to RED.
Oct 3 15:06:04 lb-01 notice mcpd[6053]: 010719e8:5: Virtual Address /NOPROD/2.2.2.61 monitor status changed from UNCHECKED to DOWN.HI MerryIT ,
For this warning , this is a Bug in your version as shown here : https://cdn.f5.com/product/bugtracker/ID753712.htmlbut as clarified this shouldn't deliver any impact to your system.
So can you try again :
>> Delete your current setup ( Virtual addresses / virtual servers if exists ) then delete the address list.
>> re-create the address list again.
>> Create simple Virtual server and attach the address list in destination.
>> Check your virtual address , you should see them in blue status.
I think you configure all objects in Common partition ?
re-try this and let me know.
- MerryIT
Here is an update after I opened a case.
- this is actually a known behavior, and it is documented here Route Domain ID specified in traffic matching criteria address list doesn't take effect on Virtual Server IP (f5.com)
- so after you assign your address list to the VS, its create a traffic-matching-criteria object that is by default attached to the default domain
- you can change the route domain from CLI
- then the virtual IP is finally UP, and answering ARP requests
In my case, I also have this other issue since I'm also using ASM policy on the VS: Security log profile cannot be assigned to a virtual servers using address list, traffic matching criteria, TMC (f5.com)
- it is NOT recommended to use address list on VS if you intend to use ASM on the VS as well
- there is a workaround to use it anyway, but only for experimental purpose
