Service chain route leaking/re-origination enhancements
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Juniper Openstack | Status tracked in Trunk | |||||
R3.0 |
Fix Committed
|
Medium
|
Prakash Bailkeri | |||
Trunk |
Fix Committed
|
Medium
|
Prakash Bailkeri |
Bug Description
This is a placeholder bug to track several enhancements to route leaking
and re-origination in the context of service chaining.
1. Ability to prevent re-origination of interface static routes - this is
typically required when routes are configured on an interface that belongs
to a service VM. Need to allow user to configure a NoReoriginate property
for interface static route.
Sample use case is where there's a right VN which is a public network and
the last VM in the SFC between the left VN and the right VN does NAT using
a NAT pool. The right interface of the VM needs to be configured with an
interface static route for the NAT pool so that destination in the right
VN know how to reach addresses in the NAT pool. However, the NAT pool
prefix clearly should not be re-orignated into the left VN.
2. Advertise default route (instead of all specifics) into access VN/VPN.
This is required for scaling reasons when PEs in an access VPN cannot be
burdened (in control and/or data plane) with all the more specific routes
from other access VPNs. It is sufficient to advertise a default route into
the access VPN. Ideal behavior is for the default to be an aggregate route
that gets activated when at least one more specific route is available.
3. Advertise aggregate (instead of more specifics) with service chaining
Consider a left VN/VPN and right VN/VPN with a SFC applied via a policy.
The left interface of the leftmost VM in the SFC could be configured with
an interface static route that represents an aggregate of all the routes
in the right VN/VPN. In this case, service chaining should only advertise
this static route into the left VN/VPN and suppress the more specifics.
The forwarding information (Nexthop + Label) for the route should direct
traffic going from left VPN to right VPN to the left interface of leftmost
VM in the SFC.
This is a generalization of item 2 above.
Functionality has to be configurable independently for both directions.
Should provide ability to configure multiple such aggregate static routes
to handle cases where all VPN routes cannot be aggregated to one prefix.
4. Nominal/Backup SFCs in different clusters/DCs
Two identical SFCs need to be created in different contrail clusters. The
SFCs are to be applied for the same pair of VPNs. There's a requirement to
steer traffic from the VPN PEs to the nominal/active SFC, while keeping
the other SFC as a hot standby.
In order to achieve this goal contrail needs to provide the ability to set
the local preference for re-originated routes. Since local preference does
not apply for eBGP, it's required that 1 of 2 user-defined (or predefined)
community values can be attached to re-orignated routes. The VPN PEs can
use policy to match these communities and influence path selection.
Both the local preference and community mechanisms need to be supported to
handle iBGP and eBGP scenarios.
description: | updated |
information type: | Proprietary → Public |
description: | updated |
description: | updated |
summary: |
- Service chain route leaking/re-orignation enhancements + Service chain route leaking/re-origination enhancements |
description: | updated |
description: | updated |
tags: | added: config |
description: | updated |
description: | updated |
description: | updated |
Review in progress for https:/ /review. opencontrail. org/14643
Submitter: Prakash Bailkeri (<email address hidden>)