See you all there tomorrow.
Regards,
Anil
From: Vinay Yadhav [mailto:vinayyad...@gmail.com]
Sent: Thursday, May 15, 2014 12:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension
in Neutron
Hi,
://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
On Thu, May 15, 2014 at 6:52 PM, Anil Rao
anil@gigamon.commailto:anil@gigamon.com wrote:
See you all there tomorrow.
Regards,
Anil
From: Vinay Yadhav
[mailto:vinayyad...@gmail.commailto:vinayyad
Thanks Vinay. I’ll review the spec and get back with my comments soon.
-Anil
From: Vinay Yadhav [mailto:vinayyad...@gmail.com]
Sent: Wednesday, May 21, 2014 10:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Openstack-dev][Neutron] Port
((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}
On Wed, May 21, 2014 at 7:38 PM, Anil Rao
anil@gigamon.commailto:anil@gigamon.com wrote:
Thanks Vinay. I’ll review the spec and get back with my comments soon.
-Anil
From: Vinay Yadhav [mailto:vinayyad...@gmail.commailto:vinayyad...@gmail.com]
Sent
Hi,
The latest version of the Tap-aaS spec is available at:
https://review.openstack.org/#/c/140292/
It was uploaded last night and we are hoping that it will be considered as a
candidate for the Kilo release.
Thanks,
Anil
___
OpenStack-dev mailing
Both Takashi and Soichi have been involved with the project for a while now and
have made significant contributions in terms of code and reviews.
+1 for both.
Thanks,
Anil
From: reedip banerjee [mailto:reedi...@gmail.com]
Sent: Tuesday, March 01, 2016 4:21 PM
To:
Thanks Soichi and Kaz for your work on implementing Horizon (dashboard) support
for TaaS. The proposal (with screen shots) discussed in our recent IRC meeting
look very nice. Here are some additional suggestions for improvement.
1. General
a. When a port is being selected (for a
The current tap-service-* and tap-flow-* APIs are synchronous. When the call
completes a status of success or failure is returned. The problem here though
is that this status is being returned by the TaaS plugin after it goes through
some checks and successfully updates the configuration state.
Hi,
Here is some additional information pertaining to the failures I am seeing
when invoking the tap-service-list and tap-flow-list commands. This is on a
multi-node DevStack environment (1 controller node, I network node and 2
compute nodes).
1. The tap-service-list command returns
Hi,
The TaaS team is planning to meet on Friday morning (29th Apr) in the Design
Summit area to discuss project status, pending issues and new work items.
Anyone interested in the project is welcome to join.
We will send out the time and location as soon as there is an agreement.
Regards,
Hi Simhon,
We are aware of this problem. The main issue is that packets entering br-int
from br-ex aren’t tagged with a VLAN id (unlike packets entering br-int from
br-tun). Since our overall design is meant to support multi-node production
environments we have to consider the packets coming
Hi Simhon,
We are in the process of removing the network-id argument from the
tap-service-create API. There is a patch that has been submitted with this
change and it is currently under review. We expect it to be merged very soon.
Thanks,
Anil
From: Simhon Doctori שמחון דוקטורי
Thanks Armando.
-Anil
From: Armando M. [mailto:arma...@gmail.com]
Sent: Tuesday, August 09, 2016 1:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness
On 9 August 2016 at 13:53, Anil Rao
<a
Hi,
This week's TaaS IRC meeting is being canceled since some of the team members
are planning to attend OpenStack Days in Tokyo. We will reconvene next week as
usual.
Thanks,
Anil
__
OpenStack Development Mailing List
Hi Jimmy,
I am working on a fix for this problem. I'll send out a patch for code-review
next week.
Best regards,
Anil
-Original Message-
From: SUZUKI, Kazuhiro [mailto:k...@jp.fujitsu.com]
Sent: Tuesday, July 05, 2016 5:26 AM
To: gmzhan...@gmail.com
Cc:
Is the MAC address of a Neutron port on a tenant virtual network globally
unique or unique just within that particular tenant network?
Thanks,
Anil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Wed, Aug 10, 2016 at 7:38 AM, huangdenghui <hdh_1...@163.com> wrote:
>> hi Armando
>> I think this feature causes problem in sriov scenario, since
>> sriov NIC don't support the vf has the same mac,even the port belongs
>> to the different network.
>>
>>
>
Hi Manik,
If the br-tap bridge is not present it is an indication that the TaaS Agent is
not running. For a single-node setup, you will need to add both of the
following lines:
enable_service taas
enable_service taas_openvswitch_agent
to the local.conf file.
You can follow the
Hi,
I recently created a multi-node DevStack environment (based on stable/ocata)
made up of the following nodes:
-1 Controller Node
-1 Network Node
-2 Compute Nodes
All VM instances are only deployed on the 2 compute nodes. Neutron network
services are provided by the network
Hello,
Here is an update on the issue of not being able to capture packets flowing
between two VMs on the same host.
Isolating the problem:
It has been confirmed that the TaaS OVS driver cannot capture packets
ingressing (flowing into) a VM's vNIC under the following conditions:
- The sender
] On TaaS not capturing some packets
between two VMs on the same host
hi,
On Sat, Sep 3, 2016 at 7:32 AM, Anil Rao <anil@gigamon.com> wrote:
> Hello,
>
> Here is an update on the issue of not being able to capture packets
> flowing between two VMs on the same host.
it it
the nf_conntrack_proto_gre kernel module loaded on the network node?
On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao
<anil@gigamon.com<mailto:anil@gigamon.com>> wrote:
Strangely enough, there is no problem when I make use of a VxLAN tunnel to
communicate between the VM (insi
for DevStack
installations?
Regards,
Anil
From: Anil Rao [mailto:anil@gigamon.com]
Sent: Thursday, March 30, 2017 11:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE
packets
This sender failed
Hi,
I am seeing a strange behavior when it comes to floating IPs and L2 GRE tunnels
that I was hoping someone could shed light on.
Inside a tenant (project) I have a VM that wants to communicate with a machine
residing outside the cloud. For this purpose, a floating IP has been assigned
to the
have only seen this problem when using L2 GRE tunnels.
Thanks,
Anil
From: Anil Rao [mailto:anil@gigamon.com]
Sent: Wednesday, March 29, 2017 3:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets
25 matches
Mail list logo
