Forum Discussion
Nimbostratusrouted environment
I needed to create a virtual with pool members to an ltm device. These new ips are no part of any of the networks available on any trunks on the bigip device. But the two members are still showing online, i ran a tcpdump and don't see any health checks being done from any of the self ips. How is the ip showing online even if none of the self ips is polling it?
8 Replies
Cory_50405Noctilucent
The health checks will have to source from one of the self IP addresses on your LTM. If the pool members are reachable, then your LTM has the proper route to get there. Try running a tcpdump on all interfaces to see where the traffic is sourcing from:
tcpdump -nni 0.0 host poolmemberipaddress
jaked_150553i ran tcpdump as under: tcpdump -i any host i see no packets going through. One thing i noticed is, ping -R shows the first hop as ip on the management interface. But if I do ping -R on other members from other pool that are already working, i don't see any results. But if run a tcpdump on these members that are working, i see packets to and fro.- Cory_50405Does your LTM have a route via a TMM interface (not management network) to your pool members that you aren't seeing traffic to?
- jaked_150553no there is no route. may be iam missing something. if an ip is not part of any subnet supported on the interfaces of a bigip, how do i still make it work and be marked online by the bigip?
- nag_54823
Cirrostratus
is there any monitor assigned to that pool ? Can u show us the pool config and status
- jaked_150553
thanks for the answers...did some poking around and this what I found, this is somewhat confusing though:
if we add an ip as pool member, bigip checks if it corresponds to any of the subnets from which the self ip addresses are added. if this ip corresponds to any of the self ip address and it's subnet, and there is SNAT automap on the corresponding virtual, bigip uses this self ip to send traffic to and fro to the pool member.
if we add an ip as pool member that doesn't correspond to any of the self ips and their subnets the bigip uses the management interface to send traffic which is not desirable on a production device( for reasons of maintenance and other stuff). This also breaks SNAT automap if any on the virtual. It might not be advisable to add mgmt ip to snat pools as well.
To overcome this, we have to define a route on the bigip, the gateway to be define is again a little tricky. we should chose an available network reaching which takes the least number of hops. I tried several gateways of several networks already configured on the bigip and each time ran "tcpdump -i any host " each time, i saw traffic being sent to the pool member from the corresponding self ip.
So, decision on which self ip is used either depends on whether there is a corresponding subnet on the bigip or if there is an explicit route using one of the subnets already configured.
- jaked_150553
thanks for the answers...did some poking around and this what I found, this is somewhat confusing though:
if we add an ip as pool member, bigip checks if it corresponds to any of the subnets from which the self ip addresses are added. if this ip corresponds to any of the self ip address and it's subnet, and there is SNAT automap on the corresponding virtual, bigip uses this self ip to send traffic to and fro to the pool member.
if we add an ip as pool member that doesn't correspond to any of the self ips and their subnets the bigip uses the management interface to send traffic which is not desirable on a production device( for reasons of maintenance and other stuff). This also breaks SNAT automap if any on the virtual. It might not be advisable to add mgmt ip to snat pools as well.
To overcome this, we have to define a route on the bigip, the gateway to be define is again a little tricky. we should chose an available network reaching which takes the least number of hops. I tried several gateways of several networks already configured on the bigip and each time ran "tcpdump -i any host " each time, i saw traffic being sent to the pool member from the corresponding self ip.
So, decision on which self ip is used either depends on whether there is a corresponding subnet on the bigip or if there is an explicit route using one of the subnets already configured.
