pool selection iRule not working

when CLIENT_ACCEPTED { 
   If remote IP address matches the datagroup then select new pool 
  if { [class match [IP::remote_addr] equals data.group.com] } { 
    pool server.pool.com-pool 
     If remote IP address doesn't match datagroup default to VIP pool 
  } else { 
    pool existing.server.pool 
  }
}

You had a typo... pool new is not a valid command.

The typo only existed in the post and not on the production iRule. I have fixed it below to reflect properly. I wasn't trying to use new as a command.

when CLIENT_ACCEPTED { If remote IP address matches the datagroup then select new pool if { [class match [IP::remote_addr] equals data.group.com] } { pool newserver.pool.com-pool If remote IP address doesn't match datagroup default to VIP pool } else { pool existing.server.pool } }

Ok then your iRule looks good. You need to turn on logging to see what IP::remote_addr is actually giving you and please post an example of one line in your datagroup.

when CLIENT_ACCEPTED { 
   If remote IP address matches the datagroup then select new pool 
  log local0. "Remote address is [IP::remote_addr]"
  if { [class match [IP::remote_addr] equals data.group.com] } { 
    pool newserver.pool.com-pool 
     If remote IP address doesn't match datagroup default to VIP pool 
  } else { 
    pool existing.server.pool 
  }
}

Here is the data-group:

ltm data-group internal custom.datagroup.com { records { 1.1.1.1/32 { } 2.2.2.2/32 { } 3.3.3.3/32 { } } type ip }

All but 3.3.3.3 are being redirected to the newserver.pool.com-pool.

I also enabled logging and so far I haven't seen the 3.3.3.3 address in the logs. I will give it more time to show up.

Everything you have done is spot on so there is nothing wrong with your iRule. My only suggestion is watch IP addresses coming in. Quite often expectations don't meet reality about incoming data. Logging is your source of truth.

You mentioned 3 iRules. What are the other two doing? Could there be some conflicting logic? This iRule is fired early in the http connection (CLIENT_ACCEPTED event). As there is no escape (return) in this iRule, the connection flow continues and next event is HTTP_REQUEST and so on. So the other iRules may/will fire, too.