The MidoNet Neutron plugin, through Neutron’s advanced service framework, provides the dynamic routing feature on the provider router.
MidoNet currently only supports BGP but it will also support OSPF in the future. The API design attempts to abstract away the underlying routing protocol.
With the dynamic routing service, an OpenStack cloud would run a routing protocol (for example, BGP) against at least one router in each uplink network provider. By announcing external network hosting floating IP prefixes to those peers, the Neutron network would be reachable by the rest of the internet via both paths. If the link to an uplink provider broke, the failure information would propagate to routers further up the stream, keeping the cloud reachable through the remaining healthy link. Likewise, in such a case, Neutron would eliminate the routes learned through the faulty link from its forwarding table, redirecting all cloud-originated traffic through the healthy link.
Without dynamic routing, the scenario described above would not be possible.
Three new models are introduced.
RoutingInstance is the top level object that abstracts a dynamic routing service (such as BGP, OSFP). When configured, the dynamic routing service is enabled on the router that it is associated with.
RoutingPeer is the peering configuration applied on the router port that you want to start the peering session from. Since RoutingPeers are associated with ports, there would be multiple RoutingPeers for a given RoutingInstance.
AdvertiseRoute is the route advertised with dynamic routing. In Neutron, Floating IP could be advertised to the outside of OpenStack cloud by creating an AdvertiseRoute object for that CIDR.
In MidoNet, routes learned from the peer are inserted into the routing table of the router, and this proposal does not affect this mechanism.
RoutingInstance
| Attribute Name | Type | POST/ PUT | Required | Description |
|---|---|---|---|---|
| id | string (UUID) | POST | generated | ID of the routing instance |
| router_id | string (UUID) | POST | Yes | Router that the routing service is attached to |
| local_as | int | POST | Yes | Local AS number used in BGP |
| protocol | string | No | Routing protocol to use. Only BGP supported, so cannot be updated. |
Deleting the routing instance deletes all the advertise routes and routing peers. ‘loopback address’ feature is not included in this spec, but will be added in the future. Also, while the models proposed are meant to abstract away all the dynamic routing protocols, because MidoNet only handles BGP right now, they only include BGP-specific fields.
A router that has a routing instance associated cannot be deleted, and you must delete the routing instance first.
A router could have only one routing instance associated.
RoutingPeer
| Attribute Name | Type | POST/ PUT | Required | Description |
|---|---|---|---|---|
| id | string (UUID) | POST | generated | ID of the routing peer |
| routing_instance_id | string (UUID) | POST | Yes | Routing instance it is associated with |
| port_id | string (UUID) | POST | Yes | Port used to connect to the peer |
| peer_as | int | POST | Yes | Peer AS number used in BGP |
| peer_address | string | POST | Yes | Peer IP address |
Only IPv4 is supported for ‘peer_address’. In this proposal, the support for establishing connections with peers that do not have an IP address is not included.
Deleting a routing instance deletes the associated routing peers.
AdvertiseRoute
| Attribute Name | Type | POST/ PUT | Required | Desciption |
|---|---|---|---|---|
| id | string (UUID) | POST | generated | Unique Identifier for route configuration |
| routing_instance_id | string (UUID) | POST | Yes | ID of the routing instance the route is associated with |
| destination | string | POST | No | Value to compare with the destination IP address of the flow being forwarded Default: 0.0.0.0/32 |
Only IPv4 is supported for destination.
Deleting a routing instance deletes the associated advertise routes.
midonet_routing_instances
| Name | Type | Description |
|---|---|---|
| id | String | ID of the routing instance |
| router_id | String | ID of the router the routing instance is attached to |
| local_as | Int | Local AS number |
| protocol | String | Routing protocol |
The only supported value for ‘protocol’ is ‘BGP’, but ‘OSPF’ will be added in the future.
midonet_routing_peers
| Name | Type | Description |
|---|---|---|
| id | String | ID of the routing peer |
| routing_instance_id | String | ID of the routing instance associated |
| port_id | String | ID of the port for the peer connection |
| peer_as | Int | Peer AS number used for BGP |
| peer_address | String | Peer IP address |
midonet_advertise_route
| Name | Type | Description |
|---|---|---|
| id | String | ID of the route |
| routing_instance_id | String | ID of the routing instance associated |
| destination | String | destination CIDR to match on |
midonet_tasks
New task data types are introduced:
- ROUTING_INSTANCE
- ROUTING_PEER
- ADVERTISE_ROUTE
For this proposal, dynamic routing configuration is limited to admins only.
The following command creates a routing instance:
The following command gets a routing instance:
The following command lists all the routing instances of a tenant:
The following command associates a routing instance to a router:
The following command disassociates a routing instance from a router:
The following command deletes a routing instance:
The following command creates a routing peer:
The following command deletes a routing peer:
The following command gets a routing peer:
The following command lists all the routing peers of a tenant:
The following command creates an advertise route:
The following command delets an advertise route:
The following command gets an advertise route:
The following command lists all the advertise routes of a tenant: