<commit_before>---
title: Networking in too much detail
category: networking
authors: jtaleric, larsks, mpavlase, rbowen
wiki_category: Networking
wiki_title: Networking in too much detail
wiki_revision_count: 6
wiki_last_updated: 2014-10-30
---

# Networking in too much detail

## The players

This document describes the architecture that results from a particular OpenStack configuration, specifically:

*   Quantum (or Neutron) networking using GRE tunnels;
*   A dedicated network controller;
*   A single instance running on a compute host

Much of the document will be relevant to other configurations, but details will vary based on your choice of layer 2 connectivity, number of running instances, and so forth.

The examples in this document were generated on a system with Quantum networking but will generally match what you see under Neutron as well, if you replace `quantum` by `neutron` in names.

## The lay of the land

This is a simplified architecture diagram of network connectivity in a quantum/neutron managed world:

![](neutron.svg "neutron.svg")

Section names in this document include parenthetical references to the nodes on the map relevant to that particular section.

## Compute host: instance networking (A,B,C)

An outbound packet starts on `eth0` of the virtual instance, which is connected to a `tap` device on the host, `tap7c7ae61e-05`. This `tap` device is attached to a Linux bridge device, `qbr7c7ae61e-05`. What is this bridge device for? From the [OpenStack Networking Administration Guide](http://docs.openstack.org/network-admin/admin/content/under_the_hood_openvswitch.html):

> Ideally, the TAP device vnet0 would be connected directly to the integration bridge, br-int. Unfortunately, this isn't possible because of how OpenStack security groups are currently implemented. OpenStack uses iptables rules on the TAP devices such as vnet0 to implement security groups, and Open vSwitch is not compatible with iptables rules that are applied directly on TAP devices that are connected to an Open vSwitch port.

Because this bridge device exists primarily to support firewall rules, I'm going to refer to it as the "firewall bridge".

If you examine the firewall rules on your compute host, you will find that there are several rules associated with this `tap` device:

    # iptables -S | grep tap7c7ae61e-05<commit_msg>The lay of the land<commit_after>---
title: Networking in too much detail
category: networking
authors: jtaleric, larsks, mpavlase, rbowen
wiki_category: Networking
wiki_title: Networking in too much detail
wiki_revision_count: 6
wiki_last_updated: 2014-10-30
---

# Networking in too much detail

## The players

This document describes the architecture that results from a particular OpenStack configuration, specifically:

*   Quantum (or Neutron) networking using GRE tunnels;
*   A dedicated network controller;
*   A single instance running on a compute host

Much of the document will be relevant to other configurations, but details will vary based on your choice of layer 2 connectivity, number of running instances, and so forth.

The examples in this document were generated on a system with Quantum networking but will generally match what you see under Neutron as well, if you replace `quantum` by `neutron` in names.

## The lay of the land

This is a simplified architecture diagram of network connectivity in a quantum/neutron managed world:

[[1](File:neutron_architecture.png)

Section names in this document include parenthetical references to the nodes on the map relevant to that particular section.

## Compute host: instance networking (A,B,C)

An outbound packet starts on `eth0` of the virtual instance, which is connected to a `tap` device on the host, `tap7c7ae61e-05`. This `tap` device is attached to a Linux bridge device, `qbr7c7ae61e-05`. What is this bridge device for? From the [OpenStack Networking Administration Guide](http://docs.openstack.org/network-admin/admin/content/under_the_hood_openvswitch.html):

> Ideally, the TAP device vnet0 would be connected directly to the integration bridge, br-int. Unfortunately, this isn't possible because of how OpenStack security groups are currently implemented. OpenStack uses iptables rules on the TAP devices such as vnet0 to implement security groups, and Open vSwitch is not compatible with iptables rules that are applied directly on TAP devices that are connected to an Open vSwitch port.

Because this bridge device exists primarily to support firewall rules, I'm going to refer to it as the "firewall bridge".

If you examine the firewall rules on your compute host, you will find that there are several rules associated with this `tap` device:

    # iptables -S | grep tap7c7ae61e-05
{'fraction_non_alphanumeric': 0.0506649778340722, 'fraction_numerical': 0.013299556681443952, 'mean_word_length': 4.915106117353308, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3223457', 'n_tokens_mistral': 1260, 'n_tokens_neox': 1178, 'n_words': 658}