Forum Discussion
MerryIT
Altocumulus
AltocumulusVirtual 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 ...
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
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
MerryITAltocumulus
AltocumulusI'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 what I just tested with same result :
- deleting VS, address list, and virtual address
- creating address list in partition A with IP 2.2.2.61
=> it appears as 2.2.2.61%2 , as partition A is using default route domain 2 - creating VS in partition A, assigning newly created address list
=> virtual address change from BLUE to RED after 30 seconds (with the logs mentionned above)
=> the status is "OFFLINE(enabled). The virtual address has no virtual servers"
As mentionned I need the VS in the A partition, not in common. I have a setup with 3 partitions : common, partition A, and partition B. Each has its own routing domain, because I need different default routes for each partition.
The result is exactly the same using a /Common address list with a VS in partition A.
- Paulius
MVP
MerryIT In my past experience with this it has never worked and I typically am in a situation where it has to be done now so I end up configuring individual virtual servers (VS) rather than opening up a ticket with F5 to see why it isn't working. My 2 cents on this one is you really should seperate it because in any instance where you want internal to work but not external you would not be able to easily achieve this. Seperating them also allows you to track how often each is used without having to create and iRule to log if it's an internal request or an external request.
