Forum Discussion
CirrusIVS IP assignment
I wanted to ask if anyone has encountered a situation in which using the below config, but instead of an internal VS it's built with a standard VS (so can specify an IP...dev requirement) and then switched to internal VS with the IP present. The issue is with this config, on a reboot, the F5 doesn't recognize the IP assigned. If so, what is the work around to the IP issue. I know F5 recommends the internal VS without the IP but again, dev requirement. I opened a case with F5 but since it was not a supported config., they couldn't assist.
Chris_GrantEmployee
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.
- Sonny
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.
- Sonny
I should add that the traffic coming into the IVS is ONLY from the standard VS.
- Chris_Grant
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?
- Sonny
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.
- Chris_Grant
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.
- Sonny
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.
- Sonny
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
- Chris_Grant
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.
- Sonny
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.