Re: [openstack-dev] [neutron][networking-sfc] Need help in simulating Service Function VM for forwarding packets from IngressPort to EgressPort
Ravi: If you only want to let the VM-SF to forward traffic from p2 to p3, you can enable ip_forward in VM-SF and configure two static route in VM-SF. Eg :ip route add VM-DST dev p2 ip route add VM-SRC dev p1 Jim 2016-08-18 8:02 GMT+08:00 Ravi Sekhar Reddy Konda < ravisekhar.ko...@oracle.com>: > Hi Networking SFC team > > I need some help in using the openstack Networking-SFC for service > chaining. > > I am trying out Openstack networking-SFC on the devstack VM. > I brought up AllInOne Devstack(master branch) on the Ubuntu VM on the > VirtualBox. > I am trying out the following scenario > > |--| |--| > |--| > | VM-SRC | | VM-SF > | | VM-DST | > |--| > |--| |--| > p1 |p2 | > |p3 p4 | > | | > || > | | > || > Net1 > - > > > I am using "cirros-0.3.4-x86_64-uec" image for bringing up VM-SRC, VM-DST > and VM-SF > > I got struck in enabling the "cirros-0.3.4-x86_64-uec" VM for forwarding > the packets coming from Ingress-Port(p2) to Egress-Port(P3) > I think we can use IPTables rules for enabling VM to forward packets from > Ingress-Port to Egress-Port, but the basic cirros-0.3.4-x86_64-uec > image does not contain IPTables also, I tried to enable external > connectivity for the VM using Floating-IP, I am able to ssh to "VM-SF" from > devstack VM using > floating-IP, but not able to connect to to external world from VM-SF, and > I could not even find yum-install on the cirros-0.3.4-x86_64-uec image for > installing. > > I want to know if there is any VM with minimal footprint(like UFM) which > can be brought up on the virtualBox setup to act as Service Function which > enables forwarding. > Also can anybody give me the steps how to make cirros-0.3.4-x86_64-uec > image to act as Service Function for forwarding traffic. > > Thanks in Advance > Ravi > > __ > 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]How to ensure the mac of neutron port is not reduplicative in a large lay2 network?
Thanks Kevin 2016-07-28 12:51 GMT+08:00 Kevin Benton <ke...@benton.pub>: > If the mac is duplicated on a network it will be violate a uniqueness > constraint in the DB which will trigger a retry. > > On Wed, Jul 27, 2016 at 9:48 PM, 张广明 <gmzhan...@gmail.com> wrote: > >> Hi, folks, >>Now the neutron use a random function to generate the mac address for >> neutron port when it was created . The sequence is as follow: >>_generate_mac >>get_random_mac >> random.randint >> As i understand it, it is possible to get same mac when create two >> different port. Because the random is pseudo random, not a fixed >> based on some unique base. >> >> Can anyone give me some explain? Thanks >> >> >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron]How to ensure the mac of neutron port is not reduplicative in a large lay2 network?
Hi, folks, Now the neutron use a random function to generate the mac address for neutron port when it was created . The sequence is as follow: _generate_mac get_random_mac random.randint As i understand it, it is possible to get same mac when create two different port. Because the random is pseudo random, not a fixed based on some unique base. Can anyone give me some explain? Thanks __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][taas] Taas can not capture the packet, if the two VM on the same host. Is it a Bug?
Hi Kaz Thanks for your answer. But int the log, i can not find how to resolve this issue. In fact ,this issue is not related with br-ex. In OVS, the normal action add or remove vlan id when output the packet. So we should add another rule that use in_port that belongs to the same vlan with mirror port as rule condition in br-int. Jimmy 2016-07-05 17:01 GMT+08:00 SUZUKI, Kazuhiro <k...@jp.fujitsu.com>: > Hi, > > I also have seen the same situation. > The same issue is discussed at the IRC meeting of TaaS. > Please take a look at the log. > > > http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-04-13-06.30.log.html > > Regards, > Kaz > > > From: 张广明 <gmzhan...@gmail.com> > Subject: [openstack-dev] [neutron][taas] Taas can not capture the packet, > if the two VM on the same host. Is it a Bug? > Date: Fri, 1 Jul 2016 16:03:53 +0800 > > > Hi , > > I found a limitation when use taas. My test case is descripped as > > follow: > > VM1 and VM2 is running on the same host and they are belong the > vlan. > > The monitor VM is on the same host or the other host . I want to monitor > > the only INPUT flow to the VM1. > > So I configure the tap-flow like this "neutron tap-flow-create > --port > > 2a5a4382-a600-4fb1-8955-00d0fc9f648f --tap-service > > c510e5db-4ba8-48e3-bfc8-1f0b61f8f41b --direction IN ". > > When ping from VM2 to VM1. I can not get the flow in the monitor VM. > >The reason is the the flow from VM2 to VM1 in br-int has not vlan > > information. The vlan tag was added in flow when output the packet in > OVS. > > So the code in file ovs_taas.py did not work in this case . > > > > if direction == 'IN' or direction == 'BOTH': > > port_mac = tap_flow['port_mac'] > > self.int_br.add_flow(table=0, > > priority=20, > > dl_vlan=port_vlan_id, > > dl_dst=port_mac, > > > actions="normal,mod_vlan_vid:%s,output:%s" % > > (str(taas_id), str(patch_int_tap_id))) > > > > > > > > > > Is this is a Bug or a Design ?? > > > > > > > > Thanks. > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][taas] Taas can not capture the packet, if the two VM on the same host. Is it a Bug?
Hi , I found a limitation when use taas. My test case is descripped as follow: VM1 and VM2 is running on the same host and they are belong the vlan. The monitor VM is on the same host or the other host . I want to monitor the only INPUT flow to the VM1. So I configure the tap-flow like this "neutron tap-flow-create --port 2a5a4382-a600-4fb1-8955-00d0fc9f648f --tap-service c510e5db-4ba8-48e3-bfc8-1f0b61f8f41b --direction IN ". When ping from VM2 to VM1. I can not get the flow in the monitor VM. The reason is the the flow from VM2 to VM1 in br-int has not vlan information. The vlan tag was added in flow when output the packet in OVS. So the code in file ovs_taas.py did not work in this case . if direction == 'IN' or direction == 'BOTH': port_mac = tap_flow['port_mac'] self.int_br.add_flow(table=0, priority=20, dl_vlan=port_vlan_id, dl_dst=port_mac, actions="normal,mod_vlan_vid:%s,output:%s" % (str(taas_id), str(patch_int_tap_id))) Is this is a Bug or a Design ?? Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][sfc] Is there a bug in networking-sfc?
Hi Cathy and other guys
I am a beginner that use networking-sfc. I create a port-chain-list
that want to steer a flow that is from public-net to private-net to SF
node. The DVR is enable in my test environment.
The test result is the flow was steered from destination node to SF node
and return to the destination node rightly, but the flow was match the
classify rule again,so the flow can not to be send to
the destination VM.
In networking-sfc agent code . there is a
function update_src_node_flow_rules that create a normal flow to handle
this case. But in networking-sfc ovs dirver code,
_update_src_node_flowrules can't
call ask_agent_to_update_src_node_flow_rules to notify agent to
exec update_src_node_flow_rules. The reason is the function
_get_portchain_src_node_flowrule return None. In function
_get_portchain_src_node_flowrule , the check
that was marked red is not right in this case.
def _get_portchain_src_node_flowrule(self, node,
add_fc_ids=None, del_fc_ids=None):
try:
add_fc_rt = []
del_fc_rt = []
if add_fc_ids:
for fc in self._get_fcs_by_ids(add_fc_ids):
if not fc.get('logical_source_port', None):
add_fc_rt.append(fc)
if del_fc_ids:
for fc in self._get_fcs_by_ids(del_fc_ids):
if not fc.get('logical_source_port', None):
del_fc_rt.append(fc)
if not add_fc_rt and not del_fc_rt:
return None
return self._build_portchain_flowrule_body_without_port(
node, add_fc_rt, del_fc_rt)
except Exception as e:
LOG.exception(e)
LOG.error(_LE("_get_portchain_src_node_flowrule failed"))
Is it a bug or my configure is wrong?
root@rg1-com01 ~]# neutron flow-classifier-show
4542a747-b205-41ff-970c-1ea11fa956fc
++--+
| Field | Value|
++--+
| description| |
| destination_ip_prefix | 192.168.1.0/24 |
| destination_port_range_max | |
| destination_port_range_min | |
| ethertype | IPv4 |
| id | 4542a747-b205-41ff-970c-1ea11fa956fc |
| l7_parameters | {} |
| logical_destination_port | |
| logical_source_port| f18895cf-6c4b-495a-8bd5-e8f12ae86541 |
| name | FC-F3|
| protocol | |
| source_ip_prefix | 192.168.200.0/24 |
| source_port_range_max | |
| source_port_range_min | |
| tenant_id | 02e5a953a113479388103c585f5b5ae1 |
++--+
the original flow is 192.168.200.2 to 192.168.200.202 floatingip(
192.168.1.202 private ip)
logical_source_port is fg-xxx interface in namespace fip.
Thanks
Jim
__
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
