Support transit VN to provide transitive connectivity between VNs/VPNs

[Nischal Sheth]

This tracks a feature request to support the notion of a transit VN.

Consider 2 regular VNs VN1 and VN2 and a transit VN VNx. If VN1
and VN2 are connected to VNx using a policy, either directly or via
a service chain, VN1 and VN2 must be able to communicate with
each other. Further, traffic between these VNs should behave as
though it were traversing the transit network VNx. It must pass
through any service chains configured between VN1/VN2 and VNx.

All of the following cases need to be supported, where SC denotes
a service chain:

a) VN1---VNx---VN2
b) VN1---SC1x---VNx---VN2
c) VN1---SC1x---VNx---SC2x---VN2
d) VN1---VNx---SC2x---VN2

There should be no fixed limit on the number of regular VNs that can
obtain connectivity to each other through a transit VN in this manner.

It's desirable to also allow transit VNs to connect to each other and
provide transitive connectivity to regular VNs that are connected to
them. An example would be VN1---VNx---VNy---VN2, where VN1 and
VN2 are regular VNs and VNx and VNy are transit VNs.

Two design options are being considered:

1. Routes that are imported into a transit VN get re-originated with
a new RD and RTs for the transit VN. This is similar to service chaining
except that the nexthop and label are not changed.

This approach requires almost no changes to regular VN functionality.
However, new RDs need to be manufactured and loop detection checks
need to tweaked/relaxed, especially in a multi-AS scenario.

2. Manipulate the export RTs of regular VNs so that they also contain
export RTs of transit VNs when appropriate. This is somewhat similar
to how logical-router is implemented, except that service chaining also
needs to supported.

This approach does not require any tweaks to bgp loop detection logic.
However, it does require careful manipulation/setting of the OriginVn
extended community to ensure that ACLs allow traffic to go through.
This becomes tricker if we also want to support transitive connectivity
via multiple transit VNs.

[Francois Eleouet (fanchon)]

Case a) seems to be already supported: if we configure "regular" policies (w/o service instances) matching any source and destination networks, routes from VN1 are propagated to VN2 through VNx.

[Harshad Nakil (hnakil)]

@Francious
Yes it is supported using regular policy, However When we need to interconnect many networks to each other via a policy, then transit VN gives nice way for indirection. So basically saying allow tcp port 80 current network and all other networks. All other networks can be represented by transit network.

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/3473
Committed: http://github.org/Juniper/contrail-controller/commit/c296fa3ae88e8b63e0515c8377d4f63a8daedb81
Submitter: Zuul
Branch: R1.10

commit c296fa3ae88e8b63e0515c8377d4f63a8daedb81
Author: Nischal Sheth <email address hidden>
Date: Wed Sep 24 22:34:58 2014 -0700

Implement transit network functionality for service chaining

Following changes have been implemented in control-node:

- Schema change to add allow-transit to VirtualNetworkType
- BGP instance config keeps track of allow-transit attribute
- RoutingInstance is updated with allow-transit from config
- Tweak service chaining code to re-originate routes that are
in the dest routing instance, even if their OriginVn is not
the same as dest instance. This exception is made only if
the VN of the dest instance is a transit VN. The OriginVn
for such routes is set to be the VN for the dest instance.
- Handle changes in allow-transit attribute
- Add tests for the new functionality

Limitations (to be enforced in API server via follow-up commit):

- A VN cannot be connected directly to a transit VN - it must
be connected via a chain of 1 or more services.
- The allow-transit attribtue can only be set when creating a
VN, it cannot be updated later.

Change-Id: I9c81ba61a3bf0e8db04577b09ee26aa5aa60ad4d
Partial-Bug: 1365277

[OpenContrail Admin (ci-admin-f)]

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

commit 3c0f26f1756bf9161dbb330115078d6e478a5570
Author: Nischal Sheth <email address hidden>
Date: Wed Sep 24 22:34:58 2014 -0700

Implement transit network functionality for service chaining

Following changes have been implemented in control-node:

- Schema change to add allow-transit to VirtualNetworkType
- BGP instance config keeps track of allow-transit attribute
- RoutingInstance is updated with allow-transit from config
- Tweak service chaining code to re-originate routes that are
in the dest routing instance, even if their OriginVn is not
the same as dest instance. This exception is made only if
the VN of the dest instance is a transit VN. The OriginVn
for such routes is set to be the VN for the dest instance.
- Handle changes in allow-transit attribute
- Add tests for the new functionality

Limitations (to be enforced in API server via follow-up commit):

- A VN cannot be connected directly to a transit VN - it must
be connected via a chain of 1 or more services.
- The allow-transit attribtue can only be set when creating a
VN, it cannot be updated later.

Change-Id: I9c81ba61a3bf0e8db04577b09ee26aa5aa60ad4d
Partial-Bug: 1365277

[Francois Eleouet (fanchon)]

I've tested the proposed patch, and faced a couple of issues:

While configuring the following chain VN1---VNx---VN2 with allow_transit=True on VNx, VN1 routes are re-originated back to the same VN. For exmaple on an adjacent MX router, here is what I see on a VRF sharing VN1's RT:

# run show route table VN1.inet.0
172.16.1.1/32 *[Direct/0] 23:05:20
                                > via lo0.2001
                                [BGP/170] 00:00:00, localpref 100, from 192.168.254.84
                                AS path: 64512 ?, validation-state: unverified
                                > via gr-2/0/10.32769, Push 16

As you can see, VRF loopback address is re-originated in service chain routing instance, and re-annonced back to MX.

Another issue is that as soon as I configure such service policies, vrouter-agent and control processes jump repectively to ~800 ~1200% CPU consumption...

[Nischal Sheth (nsheth)]

@Francois

Could you please clarify whether you tested VN1---VNx---VN2 or VN1---SC1x---VNx---SC2x---VN2?
Did you see problems with both these scenarios?

[Nischal Sheth (nsheth)]

@Francois

I've identified a bug which explains the CPU spike when service chaining is enabled
with transit network. Working on a fix and additional tests for the scenario.

[Francois Eleouet (fanchon)]

@Nischal:

Sorry for the misIead, I was actually using service instances in my test (VN1---SC1x---VNx---SC2x---VN2), I haven't yet tested it using regular policies yet (as discussed earlier, transitivity is already roughly supported using regular policies matching 'any' source/dest networks)

I'm glad you found the issue regarding CPU consuption, I'll restart testing the feature once the fix will be proposed.

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/3826
Committed: http://github.org/Juniper/contrail-controller/commit/7b102a5cf7bd0f943f71d2e03f1adfaf2828c9cc
Submitter: Zuul
Branch: R1.10

commit 7b102a5cf7bd0f943f71d2e03f1adfaf2828c9cc
Author: Nischal Sheth <email address hidden>
Date: Thu Oct 16 11:44:26 2014 -0700

Fix circular route re-origination bug with transit VN

Problem:

When a service is applied between a VN and a transit VN, routes from the
VN that are re-originated into the transit VN as ServiceChain routes get
re-originated again as ServiceChain routes into the regular VN.

Cause:

Implementation prior to transit VN used to ignore routes that did belong
to the destination VN of the service chain. Code changes for transit VN
functionality relaxed this check, but did not cover the case where route
belongs to the source VN.

Fix:

Add check to ignore routes from source VN.

Change-Id: Ic6f5520217eca64b79f5144d71f80aa6d661e48a
Partial-Bug: 1365277

[OpenContrail Admin (ci-admin-f)]

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

commit 6119e734257f35595c3571b033bd0d7788494a90
Author: Nischal Sheth <email address hidden>
Date: Wed Oct 15 13:52:21 2014 -0700

Fix circular route re-origination bug with transit VN

Problem:

When a service is applied between a VN and a transit VN, routes from the
VN that are re-originated into the transit VN as ServiceChain routes get
re-originated again as ServiceChain routes into the regular VN.

Cause:

Implementation prior to transit VN used to ignore routes that did belong
to the destination VN of the service chain. Code changes for transit VN
functionality relaxed this check, but did not cover the case where route
belongs to the source VN.

Fix:

Add check to ignore routes from source VN.

Change-Id: Ifdff8e828f0d4a9bc20ab055e0e9206d2cfd347a
Partial-Bug: 1365277