from:"Anil Rao"

Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets

2017-03-30 Thread Anil Rao

I manually loaded the specified kernel module (nf_conntrack_proto_gre) in the 
network node and now the translation between the VM’ local IP and its assigned 
floating IP is working as expected for L2 GRE traffic.

Thanks a million, Kevin. ☺

Is there something I need to do to automate this step 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 our fraud detection checks and may not be who they appear to 
be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

Hi,

Thanks for the reply. I checked the network node and the nf_conntrack_proto_gre 
kernel module is not loaded. Among the loaded kernel modules the only ones 
bearing the ‘nf_conntrack’ prefix are the following:


-  nf_conntrack

-  nf_conntrack_ipv4

-  nf_conntrfack_ipv6

-  nf_conntrack_netlink

-Anil

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Thursday, March 30, 2017 12:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE 
packets

Do you have 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 (inside the cloud) and an external machine. In this 
case, the network node is performing the correct translation between the VM’s 
local IP and the floating IP currently assigned to it.
So far I have only seen this problem when using L2 GRE tunnels.
Thanks,
Anil

From: Anil Rao [mailto:anil@gigamon.com<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


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

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 VM’s interface.
Case 1: VM communicates with external machine using ‘ping’.
This is successful.
At the network node (from where the packets leave the OpenStack cloud), the 
VM’s local IP address is replaced with its floating IP for outgoing packets. 
Similarly, for incoming packets, the floating IP is replaced with the VM’s 
local IP address.
Case 2: VM communicates with the external machine using an L2 GRE tunnel.
This is not successful.
At the network node, the outgoing packets [still] have the VM’ local IP 
address. It is not surprising that no packets come back for the VM from the 
external machine.
My question is:  why didn’t the network node replace the VM’s IP address with 
its floating IP for the L2 GRE case although it did this for the simple ping 
case?
I see this behavior on a multi-node DevStack based on stable/ocata as well as a 
multi-node production Newton cloud.
Thanks and regards,
Anil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets

2017-03-30 Thread Anil Rao

Hi,

Thanks for the reply. I checked the network node and the nf_conntrack_proto_gre 
kernel module is not loaded. Among the loaded kernel modules the only ones 
bearing the ‘nf_conntrack’ prefix are the following:


-  nf_conntrack

-  nf_conntrack_ipv4

-  nf_conntrfack_ipv6

-  nf_conntrack_netlink

-Anil

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Thursday, March 30, 2017 12:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE 
packets

Do you have 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 (inside the cloud) and an external machine. In this 
case, the network node is performing the correct translation between the VM’s 
local IP and the floating IP currently assigned to it.
So far I have only seen this problem when using L2 GRE tunnels.
Thanks,
Anil

From: Anil Rao [mailto:anil@gigamon.com<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


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

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 VM’s interface.
Case 1: VM communicates with external machine using ‘ping’.
This is successful.
At the network node (from where the packets leave the OpenStack cloud), the 
VM’s local IP address is replaced with its floating IP for outgoing packets. 
Similarly, for incoming packets, the floating IP is replaced with the VM’s 
local IP address.
Case 2: VM communicates with the external machine using an L2 GRE tunnel.
This is not successful.
At the network node, the outgoing packets [still] have the VM’ local IP 
address. It is not surprising that no packets come back for the VM from the 
external machine.
My question is:  why didn’t the network node replace the VM’s IP address with 
its floating IP for the L2 GRE case although it did this for the simple ping 
case?
I see this behavior on a multi-node DevStack based on stable/ocata as well as a 
multi-node production Newton cloud.
Thanks and regards,
Anil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets

2017-03-29 Thread Anil Rao

Strangely enough, there is no problem when I make use of a VxLAN tunnel to 
communicate between the VM (inside the cloud) and an external machine. In this 
case, the network node is performing the correct translation between the VM's 
local IP and the floating IP currently assigned to it.
So far I 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


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

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 VM's interface.
Case 1: VM communicates with external machine using 'ping'.
This is successful.
At the network node (from where the packets leave the OpenStack cloud), the 
VM's local IP address is replaced with its floating IP for outgoing packets. 
Similarly, for incoming packets, the floating IP is replaced with the VM's 
local IP address.
Case 2: VM communicates with the external machine using an L2 GRE tunnel.
This is not successful.
At the network node, the outgoing packets [still] have the VM' local IP 
address. It is not surprising that no packets come back for the VM from the 
external machine.
My question is:  why didn't the network node replace the VM's IP address with 
its floating IP for the L2 GRE case although it did this for the simple ping 
case?
I see this behavior on a multi-node DevStack based on stable/ocata as well as a 
multi-node production Newton cloud.
Thanks and regards,
Anil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron]: floating IP not being set for L2 GRE packets

2017-03-29 Thread Anil Rao

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 VM's interface.
Case 1: VM communicates with external machine using 'ping'.
This is successful.
At the network node (from where the packets leave the OpenStack cloud), the 
VM's local IP address is replaced with its floating IP for outgoing packets. 
Similarly, for incoming packets, the floating IP is replaced with the VM's 
local IP address.
Case 2: VM communicates with the external machine using an L2 GRE tunnel.
This is not successful.
At the network node, the outgoing packets [still] have the VM' local IP 
address. It is not surprising that no packets come back for the VM from the 
external machine.
My question is:  why didn't the network node replace the VM's IP address with 
its floating IP for the L2 GRE case although it did this for the simple ping 
case?
I see this behavior on a multi-node DevStack based on stable/ocata as well as a 
multi-node production Newton cloud.
Thanks and regards,
Anil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Cloud-init VM instance not coming up in a multi-node DevStack envionment

2017-03-01 Thread Anil Rao

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 node.

I am able to create VMs and have them communicate with each other and also with 
external (outside the DevStack environment) endpoints.

However, I find that I am unable to successfully deploy a VM instance that is 
based on cloud-init. As the following console log snippet shows, cloud-init 
running inside a VM instance is unable to get the necessary meta-data and hangs 
during VM instance startup.


91.811361] cloud-init[977]: ci-info: ++Net 
device info+++
[   91.818689] cloud-init[977]: ci-info: 
++--+--+---+---+---+
[   91.825274] cloud-init[977]: ci-info: | Device |  Up  |   Address
|  Mask | Scope | Hw-Address|
[   91.832763] cloud-init[977]: ci-info: 
++--+--+---+---+---+
[   91.839288] cloud-init[977]: ci-info: |   lo   | True |  127.0.0.1   
|   255.0.0.0   |   .   | . |
[   91.857827] cloud-init[977]: ci-info: |   lo   | True |   ::1/128
|   .   |  host | . |
[   91.864806] cloud-init[977]: ci-info: |  eth0  | True | 192.168.1.10 
| 255.255.255.0 |   .   | fa:16:3e:cf:a8:d8 |
[   91.871433] cloud-init[977]: ci-info: |  eth0  | True | 
fe80::f816:3eff:fecf:a8d8/64 |   .   |  link | fa:16:3e:cf:a8:d8 |
[   91.878237] cloud-init[977]: ci-info: 
++--+--+---+---+---+
[   91.896344] cloud-init[977]: ci-info: Route 
IPv4 info
[   91.903652] cloud-init[977]: ci-info: 
+---+-+-+-+---+---+
[   91.912523] cloud-init[977]: ci-info: | Route |   Destination   |   Gateway  
 | Genmask | Interface | Flags |
[   91.930131] cloud-init[977]: ci-info: 
+---+-+-+-+---+---+
[   91.936482] cloud-init[977]: ci-info: |   0   | 0.0.0.0 | 
192.168.1.1 | 0.0.0.0 |eth0   |   UG  |
[   91.942651] cloud-init[977]: ci-info: |   1   | 169.254.169.254 | 
192.168.1.1 | 255.255.255.255 |eth0   |  UGH  |
[   91.948624] cloud-init[977]: ci-info: |   2   |   192.168.1.0   |   0.0.0.0  
 |  255.255.255.0  |eth0   |   U   |
[   91.954798] cloud-init[977]: ci-info: 
+---+-+-+-+---+---+
[   91.961102] cloud-init[977]: 2017-03-01 17:46:38,723 - 
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: bad 
status code [404]
[   92.997374] cloud-init[977]: 2017-03-01 17:46:39,917 - 
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [1/120s]: bad 
status code [404]
[   94.320985] cloud-init[977]: 2017-03-01 17:46:41,240 - 
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2/120s]: bad 
status code [404]
[   95.480615] cloud-init[977]: 2017-03-01 17:46:42,400 - 
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: bad 
status code [404]
[
...

[  118.589843] cloud-init[977]: 2017-03-01 17:47:05,509 - 
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [27/120s]: bad 
status code [404]
[  121.796946] cloud-init[977]: 2017-03-01 17:47:08,716 - 
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [30/120s]: bad 
status code [404]
[  124.918111] cloud-init[977]: 2017-03-01 17:47:11,837 - 
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [33/120s]: bad 
status code [404]
[  129.195778] cloud-init[977]: 2017-03-01 17:47:16,115 - 
url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [37/120s]: bad 
status code [404]


I am not sure what needs to be done to ensure that the metadata endpoint is 
accessible from inside the VM instance and was looking for some assistance. Any 
pointer and/or suggestions would be most appreciated.

Kind regards,
Anil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tap-as-a-Service] Problem in visualizing port-mirroring information

2017-03-01 Thread Anil Rao

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 instructions in the DevStack section of the TaaS GIT repo.

Regards,
Anil

From: Manik Bindlish [mailto:manik.bindl...@nectechnologies.in]
Sent: Wednesday, March 01, 2017 2:58 AM
To: OpenStack Development Mailing List (not for usage questions); 
yamam...@midokura.com
Subject: Re: [openstack-dev] [Tap-as-a-Service] Problem in visualizing 
port-mirroring information

Hi All,
I verified and found out that with my devstack setup ( on Master) , I could not 
see the br-tap ( as shown in the image attached) on my All-In-One deployment.

Please let me know if this is an issue, or is this expected. If it is expected, 
then how can we monitor the mirrored packets without br-tap on OVS.

Regards,
Manik

From: Manik Bindlish [mailto:manik.bindl...@nectechnologies.in]
Sent: Tuesday, February 28, 2017 5:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Problem in visualizing port-mirroring information


Hi,



>  have you tried to disable port security?

I have disabled security group from both the ports. After disabling I am not 
able to ping on the instances.



===



neutron CLI is deprecated and will be removed in the future. Use openstack CLI 
instead.

+---+-+

| Field | Value 
  |

+---+-+

| admin_state_up| True  
  |

| allowed_address_pairs |   
  |

| binding:host_id   | openstack-nti-11  
  |

| binding:profile   | {}
  |

| binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
  |

| binding:vif_type  | ovs   
  |

| binding:vnic_type | normal
  |

| created_at| 2017-02-27T10:13:51Z  
  |

| description   |   
  |

| device_id | 1582911f-ed59-43d6-9711-0e505db5413b  
  |

| device_owner  | compute:None  
  |

| extra_dhcp_opts   |   
  |

| fixed_ips | {"subnet_id": "398b77d2-49aa-4d29-ac4d-f0fd14943120", 
"ip_address": "10.0.0.12"}|

|   | {"subnet_id": "401e3dde-1504-4620-8bbc-0ad6e54b0570", 
"ip_address": "fdaa:99df:2497:0:f816:3eff:fe58:4d36"} |

| id| dde6689e-4f0f-4fe2-9d28-1182ef03e113  
  |

| mac_address   | fa:16:3e:58:4d:36 
  |

| name  |   
  |

| network_id| 7fae0053-aeeb-44ac-9336-41b9cae8a9ba  
  |

| port_security_enabled | True  
  |

| project_id| 9c342a60b7cd4e8cacc8c5f6f92e80e6  
  |

| revision_number   | 13
  |

| security_groups   |

Re: [openstack-dev] [neutron][taas] On TaaS not capturing some packets between two VMs on the same host

2016-09-06 Thread Anil Rao

Hi Takashi,

Yes, this update was for bug 1529595.

Thanks,
Anil

-Original Message-
From: Takashi Yamamoto [mailto:yamam...@midokura.com] 
Sent: Monday, September 05, 2016 11:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][taas] 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 about bug 1529595 ?
https://bugs.launchpad.net/tap-as-a-service/+bug/1529595

>
> 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 port and the receiver port (which is being monitored) 
> reside on the same host.
>
> - The sender port and the receiver port are attached to the same 
> (virtual) network.
>
> We do not have a problem in the above situation for traffic egressing 
> (flowing out) of the VM’s vNIC. We also do not have a problem if the 
> sender port and receiver port are on different hosts, or if the sender 
> and receiver ports belong to different (virtual) networks.
>
> Trafffic Capture Technique:
>
> The implementation uses the following methods to capture packets 
> flowing into and out of a VM’s vNIC.
>
> Egress Side (flowing out of the vNIC):
>
> The ‘in_port=’ check is used to identify packets coming 
> in from the port associated with the VM’s vNIC. This allows us to 
> capture all packets flowing out of the vNIC under question. No problems here.
>
> Ingress Side (flowing into the vNIC):
>
> The ‘dl_vlan=, dl_dst=’ check is used 
> to identify packets destined for the port associated with the VM’s vNIC.
>
> The VLAN tag check was put in place because Neutron port MAC addresses 
> are required to be unique only within a (virtual) network. Now each 
> instance port in br-int gets tagged with a VLAN id that is the same 
> for all ports on that host, which are associated with a particular 
> (virtual) network. Ports belonging to different (virtual) networks 
> therefore get tagged with different VLAN ids.
>
> The combination of “VLAN tag + destination MAC address” was felt to be 
> a sufficient check to ensure that we are truly dealing with traffic 
> heading out of the port being monitored.
>
> Root Cause of the problem:
>
> The br-int bridge operates using the legacy (or normal) mode of operation.
> We have observed that under these circumstances, OVS does not add VLAN 
> tags to packets, as long as they are flowing within the bridge. 
> Packets escaping from br-int into br-tun (via the patch ports), 
> however, get tagged as expected when they arrive in br-tun.
>
> Due to this behavior, our ingress side flow (described above) fails to 
> capture packets flowing into a VM’s vNIC, when it is originating from 
> another port on the same host and on the same virtual network.
>
> Possible Solutions:

i think the it can be fixed by having rules to "tag" packets explicitly.
ie. match on inport and record the logical network in openflow metadata.
(or ovs registers, which is basically the same thing) as it's planned to be 
done for ovs-agent extensions:
https://review.openstack.org/#/c/320439/

>
> OVS documentation (refer: Open vSwitch FAQ) seems to recommend not 
> using the normal operating mode, but handling VLANs explicitly, if 
> flows related to VLAN ids are going to be used.  As mentioned above, 
> to ensure that we correctly handle the Neutron requirement that port 
> MAC addresses are unique only within a virtual network, we need to add 
> VLAN related checks to the TaaS flows. However, br-int today relies on 
> the normal operation mode for most of its work.
>
> This has left us now in a quandary situation. Here is a proposal to 
> move us
> forward:
>
> 1.   As a temporary fix, we can convert the TaaS ingress side flow in
> br-int from
>
> dl_vlan=, dl_dst=
>
> to
>
> dl_dst=
>
> This will obviously mean that we no longer support the notion that 
> Neutron port MAC addresses are unique only within a virtual network. 
> However, given that the probability of two port MAC addresses on a 
> host being the same is low, this should suffice for the short term.

i agree this is the easiest workaround.

>
> [We will also disable the flows used to capture broadcast/multicast 
> traffic flowing into a VM’s vNIC]
>
> 2.   Implement VLAN handling explicitly in br-int and thereby move away
> from the normal operating mode. This will be a core Neutron change and 
> not limited

[openstack-dev] [neutron][taas] On TaaS not capturing some packets between two VMs on the same host

2016-09-02 Thread Anil Rao

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 port and the receiver port (which is being monitored) reside on 
the same host.
- The sender port and the receiver port are attached to the same (virtual) 
network.
We do not have a problem in the above situation for traffic egressing (flowing 
out) of the VM's vNIC. We also do not have a problem if the sender port and 
receiver port are on different hosts, or if the sender and receiver ports 
belong to different (virtual) networks.
Trafffic Capture Technique:
The implementation uses the following methods to capture packets flowing into 
and out of a VM's vNIC.
Egress Side (flowing out of the vNIC):
The 'in_port=' check is used to identify packets coming in from 
the port associated with the VM's vNIC. This allows us to capture all packets 
flowing out of the vNIC under question. No problems here.
Ingress Side (flowing into the vNIC):
The 'dl_vlan=, dl_dst=' check is used to 
identify packets destined for the port associated with the VM's vNIC.
The VLAN tag check was put in place because Neutron port MAC addresses are 
required to be unique only within a (virtual) network. Now each instance port 
in br-int gets tagged with a VLAN id that is the same for all ports on that 
host, which are associated with a particular (virtual) network. Ports belonging 
to different (virtual) networks therefore get tagged with different VLAN ids.
The combination of "VLAN tag + destination MAC address" was felt to be a 
sufficient check to ensure that we are truly dealing with traffic heading out 
of the port being monitored.
Root Cause of the problem:
The br-int bridge operates using the legacy (or normal) mode of operation.  We 
have observed that under these circumstances, OVS does not add VLAN tags to 
packets, as long as they are flowing within the bridge. Packets escaping from 
br-int into br-tun (via the patch ports), however, get tagged as expected when 
they arrive in br-tun.
Due to this behavior, our ingress side flow (described above) fails to capture 
packets flowing into a VM's vNIC, when it is originating from another port on 
the same host and on the same virtual network.
Possible Solutions:
OVS documentation (refer: Open vSwitch FAQ) seems to recommend not using the 
normal operating mode, but handling VLANs explicitly, if flows related to VLAN 
ids are going to be used.  As mentioned above, to ensure that we correctly 
handle the Neutron requirement that port MAC addresses are unique only within a 
virtual network, we need to add VLAN related checks to the TaaS flows. However, 
br-int today relies on the normal operation mode for most of its work.
This has left us now in a quandary situation. Here is a proposal to move us 
forward:

1.   As a temporary fix, we can convert the TaaS ingress side flow in 
br-int from
dl_vlan=, dl_dst=
to
dl_dst=
This will obviously mean that we no longer support the notion that Neutron port 
MAC addresses are unique only within a virtual network. However, given that the 
probability of two port MAC addresses on a host being the same is low, this 
should suffice for the short term.
[We will also disable the flows used to capture broadcast/multicast traffic 
flowing into a VM's vNIC]

2.   Implement VLAN handling explicitly in br-int and thereby move away 
from the normal operating mode. This will be a core Neutron change and not 
limited to just TaaS. However, I have the feeling that there will be other 
projects (outside of TaaS) that will sooner or later have a need to detect 
traffic flowing into a vNIC and they will also run into the same issue we are 
presently facing.



3.   Go back to the (current) TaaS ingress side flow   
(dl_vlan=, dl_dst=) when (2) is implemented. 
We will then be able to once again support the Neutron requirement that port 
MAC addresses need be unique only within a (virtual) network.



[We will re-enable the flows used to capture broadcast/multicast traffic 
flowing into a VM's vNIC]


Thoughts /comments are welcome.
Thanks and regards,
Anil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

2016-08-15 Thread Anil Rao

Hi,

My (original) question regarding the uniqueness of Neutron port MAC addresses 
didn't concern SR-IOV support or vendor NICs. It was simply about the behavior 
w.r.t. virtual networks. I believe Armando has confirmed what I had been 
suspecting.

Thanks,
Anil

-Original Message-
From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] 
Sent: Friday, August 12, 2016 1:46 AM
To: Moshe Levi
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

That was my feeling Moshe, thanks for checking.

Anil, which card and drivers are you using exactly?

You should probably contact your card vendor and check if they have a fix for 
the issue, which seems more like a bug on their implementation of the embedded 
switch, the card or the driver.

Best regards,
Miguel  Ángel.

On Thu, Aug 11, 2016 at 12:49 PM, Moshe Levi <mosh...@mellanox.com> wrote:
> Hi Anil,
>
>
> I tested it with Mellanox NIC and it working
>
> 16: enp6s0d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP 
> mode DEFAULT group default qlen 1000
> link/ether 00:02:c9:e9:c2:12 brd ff:ff:ff:ff:ff:ff
> vf 0 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
> vf 1 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
> vf 2 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
> vf 3 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
> vf 4 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
> vf 5 MAC fa:16:3e:0d:8c:a2, vlan 192, spoof checking on, link-state enable
> vf 6 MAC fa:16:3e:0d:8c:a2, vlan 190, spoof checking on, link-state enable
> vf 7 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, 
> link-state auto
>
> I guess the problem is with the SR-IOV NIC/ driver you are using maybe 
> you should contact them
>
>
> -Original Message-
> From: Moshe Levi
> Sent: Wednesday, August 10, 2016 5:59 PM
> To: 'Miguel Angel Ajo Pelayo' <majop...@redhat.com>; OpenStack 
> Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Cc: Armando M. <arma...@gmail.com>
> Subject: RE: [openstack-dev] [neutron] Neutron Port MAC Address 
> Uniqueness
>
> Miguel,
>
> I talked to our driver architect and according to him this is vendor 
> implementation (according to him this  should work with  Mellanox NIC) I need 
> to verify that this indeed working.
> I will update after I will prepare SR-IOV setup and try it myself.
>
>
> -Original Message-
> From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
> Sent: Wednesday, August 10, 2016 12:04 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Cc: Armando M. <arma...@gmail.com>; Moshe Levi <mosh...@mellanox.com>
> Subject: Re: [openstack-dev] [neutron] Neutron Port MAC Address 
> Uniqueness
>
> @moshe, any insight on this?
>
> I guess that'd depend on the nic internal switch implementation and how the 
> switch ARP tables are handled there (per network, or global per switch).
>
> If that's the case for some sr-iov vendors (or all), would it make sense to 
> have a global switch to create globally unique mac addresses (for the same 
> neutron deployment, of course).
>
> On 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.
>>
>>
>> 发自网易邮箱手机版
>>
>>
>> On 2016-08-10 04:55 , Armando M. Wrote:
>>
>>
>>
>> On 9 August 2016 at 13:53, Anil Rao <anil@gigamon.com> wrote:
>>>
>>> Is the MAC address of a Neutron port on a tenant virtual network 
>>> globally unique or unique just within that particular tenant network?
>>
>>
>> The latter:
>>
>> https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.
>> py#L139
>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Anil
>>>
>>>
>>> 
>>> _ _ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>>
>> _

Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

2016-08-09 Thread Anil Rao

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 
<anil@gigamon.com<mailto:anil@gigamon.com>> wrote:
Is the MAC address of a Neutron port on a tenant virtual network globally 
unique or unique just within that particular tenant network?

The latter:

https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L139

Thanks,
Anil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

2016-08-09 Thread Anil Rao

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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][taas] Taas can not capture the packet, if the two VM on the same host. Is it a Bug?

2016-08-05 Thread Anil Rao

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: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][taas] Taas can not capture the packet, 
if the two VM on the same host. Is it a Bug?

Hi Jimmy,

I guess that it has not been resoved yet.
You should try to ask it on IRC meeting, I think.

http://eavesdrop.openstack.org/#Tap_as_a_Service_Meeting

Regards,
Kaz


From: 张广明 
Subject: Re: [openstack-dev] [neutron][taas] Taas can not capture the  packet, 
if the two VM on the same host. Is it a Bug?
Date: Tue, 5 Jul 2016 19:31:14 +0800

> Hi Kaz
> Thanks for your answer. But int the log, i can not find how to 
> resolve this issue. In fact ,this issue is not related with br-ex.
> In OVS, the normal action add or remove vlan id when output the pac 
> ket. So we should add another rule that use in_port that belongs to 
> the same vlan with mirror port as rule condition  in br- int.
>
>
>
>  Jimmy
>
> 2016-07-05 17:01 GMT+08:00 SUZUKI, Kazuhiro :
>
>> Hi,
>>
>> I also have seen the same situation.
>> The same issue is discussed at the IRC meeting of TaaS.
>> Please take a look at the log.
>>
>>
>> http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-04-13-
>> 06.30.log.html
>>
>> Regards,
>> Kaz
>>
>>
>> From: 张广明 
>> Subject: [openstack-dev] [neutron][taas] Taas can not capture the 
>> packet, if the two VM on the same host. Is it a Bug?
>> Date: Fri, 1 Jul 2016 16:03:53 +0800
>>
>> > Hi ,
>> > I found a limitation when use taas.  My test case is descrip
>> ped as
>> > follow:
>> > VM1 and VM2 is running on the same host and  they are belong
>>  the
>> vlan.
>> > The monitor VM is on the same host or the  other host . I want t
>> o monitor
>> > the only INPUT flow to the VM1.
>> > So I configure the tap-flow like this "neutron tap-flow-crea
>> te
>> --port
>> > 2a5a4382-a600-4fb1-8955-00d0fc9f648f  --tap-service 
>> > c510e5db-4ba8-48e3-bfc8-1f0b61f8f41b --direction IN ".
>> > When ping from VM2 to VM1.  I can not get the flow in the mo
>> nitor VM.
>> >The reason is the the flow from VM2 to VM1 in br-int has not
>> vlan
>> > information. The vlan tag was added in flow when output the pack
>> et  in
>> OVS.
>> > So the code in file ovs_taas.py did not work in this case .
>> >
>> >  if direction == 'IN' or direction == 'BOTH':
>> > port_mac = tap_flow['port_mac']
>> >  self.int_br.add_flow(table=0,
>> >  priority=20,
>> > dl_vlan=port_vlan_id,
>> > dl_dst=port_mac,
>> >
>> actions="normal,mod_vlan_vid:%s,output:%s" %
>> >  (str(taas_id), str(patch_int_ta
>> p_id)))
>> >
>> >
>> >
>> >
>> >  Is this is a Bug or a Design ??
>> >
>> >
>> >
>> > Thanks.
>>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][taas] IRC Meeting Canceled (week of 7/4/2016)

2016-07-05 Thread Anil Rao

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 (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][taas] TaaS meetup in Austin

2016-04-28 Thread Anil Rao

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,
Anil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][taas] Problem receiving mirrored ingress traffic and a solution suggestion

2016-04-14 Thread Anil Rao

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 in from br-tun. Your 
suggested fix might suffice for a single-node DevStack environment but I don’t 
think it is generic enough to support the multi-node situation.

We are looking into this and hope to come up with a fix that works for both 
cases. We’ll keep you updated.

Thanks,
Anil

From: Simhon Doctori שמחון דוקטורי [mailto:simh...@gmail.com]
Sent: Wednesday, April 13, 2016 12:56 AM
To: openstack-dev@lists.openstack.org
Cc: yossi barshishat יוסי ברששת
Subject: [openstack-dev] [neutron][taas] Problem receiving mirrored ingress 
traffic and a solution suggestion

Anil and all Hi,
Continuing the discussion from the IRC about the problem with the mirrored 
traffic incoming to a VM not being mirrored. Indeed, it does look like the bug 
mentioned on https://bugs.launchpad.net/tap-as-a-service/+bug/1544176.
I am using Liberty, ovs 2.0.2, Devstack, Single node.

As I mentioned, the problem is due to a rule match including the vlan tag. 
Since the VM port is receiving data, after the ovs stripped the vlan of the 
virtual network, there is no reason for doing match on a vlan, this rule does 
not have any hits:

cookie=0x0, duration=59625.138s, table=0, n_packets=0, n_bytes=0, 
idle_age=59625, priority=20,dl_vlan=3,dl_dst=fa:16:3e:d3:60:16 
actions=NORMAL,mod_vlan_vid:3901,output:11
IMHO, the solution should be a rule where there is no vlan in match AND an 
action where output port is the destination port. Since you already have a 
match of a destination mac, why not output it to the destination vm interface, 
together with the patch-int-tap interface? This rule works for me:

cookie=0x0, duration=20.422s, table=0, n_packets=42, n_bytes=3460, idle_age=1, 
priority=20,dl_dst=fa:16:3e:d3:60:16 
actions=output:14,mod_vlan_vid:3901,output:11
As you can see, there is no vlan in match, and two output ports - 14 for the vm 
interface, and 11 for the patch interface together with the vlan.

Simhon Doctori
imVision Technologies.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][taas] service show omits the network id

2016-04-13 Thread Anil Rao

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 שמחון דוקטורי [mailto:simh...@gmail.com]
Sent: Wednesday, April 13, 2016 4:46 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][taas] service show omits the network id

Hi,
Although the network id is essential argument when creating the service, it is 
not shown when doing show for the service. Either using cli or rest-api.

{
  "tap_services": [
{
  "tenant_id": "619ce6d9192c494fbf3dd7947ef78f9f",
  "port_id": "2250affe-6a38-4678-b4ab-969c36cc6f12",
  "description": "",
  "name": "tapServicePort",
  "id": "5afd1d73-0d8c-4931-bc6c-c8388ba6508f"
}
  ]
}

neutron) tap-service-show 5afd1d73-0d8c-4931-bc6c-c8388ba6508f
+-+--+
| Field   | Value|
+-+--+
| description |  |
| id  | 5afd1d73-0d8c-4931-bc6c-c8388ba6508f |
| name| tapServicePort   |
| port_id | 2250affe-6a38-4678-b4ab-969c36cc6f12 |
| tenant_id   | 619ce6d9192c494fbf3dd7947ef78f9f |
+-+--+

Is this in purpose or a bug ?
Simhon Doctori
imVision Technologies.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][taas] Asynchronous TaaS APIs

2016-03-21 Thread Anil Rao

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. One of the 
operations performed by the plugin is to issue tasks to the TaaS agent/driver. 
However, failures encountered by the latter don't get returned back to the 
user. This can lead to problem situations where the configuration state might 
reflect that tap-services and/or tap-flows have been successfully created, but 
in actuality that may not always be the case.
I think we should adopt an asynchronous model, where we maintain the state for 
tap-service and tap-flow objects. Valid states could be "created", 
"create-pending" and "failed." In addition, we will need a suitable mechanism 
to have the plugin extract the current state from the agent/driver and provide 
it to the end-user.
Another scenario where the asynchronous model with states (as described above) 
will be useful is for TaaS backend implementations that may take a while to 
complete certain operations. In this situation, the front-end doesn't need to 
block completely; it can return as soon as the request is successfully handed 
to the agent or if the config tasks itself failed. For the former case, 
subsequent queries of the object's state will indicate if the operation has 
completed, is still pending or has failed.
Thoughts...?
Anil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][taas] Proposal of Dashboard for TaaS

2016-03-08 Thread Anil Rao

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 tap-service instance or a 
tap-flow) it would be nice to also provide some extra information associated 
with that port, such as the VM it belongs to and the IP address.  This will 
look very similar to what is being done today when associating a floating IP 
with a VM vNIC. The extra context will allow users to identify their source and 
destination end-points with more ease. If a VM is not currently associated with 
a port then the extra information is not necessary.

b.  When selecting the traffic monitoring direction, it would be nice to 
provide two check boxes, one for 'ingress' and the other for 'egress'. A user 
wishing to monitor a port in both directions can select both check boxes. I 
feel this looks better than having an option  called 'both'.

2.   Using the Tap Services Tab

a.   Allow tap-flow-create and tap-flow-delete operations to also be 
carried out from here. This will let users who prefer working in this fashion 
get everything done from the same place.

b.  Provide a way to list tap flows currently associated with a tap service.

c.   Allow multiple tap-flows to be created at the same time. Let the user 
pick multiple source ports (and traffic monitoring directions) and have all of 
them attached to a designated tap-service.

3.   Using the Network Topology Tab

a.   Allow tap-create and tap-delete operations to be also carried out from 
here. This will allow users who prefer working in this fashion get everything 
done from the same place. The user can pick the destination port (from one of 
the existing VMs) in the same way that a source port is picked when creating a 
tap-flow.

b.  Color code the VM whose vNIC is attached to the destination port of a 
tap-service.

c.   BONUS: Allow the user to click on a VM that is serving as the 
destination side of a tap-service and highlight all the VMs that are attached 
to tap-flows associated with that tap-service.
Regards,
Anil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][taas] tap-service-list / tap-flow-list failure when list is empty

2016-03-04 Thread Anil Rao

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 a failure when there are no 
tap-services.

2.   The tap-flow-list command returns a failure when there are no 
tap-flows.

3.   Both commands work as expected when the respective objects are present.

See example output (for tap-services) below.

osadmin@ds-ctl:~$ neutron tap-service-list
list index out of range
osadmin@ds-ctl:~$ neutron tap-service-create --name TS1 --description 
"tap-service-1" --port 2100906e-cb1a-4ab4-b50f-77f55a3f0793 --network 
cfb88d7c-8e9e-4954-a923-2f9cac3b4ebe
Created a new tap_service:
+-+--+
| Field   | Value|
+-+--+
| description | tap-service-1|
| id  | 1086170e-a9cd-41bd-a5df-7ad4782da337 |
| name| TS1  |
| port_id | 2100906e-cb1a-4ab4-b50f-77f55a3f0793 |
| tenant_id   | 93c1c68f06e843938159329bfdbed384 |
+-+--+
osadmin@ds-ctl:~$ neutron tap-service-list
+--+--+
| id   | name |
+--+--+
| 1086170e-a9cd-41bd-a5df-7ad4782da337 | TS1  |
+--+--+
osadmin@ds-ctl:~$ neutron tap-service-delete TS1
Deleted tap_service: TS1
osadmin@ds-ctl:~$ neutron tap-service-list
list index out of range

Here is the output of tap-service-list with the "-debug" flag. The error is 
being reported by neutronclient.shell.


DEBUG: keystoneauth.session RESP: [200] Date: Fri, 04 Mar 2016 22:50:16 GMT 
Connection: keep-alive Content-Type: application/json; charset=UTF-8 
Content-Length: 20 X-Openstack-Request-Id: 
req-641ba1a0-7f49-4460-b720-313d92009b87
RESP BODY: {"tap_services": []}

ERROR: neutronclient.shell list index out of range
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/shell.py", line 
819, in run_subcommand
return run_command(cmd, cmd_parser, sub_argv)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/shell.py", line 
105, in run_command
return cmd.run(known_args)
  File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/common/command.py", line 
29, in run
return super(OpenStackCommand, self).run(parsed_args)
  File "/usr/local/lib/python2.7/dist-packages/cliff/display.py", line 88, in 
run
self.produce_output(parsed_args, column_names, data)
  File "/usr/local/lib/python2.7/dist-packages/cliff/lister.py", line 51, in 
produce_output
parsed_args,
  File "/usr/local/lib/python2.7/dist-packages/cliff/formatters/table.py", line 
64, in emit_list
stdout, x, int(parsed_args.max_width), min_width)
  File "/usr/local/lib/python2.7/dist-packages/cliff/formatters/table.py", line 
148, in _assign_max_widths
first_line = x.get_string().splitlines()[0]
IndexError: list index out of range
list index out of range

It appears that other list commands associated with the neutron client also 
show the same type of failure when their lists are empty.

osadmin@ds-ctl:~$ neutron agent-list
list index out of range
osadmin@ds-ctl:~$ neutron address-scope-list
list index out of range

Thanks,
Anil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][taas] Voting for new core reviewers

2016-03-01 Thread Anil Rao

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: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][taas] Voting for new core reviewers


+1 to both Soichi and Yamamoto
--
Date: Tue, 1 Mar 2016 21:26:59 +0100
From: Vinay Yadhav >
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev]  [neutron][taas]
Message-ID:

>
Content-Type: text/plain; charset="utf-8"

Hi All,

Its time to induct new members to the TaaS core reviewers, to kick start
the process i nominate the following developers and active contributors to
the TaaS project

1. Yamamoto Takashi
2. Soichi Shigeta


Cheers,
Vinay Yadhav

--
Thanks and Regards,
Reedip Banerjee
IRC: reedip



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Tap-aaS Spec for Kilo

2014-12-09 Thread Anil Rao

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 list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

2014-05-28 Thread Anil Rao

Great!

Should this also be added to the Neutron milestones/blueprints page for Juno-2?

Thanks,
Anil

From: Vinay Yadhav [mailto:vinayyad...@gmail.com]
Sent: Wednesday, May 28, 2014 5:13 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension 
in Neutron

Hi,

Issue resolved. The specification is now submitted for review: 
https://review.openstack.org/96149

Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}

On Wed, May 28, 2014 at 12:16 PM, Vinay Yadhav 
vinayyad...@gmail.commailto:vinayyad...@gmail.com wrote:
Hi all,

I am experiencing an issue when i try to commit the spec for review.

This is the message that i get:

 fatal: ICLA contributor agreement requires current contact information.

Please review your contact information:

  https://review.openstack.org/#/settings/contact

fatal: The remote end hung up unexpectedly
ericsson@ericsson-VirtualBox:~/openstack_neutron/checkin/neutron-specs/specs/juno$
 git review
fatal: ICLA contributor agreement requires current contact information.

Please review your contact information:

  https://review.openstack.org/#/settings/contact

fatal: The remote end hung up unexpectedly

I am trying to see what has gone wrong with my account.

In the mean while please use the attached spec for the irc meeting today.

I will try to fix the issue with my account soon and commit it for review.

Cheers,

main(i){putchar((5852758((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: Wednesday, May 21, 2014 10:23 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension 
in Neutron

Hi,

I am attaching the first version of the neutron spec for Tap-as-a-Service (Port 
Mirroring).

It will be formally commited soon in git.

Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}

On Tue, May 20, 2014 at 7:12 AM, Kanzhe Jiang 
kanzhe.ji...@bigswitch.commailto:kanzhe.ji...@bigswitch.com wrote:
Vinay's proposal was based on OVS's mirroring feature.

On Mon, May 19, 2014 at 9:11 PM, YAMAMOTO Takashi 
yamam...@valinux.co.jpmailto:yamam...@valinux.co.jp wrote:
 Hi,

 I am Vinay, working with Ericsson.

 I am interested in the following blueprint regarding port mirroring
 extension in neutron:
 https://blueprints.launchpad.net/neutron/+spec/port-mirroring

 I am close to finishing an implementation for this extension in OVS plugin
 and would be submitting a neutron spec related to the blueprint soon.
does your implementation use OVS' mirroring functionality?
or is it flow-based?

YAMAMOTO Takashi

 I would like to know other who are also interested in introducing Port
 Mirroring extension in neutron.

 It would be great if we can discuss and collaborate in development and
 testing this extension

 I am currently attending the OpenStack Summit in Atlanta, so if any of you
 are interested in the blueprint, we can meet here in the summit and discuss
 how to proceed with the blueprint.

 Cheers,
 main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kanzhe Jiang
MTS at BigSwitch

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

2014-05-21 Thread Anil Rao

Is this discussion going to happen in today’s meeting?

-Anil

From: Stephen Wong [mailto:s3w...@midokura.com]
Sent: Saturday, May 17, 2014 11:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension 
in Neutron

Hi Sumit,

Srinivasa has agreed to join the advanced service meeting to kick off the 
discussion on this topic at our regular meeting[1]. Looking forward to working 
with him and others that are interested in getting this tap service effort 
started in Neutron.

Thanks,
- Stephen

[1] 
https://wiki.openstack.org/wiki/Meetings#Neutron_Advanced_Services.27_Common_requirements_team_meeting

On Sat, May 17, 2014 at 9:05 PM, Sumit Naiksatam 
sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com wrote:
Hi, Unfortunately I could not participate in this discussion. As
requested in this thread earlier, it would be good to get a summary of
the discussion.

We, in the advanced services team in Neutron, have long discussed[1]
the possibility of accommodating a tap service. So I would like to
understand if/how this discussion is aligning with that goal.

Thanks,
~Sumit.

[1] 
https://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...@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,

 Booked a slot tomorrow at 9:20 AM at the neutron pod.

 Cheers,

 main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}

 On Thu, May 15, 2014 at 2:50 PM, Stephen Wong 
 s3w...@midokura.commailto:s3w...@midokura.com wrote:

 Hi Vinay,

 I am interested. Please sign up a slot on Neutron pod for tomorrow
 (Friday) and announce the timeslot to the ML.

 Thanks,

 - Stephen

 On Thu, May 15, 2014 at 7:13 AM, Vinay Yadhav 
 vinayyad...@gmail.commailto:vinayyad...@gmail.com wrote:

 Hi,

 I am Vinay, working with Ericsson.

 I am interested in the following blueprint regarding port mirroring
 extension in neutron:
 https://blueprints.launchpad.net/neutron/+spec/port-mirroring

 I am close to finishing an implementation for this extension in OVS plugin
 and would be submitting a neutron spec related to the blueprint soon.

 I would like to know other who are also interested in introducing Port
 Mirroring extension in neutron.

 It would be great if we can discuss and collaborate in development and
 testing this extension

 I am currently attending the OpenStack Summit in Atlanta, so if any of you
 are interested in the blueprint, we can meet here in the summit and discuss
 how to proceed with the blueprint.

 Cheers,

 main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

2014-05-21 Thread Anil Rao

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 Mirroring Extension 
in Neutron

Hi,

I am attaching the first version of the neutron spec for Tap-as-a-Service (Port 
Mirroring).

It will be formally commited soon in git.

Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}

On Tue, May 20, 2014 at 7:12 AM, Kanzhe Jiang 
kanzhe.ji...@bigswitch.commailto:kanzhe.ji...@bigswitch.com wrote:
Vinay's proposal was based on OVS's mirroring feature.

On Mon, May 19, 2014 at 9:11 PM, YAMAMOTO Takashi 
yamam...@valinux.co.jpmailto:yamam...@valinux.co.jp wrote:
 Hi,

 I am Vinay, working with Ericsson.

 I am interested in the following blueprint regarding port mirroring
 extension in neutron:
 https://blueprints.launchpad.net/neutron/+spec/port-mirroring

 I am close to finishing an implementation for this extension in OVS plugin
 and would be submitting a neutron spec related to the blueprint soon.
does your implementation use OVS' mirroring functionality?
or is it flow-based?

YAMAMOTO Takashi

 I would like to know other who are also interested in introducing Port
 Mirroring extension in neutron.

 It would be great if we can discuss and collaborate in development and
 testing this extension

 I am currently attending the OpenStack Summit in Atlanta, so if any of you
 are interested in the blueprint, we can meet here in the summit and discuss
 how to proceed with the blueprint.

 Cheers,
 main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kanzhe Jiang
MTS at BigSwitch

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

2014-05-15 Thread Anil Rao

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,

Booked a slot tomorrow at 9:20 AM at the neutron pod.

Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}

On Thu, May 15, 2014 at 2:50 PM, Stephen Wong 
s3w...@midokura.commailto:s3w...@midokura.com wrote:
Hi Vinay,

I am interested. Please sign up a slot on Neutron pod for tomorrow (Friday) 
and announce the timeslot to the ML.

Thanks,
- Stephen

On Thu, May 15, 2014 at 7:13 AM, Vinay Yadhav 
vinayyad...@gmail.commailto:vinayyad...@gmail.com wrote:
Hi,

I am Vinay, working with Ericsson.

I am interested in the following blueprint regarding port mirroring extension 
in neutron: https://blueprints.launchpad.net/neutron/+spec/port-mirroring

I am close to finishing an implementation for this extension in OVS plugin and 
would be submitting a neutron spec related to the blueprint soon.

I would like to know other who are also interested in introducing Port 
Mirroring extension in neutron.

It would be great if we can discuss and collaborate in development and testing 
this extension

I am currently attending the OpenStack Summit in Atlanta, so if any of you are 
interested in the blueprint, we can meet here in the summit and discuss how to 
proceed with the blueprint.

Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets

Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets

Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets

[openstack-dev] [neutron]: floating IP not being set for L2 GRE packets

[openstack-dev] [all] Cloud-init VM instance not coming up in a multi-node DevStack envionment

Re: [openstack-dev] [Tap-as-a-Service] Problem in visualizing port-mirroring information

Re: [openstack-dev] [neutron][taas] On TaaS not capturing some packets between two VMs on the same host

[openstack-dev] [neutron][taas] On TaaS not capturing some packets between two VMs on the same host

Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

[openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

Re: [openstack-dev] [neutron][taas] Taas can not capture the packet, if the two VM on the same host. Is it a Bug?

[openstack-dev] [neutron][taas] IRC Meeting Canceled (week of 7/4/2016)

[openstack-dev] [neutron][taas] TaaS meetup in Austin

Re: [openstack-dev] [neutron][taas] Problem receiving mirrored ingress traffic and a solution suggestion

Re: [openstack-dev] [neutron][taas] service show omits the network id

[openstack-dev] [neutron][taas] Asynchronous TaaS APIs

[openstack-dev] [neutron][taas] Proposal of Dashboard for TaaS

[openstack-dev] [neutron][taas] tap-service-list / tap-flow-list failure when list is empty

Re: [openstack-dev] [neutron][taas] Voting for new core reviewers

[openstack-dev] [neutron] Tap-aaS Spec for Kilo

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

25 matches

Site Navigation

Mail list logo

Footer information