Agent in act/backup mode rather than ECMP with int. static route

[amit surana]

When interface static routes are provisioned and point to the VMIs of (regular) VMs, agent treats them as active/backup pair and reduces the priority of all but one route, thus not doing ECMP.

In the topology below, an interface static route is provisioned to destination network 1.0.0.0/8 pointing to the left interface of both VM1 and VM2. To being with, both those routes are advertised to the MX with equal local preference of 200 and multi path is setup. Upon sending traffic, the local pref of one of the routes is reduced to 100.

This might be related/similar to 1461787, but logging it to track this specific case of VMs with different IPs having interface static routes pointing to them.

                   |----VM1----P_VN1----|
 cli_vrf---C_VN----| LR---GW1---ser_vrf
                   |----VM2----P_VN2----|

C_VN:

root@csol2-node11:~# rt --dump 1 | grep 2.0.0.0
2.0.0.0/8 8 PT - 38 -

root@csol2-node11:~# nh --get 38
Id:38 Type:Composite Fmly: AF_INET Flags:Valid, Policy, Ecmp, Rid:0 Ref_cnt:2 Vrf:1
              Sub NH(label): 15(25) 25(23)

P_VN1:

root@csol2-node11:~# rt --dump 2 | grep 1.0.0.0 | more
1.0.0.0/8 8 PT - 40 -

root@csol2-node11:~# nh --get 40
Id:40 Type:Composite Fmly: AF_INET Flags:Valid, Policy, Ecmp, Rid:0 Ref_cnt:2 Vrf:2
              Sub NH(label): 15(30) 34(30)

MX:

root@cmbu-tasman# run show route table spi_cli.inet.0

spi_cli.inet.0: 7 destinations, 13 routes (7 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

2.0.0.0/8 @[BGP/170] 01:05:23, localpref 100, from 172.16.180.5
                      AS path: ?, validation-state: unverified
                    > via gr-2/1/0.32772, Push 23
                    [BGP/170] 01:05:23, localpref 100, from 172.16.180.5
                      AS path: ?, validation-state: unverified
                    > via gr-2/2/0.32771, Push 25
                    [BGP/170] 01:05:23, localpref 100, from 172.16.180.7
                      AS path: ?, validation-state: unverified
                    > via gr-2/1/0.32772, Push 23
                    [BGP/170] 01:05:23, localpref 100, from 172.16.180.7
                      AS path: ?, validation-state: unverified
                    > via gr-2/2/0.32771, Push 25
                   #[Multipath/255] 01:05:23, metric2 0
                    > via gr-2/1/0.32772, Push 23
                      via gr-2/2/0.32771, Push 25

[Hari Prasad Killi (haripk)]

I had a chat with Nischal based on our discussion and here are the
conclusions,

1. An interface can have instance-ip, static-route on the interface,
allowed-address-pair and floating-ip on the interface.
2. Static-route, allowed-address-pair and floating-ip will track the
³active² state of the instance-ip. In other words, the ³instance-ip²
active state acts as necessary condition for other features to apply.
3. Static-routes will be active only if the tracked instance-ip is
³active².
4. Allowed-address-pair in active-active configuration will be advertised
only if the ³instance-ip² is active
5. Allowed-address-pair in active-backup will run sequence number
state-machine only if the underlying ³instance-ip² is active
6. Floating-ip route is added only if the underlying instance-ip is
³active².
7. Static-route, floating-ip and allowed-address-pair in active-active
configuration will have route with sequence number 0 always
8. Allowed-address-pair in active-back will run its own state-machine

In addition, we will implement the exponential backoff to take care of
cases where we see traffic from both active and backup end-points.

Regards,
Praveen

[Hari Prasad Killi (haripk)]

R2.20 : https://review.opencontrail.org/#/c/11628/

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/11628
Submitter: Naveen N (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/12581
Submitter: Naveen N (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/13134
Submitter: Naveen N (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

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

commit 590e031df3598e8dfb54d96018082aaf84401fa1
Author: Naveen N <email address hidden>
Date: Tue Aug 18 04:36:21 2015 -0700

* Track static and floating ip preference based on instance ip

1> Floating ip, static route and allowed address pair in ecmp
mode would have preference published based on instance-ip
preference
2> If allowed-address pair address is configured in active-stdby
mode, run path preference algorithm
Test case for same
Closes-bug:#1462093,#1461787

Change-Id: Ied0df91788b6fb4dc289ced5f43548da33ca34cc

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/13214
Submitter: Naveen N (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/13214
Committed: http://github.org/Juniper/contrail-controller/commit/9eabafeb982eb4a8e8ca9fd130e52117810af31c
Submitter: Zuul
Branch: R2.22-dev

commit 9eabafeb982eb4a8e8ca9fd130e52117810af31c
Author: Naveen N <email address hidden>
Date: Tue Aug 18 04:36:21 2015 -0700

* Track static and floating ip preference based on instance ip

1> Floating ip, static route and allowed address pair in ecmp
mode would have preference published based on instance-ip
preference
2> If allowed-address pair address is configured in active-stdby
mode, run path preference algorithm
Test case for same
Closes-bug:#1462093,#1461787

Change-Id: Ied0df91788b6fb4dc289ced5f43548da33ca34cc
(cherry picked from commit 590e031df3598e8dfb54d96018082aaf84401fa1)

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

commit 187cf8830648bcf061e471edd586d2b6186bdf9b
Author: Praveen K V <email address hidden>
Date: Wed Jul 29 16:08:06 2015 +0530

Flow optimizations - Run flow management in a work-queue

As part of flow processing we need to maintain data structures to keep
the flow action in-sync with config changes. Building these changes and
also revaluating flows when config change is notified can result in
significant latencies.

With this change we move the flow management part to a work-queue. The
flow management module is resposible to keep the flow in-sync with
config changed.

Few other slow operations operations such as logging/UVE also will be
moved to this module in subsequent commits.

Partial-Bug: #1479295

Removing the config listener

After IFmap dependency manager is introduced for all the objects in Agent,
the config listener does not play any role other than invoking node observers
and link observers, which is taken care in dependency manager itself.

As part of the same, Uuid change of node is also detected and handled.

Couple of test cases are moved out of flaky tests.

closes-bug: #1480124

Split flow_table.cc to create new file flow_entry.cc

Move FlowEntry methods to new file flow_entry.cc and flow_entry.h
No changes in functionality

Partial-Bug: #1479295

Move Flow logging to Flow Management module

Define a message to enqueue Flow Export requests in Flow Management module. Move FlowExport functionality from FlowTable to
Flow Management module. Replace FlowExport API calls in Flow Stats collector and Flow Table with a message to Flow Management
module.

Partial-Bug: #1479295

Run FlowTable processing from work-queue

This change is a step towards running Flow setup in multiple threads. Flow
creation is a two step process,

FlowHandler :
FlowEntry are created and flow action are determined in this context.
This stage can potentially run in multiple threads (future commits)
FlowHandler runs from a workqueue in "Agent::FlowHandler" task context

FlowTable :
1. Manage flow_entry_map_ which contains all flows
2. Enforce the per-VM flow limits
3. Generate events to KSync and FlowMgmt modueles
FlowTable runs from a workqueue in "Agent::FlowTable" task context

Partial-Bug: #1479295

Optimize packet processing ASIO context

Method PktHandler::HandleRcvPkt is called from ASIO context. Following
processing was done in HandleRcvPkt within this context,

- Decode of the packet including decoding on tunnel headers
- In case of bare-metas identification of interface based on MAC address

This commit minimizes processing in ASIO context. Packet are enqueued to
module work-queue baesd on the agent-header. The packet decode is
subsequently done when work-queue is scheduled.

Partial-Bug: #1479295

* Track static and floating ip preference based on instance ip

1> Floating ip, static route and allowed address pair in ecmp
mode would have preference published based on instance-ip
preference
2> If allowed-address pair address is configured in active-stdby
mode, r...