Re: [openstack-dev] DVR and FWaaS integration
Yi, since am from India, the FwaaS at 11PM Wed is late for me. Is it possible to have a meeting right after the l3 subteam meeting coming Thursday. This evaluates to 10AM PST Thursday. Swami, please let me know your availability as well. -- Thanks, Vivek From: Yi Sun [mailto:beyo...@gmail.com] Sent: Tuesday, July 08, 2014 9:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] DVR and FWaaS integration Vivek, I will try to join the DVR meeting. Since it conflicts with one of my other meeting (from my real job), I may join late or may not be able to join at all. If I missed it, please see if you can join FWaaS meeting at Wed 11:30AM PST on openstack-meeting-3. Otherwise, a separated meeting is still preferred Thanks Yi On 7/4/14, 12:23 AM, Narasimhan, Vivekanandan wrote: Hi Yi, Swami will be available from this week. Will it be possible for you to join the regular DVR Meeting (Wed 8AM PST) next week and we can slot that to discuss this. I see that FwaaS is of much value for E/W traffic (which has challenges), but for me it looks easier to implement the same in N/S with the current DVR architecture, but there might be less takers on that. -- Thanks, Vivek From: Yi Sun [mailto:beyo...@gmail.com] Sent: Thursday, July 03, 2014 11:50 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] DVR and FWaaS integration The NS FW will be on a centralized node for sure. For the DVR + FWaaS solution is really for EW traffic. If you are interested on the topic, please propose your preferred meeting time and join the meeting so that we can discuss about it. Yi On 7/2/14, 7:05 PM, joehuang wrote: Hello, It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into two parts: one part is for east-west FWaaS, this part could be done on DVR side, and make it become distributed manner. The other part is for north-south part, this part could be done on Network Node side, that means work in central manner. After the split, north-south FWaaS could be implemented by software or hardware, meanwhile, east-west FWaaS is better to implemented by software with its distribution nature. Chaoyi Huang ( Joe Huang ) OpenStack Solution Architect IT Product Line Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: joehu...@huawei.commailto:joehu...@huawei.com Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, P.R.China 发件人: Yi Sun [mailto:beyo...@gmail.com] 发送时间: 2014年7月3日 4:42 收件人: OpenStack Development Mailing List (not for usage questions) 抄送: Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron) 主题: Re: [openstack-dev] DVR and FWaaS integration All, After talk to Carl and FWaaS team , Both sides suggested to call a meeting to discuss about this topic in deeper detail. I heard that Swami is traveling this week. So I guess the earliest time we can have a meeting is sometime next week. I will be out of town on monday, so any day after Monday should work for me. We can do either IRC, google hang out, GMT or even a face to face. For anyone interested, please propose your preferred time. Thanks Yi On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.commailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can
Re: [openstack-dev] DVR and FWaaS integration
To level set, the FWaaS model was (intentionally) made agnostic of whether the firewall was being subject to the E-W or N-S traffic (or both). The possibility of having to use a different strategy/implementation to handle the two sets of traffic differently, is an artifact of the backend implementation (and DVR in this case). I am not sure that the FWaaS user needs to be aware of this distinction. Admittedly, this makes the implementation of FWaaS harder on the DVR reference implementation. This incompatibility issue between FWaaS and DVR was raised several times in the past, but unfortunately we don't have a clean technical solution yet. I am suspecting that this issue will manifest for any service (NAT/VPNaaS?) that was leveraging the connection tracking feature of iptables in the past. The FWaaS team has also been trying to devise a solution for this (this is a standing item on our weekly IRC meetings), but we would need more help from the DVR team on this (I believe that was the original plan in talking to Swami/Vivek/team). Would it be possible for the relevant folks from the DVR team to attend the FWaaS meeting on Wednesday [1] to facilitate a dedicated discussion on this topic? That way it might be possible to get more input from the FWaaS team on this. Thanks, ~Sumit. [1] https://wiki.openstack.org/wiki/Meetings/FWaaS On Fri, Jul 4, 2014 at 12:23 AM, Narasimhan, Vivekanandan vivekanandan.narasim...@hp.com wrote: Hi Yi, Swami will be available from this week. Will it be possible for you to join the regular DVR Meeting (Wed 8AM PST) next week and we can slot that to discuss this. I see that FwaaS is of much value for E/W traffic (which has challenges), but for me it looks easier to implement the same in N/S with the current DVR architecture, but there might be less takers on that. -- Thanks, Vivek From: Yi Sun [mailto:beyo...@gmail.com] Sent: Thursday, July 03, 2014 11:50 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] DVR and FWaaS integration The NS FW will be on a centralized node for sure. For the DVR + FWaaS solution is really for EW traffic. If you are interested on the topic, please propose your preferred meeting time and join the meeting so that we can discuss about it. Yi On 7/2/14, 7:05 PM, joehuang wrote: Hello, It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into two parts: one part is for east-west FWaaS, this part could be done on DVR side, and make it become distributed manner. The other part is for north-south part, this part could be done on Network Node side, that means work in central manner. After the split, north-south FWaaS could be implemented by software or hardware, meanwhile, east-west FWaaS is better to implemented by software with its distribution nature. Chaoyi Huang ( Joe Huang ) OpenStack Solution Architect IT Product Line Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: joehu...@huawei.com Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, P.R.China 发件人: Yi Sun [mailto:beyo...@gmail.com] 发送时间: 2014年7月3日 4:42 收件人: OpenStack Development Mailing List (not for usage questions) 抄送: Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron) 主题: Re: [openstack-dev] DVR and FWaaS integration All, After talk to Carl and FWaaS team , Both sides suggested to call a meeting to discuss about this topic in deeper detail. I heard that Swami is traveling this week. So I guess the earliest time we can have a meeting is sometime next week. I will be out of town on monday, so any day after Monday should work for me. We can do either IRC, google hang out, GMT or even a face to face. For anyone interested, please propose your preferred time. Thanks Yi On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin c...@ecbaldwin.net wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think
Re: [openstack-dev] DVR and FWaaS integration
Vivek, I will try to join the DVR meeting. Since it conflicts with one of my other meeting (from my real job), I may join late or may not be able to join at all. If I missed it, please see if you can join FWaaS meeting at Wed 11:30AM PST on openstack-meeting-3. Otherwise, a separated meeting is still preferred Thanks Yi On 7/4/14, 12:23 AM, Narasimhan, Vivekanandan wrote: Hi Yi, Swami will be available from this week. Will it be possible for you to join the regular DVR Meeting (Wed 8AM PST) next week and we can slot that to discuss this. I see that FwaaS is of much value for E/W traffic (which has challenges), but for me it looks easier to implement the same in N/S with the current DVR architecture, but there might be less takers on that. -- Thanks, Vivek *From:*Yi Sun [mailto:beyo...@gmail.com] *Sent:* Thursday, July 03, 2014 11:50 AM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] DVR and FWaaS integration The NS FW will be on a centralized node for sure. For the DVR + FWaaS solution is really for EW traffic. If you are interested on the topic, please propose your preferred meeting time and join the meeting so that we can discuss about it. Yi On 7/2/14, 7:05 PM, joehuang wrote: Hello, It's hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into two parts: one part is for east-west FWaaS, this part could be done on DVR side, and make it become distributed manner. The other part is for north-south part, this part could be done on Network Node side, that means work in central manner. After the split, north-south FWaaS could be implemented by software or hardware, meanwhile, east-west FWaaS is better to implemented by software with its distribution nature. Chaoyi Huang ( Joe Huang ) OpenStack Solution Architect IT Product Line Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: joehu...@huawei.com mailto:joehu...@huawei.com Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, P.R.China *???**:*Yi Sun [mailto:beyo...@gmail.com] *:* 2014?7?3? 4:42 *???:* OpenStack Development Mailing List (not for usage questions) *??:* Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron) *??:* Re: [openstack-dev] DVR and FWaaS integration All, After talk to Carl and FWaaS team , Both sides suggested to call a meeting to discuss about this topic in deeper detail. I heard that Swami is traveling this week. So I guess the earliest time we can have a meeting is sometime next week. I will be out of town on monday, so any day after Monday should work for me. We can do either IRC, google hang out, GMT or even a face to face. For anyone interested, please propose your preferred time. Thanks Yi On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin c...@ecbaldwin.net mailto:c...@ecbaldwin.net wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.com mailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. I'm not sure what this solution would look like. I'll have to get the details from Vivek. It seems like this would effectively centralize the traffic that we worked so hard to decentralize. It did cause me to wonder about something: would it be possible to reign the symmetry to the traffic by directing any response traffic back
Re: [openstack-dev] DVR and FWaaS integration
Hi Yi, Swami will be available from this week. Will it be possible for you to join the regular DVR Meeting (Wed 8AM PST) next week and we can slot that to discuss this. I see that FwaaS is of much value for E/W traffic (which has challenges), but for me it looks easier to implement the same in N/S with the current DVR architecture, but there might be less takers on that. -- Thanks, Vivek From: Yi Sun [mailto:beyo...@gmail.com] Sent: Thursday, July 03, 2014 11:50 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] DVR and FWaaS integration The NS FW will be on a centralized node for sure. For the DVR + FWaaS solution is really for EW traffic. If you are interested on the topic, please propose your preferred meeting time and join the meeting so that we can discuss about it. Yi On 7/2/14, 7:05 PM, joehuang wrote: Hello, It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into two parts: one part is for east-west FWaaS, this part could be done on DVR side, and make it become distributed manner. The other part is for north-south part, this part could be done on Network Node side, that means work in central manner. After the split, north-south FWaaS could be implemented by software or hardware, meanwhile, east-west FWaaS is better to implemented by software with its distribution nature. Chaoyi Huang ( Joe Huang ) OpenStack Solution Architect IT Product Line Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: joehu...@huawei.commailto:joehu...@huawei.com Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, P.R.China 发件人: Yi Sun [mailto:beyo...@gmail.com] 发送时间: 2014年7月3日 4:42 收件人: OpenStack Development Mailing List (not for usage questions) 抄送: Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron) 主题: Re: [openstack-dev] DVR and FWaaS integration All, After talk to Carl and FWaaS team , Both sides suggested to call a meeting to discuss about this topic in deeper detail. I heard that Swami is traveling this week. So I guess the earliest time we can have a meeting is sometime next week. I will be out of town on monday, so any day after Monday should work for me. We can do either IRC, google hang out, GMT or even a face to face. For anyone interested, please propose your preferred time. Thanks Yi On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.commailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. I'm not sure what this solution would look like. I'll have to get the details from Vivek. It seems like this would effectively centralize the traffic that we worked so hard to decentralize. It did cause me to wonder about something: would it be possible to reign the symmetry to the traffic by directing any response traffic back to the DVR component which handled the request traffic? I guess this would require running conntrack on the target side to track and identify return traffic. I'm not sure how this would be inserted into the data path yet. This is a half-baked idea here. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues
Re: [openstack-dev] DVR and FWaaS integration
The NS FW will be on a centralized node for sure. For the DVR + FWaaS solution is really for EW traffic. If you are interested on the topic, please propose your preferred meeting time and join the meeting so that we can discuss about it. Yi On 7/2/14, 7:05 PM, joehuang wrote: Hello, It's hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into two parts: one part is for east-west FWaaS, this part could be done on DVR side, and make it become distributed manner. The other part is for north-south part, this part could be done on Network Node side, that means work in central manner. After the split, north-south FWaaS could be implemented by software or hardware, meanwhile, east-west FWaaS is better to implemented by software with its distribution nature. Chaoyi Huang ( Joe Huang ) OpenStack Solution Architect IT Product Line Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: joehu...@huawei.com Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, P.R.China *???:*Yi Sun [mailto:beyo...@gmail.com] *:*2014?7?3?4:42 *???:*OpenStack Development Mailing List (not for usage questions) *??:*Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron) *??:*Re: [openstack-dev] DVR and FWaaS integration All, After talk to Carl and FWaaS team , Both sides suggested to call a meeting to discuss about this topic in deeper detail. I heard that Swami is traveling this week. So I guess the earliest time we can have a meeting is sometime next week. I will be out of town on monday, so any day after Monday should work for me. We can do either IRC, google hang out, GMT or even a face to face. For anyone interested, please propose your preferred time. Thanks Yi On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin c...@ecbaldwin.net mailto:c...@ecbaldwin.net wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.com mailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. I'm not sure what this solution would look like. I'll have to get the details from Vivek. It seems like this would effectively centralize the traffic that we worked so hard to decentralize. It did cause me to wonder about something: would it be possible to reign the symmetry to the traffic by directing any response traffic back to the DVR component which handled the request traffic? I guess this would require running conntrack on the target side to track and identify return traffic. I'm not sure how this would be inserted into the data path yet. This is a half-baked idea here. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I'm not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). I agree that splitting the firewall from routing presents some problems that may be difficult to overcome. I don't know how it would be done while maintaining
Re: [openstack-dev] DVR and FWaaS integration
Carl, For the overlap IP, I was thinking about whether we could have a case where two VMs have the same subnet but belongs to different network. So if we create policy base on subnet, how will it work. Yi On 6/29/14, 12:43 PM, Carl Baldwin wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.com mailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. I'm not sure what this solution would look like. I'll have to get the details from Vivek. It seems like this would effectively centralize the traffic that we worked so hard to decentralize. It did cause me to wonder about something: would it be possible to reign the symmetry to the traffic by directing any response traffic back to the DVR component which handled the request traffic? I guess this would require running conntrack on the target side to track and identify return traffic. I'm not sure how this would be inserted into the data path yet. This is a half-baked idea here. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I'm not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). I agree that splitting the firewall from routing presents some problems that may be difficult to overcome. I don't know how it would be done while maintaining the benefits of DVR. Another half-baked idea: could multi-primary state replication be used between DVR components to enable firewall operation? Maybe work on the HA router blueprint -- which is long overdue to be merged Btw -- could be leveraged. The number of DVR pieces could easily far exceed that of active firewall components normally used in such a configuration so there could be a major scaling problem. I'm really just thinking out loud here. Maybe you (or others) have other ideas? Another thing that I may have to get detail is that how we handle the overlap subnet, it seems that the new namespaces are required. Can you elaborate here? Carl --- end of forwarding YI ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] DVR and FWaaS integration
All, After talk to Carl and FWaaS team , Both sides suggested to call a meeting to discuss about this topic in deeper detail. I heard that Swami is traveling this week. So I guess the earliest time we can have a meeting is sometime next week. I will be out of town on monday, so any day after Monday should work for me. We can do either IRC, google hang out, GMT or even a face to face. For anyone interested, please propose your preferred time. Thanks Yi On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin c...@ecbaldwin.net wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. I'm not sure what this solution would look like. I'll have to get the details from Vivek. It seems like this would effectively centralize the traffic that we worked so hard to decentralize. It did cause me to wonder about something: would it be possible to reign the symmetry to the traffic by directing any response traffic back to the DVR component which handled the request traffic? I guess this would require running conntrack on the target side to track and identify return traffic. I'm not sure how this would be inserted into the data path yet. This is a half-baked idea here. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I’m not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). I agree that splitting the firewall from routing presents some problems that may be difficult to overcome. I don't know how it would be done while maintaining the benefits of DVR. Another half-baked idea: could multi-primary state replication be used between DVR components to enable firewall operation? Maybe work on the HA router blueprint -- which is long overdue to be merged Btw -- could be leveraged. The number of DVR pieces could easily far exceed that of active firewall components normally used in such a configuration so there could be a major scaling problem. I'm really just thinking out loud here. Maybe you (or others) have other ideas? Another thing that I may have to get detail is that how we handle the overlap subnet, it seems that the new namespaces are required. Can you elaborate here? Carl --- end of forwarding YI ___ OpenStack-dev mailing list 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 -- Android-x86 http://www.android-x86.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] DVR and FWaaS integration
Hello, It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into two parts: one part is for east-west FWaaS, this part could be done on DVR side, and make it become distributed manner. The other part is for north-south part, this part could be done on Network Node side, that means work in central manner. After the split, north-south FWaaS could be implemented by software or hardware, meanwhile, east-west FWaaS is better to implemented by software with its distribution nature. Chaoyi Huang ( Joe Huang ) OpenStack Solution Architect IT Product Line Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: joehu...@huawei.com Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, P.R.China 发件人: Yi Sun [mailto:beyo...@gmail.com] 发送时间: 2014年7月3日 4:42 收件人: OpenStack Development Mailing List (not for usage questions) 抄送: Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron) 主题: Re: [openstack-dev] DVR and FWaaS integration All, After talk to Carl and FWaaS team , Both sides suggested to call a meeting to discuss about this topic in deeper detail. I heard that Swami is traveling this week. So I guess the earliest time we can have a meeting is sometime next week. I will be out of town on monday, so any day after Monday should work for me. We can do either IRC, google hang out, GMT or even a face to face. For anyone interested, please propose your preferred time. Thanks Yi On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.commailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. I'm not sure what this solution would look like. I'll have to get the details from Vivek. It seems like this would effectively centralize the traffic that we worked so hard to decentralize. It did cause me to wonder about something: would it be possible to reign the symmetry to the traffic by directing any response traffic back to the DVR component which handled the request traffic? I guess this would require running conntrack on the target side to track and identify return traffic. I'm not sure how this would be inserted into the data path yet. This is a half-baked idea here. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I’m not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). I agree that splitting the firewall from routing presents some problems that may be difficult to overcome. I don't know how it would be done while maintaining the benefits of DVR. Another half-baked idea: could multi-primary state replication be used between DVR components to enable firewall operation? Maybe work on the HA router blueprint -- which is long overdue to be merged Btw -- could be leveraged. The number of DVR pieces could
Re: [openstack-dev] DVR and FWaaS integration
From: Carl Baldwin [c...@ecbaldwin.net] Sent: Monday, June 30, 2014 3:43 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] DVR and FWaaS integration On Mon, Jun 30, 2014 at 3:43 AM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote: In line... On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.commailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. I'm not sure what this solution would look like. I'll have to get the details from Vivek. It seems like this would effectively centralize the traffic that we worked so hard to decentralize. It did cause me to wonder about something: would it be possible to reign the symmetry to the traffic by directing any response traffic back to the DVR component which handled the request traffic? I guess this would require running conntrack on the target side to track and identify return traffic. I'm not sure how this would be inserted into the data path yet. This is a half-baked idea here. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I’m not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). I agree that splitting the firewall from routing presents some problems that may be difficult to overcome. I don't know how it would be done while maintaining the benefits of DVR. Another half-baked idea: could multi-primary state replication be used between DVR components to enable firewall operation? Maybe work on the HA router blueprint -- which is long overdue to be merged Btw -- could be leveraged. The number of DVR pieces could easily far exceed that of active firewall components normally used in such a configuration so there could be a major scaling problem. I'm really just thinking out loud here. Maybe you (or others) have other ideas? I think ovs based firewall may resolve the conflict between distributed and stateful. Redirect response traffic from ovs to iptable will bring a lot of challenge, such as how to restore source mac when traffic return to br-int from iptable. In the future, security group and fwaas should be merged, present to user a unified firewall API. --- end of forwarding YI ___ 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] DVR and FWaaS integration
The east/west case is the only case with this asymmetric routing problem being discussed. However, the north/south case might still be interesting from a FWaaS perspective. The fact that the router is distributed in pieces may affect it depending on the firewall implementation. Carl On Jun 28, 2014 10:27 PM, Richard Woo richardwoo2...@gmail.com wrote: Regarding of user case of this feature, are you referring E-W traffic or N-S traffic? On Wed, Jun 25, 2014 at 4:00 PM, Yi Sun beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I’m not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). Another thing that I may have to get detail is that how we handle the overlap subnet, it seems that the new namespaces are required. --- end of forwarding YI ___ OpenStack-dev mailing list 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] DVR and FWaaS integration
From real solution scenario, we usually have to integrate hardware to provide tenant north-south traffic. So the DVR should work not only for distributed FWaaS, but also for central FWaaS/SNAT/FIP for north-south traffic. Best Regards Chaoyi Huang ( Joe Huang ) 发件人: Richard Woo [mailto:richardwoo2...@gmail.com] 发送时间: 2014年6月29日 12:23 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] DVR and FWaaS integration Regarding of user case of this feature, are you referring E-W traffic or N-S traffic? On Wed, Jun 25, 2014 at 4:00 PM, Yi Sun beyo...@gmail.commailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I’m not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). Another thing that I may have to get detail is that how we handle the overlap subnet, it seems that the new namespaces are required. --- end of forwarding YI ___ 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
