diff for duplicates of <004f01ca1792$b24a7a90$16df6fb0$@edu> diff --git a/a/content_digest b/N1/content_digest index bf2234a..7418414 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,20 +1,20 @@ "ref\00199E0D51A61344794750DC57738F58E6D6A6CD7F6@GVW1118EXC.americas.hpqcorp.net\0" "From\0Paul Congdon \\(UC Davis\\) <ptcongdon@ucdavis.edu>\0" - "Subject\0Re: [Bridge] [PATCH] macvlan: add tap device backend\0" + "Subject\0RE: [Bridge] [PATCH] macvlan: add tap device backend\0" "Date\0Fri, 7 Aug 2009 12:10:07 -0700\0" - "To\0drobbins@funtoo.org\0" - "Cc\0ogerlitz@voltaire.com" - herbert@gondor.apana.org.au - 'Arnd Bergmann' <arnd@arndb.de> - mst@redhat.com + "To\0<drobbins@funtoo.org>\0" + "Cc\0'Paul Congdon \\(UC Davis\\)' <ptcongdon@ucdavis.edu>" 'Fischer Anna' <anna.fischer@hp.com> - netdev@vger.kernel.org - bridge@lists.linux-foundation.org - linux-kernel@vger.kernel.org - 'Paul Congdon (UC Davis)' <ptcongdon@ucdavis.edu> - evb@yahoogroups.com - " davem@davemloft.net\0" + 'Arnd Bergmann' <arnd@arndb.de> + <herbert@gondor.apana.org.au> + <mst@redhat.com> + <netdev@vger.kernel.org> + <bridge@lists.linux-foundation.org> + <linux-kernel@vger.kernel.org> + <ogerlitz@voltaire.com> + <evb@yahoogroups.com> + " <davem@davemloft.net>\0" "\00:1\0" "b\0" "Responding to Daniel's questions...\n" @@ -87,4 +87,4 @@ "\n" Paul -32abb2e1a3fd570fa8e3b4721c4adea8c2e45539896e7bdf68c896ff7a959712 +4640a91897ad25009a7ad2b99e61f3c33dd7b6e5a8cda5a7e79462695b4e515b
diff --git a/a/1.txt b/N2/1.txt index d6ffd12..a7c7e82 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -22,7 +22,8 @@ It would be the same as if that machine were configure to use a bridge to access > of tun/tap and bridge that make this new interface necessary or > beneficial? -If you have VMs that will be communicating with one another on the same physical machine, and you want their traffic to be exposed to an in-line network device such as a application firewall/IPS/content-filter (without this feature) you will have to have this device co-located within the same physical server. This will use up CPU cycles that you presumable purchased to run applications, it will require a lot of consistent configuration on all physical machines, it could invoke potentially a lot of software licensing, additional cost, etc.. Everything would need to be replicated on each physical machine. With the VEPA capability, you can leverage all this functionality in an external network device and have it managed and configured in one place. The external implementation is likely a higher performance, silicon based implementation. It should make it easier to migrate machines from one physical server to another and maintain the same network policy enforcement. +If you have VMs that will be communicating with one another on the same physical machine, and you want their traffic to be exposed to an in-line network device such as a application firewall/IPS/content-filter (without this feature) you will have to have this device co-located within the same physical server. This will use up CPU cycles that you presumable purchased to run applications, it will require a lot of consistent configuration on all physical machines, it could invoke potentially a lot of software licensing, additional cost, etc.. Everything would need to be replicated on each physical machine. With the VEPA capability, you can leverage all this functionality in an external network device and have it managed and configured in one place. The external implementation is likely a + higher performance, silicon based implementation. It should make it easier to migrate machines from one physical server to another and maintain the same network policy enforcement. > Is this new interface useful at all for VPN solutions or is it > *specifically* targeted for connecting virtual machines to the diff --git a/a/content_digest b/N2/content_digest index bf2234a..2f335ec 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,20 +1,20 @@ "ref\00199E0D51A61344794750DC57738F58E6D6A6CD7F6@GVW1118EXC.americas.hpqcorp.net\0" "From\0Paul Congdon \\(UC Davis\\) <ptcongdon@ucdavis.edu>\0" - "Subject\0Re: [Bridge] [PATCH] macvlan: add tap device backend\0" + "Subject\0RE: [Bridge] [PATCH] macvlan: add tap device backend\0" "Date\0Fri, 7 Aug 2009 12:10:07 -0700\0" - "To\0drobbins@funtoo.org\0" - "Cc\0ogerlitz@voltaire.com" - herbert@gondor.apana.org.au - 'Arnd Bergmann' <arnd@arndb.de> - mst@redhat.com + "To\0<drobbins@funtoo.org>\0" + "Cc\0'Paul Congdon \\(UC Davis\\)' <ptcongdon@ucdavis.edu>" 'Fischer Anna' <anna.fischer@hp.com> - netdev@vger.kernel.org - bridge@lists.linux-foundation.org - linux-kernel@vger.kernel.org - 'Paul Congdon (UC Davis)' <ptcongdon@ucdavis.edu> - evb@yahoogroups.com - " davem@davemloft.net\0" + 'Arnd Bergmann' <arnd@arndb.de> + <herbert@gondor.apana.org.au> + <mst@redhat.com> + <netdev@vger.kernel.org> + <bridge@lists.linux-foundation.org> + <linux-kernel@vger.kernel.org> + <ogerlitz@voltaire.com> + <evb@yahoogroups.com> + " <davem@davemloft.net>\0" "\00:1\0" "b\0" "Responding to Daniel's questions...\n" @@ -41,7 +41,8 @@ "> of tun/tap and bridge that make this new interface necessary or \n" "> beneficial?\n" "\n" - "If you have VMs that will be communicating with one another on the same physical machine, and you want their traffic to be exposed to an in-line network device such as a application firewall/IPS/content-filter (without this feature) you will have to have this device co-located within the same physical server. This will use up CPU cycles that you presumable purchased to run applications, it will require a lot of consistent configuration on all physical machines, it could invoke potentially a lot of software licensing, additional cost, etc.. Everything would need to be replicated on each physical machine. With the VEPA capability, you can leverage all this functionality in an external network device and have it managed and configured in one place. The external implementation is likely a higher performance, silicon based implementation. It should make it easier to migrate machines from one physical server to another and maintain the same network policy enforcement.\n" + "If you have VMs that will be communicating with one another on the same physical machine, and you want their traffic to be exposed to an in-line network device such as a application firewall/IPS/content-filter (without this feature) you will have to have this device co-located within the same physical server. This will use up CPU cycles that you presumable purchased to run applications, it will require a lot of consistent configuration on all physical machines, it could invoke potentially a lot of software licensing, additional cost, etc.. Everything would need to be replicated on each physical machine. With the VEPA capability, you can leverage all this functionality in an external network device and have it managed and configured in one place. The external implementation is likely a \n" + " higher performance, silicon based implementation. It should make it easier to migrate machines from one physical server to another and maintain the same network policy enforcement.\n" "\n" "> Is this new interface useful at all for VPN solutions or is it\n" "> *specifically* targeted for connecting virtual machines to the \n" @@ -87,4 +88,4 @@ "\n" Paul -32abb2e1a3fd570fa8e3b4721c4adea8c2e45539896e7bdf68c896ff7a959712 +e22fbb5289ce8baa1096e9b1e4dc1c687d9f47e00287a6953655c6f569256b99
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.