Bug ID 423294: LTM Virtual Servers in a non-zero route domain that contain a dot or colon in name will incorrectly be marked down

Last Modified: Dec 07, 2023

Affected Product(s):
BIG-IP GTM, LTM(all modules)

Opened: Jun 14, 2013

Severity: 2-Critical

Related Article: K14502

Symptoms

Virtual Servers will be marked down if the LTM Virtual Servers in a non-zero route domain that contain a dot or colon in the name.

Impact

The Virtual Server status will be incorrectly marked as red and not used in load balancing decisions.

Conditions

The Virtual Server name must contain a '.' or ':' and the Virtual Server must be on a non-zero route domain.

Workaround

Workaround 1: Modify the Virtual Server name to not contain a '.' or ':'. Workaround 2: This workaround involves changing the GTM configuration. To make the config work properly, the GTM has to be configured with 1 server stanza for each route domain on the ltm that has virtual servers. So for instance, if the LTM is configured with the following self IP addresses (3 self IP addresses in default RD, RD1, and RD2): net self 10.5.76.239 { address 10.5.76.239/24 allow-service all traffic-group traffic-group-local-only vlan vlan-576 } net self 10.10.11.39%2 { address 10.10.11.39%2/24 allow-service { default } traffic-group traffic-group-local-only vlan vlan-3273 } net self 10.10.10.39%1 { address 10.10.10.39%1/24 allow-service { default } traffic-group traffic-group-local-only vlan vlan-3270 } and virtual servers in each RD: ltm virtual vs.rd0.dottest { destination 10.5.76.39:http ip-protocol tcp mask 255.255.255.255 pool p1 profiles { tcp { } } vlans-disabled } ltm virtual vs.rd1.dottest { destination 10.10.10.39%1:http ip-protocol tcp mask 255.255.255.255 pool p1 profiles { tcp { } } vlans-disabled } ltm virtual vs.rd2.dottest { destination 10.10.11.39%2:http ip-protocol tcp mask 255.255.255.255 pool p2 profiles { tcp { } } vlans-disabled } Then the GTM has to be configured as: gtm server /Common/B3600-R18-S39-RD0.lab.ss.example.com { addresses { 10.5.76.239 { device-name B3600-R18-S39.lab.ss.example.com } } datacenter /Common/DC1 monitor /Common/bigip virtual-server-discovery enabled } gtm server /Common/B3600-R18-S39-RD1.lab.ss.example.com { addresses { 10.10.10.39 { device-name B3600-R18-S39.lab.ss.example.com } } datacenter /Common/DC1 monitor /Common/bigip virtual-server-discovery enabled } gtm server /Common/B3600-R18-S39-RD2.lab.ss.example.com { addresses { 10.10.11.39 { device-name B3600-R18-S39.lab.ss.example.com } } datacenter /Common/DC1 monitor /Common/bigip virtual-server-discovery enabled } This creates 3 servers, 1 for each RD. Each server will then only discover and probe *ONLY* the virtual servers in the route domain. NOTE: Remove the 'expose-route-domains yes' option from the server stanza. If that is left 'on', then each server will list ALL the virtual servers on the LTM, creating duplicates. Furthermore, the virtual servers in a given route domain that does not match the route domain of the server will be marked down. For example: -- on server 10.5.76.239, in route domain 0, all the virtual servers in RD1 and RD2 will be red. -- on server 10.10.10.39, in route domain 1, all the virtual servers in RD0 and RD2 will be red. -- on server 10.10.11.39, in route domain 2, all the virtual servers in RD0 and RD1 will be red.

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips