Re: [openstack-dev] [Openstack] [openstack] API to get tunnel port connect to other host
Hi Vikash,
The VXLAN tunnel endpoint address is listed in the output of a neutron
agent-show :
$ neutron agent-show cb45e3f8-4a28-475a-994d-83bc27806c38
+-++
| Field | Value |
+-++
| admin_state_up | True |
| agent_type | Linux bridge agent |
| alive | True |
| availability_zone ||
| binary | neutron-linuxbridge-agent |
| configurations | { |
| | "tunneling_ip": "172.29.232.66", |
| | "devices": 2, |
| | "interface_mappings": { |
| | "vlan": "br-vlan"|
| | },|
| | "extensions": [], |
| | "l2_population": true,|
| | "tunnel_types": [ |
| | "vxlan" |
| | ],|
| | "bridge_mappings": {} |
| | } |
| created_at | 2017-04-19 23:12:47|
| description ||
| heartbeat_timestamp | 2017-04-28 15:07:59|
| host| 841445-compute007 |
| id | cb45e3f8-4a28-475a-994d-83bc27806c38 |
| started_at | 2017-04-20 17:38:03|
| topic | N/A|
+-++
The actual Layer 4 port used may vary between drivers (linuxbridge vs OVS), but
that would either be hard-coded or defined within a configuration file.
James
From: Vikash Kumar
Date: Friday, April 28, 2017 at 6:50 AM
To: openstack-dev , Openstack Milis
Subject: [Openstack] [openstack-dev][openstack] API to get tunnel port connect
to other host
Is there any neutron API, which returns the tunnel port details connected to
other host ?
For eg. I have Host-A and Host-B. Is there a way to know what is the
tunnel-port on Host-A which connects Host-B ?
Can't use OVS commands directly.
--
Regards,
Vikash
__
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][dvr]What does table 9 used for in br-tun?
Each DVR router has a unique MAC address that can be found in the Neutron DB in the dvr_host_macs table. Those will MACs will likely match what’s in the flow rules there. This presentation from the Paris summit (Page 19-20) breaks it down in some detail. https://www.openstack.org/assets/presentation-media/Openstack-kilo-summit-DVR-Architecture-20141030-Master-submitted-to-openstack.pdf James From: Zhi Chang mailto:chang...@unitedstack.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, March 18, 2016 at 11:33 PM To: openstack-dev mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [neutron][dvr]What does table 9 used for in br-tun? hi guys. In DVR mode, I have some questions about flows of table 9 in br-tun. I see these flows in br-tun: cookie=0x9a5f42115762fc76, duration=392186.503s, table=9, n_packets=1, n_bytes=90, idle_age=247, hard_age=65534, priority=1,dl_src=fa:16:3f:64:82:2f actions=output:1 cookie=0x9a5f42115762fc76, duration=392186.447s, table=9, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:76:6c:6f actions=output:1 cookie=0x9a5f42115762fc76, duration=392186.388s, table=9, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:87:39:a3 actions=output:1 cookie=0x9a5f42115762fc76, duration=392186.333s, table=9, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:93:41:45 actions=output:1 Port 1 is a patch interface which is connecting to br-int. Question A: there are for mac addresses in these flows. But these mac addresses don't in my Neutron. What do they come from?? Question B: The action of each flow is output:1, why? Why put the packets to br-int? Thanks Zhi Chang __ 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][dvr]What does table 9 used for in br-tun?
Err… correction. Each host has a unique MAC, not each router. Sorry! http://assafmuller.com/2015/04/15/distributed-virtual-routing-overview-and-eastwest-routing/ James From: James Denton mailto:james.den...@rackspace.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, March 18, 2016 at 11:47 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron][dvr]What does table 9 used for in br-tun? Each DVR router has a unique MAC address that can be found in the Neutron DB in the dvr_host_macs table. Those will MACs will likely match what’s in the flow rules there. This presentation from the Paris summit (Page 19-20) breaks it down in some detail. https://www.openstack.org/assets/presentation-media/Openstack-kilo-summit-DVR-Architecture-20141030-Master-submitted-to-openstack.pdf James From: Zhi Chang mailto:chang...@unitedstack.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, March 18, 2016 at 11:33 PM To: openstack-dev mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [neutron][dvr]What does table 9 used for in br-tun? hi guys. In DVR mode, I have some questions about flows of table 9 in br-tun. I see these flows in br-tun: cookie=0x9a5f42115762fc76, duration=392186.503s, table=9, n_packets=1, n_bytes=90, idle_age=247, hard_age=65534, priority=1,dl_src=fa:16:3f:64:82:2f actions=output:1 cookie=0x9a5f42115762fc76, duration=392186.447s, table=9, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:76:6c:6f actions=output:1 cookie=0x9a5f42115762fc76, duration=392186.388s, table=9, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:87:39:a3 actions=output:1 cookie=0x9a5f42115762fc76, duration=392186.333s, table=9, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:93:41:45 actions=output:1 Port 1 is a patch interface which is connecting to br-int. Question A: there are for mac addresses in these flows. But these mac addresses don't in my Neutron. What do they come from?? Question B: The action of each flow is output:1, why? Why put the packets to br-int? Thanks Zhi Chang __ 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] - Changing the Neutron default security group rules
My opinion is that the current stance of ‘deny all’ is probably the safest bet for all parties (including users) at this point. It’s been that way for years now, and is a substantial change that may result in little benefit. After all, you’re probably looking at most users removing the default rule(s) just to add something that’s more restrictive and suits their organization’s security posture. If they aren’t, then it’s possible they’re introducing unnecessary risk. There should be some onus put on the provider and/or the user/project/tenant to develop a default security policy that meets their needs, even going so far as to make the configuration of their default security group the first thing they do once the project is created. Maybe some changes to the workflow in Horizon could help mitigate some issues users are experiencing with limited access to instances by allowing them to apply some rules at the time of instance creation rather than associating groups consisting of unknown rules. Or allowing changes to the default security group rules of a project when that project is created. There are some ways to enable providers/users to help themselves rather than a blanket default change across all environments. If I’m a user utilizing multiple OpenStack providers, I’m probably bringing my own security groups and rules with me anyway and am not relying on any provider defaults. James On 3/2/16, 3:47 PM, "Jeremy Stanley" wrote: >On 2016-03-02 21:25:25 + (+), Sean M. Collins wrote: >> Jeremy Stanley wrote: >> > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote: >> > [...] >> > > In my mind, the default security group is there so that as people >> > > are developing their security policy they can at least start with >> > > a default that offers a small amount of protection. >> > >> > Well, not a small amount of protection. The instances boot >> > completely unreachable from the global Internet, so this is pretty >> > significant protection if you consider the most secure system is one >> > which isn't connected to anything. >> >> This is only if you are booting on a v4 network, which has NAT enabled. >> Many public providers, the network you attach to is publicly routed, and >> with the move to IPv6 - this will become more common. Remember, NAT is >> not a security device. > >I agree that address translation is a blight on the Internet, useful >in some specific circumstances (such as virtual address load >balancing) but otherwise an ugly workaround for dealing with address >exhaustion and connecting conflicting address assignments. I'll be >thrilled when its use trails off to the point that newcomers cease >thinking that's what connectivity with the Internet is supposed to >be like. > >What I was referring to in my last message was the default security >group policy, which blocks all ingress traffic. My point was that >dropping all inbound connections, while a pretty secure >configuration, is unlikely to be the desired configuration for >_most_ servers. The question is whether there's enough overlap in >different desired filtering policies to come up with a better >default than one everybody has to change because it's useful for >basically nobody, or whether we can come up with easier solutions >for picking between a canned set of default behaviors (per Monty's >suggestion) which users can expect to find in every OpenStack >environment and which provide consistent behaviors across all of >them. >-- >Jeremy Stanley > >__ >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
Re: [openstack-dev] [neutron][fwaas] how a disabled firewall should behave
Hi Takashi, At least in Liberty, with the reference iptables firewall, it looks like setting the admin state of the firewall to DOWN results in traffic hitting only the neutron-l3-agent-fwaas-defau chain. The action there is to DROP all traffic. James On 1/26/16, 4:15 AM, "Takashi Yamamoto" wrote: >hi, > >what a firewall with admin_state_up=False should do? >my intuition says such a firewall should pass all traffic. (same as no >firewall) >but the reference implementation seems to block everything. (same as a >firewall without any rules) >i wrote a tempest test case (test_firewall_disable_rule) mirroring the >behaviour of the reference implementation >because i couldn't find any documentation. >but i'm now wondering if it was correct. >is the reference implementation's behavior intended? how other vendors do? > >__ >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] [Heat] Add extraroutes support to neutron routers
Hello all, Regarding https://blueprints.launchpad.net/heat/+spec/router-properties-object Does anyone know if there are plans to implement this functionality in an upcoming release? Our use case meets the one described by Kevin, but rather than trying to route traffic to an outside resource, we are routing to another instance off the router. Thanks! — James Denton __ 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
