Gitiles
Code Review Sign In
gerrit.opencord.org / sdfabric-docs / 168670a0c1f628cc407bc55bdc83fd982ef68ecc / . / configuration / network.rst
blob: 14efe64ccb7f04d6f59b8fd1896fbf8c61629fb0 [file] [log] [blame]
Network Configuration
=====================
SD-Fabric uses several different types of network configurations.
We only focus on ``devices`` and ``ports`` configuration in this section.
With these configured properly, SD-Fabric can provide basic L2/L3 connectivity.
See :ref:`advanced-features` for advanced feature configurations.
Device Configuration
--------------------
Each switch in SD-Fabric requires a device config.
.. code-block:: json
{
"devices" : {
"device:leaf1" : {
"segmentrouting" : {
"ipv4NodeSid" : 101,
"ipv4Loopback" : "192.168.0.201",
"ipv6NodeSid" : 111,
"ipv6Loopback" : "2000::c0a8:0201",
"routerMac" : "00:00:00:00:02:01",
"isEdgeRouter" : true,
"adjacencySids" : []
},
"basic" : {
"name": "Leaf1",
"managementAddress": "grpc://10.128.100.51:9339?device_id=1",
"driver": "stratum-tofino",
"pipeconf": "org.stratumproject.fabric-spgw-int.montara_sde_9_5_0"
}
}
}
}
- ``device:leaf1``: DPID of the device.
- ``ipv4NodeSid``: IPv4 node segment ID, which is used as an MPLS label in
forwarding IPv4 traffic. Can be arbitrary and should be globally unique.
- ``ipv4Loopback``: IPv4 loopback address. Can be arbitrary, should be globally
unique and should not be part of the same subnet(s) defined on the data plane
ports (see port config).
- ``ipv6NodeSid``: IPv6 node segment ID, which is used as an MPLS label in
forwarding IPv6 traffic. Can be arbitrary and should be globally unique. Only
required when using IPv6.
- ``ipv6Loopback``: IPv6 loopback address. Can be arbitrary, should be globally
unique and should not be part of the same subnet(s) defined on the data plane
ports (see port config). Only required when using IPv6.
- ``routerMac``: Router MAC address. Can be arbitrary and should be globally
unique. This MAC address will be used to reply the ARP request for the
loopback IP or the Interface IP that will be introduced later. (We recommend
using the MAC address of the device's management interface as the router
MAC.)
- ``isEdgeRouter``: True for leaf switches. False for spine switches.
- ``adjacencySids``: Deprecated. Just put an empty array for now.
- ``name``: Name of the device. It is an arbitrary name to identify the device easily.
- ``managementAddress``: gRPC endpoint of the Stratum device and a numerical device ID.
The IP address can be replaced by domain name as well.
- ``driver``: ``stratum-bmv2`` or ``stratum-tofino``, depending on which switch this is.
- ``pipeconf``: A list of available pipeconfs can be dumped by running ``pipeconfs`` in ONOS CLI.
Select the pipeconf you would like to use for this device.
.. caution::
We should avoid using reserved MPLS labels for ``ipv4NodeSid`` and
``ipv6NodeSid``. Please check here for the reserved values:
http://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml
.. note::
Most of the SD-Fabric configurations support dynamic configuration updates.
Unfortunately, SD-Fabric currently **do not support dynamic device
configuration updates**. You will have to restart the device when if
corresponding device configuration changes.
Having said that, when introducing a completely new device in the network,
the device configurations pushed before the device's connection should
apply correctly.
Bridging and Unicast Routing
----------------------------
.. attention::
- VLAN **4094** is reserved for unconfigured ports (e.g. spine facing ports)
Access Ports
^^^^^^^^^^^^
The necessary but minimum configuration for an access port is simply a VLAN.
.. code-block:: json
{
"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
{
"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.
.. tip::
One subnet cannot be configured on multiple leaf switches.
We usually configure one subnet for all the ports on the same leaf switch.
Tagged Ports
^^^^^^^^^^^^
Tagged port configuration is similar.
.. code-block:: json
{
"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
{
"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
{
"ports" : {
"of:0000000000000204/24" : {
"interfaces" : [ {
"name" : "serverA-intf",
"ips" : [ "10.0.2.254/24", "2000::1ff/120" ],
"vlan-tagged" : [ 20, 40 ]
}]
}
}
}
.. note::
There is a known issue that breaks dynamic VLAN configuration.
Until the issue get resolved, you need to restart the switch agent to reinstall the flows.
IPv6 Router Advertisement
^^^^^^^^^^^^^^^^^^^^^^^^^
Router Advertisement overview
"""""""""""""""""""""""""""""
Router advertisement application is for enabling **Router Advertisement** and
**Router Solicitation** functionalities supported by IPv6 routers.
More details are available in `RFC 4861 <https://tools.ietf.org/html/rfc4861>`_.
Application identifies which IPv6 interfaces are currently configured in the
system and it will try to send out **unsolicited Router Advertisement** (RA)
messages from these interfaces.
Each such RA message will have two mandatory options named **Source link-layer
address** and **MTU**.
Additional RA option **prefix** can be enabled using component configuration
**raGlobalPrefixConfStatus**.
Application also processes **Router Solicitations** (RS) sent from hosts. Upon
receiving RS on a particular interface application stops RA transmission in
that interface and immediately sends RA targeted to the solicited host. After
that application continues unsolicited RA transmission on that interface.
Activate and configure RA
"""""""""""""""""""""""""
RA application can be activated from CLI by running
.. code-block:: console
onos> app activate routeradvertisement
Behavior of RA application is controlled by ONOS component configuration
subsystem and following are possible configuration options.
- ``raThreadDelay``: Delay between consecutive RA transmissions
- ``raPoolSize``: Capacity of thread pool to be used for RA transmissions
- ``raFlagMbitStatus``: RA flag “Managed address configuration”
enabled/disabled
- ``raFlagObitStatus``: RA flag “Other configuration” enabled/disabled
- ``raOptionPrefixStatus``: RA Option “prefix” is enabled/disabled. Router
prefixes will be available in RA only if this flag is “true”
- ``raGlobalPrefixConfStatus``: Enable switch level global prefix
configuration.
Once ``raGlobalPrefixConfStatus`` is enabled, RA prefix option is generated
from port configuration of device, see for more details.
To set the options, following the command (example for ``raOptionPrefixStatus``)
.. code-block:: console
onos> cfg set org.onosproject.ra.RouterAdvertisementManager raOptionPrefixStatus true
Prefix details are picked up from network interface configuration.
RA app will filter out link-local IPs while preparing prefixes.
For example, in following configuration, Prefix will include only
**2001:0558:FF10:04C9::2:1ff/120**.
.. code-block:: json
{
"ports": {
"of:0000000000000018/16": {
"interfaces": [{
"ips": [ "192.168.114.1/24", "2001:0558:FF10:04C9::2:1ff/120", "FE80::4EA8:2AFF:FE24:8E5F/120" ],
"vlan-untagged": "11",
"name": "18-15"
}]
}
}
}
Global prefix configuration
"""""""""""""""""""""""""""
In some cases, users may want to have a set of global prefix **advertised on
all edge interfaces**.
Such prefixes can be configured in **devices** section of network configuration
in the following way.
.. code-block:: json
{
"devices": {
"of:0000000000000018": {
"routeradvertisement" : {
"prefixes": [ "2001:0558:FF10:04C9::3:1ff/120"]
}
}
}
}
.. note::
When global prefix is configured, RA app will ignore any prefixes
configured on switch interfaces.
Notes about interface config
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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/config-vlan.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/config-vlan-invalid.png