openstack router

3
OpenStack router's external interface is reported as DOWN Updated August 2 2014 at 1:04 AM Issue Instantiated openstack instances on a tenant network seem to have a working network configuration. The instance can get IP, hostname, router IP without problems, and can ping the outside internet, say, www.google.com. o But the router's external interface is reported as DOWN. Why? Environment Red Hat OpenStack 3.0 & 4.0 Resolution There's two different ways to connect a router to its external network. The old approach, using br-ex. The router's external leg is connected to br-ex, and br-ex is connected to some NIC which is connected to an external network. With this old approach you cannot hook up multiple external networks to a L3 agent (So that each router may be connected to a different external network). The new approach uses provider networks, so that the external leg of a router is connected back to br-int, and flows are installed on br-int connecting it to a bridge, which is connected to a physical NIC. This way, you can create multiple external networks on a L3 agent. This code was backported to RHOS 4.0.

Upload: riteshaladdin

Post on 24-Jan-2016

225 views

Category:

Documents


0 download

DESCRIPTION

Datacenter Build Quotation

TRANSCRIPT

Page 1: OpenStack Router

OpenStack router's external interface is reported as DOWNUpdated August 2 2014 at 1:04 AM

Issue

Instantiated openstack instances on a tenant network seem to have a working network configuration. The instance can get IP, hostname, router IP without problems, and can ping the outside internet, say, www.google.com.

o But the router's external interface is reported as DOWN. Why?

Environment

Red Hat OpenStack 3.0 & 4.0

Resolution

There's two different ways to connect a router to its external network. The old approach, using br-ex. The router's external leg is connected to br-ex, and br-ex is connected to some NIC which is connected to an external network. With this old approach you cannot hook up multiple external networks to a L3 agent (So that each router may be connected to a different external network). The new approach uses provider networks, so that the external leg of a router is connected back to br-int, and flows are installed on br-int connecting it to a bridge, which is connected to a physical NIC. This way, you can create multiple external networks on a L3 agent. This code was backported to RHOS 4.0.

Page 2: OpenStack Router

Attached is a diagram and in it you can see that that br-int is an OVS bridge, and does L2 switching rather than L3 routing. Each distinct virtual network (tenant network or provider network) is identified within br-int via a different tag. The OVS bridge does MAC-based learning and forwarding separately for each tag (just like a hardware ethernet switch does with VLANs), isolating the virtual networks from each other. The L3 routing is done by the kernel among the set of devices attached to each router's network namespace. These devices can include any number of tenant (aka private) networks and optionally either a provider or bridge-based external network.

In the diagram br-eth1 is where the provider network resides while br-ex is where you external or L3 routing to a physical network is done.

Root Cause

The router's gateway port's status is managed for provider external networks. When using external_network_bridge ('br-ex'), no L2 agent is involved, so there is nothing that can actively manage the port state. Thus the router's gateway port's status is correctly managed for provider external networks. However when using external_network_bridge ('br-ex'), no L2 agent is involved, so there is nothing that can actively manage the port state