Hey Manish,
Thanks for the quick reply. As far as I understood, this patch is for
R4? So my description below is accurate, and BGPaaS is not supposed to
play well with policy-disabled interfaces in R3.x?
Thanks,
Valentine
On 24.11.2017 23:32, Manish Singh wrote:
Hey Valentine,
Agent stopped setting this flag, here is the commit:
https://github.com/Juniper/contrail-controller/commit/df02316b355b4666e4018254ba44bee754b72dd2
Thanks,
Manish
On 11/23/17, 9:05 PM, "Dev on behalf of Valentine Sinitsyn"
<dev-boun...@lists.opencontrail.org on behalf of valentine.sinit...@gmail.com> wrote:
Hi everyone,
I'm looking at OpenContrail (3.1 if that matters) code to figure out how
BGPaaS flows are installed in the vRouter. This is what I've got so far:
Config phase:
-------------
- InterfaceNH::CreatePacketInterfaceNh() creates two next hops (nh) for
pkt0: one with policy disabled and one with policy enabled
- VnTable::AddIPAMRoutes() creates a route to the VN's default gateway
via the policy-enabled nexthop, as "we want to trap BGPaaS flows" (as
the comment says).
- NHKSyncEntry::Encode() pushes NH_FLAG_FLOW_LOOKUP to the kernel if
both policy and relaxed_policy are enabled for the interface.
Runtime phase - vRouter Agent:
------------------------------
- VrouterControllerInterface::Process() captures a packet from pkt0,
decodes agent headers and sends it to the PktHandler::Process()
- PktHandler::ParsePacket() is called which checks if this packet was
trapped due to TRAP_FLOW_MISS or TRAP_ACTION_HOLD (or TRAP_ECMP_RESOLVE,
actually). If so, it checks if it is a BGP SYN packet, creates the
corresponding NAT flow for BGPaaS and pushes it to the kernel.
So far, so good. Now, let us see what happens inside vRouter:
- Both TRAP_FLOW_MISS and TRAP_ACTION_HOLD are set in vr_trap_flow()
- vr_trap_flow() is called from vr_enqueue_flow()
- vr_enqueue_flow() is called from vr_do_flow_action() if
VR_FLOW_ACTION_HOLD is set
- vr_do_flow_action() is called from vr_flow_lookup(), which also sets
VR_FLOW_ACTIOB_HOLD on the flow if it's a new one (true for the SYN
packet) **UNLESS** the corresponding next hop has NH_FLAG_FLOW_LOOKUP flag.
Bang! We set the NH_FLAG_FLOW_LOOKUP flag to trap new BGP sessions to
agent, and this very flag prevents them from being trapped with an
appropriate reason.
I doubt it's a bug as I have an impression BGPaaS works in 3.1, at least
to some extent.
So which piece of a puzzle am I missing?
Sukhdev, you are a kind of point of contact in the TSC: may I ask you to
summon a Juniper's BGPaaS expert in this thread? :-) Many thanks!
Cheers,
Valentine
_______________________________________________
Dev mailing list
Dev@lists.opencontrail.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opencontrail.org_mailman_listinfo_dev-5Flists.opencontrail.org&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=WOCi8VGCEEr0-A_ll-ysCYHVLq4mNPlO5yyDOXLbgsw&m=d3VPRt3RkZRy3cfmqFuMvZQMqpK8pL2mxkgnJj190Uo&s=dwknFAml3GrrVL2v0J43TpvD7dcy6ld6LwEWJZsjBpI&e=
_______________________________________________
Dev mailing list
Dev@lists.opencontrail.org
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
