| Bridging and Unicast Routing |
| ============================ |
| |
| Access Ports |
| ------------ |
| The necessary but minimum configuration for an access port is simply a VLAN. |
| |
| .. code-block:: json |
| :linenos: |
| |
| { |
| "ports" : { |
| "of:0000000000000204/12" : { |
| "interfaces" : [{ |
| "name" : "serverA-intf", |
| "vlan-untagged": 10 |
| }] |
| }, |
| "of:0000000000000204/16" : { |
| "interfaces" : [{ |
| "name" : "serverB-intf", |
| "vlan-untagged": 10 |
| }] |
| } |
| } |
| } |
| |
| The example above shows two ports (12 and 16) on switch of:204 that have been assigned to VLAN 10 using the ``vlan-untagged`` keyword. |
| It simply means that packets come in and leave out of these switches untagged, |
| but internally they are assigned VLAN 10 and they belong to the bridging domain defined for VLAN 10. |
| |
| ``name`` is used to associate the interface with a globally unique, user friendly name. It can be omitted. |
| |
| With the configuration shown above, the packets will always be bridged, but they cannot be routed out of the VLAN (e.g. to other subnets). |
| To add the capability to route out of VLAN 10, we need to add a subnet/gateway IP (similar to `interface-vlans or SVIs in traditional networks <https://www.youtube.com/watch?v=bUXpmiJpGb0>`_). |
| |
| .. code-block:: json |
| :linenos: |
| |
| { |
| "ports" : { |
| "of:0000000000000204/12" : { |
| "interfaces" : [{ |
| "name" : "serverA-intf", |
| "ips" : [ "10.0.1.254/24"], |
| "vlan-untagged": 10 |
| }] |
| }, |
| "of:0000000000000204/16" : { |
| "interfaces" : [{ |
| "name" : "serverB-intf", |
| "ips" : [ "10.0.1.254/24"], |
| "vlan-untagged": 10 |
| }] |
| } |
| } |
| } |
| |
| In this example, VLAN 10 is associated with subnet ``10.0.1.0/24``, and the gateway IP for hosts in this subnet is ``10.0.1.254/32``. |
| When the desire is to route out of a VLAN, this assignment is currently necessary on all ports configured in the same VLAN. |
| |
| .. note:: |
| |
| Typically we only expect a single subnet for a VLAN. Similar to traditional networks, for us, a subnet == VLAN. Different VLANs should be configured in different subnets. |
| In certain use-cases, it may be necessary to configure multiple subnets in the same VLAN. This is possible by adding more subnet/gateway IPs in the ``ips`` array. |
| |
| |
| Tagged Ports |
| ------------ |
| Tagged port configuration is similar. |
| |
| .. code-block:: json |
| :linenos: |
| |
| { |
| "ports" : { |
| "of:0000000000000204/24" : { |
| "interfaces" : [{ |
| "name" : "serverA-intf", |
| "ips" : [ "10.0.2.254/24", "10.0.4.254/24" ], |
| "vlan-tagged" : [ 20, 40 ] |
| }] |
| } |
| } |
| } |
| |
| The configuration above for port 24 on switch of:204 shows two VLANs 20 and 40 configured on that port, with corresponding subnets and gateway IPs. |
| Note that there is no specific ordering required in the ``ips`` or ``vlan-tagged`` arrays to correlate the VLANs to their corresponding subnets. |
| In a future release, we will correlate VLAN and subnets configuration in a more readable way. |
| |
| |
| Native VLAN on Tagged Ports |
| --------------------------- |
| An additional configuration ``vlan-native`` possible on tagged ports includes the ability to specify a VLAN (and thus a bridging domain) for incoming untagged packets. |
| Typically, such configuration in trunk ports in traditional networks is referred to a native VLAN. |
| |
| .. code-block:: json |
| :linenos: |
| |
| { |
| "ports" : { |
| "of:0000000000000204/24" : { |
| "interfaces" : [ { |
| "name" : "serverA-intf", |
| "ips" : [ "10.0.2.254/24", "10.0.4.254/24", "10.0.1.254/24" ], |
| "vlan-tagged" : [ 20, 40 ], |
| "vlan-native" : 10 |
| }] |
| } |
| } |
| } |
| |
| Note that it is also necessary to configure the subnet/gateway IP corresponding to the native VLAN if you wish to route out of that VLAN. |
| |
| |
| Configuring interface for IPv6 |
| ------------------------------ |
| It is similar to configure IPv6 routing. Simply replace the addresses in ``ips`` with IPv6 addresses. For example, |
| |
| .. code-block:: json |
| :linenos: |
| |
| { |
| "ports" : { |
| "of:0000000000000204/24" : { |
| "interfaces" : [ { |
| "name" : "serverA-intf", |
| "ips" : [ "10.0.2.254/24", "2000::1ff/120" ], |
| "vlan-tagged" : [ 20, 40 ] |
| }] |
| } |
| } |
| } |
| |
| |
| Notes |
| ----- |
| There is no need to configure ports on switches that are meant to connect to other switches. |
| The VLAN (untagged or tagged) configuration is only meant for ports that are connected to hosts (edge ports). |
| |
| .. image:: images/vlan-config.png |
| |
| Furthermore, note that the same VLAN can be configured on multiple ToRs - e.g. vlan 20 in the figure above. |
| However this does not mean that the ports are in the same bridging domain, because in the fabric, the communication between ToRs is through a routed network. ' |
| In other words, a host on VLAN 20 (untagged or tagged) connected to one ToR can communicate with another host on VLAN 20 (untagged or tagged) connected to a different ToR, |
| but the MAC addresses will change as the traffic goes through a routed network. |
| |
| Please do not use this feature to connect switches in unsupported topologies as shown in the example below. |
| The fabric is not designed to be one big Ethernet fabric. The bridging domain is restricted to within one ToR. |
| If the bridging domain is extended across two ToRs directly linked to each other, there is a chance of loops. |
| In other words, the ToRs/Leafs are not standalone 802.1Q bridges, and should not be used as such. |
| |
| .. image:: images/vlan-config-invalid.png |