UNKNOWN TARGET error

[ccovney]

Hi everyone,

I'm running a 5-VM cluster Apigee Edge On-Prem v4.14.07, and I'm experiencing a strange issue. I'll do my best describe it.

The Error:

{
    "fault": {
        "faultstring": "Unknown target foobarapigee.foobar.com",
        "detail": {
            "code": "UNKNOWN_TARGET"
        }
    }
}

The Logged Error:

This error is found on the Apigee Router in the file:

/opt/apigee4/var/log/apigee/router/logs/system.log

2015-05-13 15:35:17,802 org: env: nioEventLoopGroup-2-2 ERROR Proxy-session - RouterProxySession.classify() : Message id:bsdvpapg01_BTU3W840_RouterProxy-10-2849_1, Classification error com.apigee.proxy.messages.HttpErrorResult@5324a927 for 
2015-05-13 15:35:17,803 org: env: nioEventLoopGroup-2-2 ERROR Proxy-session - RouterProxySession.errorResponse() : Message id:bsdvpapg01_BTU3W840_RouterProxy-10-2849_1, Sending error response to client status:404 Not Found

Environment Details:

- 2 Virtual Hosts, both listening on port 9001, but each with a different alias.

- 2 API Proxy Bundles, each pulling traffic from only one of the two Virtual Hosts (but the two proxies never pull traffic from the same virtual host) - Each API Proxy Bundle has its own API Product

Error Details:

- When I deploy both of the API Proxy Bundles, whichever one I deploy first (chronologically) works! Whichever one I deploy second, does not work!

- The error itself occurs during runtime when I hit the URL matching the alias of the Virtual Host.

Longterm Goal:

- We would like to have 15-20 Virtual Hosts (each with unique Aliases), where each VH would represent a different browser based application. This way, we could have a holistic view of Analytics across all of our products/applications.

Is this error occurring because of how Apigee deploys the code to the Message Processors? Would having each VH listen on a different port help at all?

Any help or insight would be very much obliged!

[adas]

@Chris Covney

Can you paste your virtualhosts config here or just the aliases. Also the curl command that you are running, when you get this error.

What's the version of Apigee Edge that you are running on-premise ?

In the api call that you are making, please ensure that you are passing the host header as "hostAlias:port" so that the router is able to classify your request. Also if you make the following call on your routers, it would give you the classification rules and tell you why the router is unable to classify (mostly rules may not be matching your request)

curl -v http://{routerip}:{mgmtport}/v1/classification/tree

The mgmtport should be your router's management port.

[ccovney]

Hi Arghya,

*Note that I just updated my original question with the Router Log errors.

I'm running v4.14.07.

The curl call I am using to get this error is:

curl -v https://debtspacedev1apigee.foobar.com

Our Network Topology Flow:

client curl request -> NetScaler device resolves SSL and DNS (routes request to Apigee Routers via port 9001) -> Apigee Routers (error occurs)

Virtual Host Config:

{
    "hostAliases": [
        "debtspacedev1apigee.foobar.com"
    ],
    "interfaces": [],
    "name": "debtspace",
    "port": "9001"
}

I'll try your call to the router classification tree and get back to you on how it works out. Thanks so much for your help, Arghya!

[adas]

Can you also confirm that when the request reaches your router you see a host header which is set to debtspacedev1apigee.foobar.com. If you modify your curl request to:

curl -v https://debtspacedev1apigee.foobar.com -H 'host:debtspacedev1apigee.foobar.com'  

Does it work ?

[ccovney]

I tried the above modified curl command, but still the same error:

curl https://debtspacedev1apigee.foobar.com -H 'host:debtspacedev1apigee.foobar.com'

{"fault":{"faultstring":"Unknown target debtspacedev1apigee.foobar.com","detail":{"code":"UNKNOWN_TARGET"}}}

[ccovney]

@arghya das

I tried the classification tree command on the router and I do not see the classification I expected! Why would my virtual host configuration in the management server UI conflict with the Router Classification Tree??

{
  "jmsHosts" : [ ],
  "servers" : [ {
    "address" : "bsdv4vapg02",
    "expressions" : [ {
      "condition" : "(header.host matches viadev1apigee.foobar.com) OR (header.host matches viadev1apigee.foobar.com:9001)",
      "virtualHost" : {
        "env" : "dev",
        "name" : "via",
        "org" : "foobar",
        "tree" : {
          "elements" : [ ],
          "name" : "IdentificationTree"
        }
      }
    } ],
    "name" : "RouterProxy-2",
    "port" : 9001,
    "protocol" : "HTTP",
    "running" : false
  }, {
    "address" : "localhost",
    "expressions" : [ {
      "condition" : "(header.host matches viadev1apigee.foobar.com) OR (header.host matches viadev1apigee.foobar.com:9001)",
      "virtualHost" : {
        "env" : "dev",
        "name" : "via",
        "org" : "Foobar",
        "tree" : {
          "elements" : [ ],
          "name" : "IdentificationTree"
        }
      }
    } ],
    "name" : "RouterProxy-3",
    "port" : 9001,
    "protocol" : "HTTP",
    "running" : false
} ]

[adas]

Is this the virtualhost to which the proxy is deployed: via ? If so, then as you can see in the classification tree that the host header must match "viadev1apigee.foobar.com" or "viadev1apigee.foobar.com:9001".

But in your previous curl command you gave me something else:

curl -v https://debtspacedev1apigee.foobar.com

I was assuming that you were trying to make a proxy call, to a deployed apiproxy but from your router's classification tree output I can see that you do not have any proxies deployed (assuming that you didn't obfuscate the output), so what I you trying to hit with the above curl command.

From your original problem description I thought you had 2 proxies deployed to the same virtualhost. If that's the case please make sure both the proxies have different proxy basepaths, and then try the curl command with the appropriate host header.

For example, if your proxy basepath is /123 your call would become:

curl -v http://viadev1apigee.foobar.com/123 -H 'host:viadev1apigee.foobar.com'

The same applies for your second proxy:

curl -v http://viadev1apigee.foobar.com/abc -H 'host:viadev1apigee.foobar.com'

[ccovney]

Hi Arghya,

My original problem is the correct description. This is very very strange, as I do not have any "viadev1apigee" proxies deployed! I have a "via" VH defined, but it is not being used by any deployed proxies. This classification Tree makes no sense when compared to the deployed API Proxies and Virtual Hosts in Management Server UI. There is a complete disconnect between the info displayed on the management ui and the classification tree response. How is this possible?

Just to clarify your previous point/question. I have 2 virtual hosts and 2 proxies, Virtual Host A and Virtual Host B; and Proxy A and Proxy B. Proxy A pulls traffic from VH A an Proxy B pulls traffic from VH B. Does this make sense?

[adas]

I am also wondering, if you are running into a bug which we fixed couple of months back. That fix however would not be in your Edge installation:

http://apigee.com/docs/release-notes/content/150218-apigee-edge-cloud-release-notes

Look for CORERT-331 in the release notes. Its would be available in our v4.15.04 release for on-premise customers.

[ccovney]

I do not see how CORERT-331 relates to this, as I do not have any pipes "|" in my request. Unless I've missed something.

[adas]

For your original problem description, I think you are running into the bug I mentioned above.

For the classification tree output, let me explain a bit. The "viadev1apigee" doesn't refer to any proxy, your tree suggests that there are no proxies currently deployed.

Here's a sample classification tree output:

[ {

  "condition" : "(server.port matches 10000)",

  "virtualHost" : {

    "env" : "test",

    "name" : "default",

    "org" : "myorg",

    "tree" : {

      "elements" : [ {

        "application" : "apigee-service_rev2",

        "basePath" : "/services",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "wiley",

        "basePath" : "/tdm",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "logging",

        "basePath" : "/logging",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "target-vars",

        "basePath" : "/v2/target",

        "name" : "default",

        "revision" : "2"

      }, {

        "application" : "apigee-nodejs",

        "basePath" : "/apigee/nodejs",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "demoApi",

        "basePath" : "/v1/demo",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "ipex",

        "basePath" : "/ipex",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "apigee-location",

        "basePath" : "/location/v1",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "target-vars",

        "basePath" : "/v1/target",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "example",

        "basePath" : "/example",

        "name" : "default",

        "revision" : "1"

      }, {

        "application" : "jsonApi",

        "basePath" : "/jsonapi",

        "name" : "default",

        "revision" : "1"

      } ],

      "name" : "IdentificationTree"

    }

  }]

The elements array holds the proxies that are deployed. As you can see, your elements array is empty which means you do not have any proxies deployed. If you are sure, I would request you to restart your routers once and re-run the classification tree api once more.

[ccovney]

@arghya das

I stopped all the Apigee services on all the VMs, and then brought them back up one at a time. Then, I deployed both of the proxies, one at a time.

After deploying the first proxy I ran the router classification tree command and got this response:

{  "jmsHosts" : [ ],  "servers" : [ ]}

After deploying the second proxy, I ran the command again and got this response (same response):

{  "jmsHosts" : [ ],  "servers" : [ ]}

Somehow, it seems the routers are not getting the deployment information. Any idea as to how this could be? Thanks again for all your help, Arghya.

[ccovney]

@arghya das

Any idea as to why the routers are not getting any of the deployment info? Thanks again!

Best,

Chris

[adas]

Hi @Chris Covney

I posted a comment yesterday, maybe I didn't submit that, my bad. It would be hard to comment on that without looking at your management and router logs. Can you send me those, maybe email to adas@apigee.com rather than sharing those here. I also need you to send me the response for the following management api for the current state as well as after you try deploying any new api:

curl -v http://{mgmtip}:{mgmtport}/v1/o/{org}/apis/{api}/revisions/{rev}/deployments

[ccovney]

Hi @arghya das

I'm having issues with the community website. I can't seem to post my screenshots nor my JSON responses from the mgmt apis. I'll include this in my email to you, along with the router and mgmt server logs. Thanks again for all your help!

Best,

Chris

[gnanasekaran]

@arghya das, similar issue here as well

https://community.apigee.com/questions/5787/missing-header.html#answer-5802

maybe related?

[guy_hagemans]

Hi,

I'm running into similar problems with on-premise version 4.14.06.02. Is it possible to perhaps share the answer?

thanks and best regards,

Guy

[guy_hagemans]

Hmm, adding the host header fixed the issue for me...

[ccovney · Accepted solution]

I was able to resolve this issue by upgrading to the latest version of Apigee, namely, 4.15.04.

[adas]

@GuyH I think this was a bug that was introduced during the 4.14.06 release. We fixed the issue in the first cloud release this year, and the fix is available in the 4.15.04 on-premise release. If you are comfortable upgrading to 4.15.04 release please do so, else you can request a patch on 4.15.01. I am not sure we have a patch for this on 4.14.06.02 version.

I think this problem crops up, only when you have multiple virtualhosts with the same hostAlias and/or different ports. When you set the host header with hostAlias:port that fixes the problem.