Jump to: navigation, search

Difference between revisions of "Neutron/BGP MPLS VPN"

(Configuration variables:)
(Replaced content with "Updated for more simple model (see https://docs.google.com/a/ntti3.com/document/d/1aVfYHiGrwL7XyE639_sCBkmALy7FKCJqPX8DqiHk7kY/edit#heading=h.kf4wr792gej6 )")
 
(39 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Quantum BGP/MPLS IP Virtual Private Networks (VPNs) support on Logical Router ==
+
Updated for more simple model
 
+
(see
== Scope: ==
+
https://docs.google.com/a/ntti3.com/document/d/1aVfYHiGrwL7XyE639_sCBkmALy7FKCJqPX8DqiHk7kY/edit#heading=h.kf4wr792gej6 )
This BP implements partial RFC4364 BGP/MPLS IP Virtual Private Networks (VPNs) support for interconnecting existing network and OpenStack cloud, or inter connection of OpenStack Cloud.
 
 
 
== Use Cases: ==
 
Use case 1: Connect Quantum Virtual Network with Existing VPN site via Virtual Router
 
In this case, we connect virtual networks in the quantum to the existing VPN site via Virtual Router. Each route will be dynamically exchanged using BGP.
 
 
 
 
 
Use case 2: Interconnect multiple OpenStack regions
 
There are 3 regions which is interconnected via some VPN method (eg, IPSec) in the diagram below. All regions are managed by only one operator. 10.0.0.0/24 is on Region1 and 20.0.0.0/24,30.0.0.0/24 are so on.
 
Using ibgp, we can connect virtual networks on any cluster on efficient manner.
 
 
 
The diagram below shows encapsulation of packet on this usecase. Each region connected with IPSec tunnel w/ Encryption. Each packet will labeled with MPLS.
 
 
 
== Data Model Changes: ==
 
 
 
=== Router (attribute extension) ===
 
 
 
Admin only parameter
 
 
 
#  route_distinguisher = type:administrator:assigned
 
 
 
* type=0  administrator=16bit : assigned = 32bit 
 
* type=1  administrator=IPaddress: assigned = 16bit
 
* type=2  administrator=4octet AS Number: assigend = 16 bit
 
Note Default value automatically assigned with type=0 format
 
 
 
Tenant parameter
 
 
 
# local_prefixes = [10.0.0.0/24] list of prefix which will be exposed
 
# remote_prefixes =[20.0.0.0/24]  list of imported prefix ( if this value is null, l3-agent setup all recieved routes
 
# connect_from = [VPNG_ID1,VPNG_ID2,VPNG_ID3]  (list of vpn group  )
 
# connect_to = [VPNG_ID1, VGPN_ID2] (list of vpn group )
 
 
 
Note: default value of connect_from/connet_to route target will all vpns in the list on create
 
 
 
=== Network (extended attribute) ===
 
 
 
# bgp_mpls_vpn=true|false
 
# pe_agent
 
 
 
User can add interface of the Network of which bgp_mpls_vpn enabled.
 
 
 
=== BGPVPNGroup (new resource) ===
 
shows list of route targets assigned for each tenant
 
 
 
# id:
 
# name:
 
# tenant_id:
 
# route targets(*)  asn16bit :32bit integer or ipv4:16bit integer  (admin only)
 
 
 
(*) Only admin user can specify route target, otherwise it will be automatically assigned.
 
 
 
=== BGP Routes (new resource)  Admin Only===
 
 
 
# prefix
 
# nexthop
 
# rt
 
# rd
 
# router_id
 
# paths (list of paths sorted by score)
 
 
 
Sub attribute of paths
 
# nexthop,
 
# as_path,
 
# multi_exit_disc,
 
# local_pref,
 
# origin,
 
# labels,
 
# client,
 
# local
 
 
 
=== BGP Peers (new resource) Admin only ===
 
 
 
# id
 
# neighbor_ip
 
# remote_as
 
# status = (ACTIVE|DOWN)
 
# admin_status=True|False
 
# route_refrector
 
# pe_agent
 
 
 
== Model of BGPVPNGroup ==
 
 
 
BGPVPNGroup correspond to  Route target internally. (see RFC4364 4.3.5.  Building VPNs Using Route Targets). In this diagram, VPN site1 and Site2 can talk each other.
 
 
 
 
 
You can also support hub-spoke model, shown in the diagram. In this case Hub Site and Spoke Site1 and Site2 can reach each other, however Spoke Site1 and Site2 is unreach.
 
 
 
BGPVPNGroup will be managed by Network provider.
 
We will share one BGPVPNGroup server in different data centers. In the diagram below, Region2, and Region3 uses BGPVPNGroup DB in Region1, thus they can assign BGPVPNGroup by consistent manner between several regions.
 
 
 
 
 
Note, this BGPVPNGroup assignment has driver architecture.
 
For same case, Network operator have already managing mapping to BGPVPNGroup (RT) and tenant. Fot that case,the Network operator can implement a driver which provides there own BGPVPNGroup (RT) and tenant mappings.
 
 
 
== Implementation Overview: ==
 
 
 
The diagram below shows implementation overview.
 
Quantum Server and BGP Peer will be connected via BGP speaker process.
 
There are no Open Source project which support BGP/MPLS vpn yet, we will also open our erlang version implementation of bgp speaker and PE router which will implemented partial RFC. But this design is not limited to our implementation, and API itself can be connected any MPLS/PE router implementation.
 
BGP Speaker send update of Router configuration for BGP peer, and get routes from Peer.
 
Our PE also set up vlan to mpls transformation and adding or removing mpls labels for each outgoing packet. Note that we are not talking about transport labels and that transport will be either p2p (option B ASBR) or GRE encapsulation will be used.
 
 
 
 
 
 
 
The sequence below shows how each component will talk each other.
 
 
 
 
 
=== Scheduling / HA ===
 
PE Agent is scheduled by PE Manager. When agent downs, PE Agent scheduler will reschedule bgp network for another agent. PE Scheduler itself has bulid-in HA (ACT - Sby ) support for managing PE schedule. PE Manager also dispatch message from Quantum to specific PE-Agent.
 
 
 
== Configuration variables: ==
 
 
 
=== quantum server configuration ===
 
 
 
# my_as
 
# bgp_speaker ip and port: specifies bgp speaker which will be interconnected
 
# route_target_range: route target range for rt assignment
 
# route_distinguisher_range: rd range for rd assignment
 
# bgpvpngroup_driver: driver for managing route target
 
# bgpspeaker_driver (*)
 
# driver to configure bgp speaker
 
 
 
You can use db or quantum value for bgpvpngroup_driver
 
 
 
* bgpvpngroup_driver=db using local db
 
* bgpvpngroup_driver=quantum use another quantum server
 
 
 
=== bgpspeaker  configuration ===
 
 
 
# my_as
 
# bgp_identifier
 
# neighbors
 
 
 
== API's: == 
 
CRUD rest api for each new resources
 
 
 
== Plugin Interface: Implement above data model ==
 
 
 
== Required Plugin support: yes ==
 
 
 
== Dependencies: BGPSpeaker ==
 
 
 
== CLI Requirements: ==
 
 
 
show dynamic routes
 
 
 
== Horizon Requirements: ==
 
 
 
# Extended attribute configuration page
 
# show dynamic routes
 
 
 
=== Usage Example: ===
 
 
TBD
 
 
 
=== Test Cases: ===
 
 
 
Connect two different openstack cluster (devstack) with BGP/MPLS vpn
 

Latest revision as of 05:41, 20 November 2013

Updated for more simple model (see https://docs.google.com/a/ntti3.com/document/d/1aVfYHiGrwL7XyE639_sCBkmALy7FKCJqPX8DqiHk7kY/edit#heading=h.kf4wr792gej6 )