Forum Discussion
Virtual address from address list is down after assignment to VS
- Oct 30, 2023
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
- MerryITOct 03, 2023Altostratus
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.- Oct 03, 2023
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.- MerryITOct 03, 2023Altostratus
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.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com