http://specs.openstack.org/openstack/neutron-specs/specs/juno/bgp-dynamic-routing.html

Dynamic Routing for External Networks

The goal of this blueprint is to add a dynamic routing capability to OpenStackdeployment. This feature would allow Neutron to exchange routes with an externalrouter using standard routing protocols.

This document aims to define a foundation supporting differentroute discovery/advertise protocols.

Problem description

This is a new feature and this section will describe use cases where dynamicrouting may be useful.

Expose External Networks Dynamically

Allow Neutron to dynamically announce to and/or from external uplinkrouters.

An OpenStack cloud would run a routing protocol (for example, BGP) against atleast one router in each uplink network provider. By announcing external networkhosting floating IP prefixes to those peers, the Neutron network would bereachable by the rest of the internet via both paths. If the link to an uplinkprovider broke, the failure information would propagate to routers further upthe stream, keeping the cloud reachable through the remaining healthy link.Likewise, in such a case, Neutron would eliminate the routes learned through thefaulty link from its forwarding table, redirecting all cloud-originated trafficthrough the healthy link.

Sample Topology

Please note that in this diagram, the red gateway router is actually a linuxmachine with a software BGP speaker and a software router. This blueprintproposes to configure this BGP speaker through the Neutron API (see below).

In this scenario each external network’s address range will be advertised as aroute. Individually allocated floating IP addresses will not be exported as hostroutes to reduce the workload of the upstream router(s).

This also would be a valid scenario for an internal cloud, where the uplinkrouter is actually one’s provider router and the routes are advertised usingiBGP.

Learn Uplink Routes Dynamically

With a dynamic routing system, having tenant routers connected directly touplink routers, will let you discover dynamically uplink routes.

Routed Model for Floating IPs on External Network

This use case will allow an external network with a large public IP space topossibly span more than one L2 network. This could allow for improved scale andisolation between AZs while maintaining the appearance of a large externalnetwork where floating IPs and networks can float freely.

This use case may also include announcing public networks behind Neutron routersto an upstream router. It does not require learning routes from the upstreamrouter.

Sample Topology

This use case is covered in detail in Pluggable External Net Blueprint

The topology of this use case can be seen as a generalization of the previousone, with a multi-homed OpenStack installation and leverage the fact that afloating IP can be seen as a /32 network.

Proposed change

Overview

A new system that dynamically advertises and discovers routes from other peersoutside the OpenStack deployment is proposed. From the Neutron API, cloudadministrator should be able to define these peers as well as the way tointeract with them.

Peer Configuration

A system that supports dynamic routing must be able to both advertise its ownroutes to its peers as well as discover peers’ routes. It order to achieve thisthe system must know the list of its peers and be able to trust the informationthat it receives from them.

Route Advertisement

When enabled, the system will automatically advertise all external networks toconfigured dynamic routing peers. Routes added manually by administrator willhave an option to be advertised to external dynamic routing peers.

Route Discovery

Routes advertised by remote dynamic routing peers will be added to the routingtables of the neutron routers. These are the routes into the namespacesqrouter-<route uuid> in the case of the reference L3 implementation. Since thereis already an RPC call in Neutron to advertise new routes (when user requests anextra route), there will be no need to change anything in the reference L3agent. The route information will show that it was installed dynamically andwill contain the ID of the dynamic routing peer that has advertised it.

The dynamically installed routes will also contain destination virtual portinformation and relative weight. This additional configuration is useful whenthe system has multiple uplinks to the same destination network. In suchscenario there may be 2 or more identical routes that may be differentiated bythe destination port and relative weight fields. The actual L3 agent or 3rdparty router implementation will be able to select the correct port to forwardpackets to.

Dynamic Routing System

In default implementation a new system will be used to manage dynamic routinginformation at the edge of OpenStack deployment. Dynamic peering will not beperformed by each Neutron router due to scaling concerns, as such approach maycreate a high number of peering relationships.

This system will allow different implementations (develop your own BGP speakerimplementation, for instance) to fit into third party requirements.

IPv6 Considerations

The implementation must be able to exchange IPv4 and IPv6 routes.

Solution Proposed

This proposal, Dynamic Routing, is intended to abstract the common dynamicrouting protocols such as BGP and OSPF. Its first driver is based on an agent(dr_agent) implementing BGP.

There is a comparison of different BGP speakers in the wiki’s BGP Comparisontable.

The agent will communicate to the uplink through the chosen protocol and toneutron using RPC calls:

That means the dr_agent will bind an interface to the management network andanother one to theouter network. This outer network may not be the samenetwork than theexternal data path network. The ports to bind shall beinformed in the dr_agent.ini configuration file.

dr_agent does not know anything about the networking topology in use, justwill advertise and receive routes as well as configure its remote peersaccording to Neutron requests.

dr_agent should be able to run in multiple instances, providing HA in thefunctionality of the agent if you configure more than one agent using the samepeers.

Cloud administrator also can configure different agents using different peers,to have the flexibility to expose different external networks to different paths(useful if you have a multi-homed OpenStack deployment):

So, through the Neutron API, cloud administrator should be able to define thepeer connections for each agent, as well as the policies to discover andadvertise routes from those peers, according to his needs. RoutingInstanceobject will be the entity that will group all these configurations.

So the cloud administrator will be able to execute the following actions:

Create a peer connection.
Associate a peer connection to a dr_agent.
Create a Routing Instance. This entity will establish the discovery/advertiseoptions and associate external networks.
Associate a Routing Instance to networks.
Associate a Routing Instance to a dr_agent.

Considerations

Have more than one peer providing routes and in the same time let the user addmanually routes could end up in routing conflicts at the neutron routers. It isout of the scope of this blueprint provide a decision algorithm or offer apolicy interface to solve this conflicts.

Alternatives

Dynamic routing may be implemented using protocols other than BGP. This documentaims to create the framework to make it easier to add more dynamic routingprotocols in the future.

Multi-homed clouds can be handled using classic networking infrastructure,configuring manually the vendor router with BGP outside the OpenStackdeployment.

Data model impact

This document proposes modifying data objects and schema in the following way.For a quick glance of the Data Object Model, check out thisetherpad.

Data Object Changes

Three new data model classes will be added: db.l3_db.RoutingPeer,db.l3_db.RoutingInstance anddb.l3_db.AdvertiseRoute.db.models_v2.Route will be extended.

New db.l3_db.RoutingPeer class will contain the following attributes:

id: UUID
peer: String
protocol: String
config: String (json with remote_as, password, weight, and so on)

(in BGP case, local-as will be configured in dr_agent.ini config file.)

New db.l3_db.RoutingInstance class will contain the following attributes:

id: UUID
networks: List of networkdb.models_v2.Network resources
agents: List of db.agents_db.Agent resources
advertised_routes: List ofdb.l3_db.AdvertiseRoute resources
ipv4: String
ipv6: String
discovery_mode: String (available values will be: Network | None)
advertise_mode: String (available values will be: Network | None)

advertise_mode and discovery_mode are defined as String and not Boolean toallow more fine grained options in the future without modify the database

ipv4 and ipv6 will be the values inserted as next_hop in theadvertised routes. So these should be the IP addresses of the gateway thatconnects to the ISP.

In current Neutron implementation the route data object is defined indb.models_v2.Route class. The following attributes will be added to thisclass:

source, String
weight, Integer
type, String
dynamic, Boolean
origin_type, String
origin_id, UUID

Another data object called db.l3_db.AdvertiseRoute will be created with thefollowing attributes:

id: UUID
nexthop, String
destination, String
source, String

Schema changes

A new resource type will be defined for Peer configuration. It will be calledroutingpeer and will contain the following attributes:

Attribute	Type	Req	CRUD	DefaultValue	ValidationConstraints	Notes
id	uuid-str	n/a	R	generated	n/a	Unique identifierfor peer connectionconfiguration
peer	String	Y	CRU	n/a	n/a	value to identify the peer
protocol	String	Y	CRU	n/a	n/a	Protocol to connectto peer
config	string	Y	CRU	n/a	n/a	json the needed info to connecto tothe peer

Between routingpeer andagents there is an n-to-n relationshipmanaged by the tablepeeragentbindings

Attribute	Type	Req	CRUD	DefaultValue	ValidationConstraints	Notes
id	uuid-str	n/a	R	generated	n/a	Unique identifierfor binding
routingpeer_id	uuid-str	Y	CR	generated	n/a	Unique identifierfor routing peerid
agent_id	uuid-str	Y	CR	generated	n/a	Unique identifierfor agent id

A new resource will be defined to describe how to forward and import trafficfrom external Neutron networks to upstream provider routers. It will be calledroutinginstance and contain the following attributes:

Attribute	Type	Req	CRUD	DefaultValue	ValidationConstraints	Notes
id	uuid-str	n/a	R	generated	n/a	Uniqueidentifier forexternalnetwork gatewayconfiguration
ipv4	str	n/a	CRUD	n/a	it should be a validipv4 address	IPv4 that willbe used as ‘nexthop’ in IPv4networks.
ipv6	str	n/a	CRUD	n/a	it should be a validipv6 address	IPv6 that willbe used as ‘nexthop’ in IPv6networks.
advertise_mode	string	Y	CRU	network	Validmode	whether to advertise the associated networks or not
discovery_mode	string	Y	RU	network		whether to propagate the discovered routesto the network’s router

A routinginstance can manage severaldr_agents, but a dr_agent onlycan be managed by one routinginstance. The normal approach would be add aroutinginstance_id in tableagents. But we don’t want to touch thisentity because it is used by the rest of the agents. So we are going to create anewroutinginstanceagentbindings table with a constraint foragent_idcolumn must be unique.

Attribute	Type	Req	CRUD	DefaultValue	ValidationConstraints	Notes
id	uuid-str	n/a	R	generated	n/a	Unique identifierfor binding
routinginstance\_id	uuid-str	Y	CR	generated	n/a	Unique identifierfor routing instance
agent_id	uuid-str	Y	CR	generated	must be unique	Unique identifierfor agent id

There is also a n-to-n relationship between the routinginstance and thenetworks table.routinginstancenetworkbindings is needed:

Attribute	Type	Req	CRUD	DefaultValue	ValidationConstraints	Notes
id	uuid-str	n/a	R	generated	n/a	Unique identifierfor binding
routinginstance\_id	uuid-str	Y	CR	generated	n/a	Unique identifierfor routing instance
network\_id	uuid-str	Y	CR	generated	n/a	Unique identifierfor network id

A new resource type will be defined for storing route configuration. Acollection of these objects may be used to define a routing table in otherresources. This resource will be calledadvertiseroute and contain the followingattributes:

Attribute	Type	Req	CRUD	DefaultValue	ValidationConstraints	Notes
id	uuid-str	n/a	R	generated	n/a	Unique Identifier forroute configuration
routinginstance_id	uuid-str	Y	CR	generated	n/a	Unique identifierfor routing instance
source	CIDR	N	CRU	0.0.0.0/0	n/a	Value to compare withthe source IP addressof the flow beingforwarded
destination	CIDR	Y	CRU	0.0.0.0/0	n/a	Value to compare withthe destination IPaddress of the flowbeing forwarded
nexthop	IPaddress	Y	CRUD	None	Routable IPaddress	IP address of the nexthop

REST API impact

Peer Connection Settings

The following Neutron API changes will allow an administrator to configure peerconnections.

List Peer Connections, Show Peer Connection

Verb	URI	Description
GET	/routingpeers	List the peer connections
GET	/routingpeers/{routingpeer_id}	Show the configuration forpeer connection with thespecified id

Response Codes:

200: Normal
401: Unauthorized
403: Forbidden (for example, when non-administrator tries to accessconfiguration)
404: Not Found (for example, when the peer connection with the specified IDdoesn’t exist)

On success a response will contain one or more peer connection objects (JSONformat used in the example). On failure, the response will contain empty body.Note that “password” field is not included in the output. The API may only beused to create/update/delete password field, not to display it. Password will beprovided to the plugin code in the clear text.

{
 [{
    “routingpeer”: {
       “id”: “88d2dbf0-35e5-11e3-aa6e-0800200c9a66”,
       “peer”: “10.32.0.2”,
       "protocol": "bgp",
       "configuration" : {
         “local_as”: “65000”,
         “remote_as”: “65001”,
         “weight”: “1”,
       }
    }
  },
  {
    “routingpeer”: {
      “id”: “40edaac2-881c-457b-9b4f-05bcd8510d28”,
      “peer”: “10.32.0.3”,
      "protocol": "bgp",
      "configuration": {
        “local_as”: “65000”,
        “remote_as”: “65002”,
        “weight”: “2”
      }
    }
  }]
}

Create Peer Connection

Verb	Uri	Description
POST	/routingpeers	Create a new peer connectionconfiguration

Response Codes:

201: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator user tries to create BGPconfiguration)
404: Not Found (for example, when the router with the specified id does notexist)

This operation requires a request body and returns a response body. Both containBGP configuration inside object. A JSON-encoded example is provided.

Request:

{
 “routingpeer”:
 {
   “peer”: “10.32.0.17”,
   "protocol": "bgp",
   "configuration": {
       “password”: “secret”,
       “local_as”: “65000”,
       “remote_as”: “65005”,
   }
 }
}

Response:

{
 “routingpeer”:
 {
   “id”: “c1bcd3d8-2f02-4d05-8283-ff87ae962223”,
   “peer”: “10.32.0.17”,
   "protocol": "bgp",
   "configuration": {
       “local_as”: “65000”,
       “remote_as”: “65005”,
       “weight”: “2147483647”,
   }
 }
}

Update Peer Connection

Verb	Uri	Description
PUT	/routingpeers/{id}	Update peer connectionconfiguration

Response Codes:

200: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator tries to update BGPconfiguration)
404: Not Found (for example, when the BGP connection with the specified iddoes not exist)

This operation requires a request body and returns a response body. Both containRoutingPeer object. A JSON-encoded example is provided.

Request:

{
 “routingpeer”:
 {
   “id”: “c1bcd3d8-2f02-4d05-8283-ff87ae962223”,
   "configuration": {
       “remote-as”: “65006”,
   }
 }
}

Response:

{
 “routingpeer”:
 {
   “id”: “c1bcd3d8-2f02-4d05-8283-ff87ae962223”,
   “peer”: “10.32.0.17”,
   "protocol" : "bgp",
   "configuration": {
       “local_as”: “65000”,
       “remote-as”: “65006”,
       “weight”: “2147483647”
   }
 }
}

Delete Peer Connection

Verb	Uri	Description
DELETE	/routingpeers/{id}	Delete peer connectionconfiguration

Response Codes:

204: Normal
401: Unauthorized
404: Not Found (for example, if the peer connection with the specified id doesnot exist)

This operation does not require request body and does not provide response body.

Routing Instance Settings

Routing instance is the configuration entity that makes relationships betweenthe networks to advertise, routes to discover and configured peers. It can beseen as the entity that providesVRF in Neutron.

List Routing Instances, Show Routing Instance config

Verb	URI	Description
GET	/routinginstances	List the routing instances
GET	/routinginstances/{routinginstance_id}	Show the configuration forthe routing instance with thespecified id

Response Codes:

200: Normal
401: Unauthorized
403: Forbidden (for example, when non-administrator tries to accessconfiguration)
404: Not Found (for example, when the peer connection with the specified IDdoesn’t exist)

Response:

{[
  { "routinginstance":
      {
        “id”: “r1bcd3d8-2f02-4d05-8283-ff87ae962223”,
        "advertise_mode": "network",
        "discovery_mode": "none",
        "ipv4": "119.12.32.2",
        "ipv6": "",
        "agents": [
          “a1bcd3d8-2f02-4d05-8283-ff87ae962223”,
          “a2bcd3d8-2f02-4d05-8283-ff87ae962223”
        ],
        "networks": [
          “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
        ],
        "advertise_routes": [
        ]
      }
  },
  { "routinginstance":
    {
        “id”: “r2bcd3d8-2f02-4d05-8283-ff87ae962223”,
        "advertise_mode": "network",
        "discovery_mode": "network",
        "ipv4": "119.12.32.2",
        "ipv6": "",
        "agents": [
          “a3bcd3d8-2f02-4d05-8283-ff87ae962223”,
        ],
        "networks": [
          “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
          “n2bcd3d8-2f02-4d05-8283-ff87ae962223”,
        ],
        "advertise_routes": [
          {
            "destination": "33.33.33.0/22",
            "nexthop": "119.15.112.1",
          }
        ]

      }
    }
  }
]}

Now there is an example of the return entity, it is worth to clarify what thisdata means:

Routing Instance r1bcd3d8-2f02-4d05-8283-ff87ae962223 will advertise thenetworksn1bcd3d8-2f02-4d05-8283-ff87ae962223 through the peers connectedto the agentsa1bcd3d8-2f02-4d05-8283-ff87ae962223 anda2bcd3d8-2f02-4d05-8283-ff87ae962223 but won’t update the routers of thisnetwork.
Routing Instance r2bcd3d8-2f02-4d05-8283-ff87ae962223 will advertise thenetworksn1bcd3d8-2f02-4d05-8283-ff87ae962223 andn2bcd3d8-2f02-4d05-8283-ff87ae962223 through the peers connected to theagenta3bcd3d8-2f02-4d05-8283-ff87ae962223 and will update the routersassociated to this networks with the discovered routes.

Create Routing Instance

Verb	Uri	Description
POST	/routinginstance	Create a new routing instance

Response Codes:

201: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator user tries to create arouting instance)
404: Not Found (for example, when the routing instance with the specified iddoes not exist)

This operation requires a request body and returns a response body. Both containRoutingInstance object. A JSON-encoded example is provided.

Request:

{
 “routinginstance”:
 {
   "ipv4": "119.12.32.2",
   "discovery_mode": "network",
   "advertise_mode": "network"
 }
}

Response:

{
 “routinginstance":
 {
   “id”: “r1bcd3d8-2f02-4d05-8283-ff87ae962223”,
   "discovery_mode": "network",
   "advertise_mode": "network"
   "ipv4": "119.12.32.2",
   "ipv6": "",
   "agents": [
   ],
   "networks": [
   ],
   "advertise_routes": [
   ]
 }
}

Associate a Routing Instance to a network

Verb	Uri	Description
PUT	/routinginstance/{routinginstance_id}/add_network	Associate a Routing Instance to anetwork

Response Codes:

201: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator user tries to modify therouting instance)
404: Not Found (for example, when the network with the specified id does notexist)
409: Conflict (for example, the ID is valid but is not actually a network)

Request:

{
  "network_id": “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
}

Response:

{
  “routinginstance":
  {
    “id”: “r1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    "discovery_mode": "network",
    "ipv4": "119.12.32.2",
    "ipv6": "",
    "advertise_mode": "network",
    "agents": [
    ]
    "networks": [
      “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    ],
    "advertise_routes": [
    ]
  }
}

Disassociate a Routing Instance to a network

Verb	Uri	Description
PUT	/routinginstance/{routinginstance_id}/remove_network	Disassociate a Routing Instance toa network

Response Codes:

201: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator user tries to modify therouting instance)
404: Not Found (the routinginstance does not exist)

Request:

{
  "network_id": “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
}

Response:

{
  “routinginstance":
  {
    “id”: “r1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    "discovery_mode": "network",
    "advertise_mode": "network",
    "ipv4": "119.12.32.2",
    "ipv6": "",
    "agents": [
    ],
    "networks": [
    ],
    "advertise_routes": [
    ]
  }
}

Associate a Routing Instance to an Agent

Verb	Uri	Description
PUT	/routinginstance/{routinginstance_id}/add_agent	Associate a Routing Instance to anagent

Response Codes:

201: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator user tries to modify therouting instance)
404: Not Found (for example, when the agent with the specified id does notexist)
409: Conflict (for example, the ID is valid but is not actually an agent)

Request:

{
  "agent_id": “a1bcd3d8-2f02-4d05-8283-ff87ae962223”,
}

Response:

{
  “routinginstance":
  {
    “id”: “r1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    "discovery_mode": "network",
    "advertise_mode": "network",
    "ipv4": "119.12.32.2",
    "ipv6": "",
    "agents": [
      "a1bcd3d8-2f02-4d05-8283-ff87ae962223"
    ],
    "networks": [
      “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    ],
    "advertise_routes": [
    ]
  }
}

Disassociate a Routing Instance to an Agent

Verb	Uri	Description
PUT	/routinginstance/{routinginstance_id}/remove_agent	Dissasociate a Routing Instance toan agent

Response Codes:

201: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator user tries to modify therouting instance)
404: Not Found (for example, when the routing instance id does not exist)
409: Conflict (for example, the ID is valid but is not actually an agent)

Request:

{
  "agent_id": “a1bcd3d8-2f02-4d05-8283-ff87ae962223”,
}

Response:

{
  “routinginstance":
  {
    “id”: “r1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    "discovery_mode": "network",
    "advertise_mode": "network",
    "ipv4": "119.12.32.2",
    "ipv6": "",
    "agents": [
    ]
    "networks": [
      “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    ],
    "advertise_routes": [
    ]
  }
}

Update a Advertise Routes

This action gives you the chance to statically add routes to advertise. Pleasenote some advertise routes will be added dynamically by Neutron according to theadvertise_mode field and the networks associated to the Routing Instance. So,some deleted routes may appear again in the future.

Verb	Uri	Description
PUT	/routinginstance/{routinginstance_id}/update_routes	Update routes to advertise

Response Codes:

201: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator user tries to modify therouting instance)
404: Not Found (for example, when the agent with the specified id does notexist)

Request:

{
  "advertise_routes": [
    {
      "nexthop":"10.1.0.10",
      "destination":"40.0.1.0/24"
    }
  ]
}

Response:

{
  “routinginstance":
  {
    “id”: “r1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    "discovery_mode": "network",
    "advertise_mode": "network",
    "ipv4": "119.12.32.2",
    "ipv6": "",
    "agents": [
      "a1bcd3d8-2f02-4d05-8283-ff87ae962223"
    ],
    "networks": [
      “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    ],
    "advertise_routes": [
      {
        "nexthop":"10.1.0.10",
        "destination":"40.0.1.0/24"
      }
    ]
  }
}

Update Routing Instance

Verb	Uri	Description
PUT	/routinginstance/{routinginstance_id}	Update a routing instance

Response Codes:

201: Normal
400: Bad Request (for example, invalid request format)
401: Unauthorized
403: Forbidden (for example, when non-administrator user tries to modify therouting instance)
404: Not Found (for example, when the agent with the specified id does notexist)

Request:

{
  "routinginstance": [
    {
      "advertise_mode":"None",
      "ipv6: "fe80::21f:3bff:fe02:8607/64"
    }
  ]
}

Response:

{
  “routinginstance":
  {
    “id”: “r1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    "discovery_mode": "network",
    "advertise_mode": "None",
    "ipv4": "119.12.32.2",
    "ipv6: "fe80::21f:3bff:fe02:8607/64"
    "agents": [
      "a1bcd3d8-2f02-4d05-8283-ff87ae962223"
    ],
    "networks": [
      “n1bcd3d8-2f02-4d05-8283-ff87ae962223”,
    ],
    "advertise_routes": [
      {
        "nexthop":"10.1.0.10",
        "destination":"40.0.1.0/24"
      }
    ]
  }
}

Delete Routing Instance

Verb	Uri	Description
DELETE	/routinginstance/{id}	Delete a Routing Instance

Response Codes:

204: Normal
401: Unauthorized
404: Not Found (for example, if the Routing Instance does not exist)

This operation does not require request body and does not provide response body.

Security impact

This feature will allow an external system to manipulate routing informationwithin Neutron network. The external system should be trusted and may beauthenticated using a shared secret.

Dynamic routing may only be configured by the system administrator.

Notifications impact

A notification should be provided when connectivity of control channel overwhich routes are exchanged is interrupted

Other end user impact

The following CLI commands will be added to manage peer connectionconfiguration:

routingpeer-list: List configured peers.
routingpeer-show(id): Show detailed peer configuration for thespecified peer connection.
routingpeer-create(gateway, peer, protocol, config): Create a new peerconnection configuration.
routingpeer-update(id, config): Update existing peer connectionconfiguration.
routingpeer-delete(id): Delete peer configuration for the specifiedpeer connection.
agent-update(id): Modify the agent update call to allow associatedr_agent toroutingpeer.

The following CLI commands will be added to manage RoutingInstance specification forconnecting OpenStack to outside networks:

routinginstance-list: List configured Routing Instances.
routinginstance-show(id): Show detailed Routing Instance configuration.
routinginstance-create(advertise_mode, discovery_mode) Create new RoutingInstance.
routinginstance-update(id, advertise-mode, discovery_mode): Update RoutingInstance specification.
routinginstance-delete(id): Delete Routing Instance specification
routinginstance-routes-update(id, routes): Update the advertise routes.
routinginstance-agent-add(id, agent_id): Associate an agent to a RoutingInstance
routinginstance-agent-remove(id, agent_id): Disassociate an agent to aRouting Instance
routinginstance-network-add(id, network_id): Associate a network to a RoutingInstance
routinginstance-network-remove(id, network_id): Disassociate a network to aRouting Instance

Horizon Requirements

A new screen will be added to configure gateway configuration for connectingOpenStack to outside networks. This screen will allow routes and peerconfiguration to be added to gateway configuration.

An external network will have an option to be linked to a routing instance.

Usage Example

Configure 2 uplinks for the routing instance serving an external network toadvertise its routes and update the discovered ones.

Sample configuration using Neutron CLI commands:

neutron routingpeer-create --protocol bgp --gateway ext-gateway --peer
    10.10.0.15 \ --password secretsession --local-as 65010 --remote-as 65001

neutron routingpeer-create --protocol bgp --gateway ext-gateway --peer
    10.10.0.16 \ --password secretsession --local-as 65010 --remote-as 65002

neutron agent-update --add-peer created_peer1_uuid agent_id

neutron agent-update --add-peer created_peer2_uuid agent_id

neutron routinginstance-create --advertise_mode network --discovery-mode
  network

neutron routinginstance-agent-add agent_id

neutron routinginstance-network-add network_id

Performance Impact

This feature describes an out of band mechanism to negotiate routingconfiguration. This feature should not have a performance impact on Neutronnetwork.

Other deployer impact

This feature would have to explicitly enabled and configured before it will takeeffect. There are no changes to configuration files.

Developer impact

This change does not affect current developments or any plugin development.

Neutron API exposed is agnostic of the exchange routing protocol used. Ifanother developer want to provide other driver than BGP with exabgp, only thedr_agent part will be affected with new code.

Implementation

Assignee(s)

This is a pre-liminary contributor list

Primary assignee:: nextone92
Other contributors:: devvesa

Work Items

Create the dr_agent, exposing the API and implemented with the chosenBGP speaker. (BGP Comparison)
Model tables and API resources.
Periodically scheduled process to communicate with dr_agent.
Testing.
Devstack.
Documentation.

Dependencies

Depending on the implementation, new system library or python library will needto be installed.

Testing

Dynamic routing testing may be performed in an isolated environment. An externalautonomous system may be simulated with an instance of BGP capable softwarerouter (for example, quagga).

The following dynamic routing scenarios could be tested:

Verify that when BGP is enabled on the gateway and one peer is configured theagent establishes BGP session with the peer, receives a list of routes, andsubmits advertised routes to the peer.

Verify that when BGP is disabled on the gateway and one peer is configured thedr_agent establishes no BGP sessions.

Verify that when BGP is enabled on the agent and 3 BGP peer connections areconfigured, the agent establishes 3 BGP sessions, one to each of theconfigured peers.

When 2 or more peers are configured, verify that BGP implementation is able todetect when the BGP session is interrupted the routes received from that BGPsession are automatically removed from the routing table.

Documentation Impact

New documentation for the whole functionality.

Dynamic Routing for External Networks

Dynamic Routing for External Networks

Problem description

Proposed change

Overview

Peer Configuration

Route Advertisement

Route Discovery

Dynamic Routing System

IPv6 Considerations

Solution Proposed

Considerations

Alternatives

Data model impact

Data Object Changes

Schema changes

REST API impact

Peer Connection Settings

List Peer Connections, Show Peer Connection

Create Peer Connection

Update Peer Connection

Delete Peer Connection

Routing Instance Settings

List Routing Instances, Show Routing Instance config

Create Routing Instance

Associate a Routing Instance to a network

Disassociate a Routing Instance to a network

Associate a Routing Instance to an Agent

Disassociate a Routing Instance to an Agent

Update a Advertise Routes

Update Routing Instance

Delete Routing Instance

Security impact

Notifications impact

Other end user impact

Horizon Requirements

Usage Example

Performance Impact

Other deployer impact

Developer impact

Implementation

Assignee(s)

Work Items

Dependencies

Testing

Documentation Impact

References