[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e0bf4896-d394-b1d0-1a0d-4affc3b0df4a@redhat.com>
Date: Tue, 21 Jun 2016 14:34:35 -0700
From: Hannes Frederic Sowa <hannes@...hat.com>
To: Tom Herbert <tom@...bertland.com>,
Alexander Duyck <alexander.duyck@...il.com>
Cc: Edward Cree <ecree@...arflare.com>,
David Miller <davem@...emloft.net>,
Alex Duyck <aduyck@...antis.com>,
Netdev <netdev@...r.kernel.org>,
intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
Jesse Gross <jesse@...nel.org>,
Eugenia Emantayev <eugenia@...lanox.com>,
Jiri Benc <jbenc@...hat.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Ariel Elior <ariel.elior@...gic.com>,
Michael Chan <michael.chan@...adcom.com>,
Dept-GELinuxNICDev@...gic.com
Subject: Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers
On 21.06.2016 11:42, Tom Herbert wrote:
>> > There is also some argument to be had for theory versus application.
>> > Arguably it is the customers that are leading to some of the dirty
>> > hacks as I think vendors are building NICs based on customer use cases
>> > versus following any specifications. In most data centers the tunnel
>> > underlays will be deployed throughout the network and UDP will likely
>> > be blocked for anything that isn't being used explicitly for
>> > tunneling. As such we seem to be seeing a lot of NICs that are only
>> > supporting one port for things like this instead of designing them to
>> > handle whatever we can throw at them.
>> >
> Actually, I don't believe that's true. It is not typical to deploy
> firewalls within a data center fabric, and nor do we restrict
> applications from binding to any UDP ports and they can pretty much
> transmit to any port on any host without cost using an unconnected UDP
> socket. I think it's more likely that NIC (and switch vendors) simply
> assumed that port numbers can be treated as global values. That's
> expedient and at small scale we can probably get away with it, but at
> large scale this will eventually bite someone.
I do have access to relatively normal expensive switches that can
basically be used to realize a scenario like the one Alex described. No
firewalls necessary. If you can guarantee that your customers never have
access to your hypervisors or container management namespace, this is
actually a pretty solid assumption.
Bye,
Hannes
Powered by blists - more mailing lists