| 2015-11-11 18:11:28 |
Carl Baldwin |
description |
This RFE bug describes and proposes a type of Neutron network in
which connectivity between the VMs attached to that network is
provided by L3 routing. This type of network provides full (subject
to security policy) IP connectivity between VMs in that and other
routed networks: v4 and v6, unicast and multicast; but it provides no
L2 capability, except as required for this IP connectivity, plus
correct operation of the ICMP, ARP and NDP protocols that exist to
support IP. Therefore, this kind of network is suitable for VMs that
only communicate over IP.
Why would anyone want that? Compared to the other kinds of networks
that provide connectivity at L2, its arguable benefits are that:
- it is conceptually simpler, in that VM data is transported in a
uniform way between a VM and its compute host, between compute
hosts, and between the data center network and the outside world,
without any encapsulation changes anywhere
- as a practical consequence, it is easier to debug, using standard
tools such as ping, traceroute, wireshark and tcpdump
- its scale is not limited in the way that VLAN-based and VXLAN-based
networks are, by the practical diameter of the physical underlying
L2 network.
FYI I started proposing/discussing this as a devref at https://review.openstack.org/#/c/198439/, and lots more detail can be found there about how I think this could work. However, I understand that that is not the correct process, hence in principle starting again here as an RFE bug. |
This RFE bug describes and proposes a type of Neutron network in
which connectivity between the VMs attached to that network is
provided by L3 routing. This type of network provides full (subject
to security policy) IP connectivity between VMs in that and other
routed networks: v4 and v6, unicast and multicast; but it provides no
L2 capability, except as required for this IP connectivity, plus
correct operation of the ICMP, ARP and NDP protocols that exist to
support IP. Therefore, this kind of network is suitable for VMs that
only communicate over IP.
Why would anyone want that? Compared to the other kinds of networks
that provide connectivity at L2, its arguable benefits are that:
- it is conceptually simpler, in that VM data is transported in a
uniform way between a VM and its compute host, between compute
hosts, and between the data center network and the outside world,
without any encapsulation changes anywhere
- as a practical consequence, it is easier to debug, using standard
tools such as ping, traceroute, wireshark and tcpdump
- its scale is not limited in the way that VLAN-based and VXLAN-based
networks are, by the practical diameter of the physical underlying
L2 network.
FYI I started proposing/discussing this as a devref at https://review.openstack.org/#/c/198439/, and lots more detail can be found there about how I think this could work. However, I understand that that is not the correct process, hence in principle starting again here as an RFE bug.
NOTE: The above mentioned devref has been abandoned in favor of a spec here: https://review.openstack.org/#/c/238895/ |
|
