TSN crash when ToR forwards unknown unicast packet

Bug #1465607 reported by Praveen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R2.20
Fix Committed
High
Praveen
Trunk
Fix Committed
High
Praveen

Bug Description

(gdb) bt
#0 0x00007f475cb540d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f475cb5783b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f475cb4cd9e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007f475cb4ce42 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00000000015ba15a in FlowEntry::SetRpfNH (this=0x7f46d40048c0, ft=0x7f4754051550, rt=0x7f46e00194a0)
    at controller/src/vnsw/agent/pkt/flow_table.cc:1286
#5 0x00000000015ba9d7 in FlowEntry::InitFwdFlow (this=0x7f46d40048c0, info=0x7f4700f7a8a0, pkt=0x3088a50, ctrl=0x7f4700f7a7e0,
    rev_ctrl=0x7f4700f7a820) at controller/src/vnsw/agent/pkt/flow_table.cc:1423
#6 0x00000000015f2259 in PktFlowInfo::Add (this=0x7f4700f7a8a0, pkt=0x3088a50, in=0x7f4700f7a7e0, out=0x7f4700f7a820)
    at controller/src/vnsw/agent/pkt/pkt_flow_info.cc:1399
#7 0x00000000015fce77 in FlowHandler::Run (this=0x7f46d401e3c0) at controller/src/vnsw/agent/pkt/flow_handler.cc:80
#8 0x00000000015f8bd5 in Proto::ProcessProto (this=0x7f4754037d40, msg_info=...) at controller/src/vnsw/agent/pkt/proto.cc:44
#9 0x00000000015faf0e in boost::_mfi::mf1<bool, Proto, boost::shared_ptr<PktInfo> >::operator() (this=0x7f4700f7abe8,
    p=0x7f4754037d40, a1=...) at build/include/boost/bind/mem_fn_template.hpp:165
#10 0x00000000015fa920 in boost::_bi::list2<boost::_bi::value<Proto*>, boost::arg<1> >::operator()<bool, boost::_mfi::mf1<bool, Proto, boost::shared_ptr<PktInfo> >, boost::_bi::list1<boost::shared_ptr<PktInfo>&> > (this=0x7f4700f7abf8, f=..., a=...)
    at build/include/boost/bind/bind.hpp:303
#11 0x00000000015fa308 in boost::_bi::bind_t<bool, boost::_mfi::mf1<bool, Proto, boost::shared_ptr<PktInfo> >, boost::_bi::list2<boost::_bi::value<Proto*>, boost::arg<1> > >::operator()<boost::shared_ptr<PktInfo> > (this=0x7f4700f7abe8, a1=...)
    at build/include/boost/bind/bind_template.hpp:32
#12 0x00000000015f9ebf in 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 build/include/boost/function/function_template.hpp:132
#13 0x00000000015ed361 in boost::function1<bool, boost::shared_ptr<PktInfo> >::operator() (this=0x7f4700f7abe0, a0=...)
    at build/include/boost/function/function_template.hpp:763
#14 0x00000000015fb2f6 in QueueTaskRunner<boost::shared_ptr<PktInfo>, WorkQueue<boost::shared_ptr<PktInfo> > >::RunQueue (
    this=0x3094800) at controller/src/base/queue_task.h:81
#15 0x00000000015fb12e in QueueTaskRunner<boost::shared_ptr<PktInfo>, WorkQueue<boost::shared_ptr<PktInfo> > >::Run (this=0x3094800)
    at controller/src/base/queue_task.h:64
#16 0x0000000001bfdf21 in TaskImpl::execute (this=0x3081a40) at controller/src/base/task.cc:238
#17 0x00007f475d71eece in ?? () from /usr/lib/libtbb_debug.so.2
#18 0x00007f475d715e0b in ?? () from /usr/lib/libtbb_debug.so.2
#19 0x00007f475d7146f2 in ?? () from /usr/lib/libtbb_debug.so.2
#20 0x00007f475d70f3ce in ?? () from /usr/lib/libtbb_debug.so.2
#21 0x00007f475d70f270 in ?? () from /usr/lib/libtbb_debug.so.2
#22 0x00007f475d948e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#23 0x00007f475cc1138d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#24 0x0000000000000000 in ?? ()

Tags: vrouter
Revision history for this message
Praveen (praveen-karadakal) wrote :

The setup used here is,

1. VN is created with subnet 1.1.1.0/24. VXLAN is 2000
2. There are 2 MX in network. Gateway ip 1.1.1.1 is assigned as VRRP-IP on MX
3. The MAC for VRRP IP is 00:00:5E:00:01:01
4. Due to 2 MX, route for 1.1.1.0/24 is ECMP with the 2 MX
5. Baremetal with IP 1.1.1.5 pings Gateway IP 1.1.1.1
6. The ToR does not have FDB for 00:00:5E:00:01:01. As a result, it sends packet to TSN for flooding

VRouter on TSN does following:
1. VRouter receives packets on VXLAN 2000
2. VRouter does route lookup for src-ip (1.1.1.5)
3. Route lookup for src-ip 1.1.1.5 hits ECMP route 1.1.1.0/24. ECMP NH contains the two MX
4. VRouter traps packet for flow-processing

Agent on TSN does following:
1. Agent tries to create L2 Flow
2. Agent tries to set RPF NH for the flow
3. The RPF lookup for 1.1.1.5 hits ECMP Route

Problem:
Agent is doing IP lookup for RPF checks for packet from Baremetal. In L2 Flow setup, agent is not expecting ECMP-NH in RPF processing.

Fix:
When flow is being setup for BMS, agent is not aware of IP for BMS. So, RPF check should be based on Src-MAC instead of Src-IP

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R2.20

Review in progress for https://review.opencontrail.org/11682
Submitter: Praveen K V (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/11682
Committed: http://github.org/Juniper/contrail-controller/commit/2a5d07ab55e6d0010c687a9ee7e758e09a28ee9f
Submitter: Zuul
Branch: R2.20

commit 2a5d07ab55e6d0010c687a9ee7e758e09a28ee9f
Author: Praveen K V <email address hidden>
Date: Tue Jun 16 16:08:11 2015 +0530

RPF check for baremetal flows should check src-mac

Problem:
When flow is being setup for baremetal, method FlowEntry::SetRpfNH is
using src-ip to do RPF check.

Fix:
In case of baremetals, agent is not aware of IP address. So, it must do
RPF check based on src-mac instead of src-ip.

Change-Id: I928fdeca1fb79b1474ba9e33c3a2e6616de29ebb
Closes-Bug: #1465607

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/11868
Submitter: Praveen K V (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/11868
Committed: http://github.org/Juniper/contrail-controller/commit/f8f4abc6f486db9ebd93ef141be6fd1b5b827e69
Submitter: Zuul
Branch: master

commit f8f4abc6f486db9ebd93ef141be6fd1b5b827e69
Author: Praveen K V <email address hidden>
Date: Tue Jun 16 16:08:11 2015 +0530

RPF check for baremetal flows should check src-mac

Problem:
When flow is being setup for baremetal, method FlowEntry::SetRpfNH is
using src-ip to do RPF check.

Fix:
In case of baremetals, agent is not aware of IP address. So, it must do
RPF check based on src-mac instead of src-ip.

Change-Id: I928fdeca1fb79b1474ba9e33c3a2e6616de29ebb
Closes-Bug: #1465607

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.