Cloud Native应用交付

  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
Cloud Native Application Services: cnadn.net
  1. 首页
  2. 化云为雨/Openstack
  3. 正文

Provider network and tenant network in neutron

2014年12月23日 10640点热度 0人点赞 0条评论

OpenStack is composed of many different projects. The core projects provide compute, storage, and network resources. The Neutron project provides network resources to the OpenStack environment and can be difficult to get started with. To help get the gears turning, I will be discussing some of the functionality Neutron Networking is capable of.

I would wager that most of us are familiar with virtualized networking through experience running VMware vSphere. Each node in the VMware vSphere Cluster will have physical NICs connected to physical switch ports on a managed switch. Those physical switch ports on the managed switch are configured as a trunk containing all of the particular VLANs you need accessible from your VMware vSphere Cluster. Within the VMware vSphere Client, virtual networks are created mapping to the different VLANs in the trunk. As VMware virtual machines are provisioned, one or more of those virtual networks can be attached to the virtual machine. The virtual network interfaces within the virtual machines can then be assigned IP addresses associated with the subnet on that particular VLAN and the virtual machines can begin communicating.

OpenStack Neutron Networking has the same capabilities. The controller and compute nodes will have physical NICs connected to physical switch ports on a managed switch. Those physical switch ports on the managed switch are configured as a trunk containing all of the particular VLANs you need accessible from your OpenStack environment. Then from the command line on one of the OpenStack nodes, Neutron Provider Networks (Neutron Provider Networks always map to a physical network with a gateway that exists on a router or firewall) are created mapping to the different VLANs in the trunk. As OpenStack instances are provisioned, one or more of those Neutron Provider Networks can be attached to the instance. The virtual network interfaces within the instances will then be assigned IP addresses associated with the subnet on that particular VLAN and the instances can begin communicating.

Both of these scenarios are very similar to each other, so what else does Neutron Networking bring to the table? Neutron Tenant Networks.

First, what is a Tenant (also known as a Project)? OpenStack has been designed to be a multi-tenant environment. User X and User Y can co-exist within the same OpenStack environment and share compute, storage, and network resources or they can have dedicated compute, storage, and network resources within the same OpenStack environment.

User X can create Neutron Tenant Networks that are completely isolated from any Neutron Tenant Networks created by User Y, even if User X and Y are sharing resources. User X and Y can do this without help from a Systems Administrator (assuming they have the proper permissions). This functionality is possible through the use of Network Namespaces, a feature implemented in the Linux kernel. You can think of Network Namespaces as a chroot jail for the networking stack.

When User X and User Y create Neutron Tenant Networks, a Network Namespace is created for each. When User X and Y create OpenStack instances and attach those instances to their respective Neutron Tenant Network, only those instances within the same Network Namespace can communicate with each other, even if the instances are spread across OpenStack compute nodes. This is very similar to having two physical Layer 2 networks that have no way of communicating with each other until a router is put between them. And this is exactly how different Neutron Tenant Networks can communicate with each other, by putting a Neutron Router between them.

With a Neutron Router between the two Neutron Tenant Networks, the instances in each Neutron Tenant Network can now communicate with each other.

Now, what if those instances need to route out to the internet? One of the Neutron Provider Networks you created above, or possibly a different one, could be attached to the Neutron Router and act as the Neutron Router's default gateway out to the internet. The Neutron Tenant Networks could then be attached to the Neutron Router and those Neutron Tenant Networks could then route out to the internet.

There is a lot more to Neutron Networking, and this has simply been a high-level overview to get you thinking.

If you would like to dive deeper and see how to configure various aspects of Neutron Networking, I encourage you to read the following posts by fellow Racker James Denton:

Neutron Networking: The Building Blocks of an OpenStack Cloud

Neutron Networking: Simple Flat Network

Neutron Networking: VLAN Provider Networks

Neutron Networking: Neutron Routers and the L3 Agent

相关文章

  • openstack L3-GRE 网络结构分析记录 (Icehouse) 第三篇(多租户)
  • openstack L3-GRE 网络结构分析记录 (Icehouse) 第二篇
  • Neutron Networking: Neutron Routers and the L3 Agent
  • Neutron Networking: VLAN Provider Networks
  • openstack L3-GRE 网络结构分析记录 (Icehouse) 第五篇(多外部网络)
本作品采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可
标签: network neutron openstack
最后更新:2014年12月23日

纳米

linjing.io

打赏 点赞
< 上一篇
下一篇 >
页面AI聊天助手

纳米

linjing.io

☁️迈向Cloud Native ADC ☁️

认证获得:
TOGAF: ID 152743
Kubernetes: CKA #664
Microsoft: MCSE MCDBA
Cisco: CCNP
Juniper: JNCIS
F5:
F5 Certified Solution Expert, Security
F5 Certified Technology Specialist, LTM/GTM/APM/ASM
F5 Certified BIG-IP Administrator
  • 点击查看本博技术要素列表
  • 归档
    分类
    • AI
    • Automation
    • Avi Networks
    • Cisco ACI
    • CISCO资源
    • F5 with ELK
    • F5-Tech tips
    • F5技术
    • Juniper
    • Linux
    • NGINX
    • SDN
    • ServiceMesh
    • WEB编程
    • WINDOWS相关
    • 业界文章
    • 交换机技术
    • 化云为雨/Openstack
    • 协议原理
    • 容器/k8s
    • 我的工作
    • 我的生活
    • 网站技术
    • 路由器技术
    • 项目案例
    标签聚合
    k8s api openstack DNS nginx docker gtm neutron F5 envoy istio irule bigip network flannel
    最近评论
    汤姆 发布于 8 个月前(09月10日) 嗨,楼主,里面的json怎么下载啊,怎么收费啊?
    汤姆 发布于 8 个月前(09月09日) 大佬,kib的页面可以分享下吗?谢谢
    zhangsha 发布于 1 年前(05月12日) 资料发给我下,谢谢纳米同志!!!!lyx895@qq.com
    李成才 发布于 1 年前(01月02日) 麻烦了,谢谢大佬
    纳米 发布于 1 年前(01月02日) 你好。是的,因为以前下载系统插件在一次升级后将所有的下载生成信息全弄丢了。所以不少文件无法下载。DN...
    浏览次数
    • Downloads - 183,766 views
    • 联系我 - 118,966 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 116,497 views
    • Github - 103,659 views
    • F5常见log日志解释 - 79,774 views
    • 从传统ADC迈向CLOUD NATIVE ADC - 下载 - 74,623 views
    • Sniffer Pro 4 70 530抓包软件 中文版+视频教程 - 74,320 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 67,770 views
    • 关于本站 - 60,905 views
    • 这篇文档您是否感兴趣 - 55,493 views
    链接表
    • F5SE创新
    • Jimmy Song‘s Blog
    • SDNlab
    • Service Mesh社区
    • 三斗室
    • 个人profile
    • 云原生社区

    COPYRIGHT © 2023 Cloud Native 应用交付. ALL RIGHTS RESERVED.

    Theme Kratos Made By Seaton Jiang

    京ICP备14048088号-1

    京公网安备 11010502041506号