IVS IP assignment

This isn't going to work. From:K15819: Overview of the internal virtual server (https://support.f5.com/csp/article/K15819)

By design, the internal virtual server is accessible only by a locally configured standard virtual server.

This means that you won't be able to get it to work with an IP. It's not unsupported in the sense that we won't help you, it's unsupported in the sense that it doesn't work that way.

Hmm, it was working for 5 months until the reboot. Yes, I know IVSs are only intended for other standard VS. Again, I assigned the IP because of dev requirement.

I should add that the traffic coming into the IVS is ONLY from the standard VS.

What exactly are you hoping to accomplish by adding an IP to the Internal? What is the ICAP server looking for that needs that IP?

Again, by adding the IP, the dev folks can point their app to the IVS. The ICAP server don't have the IP requirement...it was a dev requirement. I was thinking about this more...what if I just make the IVS a standard VS and still have the ICAP pool? In theory, it should still work.

I doubt it will work as expected. If you have devs pointing an app at the internal virtual server, you are by definition violating the designed intent of the internal virtual server. Your devs should be pointing to a standard virtual server which would then pass the traffic to the internal virtual server for transition to ICAP inspection.

Ah, that might be the better route. I'll create a standard VS, have dev point to it and then have that SVS point to the IVS with the ICAP pool. This should work, too.

Oh, I had forgotten that when I apply the adapt profile to the SVS, it resets my http connection. Thus, the site doesn't render. You can see from the below dump....143.51 is the SVS and .0.36 is me. I had opened a case with F5, too and they could not provide an answer as to why.

X.X.143.51.https > X.X.0.36.49332: Flags [R.], cksum 0xa45c (incorrect -> 0xda32), seq 3404, ack 965, win 0, length 0 out slot1/tmm1 lis=/Common/dev92_vs flowtype=64 flowid=5701D4BC9700 peerid=0 conflags=100200004800024 inslot=1 inport=1 haunit=1 priority=3 rst_cause="[0x239769b:1808] ADAPT unexpected state transition (old_state 10 event 9)" peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0

I found the case in question, and the notes report that you were able to resolve this problem by setting the preview size to 0, and that the root cause of the problem was that the BigIP could not reach the ICAP servers.

If this is incorrect and you were not able to resolve this, you should open a new ticket, reference the old one so we can continue troubleshooting with you.

Yes, changing the preview size resolved the issue temporary (a few days later though, not immediate). The root cause was never determined. If the SVS is resetting my connection, how does the BIGIP even begin to establish a connection to the ICAP servers?. So now that I'm testing the configs., the same reset is occurring with the request adapt profile. Yes, the preview size is at zero. They are working out the support contract issue at the moment. Thus, I can't open up a case. I've already burned my one time.