The requested pool member xxxxx was not found.

Hi Rob,

 

 

What is the status shown for these pool members in the F5 device hierarchy in SCOM, for the F5 device(s) discovered? Are the name-port pairs on the pool members discovered (in the SCOM F5 device hierarchy) matching those present in your deployment? After upgrading the F5 device(s) did you attempt to perform a re-discovery? There seems to be a slight inconsistence between your current F5 discovery configuration in SCOM and your deployment.

 

 

Probably a re-discovery of the F5 devices would clear the problem. Let me know if you need any assistance with re-discovering the devices, or if you see any inconsistencies.

 

 

Julian

Julian,

 

 

Thanks for the quick response. The status of the pool members in SCOM are just a white circle where as they are up/available on the F5. Ironically in SCOM the VS is up with a green check even thought there are no green pool memebers available in the VS. The name-port in SCOM shows PXC-ROID whereas on the F5 it is tcp/4004. This morning I removed the 2 LTM F5's from SCOM and then ran a new discovery for each and I'm still seeing the errors on the F5.

 

 

Rob

Rob,

 

 

From your latest post, where you mention that the virtual server port shows up in SCOM as PXC-ROID (e.g. UDP:4004), I can see that there might be a problem in our F5 Management Pack with correctly interpreting ('normalizing') this port. And for this matter we cannot correctly resolve the virtual server hierarchy in the SCOM health model, and then your underlying pool members end up not being monitored. That's at least my first guess to your problem, but I'll try to get a repro in our LAB and hopefully I'll be able to tell more. In the meantime, if you can send us the exact configuration of your virtual server as it is shown on the F5 device (not in SCOM), this will help us in trying to address the problem. In particular, we're interested in the name/port values defined on your virtual server and underlying pool members. Probably the best would be to run a qkview and send us the results. You can send this information to managementpack(at)f5(dot)com.

 

 

Thank you for your patience.

 

Julian

Rob,

 

 

We have a fix for the problem that you're having and this will be included in our upcoming release of the F5 Management Pack, later on this month (June 2010). As I mentioned in my previous post, the issue was related to the TCP/UDP port 4004 and its service-name (PXC-ROID) which couldn't be resolved by the F5MP discovery/configuration module. We updated our service-name-port dictionary in our F5MP to match the one shipped with the latest F5 device platforms, so most probably similar error conditions won't happen again.

 

 

We do our best to get this next maintenance release of the F5MP out ASAP, so bear with us and if in the meantime we could be of any help, let us know.

 

 

Thank you for your patience,

 

Julian

Julian,

 

Thanks for the update. We have multiple errors similar to this one but for different virtual services with different ports. Would you like additional examples so that we can validate they are failing becase of the same fix? In addition, does the big3d typically require updates for every released F5 mp. We're running F5 MP Version 1.7.0 and i see the latest is 2.1.0.43.

 

 

Thanks for your assistance!

 

Rob

Yes, if you can provide additional examples on the failures you get, we can make sure those would be all addressed with our hotfix. I strongly believe you should be safe with the upgrade, as we tried to sync up with the latest service-port dictionary on the BIG-IP, but an extra measure of caution is welcome in this case.

 

 

To answer your second question, we do include an upgraded version of the big3d agent occasionally, with new releases of the F5 Management Pack, when the added feature work or hotfixes require it. With our upcoming maintenance release, the big3d agent will be updated, as it has a few fixes addressing issues with discovering older BIG-IP platforms (v9.3.x).

 

 

Julian

Rob,

 

 

We have just released a new version of the F5 Management Pack that includes a number of fixes, including the one addressing the issue you've been having.

 

You can download this release from: http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/54/aft/1174022/aff/2301/afv/topic/showtab/groupforums/Default.aspx

 

 

Let us know if this works or if you still run into any issues.

 

 

And thank you for your patience through all of this!

 

Julian

Julian,

 

We installed the latest F5 MP, removed the F5 devices, discovered the F5 devices and we're still getting the errors for "The requested pool member xxxx was not found." Please let me know if you need additoinal informatoin.

 

 

Fri Jul 9 12:47:39 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (AcctSites_HTTP_Pool 172.18.9.9 8324) was not found.

 

Fri Jul 9 12:47:36 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (BIZTALKPRD_POOL_ALLPORTS 172.18.7.199 10672) was not found.

 

Fri Jul 9 12:47:34 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (AllPort_Pool_VAppCtx 172.18.10.45 8845) was not found.

 

Fri Jul 9 12:47:30 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (BIZTALKPRD_POOL_ALLPORTS 172.18.5.149 10404) was not found.

 

Fri Jul 9 12:47:27 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (AcctSites_HTTP_Pool 172.18.9.7 8070) was not found.

 

Fri Jul 9 12:47:21 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (DialOut_Access_AllPorts 172.19.120.4 14686) was not found.

 

Fri Jul 9 12:47:18 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (CEMIOpsProd_HTTP_Pool 172.18.9.7 12646) was not found.

 

Fri Jul 9 12:47:12 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (SGR_POOL_ALLPORTS 10.50.0.82 43453) was not found.

 

Fri Jul 9 12:47:09 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (HTTP_POOL_K2BDEV 10.50.0.36 23108) was not found.

 

Fri Jul 9 12:47:06 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (CEMIOpsProd_HTTP_Pool 172.18.10.110 13036) was not found.

 

Fri Jul 9 12:47:03 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (OKCINFPRD_POOL_ALLPORTS 172.18.4.226 38761) was not found.

 

Fri Jul 9 12:47:00 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (SGR_POOL_ALLPORTS 10.50.0.80 43328) was not found.

 

Fri Jul 9 12:46:57 CDT 2010 err local/okcbigip2 mcpd[3179] 01020036 The requested pool member (OKCINFPRD_POOL_ALLPORTS 172.18.4.227 38894) was not found.

 

Rob,

 

 

Apparently none of the ports in these unresolved pool members show up in our default port-service name normalization dictionary. And I checked this dictionary also on the latest BIG-IP platform builds. That makes me think that you may have custom entries in your /etc/services file, on your BIG-IP, mapping certain ports to service-names that we don't know of. The /etc/services file keeps the port -> service name mappings. So, if that's the case, we have a problem. Can you please verify your /etc/services file, and can you confirm that you have the following port mappings defined in it (just look for the port number):

 

 

8324, 10672, 8845, 10404, 8070, 14686, etc...?

 

 

If you do have custom mappings for these ports, the immediate workaround to unblock your discovery, would be to remove the custom mappings from the /etc/services file (and these are the mappings for the ports shown in the errors about the requested pool members not found. Would this be a blocker for you? Removing the custom mappings? Are you performing any business / data analysis in your network environment that specifically target those port mappings?

 

 

Let us know, and we'll decide what to do next.

 

Julian