| *** hongbin has joined #openstack-lbaas | 01:23 | |
| *** bcafarel has quit IRC | 01:40 | |
| *** bcafarel has joined #openstack-lbaas | 02:00 | |
| *** ramishra has joined #openstack-lbaas | 02:50 | |
| *** ramishra has quit IRC | 03:29 | |
| *** ramishra has joined #openstack-lbaas | 03:45 | |
| *** hongbin has quit IRC | 04:23 | |
| *** sapd1 has quit IRC | 04:38 | |
| *** sapd1 has joined #openstack-lbaas | 04:59 | |
| *** pcaruana has joined #openstack-lbaas | 05:36 | |
| *** pcaruana has quit IRC | 05:47 | |
| *** ramishra has quit IRC | 06:16 | |
| *** mnaser has quit IRC | 06:16 | |
| *** mnaser has joined #openstack-lbaas | 06:17 | |
| *** ramishra has joined #openstack-lbaas | 06:18 | |
| *** beisner has quit IRC | 06:30 | |
| *** beisner has joined #openstack-lbaas | 06:31 | |
| *** ccamposr has joined #openstack-lbaas | 06:40 | |
| *** ramishra_ has joined #openstack-lbaas | 06:59 | |
| *** ramishra has quit IRC | 07:01 | |
| *** tomtom001 has quit IRC | 07:02 | |
| *** abaindur has quit IRC | 07:56 | |
| *** pcaruana has joined #openstack-lbaas | 07:57 | |
| *** pcaruana is now known as pcaruana|elisa| | 07:59 | |
| *** celebdor has joined #openstack-lbaas | 08:10 | |
| *** sapd1 has quit IRC | 08:10 | |
| *** sapd1 has joined #openstack-lbaas | 08:12 | |
| *** numans has joined #openstack-lbaas | 08:41 | |
| *** yboaron has joined #openstack-lbaas | 08:47 | |
| *** celebdor has quit IRC | 09:05 | |
| openstackgerrit | Kim Bao Long proposed openstack/octavia master: Update README by adding Mailing List and Wiki URL https://review.openstack.org/614158 | 09:51 |
|---|---|---|
| *** salmankhan has joined #openstack-lbaas | 10:01 | |
| *** celebdor has joined #openstack-lbaas | 10:01 | |
| openstackgerrit | Carlos Goncalves proposed openstack/octavia master: Redirect disk-image-builder logs, make verbose https://review.openstack.org/612622 | 10:39 |
| *** ramishra_ has quit IRC | 11:15 | |
| *** ramishra has joined #openstack-lbaas | 11:18 | |
| *** salmankhan has quit IRC | 11:26 | |
| *** yamamoto has quit IRC | 11:51 | |
| *** yamamoto has joined #openstack-lbaas | 11:53 | |
| *** yamamoto has quit IRC | 11:58 | |
| *** salmankhan has joined #openstack-lbaas | 12:02 | |
| *** yamamoto has joined #openstack-lbaas | 12:33 | |
| *** celebdor has quit IRC | 13:04 | |
| *** celebdor has joined #openstack-lbaas | 13:06 | |
| *** velizarx has joined #openstack-lbaas | 13:07 | |
| *** yamamoto has quit IRC | 13:12 | |
| *** yboaron has quit IRC | 14:04 | |
| *** yamamoto has joined #openstack-lbaas | 14:21 | |
| *** yamamoto has quit IRC | 14:26 | |
| *** pcaruana|elisa| has quit IRC | 14:33 | |
| *** fnaval has joined #openstack-lbaas | 14:40 | |
| *** pcaruana|elisa| has joined #openstack-lbaas | 14:45 | |
| openstackgerrit | Carlos Goncalves proposed openstack/octavia-tempest-plugin master: Add octavia-v2-dsvm-py3-scenario-fedora-latest job https://review.openstack.org/600381 | 14:45 |
| *** dolly has joined #openstack-lbaas | 14:46 | |
| dolly | rm_work, you there and have a few minutes? | 14:51 |
| johnsom | dolly He is on vacation for a while, so may not reply. Is there something I can help you with? | 14:54 |
| dolly | johnsom, oh! I see, well I was curious about his work on https://review.openstack.org/#/c/558962/ | 14:54 |
| dolly | I seem to hit a bug there when the health-manager recreates an amp | 14:55 |
| dolly | I talked about that with him, I was just curios if he was able to reproduce it | 14:56 |
| johnsom | dolly He is running that, but with a bunch of other patches too. His network is L3 and he doesn't use the standard active/standby, but moves ports. So, it's a bit of a different animal | 14:56 |
| johnsom | Ah, ok. Yeah, I think he is the only one running that, so you might need an answer from him. | 14:57 |
| dolly | johnsom, I see, no worries. | 14:57 |
| dolly | johnsom, do you know that the "cached_zone" field is in the amphora table ? | 14:59 |
| dolly | Cause, this is what I'm hitting http://paste.openstack.org/show/728729/ | 14:59 |
| *** yamamoto has joined #openstack-lbaas | 14:59 | |
| dolly | I've actually described quite thoroughly, and I'm not sure why the "creation of the amp-step" chooses the wrong AZ, even though the "filterer" in the step before, got the correct one. | 15:01 |
| dolly | It very weird | 15:01 |
| *** ianychoi_ is now known as ianychoi | 15:07 | |
| *** velizarx has quit IRC | 15:08 | |
| *** yamamoto has quit IRC | 15:20 | |
| *** yamamoto has joined #openstack-lbaas | 15:23 | |
| *** yamamoto has quit IRC | 15:28 | |
| *** pcaruana|elisa| has quit IRC | 15:35 | |
| *** tomtom001 has joined #openstack-lbaas | 15:40 | |
| tomtom001 | Hello, I'm creating load balancers in Queens and noticed that the Octavia Management network has to be in a shared state to operate correctly. Is there a reason why it can't be an non-shared network to operate correctly? | 15:41 |
| johnsom | tomtom001: It should not be a shared network | 15:43 |
| johnsom | Everything using that network should be under the octavia user/project | 15:43 |
| tomtom001 | when I make the network non-shared octavia containers are unable to contact the lb instances on 9443 to set them up. If I run telent <octavia mgmt ip> 9443 the containers are able to connect, but the octavia-worker cannot. | 15:44 |
| tomtom001 | hmmm.... ok let me check that | 15:45 |
| tomtom001 | ok, so if I log in as the octavia user, under project service, that's where the Octavia management network is specified. It seems to be correct from what I'm seeing | 15:47 |
| *** pcaruana|elisa| has joined #openstack-lbaas | 15:50 | |
| tomtom001 | johnsom: so octavia user's default project is service, is that ok? | 15:51 |
| johnsom | Should be ok. Check your service_auth settings, they should match | 15:52 |
| tomtom001 | johnsom: Octavia user is an admin under the service project members, is that what I should be looking for? | 15:54 |
| *** yamamoto has joined #openstack-lbaas | 15:57 | |
| tomtom001 | under service_auth in octavia.conf service is the project_name as well. That should be good | 15:57 |
| *** aojea_ has joined #openstack-lbaas | 15:57 | |
| *** pcaruana|elisa| has quit IRC | 16:00 | |
| *** ccamposr has quit IRC | 16:04 | |
| dolly | cgoncalves, you there ? | 16:10 |
| cgoncalves | dolly, I am | 16:10 |
| dolly | yo! long time no hear, I've got a question for you =) | 16:10 |
| cgoncalves | dolly, hit me. I'll do my best to answer | 16:11 |
| dolly | - > /usr/share/rhosp-director-images/octavia-amphora-13.0-20180905.1.x86_64.raw <- Whats the status on this image in the current release of OSP 13. I use the github/octavia/queens/stable-release, and when creating an amp we hit this issue http://paste.openstack.org/show/733653/ | 16:13 |
| dolly | But, using the image you provided me a long time ago, works good! | 16:13 |
| dolly | cgoncalves, did you run away ;) | 16:23 |
| cgoncalves | dolly, I was afk for a moment, sorry | 16:25 |
| dolly | no worries =) | 16:25 |
| cgoncalves | dolly, the OSP-provided amp image is based on latest RHEL cloud image at build time + octavia stable queens amphora bits | 16:26 |
| cgoncalves | dolly, I am not sure what the issue is from that paste. would you have the amp logs? | 16:27 |
| dolly | ok, do you remember the image you made me a while ago ? | 16:27 |
| dolly | I guess I can get the logs tomorrow, need to make sure the amp is not deleted | 16:28 |
| dolly | so need to update the config | 16:28 |
| cgoncalves | I did one? didn't I point you to the periodically built images instead? | 16:28 |
| dolly | and I'm on my way home | 16:28 |
| dolly | oh yes, sorry | 16:28 |
| dolly | yeah you did | 16:28 |
| dolly | but yes, that image works. the image provided from rhel/osp doesn't. | 16:28 |
| dolly | and I was just curios why | 16:29 |
| cgoncalves | dolly, does it happen all the time when you build an amp? | 16:30 |
| dolly | cgoncalves, yeps, everytime, same place. never happens with the other image | 16:30 |
| dolly | (but understand that we use the github/stable/queens-version of octavia, and not the one provided by rhel) | 16:31 |
| cgoncalves | ok, that is weird. I would really need to see the amp-agent log | 16:31 |
| cgoncalves | dolly, control plane services run queens upstream while amp from OSP, is that it? | 16:32 |
| dolly | yes | 16:32 |
| dolly | exactly | 16:32 |
| cgoncalves | ok, got it | 16:33 |
| cgoncalves | well, downstream we do not support that obviously ;) | 16:33 |
| dolly | ofc :) | 16:33 |
| cgoncalves | but I could have a look once you share some logs | 16:33 |
| dolly | I'm just curious in why it crashes | 16:33 |
| dolly | with "internal server erro" | 16:33 |
| dolly | And I thought since the amp-image was updated in OSP just a month ago, I figured it was "new enough" to work with the upstream version of octavia. | 16:34 |
| dolly | But guess I was wrong ;) | 16:34 |
| cgoncalves | dolly, not sure in which 13.0.z version you're on | 16:35 |
| cgoncalves | but 13z2 doesn't ship with latest queens release | 16:35 |
| dolly | No, thats why we build our own =) | 16:36 |
| cgoncalves | checked, 13z2 ships octavia 2.0.1 | 16:36 |
| dolly | Where do you find info about which z-release you are running ? | 16:36 |
| cgoncalves | dolly, yeah so the amp is also based on 2.0.1 | 16:36 |
| dolly | we are running the "latest" available | 16:36 |
| dolly | got it | 16:36 |
| dolly | Is there no way of determining which openstack 13.z version you are running? (lets say you dont know which one you have) | 16:39 |
| cgoncalves | good question, heh. looking | 16:45 |
| dolly | no worries =) we have just updated everything to the latest available, i'm just a bit confused about these .z releases | 16:45 |
| cgoncalves | dolly, https://bugzilla.redhat.com/show_bug.cgi?id=1533565 | 16:50 |
| openstack | bugzilla.redhat.com bug 1533565 in rhosp-release "Please include information about minor version (z stream) in rhosp-release" [Unspecified,Closed: notabug] - Assigned to mburns | 16:50 |
| cgoncalves | tl;dr: no way | 16:50 |
| *** aojea_ has quit IRC | 16:53 | |
| colin- | if i provided octavia with a network value for this parameter https://docs.openstack.org/octavia/ocata/main/configref.html#controller_worker.amp_boot_network_list whose definition contained an IPv6 subnet would it support that? | 16:56 |
| colin- | yikes i reallly linked the ocata doc, my bad | 16:57 |
| cgoncalves | dolly, ok, so, I'm hearing that it will be possible soon ;) | 16:57 |
| johnsom | colin- Yes, someone has done this in the past. There are two comments I will make: 1. we don't yet test this in the gates, so it *might* be broken (it's on my to-do list). 2. If you want to use link-local addresses there is an open patch with some changes that need to be made. | 16:58 |
| cgoncalves | dolly, https://bugzilla.redhat.com/show_bug.cgi?id=1640291 | 17:00 |
| openstack | bugzilla.redhat.com bug 1640291 in rhosp-release "Add a maintenance release version to /etc/rhosp-release" [Low,On_qa] - Assigned to jjoyce | 17:00 |
| colin- | oh nice, i'll give it a whirl | 17:01 |
| colin- | thanks johnsom | 17:01 |
| johnsom | colin- I have recently been working on getting our IPv6 house back in order. Patch reviews would be welcome. I have gates for the VIP and members now, the next step is for the lb-mgmt-net just to make sure we don't get bit-rot there. | 17:03 |
| *** velizarx has joined #openstack-lbaas | 17:14 | |
| *** velizarx has quit IRC | 17:15 | |
| *** aojea_ has joined #openstack-lbaas | 17:19 | |
| *** yamamoto has quit IRC | 17:24 | |
| colin- | yeah, link-local would be useful. i'll take a look at the open changes for the patch. will also take a stab at some reviews | 17:26 |
| *** aojea_ has quit IRC | 17:31 | |
| *** aojea_ has joined #openstack-lbaas | 17:32 | |
| *** aojea_ has quit IRC | 17:39 | |
| *** aojea_ has joined #openstack-lbaas | 17:40 | |
| *** aojea_ has quit IRC | 17:44 | |
| *** salmankhan has quit IRC | 17:55 | |
| *** yamamoto has joined #openstack-lbaas | 18:03 | |
| colin- | unrelated, is there a section of the config that would disable the creation of LBs outside of RFC1918 space? | 18:05 |
| johnsom | colin- Like block the creation of LBs with VIPs outside 1918? | 18:07 |
| johnsom | Right now, the only restrictions we have on the user specified networks/subnets is if they have access to them, and the valid VIP networks whitelist and the reserved member addresses. https://docs.openstack.org/octavia/latest/configuration/configref.html#networking.valid_vip_networks | 18:10 |
| *** yamamoto has quit IRC | 18:12 | |
| colin- | yes that's what i had in mind, that makes sense thanks | 18:24 |
| colin- | johnsom: does this describe the link-local changes you mentioned above? https://review.openstack.org/#/c/391204/ | 18:47 |
| johnsom | Yes, that is the one. I haven’t looked at it in a while | 18:48 |
| *** abaindur has joined #openstack-lbaas | 19:01 | |
| *** abaindur has quit IRC | 19:01 | |
| *** abaindur has joined #openstack-lbaas | 19:01 | |
| *** aojea_ has joined #openstack-lbaas | 19:06 | |
| *** aojea_ has quit IRC | 19:26 | |
| *** aojea_ has joined #openstack-lbaas | 19:27 | |
| *** aojea_ has quit IRC | 19:30 | |
| *** aojea_ has joined #openstack-lbaas | 19:31 | |
| *** aojea_ has quit IRC | 19:52 | |
| *** pcaruana|elisa| has joined #openstack-lbaas | 20:12 | |
| *** pcaruana|elisa| has quit IRC | 20:32 | |
| openstackgerrit | Michael Johnson proposed openstack/octavia master: Add framework for octavia-status upgrade check https://review.openstack.org/612883 | 20:43 |
| *** aojea_ has joined #openstack-lbaas | 20:57 | |
| openstackgerrit | Swaminathan Vasudevan proposed openstack/octavia master: Update osutil support for SUSE distro https://review.openstack.org/541811 | 21:20 |
| *** salmankhan has joined #openstack-lbaas | 21:20 | |
| *** yamamoto has joined #openstack-lbaas | 22:10 | |
| abaindur | johnsom: Hey, I might've already asked this before, but a question about the LB mgmt network. It seems octavia can only talk to the amphora via its fixed IP on the lb mgmt network. Is there a way to use floating IPs instead? | 22:11 |
| abaindur | It seems the requirement is that the lb mgmt network must only be a provider network, if it cant talk via floating ip/external network. | 22:12 |
| johnsom | abaindur No, we currently do not have support for adding floating IPs to the lb-mgmt-net addresses. You can specify any network, including public networks if you really want, but we don't have code to add floats to those addresses. | 22:13 |
| johnsom | No, it doesn't have to be a provider network. It's simply a neutron tenant network | 22:13 |
| abaindur | How does octavia talk to an isolated tenant network then? the octavia-worker process isnt plumbed into OVS or attached to a neutron port - its a process running directly on the host | 22:14 |
| abaindur | We are out of VLANs to allocate a provider network that exists in a physical router. Therefore we can create an isolated VXLAN based tenant network. VMs have external access, but only via floating IP | 22:14 |
| *** yamamoto has quit IRC | 22:15 | |
| johnsom | abaindur There are many ways to do this. One is to add a port to OVS like we do in devstack. One is to route the traffic. | 22:15 |
| johnsom | Yeah, or piggy back it on one of your existing networks. It doesn't do anything fancy/special, it is simply IP traffic with TCP and UDP in them. | 22:16 |
| abaindur | I'm not familiar with behavior of former (devstack). route the traffic... where? in our physical router? This would make it a "provider" network, then no? But the problem is, the tenant network is VXLAN based. We dont have hardware based VTEPS or vxlan gateways | 22:17 |
| abaindur | so lets say our lb_mgmt network is a VXLAN based tenant network, on 192.168.1.0/24 | 22:17 |
| abaindur | Octavia-worker resides on a host | 22:19 |
| abaindur | if our tenant network was VLAN based, we could tag it in our switches, and add it to our router. SO our host's networking can communicate to 192.168.1.0/24 | 22:19 |
| abaindur | But this implies its a provider network, and that we have available vlans | 22:20 |
| johnsom | Can your host access your VXLAN underlay? | 22:23 |
| abaindur | Suppose our host has connectivity via 10.4.0.0/16, on vlan 4. If I make my LB mgmt network 10.8.0.0/16, on say vlan 8, I can add vlan 8 to our switches and add a route to 10.8/16 on physical router. I'm not sure what i'd need to do to achieve this, if 10.8.0.0/16 was VXLAN based | 22:23 |
| abaindur | no... | 22:23 |
| abaindur | We dont do VXLAN on any of our physical switches | 22:24 |
| *** aojea_ has quit IRC | 22:24 | |
| abaindur | the encap/decap is all done by OVS on the br-tun VTEPs | 22:24 |
| johnsom | I was just thinking if you could add a VXLAN endpoint on your controller host (linux software based) and add it to the neutron vxlan tenant network. But it sounds like you can't do that..... | 22:25 |
| johnsom | It is super hard to come up with the right decision for your environment when I don't really know much about it. However, I can describe how the lb-mgmt-net works and maybe that will spark an idea? | 22:27 |
| abaindur | yea.... hence why i wa hoping there was a way to do this using external networks/floating IPs | 22:27 |
| abaindur | sure | 22:27 |
| johnsom | Well, you can use an external network for your lb-mgmt-net. There is no restriction there. Just not floating IPs (NAT) | 22:27 |
| abaindur | I dont believe you can attach a VM to an external network | 22:28 |
| abaindur | A Provider network is really the same as an external network. Only difference is external network does NAT and you cannot attach a VM directly to it. A provider network can attach to a VM, but not do NAT | 22:28 |
| johnsom | So, fundamentally the lb-mgmt-net is a neutron network, type doesn't matter to octavia. It just needs to be a network with a subnet that the octavia user can attach to the service VMs (amphora). | 22:29 |
| johnsom | The tricky part is how to get your controller processes access to those addresses. (CW, HM, HK processes. API does not need access) | 22:29 |
| abaindur | For reference, in neutron lbaas using AVI, uses a similar LB mgmt network that it attaches to each service engine (equivalent of amphora) | 22:30 |
| abaindur | the difference is, the AVI controller is a VM, deployed in the same openstack cloud | 22:30 |
| johnsom | One option is to pop it off on your network nodes by adding a port to OVS. This can also be done if you put neutron on your controller hosts. | 22:31 |
| abaindur | so the AVI controller is attached to the same fixed IP/neutron network | 22:31 |
| abaindur | hence, avi can talk directly over L2 to an isolated service engine | 22:31 |
| johnsom | One option is to use a neutron router to make a routable path from the tenant network to another network in your environment that the controllers are on. | 22:31 |
| abaindur | yep and in octavia case, its a process but not a VM. so it attaches to host networking, not OVS/neutron | 22:31 |
| abaindur | I guess if we packaged octavia-worker and health-manager inside a VM image, and booted it up as a "Octavia controller" VM in same environment, it would work | 22:32 |
| abaindur | similar to AVI | 22:32 |
| johnsom | It needs access to the rabbit and database for your cloud. Probably exactly like avi. | 22:33 |
| johnsom | The controllers also need access to the other service APIs, keystone, neutron, nova, etc. | 22:33 |
| abaindur | that can be achieved by assigning a floating IP to the VM | 22:33 |
| johnsom | Frankly most of us run them in containers of some sort, so running in a VM should not be a problem. | 22:34 |
| johnsom | Ugly solutions that would work if you are really stuck is to tunnel the networks. GRE/IPSec, etc. There isn't that much traffic between the amps and controllers. The highest use is the heartbeats back. | 22:35 |
| abaindur | "One option is to use a neutron router to make a routable path from the tenant network to another network in your environment that the controllers are on." | 22:39 |
| abaindur | ok let me try to work that out... | 22:39 |
| abaindur | Back to my example, we attach our VXLAN based 10.8.0.0/16 network, to a neutron router... suppose here we have an external network on 10.4.0.0/16 vlan 4 (same VLAN and subnet as our host's networking) | 22:41 |
| abaindur | Now the amphora has octavia's IP as part of its controller_ip_port_list config... so it will try to contact 10.4. this theoretically might work? | 22:42 |
| abaindur | well this would go out via SNAT | 22:43 |
| *** salmankhan has quit IRC | 22:43 | |
| johnsom | Both sides connect via IP, so as long as there is a route in both directions it works fine. You would not want to NAT though. | 22:44 |
| abaindur | ok, guess it would not be ablke to be an external network | 22:45 |
| abaindur | we'd have to add 10.4 vlan 4 as a provider net, and attach to same neutron router | 22:45 |
| abaindur | ... and I suppose in our physical router, we would have to add a route saying 10.8.0.0/16 ---> nexthop = the 10.4 IP of our neutron router? | 22:47 |
| abaindur | I guess we are back to same problem then though. requires us to add this network in neutron, VLAN based. we have just made it a point to point link between neutron router and physical router, rather than deploying amphora directly on it | 22:56 |
| johnsom | I think I am following. Here is what I am saying: | 22:59 |
| johnsom | 1. create the lb-mgmt-net in neutron, it can whatever type you need. Create a subnet on that network, let's say 10.5.0.0/16. | 23:00 |
| johnsom | 2. Add that network will be attached to a neutron router, either by default gateway or host route. | 23:01 |
| johnsom | At this point you can boot an amphora, it will get a 10.5.0.10 address, and can reach the router address (gateway, etc.) | 23:01 |
| johnsom | 3. Then on the controller hosts, let's say they are connected to 192.168.0.0/16, and you CW host has 192.168.0.20 | 23:02 |
| johnsom | 4. setup routing where that the 192.160.0.20 can reach a router that has a path to the neutron router. This could be a physical router, etc. It needs to know how to reach 10.5.0.0/16 (could be multiple hops) the neutron router needs to know how to reach 192.168.0.0/16 (again, can be multiple hops). | 23:04 |
| johnsom | 5. boot network config in octavia.conf points to the 10.5.0.0/16 subnet/network, controller_port_ip_list has the 192.168.0.20, etc. addresses. | 23:05 |
| johnsom | That configuration works. | 23:06 |
| abaindur | yeah, I think the problem is just with #4, specifically, "It needs to know how to reach 10.5.0.0/16 (could be multiple hops) the neutron router needs to know how to reach 192.168.0.0/16 (again, can be multiple hops)." | 23:08 |
| abaindur | It can't go out the external network of the router, due to NAT | 23:08 |
| abaindur | So the neutron router can't just attach 2 subnets - our external network and 10.5.0.0/16 | 23:09 |
| *** salmankhan has joined #openstack-lbaas | 23:09 | |
| johnsom | Well, it has to be so that it can provide floating IPs right? | 23:09 |
| abaindur | will need to attach another network to this router, in order to route the traffic to 196.168 out of the router | 23:10 |
| johnsom | That is how the NAT works for floating IPs | 23:10 |
| abaindur | yeah, but we are not attaching floating IPs to the amphora | 23:10 |
| abaindur | So it needs to leave the router without being NAT'd, still retaining the 10.5.0.10 source IP | 23:11 |
| johnsom | Yeah, which neutron can do. | 23:12 |
| abaindur | But because we dont have any vxlan gateways of our own, it would have to leave via a VLAN based network | 23:12 |
| abaindur | That is mainly the problem ^^ | 23:12 |
| abaindur | burning up a VLAN, when they might be limited or not readily available | 23:13 |
| johnsom | I'm not sure the L2 matters here | 23:13 |
| abaindur | How else would packet leave the neutron router then? | 23:14 |
| johnsom | Your VXLAN tenant lb-mgmt-net terminates at the neutron router. What is L2 for the otherside could be anything | 23:14 |
| abaindur | ext-network <---> (neutron router) <---> lb-mgmt net | 23:14 |
| abaindur | it seems like we'd need a 3rd subnet attachment there | 23:14 |
| abaindur | because we always NAT on the external network for the router | 23:15 |
| johnsom | Not necessarily. | 23:15 |
| abaindur | wouldn't everything get SNAT'd outbound? | 23:15 |
| johnsom | It has to have an address on the ext-net that you could route to | 23:15 |
| johnsom | Not if the routing table tells it not to SNAT it, but to forward it | 23:16 |
| *** fnaval has quit IRC | 23:16 | |
| abaindur | hmm ok. I assumed the ip rule in qrouter would redirect packet to snat namespace(because the amph does not have a floating IP), and there all outbound packets would get SNAT'd | 23:17 |
| abaindur | ip netns exec qrouter-72471ae2-5960-464b-8be2-dfcb035383c7 ip rule | 23:19 |
| abaindur | 46861:from 172.90.0.16 lookup 16 | 23:19 |
| abaindur | 57482:from 172.90.0.7 lookup 16 | 23:19 |
| abaindur | 2891579393:from 172.90.0.1/16 lookup 2891579393 | 23:19 |
| abaindur | 3232366593:from 192.170.0.1/16 lookup 3232366593 | 23:19 |
| abaindur | That's usually how the neutron qrouter's are implemented. If theres a floating IP, theres an exact match to source fixed IP. Otherwise everything hits the subnet. Table 2891579393 re-directs packet to SNAT, and I thought just indiscriminately performs SNAT on the packet | 23:20 |
| abaindur | I will have to try and confirm behavior | 23:21 |
| *** yamamoto has joined #openstack-lbaas | 23:23 | |
| abaindur | johnsom: actually nvm. I realized this table and the ip rules are only lookedup if no route exists in the router's main table. It usually is the case as the router does not have a default route | 23:25 |
| abaindur | Maybe adding a static route over the ext-network would allow us to bypass the SNAT rule | 23:26 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!