Wednesday, 2016-03-30

*** prithiv has joined #openstack-astara00:06
*** jordantardif has quit IRC00:07
*** prithiv has quit IRC00:56
*** prithiv has joined #openstack-astara00:57
*** prithiv has quit IRC00:57
openstackgerritMerged openstack/astara: devstack: Bump alive_timeout
openstackgerritAdam Gandelman proposed openstack/astara-neutron: Remove UNRELEASED tag from Mitaka release notes
openstackgerritAdam Gandelman proposed openstack/astara: Remove UNRELEASED tag from Mitaka release notes
*** jordant has joined #openstack-astara02:56
*** jordant has quit IRC02:56
adam_gthe gate seems to be stabilized thanks to a combo of +
adam_gmarkmcclain,  ^03:11
adam_gmarkmcclain, rods is the bug fix we want backported to the stable/mitaka branch so we can cut the RC2 tag from there. ive self-approved the gate fixers but would appreciate it if you guys could approve that one just to be kosher03:12
adam_gshould be good to tag the final RCs on Thurs provided the gate doesnt continue to blow up03:12
adam_gtty then03:12
openstackgerritMerged openstack/astara-neutron: Remove UNRELEASED tag from Mitaka release notes
openstackgerritMerged openstack/astara: Remove UNRELEASED tag from Mitaka release notes
*** jordant has joined #openstack-astara04:11
*** ronis has joined #openstack-astara07:25
*** elo has quit IRC07:38
*** elo has joined #openstack-astara07:38
*** prithiv has joined #openstack-astara08:51
*** prithiv has quit IRC09:30
*** prithiv has joined #openstack-astara10:02
*** prithiv has quit IRC11:19
*** cleverdevil has quit IRC11:40
*** cleverdevil has joined #openstack-astara11:47
*** openstackgerrit has quit IRC11:47
*** openstackgerrit has joined #openstack-astara11:48
*** openstackgerrit has quit IRC12:33
*** openstackgerrit has joined #openstack-astara12:33
*** openstackgerrit has quit IRC13:18
*** openstackgerrit has joined #openstack-astara13:18
*** xiayu1 has quit IRC13:19
*** xiayu has joined #openstack-astara13:19
*** ronis has quit IRC14:26
*** jordantardif has joined #openstack-astara16:06
*** openstack has joined #openstack-astara17:05
*** ronis has joined #openstack-astara17:20
stupidnicCould somebody explain to me where security groups are implemented in Astara? Are they stored as iptables rules in the router? If so where would they be? Are they namespaced?18:07
*** davidlenwell has quit IRC18:27
stupidnicnevermind... I now understand that they are implemented in the hypervisor. I was trying to understand how Astara would work with the DHCP and why our configuration still requires implicit DHCP rules in all security groups18:34
*** davidlenwell has joined #openstack-astara18:34
markmcclainstupidnic: that was addressed here:
markmcclainshould be in stable/(liberty|mitaka) and master19:53
stupidnicmarkmcclain: yeah, I actually have that code, but it still doesn't work without the security group rules, and that is what I was trying to determine19:56
stupidnicThis could be an instance of version mismatch19:56
markmcclainwe've tested with default sec group rules for some time19:57
stupidnicIf you recall I am running Liberty but I am running astara master19:57
markmcclainright... so the change was backported to astara-neutron stable/liberty branch19:57
markmcclainmake sure the astara-neutron package is the latest from stable19:57
markmcclainthe backport was merged 2/1 (
stupidnicYeah, I mean I am running master astara code with a Liberty install20:00
stupidnicLiberty should still reference akanda, but my code references astara20:00
stupidnicAlthough looking at the code they appear to be the same20:01
*** ronis has quit IRC20:06
stupidnicmarkmcclain: can you explain exactly what this is supposed to be doing? From what I gather there is some MAC address filtering on the routers that is supposed block non-recognized MAC addresses from instances, is that correct?20:20
stupidnicOr is that on the hypervisor?20:21
markmcclainthe mac filtering is on the hypervisor20:21
markmcclainthis code adds rules to allow DHCP since by default it is blocked to prevent DHCP spoofing20:21
markmcclains/spoofing/rogue severs/20:21
stupidnicRight. Okay.20:22
stupidnicSo should this be in the incoming, outgoing, or source filtering?20:22
markmcclainshould see 2 rules20:23
stupidnicin which chain?20:23
markmcclainone for 68 > 67 accepting traffic from VM and the other for 67 > 68 dropping if originates from VM20:24
markmcclainstupidnic: does the router instance have security group rules?20:25
markmcclainby default nova should not be installing any rules for it20:25
markmcclainwondering if that's the problem20:25
stupidnicmarkmcclain: I am not sure. How would I check that?20:25
stupidnicI placed my router instances in the service project20:26
markmcclainon the hypervisor where a router is running20:26
stupidnic(since that made sense to me)20:26
markmcclaindump the iptables via iptables-save20:26
markmcclainright the routers are owned by service tenant20:26
stupidnicOkay... so looking at the outgoing chain... I can see that there is a rule for sport 68 to 67 with a drop on sport 67 to 6820:47
stupidnicand looking at the incoming chain there is a rule with source of the router's IP sport 67 to 6820:47
stupidnicso the rules are there20:47
*** openstackgerrit has quit IRC20:48
*** openstackgerrit has joined #openstack-astara20:48
stupidnicOkay. Well I just fired up an instance and didn't have any issues with getting an IP address with a limited security group (basically only 22 inbound)20:54
stupidnicSo I am not sure why some of my clients require it20:54
stupidnicperhaps it is an issue with the router version I have running? My project (admin) has a newer version that supports LBaaSv2 where as other clients have older versions20:55
stupidnicYeah, I just confirmed that it doesn't work with another client's project (the one that was complaining), same instance image (Ubuntu).21:08
stupidnicI will do a router refresh on this client once I clean up the new router image21:08
*** prithiv has joined #openstack-astara21:11
*** phil_h has quit IRC21:20
*** phil_h has joined #openstack-astara21:36
*** shashank_hegde has joined #openstack-astara21:37
*** davidlenwell has quit IRC21:48
*** davidlenwell has joined #openstack-astara21:55
*** shashank_hegde has quit IRC22:07
*** shashank_hegde has joined #openstack-astara22:16
markmcclainstupidnic: it might actually be related to the age of the instance22:18
stupidnicThe router instance?22:18
markmcclainany instances started prior to updating astara-neutron with that change would not have the proper DHCP rules22:18
stupidnicOkay. That's most likely the culprit then22:18
stupidnicI just finished tweaking the new image and updating astara's config to point to it22:19
stupidnicI just rebooted the admin router instance and it works as planned, so I am guessing that is probably the case. I will sneak in a reboot on the other instances to get them on the new router instances22:20
markmcclainok cool22:20
stupidnicmarkmcclain: confirmed. The client that was having the issue previously no longer has the same issue. Updating the router image did the trick.22:44
*** prithiv1 has joined #openstack-astara23:00
*** prithiv has quit IRC23:00
*** prithiv has joined #openstack-astara23:07
*** prithiv1 has quit IRC23:08
*** fzylogic has joined #openstack-astara23:10
*** shashank_hegde has quit IRC23:13
*** shashank_hegde has joined #openstack-astara23:17
*** prithiv has quit IRC23:26
*** prithiv has joined #openstack-astara23:33
*** prithiv has quit IRC23:33
*** shashank_hegde has quit IRC23:47
*** shashank_hegde has joined #openstack-astara23:54
openstackgerritmark mcclain proposed openstack/astara-appliance: Ensure VPN settings are more prescriptive.

Generated by 2.14.0 by Marius Gedminas - find it at!