On Azure deployment, getting "Unable to bind to http://localhost:9410 on the IPv6 loopback interface."

[muratg]

From @kirk-marple on July 20, 2016 16:50

On the first time I deployed my .NET Core Web API to Azure, I noticed this in my logs.

Obviously just a warning, but it's binding to localhost while on Azure, which seemed a little odd, so I thought I'd ask about it.

From global.json:
"version": "1.0.0-preview2-003121"

And I'm using 'net452' frameworks.

  "Timestamp": "2016-07-20T16:42:54.8896127+00:00",
  "Level": "Warning",
  "MessageTemplate": "Unable to bind to http://localhost:9410 on the IPv6 loopback interface.",
  "Exception": "System.AggregateException: One or more errors occurred. ---> Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.Check(Int32 statusCode)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.tcp_bind(UvTcpHandle handle, SockAddr& addr, Int32 flags)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvTcpHandle.Bind(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.TcpListener.CreateListenSocket()\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Listener.<>c.<StartAsync>b__6_0(Object state)\r\n   --- End of inner exception stack trace ---\r\n   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)\r\n   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelEngine.CreateServer(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.KestrelServer.Start[TContext](IHttpApplication`1 application)\r\n---> (Inner Exception #0) Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.Check(Int32 statusCode)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.tcp_bind(UvTcpHandle handle, SockAddr& addr, Int32 flags)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvTcpHandle.Bind(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.TcpListener.CreateListenSocket()\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Listener.<>c.<StartAsync>b__6_0(Object state)<---\r\n",
  "Properties": {
    "SourceContext": "Microsoft.AspNetCore.Server.Kestrel",
    "MachineName": "RD000D3A124D8B",
    "ThreadId": 1
  }

Copied from original issue: aspnet/KestrelHttpServer#1001

[muratg]

From @davidfowl on July 20, 2016 17:7

To azure using what? Azure app service?

[muratg]

From @kirk-marple on July 20, 2016 17:9

Correct, yeah. Azure App Service. Freshly created a new App Service, and published from VS.

[muratg]

From @davidfowl on July 21, 2016 6:48

What does your Program.Main look like

[muratg]

From @vmykhaylovskiy on July 21, 2016 8:5

I'm getting the same warning message on Azure App service. I'm using 'net46' frameworks with 1.0.0-preview2-003121 sdk.

Here is what my Program.Main looks like.

    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();
            host.Run();
        }
    }

[muratg]

From @kirk-marple on July 21, 2016 15:12

Same here... just the default from the template.

    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }
    }

[muratg]

From @davidfowl on July 21, 2016 15:58

Which default template? Are you saying, the default template for ASP.NET Core ( .NET Framework) with no changes doesn't work on azure websites?

[muratg]

From @kirk-marple on July 21, 2016 16:3

Using Templates/Visual C#/.NET Core/ASP.NET Core Web Application (.NET Core), and selecting Web API.

It's not that it doesn't work, the Web API runs fine on Azure, after publishing.

I just noticed that warning in the log data, and thought it may be an concern, even though it doesn't affect the functionality of the Web API.

[muratg]

From @davidfowl on July 21, 2016 16:5

Are you running .NET Core or .NET Framework? You mentioned that you were using net452. Why did you pick .NET Core if that's the case?

[muratg]

From @kirk-marple on July 21, 2016 16:14

Right now, using the .NET Core project.json model (see attached example), but running net452 framework. Started this project last year during early DNX days, and been focusing on net452 for a stable baseline before going back and migrating to .NET Core runtime. The new project model works great, so didn't want to have to redo everything if we went to .NET Core runtime in future.

We also publish packages from our .NET Core projects and use them in .csproj projects (like on Service Fabric) where needed. So that part works well today.

project.json.txt

[muratg]

From @halter73 on July 22, 2016 0:50

@kirk-marple Kestrel binding to localhost is expected since Azure App Services use IIS as a reverse proxy in front of Kestrel on the same "machine". IIS uses an available port (in this case 9410) to communicate to Kestrel.

All the way until RC2, we would only try to bind to the IPv4 loopback address (127.0.0.1) when binding to "localhost", so you likely wouldn't have seen this warning. Starting in 1.0.0, we try to bind to the IPv6 loopback address as well ([::1]). It seems that Azre App Services doesn't allow binding to ([::1]).

I think that it makes sense for UseIISIntegration to specify http://127.0.0.1:[port] so you don't see this warning, since it seems it uses IPv4 anyway. @Tratcher what do you think?

[Tratcher]

Open questions:

• Why does [::1] binding fail in Azure App Services?
• Why does ANCM prefer connecting to 127.0.0.1? [::1] has been the preferred loopback address since Vista.

We want to avoid binding to a different address than then one ANCM will try first or we'll incur a delay at the start of every connection.

[muratg]

@davidebbo Could you look into @Tratcher's question re [::1] binding on Antares?

[davidebbo]

Not sure, might be a sandbox thing. If you have a simple repro (using a repo), we can probably verify.

[muratg]

cc @mikeharder

[muratg]

@mikeharder Could we provide @davidebbo a repro? I think you had reported this problem in the past.

[mikeharder]

@davidebbo: Repro at https://github.com/mikeharder/AspNetCoreAppService. This is our default ASP.NET Core template with stdout logging enabled.

After you deploy and browse to the app, it will create a log file starting with "stdout" under D:\home\LogFiles, which shows the IPv6 binding exception:

warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to bind to http://localhost:13620 on the IPv6 loopback interface.
System.AggregateException: One or more errors occurred. (Error -4089 EAFNOSUPPORT address family not supported) ---> 
Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported

On Windows or Linux, when IPv6 is "disabled", apps can still bind to IPv6 sockets without error, they just cannot receive traffic on IPv6. It would be nice if App Service did the same.

[philmh-isams]

Is there a workaround for this exception?

warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to bind to http://localhost:8615 on the IPv6 loopback interface.
System.AggregateException: One or more errors occurred. (Error -4089 EAFNOSUPPORT address family not supported) ---> Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported

[halter73]

@philmh-isams The error is benign, so I would just ignore the warning for now. If you were configuring the endpoint directly using UseUrls(), I would recommend changing "localhost" to "127.0.0.1". If you absolutely must work around this, something like the following would work:

    public static void Main(string[] args)
    {
        var hostBuilder = new WebHostBuilder()
            .UseKestrel()
            .UseIISIntegration()
            .UseStartup<Startup>();

        // ConfigureServices is only used to delay execution until UseIISIntegration()
        // has actually set the "urls" setting.
        hostBuilder.ConfigureServices(services =>
        {
            var urls = hostBuilder.GetSetting("urls");
            urls = urls.Replace("localhost", "127.0.0.1");
            hostBuilder.UseSetting("urls", urls);
        });

        var host = hostBuilder.Build();

        host.Run();
    }

[philmh-isams]

@halter73 Thank you for your reply. You are right, I don't need to do it, but someone else finding this thread might - so thank you for that.

I will continue to ignore the issue. At first, I thought it was the reason for my service on Azure failing, but it was another configuration issue.

[muratg]

@davidebbo @mikeharder Any updates on Antares investigation?

[davidebbo]

Sorry, no. Can you start internal thread so I can loop in people who know more about this and are not on GitHub? Thanks.

[muratg]

@davidebbo done.

[muratg]

Closing this as no code changes expected in IISIntegration repo.