For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

James_Greenlee_'s avatar
James_Greenlee_
Icon for Nimbostratus rankNimbostratus
Oct 15, 2008

iRule broken after code update?

So...I had a LB running 9.1.0 code with an iRule to take the two IP address coming into the Virtual Server and route each individual IP to a specific pool.

 

 

Here's the iRule...

 

 

 
 when CLIENT_ACCEPTED { 
   if { [IP::addr [IP::remote_addr] equals 10.102.16.18 ] } 
  { 
          log local0. "Node IP address is: [IP::remote_addr] and sent to pri50" 
          pool prod_DP-MQ_pri50 
      } 
  elseif { [IP::addr [IP::remote_addr] equals 10.102.16.19 ] } 
  { 
          log local0. "Node IP address is: [IP::remote_addr] and sent to pri52" 
          pool prod_DP-MQ_pri52 
      } 
 }

 

 

After upgrading to 9.3.1 HF4 the rule has apparently stopped.

 

 

here's a TCPDump from the front of the LB...

 

 

19:33:10.933017 32.243.6.166.1414 > 10.102.16.19.52443: . ack 444 win 12008 (DF)

 

19:33:12.317238 10.102.16.18.39428 > 32.243.6.166.1414: . ack 445 win 16080 (DF)

 

19:33:13.207934 10.102.16.18.39429 > 32.243.6.166.1414: . ack 445 win 16080 (DF)

 

19:33:13.332083 10.102.16.18.39429 > 32.243.6.166.1414: P 444:888(444) ack 445 win 16080 (DF)

 

19:33:13.432016 32.243.6.166.1414 > 10.102.16.18.39429: . ack 888 win 32768 (DF)

 

19:33:14.209897 10.102.16.18.39428 > 32.243.6.166.1414: P 444:888(444) ack 445 win 16080 (DF)

 

19:33:14.309017 32.243.6.166.1414 > 10.102.16.18.39428: . ack 888 win 32768 (DF)

 

19:33:19.825583 10.102.16.19.52434 > 32.243.6.166.1414: . ack 445 win 16080 (DF)

 

19:33:20.825805 10.102.16.19.52434 > 32.243.6.166.1414: P 444:888(444) ack 445 win 16080 (DF)

 

19:33:20.832975 10.102.16.19.52443 > 32.243.6.166.1414: . ack 445 win 16080 (DF)

 

 

Now obviously...There's traffic from 10.102.16.18 and 10.102.16.19. Unfortunately...The log file contains NO entries for 16.18. But there's a whole buttload of entries for 16.19.

 

 

So I added this to the end of the iRule...

 

 

 
 else { log local0. "Node IP address is: [IP::remote_addr] and failed." }

 

 

That did nothing either.

 

 

And what started this was the server admins seeing that there was no traffic on the pri50 pool server.

 

 

So...The F5 and this iRule are seemingly ignoring the .16.18 server.

 

 

I dunno. Help?

 

 

Thanks,

 

 

James
application delivery
dev
devops
iRules

3 Replies

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Oct 15, 2008
    Hi James,

     

     

    The rule looks fine. I don't see any commands which would have changed in an upgrade from 9.1.x to 9.3.x. The tcpdump shows the correct client IP address connecting to the BIG-IP, so assuming the rule is attached to the correct VIP, the rule should trigger.

     

     

    Perhaps there is a more specific VIP which the requests are matching? What destination are the requests being sent to? Which pool(s) is that destination in?

     

     

    Aaron
  • James_Greenlee_'s avatar
    James_Greenlee_
    Icon for Nimbostratus rankNimbostratus
    Oct 15, 2008
    Hey Aaron,

     

     

    This rule is in place to perform a bit of persistence.

     

     

    There are 2 servers that use this VS (and only two) and there are two servers that these boxes can talk to.

     

     

    The servers sending data are 10.102.16.18 and 16.19

     

     

    The servers that will handle their requests are 10.102.101.50 and 52.

     

     

    I created two pools with priority groups.

     

     

    One pool has .50 and the primary and the other pool has .52 as the primary.

     

     

    So the goal was to take requests from 16.18 and pin it up to .50 unless .50 went away, then it needs to go to .52. And when .50 comes back up...It needs to gracefully go back to .50. And the same is true for .16.19 and the .52 server.

     

     

    I pulled the logs from the load-balancer and it looks like it worked after the code update (on the 12th) but something on the 13th caused it to stop functioning.

     

     

    I'm guessing I need to perform a either a bigstart restart or perhaps a b load to kinda jar this LB back into functioning properly?

     

     

    I just don't get why it stopped working. I might need to perform a more serious packet capture and analyze the traffic going into the LB a little more closely.

     

     

    Thanks,

     

     

    James
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Oct 15, 2008
    Hi James,

     

     

    If it was working after the upgrade and stopped working, the configuration should be okay. You could run qkview and open a case with F5 Support while it's still broken to try to determine why it failed.

     

     

    Aaron