This issue affects 1.2 as well as current trunk:
Create an in-network service instance, and associate it with a policy attached to 2 networks.
Attach a floating IP to an interface of the service instance
As soon as trafic coming from the instance hits the vrouter, it will soft-reset.
Here is the backtrace:
#0 DBEntryBase::get_table (this=this@entry=0x0) at controller/src/db/db_entry.cc:94
#1 0x0000000000a0c792 in RouteToOutInfo (rt=0x0, pkt=pkt@entry=0x1403790, info=info@entry=0x7fffee4f7980, in=in@entry=0x7fffee4f7900, out=out@entry=0x7fffee4f7940) at controller/src/vnsw/agent/pkt/pkt_flow_info.cc:255
#2 0x0000000000a0ef8e in PktFlowInfo::FloatingIpSNat (this=this@entry=0x7fffee4f7980, pkt=pkt@entry=0x1403790, in=in@entry=0x7fffee4f7900, out=out@entry=0x7fffee4f7940) at controller/src/vnsw/agent/pkt/pkt_flow_info.cc:730
#3 0x0000000000a0f5ae in PktFlowInfo::IngressProcess (this=this@entry=0x7fffee4f7980, pkt=pkt@entry=0x1403790, in=in@entry=0x7fffee4f7900, out=out@entry=0x7fffee4f7940) at controller/src/vnsw/agent/pkt/pkt_flow_info.cc:880
#4 0x0000000000a0f717 in PktFlowInfo::Process (this=this@entry=0x7fffee4f7980, pkt=0x1403790, in=in@entry=0x7fffee4f7900, out=out@entry=0x7fffee4f7940) at controller/src/vnsw/agent/pkt/pkt_flow_info.cc:996
#5 0x0000000000a0bf12 in FlowHandler::Run (this=0x7fffe0116760) at controller/src/vnsw/agent/pkt/flow_handler.cc:54
#6 0x00000000009f2fa6 in Proto::ProcessProto (this=<optimized out>, msg_info=...) at controller/src/vnsw/agent/pkt/proto.cc:44
#7 0x00000000009f39bc in operator() (a1=..., p=<optimized out>, this=<optimized out>) at /usr/include/boost/bind/mem_fn_template.hpp:165
#8 operator()<bool, boost::_mfi::mf1<bool, Proto, boost::shared_ptr<PktInfo> >, boost::_bi::list1<boost::shared_ptr<PktInfo>&> > (a=<synthetic pointer>, f=..., this=<optimized out>) at /usr/include/boost/bind/bind.hpp:303
#9 operator()<boost::shared_ptr<PktInfo> > (a1=..., this=<optimized out>) at /usr/include/boost/bind/bind_template.hpp:32
#10 boost::detail::function::function_obj_invoker1<boost::_bi::bind_t<bool, boost::_mfi::mf1<bool, Proto, boost::shared_ptr<PktInfo> >, boost::_bi::list2<boost::_bi::value<Proto*>, boost::arg<1> > >, bool, boost::shared_ptr<PktInfo> >::invoke (function_obj_ptr=...,
a0=...) at /usr/include/boost/function/function_template.hpp:132
#11 0x00000000009f4e0f in operator() (a0=..., this=0x7fffee4f7b90) at /usr/include/boost/function/function_template.hpp:767
#12 QueueTaskRunner<boost::shared_ptr<PktInfo>, WorkQueue<boost::shared_ptr<PktInfo> > >::RunQueue (this=0x1401780) at controller/src/base/queue_task.h:53
#13 0x0000000000e6a3e0 in TaskImpl::execute (this=0x7fffeeaf3a40) at controller/src/base/task.cc:224
#14 0x00007ffff647bb3a in ?? () from /usr/lib/libtbb.so.2
#15 0x00007ffff6477816 in ?? () from /usr/lib/libtbb.so.2
#16 0x00007ffff6476f4b in ?? () from /usr/lib/libtbb.so.2
#17 0x00007ffff64730ff in ?? () from /usr/lib/libtbb.so.2
#18 0x00007ffff64732f9 in ?? () from /usr/lib/libtbb.so.2
#19 0x00007ffff6697182 in start_thread (arg=0x7fffee4f8700) at pthread_create.c:312
#20 0x00007ffff596ffbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
One option can be to also add a rule indicating floating ip to any to do routing in native vrf.
Sachin
=======
Hi Sachin,
In case of in-network service interface, interface has VRF assign acl entries present in it.
Rules are as below
1> Self-IP to any —Do route lookup in native VRF
2> Rest all — Do route lookup in internal VRF.
If this interface also has floating IP, then in agent we were applying this ACL after floating-ip
translation and eventually doing route lookup in internal VRF where destination route would
not be present.
Can this ACL be more precise specifying source VN and destination VN??
Or Should agent not apply interface ACL entries while doing floating IP translation??
Regards
Naveen N