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

Reply via email to