Hi!

We have this application that talks CORBA/IIOP.
After putting this application behind a BIG-IP Loadbalancer the application stopped working.

Is there anything that needs to be configured in the BIG-IP to let the IIOP/GIOP traffic through ?

If we move the application to an environment without a BIG-IP it starts to work again.




Exception i EJB SEssion:org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe

This exception is raised if communication is lost while an operation is in progress, after the request was sent by the client, but before the reply from the server has been returned to the client.
COMM_FAILURE/208. vmcid: SUN minor code: 208 literally means "CONNECTION ABORT", which generally means the connection has been dropped

The application runs from an Oracle Weblogic 9.2 Server in a clustered environment.

Hello Henrik!

It sounds like the BIG-IP doesn't know what to do with traffic on that port. Do you have a VIP accepting traffic and a pool servicing on that port?

Just starting with the easy stuff, sorry if you've been over this already.

Don.

Hi Don and thanks for your answer.

We have alreadey triede that one and it looks lite the traffic will not pass.

Regards

Henrik

Henrik,

What does the configuration on that Virtual Server look like? Are you using IIOP over TCP/IP or something else?

Was this ever solved? I am having the same problem getting IIOP traffic to go through the F5 while using Weblogic.

It appears that the IIOP traffic is using port 80/TCP as is HTTP. I am guessing that the F5 passes the HTTP traffic, but then drops the IIOP traffic.

Another site has an A10 load balancer with a similar problem and proposed the solution below. Not being very savy on F5 setup, I was wondering how their solution might translate into a configuration for our F5. (BIG-IP 10.0.0 Build 5514.0 Hotfix HF2).

I am stuck in using port 80/TCP for both the HTTP and IIOP traffic.

-------------
We have a solution from A10 Networks, the load balancer vendor. Basically the issue was that the Vista Web Logic cluster was accepting both the HTTP and CORBA IIOP protocols on the same port (80/TCP). It is a bit unusual for a single service bound to a particular port to accept more than one Layer 7 protocol. The load balancer only expected HTTP packets to be received on the public cluster virtual IP from anywhere, so when AS8 tried to send CORBA packets to the Vista cluster on port 80, it just dropped them after the TCP session was set up and saw that the Layer 7 payload was not HTTP 1.0/1.1.


We worked around that by configuring a new (different) cluster VIP on the load balancer, using the same "real" server nodes as members of the cluster, and using the same port 80/TCP; however this cluster was configured for Layer 4 load balancing only, not Layer 7 HTTP. The FQDN corresponding to this Layer 4 cluster VIP was configured in AS8 for the SSO authentication URL. ACLs are configured on the load balancer to prevent anyone from trying to get to the Vista cluster via this FQDN/VIP (only the AS8 nodes are allowed).


Although CORBA IIOP packets contain Layer 3 information (namely, the IP of the AS8 real server node trying to communicate with the Vista cluster), the NAT performed by the load balancer is not a problem for us because the Vista and AS8 real server nodes are in the same private VLAN. Thus after the load balancer selected one of the Vista nodes to send the CORBA packet to, that Vista node then communicated with the AS8 node initiating the SSO auth directly.

Well, it looks like the question you raise, and the solution from A10 are slightly different. My guess, is that you have an HTTP profile enabled on the F5 virtual server, which tells the F5 to look for HTTP type traffic. Your assumption about dropping non-HTTP traffic is correct, it will definitely get dropped if it does not conform to http standards.

If that is true, you have a couple options:

First, for a test, try setting the HTTP profile to None on the virtual server. This essentially makes the virtual server work at L4, and ignores the tcp payload contents. If IIOP traffic passes normally, then you have confirmed it. However, if you are using any advanced F5 HTTP features, it may not let you do this, and may actually break the HTTP traffic processing, so don't do this in the middle of work hours. A safer test would be to set up a new virtual server for IIOP, and try it.

If you really want to separate the traffic, you have three choices.

1. Separate using different virtual servers with a different IP addresses. If I read the A10 solution correctly, this is what was configured.
2. Separate using different TCP ports, like 80 for the HTTP traffic, and 8000 for IIOP ( or any other port except 80 ), but on the same IP address. Remember, an F5 can only have one virtual server with a single a.b.c.d:80 vip.
3. Separate using an iRule that would inspect the TCP payload, and then select the correct pool for the traffic ( one pool for HTTP, one pool for IIOP ).

Number 1 and 2 are probably the easiest and best options, number 3 means you have roll up your sleeves and spend more time on DevCentral to learn you to parse tcp traffic and select pools :-)

You also might consider what would be a supported solution from the Oracle perspective, you certainly don't want to build something that they won't support.

You would need to post the configuration of your virtual server to confirm the above.

Thanks for the help. We cannot set the HTTP profile to known because then the F5 complains that cookie persistence will not work, which we need. I am working on how we can test option 1. Option 2 does not seem doable since WebCT seems to have IIOP and port 80 entwined too much to change.

If this is still an issue, stop using cookie persistence, as you are no longer using the HTTP profile. Change to source IP address based persistence, as that is the only kind of persistence you can do with TCP only connections.