Google wifi at Starbucks, it's free right?

    I noticed something today, Google is partnering and sponsoring "free" wifi for the Starbucks patron. Now this isn't new news as I found out that they announced this last year. Tells you how much I noticed this change. This makes sense as I found it hard to see how AT&T was monetizing wifi customers. This is a great strategic move for Google on the other hand as now they have a more captive audience to track. 7000 stores worth of audience to be exact.
     They'll know a customer's ip address. They can tell which websites customers are going to based on DNS lookups. This circumvents a browser's Do Not Track or disabling of cookies because their is no need to adhere to it. Unless you're a savvy patron who knows networking by manually changing the DNS address, most people will use Google's DNS address. Even then Google can still figure out where you're going by doing some Deep Packet Inspection sampling on traffic passing through their networking gear. By clicking on their terms of service, a patron is basically allowing them to do this, thus giving up more of their info to the Marketing Juggernaut.
     I haven't used their wifi service, but I'm assuming you'll need to register for a Google Account in order to use their service. Then they'll probably have some kind of jump point to sell you Google products, like music as you sip your expresso drink. They even made an app that has an auto-login capability. It's supposed to be "convenient" for you so you don't have to open a webpage and click "accept" on their terms of service every single time. However this also means that Google will know every time you walk into a Starbucks and how long you spend time goofing off working at a location. Even if you don't use the internet when you visit, they'll know. 
     I don't know how many people use the wifi at a Starbucks location, but I see quite a few people on laptops tapping away on their keyboards dreaming up of the next big startup. I wonder how they would feel if they knew it wouldn't take much for Google to see what they were working on. Well played Google. I'll have a Tall Vanilla Latte please, hold my privacy please.

python script that will add a vlan on a Juniper switch

Here's a simple python script to add a vlan on an EX switch. I use an argument to pass the vlan id to the script.

from my laptop shell

----------

[MYMAC:~/scripts/PYTHON] user% python vlan_add.py 100

Config added:

set vlans v100 vlan-id 100

diff from junos device:

[edit vlans]

+   v100 {

+       vlan-id 100;

+   }

None

---------------------------

On the EX switch:

{master:0}[edit]

user@myswitch# show vlans 

v100 {

    vlan-id 100;

}

The python script:

[MYMAC:~/scripts/PYTHON] user% more vlan_add.py 

------------------------

from sys import argv

from jnpr.junos import Device

from jnpr.junos.utils.config import Config

session = Device(host='myswitch',user='user',password='password')

session.open()

change = Config(session)

vlan = argv[1]

cmd = 'set vlans v%s vlan-id %s' % (vlan,vlan)

print 'Config added:'

print cmd

change.load(cmd, format ='set')

print 'diff from junos device:'

print change.pdiff()

change.commit()

session.close()

My attempt at python scripting using netconf to extract information from a juniper router

Here's a pretty simple script. I loaded all the modules for netconf from github.

You'll need to make sure the router is configured to accept netconf connections.

user@router# show system

services {

    netconf {

        ssh;

    }

}

Now from my mac I can make an off router connection and extract the Juniper hardware inventory information.

[user-mac:~/scripts/PYTHON] user% python chassis.py

executing command: 'show chassis hardware'

Hardware inventory:

Item             Version  Part number  Serial number     Description

Chassis                                G0004             MX80-P

Midplane         REV 01   711-044315   CAAL7076          MX80-P

PEM 0            Rev 03   740-028288   UE00405           AC Power Entry Module

Routing Engine            BUILTIN      BUILTIN           Routing Engine

TFEB 0                    BUILTIN      BUILTIN           Forwarding Engine Processor

  QXM 0          REV 06   711-028408   CAAL7913          MPC QXM

FPC 0                     BUILTIN      BUILTIN           MPC BUILTIN

  MIC 0                   BUILTIN      BUILTIN           4x 10GE XFP

    PIC 0                 BUILTIN      BUILTIN           4x 10GE XFP

      Xcvr 1     REV 01   740-014289   T08A16369         XFP-10G-SR

      Xcvr 3     REV 03   740-014289   CA06BQ03L         XFP-10G-SR

FPC 1                     BUILTIN      BUILTIN           MPC BUILTIN

  MIC 0          REV 26   750-028392   CAAH5493          3D 20x 1GE(LAN) SFP

    PIC 0                 BUILTIN      BUILTIN           10x 1GE(LAN) SFP

      Xcvr 0     REV 02   740-014132   PNC0ZYF           SFP-T

      Xcvr 5     REV 01   740-011782   PCK067K           SFP-SX

    PIC 1                 BUILTIN      BUILTIN           10x 1GE(LAN) SFP

      Xcvr 0     REV 02   740-014132   PNC0ZXX           SFP-T

      Xcvr 1     REV 01   740-013111   6500192           SFP-T

      Xcvr 3     REV 01   740-014132   72322029          SFP-T

      Xcvr 5     REV 01   740-013111   70851030          SFP-T

      Xcvr 8     REV 01   740-014132   72331007          SFP-T

Fan Tray                                                 Fan Tray

Actual Python script.

[user-mac:~/scripts/PYTHON] user% more chassis.py 


______________________

from pprint import pprint as pp 

from lxml import etree

from jnpr.junos import Device as Junos

login = dict(user='user', host='192.168.1.1', password='password')

jdev = Junos(**login)

jdev.open()

# you can run any cli command using the :cli: method, for example

print "executing command: 'show chassis hardware'"

print jdev.cli("show chassis hardware")

Test driving Open Contrail

So I went to the hands on Open Contrail MeetUp. It started off as a semi Q&A overview of the architecture and business use case.

There is a need from Service providers to create services for customers that could

a) be deployed in a timely matter (seconds rather than months

b) Lower Op Ex through automation

c) reduce Operational complexity with template configs

Contrail is a module that can be currently added to an Openstack or Cloudstack platform. I'll talk about the Openstack implementation as I know more about this Cloud platform. The Contrail Controller works entirely in the overlay. It does not know anything about the underlay except for the gateway so it expects the physical network to already be in place. This means it can interoperate with any existing switch vendor network. When you install Contrail as a Neutron plugin into Openstack, it will create a vRouter which is bound to the hypervisor. Currently KVM is the one it works with but I hear that it was tested on VMware as a vm but not directly onto ESXi.  The vRouter is important because you wouldn't use Open vSwitch (OVS). The main function of Contrail is creating the overlay network within Openstack.

Here's how this works. Let's look at this simple logical topology

First you would go to the Contrail Controller (Web GUI) and create the two networks.

Then you would go to the Openstack Horizon Web UI and spin up your VM instances. Under the networking tab you should be able to associate the network to the VM.

Next you would need to create a policy so that each network can talk to each other. Think of it as creating a firewall ACL.

Last you need to attach the policy to each network.

Contrail will automatically assign the VM an ip address and point the default route of the VM to the vRouter.

This will allow you to access the Back End Server.

Overall provisioning time would be roughly 2-3 minutes depending on how fast the VMs can spin up.

Now if you want to provide access to anything outside of the Data Center you'll need to go through a gateway router. AKA Data Center Interconnect (DCI)

To understand this more you will need a Gateway router that speaks MP-BGP can can support GRE or VXLAN. A GRE tunnel will be created from the Contrail vRouter (Virtual) to the physical Gateway Router. If you want to create multi-tenency, you will have to put each tunnel into a separate VRF on the Gateway Router. This provisioning is a manual process of the Gateway Router. Contrail does not manage the Gateway Router at all, however you may be able to automate this function using scripting.
The vRouter will exchange routes via MP-BGP and there is a setting in Contrail to create the Router-Target. The BGP  family types vRouter supports is inet-vpn (or vpnv4) and evpn.

Overall the provisioning is fairly simple. There are a few things I would like "improved" in the product, such as being able to attach a policy from the networking overview "tab" instead of having to drill down into each network and doing it there. There could be a more excel feel to this view as you should be able to make modifications from this view using pulldowns or directly adding the ip subnets.
Also the manual process of creating VRFs on the Gateway router is a bit tedious. I'm investigating whether Openstack has the ability run a script that can make a netconf rpc call to the gateway router.

An alternative is to use slax and curl on a Juniper MX router to extract the details from the Contrail controller.

Neutron Network Namespaces

Warning: The following is a rant of my observations about Openstack neutron.

They shouldn't call it Network Namespaces. They should call it overly complex naming convention.
I've been trying to wrap my head around the networking portion, aka Neutron, of OpenStack. What I've noticed is how ridiculously lousy the Horizon GUI is when trying to troubleshoot any issues. Almost anything useful is accessible through the CLI. What's the purpose of Cloud computing if you have to fallback to the cli to do anything?

When I build a VM, say VM1 on network net1 , I have no visibility about the virtual interfaces that it uses.

For example: Say I want to ping the virtual interface the VM created from the Openstack server. It should be pretty simple right? You should be able to do something like ping <network-name> ip address.

In order to do this you have to use this command:

ip netns - which I believe is short for network namespace

First, you need to know what the networkUUID.

You can list the network objects that were created by the namespace as follows:

# ip netns list
qrouter-ed4afc1b-06ab-417e-a7e2-d5be13b822af
qdhcp-4dc834f5-e759-4d79-acf0-780768f1fa86
qdhcp-0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48
qdhcp-a5958652-7348-436f-8aff-2c9ebd7dd9f7
qdhcp-dc49c1a5-07d0-4225-bea5-02316aec3a42

The structure of the networkUUID looks like this

qdhcp-<networkUUID>

WHAT the hell? That's not a useful name. That's an ID.

You can find this under this directory:

[root@centos-6-5-openstack ~(keystone_admin)]# ls /var/lib/neutron/dhcp/
0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48  a5958652-7348-436f-8aff-2c9ebd7dd9f7
4dc834f5-e759-4d79-acf0-780768f1fa86  dc49c1a5-07d0-4225-bea5-02316aec3a42

and then peer into it's contents

[root@centos-6-5-openstack ~(keystone_admin)]# cat /var/lib/neutron/dhcp/0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48/host
fa:16:3e:b8:98:40,host-20-20-0-11.openstacklocal,20.20.0.11
fa:16:3e:b5:6f:26,host-20-20-0-10.openstacklocal,20.20.0.10

You can also try to do this via this command:

[root@centos-6-5-openstack ~(keystone_admin)]# ip netns exec qdhcp-0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48 ip a
30: tapafe229a7-2e: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:b8:98:40 brd ff:ff:ff:ff:ff:ff
    inet 20.20.0.11/24 brd 20.20.0.255 scope global tapafe229a7-2e
    inet6 fe80::f816:3eff:feb8:9840/64 scope link
       valid_lft forever preferred_lft forever
33: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

It won't give show you the VM's ip, but should show you the subnet it's on.

One other place to look:

[root@centos-6-5-openstack ~(keystone_admin)]# neutron net-list
+--------------------------------------+---------+-------------------------------------------------------+
| id                                   | name    | subnets                                               |
+--------------------------------------+---------+-------------------------------------------------------+
| 0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48 | net1   | d4bf516f-135c-4c7f-ba7e-363cb6c7d307 20.20.0.0/24     |
| 1f438ff9-43cf-4eb4-8b92-a385dc1dff8d | public  | 8942189b-8fbf-44e9-adbb-d62dd0d27015 192.168.250.0/24 |
| dc49c1a5-07d0-4225-bea5-02316aec3a42 | private | 6d67e2de-7f63-454d-9e88-fe33e6121b7b 10.0.0.0/24      |
+--------------------------------------+---------+-------------------------------------------------------+

So once I have the network id I can issue the following command:

[root@centos-6-5-openstack ~(keystone_admin)]# ip netns exec qdhcp-0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48 ping 20.20.0.10
PING 20.20.0.10 (20.20.0.10) 56(84) bytes of data.
64 bytes from 20.20.0.10: icmp_seq=1 ttl=64 time=29.5 ms
64 bytes from 20.20.0.10: icmp_seq=2 ttl=64 time=15.0 ms
^C
--- 20.20.0.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1534ms
rtt min/avg/max/mdev = 15.079/22.301/29.523/7.222 ms

This is such a pain. What if the number of tenants, networks and VMs is huge? Why can't Openstack utilize the network name as part of the network UUid?

Doing reverse lookups of information in order to find things in Openstack

One of the most annoying things I find in Openstack is the lack of use of user friendly names. It's very tedious to reverse lookup information for troubleshooting and configuration.

For example, say I want to find out which tap port on my VM is connected to an openvswitch bridge. I would have to look up the VM in nova and find the corresponding IP assigned to it.

[root@centos-6-5-openstack ~(keystone_admin)]# nova list

+--------------------------------------+------+--------+------------+-------------+---------------------+

| ID                                   | Name | Status | Task State | Power State | Networks            |

+--------------------------------------+------+--------+------------+-------------+---------------------+

| 8b3ecae9-7b59-4b6f-a0a0-bbd5ab5aa629 | aa   | ACTIVE | -          | Running     | net1=192.168.251.10 |

| a679f6f9-bd7d-4e31-95a6-9776c44f0a4a | bb   | ACTIVE | -          | Running     | net1=192.168.251.12 |

Then I would list the ports in neutron.

[root@centos-6-5-openstack ~(keystone_admin)]# neutron port-list

+--------------------------------------+-------------+-------------------+---------------------------------------------------------------------------------------+

| id                                   | name        | mac_address       | fixed_ips                                                                             |

+--------------------------------------+-------------+-------------------+---------------------------------------------------------------------------------------+

| 014d6bba-7ab9-4028-9cd9-dbe27bd51b83 |             | fa:16:3e:1b:19:7d | {"subnet_id": "8942189b-8fbf-44e9-adbb-d62dd0d27015", "ip_address": "192.168.250.10"} |

| 1d3246d7-adb1-4b18-a911-b36562c278e0 |             | fa:16:3e:bd:e9:69 | {"subnet_id": "0147052f-2a0b-4a5b-9930-1d4e258e0c1a", "ip_address": "192.168.251.10"} |

| 40b988aa-c016-4e85-b9cf-beeb4332ab04 |             | fa:16:3e:e1:7e:57 | {"subnet_id": "0147052f-2a0b-4a5b-9930-1d4e258e0c1a", "ip_address": "192.168.251.12"} |

| cb867d96-a4ed-449d-a35a-f3670a14e710 |             | fa:16:3e:ce:a5:7e | {"subnet_id": "0147052f-2a0b-4a5b-9930-1d4e258e0c1a", "ip_address": "192.168.251.11"} |

| d267267b-5630-43df-8a07-05793fd831d0 |             | fa:16:3e:61:84:91 | {"subnet_id": "8942189b-8fbf-44e9-adbb-d62dd0d27015", "ip_address": "192.168.250.11"} |

| f434c257-5bbf-42a6-9136-072d1104fa19 |               | fa:16:3e:24:18:08 | {"subnet_id": "0147052f-2a0b-4a5b-9930-1d4e258e0c1a", "ip_address": "192.168.251.1"}  |

+--------------------------------------+-------------+-------------------+---------------------------------------------------------------------------------------+

Next I would need to look at the mac address and do a lookup in ip address

After coming through the list I can then verify the tap address with ip address show tapxxxx

[root@centos-6-5-openstack ~(keystone_admin)]# ip a show tap40b988aa-c0

30: tap40b988aa-c0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500

    link/ether fe:16:3e:e1:7e:57 brd ff:ff:ff:ff:ff:ff

    inet6 fe80::fc16:3eff:fee1:7e57/64 scope link 

       valid_lft forever preferred_lft forever

And now I can do something useful like see which bridge the tap interface belongs to and verify the mac in the mac table.

[root@centos-6-5-openstack ~(keystone_admin)]# brctl show

bridge name bridge id STP enabled interfaces

qbr1d3246d7-ad 8000.4a04d0b90d18 no qvb1d3246d7-ad

tap1d3246d7-ad

qbr40b988aa-c0 8000.de752effa37c no qvb40b988aa-c0

tap40b988aa-c0

qbr7316a274-16 8000.8671bda4d699 no qvb7316a274-16

tap7316a274-16

qbrd06fccba-ad 8000.4613c3848432 no qvbd06fccba-ad

tapd06fccba-ad

[root@centos-6-5-openstack ~(keystone_admin)]# brctl showmacs qbr40b988aa-c0

port no mac addr is local? ageing timer

  1 de:75:2e:ff:a3:7c yes   0.00

  2 fe:16:3e:e1:7e:57 yes   0.00

or look at the openvswitch table and find out which bridge it belongs to

[root@centos-6-5-openstack ~(keystone_admin)]# ovs-vsctl list-ifaces br-int

int-br-ex

qr-87202226-14

qr-ba3e1c3b-49

qr-f2b01b2b-ad

qr-f434c257-5b

qvo1d3246d7-ad

qvo40b988aa-c0

qvo7316a274-16

qvod06fccba-ad

tapafe229a7-2e

tapca265ec6-29

tapcb867d96-a4

tape4751034-2c

This looks like a to do scripting project to get this information. 

Here I could create a table that would give me:

Nova ID

VM name

VM IP

VM Mac address

Neutron ID

tap interface

bridge mac table

openvswitch bridge

Creating my first OpenStack cloud platform and connecting it to a physical network.

In my quest to learn more about network virtualization I decided to learn more about OpenStack as a cloud platform. So I started from scratch and tried to install Openstack.

I took an old server which had two NIC ports and installed Centos 6.5. I then installed openstack all in one server from the following:

http://openstack.redhat.com/Quickstart

I decided to use the havana version because icehouse just came out and I wanted to wait until after the bugs were fixed.

After doing a bunch of yum installs I had it working. I was actually able to create a few VMs using the Cirros Linux image and created a simple network. I was able to ping from one VM to the other.

However the documentation was not clear on how to connect your VMs to the outside world through a physical network.

After searching around for a few days, I found this:

http://openstack.redhat.com/Neutron_with_existing_external_network

I decided to use eth0 as my management ip to access Openstack and use eth1 as the port for the VMs to connect to the physical network.

I also learned that OpenStack uses OpenVswitch and Neutron for network connectivity. You have to learn a little bit about OpenVswitch on a server.

This led me to make the following changes.
under  /etc/sysconfig/network-scripts

I duplicated (to backup) and changed the following files.

[root@centos-6-5-openstack network-scripts]# more ifcfg-eth1
DEVICE=eth1
TYPE=OVSPort
UUID=100083c1-6174-4a59-b3d0-09081eef106a
ONBOOT=yes
DEVICETYPE=ovs
HWADDR=00:30:48:F9:B9:C9
OVS_BRIDGE=br-ex
NAME="System eth1"

[root@centos-6-5-openstack network-scripts]# more ifcfg-br-ex
DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=192.168.250.11
NETMASK=255.255.255.0
DNS=198.6.1.1
ONBOOT=yes

Then I tied the eth1 interface to the bridge "br-ex"

"br-ex" was automatically created on my server, but if it's not there, you should create a bridge (ova-vsctl add-br <NAME>)  and associate the physical interface (eth1) to that bridge.

[root@centos-6-5-openstack network-scripts]# port br-ex eth1

[root@centos-6-5-openstack network-scripts]# ovs-vsctl show
f6d22683-9529-48b6-b9d0-5e49cb720d44
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port "qg-d267267b-56"
            Interface "qg-d267267b-56"
                type: internal
        Port phy-br-ex
            Interface phy-br-ex
        Port "eth1"
            Interface "eth1"
    Bridge br-int

I also had to make a change to a file:

Add to the /etc/neutron/plugin.ini file these lines:
network_vlan_ranges = physnet1
bridge_mappings = physnet1:br-ex

I had to make sure that eth1 is a port for bridge br-ex not br-int. For some reason it was not doing this, so I removed the port from br-int using ovs-vsctl del-port command

Red hat wants you to restart nework services after making the changes. However when I issued that command, in ifconfig I would see that eth1 still had an ip address and br-ex was not updated. So I rebooted the server.

I also used the following to troubleshoot
tcpdump -nei br-ex
tcpdump -nei eth1

After reboot all was well.

root@centos-6-5-openstack network-scripts]# ifconfig
br-ex     Link encap:Ethernet  HWaddr 00:30:48:F9:B9:C9
          inet addr:192.168.250.11  Bcast:192.168.250.255  Mask:255.255.255.0
          inet6 addr: fe80::5822:16ff:fe25:91a/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:100 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4834 (4.7 KiB)  TX bytes:1336 (1.3 KiB)

br-int    Link encap:Ethernet  HWaddr BE:9D:E4:A4:B0:44
          inet6 addr: fe80::230:48ff:fef9:b9c9/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:213 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16262 (15.8 KiB)  TX bytes:468 (468.0 b)

eth0      Link encap:Ethernet  HWaddr 00:30:48:F9:B9:C8
          inet addr:10.161.32.230  Bcast:10.161.39.255  Mask:255.255.248.0
          inet6 addr: fe80::230:48ff:fef9:b9c8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14400 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1686756 (1.6 MiB)  TX bytes:7627901 (7.2 MiB)
          Interrupt:18 Memory:d8020000-d8040000

eth1      Link encap:Ethernet  HWaddr 00:30:48:F9:B9:C9
          inet6 addr: fe80::230:48ff:fef9:b9c9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:905 errors:0 dropped:0 overruns:0 frame:0
          TX packets:978 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:82360 (80.4 KiB)  TX bytes:87771 (85.7 KiB)
          Interrupt:19 Memory:d8060000-d8080000

int-br-ex Link encap:Ethernet  HWaddr 5A:EC:7F:16:11:35
          inet6 addr: fe80::58ec:7fff:fe16:1135/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:100 errors:0 dropped:0 overruns:0 frame:0
          TX packets:190 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4752 (4.6 KiB)  TX bytes:14550 (14.2 KiB)


From my physical gateway switch/router 192.168.250.1 I tried pinging the br-ex interface 192.168.250.11

Next I created the tenant subnet, vm and the openstack router.

First I had to source my admin credentials

source /root/keystonerc_admin

Next I followed the instructions on creating a public network. I added a floating ip.

http://openstack.redhat.com/Floating_IP_range

By default packstack creates a demo public network, with a subnet that I was not using. So I cleared the gw of this first.

# neutron router-gateway-clear router1
Then deleted the subnet
# neutron subnet-delete public

Next I recreated a new subnet
neutron subnet-create --name public --enable_dhcp=False --allocation-pool=start=192.168.250.10,end=192.168.250.20 --gateway=192.168.250.1 public 192.168.250.0/24

Then created a router using Horizon.
Then I tied the router to the public subnet.

neutron router-gateway-set test-rtr public

[root@centos-6-5-openstack network-scripts(keystone_admin)]# neutron subnet-show public
+------------------+------------------------------------------------------+
| Field            | Value                                                |
+------------------+------------------------------------------------------+
| allocation_pools | {"start": "192.168.250.10", "end": "192.168.250.20"} |
| cidr             | 192.168.250.0/24                                     |
| dns_nameservers  |                                                      |
| enable_dhcp      | False                                                |
| gateway_ip       | 192.168.250.1                                        |
| host_routes      |                                                      |
| id               | 8942189b-8fbf-44e9-adbb-d62dd0d27015                 |
| ip_version       | 4                                                    |
| name             | public                                               |
| network_id       | 1f438ff9-43cf-4eb4-8b92-a385dc1dff8d                 |
| tenant_id        | 3a10de8a82444118865a6398b336ee68                     |
+------------------+------------------------------------------------------+

From Horizon, my setup looks simple:

One thing that threw me off during the whole process was trying to figure out if the openstack Gateway IP was working or not.

I noticed that the status kept saying down.

[root@centos-6-5-openstack network-scripts(keystone_admin)]# neutron port-show router-gw | grep status
| status                | DOWN  

After googling it, I found out that this was a bug and a display issue. So you can't tell if the gateway ip is actually working or not because the status is broken.


From my VM I am now able to access my physical switch